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.
