Profissionais TI - Pra quem respira informação

Dando continuidade ao último artigo Scrum no Burndown (recomendo sua leitura antes deste), vamos conversar a respeito do papel mais importante, na minha opinião, deste framework: o Product Owner.

Esta figura realmente é o dono do produto. É a pessoa responsável por fazer o pedido para a área de TI e acompanhar todo o desenvolvimento e entrega de cada pacote do sistema. Alguns clientes insistem em designar este papel para uma pessoa de TI. Acreditam que um analista de sistemas sênior seja o mais indicado para esta função, inclusive para facilitar a comunicação com a equipe de desenvolvimento. Eu discordo e vou explicar.

O Product Owner é a única pessoa que tem a responsabilidade de gerenciar o Product Backlog, o que inclui:

• Expressar com clareza os itens do Product Backlog. Por este motivo é absolutamente importante que esta pessoa seja da área de negócios da empresa, com know-how suficiente para tomar decisões que sejam aderentes às necessidades e expectativas corporativas. O Product Owner representa e defende os interesses de negócios que serão traduzidos em sistemas pela equipe de desenvolvimento. Por esta razão que eu não concordo em atribuir este papel a um analista de sistemas que, por evolução da carreira na maior parte dos casos, vem da área de desenvolvimento ou ainda atua na área, dependendo da organização da empresa.

• Priorizar os itens do Product Backlog para alcançar com mais eficiência as metas. Justamente por ser a pessoa que melhor conhece as regras de negócios tratadas no projeto, possui a percepção para criar e ordenar os itens (pacotes) a serem desenvolvidos e entregues de maneira eficiente e produtiva para sua área. Lembrem-se de que o Scrum  emprega uma abordagem iterativa e incremental para aperfeiçoar a previsibilidade e o controle de riscos, permitindo a entrega de uma versão incremental potencialmente utilizável do produto, em outras palavras, um pacote entregue é um pacote que pode ser utilizado em produção. Portanto fica evidente a importância do Product Owner ser a pessoa que conheça tão bem os processos e regras de negócios que seja capaz de criar estes pacotes de forma inteligente e produtiva.

• Garantir o valor do trabalho realizado pelo Time de Desenvolvimento. Um projeto TI vencedor é aquele que concilia a inteligência de negócios às habilidades técnicas de cada profissional envolvido e que estas pessoas formem uma equipe eficiente. Garantir este valor requer ponderação do Product Owner em saber exatamente o que está solicitando em cada pacote e ser responsável pelo produto entregue, considerando que a equipe de desenvolvimento tenha seguido à risca o que foi solicitado. Vejam que é um trabalho onde cada um precisa executar sua tarefa sem desvios ou dúvidas. Novamente fica evidente a importância do Product Owner em conhecer muito bem os processos e regras de negócios envolvidos em cada pacote a ser desenvolvido. O time de desenvolvimento, por sua vez, deve ser tecnicamente competente e responsável por entregar um pacote que contenha tudo o que foi solicitado. As reuniões diárias previstas neste framework têm justamente a função de expor e sanar qualquer dúvida ou empecilho que possam existir durante o desenvolvimento do pacote e permitir que o produto entregue seja fiel ao que foi solicitado pelo Product Owner. Estas reuniões vou detalhar futuramente, em outro artigo, onde vamos conversar a respeito dos Eventos no Scrum.

• Garantir visibilidade, transparência e clareza das etapas concluídas e próximo passo do projeto para todos envolvidos. Esta responsabilidade é fundamental para que todas as pessoas, de negócios e TI, estejam cientes do andamento. A real sensação de que o projeto está sempre caminhando é uma das características mais brilhantes do Scrum e que proporciona um aumento constante da confiança e credibilidade em todas as pessoas envolvidas no projeto. Pessoas motivadas produzem mais, principalmente quando enxergam que o caminho a frente fica mais curto a cada semana.

• Garantir que o Time de Desenvolvimento entenda os itens do Product Backlog no nível necessário. Tão importante quanto conhecer muito bem os processos envolvidos e ter uma equipe técnica competente, é fazer com que o time de desenvolvimento entenda claramente cada item. É preciso manter um nível de diálogo em que técnicos e executivos sejam compreendidos. Muitas vezes participei de projetos de baixa complexidade e acabaram tornando-se críticos porque envolviam pessoas que falavam idiomas diferentes ou porque tentavam incluir nas conversas termos técnicos. O Product Owner é responsável por esta interface, independente de idiomas ou nível técnico. Como comentei anteriormente, o Product Owner não deve ser técnico para que não haja qualquer tipo de interferência, mas é necessário que tenha fluência nos idiomas que estarão presentes no projeto, uma vez que ele é o condutor de todas informações entre área de negócios e equipe de desenvolvimento. Deve ser capaz estabelecer uma comunicação absolutamente clara entre qualquer pessoa envolvida no projeto.

Estas são as principais responsabilidades de um PO (vamos tratar desta maneira o Product Owner para efeito de praticidade). Para que o PO tenha sucesso todos da empresa devem respeitar as suas decisões que são visíveis no conteúdo na priorização do Product Backlog. Ninguém está autorizado a falar com o time de desenvolvimento sobre diferentes configurações de prioridade ou alterações de itens a serem entregues, assim como o time de desenvolvimento não tem permissão para agir de acordo com o que outras pessoas disserem. Exceto que o próprio PO encaminhe para outra pessoa, o que adianto ser uma abertura para grandes problemas futuros, portanto evite que isto aconteça. Este é um cuidado fácil de se justificar, pois se o PO é o responsável por todo andamento do projeto dentro da empresa, é imprescindível que todas informações passem por ele e ao promover uma reunião da equipe de desenvolvimento com outro stakeholder, corre o risco de que os entendimentos sejam diferentes do planejado pelo PO.

Qualquer alteração do Product Backlog sugerida por outro stakeholder deve ser encaminhada ao PO e somente será efetivada se ele for convencido de que a alteração é justa e necessária. Em seguida o PO deve levantar os impactos consequentes e comunicar a equipe de desenvolvimento e gestores do projeto.

Como podem perceber, o PO é uma pessoa de extrema importância para o sucesso de um projeto no Scrum. Já participei de projetos onde um executivo foi contratado para exercer esta função e não deu certo. Por mais habilidoso e experiente que seja o executivo, não vai dar a dinâmica esperada para a empresa que implanta Scrum porque haverá um gasto de tempo para levantamento de requisitos, justamente porque o executivo que chega não conhece os processos e detalhes importantes a serem considerados no projeto.

Se vale dizer uma dica, então fica aqui a recomendação: sabe aquela pessoa que trabalha a anos na empresa e que muitas vezes está cuidando de uma série de assuntos burocráticos e pouco produtivos? Desde que ele compre a ideia de melhorar processos e produtividade, este será o seu melhor PO.

Entenderam agora por que eu não concordo com um profissional de TI exercendo o papel de PO? Esta pessoa não deve ter conhecimento de TI, mas precisa ter muito conhecimento e experiência dentro de cada setor envolvido no projeto para que tenha condições de elaborar uma proposta que realmente melhore os processos. Sabemos que o profissional de TI, muitas vezes por ter lidado com diversos projetos, “pensa” que já viu de tudo e “acha” que uma solução conhecida seja a solução desta empresa.

Pensem nisso quando decidirem implantar Scrum.

Publicado Originalmente em: Blog Andrey Kurka