Não é incomum ouvir a frase “pare, precisamos reescrever isso” em algum momento de um projeto. Existem até projetos inteiros dedicados a reescrever um sistema.

Chris Stevenson e Andy Polls contaram sua experiência de Uma abordagem ágil para um sistema legado, onde contaram que

Houve várias iniciativas anteriores para melhorar o sistema. A mais recente foi uma tentativa de reescrever uma parte fundamental do sistema em uma linguagem que conhecíamos (Java), na suposição de que isso aumentaria a compreensão do sistema e o tornaria mais receptivo à refatoração.

Esta estratégia não funcionou.

Logo após esta introdução, eles fornecem suas duas regras práticas mais valiosas:

• Não reproduza código legado.
• Sempre pergunte ao usuário qual é o problema.

Marty Cagan, do SVPG, tem um artigo muito interessante sobre esse tema chamado Engineering Wants to Rewrite!, onde diz que se uma empresa ainda não está na fase “parar, precisamos reescrever”, você pode evitar chegar lá:

… [alocando] uma porcentagem de sua capacidade de engenharia para o que no eBay chamamos de “headroom”. A ideia é evitar bater a cabeça no teto. Você faz isso criando espaço – espaço livre – espaço para crescimento na base de usuários, crescimento nas transações, crescimento na funcionalidade.

No entanto, há momentos em que a reivindicação de reescrita é apenas uma forma de chamar a atenção para um projeto. Um projeto de reescrita normalmente parece ser mais importante do que adicionar funcionalidades incrementais ou consertar uma pequena peça do sistema. No entanto, adicionar um recurso por vez agrega valor ao cliente muito mais rápido do que reescrever o projeto. Para chamar mais atenção ao seu projeto, considere usar o planejamento de lançamento. Falarei mais sobre planejamento de lançamento em um post futuro.

Portanto, minha recomendação é, antes de usar a palavra reescrita, verificar a motivação para usá-la:

• Você atingiu o teto e não consegue adicionar nenhum recurso novo ao seu produto? Considere adicionar o conceito de headroom à sua equipe de desenvolvimento. Se você não atingiu o teto, é uma boa maneira de evitar isso.
• Todas as pessoas que originalmente escreveram o código se separaram? Considere a abordagem ágil de Stevenson e Pols e sua regra prática: “Não reproduza código legado” e “Sempre pergunte aos usuários qual é o problema”.
• Você precisa de mais atenção ao seu produto e surge com um projeto de reescrita? Considere não usar essa abordagem. Em vez disso, pense em lançamentos de produtos que incluam correções de bugs, melhorias e novas funcionalidades.

Um projeto de reescrita geralmente implica um período sem novos recursos e algumas situações de desculpas pela inconveniência durante o projeto. Portanto, sempre que lhe for apresentado um projeto de reescrita, analise seu impacto no valor do cliente. Se não houver impacto no valor do cliente, provavelmente a reescrita não será a melhor solução.

Treinamento e consultoria em gestão de produtos e transformação digital

Ajudo líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders, heads de transformação digital) a enfrentarem seus desafios e oportunidades de produtos digitais por meio de treinamentos e consultoria em gestão de produtos e transformação digital.

Gestão de produtos digitais

Você trabalha com produtos digitais? Quer saber mais sobre como gerenciar um produto digital para aumentar suas chances de sucesso, resolver os problemas do usuário e atingir os objetivos da empresa? Confira meu pacote de gerenciamento de produto digital com meus 4 livros, onde compartilho o que aprendi durante meus mais de 30 anos de experiência na criação e gerenciamento de produtos digitais. Se preferir, pode comprar os livros individualmente:

• Transformação digital e cultura de produto: Como colocar a tecnologia no centro da estratégia de sua empresa
• Liderança de produtos digitais: A ciência e a arte da gestão de times de produto.
• Gestão de produtos: Como aumentar as chances de sucesso do seu software.
• Guia da Startup: Como startups e empresas estabelecidas podem criar produtos de software rentáveis.