De acordo com pesquisas da CB Insight, boa parte das startups fecham as portas prematuramente por não encontrarem o product market fit. Ou seja, por não atenderem às necessidades dos seus usuários de uma maneira melhor do que outras alternativas. Isso me faz refletir como as empresas estão olhando para os problemas em que estão dispostas a resolver. Trazendo essa reflexão para a nossa realidade, como olhar para os problemas que aparecem na empresa que você trabalha? Será se você está dando a atenção necessária para entender mais a fundo os sintomas (afim de encontrar as causas raízes)? ou está apenas reagindo a eles?
Agilidade e a Complexidade.
Como agilistas, é fundamental entendermos a relação da agilidade dentro de um ambiente complexo. Mas, o que isso quer dizer? De acordo com o modelo Cynefin, um ambiente complexo é definido pela imprevisibilidade, onde a relação entre causa e efeito se dá através de situações emergentes, necessitando a existência de padrões que priorizem respostas rápidas a mudanças e bastante experimentações.
Gerando um debate sobre essa visão, temos também a gestão 3.0 falando sobre a nossa capacidade de lidar com situações complexas sustentada por uma definição, muito interessante, de Russell L. Ackoff.
A busca por soluções simples – ou simplificadas – para problemas complexos é uma consequência da incapacidade de lidar eficazmente com a complexidade.
Em outras palavras, é natural para nós, como seres humanos, querer simplificar os eventos que acontecem para entendermos com mais facilidade. Porém, é preciso criar mecanismos para tratar complexidade com complexidade. Simplificá-la traz um risco grande em agirmos nos sintomas e não na causa raiz.
Qual o nosso olhar sobre os problemas?
Penso que essa é a pergunta chave deste post. Você, um líder-servidor, como tem mapeado isso? É de suma importância entender a natureza do seu contexto. Como falei no início, muitas empresas fecham suas portas por não entenderem a necessidade de seus usuários e, consequentemente, não conseguem adaptar-se para o contexto em que vivem.
Por isso, gostaria de apresentar um framework que costumo utilizar no meu dia-a-dia para mapear os problemas e suas causas raízes. Vale destacar que montei esse modelo baseado em uma retrospectiva com Kata.
Como Funciona?
Evidências ou Perspectivas
E nessa loucura, de dizer que não te quero… Gosto de começar por aqui. Quais são as evidências ou perspectivas que você tem percebido de um possível problema? Liste aqui os itens de forma clara e procure associar também as suas consequências como algum comentário que você ouviu durante uma reunião ou conversa com o time, por exemplo.
Essa etapa é bastante importante, pois irá te ajudar a sintetizar melhor o problema a ser resolvido.
- Exemplo: User Stories não citam o valor de negócio, logo o time não se sente produtivo.
- Demandas top-down sem passar pelo entendimento de produto/negócio
- “PO não traz as demandas claras o suficiente pra gente” (comentário de alguém do time).
Problema
Logo após saber as evidências (ou perspectivas) de um possível problema e suas consequências, tente escrever isso em uma sentença. Importante ser bastante claro, pois essa sentença é a declaração que irá guiar todas as suas ações.
Um ponto interessante aqui é definir também quais são os critérios de sucessos de cada problema respondendo a seguinte frase: o problema estará resolvido quando… ?
Procure não se prolongar muito e coloque em prática seu poder de síntese. Pergunte-se: como definir esse problema em um tweet?
- Exemplo: Valor de negócio não está claro o suficiente para o time. Esse problema estará resolvido quando as próximas 10 histórias estiverem com o valor de negócio declarado em sua descrição.
Ações
Com a visibilidade do problema, suas evidências e consequências, pense em possíveis experimentos que poderiam ajudar a resolvê-los. Você pode, no entanto, associar os experimentos com um ou mais itens da evidência.
- Exemplo: Demonstrar como se escreve uma user story.
- Definir estrutura básica do que é preciso ter em uma user story antes de chegar para o time.
Resultado
Após rodar os experimentos, é importante você anotar o resultado. Mas primeiro, mova o experimento para a coluna resultados e liste todos os resultados que aquele experimento teve (tanto positivos quanto negativos).
Seguindo o exemplo do problema, você pode também definir critérios de sucesso para cada experimento. Isso o ajudará saber se seu experimento resolveu o problema como um todo ou não.
- Exemplo: Demonstrar como se escreve uma user story: Rodei uma dinâmica específica para isso, o PO pareceu bem empolgado e se comprometeu em deixar claro o valor para as próximas histórias.
Bastante simples, não?
Tenho utilizado esse modelo já tem mais de ano e tem me ajudado bastante em diversos aspectos. Em primeiro lugar, a visibilidade das situações me dão clareza dos insumos que preciso para montar meu backlog de problemas.
Uma técnica que me ajuda a identificar alguns problemas são os cinco porquês.
Outro fator positivo é que essa estrutura facilita a comunicação com gestores e c-level que estão mais distante do dia-a-dia dos times, deixando claro quais são os problemas e como pretende-se resolvê-los.
Outro aspecto que acho legal é mostrar para mim o quanto tenho ajudado na resolução dos problemas da empresa e dos times, ajudando mandar a Síndrome do Impostor para beeeem longe.
Por fim, uma última dica que dou para esse modelo é manter o anonimato. Ele é específico para atuar com melhoria contínua e nada mais! Então, se tem a intenção de compartilhar com alguém, tenha cuidado com as palavras e tente não enviesar a visão de quem você está compartilhando.
Portanto recomendo que você utilize e adapte esse modelo para o seu contexto, pois não existe certo e nem errado na interação com ele. Apenas mantenham a disciplina de olhar com frequência e não deixar para atualizar depois.
O que acharam? Coloca aí nos comentários como você tem feito!
Abraço 😉
Diogo, acredito que dessa forma podemos chegar a causa raíz do problema de uma forma muito mas prática, confesso que hoje utilizo muito os 5 “porquês”, mas irei testar esse método apresentado, obrigado por compartilhar.
Grande Jackson!
Acredito que os 5 porquês ajudam demais a construir esse modelo.
Depois compartilha suas experiencias 🙂