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.

Uma das situações em que podemos identificar a ação do PO Proxy está ilustrada na figura anterior: 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.

* Simone Kunigami é Product Owner na GFT Brasil

Sobre a GFT

A GFT está impulsionando a transformação digital das empresas líderes mundiais nos setores financeiro e de seguros assim como na indústria de manufatura. Como provedora de serviços de TI e engenharia de software, a GFT oferece forte capacidade de consultoria e desenvolvimento em todos os aspectos das tecnologias pioneiras, como engenharia de nuvens, inteligência artificial, Internet das Coisas para a Indústria 4.0 e blockchain.

Com sua expertise tecnológica, profundo conhecimento de mercado e fortes parcerias, a GFT implementa soluções de TI escaláveis para aumentar a produtividade. Isso proporciona aos parceiros acesso mais rápido a novas aplicações de TI e a modelos de negócios inovadores, além de redução de riscos. No Brasil, a expertise em tecnologias exponenciais da GFT permite que seus clientes sejam lean-agile e lancem seus projetos digitais em um melhor time to market.

Fundada em 1987 e localizada em 15 países para garantir proximidade com seus clientes, a GFT emprega 5.900 pessoas. A GFT oferece aos seus colaboradores oportunidades de carreira em todas as áreas de engenharia e inovação de software. As ações da GFT Technologies SE está listada no segmento Prime Standard da Bolsa de Frankfurt.