Quase nenhum projeto fracassa por causa de uma grande mudança. Os projetos fracassam por causa de trinta pequenas mudanças, cada uma razoável por si só, mas nenhuma delas incluída no orçamento.
Esclarecimento ou mudança
A distinção é importante e, em geral, pode ser determinada.
Um esclarecimento resolve uma ambiguidade em algo já acordado. A especificação diz que os usuários podem redefinir a senha; o cliente confirma que o link de redefinição deve expirar após uma hora. Isso já seria implementado de qualquer forma; apenas se definiu um detalhe.
Uma mudança acrescenta, remove ou altera o escopo acordado. A especificação diz que os usuários redefinem a senha por e-mail; agora o cliente também quer SMS. Isso é trabalho novo.
A zona cinzenta surge quando a especificação não diz nada sobre o assunto. Se a especificação não indicava por quanto tempo o link seria válido, alguém precisava decidir, e essa decisão é um esclarecimento. Se a especificação não mencionava SMS, acrescentá-lo é uma mudança. Uma regra útil: se um desenvolvedor razoável, ao ler a especificação, teria implementado o recurso de qualquer maneira, trata-se de um esclarecimento.
Por que pequenas mudanças custam mais do que seu tamanho sugere
Uma mudança que leva duas horas para ser codificada raramente custa apenas duas horas. Ela também envolve:
- Discussão e especificação da própria mudança.
- Efeitos sobre o que já foi desenvolvido — um novo campo aparece em um formulário, na validação, no banco de dados, nos relatórios e nas exportações.
- Novos testes de tudo o que a mudança afeta.
- Atualização da documentação e de qualquer projeto já aprovado.
- O custo da interrupção, que é real e raramente entra no orçamento.
É por isso que uma mudança solicitada durante a fase de projeto custa uma fração do custo da mesma mudança solicitada após os testes de aceitação. O multiplicador entre esses dois momentos é alto — costuma-se dizer que é da ordem de uma magnitude, e essa relação não é contestada, ainda que o valor exato não seja.
Explicar isso ao cliente desde o início facilita muito as conversas posteriores, porque ele entende por que precisa pensar com cuidado na fase de projeto.
Um processo de mudanças simples o bastante para ser usado de verdade
Para um projeto pequeno, quatro etapas:
- O pedido é registrado por escrito. Um parágrafo, em um único lugar ao qual ambas as partes tenham acesso. Mudanças verbais são a origem da maioria das disputas.
- O desenvolvedor faz uma estimativa — esforço, custo e impacto na data de entrega. O impacto na data é tão importante quanto o custo e costuma ser esquecido.
- O cliente aprova ou recusa por escrito. Recusar é um resultado legítimo e deve ser simples.
- As mudanças aprovadas são adicionadas ao cronograma e à fatura, e a data de entrega é oficialmente ajustada, caso tenha mudado.
A etapa que mais costuma ser ignorada é a terceira, e ignorá-la é o que gera a discussão no final: foi feito um trabalho que ninguém concordou formalmente em pagar.
Como lidar com as pequenas mudanças
Formalizar um pedido de mudança para um ajuste de quinze minutos custa mais em processo do que em trabalho, e isso torna o projeto conflituoso. Duas abordagens viáveis:
Uma reserva para mudanças. Inclua no contrato um número definido de horas para pequenos ajustes, com registro e prestação de contas. Quando as horas se esgotarem, as mudanças adicionais serão orçadas. Isso é transparente e elimina o atrito em pedidos realmente pequenos.
Agrupamento. Reúna pequenas mudanças e faça um orçamento conjunto em momentos definidos. Há menos interrupções, e o cliente vê o custo acumulado — o que muitas vezes o ajuda a definir prioridades.
Mudanças às quais o cliente deve se opor
Nem todo pedido de mudança parte do cliente. Se um desenvolvedor propõe uma mudança porque algo na especificação acordada acaba sendo mais difícil do que o esperado, em geral isso não é uma mudança — é um erro de estimativa, e o risco da estimativa normalmente cabe a quem a elaborou.
A exceção é quando a especificação era realmente ambígua e a interpretação do cliente é a mais cara. Isso é uma mudança real, e é por isso que o esforço de especificação no início se paga.
Manter o registro
Uma única lista, visível para ambas as partes, com todas as mudanças, seu status, custo e impacto na data. Ao final do projeto, essa lista explica exatamente por que a fatura final difere do orçamento inicial — e um projeto capaz de explicar essa diferença raramente termina em uma disputa.
Serviços Manboo relacionados
- Desenvolvimento de aplicativos Flutter para MVPs de iOS e Android.
- Desenvolvimento de software empresarial para sistemas de CRM, reservas, estoque e fluxos de trabalho.
- Desenvolvimento de painéis administrativos para painéis de operações e gerenciamento de back-end.
- Integração de API de IA quando seu produto estiver pronto para busca inteligente, chat ou automação.
- Solicite uma análise de escopo e uma estimativa do projeto quando estiver pronto para planejar a primeira versão.