Resumo

  • Em fevereiro de 2008, uma universidade ficou fora de uma disputa por financiamento após o portal rejeitar um formulário feito com software incompatível.
  • O preenchimento sem conexão ajudava quem tinha acesso precário à Internet, mas também transferia tarefas de manutenção para o candidato.

Quem prepara um projeto para pedir financiamento espera perguntas difíceis. Por que isso merece dinheiro? O orçamento faz sentido? A primeira pergunta de um sistema eletrônico pode ser bem menos intelectual: com que versão do programa você fez esse arquivo?

Uma grande universidade estadual americana parou nessa etapa em fevereiro de 2008. Ela solicitava aproximadamente US$ 250 mil para assistência educacional a comunidades africanas. A versão antiga do software de formulários era incompatível com a versão mais nova usada pelo Grants.gov. O portal rejeitou o envio e a universidade não conseguiu reapresentá-lo antes do prazo. Perdeu a oportunidade de competir, conforme o relatório de GAO de 2009.

O formulário havia conseguido uma promoção: agora trabalhava na portaria.

Poupar conexão dava trabalho

A opção por formulários preenchidos fora da rede tinha uma justificativa respeitável. O relatório de GAO de 2006 registrou a explicação da equipe do Grants.gov: usuários rurais passariam menos tempo conectados. Manter solicitações incompletas no servidor, com desempenho adequado, também exigiria mais equipamento.

Era uma escolha compreensível para quem precisava economizar tempo numa conexão ruim. Só que preencher no próprio computador exigia ter a máquina certa. O programa funcionava em Windows. Instituições de pesquisa com Macintosh precisavam de outra saída; uma solução provisória havia sido oferecida em dezembro de 2005. Algumas organizações ainda limitavam a instalação de programas e a movimentação de arquivos por suas regras internas de informática.

Antes de convencer o financiador, podia ser necessário convencer o pessoal de TI. O governo colocava a oportunidade na rede; o candidato montava parte da infraestrutura de inscrição em casa ou no trabalho.

Essa divisão distribuía também o risco. Sistema operacional, permissões, versão do leitor e pacote de formulários precisavam combinar. O momento em que se descobria uma incompatibilidade podia ser justamente aquele em que faltava menos tempo para corrigi-la.

A aparência era quase igual. O destino do arquivo, nem sempre

Em setembro de 2008, NIH publicou o calendário da troca de PureEdge por formulários Adobe para NIH e órgãos parceiros. A maioria das submissões eletrônicas a NIH a partir de janeiro de 2009 usaria o novo formato, com exceções listadas. O aviso dizia que as mudanças de aparência eram principalmente cosméticas. Também alertava que versões do Adobe Reader anteriores à 8.1.2 poderiam corromper a solicitação durante o envio.

Uma mudança cosmética com poder para estragar o arquivo completo merecia mais atenção do que a expressão sugeria.

A orientação prática era continuar preparando o plano de pesquisa e os anexos, deixando o preenchimento para quando os novos formulários chegassem, previsto para dezembro. O projeto podia andar enquanto a embalagem oficial ainda estava em preparação. O aviso veio depois do caso universitário de fevereiro; ele documenta outra parte do esforço exigido pela transição.

O episódio mostra quanto poder cabe num requisito técnico aparentemente miúdo. A compatibilidade decidia se o projeto chegaria à disputa. A manutenção do computador passava a interferir no acesso a uma decisão pública.