Como avaliar uma proposta de desenvolvimento de software

Checklist rápido antes de assinar

• Escopo incluído e escopo excluído.
• Premissas e responsabilidades de cada parte.
• Marcos ou cadência de entregas.
• Entregáveis.
• Critérios de aceitação.
• Preço e custos recorrentes.
• Gestão de mudanças.
• Correção de bugs e suporte.
• Direitos sobre o software, licenças e acesso ao código.
• Dependências de terceiros.
• Condições de encerramento e de saída do fornecedor.

O que uma proposta de desenvolvimento de software precisa incluir

Antes de comparar preços, verifique se as propostas cobrem as mesmas coisas. Estes são os elementos que uma proposta profissional deveria trazer por escrito, e não combinados de boca:

Escopo explícito (scope of work). Precisa dizer exatamente o que está incluído — funcionalidades, integrações, documentação — e o que não está. Uma proposta que descreve o projeto em termos genéricos (“uma plataforma que ajude seu time a gerenciar X”) deixa espaço demais para cada parte entender uma coisa diferente, e essas divergências costumam aparecer só no meio do projeto.

Cronograma dividido em fases. Discovery, design, desenvolvimento, testes, lançamento — cada fase com uma data estimada. Não precisa ser milimétrico, mas sem nenhuma referência de tempo você não tem como saber se o projeto está no rumo certo ou atrasando, até que seja tarde demais.

Entregáveis claros por etapa. O que você recebe em cada marco: mockups, código-fonte, documentação, ambiente de testes. Se os entregáveis não estiverem definidos, qualquer “isso não estava incluído” vira discussão de interpretação em vez de um fato verificável no contrato.

Critérios de aceitação. Um entregável não deveria ser definido só pelo nome. Vale estabelecer quais condições ele precisa cumprir para ser considerado pronto, quem valida e o que acontece se não cumprir o combinado. Isso reduz discussões posteriores sobre se algo é bug, tarefa pendente ou pedido novo.

Premissas documentadas. Toda proposta é montada sobre algumas suposições: que você vai disponibilizar determinada informação, que certas decisões de negócio já foram tomadas, que você tem determinados acessos ou dados em mãos. Uma proposta séria escreve isso de forma explícita, para que nenhuma das duas partes se surpreenda quando alguma premissa se mostrar falsa.

Propriedade intelectual, licenças e acesso ao código. Precisa ficar claro quais direitos cada parte recebe ao final do projeto: quais desenvolvimentos são cedidos ao cliente, quais componentes o fornecedor mantém ou licencia, quais elementos pertencem a terceiros e qual acesso o cliente terá ao código-fonte, aos arquivos de design e à documentação. Não presuma que pagar a fatura resolve automaticamente todas essas questões: leia o que o contrato estabelece.

No Paraguai, o artigo 14 da Lei Nº 1328/98 estabelece que, nas obras criadas em execução de um contrato por encomenda, a titularidade dos direitos transferíveis é regida pelo que as partes acordarem. A mesma lei também traz disposições específicas para programas de computador (Lei Nº 1328/98, DINAPI — Instructivo de Derecho de Autor para la Industria del Software). Por isso vale que o contrato defina expressamente o alcance de qualquer cessão ou licença, em vez de depender de interpretações posteriores — esta é uma informação geral, e não uma assessoria jurídica para o seu caso específico.

Também vale identificar bibliotecas, frameworks, componentes open source, APIs e outros elementos de terceiros. O fornecedor não pode repassar a você como próprios direitos que pertencem a terceiros; esses componentes continuam sujeitos às respectivas licenças e condições, que podem condicionar a exploração do software resultante (DINAPI — Instructivo de Derecho de Autor para la Industria del Software).

