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 Keen1 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 Funcional2.
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:
-
O Manifesto Ágil3 é 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”.
-
A Projetos e TI vem melhorando cada dia mais a categoria Agile, com artigos bem escritos dá uma conferida.
-
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:
-
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.
-
O Microsoft Project, na maior parte, suporta o gerenciamento de projetos em cascata.
-
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:
-
Considere o grau em que seu projeto pode precisar ser totalmente planejado antecipadamente – e na medida em que isso é possível.
-
Até que ponto o seu projeto pode se beneficiar com a execução de incrementos de curto prazo, com entregas antecipadas e frequentes?
-
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”?
-
Os seus requisitos não negociáveis - regulatórios ou outros – podem exigir um maior grau de planejamento antecipado?
-
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?
🎯PMP, SMC, SAMC, SPOC, SCT, PTMC, SDC, SSYB, SAP ACTIVATE, CYNEFIN💡 Educador e orientador 🎥Webinar specialist
Como fundador da Projetos e TI, ajudo as organizações a se tornarem ecossistemas adaptativos, responsivos e auto-organizáveis, implementando novas práticas, estruturas, ritmos e tecnologias que permitam transparência, abertura, inovação e uma forma progressiva de liderar. Caso queira saber mais entre em contato comigo, ou me convide para uma palestra.
1 comentário em “O que é preciso para gerenciar projetos híbridos”