PO Proxy: como melhorar a contribuição para o projeto?

O Product Owner é um dos papéis fundamentais no Scrum, por ser o membro do time responsável por maximizar o valor do produto resultante do trabalho do time de desenvolvimento (ROI). Ele tem a responsabilidade de expressar uma visão clara do que se deseja construir, estabelecendo procedimentos e etapas necessárias ao desenvolvimento do produto. É a pessoa que gerencia o Product Backlog (uma lista contendo todas as funcionalidades desejadas para um produto), aponta prioridades, altera listas e garante o gerenciamento do escopo e checagem de entregas. O PO direciona o esforço da equipe de uma maneira eficiente para que as expectativas dos clientes sejam atendidas.
Em muitos projetos, porém, encontramos “PO Proxy”, profissional que realiza grande parte das mesmas atividades de um PO, embora normalmente não seja o “dono” do produto. Ou seja, não pode tomar as decisões principais nem controlar o budget. O Proxy auxilia o PO “principal” no que for necessário, atuando como um intermediário entre as pessoas que tomam decisões sobre o produto e os desenvolvedores. E por que faz sentido a existência desta função, que não segue exatamente o padrão de times ágeis ideais? Alguns cenários em que podemos encontrar um PO Proxy:
• O tempo é curto: o PO precisa ter tempo de estar em contato com o time, participar de reuniões, negociar com stakeholders, gerenciar as características e prioridades do produto. O PO Proxy vai ajudar provendo ao time de desenvolvimento os requerimentos refinados, discutindo dúvidas e participando das reuniões, ajudando a eliminar qualquer mal-entendido;
• Quando o cliente não está muito familiarizado com metodologias ágeis: o PO proxy pode auxiliar para que o PO (normalmente alguém da área de negócios) siga os princípios ágeis na condução de um projeto de sucesso. Ele(a) ajuda o PO a entender as necessidades, os desafios técnicos do time e as realidades de um desenvolvimento;
• Quando o time de desenvolvimento é remoto: por estar longe do time, não será possível para o PO participar das cerimônias, conhecer as pessoas da equipe nem estar sempre à disposição para debates e discussões. O Proxy será responsável por fazer essa “ponte”, estabelecendo um relação de proximidade com o time e dando rapidez a todo esse processo.
• Em projetos envolvendo diversas culturas: primeiro, há a questão dos diferentes fuso-horários, que muitas vezes impede que o PO esteja sempre disponível para a equipe. Além disso, quando há diferentes culturas envolvidas, o Proxy conversará de maneira eficaz com os POs, preparado para constatar diferenças.
Fonte da imagem: http://www.scrum.org/resources/blog/what-proxy-product-owner-why-it-found-so-often
Uma das situações em que podemos identificar a ação do PO Proxy: a área de business (normalmente no cliente) possui o Product Owner, e o Scrum Team conta com um PO Proxy que trabalha próximo ao time de desenvolvimento. Outro cenário bem comum é quando o cliente tem um PO, e a empresa de consultoria possui um PO Proxy atuando em seus projetos.
Assim, sendo um PO Proxy, você pode se perguntar: como posso contribuir mais com meu projeto, se não consigo dar a última palavra em relação ao produto?
Primeiro, se certificando de que todas as necessidades que o PO reporta estejam realmente claras. Afinal, o produto será construído por meio do seu entendimento e das histórias que muitas vezes serão escritas por você. É importante ter todas as dúvidas respondidas, além de sugerir soluções ao cliente. Afinal, a ideia que ele(a) tem nem sempre pode ser a melhor, a mais viável ou a que apresente a melhor experiência de usuário.
Vale a pena também trabalhar o mais próximo possível ao time de desenvolvimento. Preparar protótipos de soluções, entender a viabilidade e a complexidade técnica dos requisitos e assim discutir sobre as dificuldades e impedimentos levantados pelos desenvolvedores.
Outra situação que o PO Proxy deve atuar é no estabelecimento de um DoR (Definition of Ready) bem claro para que todos possam facilmente entender. Ou seja, garantir a qualidade das histórias que estão entrando na sprint, prontas para serem implementadas. Alguns exemplos: histórias devem estar escritas no formato 3Ws; critérios de aceite devem estar definidos e entendidos pelo time; histórias devem estar estimadas; as dependências devem ter sido identificadas etc.
Outro ponto bem interessante é conhecer o negócio, não somente o funcional do produto. Enfim, quem usa a aplicação que está sendo desenvolvida? Para que é usada? Qual o benefício de cada um dos incrementos para o cliente? Entender tudo isso faz com que você tenha mais autonomia em sugerir, opinar, e, inclusive, em pré-aprovar o produto antes da validação final do cliente, evitando muitos imprevistos e minimizando a quantidade de bugs.
Sempre que possível, também é válido trabalhar junto ao time de testes, por exemplo, empregando o BDD (Behaviour Driven Development), que é o desenvolvimento orientado por comportamento. É uma iniciativa que melhora a comunicação do time e promove a integração das regras de negócio com a linguagem de programação. Isso permite que o foco seja no porquê da criação do código, e não somente no desenvolvimento da tarefa em si.
Por todas essas possibilidades, entender e considerar o contexto de cada projeto é super importante para estabelecer um outro nível de entrega, garantindo desde interações qualificadas e de conteúdo com o time até produtos que ofereçam, efetivamente, valor para os clientes.
Por Simone Kunigami, Product Owner na GFT Brasil