O mundo gira sem parar e, para acompanhar a evolução, as empresas (em especial agências digitais) vivem em constante estado de mudança.
De um modo geral, percebemos que em ambientes ligados a projetos de tecnologia os desafios são muitos (já falamos sobre eles aqui), principalmente quando falamos de cultura e gestão de planejamento em projetos dinâmicos.
Neste contexto, profissionais buscam incansavelmente testar, em startups e organizações, metodologias e práticas diversas de gestão de projetos em prol de melhores resultados. Não é fácil, mas é importante experimentar.
Alguns gestores tem o guia do PMBOK como “bíblia”, o que muitas vezes gera um impasse com aqueles apaixonados por metodologia ágeis, como o Scrum.
Uma adaptativa que seguimos há alguns anos aplicando sob múltiplos projetos digitais é um modelo com mix de boas práticas PMBOK + Scrum.
O PMBOK (Project Management Body of Knowledge) é o guia das melhores práticas de gerenciamento de projetos, amplamente reconhecido e suportado pelo PMI (Project Management Institute), instituição respeitada no mundo inteiro.
O outro guia é o framework Scrum, bastante conhecido em projetos de produção de softwares comerciais, de websites como é caso da Apiki – uma empresa de tecnologia especializada em WordPress – softwares de aplicativos para dispositivos móveis, softwares financeiros, jogos, etc.
Você utiliza PMBOK ou Scrum na gestão de seus projetos digitais?
Tweet
O PMI não dita ou prescreve a metodologia e sim as melhores práticas. Então, nesse caso, seria possível pensar na oportunidade de mesclá-lo aos métodos ágeis?
Sim, claro! Método Ágil tem uma forte ligação com projetos com grande indícios de mudanças, mas tem carência de alguns processos que são presentes no PMBOK, atual 6ª edição, e que introduz às práticas Agile.
Os métodos ágeis têm como principais características as frequentes interações do cliente e grande flexibilidade. São muito usados em projetos digitais e proporcionam práticas adaptativas.
Segue abaixo um modelo simplificado:
| 1. Iniciação | 2. Planejamento |
| 1.1 Crie a TAP junto com seu cliente | 2.1 Colete os requisitos |
| 1.2 Faça uma reunião de kick-off | 2.2 Crie a EAP |
| 1.3 Identifique os stakeholders | 2.3 Crie histórias ou dicionário do EAP |
| 1.4 Registre papéis e responsabilidades | 2.4 Identificação e mitigação dos riscos |
| 2.5 Elabore o cronograma | |
| 2.6 Alinhe a gestão de comunicação |
| 3. Execução | 4. Monitoramento e Controle | 5. Encerramento |
| 3.1 Faça o Scrum acontecer | 4.1 Gestão de Mudanças | 5.1 Entrega/ Aceite final com o cliente |
| 4.2 Atualização de documentos | 5.2 Lições aprendidas e desmobilização |
1.1 Documento inicial é básico para projetos complexos e muito grandes, devem ser separados por fases.
Ajuda a manter o foco do projeto na necessidade do cliente e Product Owner. Esta etapa sugestivo o Termo de Abertura do Projeto TAP.
1.2 Reunião de abertura na qual sugere validação da TAP junto às principais partes interessadas, assim como identificação de demais envolvidos as fases. Ajuda a manter o foco do projeto na necessidade do cliente e Product Owner.
1.3 Pessoas, grupos e organizações que estão ativamente envolvidos ou então, cujos interesses possam ser afetados de forma positiva ou negativa como resultado de execução ou conclusão do projeto.
1.4 Apresenta a equipe Scrum neste momento é fundamental e explicar a importância e dos papéis e interação de cada para o sucesso dos Sprints do projeto.
2.1 Em projetos digitais as mudanças são ocorridas com mais frequência, é primordial buscar entendimento sob objetivo do projeto, muitas vezes nem o cliente sabe o que de fato precisa, né! Refine os requisitos sempre a cada ciclo de Sprint.
2.2 O ciclo de vida do projeto possui conjunto de fases tendo escopo e prazo entre os principais desafios de gestão agile e afeta direto na qualidade do produto. Um processo PMBOK de apoio ao Scrum é o EAP (Estrutura Analítica do Projeto).
2.3 Utilização de histórias (User Story), é um processo mais prático e focado aos incrementos e funcionalidades previstas, mas pode ser melhor adaptado junto ao Dicionário do EAP (PMBOK). Exemplo, definir critério de aceitação dos incrementos.
2.4 A identificação dos riscos ocorrem com muita frequência na fase de desenvolvimento dos incrementos e funcionalidades, no Scrum muitas vezes durante as interações dos Sprints.
A matriz planejamento de riscos PMBOK ajuda.
2.5 Processo muito importante do PMBOK, indicado e pode ser adaptado em ambientes Scrum e Agile. Normalmente é requisito em qualquer tamanho de projeto.
2.6 Muitas das vezes os P.O. e/ou GP não conseguem aplicar o processo com eficiência, seja por limitação de tempo a outras atribuições, dificuldades no entendimento de requisitos, ou mesmo não dar importância. Interações são cruciais.
3.1 Use os eventos e cerimônias, ou ajuste o framework a realidade do negócio.
4.1 Embora um entre os doze princípios do Manifesto Ágil deixar uma mensagem clara que mudanças são bem vindas no Scrum, é interessante um controle mínimo no plano do projeto. Um descuido pode fracassar tudo, pense nisso.
4.2 Agende as rotinas de acompanhamentos e atualizações dos processos, como EAP, cronograma, riscos, etc. E quando necessário, faça retroplanning. Seja claro!
5.1 Realize o processo em três situações: quando o Backlog do Projeto foi totalmente completado e desenvolvido; quando o cliente expressa que os incrementos já entregues do Backlog do Projeto atendem a sua expectativa inicial do produto e que pode finalizar o projeto; ou quando o projeto tem o término antecipado, por algum motivo particular.
5.2 Crie um banco de dados de registro das lições aprendidas, das retrospectivas de Sprints e fase final. Faz a diferença no futuro em projetos similares e complexos.
Está aí um pouco da minha vivência liderando projetos na Apiki. Espero ter ajudado!
