Product Owner, o PM do agile?

Um dos grandes desafios em uma transição de ambientes tradicionais para um ambiente ágil é o mapeamento de cargos. Na verdade, um dos primeiros impulsos dos profissionais é perguntar “e agora, eu virei o quê?”, questionando justamente qual será o novo cargo a ocupar após a transformação. E essa não é uma pergunta cuja resposta está em uma alteração dos títulos, e assunto resolvido, existem muitos detalhes a serem levados em consideração e esse mapeamento nunca é binário (se você é X vai passar a ser Y).

Os cargos técnicos geralmente são os mais fáceis de serem mapeados, um developer continua sendo developer, um designer continua sendo designer, e assim por diante. Porém, quando lidamos com cargos mais estratégicos, essa resposta fica cada vez menos direta e um dos grandes impasses acontecem quando lidamos com o cargo de Project Manager (PM) ou Gerente de Projetos, que geralmente é mapeado de forma arbitrária como um Product Owner (PO).

Para começar a entender esse movimento, vamos entender os termos que compõem os dois cargos, e no final quero apresentar minha abordagem quando falamos de mudança de cargos tradicionais para “cargos agile”.

Ownership vs Management

O cargo de Project Manager contém a palavra “manager” no seu título, que é traduzido como “gerente”. De acordo com o Project Management Institute (PMI) “o conhecimento em gerenciamento de projetos baseia-se em dez áreas: Integração; Escopo; Tempo; Custo; Qualidade; Compras; Recursos humanos; Comunicações; Gerenciamento de riscos; Gerenciamento de partes interessadas (stakeholders)”

Vemos então que um Gerente de Projetos tem uma responsabilidade do início ao fim dentro de um projeto, gerenciando de forma literal diversas áreas que compõem um projeto, e tendo dentro das suas atribuições responsabilidades múltiplas, e muitas vezes multidisciplinares, que variam de análise de requisitos, até mesmo gestão de stakeholder e recursos humanos.

Quando entendemos a palavra “gerenciar” vemos que ela compõe os atos de dirigir, gerir, comandar ou administrar, nesse nosso contexto, essas dez áreas de um projeto, entendendo assim que um PM é uma função estratégica central dentro de times tradicionais e é uma função-chave para garantir o sucesso de um projeto.

Quando olhamos para a definição de um Product Owner ou “dono do produto” vemos a seguinte definição pela International Consortium of Agile (ICAgile) “… concentra-se na entrega […] orientada a valor, na mentalidade que o acompanha e nas principais práticas ágeis projetadas para enfatizar o valor do cliente. Ele também procura criar ambientes organizacionais e de equipe, propícios à colaboração frequente e transparente entre as equipes de negócios e desenvolvimento.”

Aqui entendemos que o PO se foca na entrega de valor, relacionamento com as partes interessadas (stakeholders) e também na comunicação deles para com o time de desenvolvimento. Assim, seu foco é voltado ao produto, sendo ele o representante do dono desse produto (cliente) dentro do time ágil.

Dessa forma, o termo “ownership”, que não tem uma tradução literal para português a não ser “sentimento de dono”, exemplifica que o PO é a pessoa com o “sentimento de dono” dentro da equipe que vai desenvolver o produto ou solução contratados.

Só de entender os termos e definições dos cargos conseguimos ver algumas correlações, como por exemplo o relacionamento com os stakeholders e a entrega de valor ao cliente. Porém muitas responsabilidades presentes dentro do cargo de PM, não são descritas no cargo de PO. Além disso, existe uma grande diferença entre gerenciamento e ownership, mesmo quando lidamos com esses aspectos em comum.

Single point of failure

Fica claro aqui que a transformação de PM’s em PO’s binariamente não satisfaz todas as atribuições de um PM, questões ligadas a tempo, recursos humanos e até mesmo compras, ficam faltando se transformarmos todos os PM’s em PO’s.

