A amiga Jessica Seixas (https://aboutproduct.medium.com/) publicou recentemente um texto (“Não seja apenas um problem-giver” — <https://bit.ly/3n5LTJz>) sobre um dos papéis do Product Manager/Owner. Excelente texto, apesar de breve, em que ela defende o ponto do PM/PO trazer soluções para os problemas dos clientes nos produtos e não apenas levantar os problemas.
Nota: numa leitura adicional ao texto de Jessica, percebi que cometi uma asneira. Ela estava desabafando num sentido inverso do que comento no texto. Ali ela pede que as pessoas venham com soluções, ela chama os participantes para ajudar a resolver o problema. Com esta visão, este texto vem como sublinhado do original e não como contraponto. Mea culpa, maxima culpa.
Primeiro, preciso dizer que simpatizo com essa visão. Trabalhei minha vida inteira como troubleshooter, desde meus tempos de produtor gráfico, e gosto de resolver as coisas para as pessoas ao meu redor. Mas isto é uma característica pessoal, a meu ver. Não é uma função de um Product Owner/Manager.
O grande barato nos modelos ágeis é que o protagonismo da execução de um projeto sai da mão do cliente ou do project manager e vai para quem executa, quem está com a mão na massa. É mais ou menos deixar para o time que está levantando um prédio a responsabilidade e a potencialidade de resolver os problemas que possam surgir durante a execução do projeto.
Essa é uma referência boa, apesar de derivada do PMI: a noção de accountability e responsability. Um bom PM/PO é accountable pelo resultado de uma ou uma série de sprints. Ele é quem garante que o que foi combinado com os stakeholders está alinhado com o que está sendo produzido. Usando a mesma metáfora do prédio, é o condutor de obras, o responsável em verificar as plantas, os impactos não previstos da obra, os problemas não medidos anteriormente. E, o terror de todos, em atualizar os malditos cronogramas. E responsible é quem executa algo, alguém que toma para si a ação da coisa. As funções podem se fundir na mesma pessoa, mas o accountability tende a ser escalado e divido por toda a organização. A responsability, não.
Quando a gente coloca a responsabilidade da solução de um problema ou dor de um produto na mão do PM/PO estamos entrando numa seara muito arriscada: a do Ego. Estamos pedindo para que o PM/PO coloque sua visão do produto acima das dos demais. Erro crasso.
Em primeiro lugar, partimos do pressuposto que o PM/PO tem a visão completa dos impactos de um produto ou, pelo menos, dos motivos daquela dor que está sendo endereçada na sprint. Apesar disso estar no manual de todo mundo que contrata um PM/PO e em todos os discursos feitos pelos gurus de produto (sem apóstrofo) pelo mundo afora, é uma mentira deslavada. Ninguém é capaz de prever todas as infinitas possibilidades de um produto. Aliás, digo mais: se um produto chegar a este nível de previsibilidade, de não dar para imaginar algo maluco com ele, tá na hora de jogar fora e fazer um novo. Ele virou peso de porta.
Digressões à parte, o PM/PO realmente precisa ter uma boa base do produto. Principalmente ter em mente os valores de entrega dele para seu usuário/cliente e saber medir o impacto desses valores à medida que ajuda o time a desenvolver funcionalidades ou melhorar o desempenho do que está em funcionamento. É esta a sua função em um squad de desenvolvimento. Medir, priorizar e endereçar. Na falta do Scrum Master — que andam sumidos, assim como os QAs —, também tem que desembaraçar problemas de trânsito de informação ou de engajamento (os problemas técnicos tão caindo no colo dos Tech Leads, coitados).
Em segundo lugar, o PM/PO é um membro de um time. Sua voz não deveria estar acima dos desenvolvedores, dos UXers ou, principalmente, dos stakeholders. Todos estão ali, juntos, para resolver o problema que o PM/PO diz ser o prioritário, é a bola da vez. Esta discussão é coletiva. Claro que o PM/PO pode — e deve! — ter opinião forte, baseada em dados e fatos, para defender um ponto de vista ou uma solução que ele acha a ideal, mas ele é apenas uma visão em uma multiplicidade de vivências. É esta a grande força do SCRUM.
Vários dos meus ex-colegas, de lugares que trabalhei no passado, chegavam com soluções prontas para seus times de desenvolvimento, mas geravam mais antipatia que engajamento. A reclamação mais comum dos PM/PO era que o time “ficava enrolando”; a dos desenvolvedores era que os PM/PO não os escutava. Ambos estavam certos nas suas reclamações. A descrição da função (PM/PO = chefe) é que estava e está erradíssima. Já estive no time que “mandava” nos desenvolvedores e fazia pouco de seus prazos e impedimentos. Sempre me ferrei de verde e amarelo (mugindo, claro!) e me provaram por A+B que este método não funciona. O jogo é jogado com o time inteiro.
Claro que muitos gerentes (ou Group PM/PM, Product Head, Übermaester, ou coisa assim) vão querer ver entregas, vão forçar a barra com cronogramas e roadmaps (outra coisa que deveria morrer amanhã!), mas esse é um legado de um capitalismo industrial que está morrendo a passos largos.
Pro terceiro lugar, trago uma analogia acadêmica. Em Filosofia dizemos que as perguntas que fazemos são mais importante que as respostas (até porque dificilmente as temos nesse saber). Isto também serve para o filho mais ilustre da filosofia, as Ciências “puras”. O perguntar tem que ser bem feito, bem montado. Falseável, testável, verificável e passível de repetição. As propostas de solução precisam ser submetidas a uma verificação pelos pares (do mesmo saber) e colocadas em dúvida novamente. A dúvida é que faz com que os saberes caminhem à frente e não uma resposta impromptu. Cada vez que chegamos com uma solução “no bolso”, abrimos mão de outra solução que talvez seja mais eficiente, barata e elegante daquilo que estávamos pensando.
Este contraponto é o tal do dogma versus paradigma. O dogma não admite discussão. Ele é e pronto. É uma tautologia. O paradigma muda, adapta-se ou é descartado quando deixa de funcionar. Essa mentalidade é que tem que permear a conduta do PM/PO. A gente não pode ter uma solução antes de levar para o time; temos é que ter um problema bem formulado, entender que dor aquele problema gera, que valor estamos deixando de atender ou que incremento estamos propondo ao produto.
Valores. Incremento. Dores. É nisso que o PM/PO precisa focar desde o café da manhã. E, pessoalmente, fujo de gente com solução para tudo.
E, como dizia H.L. Menken, “para todo problema complexo, existe sempre uma solução simples, elegante e completamente errada.”
a casa do zander 