Como um PO pode salvar ou destruir seu projeto
Autor: Fred Belisario | Publicado: 2014-04-11T13:09:00-07:00

O Product Owner é o dono, CEO, manda-chuva, o cargo máximo de um projeto. Ele é o responsável pelo caminho que o projeto irá seguir, responsável pela desenvolvimento e materialização da visão do projeto.

Mas é claro que nem todos pensam assim e muitos que estão &nbsp;hierarquicamente acima do PO gostam de "dar palpite" no seu trabalho.

Associando um pouco de desenvolvimento ágil com Lean ou seja, um método de desenvolvimento de software ágil com um método ágil de desenvolvimento de negócios e produtos.

O Product Owner pode levar seu produto à produção de uma forma rápida, diminuindo o custo, desperdício e maximizando o ROI, definir o MVP e operar o quento antes, esta ajuda quem pode dar é o PO.

Software em 30 dias, porque não negócios em 30 dias?

Porém o PO não pode ser apenas alguém da equipe de marketing, gerente de projetos, um bom desenvolvedor, o PO tem características pessoais, tem que ter empatia, entender o projeto, empresa, boas práticas e não ficar atrás de um computador como se o mundo encantado funcione normalmente. O PO tem que ser treinado e suportado, ter a vivência de bons e maus projetos, acreditar no produto e coloca-lo no ar, saber testar, mudar e adaptar.

O bom PO entende o que os early adopters querem e para onde o produto ou negócio devem ir.

Com 15 anos trabalhando com TI vi inúmeros projetos, muitos, mesmo "ágeis" chegam a um final não tão feliz, principalmente quando o PO ou POs não sabem para onde devem ir.

Tentarei exemplificar com dois cases, o bom PO e quando os POs não se entendem.

O Bom PO, colocando os stakeholders a par do que é o desenvolvimento ágil:

Em um lugar não tão distante, uma startup de comércio eletrônico com um enorme crescimento e aportes milionários, tem um dos sócios como peça fundamental do processo de desenvolvimento, com papel chave nas cobranças de prazo. Embora todo o time diga trabalhar com desenvolvimento ágil, não é bem assim que funcionam; Os projetos tem que ter prazo e escopo definidos, fechado pelos gerentes no início de cada Sprint, arbitrado, sem a participação do time de desenvolvimento.

É bem óbvio que isso não irá funcionar, apenas trará a ideia de que a equipe de desenvolvimento atrasou a entrega ou as custas de muitas horas extras.

Para este projeto deveríamos entregar apps mobile, iOS e Android, simples assim. Mas o bom PO foi além. A visão do projeto foi entregue, continua a crescer mais e mais, mas sempre respeitando os conceitos de agilidade, lean e respeitando o time.

A história é muito boa para a consultoria, a primeira tentativa de vender um produto para criar os canais iOS e Android não foi bem finalizada, um produto para ser adaptado a loja virtual mais a API de integração sairia caro comparada ao desenvolvimento na Índia.
Não julgando a qualidade da decisão, esta primeira versão, com um projeto fechado se mostrou inexequível após entregue, difícil de usar, manter e adaptar.

A versão 2 veio através do desenvolvimento na Europa, em um centro de "excelência" da investidora. versão 2 com &nbsp;bugs na primeira semana se tornou enviável lança-lo.

A versão 3 foi desenvolvida com meu time, para isso construímos o time com:

1 PO
2 devs
1 design



Com 2 meses já havia um release em produção ( incluído os 15 dias da Apple) sem bugs conhecidos e iniciando a aquisição de leads.

Mas como lançamos um produto maduro em 2 meses?

A primeira interação do time com o gerente de projetos e sócios da empresa foi: - tem que estar pronto no dia X.
Como um bom time ágil, quem pode dizer quando estará proto é o time, as funcionalidades a entrar é o PO e a partir daí vamos entrar em produção. Com os stakeholders já ciente como seria o desenvolvimento e com as features e requisitos que não agregam valor retirados, &nbsp;time capaz e sênior, já acostumados às práticas ágeis, o produto entrou em produção antes do esperado, com menor custo e adiantamento do ROI.

Hoje a equipe mobile está migrando para o cliente com desenvolvedores contratados, mas treinados nas práticas ágeis.


E porquê não um&nbsp;PO a ser treinado, sem mandato e sem entendimento de produtos digitais e o coach que nada sabia do que fazer pode atrapalhar tudo?

Um projeto com um dos maiores bancos do Brasil, tudo voltado para utilização do lean, com 1 problema, ocupava a pasta de 2 superintendências, TI e MKT. Todos falavam lean, queriam lean, eram "produteiros" que queriam levar o lean para uma grande instituição.
Contrataram uma consultoria especializada em lean.
Só esqueceram de definir quem realmente manda no projeto. Quem é o PO.
Esqueceram não, definiram 1 de TI, 1 de marketing e um coach que pouco apareceu.
Junto a isso haviam 2 superintendentes, o de TI sempre foi o melhor guiado, sabia como e onde chegar, mas marketing não ajudou muito.

Além de 2 POs mais o "coach" havia mando e desmando, verba para marketing do produto que não apareceu ou qualquer outra maneira.

Foram traçadas inúmeras brigas para o bem do produto ate sair, umas certas, outras erradas, mas sempre confusas, alguns erros, só o começo.



Muitos POs
Um coach de PO preocupado com outros assuntos
Stakeholders sem poder na instituição
Stakeholder que quer ter o poder total no produto, mas não quer ser o PO.


Em que isso culminou: Um belo final de tarde após o primeiro release ser lançado, ainda no escritório, um dos devs vem a mim dizer:&nbsp;

- A PO do marketing quer que tire a aplicação do ar. Ao ver o chat leio: vamos todos ser mandados embora.



Na sala com o dev tinha o coach de PO, impassível como se nada houvesse acontecido.O SM não estava e o dev desesperado sem saber o que fazer. Agora tem o outro PO, de TI, esse estava de férias.



Mas o que está acontecendo? Ficou evidente a falta de poder do PO quando desesperadamente pediu pra tirar um sistema do ar, o coach não se aprontou ou não sabia ajudar, o superintendente de marketing desaparece e o gerente comercial tem que intervir para entender o que está havendo. Sobrou uma pessoa para ajudar, o superintendente de TI, o único que entende a merda que está se formando que assumiu a propriedade do assunto, disse não e se mostrou o verdadeiro product owner, mas sem o papel de product owner.





O que esperamos para o bom papel de um PO:


Empowerment;
Entender a visão produto;
Entender o que é o método;
Vontade de faze-lo