Custos incluídos e custos recorrentes. Além do desenvolvimento, a proposta deveria indicar quais custos ficam de fora ou continuam depois do lançamento: hospedagem e nuvem, domínios, APIs de terceiros, mensageria, licenças, armazenamento, backups, monitoramento, suporte, manutenção, migração de dados ou treinamento, quando for o caso. Duas propostas com o mesmo preço inicial podem ter custos operacionais muito diferentes lá na frente.

Sinais de alerta

Nenhum desses sinais desqualifica um fornecedor automaticamente, mas, se aparecerem sem explicação, vale perguntar antes de assinar:

• Preço fechado sem levantamento prévio. Um preço fechado pode ser razoável quando o escopo já está suficientemente definido. Se o fornecedor orça sem ter conversado com você nem ter requisitos detalhados em mãos, pergunte com base em qual escopo, quais premissas e quais exclusões aquele valor foi construído.
• Escopo ambíguo ou “tudo incluído”. Propostas que prometem muito sem detalhar geram desgaste depois: quando algo não é entregue, cada parte acha que a outra prometeu outra coisa.
• Nenhum cronograma e nenhum marco. Como orientação geral (não como regra fixa — existem projetos pequenos em que uma gestão mais informal funciona bem), a ausência total de datas ou de entregáveis intermediários costuma dificultar a medição do progresso real até o fim do projeto.
• Preço muito abaixo dos demais. Quando vários orçamentos ficam numa faixa parecida e um deles é bem mais baixo, vale investigar antes de assinar — pode haver um motivo legítimo (estrutura mais enxuta, mais eficiência), mas também pode ser que aquela proposta tenha entendido um escopo diferente ou excluído itens que os outros orçamentos contemplam, e que essas diferenças reapareçam depois como mudanças de escopo. Não presuma nenhuma das duas hipóteses sem perguntar.

Perguntas para fazer ao fornecedor — inclusive as incômodas

Estas são perguntas que qualquer fornecedor sério, a Flexora incluída, precisa conseguir responder com clareza. Se você está avaliando uma proposta da Flexora, faça exatamente as mesmas perguntas que faria a qualquer outro fornecedor.

1. Quais direitos eu recebo sobre o software quando o projeto termina? Existe cessão de direitos patrimoniais, licença de uso ou uma combinação das duas coisas? O que acontece com o código desenvolvido especificamente para você, com os arquivos de design, a documentação, os componentes que o fornecedor já tinha e as dependências de terceiros? Vou ter acesso ao repositório e poder contratar outro time para manter o sistema, se um dia precisar?
2. Como uma mudança de escopo é tratada depois que o contrato é assinado? Precisa de aprovação por escrito? Como ela é orçada? Não deixe essas mudanças só numa conversa: registre cada uma pelo mecanismo de aprovação previsto no contrato.
3. O que acontece depois da entrega final? Existe um período de correção de defeitos? O que o contrato considera bug e o que considera mudança ou funcionalidade nova? Qual suporte ou manutenção posterior está incluído e o que é contratado separadamente?
4. Qual time vai trabalhar no meu projeto? Quem será o responsável, quais perfis e qual nível de experiência o time terá, e qual capacidade aproximada será alocada?
5. O que acontece se o projeto atrasar? Existem penalidades? Existe comunicação proativa, ou você só fica sabendo quando pergunta?
6. Posso conversar com um cliente anterior que tenha tido um projeto de tamanho e complexidade parecidos com o meu? Se houver restrições de confidencialidade, pergunte se dá para mostrar um caso anonimizado comparável, métricas verificáveis ou outra evidência de experiência relevante — não conseguir compartilhar um contato específico não é automaticamente um sinal ruim.

Se um fornecedor — qualquer um — ficar desconfortável ou evasivo diante dessas perguntas, isso é uma informação tão valiosa quanto a própria proposta.

Preço fixo vs. tempo e materiais

Existem dois modelos principais de contratação, e entender a diferença ajuda você a ler melhor qualquer proposta:

