Rafa Nascimento

Esqueceram de mim

Posted in papéis, scrum by Rafa Nascimento on 11/08/2011

A principal tarefa de um Scrum Master é curta e grossa: garantir o bom funcionamento do Scrum. Existe uma tarefa implícita nesta frase, que é extremamente desafiadora: educar bons Product Owners. Muitos Product Owners ainda não conhecem seus papéis como deveriam, geralmente têm bastante experiência em projetos de software e raramente são incentivados a criar uma comunidade para que possam desafiar suas certezas em prol de uma nova realidade. Além disso, eles enfrentam a principal mudança que os métodos ágeis trazem consigo: foco nas pessoas como o verdadeiro motor durante o desenvolvimento de um produto, não no projeto. Em um primeiro momento, a cultura ágil privilegia os times de desenvolvimento de produtos, o que torna a adoção da cultura mais fácil para os desenvolvedores. Por conta da dificuldade particular de educar Product Owners, muitos acabam “esquecidos” pelos Scrum Masters e viram verdadeiros pedregulhos no caminho dos times.

Quem é o Product Owner?

O primeiro passo para se educar um Product Owner é saber quem ele é (ou quem ele pode ser). E definir quem é o Product Owner é uma tarefa do Scrum Master. Algumas características ajudam nesse desafio:

Segundo Roman Pichler, em Agile Product Management with Scrum, um Product Owner deve ser:

  • Visionário e executor;
  • Líder e membro do time;
  • Comunicador e negociador;
  • Com poder de decisão e comprometido;
  • Disponível e qualificado.

Levando em consideração tais características, podemos elencar alguns profissionais que podem se encaixar no papel:

Analista de negócio: Este profissional tem a peculiaridade de conhecer bem as regras de negócio de uma organização sendo ele um profissional de TI. Pelo forte foco no produto que a cultura ágil prega, ele acaba sendo uma boa opção por seu conhecimento das necessidades da organização. O problema é que nem todo analista de negócio sabe ou quer medir o progresso do desenvolvimento do produto e resolver, ele próprio, as barreiras de comunicação que dificultam a integração entre as partes de um produto.

Gerente de produto: Pouco explorado, este profissional é utilizado em pouquíssimas empresas. Na minha opinião, é a melhor representação de um Product Owner. É um analista de negócio, que tem responsabilidade sobre o prazo de seu produto e precisa reportar o progresso do desenvolvimento do mesmo aos seus clientes. O único perigo com este profissional é o de ser uma pessoa hiperativa que não consegue esperar que as soluções emirjam do próprio time. Esta atitude pode minar a auto-organização e a auto-gestão do time.

Gerente de projetos: Algumas empresas já tentaram elencar gerentes de projetos como Product Owners. Funciona bem, desde que o profissional consiga se desvencilhar do hábito de comando e controle que seu papel original propõe. Adotando uma mentalidade de coach, de liderança-servidora e focando no produto e na satisfação do cliente acima de tudo, o gerente de projetos também pode se tornar um bom Product Owner.

Usuário-chave: Usuários têm outros afazeres em suas rotinas que não podemos ignorar. Quando estamos falando de projetos pequenos, onde o próprio dono de um empreendimento trata com 1 ou 2 desenvolvedores, o usuário-chave como Product Owner funciona muito bem. Quando o produto começa a crescer e ficar mais e mais complexo, surgem questões tecnológicas das quais um usuário-chave não tem a mínima ideia do que significam. Sem contar que este tipo de Product Owner tem a tendência à otimização local e ignora as questões de integração com outras áreas da empresa dentro do produto. Nesse momento, um usuário-chave como Product Owner pode ser extremamente prejudicial ao produto.

Um bom Product Owner leva todos a bons sprints

Um time Scrum que não tem um bom Product Owner está fadado a fracassos. Os insulmos oridundos deste papel são tão importantes quanto o produto que está sendo desenvolvido pelo time de desenvolvimento. Em todas as experiências que tive com times ágeis, o Product Owner tinha um peso enorme sobre o progresso do time. Negativo ou positivo. Um bom Product Owner sabe motivar o time em prol da sua visão de produto e consegue, facilmente, definir o plano de ação para ter aquele produto, ao final de um projeto ou período. Um mau Product Owner é capaz de segurar o progresso do time inteiro e, mais do que isso, desmotivá-lo por sua falta de visão, clareza e segurança e colocar seu produto em sérios apuros. Sem um bom Product Owner, não há um bom time. Sem um bom time, não há um bom produto.

Coaching, não só mentoring

Para um time de desenvolvedores, o que importa é desenvolver software e ter seu conhecimento constantemente desafiado para que criem boas soluções para os problemas que encontram durante a construção de um produto. Se estamos utilizando Agile ou Waterfall, pouco importa. Desde que todos sintam-se em casa e estejam felizes em estar ali. Em minhas experiências, é relativamente fácil conduzir a adoção de um framework ágil em um time de desenvolvedores. Principalmente porque a cultura ágil favorece seu bem-estar. É um trabalho muito mais forte de mentoring, de ensino, do que de coaching.
No caso do Product Owner, a realidade é outra. Desenvolvedores, designers, testadores. Todos continuam sendo desenvolvedores, designers e testadores. Mas um Product Owner, provavelmente, era gerente de projetos ou analista de negócio. Além disso, a cultura ágil “prejudica”, à primeira vista, o seu tempo de resposta ao cliente. Ele está passando por 2 grandes mudanças: no formato do seu trabalho e no seu próprio papel dentro da cultura. Não há dúvidas: haverá resistência. E tal resistência não é quebrada somente com o mentoring em Scrum do Scrum Master. Este Product Owner vai precisar de um Scrum Master no papel de seu coach, ajudando-o a desenvolver novas competências para uma nova realidade e auxiliando-o no questionamento de suas certezas para descobrir novas certezas. Não é um trabalho fácil, nem breve, mas é fundamental.

Scrum Master: seja parceiro do seu Product Owner

Costumo dizer que, no Scrum, o gerente de projetos foi dividido em 2: Scrum Master, responsável pelo processo e pelas pessoas, e Product Owner, responsável pelo produto. Antes, um gerente de projetos era responsável por processo, pessoas e produto. Fatalmente, e não pouco frequente, seu foco se mantinha no produto, ignorando o bem-estar das pessoas e a manutenção de um bom processo de desenvolvimento do produto. Scrum Masters e Product Owners, juntos, devem representar gerentes de projetos melhores do que os representados em uma só pessoa, pois as atenções estão bem divididas. Se estes dois papéis representam um profissional, para que ambos tenham sucesso é preciso uma colaboração e parceria muito fortes. Apesar das rusgas e discussões que os prazos e negociações trazem, Scrum Masters e Product Owners trabalhando em parceria são vitais para o bem-estar e felicidade do time de desenvolvimento  e, consequentemente, para o time Scrum e, consequentemente, para o produto e, consequentemente, para a empresa e, consequentemente…

Anúncios
Tagged with: , ,

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 )

Imagem do Twitter

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

Foto do Facebook

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

Foto do Google+

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

Conectando a %s

%d blogueiros gostam disto: