Aqui a solução é simples, pelo menos em teoria. Produto atual é produto atual, novas oportunidades são novas oportunidades. Cada um tem que ser tratada de um jeito. O ideal é que sejam tratadas até mesmo por times diferentes. Só que nem sempre isso é possível. Nesses casos, se quisermos perseguir novas oportunidades, esse time tem que saber separar claramente o trabalho no produto existente vs o trabalho nas novas oportunidades. Por exemplo, 2 semanas para o produto existente, uma para a nova oportunidade, até que se justifique a criação de um novo time para a nova oportunidade.
Atenção: não é time de bugs
Esse é um ponto importante. A ideia não é separar os times para ter um time fazendo coisas novas e outro corrigindo bugs do produto existente. Isso não funciona, pois vai criar uma separação muito grande entre os dois times. Quem faz coisas novas vai eventualmente acreditar que pode fazer qualquer coisa sem se preocupar tanto com qualidade já que existe um time focado em correção de bugs. Do outro lado, o “time de bugs” vai achar que está fazendo trabalho de faxineiro, limpando as bagunças que outras pessoas fazem.
Oportunidades vs melhorias
Antes de investir em uma nova oportunidade é muito importante entender porque está se investindo nessa nova oportunidade. Uma ótima ferramenta para isso é a análise de oportunidades. Sem um claro entendimento e correto engajamento de todos os envolvidos pode-se colocar a oportunidade a perder sem nem mesmo começar a explorá-la.
Um ponto importante que todos os envolvidos devem entender é que uma nova oportunidade é uma nova oportunidade, ou seja, ela deverá gerar resultados que se somam aos atuais. Esses resultados deveriam ser suficientes para justificar a criação de um novo time para perseguir essa nova oportunidade. No mínimo, dois engenheiros de software. Idealmente, além dos dois engenheiros, seria bom ter um gestor de produtos, um designer de UX e uma pessoa de marketing de produtos dedicadas a essa nova oportunidade. Essa nova oportunidade irá ser um novo produto ou uma nova funcionalidade. Quando esse novo produto ou nova funcionalidade estiver pronto e lançado, quem trabalhou no seu desenvolvimento irá cuidar de seus bugs e melhorias.
Enquanto isso, o outro time cuida do produto atual, ou seja, de melhorar o produto atual para que ele continue atingindo seus objetivos. Melhorar o produto atual significa sim corrigir bug, mas significa também fazer coisas novas no produto existente. Melhorias para tornar o produto melhor, mais útil e mais usável.
Caso não seja possível criar um novo time, pode-se fazer compartilhamento do tempo do mesmo time. Algo como uma ou duas semanas para bugs e melhorias do produto atual e uma semana para a nova oportunidade, até que se justifique a criação de um novo time para a nova oportunidade.
Como saber se é uma melhoria ou uma nova oportunidade?
É responsabilidade do gestor de produtos, junto com o time, entender se esse algo novo que surgiu para ser feito é uma oportunidade ou uma melhoria. Mas como discernir entre melhoria e oportunidade? Especialmente quando o algo novo a fazer for uma nova funcionalidade do produto existente, devemos encarar como nova oportunidade ou melhoria do produto existente?
Depende do esforço e do retorno envolvidos. Uma nova oportunidade deve ter um retorno alto para fazer sentido persegui-la. Lembre-se que uma nova oportunidade vai eventualmente ter um time só para cuidar dela, então é preciso que o retorno seja suficiente para justificar esse novo time. Se o retorno for incerto, é melhor não tirar energia do produto existente para perseguir essa nova oportunidade. Por outro lado, se houver a perspectiva de um bom retorno, qual o esforço de criar algo para explorar essa oportunidade? E qual será o esforço para manter esse algo? Essas duas perguntas devem orientar a forma de encarar. Se o esforço for baixo, esse algo novo pode ser tratado como uma melhoria e ser desenvolvido pelo time atual. Se o esforço é alto, é recomendável tratá-lo como nova oportunidade e considerar ter um time separado para fazer o desenvolvimento.