(Praia de Cabanas, Portugal) Muito já foi escrito neste blog sobre as vantagens da metodologia Agile. A verdade é que, no momento em que uma organização decide iniciar uma Transformação Agile, particularmente, adoptar a prática do Scrum, educar recursos pode ser um desafio aterrorizante. A experiência necessária para uma função de Scrum Master ou Product Owner, é muito diferente do que normalmente se encontra num recurso experiente atuando como gestor de projectos Waterfall.
O background de um gestor de projecto Waterfall
Em Waterfall, o principal objetivo de um gestor de projecto é entregar o projecto dentro do tempo, orçamento e qualidade previamente acordados. O projecto Waterfall segue um processo sequencial em V, partindo da fase de requisitos, e seguindo para desenvolvimento, testes, treinamento, suporte e manutenção. O gestor de projecto tem um papel de facilitador, organizando todos os recursos necessários, condições e materiais, respeitando o roadmap acordado, informando os stakeholders e sponsors do projecto, atenuando os riscos, se necessário, e desenvolvendo planos de contingência. Ele sente-se mais comprometido com o “fazer acontecer” do que com “o que é entregue”.
Eu já ouvi na minha carreira gestores de projecto Waterfall dizerem com algum orgulho: “Eu fiz um projecto SAP sem nunca ter aberto uma aplicacao SAP”. Para mim isto é completamente inconcebível…
Um gestor de projecto de Waterfall tem uma perspectiva de comprometimento temporário: ele está de passagem até ao lançamento do projecto, depois parte para outro projecto. Esta é a abordagem do projecto e não a abordagem do produto. Na abordagem do produto, temos um compromisso de longo prazo e um compromisso com o valor a ser entregue permanentemente ao cliente.
O gestor de projectos Waterfall tem o seu foco em satisfazer sponsors e stakeholders: entrega no tempo certo, escopo, orçamento e qualidade. Não observamos aqui um papel importante para usuários/utilizadores e clientes. Usuários e clientes são levados em consideração em 2 momentos diferentes:
- 1º momento: durante a fase de requisitos.
- 2º momento: durante testes, validação e aceitação do projecto, treinamento e suporte.
Neste segundo momento, os usuários/utilizadores ou clientes estão expostos a uma versão completa do produto, a um conjunto de funcionalidades. O feedback coletado é acumulado e não tão detalhado funcionalidade por funcionalidade, como no fundo se faz a cada Sprint Review.
Tenha em mente, em Waterdall, a presença do gestor de projecto nesses 2 momentos de interaçao não é obrigatória. Essas tarefas geralmente são delegadas a especialistas, nao havendo obrigatoriamente contribuição directa por parte do gestor de projecto.
Outras tarefas normalmente não consideradas pelo gestor de projectos Waterfall: retrospectiva e melhoria continua. O gestor do projecto Waterfall normalmente não organiza reuniões retrospectivas com a equipe de desenvolvimento, ele não sente como sua a responsabilidade a satisfação, a gestao de capacidade e velocidade da equipe. Tal como também não sente como sua responsabilidade ter uma atitude permanente de procurar a melhoria em tudo o que está relacionado com o produto, equipa e processos.
Qual a razao para que a experiência do gestor de projectos Waterfall não traga tanto valor para a prática Agile
Os tipos de competencias e experiências que desenvolve um gestor de projecto Waterfall sao normalmente as seguintes:
- Identifica recursos especializados necessários para executar tarefas de projecto;
- Guarda e atualiza orçamento e Roadmap;
- Regularmente requer atualizações sobre estado, riscos e dependências da equipe de implementação e resume-os em reuniões de direção para sponsors e stakeholders;
- Organiza o escalonamento de assuntos se necessário;
- Competencias de comunicação e negociação são fundamentais: Organiza reuniões e modera discussoes em diferentes níveis hierárquicos: a nível inferior com especialistas, de nível superior para atualização executiva e escalonamento de problemas.
Essas competencias são apreciadas em qualquer projecto, mas em Agile as equipes e as funcoes estao organizadas de uma forma diferente e parte das tarefas descritas acima são distribuídas por diferentes funcoes.
Uma equipe Agile é autoorganizada, cada membro da equipe conhece sua área de especialização e assume responsabilidade de implementacao voluntariamente sobre as stories ou tarefas que acredita ser competente para se comprometer com a entrega. Com o tempo, a equipe geralmente seleciona “naturalmente” quem é o expert no que: quem é o test manager, o arquitecto, o programador backend, etc.
A atribuição de stories é feita pelo Scrum Master ou por cada membro da equipe, reconhecendo suas áreas de especialização individuais, assumindo espontaneamente sua própria responsabilidade.
Escalonamento, mitigação de riscos e o desbloqueio de impedimentos é uma tarefa Scrum Master. Mas é também tarefa do Scrum Master, procurar a melhoria continua de desempenho, motivação e satisfação da equipe, o que nunca observamos num gestor de projecto Waterfall.
O Product Owner traz a visão do produto, funcionalidades, é a voz do cliente. Tráz essencialmente requisitos, comprometimento para construir o melhor produto, consolidando a estratégia em valor para o cliente.
Como podem ver, esta é uma mudanca radical de mindset entre os actores da metodologia Waterfall e Agile mas, essencialmente, trata-se de um grande desafio para um gestor do projecto da Waterfall especializar-se tecnicamente e comprometer-se com o produto e os utilizadores mais do que com os stackholders.
