Mapeando Riscos e Dependências de forma Ágil: como proteger seu roadmap da estagnação.
O grande terror de todo agilista é aquele roadmap que não anda. Seja um produto, um projeto, um serviço, uma iniciativa… o time trabalhando, os dias passando, tarefas indo para “done” e nada de valor é entregue. #ohorror
Já encontramos cenários bem intensos, dezenas de times trabalhando no mesmo produto, e sprint após sprint nenhuma funcionalidade saía, nada que o usuário pudesse usar, nada que pudesse ser lançado ao mercado.
A produtividade dos times era extremamente variável, mas mesmo para os times que produziam bem, a ideia de “produto funcionando na mão do cliente” ainda era um sonho distante.
Para lidar com situações como esta e tantas outras onde não podemos nos dar ao luxo de ficar parados, combinamos três dinâmicas, que têm como objetivo ajudar seu time a ganhar tração rapidamente.
1- Tanque de Decantação
Já falamos bastante do Tanque, criado pelo Danilo Risada. Neste cenário, começar com o Tanque é crucial porque a maioria dos times tem uma dificuldade grande em tangibilizar sua estratégia e conectar com um plano tático. Muitos times se vêem executando tarefas “porque alguém mandou”, que é uma postura extremamente prejudicial para a busca por resultados na organização.
Para rodar o passo a passo do tanque, veja aqui.
Ao final desta dinâmica: você terá clareza do propósito do time, dos problemas de negócio (foco no cliente) que eles devem resolver, das métricas de sucesso para a resolução destes problemas e das ideias que provavelmente vão compor seu backlog.
2- Matriz de hipóteses
Um dos maiores riscos para a organização e para o seu roadmap é justamente não correr riscos, parafraseando Mark Zuckerberg. Acreditamos que aquela ideia brilhante vai funcionar no mercado, e é só uma questão de executá-la. Isso não poderia estar mais distante da verdade. A maioria das startups falha, e a maior parte do software construído não é usado ou é usado raramente porque pensamos desta forma.
Para evitar este cenário, antes de fazer uma planilha de riscos baseada em um grande toró de palpite, criamos uma ferramenta para resolver essa questão. Ela é baseada no material do Marty Cagan sobre gestão de produto, no livro Four Steps to the Epiphany (Steve Blank), no Lean Startup (Eric Ries) e na validação de hipóteses do Test Card, do Strategyzer.
Para rodar a Matriz de hipóteses, você vai precisar de:
a. 1 folha grande (a2 ou flipchart)
b. post-its
c. sharpies ou semelhantes
d. seu time e stakeholders
e. o Tanque de Decantação feito.
Antes de começar: Esta matriz não é uma prova na qual o time tem que gabaritar. Há times que rodam essa dinâmica e começam a responder as perguntas da matriz com “sim” antes mesmo de entender o objetivo da atividade. Isso denota uma disfunção cultural de um ambiente error safe, ou seja, à prova de falhas, onde as pessoas não têm ambiente seguro para errar. O que devemos buscar é um ambiente safe to error, onde as pessoas podem errar rápido, aprender rápido para então chegar mais rapidamente ao sucesso.
O problema existe?
Peça para o time escolher uma ideia que eles priorizaram no tanque e desenhar uma cruz na folha, dividindo-a em quatro partes. Na primeira parte, peça que eles escrevam “o problema existe?”
Oriente o time a identificar o problema conectado àquela ideia, e debater sobre quais são as métricas que possuímos que nos fazem afirmar que o problema existe. Lembre ao time que, sem métricas, eles não têm uma certeza, e sim uma suposição. Neste caso, devem ser identificadas ações para conseguir os indicadores que comprovam a existência do problema.
O time deve preencher o problema e 1-3 métricas que comprovam (ou comprovariam) com sucesso que aquele problema é real e suficientemente doloroso para ser resolvido.
Você pode fazer ciclos de 3 minutos usando 1-2-all (como sugerido pelo Liberating Structures):
ciclo 1: cada pessoa pensa individualmente em uma métrica (preferencialmente do ponto de vista do cliente) que comprova que aquele problema existe.
ciclo 2: em pares, discutem e iteram as métricas.
ciclo 3: o grupo traz as sugestões e escolhe as métricas finais.
Exemplo:
O problema existe?
Hipótese de problema: o pagamento via boleto é pouco prático e gera esquecimento.
Como vamos saber: de uma base de 200 mil clientes, temos uma inadimplência de 8% no momento do vencimento. Dos 16 mil clientes que ficam inadimplentes na data de vencimento, metade (8 mil) paga nos 20 dias seguintes após o vencimento.
Saberemos que o boleto é o problema se ao menos 25% de uma amostragem de 200 clientes mencionar esquecimento do boleto, da data de vencimento ou qualquer outra questão relacionada a este processo como motivo para a inadimplência.
ATENÇÃO: “X”% ou “N” clientes não é uma métrica que comprova absolutamente nada. Se o time colocar algo assim, provoque para que eles tenham um número, mesmo que não estejam completamente certos dele. Provoque que eles busquem saber o número correto com outras áreas da empresa e validem o que eles acreditam ser verdade. Isso vai gerar um conhecimento sobre o produto ou serviço que está sob a responsabilidade deles que não tinham até então.
A solução resolve o problema?
Peça para o time colocar a solução que eles pensaram durante o Tanque. Agora o mesmo processo de 1-2-all vai acontecer para encontrar métricas que comprovam que essa solução resolve o problema. Talvez a métrica do problema seja suficiente para esta comprovação, mas provoque-os a pensar em ciclos mais curtos.
Exemplo:
A solução resolve o problema?
Hipótese de solução: disponibilizar uma notificação que informa a data de vencimento próxima e o código de barras.
Como vamos saber: enviaremos alguma forma de notificação (SMS por exemplo) para clientes que costumam ficar inadimplentes, lembrando do vencimento e com o código de barras. Estaremos certos se a inadimplência diminuir em ao menos 10% dentre os clientes testados.
ATENÇÃO: neste cenário, a tendência do time é pensar na solução final, por exemplo, notificações via app. Mas não sabemos nem se receber o código de barras e um lembrete vai resolver o problema, então primeiro precisamos testar isso. Posteriormente, podemos enviar SMSs com o link do código de barras para ver se o cliente tem acesso à internet (já que no SMS isso não é uma barreira). Se ele não tiver, não faz sentido seguir com a solução do app.
É economicamente viável?
Encadeando com o ponto de atenção anterior, o mesmo processo vai acontecer para as questões de engajamento e viabilidade econômica. Precisamos saber quanto prevemos de retorno financeiro para compensar o esforço que estamos fazendo, senão este esforço é inútil. A maioria dos times não faz ideia disso, e este desconhecimento costuma gerar uma falta de comprometimento com evitar desperdício.
Exemplo:
É economicamente viável?
Hipótese: Hoje cada ligação da central para cobrança desses casos tem um custo de R$10. Se conseguirmos que 25% das pessoas que pagam em 20 dias depois do vencimento não precise receber ligações da central, são 2 mil ligações a menos por mês, ou seja, R$ 20 mil reais de economia ao mês, ou R$240 mil ao ano.
Consideraremos sucesso se o custo/esforço para construir e manter esta solução for menor que 240 mil reais.
É tecnicamente viável?
Uma vez que temos clareza do que precisamos validar em relação ao problema, à solução, e ao ROI, podemos usar o mesmo processo de 1-2-all para discutir sobre quais são os critérios técnicos para considerar a solução bem sucedida.
Exemplo:
É tecnicamente viável?
Para ser tecnicamente viável, precisamos construir um processo automatizado de envio de mensagens. Para uma primeira fatia, podemos contratar um disparador de SMS com o objetivo de testar as hipóteses, mas para incorporar isso às plataformas da empresa consideraremos tecnicamente viável se o custo mensal pós-construção for abaixo de R$1 mil, e mantivermos uma cobertura de testes automatizados de 80%, para que os custos de manutenção do código sejam minimizados. Ainda, a solução deve ser adequada para uma volumetria de 100 mil clientes/mês, com crescimento de 20% ao ano.
Ao final desta dinâmica: De cara, você terá aí mapeados os 4 principais riscos relacionados ao investimento para resolver este problema. Certamente haverá outros, mas estes são os mais importantes para evitar que desperdicemos esforço e dinheiro criando uma solução inadequada. É absurdamente comum que foquemos apenas em riscos para a execução da solução, quando na verdade os maiores riscos para a estratégia estão nas hipóteses que deixamos de (in)validar. Você pode repetir este processo para ideias que forem priorizadas.
3- Mapa de Dependências
Por último, temos que tratar um dos maiores motivos para que um roadmap fique estagnado: as dependências! Em geral, buscamos sempre que possível eliminar dependências, mas nem sempre isso é viável. Além disso, seja para eliminá-las, ou para impedir que elas virem um problema, precisamos garantir que haja transparência sobre as dependências para a organização. E este é o objetivo desta dinâmica.
Para rodar o Mapa de Dependências, você vai precisar de:
a. 1 quadro branco
b. post-its
c. sharpies ou semelhantes
d. seu time e stakeholders
e. o Tanque de Decantação e a Matriz de Hipóteses feitos
f. opcionalmente, fitas crepe coloridas (fina e grossa)
Antes de começar: Este mapa não é um muro das lamentações. Se o seu time está colocando dependência em tudo, ou temos um sério trabalho de transmissão de conhecimento pela frente, ou ele está assumindo uma postura de reforçar os silos e atuar menos como um time multidisciplinar que deve aprender coisas novas para resolver problemas complexos. Fazer alinhamentos com outras áreas não é uma dependência, e sim parte normal do trabalho do time. Uma dependência significa que você precisa de uma entrega conjunta com alguém para que o que você está entregando funcione.
Peça para o time escrever 1 ideia que foi priorizada do Tanque de Decantação em um postit.
Depois, peça para o time tentar levantar todos os sistemas, áreas e outros times que têm entregas das quais este time depende para fazer a ideia funcionar e escrever cada um em um post-it.
No quadro branco, deve ser criada uma tabela com o seguinte formato:
Peça agora para o time colocar post-its com “X” na primeira linha de cada ideia nas colunas onde houverem dependência.
Agora, peça para o time identificar em cada caso onde há o “X”, qual é a contingência que eles podem oferecer para esta dependência. Onde uma contingência for viável, trocar o “X” por um “V” e informar a contingência no quadrante abaixo.
Ao final desta dinâmica: o time será capaz de priorizar não apenas seu próprio backlog, mas também ajudar a refinar e priorizar o backlog de outros times, evitando que haja estagnação. A partir deste momento o roadmap poderá ser montado ou atualizado considerando:
- O valor entregue para o negócio (métricas de resultado do Tanque, métricas de sucesso das hipóteses)
- Os riscos mais urgentes (hipóteses mais arriscadas para o negócio)
- Os desbloqueios necessários para dar início a uma entrega de valor (não adianta deixar uma parte pronta se há uma dependência e a outra parte não está priorizada pelo outro time).
ATENÇÃO: Todas as ferramentas aqui citadas devem ser atualizadas constantemente. Usá-las uma vez e então partir para a execução e não retornar à discussão com os aprendizados gerados durante a execução e testes de hipótese com os usuários será extremamente nocivo. Mantenha estas informações atualizadas com frequência, pois estas ferramentas vão auxiliar seu time a melhorar cada vez mais sua estratégia e resultados.
E aí? Curtiu? Ficou com alguma dúvida, ou tem alguma experiência que você quer compartilhar? Comente aqui embaixo!
