A data chega e a pressão aumenta, como escolher onde a energia deve ser investida?
Sejam projetos, produtos ou programas, uma verdade é que sempre vão existir datas e precisamos entender como trabalhar previsões de entrega. A data não deve ser percebida como um problema, é preciso saber compreendê-la e montar planos reais para alcançá-la. Um dos caminhos é responder às seguintes perguntas: quais são as funcionalidades que mais trazem valor para a empresa e a pessoa usuária final? Como trabalhar primeiro no que tem mais valor?
No mesmo contexto de trabalho que contei em Como três equipes distintas podem trabalhar em conjunto para um mesmo objetivos?, quanto mais perto da data do principal lançamento, mais coisas foram aparecendo, grande parte delas tem com alto nível de urgência e valor para quem as solicitava. Faltando um mês para o prazo, mitigamos este problema quando começamos a fazer um estudo semanal sobre a lista de pendências que deveríamos focar. Estavam presentes as gerentes de produto, analistas de negócio, gerentes de projeto e líderes técnicas. Escolhemos não envolver toda a equipe, pois o momento era de foco total na entrega e a equipe estava na fase de maturidade de atuação, quando as decisões tomadas por parte da equipe reflete o mesmo que as demais acreditam (leia mais sobre o Modelo de Tuckman).
Essas sessões aconteceram com todas em frente a um quadro com os seguintes pontos:
- Estado: para fazer, fazendo, pronto.
- Impacto em qual parte: Aqui listamos se era em front-end, back-end ou em ambos.
- Qual a necessidade da funcionalidade proposta: Qual o problema que estamos tentando resolver.
- Planejamento de resposta: O que vamos fazer para resolver o problema. Com histórico de decisões e atualizações, listados por datas.
- Responsáveis: os nomes das pessoas que estão buscando as respostas;
- Necessidade: Nota de 0 a 10 qual a necessidade de ter este problema resolvido;
- Severidade: Nota de 0 a 10 quão crítico é caso isso não esteja resolvido;
- Pontuação: Um cálculo sobre a média de necessidade e severidade para identificar a priorização deste item, considerando que severidade tem peso de 120%.
- Go / No Go: Se a funcionalidade/problema em questão pode ser um no go para a data que temos. Ou seja, é essencial seu desenvolvimento.
Para cada item adicionado, fizemos a avaliação em conjunto, ouvindo todas pessoas da sala e comparando com os itens anteriores. Sempre que necessidade e severidade são pontuados, buscamos um outro item da lista para entender se eles tem o mesmo nível. Por exemplo:
Na tabela acima validamos duas funcionalidades que chegaram como urgentes.
O item um precisava atualizar a ordem de exibição da listagem de produtos, pois o que trazíamos na primeira entrega era diferente do que a usuária estava acostumada. É muito necessário para a cliente (nota nove) e a severidade é alta (nota oito) pois a pessoa usuária pode se sentir perdida caso não encontre as opções rapidamente.
O item dois define que precisamos exibir a página em outros idiomas, para garantir que a venda em outros países siga funcionando. A necessidade é dez, porque o produto vai ser lançado para vários países ao mesmo tempo. E a severidade é dez, não é possível que o lançamento geral seja feito se a pessoa usuária não puder ler o conteúdo em seu idioma. Isso também define que este item é um no go.
Ao comparar um item com o outro definimos que o primeiro item não seria um no go, pois a pessoa usuária ainda vai ter as informações em lista, podendo buscá-las com um pouco mais de trabalho, mas não impossibilitando a venda. Ter a página aberta para o México, por exemplo, e o conteúdo todo em chinês, é um no go pois as pessoas usuárias não iam entender o conteúdo exibido sem tradução.
Assim decidimos que, entre os dois itens muito necessários para a cliente, iremos trabalhar primeiro no item dois que tinha pontuação 10. E assim que possível o item um, cuja pontuação está em 9.4.
Este formato facilita que as conversas sejam focadas nos pontos que precisamos resolver e a priorização feita de acordo com uma visão geral das próximas funcionalidades, não apenas na emoção e argumentação de quem as solicita.
Quais os ganhos que percebemos ao aplicar esta prática?
As ações descritas aqui nos ajudaram a aproximar as três equipes, colocar todas numa mesma página e aproximar as gerentes de produto. Um dos principais ganhos que tivemos foi parar de tomar decisões em separado e começar a olhar todas juntas para a mesma direção. Isto nos trouxe força, foco e resultado. Conseguimos melhorar as métricas de entrega das equipes, ter retorno da usuária final de forma mais rápida, transacionar pessoas desenvolvedoras entre as equipes, conseguindo apoiar a frente que estivesse com maior demanda no momento, sem precisar aumentar o tamanho das equipes.
As duas práticas (trabalhando três times em um programa e o processo de priorização) exigem dedicação e disciplina. É preciso manter as sessões ocorrendo frequentemente para que os itens sejam revisados e sigam o caminho previsto. Nenhuma prática dura para sempre, então é importante manter retrospectivas e entender até que ponto este acompanhamento em detalhe ainda é essencial para o momento das equipes.
