O que é preciso para gerenciar projetos híbridos

Gerenciamento de projetos híbridos parece ser uma expressão emergente.

Na verdade eu não concordo muito com isso até porque ela foi cunhada por Peter Keen¹ em meados de 1980, e como citada por Michael Earl:

“A person with strong technical skills and adequate business knowledge or vice versa …. hybrids are people with technical skills able to work in user areas doing a line job, but adept at developing and implementing IT application ideas”

O fato é que desde 2018 tenho ouvido que é necessário se tornar mais ágil, que o “Gerente de projetos vai morrer” e que tudo será realizado em prol do ágil ou do híbrido.

Hoje em 2020 já escuto também sobre A Morte do Gerente, do Testador e do Analista Funcional².

Em essência, meu entendimento é que ele se refere a uma combinação de abordagens ágeis e em cascata, ambas com seus méritos, mas nenhuma das quais fornece necessariamente uma solução de 100% como uma abordagem para gerenciar um projeto em particular.

Vamos investigar!

Um pouco sobre Agile

Agile é sobre ser flexível – e sobre a entrega de resultados tangíveis. É também sobre empoderamento – onde o trabalho está sendo feito.

Aqui estão alguns pontos importantes sobre o agile e algumas fontes importantes para mais informações:

1. O Manifesto Ágil³ é o melhor ponto de partida para compreender a essência da agilidade – que é enfatizar “indivíduos e interações sobre processos e ferramentas, trabalhando com documentação abrangente, colaboração do cliente sobre negociação de contrato e respondendo a mudanças seguindo um plano”.
2. A Projetos e TI vem melhorando cada dia mais a categoria Agile, com artigos bem escritos dá uma conferida.
3. A Wikipedia USA sobre “ gerenciamento ágil ” enfatiza as ideias de projetar e construir “incrementalmente” e de “maneira altamente flexível e interativa”. Ele ainda mais detalha que “Requer indivíduos capacitados do negócio relevante, abertura para entrada consistente do cliente e gerenciamento abertura a formas não hierárquicas de liderança ”.

Um pouco sobre Cascata

Waterfall é sobre ser mais rígido no começo e durante todo o processo – e sobre o planejamento sequencial de tudo o que deve ser entregue, e entregar tudo o que foi planejado.

Trata-se de descrever bem todos os requisitos – e especificar exatamente o que deve ser feito por aqueles que o farão.

Aqui estão alguns pontos importantes sobre a cascata e algumas fontes importantes para mais informações:

1. Winston Royce é geralmente creditado como originário do método cascata para desenvolvimento de software através de um artigo que ele escreveu em 1970 intitulado “Gerenciando o desenvolvimento de grandes sistemas de software .” Royce especificou cinco etapas principais para gerenciar um projeto e curiosamente também recomendou cinco coisas de ágil natureza que reduziria a maioria dos riscos inerentes ao método da cascata.
2. O Microsoft Project, na maior parte, suporta o gerenciamento de projetos em cascata.
3. A Wikipedia USA sobre o “ Waterfall ” descreve-o como um método “no qual o progresso é visto como fluindo para baixo (como uma cachoeira) através das fases de concepção, iniciação, análise, projeto, construção, teste, produção / implementação e manutenção”. Ele também observa que o modelo em cascata é uma adaptação da indústria pesada, onde a mudança é extremamente cara e impraticável.

Agile + Waterfall = Gerenciamento Híbrido

Então, de onde veio esse termo “gerenciamento de projetos híbridos”, e o que isso realmente significa? (Vamos entender o porque é importante mais tarde …)

Logicamente, veio da ideia de que existem méritos e falhas tanto no ágil quanto no cascata, e que alguma combinação híbrida é necessária para fornecer o melhor de cada um de forma equilibrada.

Eu diria que praticamente todos os projetos são híbridos – que realmente não existe um Waterfall puro ou um projeto explicitamente ágil.

Na realidade, é apenas uma questão de grau: quanto ágil e cascata empregar no projeto em particular.

Tenha em mente que até mesmo o Manifesto Ágil fala como se tudo fosse uma questão de grau, declarando que:

“Nós passamos a valorizar: indivíduos e interações sobre processos e ferramentas; Software que trabalha sobre uma documentação completa; Colaboração de clientes sobre negociação de contratos; Respondendo a mudar depois de um plano. ”