Os métodos ágeis entendem que existem muitas atribuições em um único cargo, deixando assim os PM’s muitas vezes sobrecarregados e até mesmo transformando-os em um single point of failure, ou ponto único de falha, dentro de um projeto. Deixar tantas atribuições na mão de um único cargo levanta um risco de quem, se a pessoa que exerce esse cargo falha, coloca em risco toda a cadeia em que ele está envolvido.

Dessa forma, dentro de ambientes ágeis, as responsabilidades de um Project Manager são diluídas em diversos outros cargos, distribuindo assim as responsabilidades e reduzindo o risco de falha de um projeto.

Enquanto um Product Owner tem a responsabilidade de comunicar para a produção o que deve ser feito, a qualidade é inerente ao time de desenvolvimento. Enquanto um Product Owner é responsável pelo gerenciamento de custo, o gerenciamento de tempo fica a cargo da equipe. O acompanhamento e suporte, criação de ambiente que promova a produtividade, isso fica a cardo da liderança ágil (seja um Scrum Master, Iteration Manager, Service Delivery Manager, Team Lead…).

Dessa forma, um Project Manager que atua mais nas fases iniciais de um projeto, levantando requisitos, estimando custos e prazos pode sim, talvez ser transicionado para um Product Owner, agora se ele é um PM que se identifica mais no acompanhamento do projeto e apoio ao time de produção, talvez o cargo de PO não seja o ideal, mas sim um cargo de liderança ágil. Assim como um PM que tenha maior habilidade em apoio técnico ao time, garantindo a qualidade dos entregáveis, ele pode facilmente ser mapeado como um membro da equipe ágil, as vezes como analista ou especialista de qualidade.

Todos esses exemplos são genéricos para ilustrar que um Project Manager pode assumir diversas responsabilidades dentro de um time ágil de acordo com seu foco de atuação ou preferência de trabalho, sendo que cada caso deve ser cuidadosamente estudado junto do próprio profissional e sua liderança, para que a transformação ágil não prejudique seus planos de carreira, e continue a agregar valor de negócio para a empresa e clientes.

Gerenciamento de mudanças

Toda a discussão que gira em torno de mapeamento dos cargos em uma transformação ágil é importante e necessária, porém eu questiono o momento em que ela deve acontecer, e nas minhas abordagens de transformação ágil eu deixo a mudança de cargos para o final da transformação, isso por um único motivo: gerenciamento de resistências.

Qualquer mudança gera resistências, quando estamos em uma zona confortável e se algo ou alguém nos tira desse conforto, tendemos a resistir a menos que tenhamos um momento ou justificativa forte o bastante que motive essa transformação. E um dos pontos que mais gera desconforto e consequentemente resistências é a autoimagem.

Todos nós temos e construímos naturalmente uma imagem que nos representa, seja ela um grupo, um cargo ou até mesmo uma certificação.

Quando vamos conhecer os profissionais que farão parte da transformação ágil e perguntamos “quem é você?”, dentro dessa resposta temos ótimas dicas de sua autoimagem, e geralmente a resposta que vem está atrelada ao seu cargo ou à alguma certificação que carrega, por exemplo “sou o PM do projeto” ou “Administrador de Banco de Dados certificado Oracle”… Nós passamos anos da nossa vida construindo essa imagem, e do dia para a noite alguém dizer que essa imagem não mais representa suas atribuições é como se eu desconsiderasse sua história dizendo que ela não é mais importante. É como se eu falasse “ok, seu certificado PMP não serve mais, pode jogar fora”, sem levar em conta todo o esforço e dedicação que esse profissional teve para conquistá-lo.

Dessa forma, seja você o cargo que for, mantenha-o, e adapte suas atribuições e áreas de atuação, no futuro, depois de já ter criado um ambiente que justifique essa mudança de cargo, depois dos profissionais terem absorvidos suas adaptações de responsabilidade, aí sim podemos discutir qual é o melhor título que representa suas atribuições.

Afinal de contas, não é o título que garante o sucesso de suas atividades, e sim seu profissionalismo, seja você chamado de Project Manager, Product Owner ou qualquer quer seja o título do seu cargo.