Preço fixo (Fixed Price). Define-se um valor total, um escopo fechado e um cronograma antes de começar. Como orientação geral, funciona melhor quando os requisitos já estão bem definidos e estáveis — isso não é uma regra rígida sobre a duração do projeto. A desvantagem é a menor flexibilidade: uma mudança que amplie ou altere o escopo de forma relevante pode exigir renegociar preço, prazo ou entregáveis. Também é possível combinar uma repriorização mantendo as restrições originais, se as duas partes considerarem as mudanças equivalentes.

Tempo e materiais (T&M). Você paga pelo tempo ou pela capacidade efetivamente utilizada, conforme as tarifas e condições acordadas. O faturamento pode ser por horas, dias, capacidade de time ou outra unidade definida em contrato; qualquer gasto adicional deveria estar previsto. Dá bem mais flexibilidade e cai melhor quando os requisitos ainda estão evoluindo ou não estão totalmente claros. O risco, do lado do cliente, é que sem marcos de revisão periódica o orçamento fica em aberto.

Modelo híbrido. Uma alternativa é começar em T&M na etapa de discovery e especificação — enquanto o escopo ainda está sendo definido — e migrar para preço fixo assim que ele ficar claro. Isso reduz certos riscos para as duas partes, embora a conveniência do modelo e o tempo que vale dedicar a cada etapa dependam do projeto.

Nenhum dos dois modelos é “melhor” no abstrato — o que importa é o modelo escolhido combinar com o quanto os seus requisitos estão definidos hoje.

Os riscos de escolher só pelo preço

O preço mais baixo nem sempre sai mais barato no final. Alguns riscos que vale revisar:

• Corte ou renegociação de escopo. Quando uma proposta fica muito apertada diante do trabalho real, pode ser necessário reduzir, repriorizar ou renegociar entregáveis. Por isso vale comparar com cuidado o que cada orçamento inclui e exclui.
• Custos extras por pedidos de mudança. Quando o escopo inicial não está suficientemente definido, esclarecimentos ou necessidades que surgem durante o projeto podem acabar tratados como mudanças adicionais e elevar o custo final.
• Possível impacto na qualidade e na facilidade de manutenção. Um preço muito apertado pode significar menos tempo dedicado a testes, documentação ou boas práticas de segurança, o que depois pode se traduzir em custos maiores de manutenção.

Esses riscos não aparecem só porque o preço é baixo — mas, se vários desses sinais aparecerem juntos, vale revisar com mais cuidado o escopo, as premissas e as condições antes de decidir.

Como estruturar o pagamento

A estrutura de pagamento deveria acompanhar o modelo de contratação. Num projeto a preço fixo ou por marcos, faz sentido vincular os pagamentos a entregáveis ou etapas verificáveis. Em T&M, o mais comum é um faturamento periódico acompanhado de visibilidade sobre tempo ou capacidade consumida, progresso, orçamento utilizado e revisões regulares. Num modelo híbrido, dá para combinar os dois mecanismos.

Mudanças que alterem preço, prazo, capacidade contratada ou compromissos acordados deveriam seguir o mecanismo de aprovação definido no contrato e ficar documentadas antes de serem executadas.

Antes de assinar

Se você já concluiu que o software sob medida é o caminho certo para a sua empresa — assunto que tratamos em quando uma empresa precisa de software sob medida (e quando não) — e já tem uma noção do que determina o preço no mercado paraguaio, tema que desenvolvemos em quanto custa desenvolver software sob medida no Paraguai, o próximo passo é ler a proposta concreta que está na sua mesa com essa lista em mãos.

Nenhuma proposta vai ter nota máxima em todos esses pontos, e isso não a desqualifica automaticamente. O que importa é o fornecedor conseguir explicar com clareza as partes que faltam e estar disposto a completá-las por escrito antes de você começar a pagar. Se quiser ver como estruturamos nossas propostas de software sob medida, a mesma lista de perguntas deste guia se aplica.