Product Owner Técnico??

A motivação pra escrever esse post veio de uma nobre discussão que meu amigo Guilherme Chapiewski gerou em seu blog ao fazer um post sobre o papel do Scrum Master atuando como líder técnico do time. Como o assunto é polêmico, e vou adicionar um pouco mais de pimenta, preferi fazer esse “post resposta”, pra não transformar o post do GC num fórum. 😉

<post_resposta>

Na minha opinião, uma das grandes sacadas do Scrum está justamente no fato dos papéis estarem muito bem definidos.

Durante anos a empresa para a qual eu trabalho, transformou nossos melhores técnicos em coordenadores, pois esse era o único jeito de diferencia-los do resto da equipe pelo excelente trabalho que eles faziam como desenvolvedores/arquitetos/resolvedores de problemas. E é ai que começam os problemas, pois o nosso excelente desenvolvedor senior, foi promovido a aprendiz de gestor junior e tem um longo caminho a trilhar. Mas pra complicar um pouco mais, ele não pode dedicar 100% do seu tempo as suas novas atribuições e ao seu aprendizado, porque alem de coordenador ele também é líder técnico, mete a mão na massa, faz café e chuleia, ou seja, começa a sofrer da sindrome do sofá-cama e não consegue fazer mais nada direito.

Felizmente, a menos de 2 anos atrás, nós criamos o cargo de “especialista” e agora as pessoas podem optar por seguir a carreira técnica e se dedicar aquilo que elas realmente gostam de fazer. Mas isso não resolveu o problema dos nossos amigos coordenadores que ficaram perdidos no espaço-tempo vestindo o chapéu de gestor até o meio dia e o de líder técnico depois do almoço. Isso só foi endereçado a cerca de 10 meses quando começamos a implantar o SCRUM.

Hoje temos coordenadores e até gerentes vestindo integralmente o chapel de time, analistas atuando como Scrum Masters, e todos -podendo- se dedicar 100% ao que mais gostam de fazer.

</post_resposta>

Essa polêmica toda acerca do Scrum Master técnico já foi muito bem endereçada pelo GC em seu blog. No entanto isso me fez lembrar de um tema que venho pensando há algum tempo e que deu origem ao título desse post.

Pode, ou deve, o responsável pelo retorno de investimento do projeto ser uma pessoa com excelentes conhecimentos técnicos?

Entre os papéis que o Product Owner deve exercer estão coisas como:

  • Definir as features do produto;
  • Release management;
  • responsabilidade pelo (ROI);
  • priorizar as features que tenham o maior valor de negócio;
  • aceitar ou rejeitar o trabalho feito pelo time;

Certo, olhando para isso não me parece que o P.O. precise de qualquer conhecimento técnico. Mas espere um pouco, observe como as grandes empresas que apostam no Lean Thinking constroem os seus produtos.

Vamos começar pelo criador da filosofia, a Toyota. No livro “The Machine that Changed the World”, James P. Womack explica que o elemento chave no processo de desenvolvimento de novos carros é o Shusa, uma espécie de super homem, o engenheiro chefe com excelência técnica, que mistura poderes de gestão a uma visão de mercado excepcional, para ser responsável pelo sucesso do produto. Ele tem responsabilidade e autoridade total sobre o projeto, é ele quem decide quais são as features que o carro terá e também qual será o seu custo no mercado.

O fato do shusa ser multidisciplinar, facilita a decisão rápida na hora de colocar na balança o custo de se implementar determinado requisito funcional versus o seu valor de negócio.

A Toyota é reconhecida por valorizar os seus funcionários como sendo o seu maior patrimonio, pois são as pessoas que desenham processos e produtos. E é com essa premissa que o shusa é “construído” dentro da Toyota, em geral ele é um engenheiro senior com mais de 10 anos de experiência, que então começa a ser moldado nas áreas de gestão, negócios, marketing e etc, para depois de cerca de mais 10 anos finalmente virar um shusa.

Na 3M, nosso líder é chamado de Champion e tem funções muito semelhandtes ao shusa. Todo desenvolvimento de um novo produto é liderado por uma figura dessas e um time extremamente motivado. É o Champion quem concebe o produto(sempre visando resolver um problema do cliente), escreve a sua especificação inicial, monta o time, motiva, remove impedimentos, e lídera até o delivery. O Champion é um líder técnico que consegue enxergar um problema do cliente e endereçar o mesmo com uma solução inovadora.

Como é de se imaginar, na Toyota e na 3M, a posição do shusa e do champion são altamente desejadas. Esse é o lugar onde todo mundo dentro da empresa gostaria de estar, e isso motiva novas pessoas a perseguirem esse caminho gerando uma escola natural de líderes.

Seja Shusa ou Champion, o fato é que produtos brilhantes são concebidos por pessoas brilhantes.

