Como alguns de vocês já sabem, estou desde o final de 2008 no Yahoo!, e junto com uma equipe incrível ajudei a criar o Meme, um novo site de light-blogging que está em versão beta.
Entrei no Yahoo! a convite do Antonio, que acabou me citando nesse post ao explicar um pouco sobre o Meme e como foi desenvolvê-lo usando Scrum desde o começo.
Quero contar pra vocês o que é esta função e como eu vim parar aqui.
Meu papel na equipe é de P.O., ou seja, Product Owner, que traduzindo significa “dono do produto”. O nome é imponente e sugere uma importância crucial, e essa foi mesmo a minha primeira impressão. Mas não é nada ditatorial, o PO tem é a palavra final na priorização das funcionalidades durante o desenvolvimento.
Eu sempre quis implantar métodos ágeis na TV Cultura, onde estava trabalhando antes, e havia começado a estudar o assunto. Mas confesso que não tinha entendido direito o que um PO faz até ler o Agile Estimation and Planning, do Mike Cohn.
Quando recebi o convite para vir pro Yahoo!, o Antonio me disse que fui selecionado por ter “o perfil mais estranho que ele havia encontrado”. Achei graça, mas deve fazer sentido, eu também conheço pouquíssimas pessoas com um perfil similar.
Mas qual é esse perfil? E por que ele se encaixa na função de PO?
Sou jornalista formado, fiz mestrado em engenharia e adoro programar no meu tempo livre. A multidisciplinaridade sempre me atraiu e por isso acabei – sem perceber – durante toda a vida me preparando para exercer esta função que eu eu nem sabia que iria existir.
Não sou tão bom programador quanto os caras da nossa equipe. Eles me põem no chinelo, fácil. Não sou tão bom repórter quanto meu amigos de redação. O texto deles é muito melhor, sem nem fazer força. Mas sou autodidata e fuçador, atiro para todos os lados. E sempre tive a intuição de que isso – além de ser muito divertido – ia me servir pra alguma coisa no futuro.
E serviu. A função de PO, conforme explicada nos livros, exige um entendimento das pressões externas do mercado, das demandas internas da empresa e do desenvolvimento diário do produto. Em cima de tudo isso, o PO precisa ter uma visão clara do caminho que o produto deve seguir e priorizar as coisas para que essa visão se concretize.
Óbvio que eu não sabia nada disso ao começar, muito menos como era trabalhar em uma empresa multinacional com 15 mil funcionários. Mas fui aprendendo, entendi a lógica do processo e me adaptei sem grandes traumas. Um ano depois, ficou natural transitar entre discussões sobre refatoração de código e iniciativas de marketing. É corriqueiro passar de brigas sobre design de API a apresentações com planejamento para o ano seguinte.
Em um time, ninguém manda em ninguém
Como estou cercado de gente que sabe mais do que eu em suas especialidades, não sou trouxa de sair decretando o que me vem na telha. Em teoria, o PO tem esse poder, mas eu acho bobagem centralizar tanto assim. Sou obrigado a buscar argumentos convincentes – técnicos, teóricos ou políticos – para justificar as decisões do que vai ser feito na seqüência. E assim como posso ser convencido, tento convencer também por meio destes argumentos.
Estar em um time ágil com profissionais de diversas áreas dedicados inteiramente a um produto foi uma novidade que me fez aprender muito. Todos trabalham para entregar o resultado final, e não para concluir a sua parte na linha de produção. A auto-organização e respeito à inteligência do time é essencial. Não existe alguém mandando nos outros para que determinada tarefa seja feita.
O reflexo deste modelo para o PO é que qualquer decisão incomum aos olhos do time vai ser bastante questionada. Estamos todos no mesmo barco, e o fato de termos sucesso ou afundarmos juntos faz com que o grupo queira fazer a coisa certa e seja bastante proativo em relação a isso. Portanto, mais do que ditar a visão a ser seguida, o PO precisa convencer a tripulação a remar pra frente, mostrando por A+B que a direção faz sentido.