Então, até mesmo o Manifesto não diz que devemos eliminar processos e ferramentas, documentação, negociação de contrato ou um plano – os fundamentos do método da cascata!

É tudo uma questão de grau … mas enquanto o ágil enfatiza “erre rápido, aprenda rápido” o método cascata enfatiza mais “onde e quem errou”.

De fato, tanto as metodologias ágeis quanto a cascata têm pontos fortes e fracos. A Waterfall protege contra mudanças dispendiosas no final do ciclo.

Tais mudanças dispendiosas no ciclo tardio são um problema inultrapassável e inaceitável em projetos de construção, por exemplo.

Mas eles também são um problema (embora em menor grau) em projetos de software – mas cada vez menos com design orientado a objetos e componentes, e certamente em contraste com a construção de uma estrutura ou uma instalação de fabricação.

Em um projeto de desenvolvimento de software, é virtualmente impossível conhecer e planejar todos os detalhes antecipadamente – e também desaconselhável, porque você quer ser responsivo diante das mudanças.

Assim, uma abordagem ágil de entregar cedo e com frequência, com uma capacidade e vontade de mudar de curso enquanto está em movimento, é o caminho a percorrer.

Organizando-se para um projeto híbrido

É preciso pensar um pouco mais para alcançar o equilíbrio em projetos híbridos (e lembre-se de que eu disse que todos os projetos são híbridos!).

Pense no que você precisa em seu projeto sobre esses elementos básicos:

1. Considere o grau em que seu projeto pode precisar ser totalmente planejado antecipadamente – e na medida em que isso é possível.
2. Até que ponto o seu projeto pode se beneficiar com a execução de incrementos de curto prazo, com entregas antecipadas e frequentes?
3. Quais habilidades sua equipe tem? Eles estão mergulhados em alguma metodologia específica? Quanta direção eles precisam… e quanta habilidade eles têm de se “auto-gerenciar”?
4. Os seus requisitos não negociáveis ​​- regulatórios ou outros – podem exigir um maior grau de planejamento antecipado?
5. Quão claros são os requisitos? Eles provavelmente permanecerão inalterados ou poderão mudar com o tempo?

Primeiramente, no trabalho, imagine que você esteja trabalhando como gerente de projeto em um grande projeto de desenvolvimento de software para desenvolver um sistema complexo e integrado.

Afinal várias equipes Scrum estão em ação, em vários locais e até mesmo em parte de diferentes organizações – mas todas estão trabalhando no mesmo projeto geral que você deve coordenar.

Primordialmente o ritmo do projeto é rápido; Sprints são executados em uma cadência de cada duas semanas.

O fluxo constante de reuniões – planejamento de sprint, revisões de design, reuniões de requisitos, planejamento de teste integrado, scrum de scrums e muito mais – pode ser incompreensível!

As rodas estão girando, o trem saiu da estação e está se movendo em alta velocidade … mas há outro lado para isso.

Qual é o destino final? Qual é o plano geral ?

Ainda assim à medida que você analisa o fluxo constante de atividade e os detalhes, percebe que atingiu a “junção” – entre processos ágeis de baixo para cima, orientados por Scrum, e o planejamento de cima para baixo e direcionado por cascata.

Além disso, você percebe que está em um projeto híbrido .

O que é preciso para gerenciar projetos híbridos

Portanto parte da minha premissa é que todos os projetos de desenvolvimento de software são projetos híbridos. Como resultado, eu não acho que uma pessoa que é estritamente mergulhada em metodologias ágeis ou no método cascata vá bem; em vez disso, é preciso um gerente de projeto com habilidades híbridas.

Entretanto acredito que o gerente de projetos de software de hoje deve ter o domínio dos métodos ágeis e da cascata – e precisará classificar as necessidades exclusivas do projeto para determinar a combinação apropriada, identificando onde a “costura” entre as opções de baixo para cima e de cima para baixo.

Concluindo você acredita que todos os projetos de desenvolvimento de software são híbridos? E o que você acha que é necessário para gerenciar projetos híbridos?

1. Peter Keen – The Hybrid Manager
2. A Morte do Gerente, do Testador e do Analista Funcional
3. Manifesto Ágil BR