Concurso não tem regra fixa, e o software precisa saber disso

O edital do Concurso do Queijo e Produtos Lácteos de Mato Grosso, na terceira edição, foi retificado duas vezes. As duas retificações estão publicadas no site do Sebrae, ao lado do regulamento original. E aconteceram com a inscrição já aberta — com produtor cadastrado e queijo já enviado sob a regra anterior.

Quem organiza concurso lê isso e reconhece. Quem nunca organizou acha que foi desorganização. Não foi.

O edital é escrito antes de a realidade acontecer. Aí chegam vinte queijos numa categoria onde se esperavam cinco, e é preciso dividir a categoria. Dois jurados leem o mesmo critério de formas diferentes, e é preciso deixar o texto mais claro. O transporte das amostras atrasa, e o prazo tem que esticar. Toda edição traz o caso que ninguém previu.

O momento em que o sistema vira problema

É aqui que a maioria dos sistemas de concurso trava o organizador.

Eles são feitos com as regras daquele edital escritas por dentro. As categorias, os pesos de cada nota, quem avalia o quê, quantas notas cada produto recebe — tudo isso fica enterrado no programa. Funciona muito bem na primeira edição.

Na segunda, o edital muda. E aí muda a natureza da conversa: você abre um chamado, espera um programador mexer, espera testarem, espera publicarem. No meio do concurso, com jurado sentado esperando para avaliar. Você deixa de organizar o concurso e passa a gerenciar um fornecedor de software.

O Konq foi construído para o contrário disso. Toda regra do concurso é um campo que o organizador preenche: as categorias e suas subdivisões, os critérios da ficha de avaliação, o peso de cada um, quem julga o quê, como a nota final é calculada. Quando o edital é retificado, alguém ajusta os campos e o concurso segue. Ninguém precisa mexer no sistema, e não existe o risco de quebrar o que já estava funcionando.

A ideia por trás é simples: o Konq se adapta ao seu concurso, não o seu concurso ao Konq. Um sistema que obriga a entidade a mudar o próprio regulamento para caber no software não está ajudando.

O resultado publicado não é o resultado final

Nesta edição aconteceu o caso que mostra melhor por que isso importa.

A apuração já estava fechada e o resultado, pronto. Foi então que a mesa identificou produtos que deveriam ter sido desclassificados. Não era erro de conta — era uma decisão de julgamento que só ficou visível com o resultado à vista.

Houve conversa com o jurado líder, a desclassificação foi aplicada, e o sistema refez a apuração inteira: recalculou sem os produtos desclassificados e remontou a classificação. Quem estava em terceiro podia passar para segundo. E passou.

Parece detalhe, mas quase nenhum sistema de avaliação aceita isso. Eles tratam nota publicada como definitiva — o que é verdade numa prova de escola e é falso em concurso. Concurso tem resultado preliminar. Tem prazo para o produtor recorrer. Tem mesa que revê. Cada uma dessas etapas mexe na classificação depois que ela já existe e já foi vista por todo mundo.

Por isso, no Konq, a conta pode ser refeita quantas vezes for preciso, a qualquer momento, a partir do que está valendo naquele instante. E fica registrado quem mudou o quê e quando — porque quando um produtor questiona o resultado, essa resposta vai ser pedida.

O que você contrata é o piso

Preferimos dizer isso na mesa, antes de fechar: o que está no contrato é o mínimo.

Todo ano o concurso apresenta uma situação que o sistema não previa. A desclassificação tardia foi uma. A retificação que chegou no pior momento foi outra. Cada uma dessas vira melhoria no produto, e chega pronta para quem organizar o próximo concurso.

É por isso que a terceira edição é mais tranquila que a primeira — para todo mundo envolvido.

Se o seu concurso tem edital que muda, prazo recursal e uma mesa que às vezes precisa rever o que já foi publicado, é exatamente esse tipo de coisa que a gente resolve.