Como provocar um roadmap de estabilização? - Parte 1

Se relacionando melhor com conceitos e contextos técnicos para potencializar relacionamento com time e identificar soluções.

Como provocar um roadmap de estabilização? - Parte 1
Photo by Sylwia Bartyzel / Unsplash

Atenção! As informações deste artigo são para que nós produteiros provoquemos mudanças que vão nos afetar positivamente no roadmap de negócios, EM MOMENTO ALGUM A IDEIA é que você desenvolva habilidades técnicas.

Chega um determinado momento do desenvolvimento de um software que precisamos parar e avaliar o que já temos implantado, será que já temos um software estável? Estamos produzindo crises em produção? Estamos usando os padrões mais recentes do mercado? Deixamos débitos técnicos que podem colocar os serviços em perigo? Estamos vulneráveis a ciberataques? As perguntas são infinitas e podem ser resumidas em um único tema: roadmap de estabilização.

Este tipo de roadmap é majoritariamente técnico e fogem bastante da nossa alçada de conhecimento, que, geralmente, é de negócios e mercados.

Já mencionei em diversos outros artigos, aqui mesmo na Product Oversee o quanto é importante a relação de confiança entre Produtos e TI, e sim, já ajuda muito quando temos essa boa relação entre os membros do time para que as pessoas que desenvolvem proativamente nos deem insumos do que está errado, ou poderia ser melhor no código. Entretanto, nem sempre isso é possível, e é aí que nós de produtos pelo menos temos que saber que certas ferramentas existem — ênfase no “existem” - em momento algum nós devemos operar essas ferramentas para levantar backlogs nós mesmos.

Esse conceito é estranho para a maioria dos produteiros, mas chama-se “Spike”.

Origem do Spike e por que você deveria ser fã dele