Três desenvolvedores que apresentam orçamentos de 40,000, 90,000 e 250,000 para o mesmo briefing geralmente não estão discordando sobre suas tarifas. Eles estão orçando três produtos diferentes, porque o briefing permitia três interpretações.
Por que essa diferença acontece
Um briefing que diz "os usuários podem fazer upload de documentos" deixa em aberto todas as decisões dispendiosas. Qual é o tamanho máximo? Quais formatos? Haverá verificação de vírus? A visualização será no navegador ou apenas por download? Haverá versionamento? Quem pode ver os arquivos de quem? Qual será a retenção e a exclusão?
Um desenvolvedor que faz um orçamento cauteloso presume a interpretação simples. Quem faz um orçamento defensivo presume a complexa e inclui esse custo. Ambos estão agindo de forma razoável. O comprador conclui que o mais caro está cobrando acima do justo, escolhe o mais barato e descobre a diferença durante o desenvolvimento, momento em que ela se torna uma solicitação de mudança.
As cinco coisas que precisam ser definidas
- Os papéis dos usuários e o que cada um pode fazer. Não apenas "administrador e usuário", mas uma lista de ações por papel. A lógica de permissões representa uma parcela significativa do trabalho na maioria das aplicações empresariais e fica invisível em uma lista de funcionalidades.
- Os principais fluxos de trabalho, passo a passo. Escreva a sequência pela qual um usuário realmente passa, incluindo o que acontece quando algo dá errado, como um pagamento recusado, uma sessão expirada ou um envio duplicado.
- Os dados. O que é armazenado, o que é obrigatório, quais validações se aplicam e por quanto tempo é mantido. Uma lista de campos é mais útil do que uma descrição de tela, porque as telas mudam e os dados não.
- As dependências externas. Pagamentos, mensagens, mapas e sistemas existentes aos quais será necessário conectar-se. Cada uma envolve tempo de aprovação e tratamento de falhas, que precisam ser incluídos no orçamento.
- Os critérios de aceitação. Como você decidirá que o produto está concluído. Esta é a seção mais frequentemente omitida e a que evita a maior parte das discussões.
Volume e desempenho expressos em números
"Deve ser rápido" e "deve atender muitos usuários" não podem ser orçados nem testados. Números podem:
- Indicar os usuários esperados no primeiro ano e os usuários simultâneos no pico.
- Indicar a quantidade de registros esperada na maior tabela após um ano.
- Definir o tempo de resposta aceitável para a operação comum mais lenta.
- Definir os tamanhos dos arquivos e o armazenamento total.
Esses fatores mudam a arquitetura. Uma aplicação projetada para 200 usuários e outra projetada para 200,000 diferem no design do banco de dados, no cache e no custo de hospedagem; construir a segunda quando você precisa da primeira desperdiça dinheiro que poderia ser investido em funcionalidades.
O que uma especificação não deve conter
Duas coisas que tornam as especificações piores:
Escolhas tecnológicas, a menos que exista uma restrição real. Especificar um framework porque ele foi recomendado elimina a possibilidade de o desenvolvedor propor algo mais adequado. Se houver uma restrição genuína, como um sistema existente ou uma equipe interna que precise fazer a manutenção, declare a restrição em vez da conclusão.
Design em nível de pixel em uma especificação funcional. É melhor separar design e função. Uma especificação que mistura os dois torna ambos mais difíceis de revisar e transforma cada preferência visual em uma mudança funcional.
As seções que causam discussões posteriormente
De forma consistente, nesta ordem:
- Relatórios. "Relatórios" em um briefing se transforma em uma semana de trabalho por relatório quando os campos, filtros, agrupamentos e o formato de exportação são conhecidos.
- Notificações. E-mail, SMS, push e notificações no aplicativo são quatro implementações diferentes, com quatro custos diferentes. "O sistema notifica o usuário" não especifica nenhuma delas.
- Pesquisa. Pesquisar um único campo é trivial; pesquisar em registros relacionados com classificação de relevância é um projeto por si só.
- Migração. Importar dados existentes quase sempre é mais difícil do que o esperado, porque os dados antigos são inconsistentes de maneiras que ninguém documentou.
Nomear explicitamente esses quatro itens na especificação, mesmo que brevemente, faz com que deixem de ser suposições e passem a fazer parte do escopo.
Uma abordagem prática
Uma especificação útil para um projeto pequeno geralmente tem de cinco a quinze páginas: lista de papéis, descrições dos fluxos de trabalho, campos de dados, lista de integrações, métricas não funcionais quantificadas, critérios de aceitação e uma seção explícita de itens fora do escopo.
Essa última seção produz um efeito maior do que seu tamanho sugere. Escrever "relatórios além das três telas listadas estão fora do escopo desta fase" custa uma linha e elimina toda uma categoria de divergências posteriores.
Serviços relacionados da Manboo
- Desenvolvimento de aplicativos Flutter para MVPs de iOS e Android.
- Desenvolvimento de software empresarial para sistemas de CRM, reservas, inventário e fluxos de trabalho.
- Desenvolvimento de painéis administrativos para painéis operacionais e gerenciamento de back-end.
- Integração de APIs de IA quando seu produto estiver pronto para pesquisa inteligente, chat ou automação.
- Solicite uma revisão do escopo e uma estimativa do projeto quando estiver pronto para planejar a primeira versão.