Bug's: Como eles podem prejudicar a estratégia do seu produto?

Todas as empresas em que eu entrei, e tínhamos um produto legado, ou mesmo algum produto novo, já no ar. Uma das minhas primeiras "quick wins" foi estruturar esse processo, o de sustentação do produto.

Vocês devem estar se perguntando o porque, não é mesmo?

Vou explicar, aqui: Quando você entra na área de produto, uma das primeiras coisas que você tem que organizar é o processo de sustentação do seu produto, se não esse tipo de demanda faz com que seu squad ou tribe, perca o foco dos objetivos de negócio e com isso deixe de entregar valor, apenas focando nesse tipo de demanda, de suporte, de correção. E não, de evolução do produto.

Eu já vi vários casos, onde o time tinha mais de 150k de usuários ativos, sendo 3 tipos de personas diferentes, e mesmo assim o time parava para atender 1 usuário, que estava com um bug específico da máquina dele, que não impedia a pessoa de trabalhar, nem parece verdade, não é mesmo?!

PS: eu demorei quase 3 quartes para ter um bom processo. Sim! Estou falando de quase 1 ano, e ainda assim, sempre rodando o PDCA para melhorar o processo.

Na maior parte das empresas que passei, já tinham produtos rodando, não é o caso de você entrar, e colocar um MVP na rua, para depois entender como lidar com o suporte do produto.

Eu costumo brincar que você, enquanto produto, tem que consertar o avião com ele voando, rs. Não falo sobre ser um super herói/heroína. Mas entender de forma sistêmica como lidar com os problemas e como um problema "X" impacta no resultado do todo.

No contexto de fusão de 2 empresas, como é o caso aqui da Minuto Seguros com a Creditas, isso não seria diferente, não é mesmo?

Dado esse contexto vou contar um pouco da minha experiência com a estruturação desse processo aqui na Business Unity de Insurance na Creditas.

Quando eu entrei, na Creditas, nós tínhamos apenas 1 squad, com 1 APM, que era uma pessoa mega parceira e conhecia do negócio, e precisávamos começar a estruturar o processo de sustentação, tínhamos grandes produtos legados que demandavam atenção do time para suporte.

Então, começamos a separa o board no Service Desk para isso. E criar a cultura com os stakeholders que, nem todos os bug's seriam resolvidos de imediato. Também precisávamos explicar como seriam dadas as prioridades e então como lidaríamos com esse processo, criamos documentações e apresentações para alinhar as expectativas com todos.

Em time, estabelecemos alguns acordos e estratégias para lidar com o alto volume de chamados, eram em média 15 chamados por dia, 90 chamados por semana, e no final do mês tínhamos atendido quase 300 chamados de bug's e ainda assim, ficavam quase 60 bug's por mês em aberto, e todo mês tínhamos mais bug's e a cada fechamento de mês ainda tinham alguns em aberto, o que fazia com que nosso board de sustentação nunca ficasse limpo. E, pelo contrário, acumulávamos tícket's de um mês para o outro, virando uma bola de neve.

E sabe o que era ainda pior?

O time não entregava o planejado do mês, e estávamos cada vez mais distante dos nossos objetivos do trimestre.

Depois destes primeiros passos, para estruturamos o processo, começamos a analisar os tíckets que chegavam do ponto de vista de volume x assuntos recorrentes e notamos que muitos deles era por, o usuário, não saber usar o produto. E outros, conseguimos clusterizar por necessidades de usuário ou negócio. O que abriram 2 planos de ação:

1 — Como faríamos para educar o usuário sobre o produto e como faríamos para deixar ele mais usual? Treinamento, Base de Conhecimento e Melhorias de design.

2 — O que faríamos com os tícket's com necessidades em comum?

E dado o cenário, no início começamos a fazer reuniões semanais para falar sobre o primeiro ponto e o que concluímos foi:

• Precisamos de um Confluence em que o usuário consiga acessar e consultar a base de conhecimento, onde o time de treinamentos construiu;
• Teríamos um time de suporte N1, para nos apoiarmos e filtrar os tíckets, para deixar apenas o que realmente eram bug's;
• Quick Win's de Design, para melhorar a usabilidade, afim do usuário se encontrar no produto;

E no segundo plano de ação, o que pudemos observar é que todo o permissionamento do produto estava obsoleto e algumas outras features demandavam evolução, diante das alterações de processos nos times, e mudanças na aquisição da minuto seguros, com os times da Creditas, com isso começamos a colocar no backlog para atacar como "quick wins" de acordo com os nossos objetivos também, e sempre negociando e comunicando com os stakeholders, no começo funcionou. Mas depois ainda formamos mais um squad, que hoje não é o que atuo, para atacar problemas mais profundos ainda e evoluções maiores.

E sabe qual foi o resultado disso tudo?

Desse momento em diante, o time começou a focar nos objetivos estabelecidos nos trimestre, e então começar a entregar valor para o negócio.

Com isso naturalmente, voltou para a estratégia de produto, que tinha sido estabelecida e também olhar as métricas que estavam sendo impactadas (KPI's e KR's).

Conclusão: Se você não tem um processo de sustentação e resolução de bug's bem estruturados, você precisa olhar para isso. Pois, isso vai afetar a sua estratégia de produto, em breve. E, tirar o foco do seu time do que importa, que é: Entrega de valor, resolução de problemas e evolução do produto.