Like A Girl

Pushing the conversation on gender equality.

Code Like A Girl

Ser ágil e o desafio de não ser rápido

Não adianta remar rápido se você está indo pro lado errado.

Há não muito tempo atrás facilitei, em conjunto com a Ju Akemi e Renata Gabriella (duas outras POs que eu admiro muito), um workshop sobre Product Discovery, originalmente criado em conjunto com o Flavio Nazario. Durante e após o workshop, gosto de observar quais são as perguntas que surgem, se as pessoas têm desconfortos em comum, e como a inteligência coletiva lida com estas questões.

Algumas das principais dúvidas mais comuns são:

  • O time participa do discovery?
  • Mas a gente envolve os stakeholders pra definir o detalhamento do produto?
  • Como transformo a crença de um stakeholder sobre o que o produto deve ser em histórias que façam sentido pro usuário?
  • O que fazer quando tudo é prioridade máxima?

O que essas perguntas me dizem é que estamos — e me incluo no balaio — sempre lutando contra o impulso de deixar o ágil de lado e seguir o caminho de maior conforto. Ágil é simples, mas não é fácil. Da mesma forma, a escolha mais confortável é fazer a coisa rápido, o que nem sempre coincide com fazer a coisa ágil.

O caminho mais rápido é não envolver o time no discovery, e tratar o time como um grupo de executores, e não como idealizadores de soluções para necessidades que estamos descobrindo juntos.

O caminho mais rápido é detalhar as histórias e já passá-las para o time desenvolver, sem que elas emerjam dos stakeholders + time.

O caminho mais rápido é perguntar pro cliente o que ele quer, agir como um tirador de pedido, e não entender profundamente a necessidade que está por trás do pedido, conduzindo os stakeholders até a solução.

O caminho mais rápido é deixar que o HiPPO (the Highest Paid Person's Opinion) te diga qual é a prioridade em vez de efetivamente construir consenso entre stakeholders e time.

Essas e tantas outras práticas são indicadores de que queremos resolver o problema logo, nos livrarmos do incômodo do conflito, priorizar velocidade sobre fazer o produto certo e, em suma, entregar features, e não valor.

Estamos fazendo tudo contra o que é o papel do PO.

Durante o processo de gerir um produto, o papel do PO é maximizar valor. No entanto, para maximizar o valor, precisamos antes lidar com todos os empecilhos para que este valor se materialize. Temos stakeholders que acordaram aquele dia com *a* ideia genial que vai resolver todos os nossos problemas (ou não), temos conflitos de interesses, temos falta de visão de métricas de sucesso… e, sobretudo, temos problemas de comunicação.

Na prática, eu costumo dizer que, na gestão de um produto, todo problema é um problema de comunicação. Porque se algo é inviável, e isso é comunicado de forma que todos os envolvidos entendam os porquês da inviabilidade, isso deixa de ser um problema e passa a ser uma circunstância a ser considerada. Se temos um conflito e as necessidades de ambas as partes estão bem comunicadas, podemos consensar uma solução, e novamente, o problema se dissolve.

Só há um problema na gestão de um produto que efetivamente deve ser encarado como um problema: o problema do seu usuário, que você está tentando resolver com o seu produto.

Para isso, precisamos parar de buscar soluções rápidas e confortáveis para nossos conflitos do dia a dia, e entender como podemos ser ágeis na validação de hipóteses, consenso, motivação e aprendizado.

E aí, inevitavelmente, faremos produtos fantásticos.

Siga a tag codelikeagirlBR para ver nossos posts! 😀

Quer escrever ou traduzir artigos em português para a Code Like A Girl? Se você já faz parte do time de escritoras(es) da Code Like A Girl basta enviar seu artigo diretamente para nossa publicação. Se você ainda não faz parte do nosso time, envie uma mensagem direta para a conta de twitter CodeLikeAGirlBr. Nós avaliaremos seu artigo e ajudaremos a refiná-lo para publicação.