Waterfall e papel do PO
Autor: Fred Belisario | Publicado: 2014-04-07T13:37:00-07:00


Todas &nbsp;as empresas, talvez não todas, mas muitas, as maiores, tradicionais e mais assertivas, compram software com o &nbsp;pensamento de criar um produto mas que possam se livrar ao máximo dos riscos inerente a um novo projeto. Lógico que todos fugimos, mas muitos pensam em mitigar riscos apenas fechando o escopo, tempo e custo. Como uma ciência exata.

Riscos sempre existirão, o objetivo é saber como e quando nos preocuparmos com ele. Seguindo o PMI, definiríamos os riscos no início do projeto, na longa fase de planejamento e nosso grande objetivo: mitiga-los.

Quando se compra projeto fechado o grande ganho quanto aos riscos está em diminuí-los, mitiga-los ou simplesmente delega-los para o contratado. Mas e quanto ao desperdício, como ficam? Qual a melhor forma de lucrar com um novo software que será construído?

Ainda hoje ouço meus clientes dizerem sobre saberem qual o escopo final do projeto, qual a data entrará em produção, meu dever é só saber o custo total do projeto, de todo o projeto, é claro. Não posso, não sou vidente ou mal-caráter a esse ponto.

Mesmo com todo o projeto, escopo x custo x tempo definidos, usarão desenvolvimento ágil.

Será que não conseguem entender que está tudo errado?

1- 50% de um software é raramente ou nunca utilizado, já abriu seu office hoje?





2 - 80% dos usuários do site da hp.com utilizam apenas 14% das funcionalidades do site.

3 -35% dos requisitos mudam durante um projeto. Isso se chama change request?

4 - 86% dos projetos que utilizam waterfall como método de desenvolvimento não obtém sucesso, 29% é falha total, sem change request para salva-los, dinheiro rasgado.




O risco se torna maior que apostar em opções da Petro no governo da Dilma.

Diferente de todos os processos que acompanham um projeto fechado, o Scrum consegue nos ajudar com apenas 9% de falha total de um projeto, é quase 1/3 do risco do waterfall. 42% de sucesso, sem contar que mudar o rumo de um backlog é dinâmico, fácil e rápido, sem necessidade de contratos adicionais.

O que vejo nestes anos não é a falta de confiança no método, é um pouco de não entendimento de agilidade, medo e problemas para se engajar, fica menos trabalhoso delegar tudo para alguém que assuma os riscos. É melhor não se mover e se envolver a fazer a empresa ganhar.

Poucos entendem como seria a ineficiência em somente vender desenvolvedores por homem-hora, atrasar projetos e cobrar horas-extras, não é sustentável a longo prazo. Uma empresa séria vai entregar o produto com qualidade, evitar desperdício e gorduras.

O importante para quem quer um bom projeto é usar o que os métodos ágeis irão oferecer, não só reuniões e entregas.

Utilize os papeis do Scrum.

Scrum Master, &nbsp;com experiencia, responsável em fazer que as práticas do Scrum sejam seguidas e funcionem.Suporta o time, PO e empresa quando necessário, muda a forma de trabalhar. Tem uma função similar a um GP, resolve problemas e impedimentos, mas junto com &nbsp;o time tem o objetivo de trazer valor

Valor este que é priorizado na visão do produto e do Product Owner. Responsável pelo produto, pelo software que será desenvolvido e entregue. O PO e responsável por priorizar os itens do backlog para que a visão do software seja alcançada. responsável por definir o que entra ou não em produção.

Time de desenvolvimento, é sua equipe de desenvolvimento, auto-gerenciável e deve possuir todos os perfis necessários para atingir o objetivo da Sprint. Todos que participem do desenvolvimento do projeto devem participar do time e participar dos rituais.

Todos os papeis são extremamente importantes para o sucesso do produto e gerar valor, gosto do papel do PO pois ele é o responsável pelo entendimento e destino do MVP, mas não é necessariamente uma figura da contratante e funciona bem:

Na própria empresa - Benefício de poder conhecer stakeholders fundamentais e o domínio do projeto, mas é necessário que tenha treinamento para isso.

Parte do time da consultoria - A consultoria que tenha expertise para o papel pode ajudar, mas, garanta que o PO esteja próximo aos 2 lados, devs e stakeholders. Já vi casos desastrosos de PO longe do head quarter.

Consultor Externo - Caso sua empresa não tenha alguém formado para isso, com perfil adequado, o consultor externo pode levar seu software ao lugar correto. É importante que tenha experiencia em desenvolvimento ágil e aumentando ainda o ROI, é muito interessante que conhece os conceitos e tenha trabalhado com metodologias do Lean Startup.

Para que o PO possa exercer o trabalho com a maestria esperada, é necessário dar a ele total autoridade sobre o projeto e esse seja uma única pessoa, é proibitivo desautoriza-lo.

Breve um pequeno case sobre o papel do PO.