Quase todos os fundadores com um MVP avariado perguntam se devem reescrevê-lo. Quase sempre a resposta é não — e a razão é aritmética, não sentimento.
Um MVP avariado apresenta-se normalmente de três formas: cai sob utilização real, cada alteração parte outra coisa, ou os programadores originais saíram e ninguém o percebe. O instinto é recomeçar. Esse instinto é caro e normalmente errado.
Porque a reescrita é uma armadilha
A reescrita parece atraente porque o sistema novo é imaginário, e sistemas imaginários não têm bugs. Na realidade:
- O código existente codifica anos de casos limite que ninguém documentou — serão redescobertos como incidentes em produção
- Congela o desenvolvimento de funcionalidades durante meses enquanto os concorrentes não o fazem
- A reescrita bate na mesma complexidade, porque a complexidade está no domínio e não no código
- As estimativas de reescrita erram por larga margem, consistentemente, em todas as organizações
Passo 1: estancar a hemorragia
Antes de melhorar seja o que for, torne o sistema observável e recuperável. Não se corrige o que não se vê, nem se experimenta sem caminho de volta.
- Rastreio de erros, para que as falhas sejam conhecidas em vez de reportadas por clientes
- Monitorização de disponibilidade e das transações-chave — pagamento, registo, compra
- Um rollback que funciona e foi testado
- Backups, e um restauro que tenha sido efetivamente executado pelo menos uma vez
Passo 2: triar, não inventariar
Resista à vontade de listar tudo o que está mal. Ordene os problemas por consequência:
| Categoria | Definição | Ação |
|---|---|---|
| Hemorrágico | Perde dinheiro, dados ou clientes neste momento | Corrigir esta semana |
| Bloqueante | Impede entregar o roadmap do trimestre | Corrigir este trimestre |
| Cumulativo | Torna cada alteração mais lenta | Planear deliberadamente |
| Cosmético | Ofende o gosto, não custa nada | Nunca |
A maioria dos resgates encontra dois ou três itens na primeira categoria e uma mão-cheia na segunda. É um programa de trabalho gerível — bem diferente da impressão esmagadora que a equipa tinha antes de ordenar as coisas.
Passo 3: corrigir pela ordem que se acumula
- Integridade dos dados primeiro — dados corrompidos ou perdidos são irrecuperáveis de uma forma que a indisponibilidade não é
- Depois o caminho de deploy — enquanto lançar não for seguro e frequente, qualquer outra correção sai devagar e com risco
- Depois a principal fonte de falhas — normalmente um ou dois endpoints ou consultas causam a maioria dos incidentes
- Depois o bloqueador de mudança — o acoplamento ou a falta de testes que faz a equipa ter medo de mexer
- Só então desempenho e acabamento
Passo 4: prevenir a recaída
- Testes nos caminhos que doem — dinheiro, autenticação e exatamente aquilo que partiu
- Um registo escrito de decisões, para que o próximo engenheiro herde raciocínio e não apenas código
- Um processo de deploy que qualquer pessoa da equipa consiga executar
- Uma regra explícita de que o roadmap inclui capacidade de manutenção — caso contrário a dívida regressa
Um resgate não é uma limpeza. É um pequeno número de alterações dirigidas que levam o sistema de inseguro a aborrecido — e é o aborrecido que permite a uma equipa voltar a entregar.
Definir a reparação antes de reescrever
Demonstre que um percurso falhado pode ser estabilizado. Use o resultado para estimar o próximo passo e comparar substituição.
- Criar um teste de regressão da falha observada.
- Reparar uma área delimitada e verificar comportamentos adjacentes.
- Comparar reparação e substituição com migração e operação paralela.
Perguntas frequentes
Devemos reescrever o nosso MVP ou consertá-lo?
Consertá-lo, a menos que a plataforma seja insustentável, o produto tenha mudado fundamentalmente, ou todo o sistema possa ser reconstruído em poucas semanas. As reescritas congelam o trabalho de produto durante meses, redescobrem casos limite esquecidos como incidentes em produção e ultrapassam consistentemente as estimativas.
Quanto tempo demora um resgate de MVP?
A triagem demora dias. Estabilizar os problemas críticos leva tipicamente duas a seis semanas consoante a gravidade. A remediação completa da dívida cumulativa leva um trimestre ou mais — mas acontece em paralelo com o trabalho de produto, não em vez dele.
Os nossos programadores originais saíram. O código ainda é recuperável?
Quase sempre. Perder os autores torna o trabalho mais lento, não impossível: a primeira tarefa é reconstruir como o sistema se comporta de facto — através de leitura, instrumentação e testes de caracterização — antes de mudar seja o que for.
Como sabemos se o nosso MVP está mesmo avariado ou apenas imperfeito?
Pergunte se perde dinheiro ou dados, se impede entregar o roadmap, e se a equipa tem medo de fazer deploy. Se nada disso for verdade, tem um MVP imperfeito — o que é normal e não justifica uma intervenção.
Quando suspender novas funcionalidades?
Quando as mudanças impedem o diagnóstico ou aumentam riscos materiais nos dados e disponibilidade. Defina âmbito da pausa e condições de retoma.
MVP em apuros?
Triamos em dias e dizemos honestamente se precisa de um resgate, de uma reescrita, ou de nada.
Leitura complementar
Auditoria técnica de MVP: o que verificamos nas primeiras 48 horas
A maioria das auditorias de MVP produz um documento. Uma útil produz decisões: o que está a arder, o que pode esperar e quanto custa corrigir.
Dívida técnica em startups: quanta é demasiada?
Todas as startups têm dívida técnica, e a maior parte foi a decisão certa. A pergunta não é como eliminá-la — é que partes cobram juros que já não consegue pagar.