No início do Scrum o P.O. era visto como uma pessoa que trabalhava com uma distância grande do time, ja que a pressão que ele exercia era prejudicial ao time. Atualmente a grande missão do Scrum Master é transformar o P.O. num aliado do time.

Juntando todas essas peças, formulo minha teoria de que, se alguém além do time deve ter conhecimentos técnicos, esse alguém é o P.O.. Ele sim deve ser um grande líder, com experiência técnica em alguma área funcional, que direciona o time pela competência, motiva e entusiasma. É a pessoa na qual o time se espelha e briga pra fazer da idéia dele uma realidade.

Anúncios

17 comentários em “Product Owner Técnico??

  1. a globo.com eh uma empresa de mediatechnology, todo mundo tem que entender de tecnologia, respirar tecnologia, falar de tecnolgia alem de media eh claro.

    nao acho que seja possivel ter scrumaster/productowner que naum tenham profundos conhecimentos de tecnologia/web/media.

  2. Nada contra, mas também nada a favor. Além de mídia e internet, o PO precisa ter um olho no gato e outro no peixe – usuários e metas corporativas. É na trincheira dessa tradução criativa que vamos construir grandes produtos.

  3. Pra variar, meto meu bedelho 🙂

    Qualquer metodologia, desde as que funcionam até as que só funcionaram uma vez e para desenvolvimento em mainframe, tem papéis bem definidos. O ponto é que *papel* não é *cargo*, uma pessoa pode exercer vários papéis ou um só, *depende do contexto*.

    Quanto ao conceito de campeão, Fred Brooks propôs um time onde existe um engenheiro-chefe que lembra este papel.

    []s

  4. Opa,

    Tendo a discordar um pouco.
    O caso que você descreve é de um produto para uma empresa de técnologia.
    Imagine se sua empresa fizesse cosméticos, ou panelas ou fosse uma empresa de logistica, nestes casos, um PO técnico não adiantaria nada. Minha impressão é que seria melhor alguém que soubesse de cosméticos, ou de panelas ou de logística, se esses fossem os temas dos sistemas a serem construídos.

    Já vivi na pratica situações em que o product owner queria um produto para usuários como ele e ele havia instalado micro em casa havia 3 meses. Era totalmente leigo em técnologia e queira uma interface cativante para pessoas como ele. Faziamos sugestões enquanto time e o P.O. recusava pois era muito avançado para o espirito iniciante dele. O projeto foi entregue e o produto era extremamente robusto para atrair o publico que ele queria atrair e conhecia bem.

    Minha impressão é que o P.O. deve ser técnico em uma empresa de técnologia, jornalista numa empresa de jornalismo e engenheiro em uma empresa de engenharia….minha impressão…..

    falou!

  5. Daniel,

    concordo plenamente com vc. Acho que acabei usando a palavra técnico por ser de mais fácil entendimento. Mas o importante mesmo é que o PO entenda do “DOMíNIO” do negócio.

    Muito bem colocada a sua observação, obrigado!

    []’s
    Danilo Bardusco

  6. Concordo com boa parte do que diz o post, embora não acredite que um PO com visão técnica em tecnologia seja o mais adequado para a entrega de times.

    Como em qualquer time, a maior parte dos integrantes são técnicos-especialistas, ou seja, é um desperdício ter um PO, responsável pelo ROI, pensar em questões técnicas.

    Creio que o mais adequado são POs com perfis mais de humanas, ligados a marketing ou áreas afins. POs com conhecimentos nessas áreas são mais capazes de indentificar boas oportunidades de negócio dentro do domínio de atuação dos produtos.

    Quanto a expertise técnica, porque não confiar 100% no time? Afinal, são eles os especialistas. Basta ao PO ter a clareza em dizer aquilo que devemos fazer para gerar mais lucros aos produtos. Eles são cobrados por isso, e não por conhecimentos técnicos.

    E vamos combinar… ScrumMaster técnico? Parece até que não conhecem o scrum… Os melhores ScrumMasters seriam, possivelmente, psicólogos, sociologos ou coisas do generos… Afinal, para lidar com times multidisciplinares (ou não), é interessante não existirem ScrumMasters que “puxem a sardinha” para os desenvolvedores. Lidar com pessoas é algo bastante complicado, é melhor colocar os profissionais certos para lidar com estas situações. E também porque perder os melhores lideres técnicos em suas áreas? Desculpe ser tão enfático, mas parece idiotice!

  7. Acho que o PO tem que conhecer de negócio e deixar a parte técnica com o SM e o Time, pois assim ele se dedicar exclusivamente a parte de negócio…assim como o time se dedica a parte técnica e não de negócio. É claro que em alguns casos é válido a sugestão de todos, mas a especialidade de cada um tem que ser reservada.

    []’s

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s