menu

Ajude o PO a ser um profissional melhor

Por

Muitos artigos discutem o papel de cada personagem dentro de uma estrutura ágil. Um deles é o de Product Owner (PO), que de modo geral é o responsável por priorizar o backlog, tirar dúvidas de negócio com o time de desenvolvimento, garantir que as entregas tenham o maior valor possível para o produto e, às vezes, escrever histórias de usuário.

No dia a dia, colocar essas responsabilidades em prática não é tão simples. Além de cursos e livros que ajudam a fixar esses conceitos, nada melhor que o feedback constante da equipe para que os papeis se ajustem. Quanto melhor o relacionamento e o diálogo entre os integrantes, mais fácil será manter o projeto no rumo certo.

Especificamente no caso do PO, algumas atitudes simples da equipe podem ajudá-lo a exercer bem seu papel:

1. Deixe claro o tamanho do esforço que uma determinada tarefa exige

Algumas vezes o PO não tem background técnico e palavras como “Capistrano”, “Mongo” e “Jenkins” podem ser assustadoras. Quando for explicar o esforço que uma história exige, o ideal é evitar o tecniquês, comparar a história atual com alguma que já tenha sido entregue e ter certeza de que todos estão cientes do tamanho da tarefa. Isso ajuda a alinhar as expectativas.

2. Diga quando as histórias estão incompletas

Se o PO se reunir com parte do time de desenvolvimento para analisar uma história, esse problema será minimizado, mas ainda corre o risco de acontecer. Na hora de colocar a mão na massa, se alguém notar que algum cenário ficou descoberto ou que a forma não está clara, não pense duas vezes antes de mostrar os pontos que o incomodam.

No caso do cenário, o PO vai aprender e levar mais pontos em consideração na próxima vez. Já no caso do formato, uma história eficiente é aquela que expõe todos os pontos relevantes para o negócio e dá todas as informações necessárias ao desenvolvimento. Se o modelo atual não funciona, proponha outro 😉

3. Não concorda com a priorização? Fale

É comum isso acontecer e se os argumentos para contestar a priorização forem bons, não será difícil convencer o PO a, pelo menos, repensar. É bem mais produtivo expor sua opinião e conversar sobre o assunto que executar uma tarefa com a sensação de estar no caminho errado.

4. Conheça seu produto

Trabalha em um site de e-commerce? Compre alguma coisa (nem que tenha que cancelar a compra em seguida) e veja se o processo é fácil. Desenvolve um aplicativo? Tenha o app no seu celular ou tablet e tente usá-lo. É intuitivo? Entrega o que você procura? Repasse aos amigos, às pessoas que você sabe que gostam do tema e reúna os feedbacks. A ideia não é trabalhar 24h por dia, mas usar seu produto sempre que houver uma chance.
Levar ao PO as opiniões de usuários (a sua também conta) tem grande peso na hora de determinar os próximos passos.

Não se esqueça de que todos são responsáveis pelo sucesso do projeto e essas dicas podem ajudar na construção de um produto melhor e, de quebra, auxiliar o desenvolvimento profissional do PO.

Você concorda com essas dicas? Quer adicionar mais alguma? Deixe seu comentário.

8 comments

  1. André Faria Gomes

    Muito bom seu artigo, Bruna.

    Parabéns!

    Abraços.

    Posted on setembro 6, 2013
    • Bruna Gomes

      Obrigada, André! =D

      Posted on setembro 6, 2013
  2. Guilherme Massa

    Bruna, excelente! Gostei especialmente dos itens 1 e 4. O 1º porque entendo que ele é chave para construir confiança, além de ser obrigação do time se explicar quanto ao esforço de uma tarefa; do contrário, o PO fica com a mesma sensação de quando vamos consertar algo no carro e o mecânico fala da rebimboca da parafuseta e você só pensa “tá me enrolando pra eu pagar mais caro”, ou seja, o oposto da confiança. O 4º item porque é comum pra caramba ver gente trabalhar num produto ou serviço e não usá-lo/usar outros semelhantes, o que inevitavelmente gera um gap de entendimento sobre os clientes.

    Posted on setembro 9, 2013
    • Bruna Gomes

      Adorei a comparação com o mecânico! É bem essa a sensação mesmo. Obrigada pelo comentário 😉

      Posted on setembro 10, 2013
  3. Rafael Rossi

    Muito Bom o texto Bruna! Compartilhei com o time. É legal a forma que coloca que o PO nem sempre tem um background técnico e em alguns caso isso prejudica a priorização, pois o time (técnico) enxerga esta deficiência e muitas vezes dificulta a vida do PO.

    Posted on setembro 9, 2013
    • Bruna Gomes

      Espero que o texto ajude, Rafael! Obrigada.

      Posted on setembro 10, 2013
  4. Fred

    Concordo com todos os itens, especialmente com os dois últimos. Acho que a equipe de desenvolvimento sempre tem muito a contribuir pois ela é formada por pessoas antenadas e normalmente “hard users”.

    Excelente artigo Bruna, parabéns.

    Posted on setembro 10, 2013
  5. Bruna Gomes

    Obrigada, Fred!

    Posted on setembro 11, 2013

Leave your reply

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Go to top