Enquanto na função de gerente de alguns projetos, uma de minhas missões é minimizar ao máximo os riscos de cada um dos projetos. São vários os tipos de riscos inerentes a projetos de software, tais como:
- risco de estourar o prazo;
- risco de estourar o orçamento;
- risco de não obter o retorno do investimento (ROI);
- riscos tecnológicos;
- riscos de pessoal;
- etc
Obviamente não existe uma maneira de gerenciar um projeto 100% à prova de riscos e por isso me empenho o máximo que posso ao mesmo tempo que me preparo para imprevistos. As metodologias ágeis, e especialmente o Scrum (assunto principal do meu livro), foram criados exatamente para lidar com as incertezas dos projetos, ao contrário de metodologias mais tradicionais que tentam planejar tudo, em todos os detalhes, antecipadamente ao início do desenvolvimento.
Muitos gerentes mais tradicionais enxergam métodos ágeis como um risco a ser evitado, entendem que é mais seguro continuar do jeito tradicional de gerenciar projetos. No entanto, é exatamente o contrário. Sendo um processo iterativo e ágil, o framework Scrum inerentemente minimiza o risco ao abraçar as incertezas e inclui-las na pauta dos projetos. No artigo de hoje vou listar as práticas do Scrum que facilitam o gerenciamento eficaz de risco:
E se você nunca trabalhou com Scrum antes, recomendo assistir ao vídeo abaixo antes de prosseguir neste artigo, onde resumo o Scrum em 10 minutos.
Vamos lá!
Flexibilidade de escopo
Você sabia que os pinheiros mais antigos não são os mais fortes? São os mais flexíveis. Quando acontecem as tempestades, os primeiros pinheiros que quebram são aqueles que não se torcem ao vento, que não se adaptam, que tentam se manter rígidos e impassíveis em qualquer situação.
Da mesma forma, a flexibilidade de escopo reduz o risco do projeto em relação ao ambiente externo. Tendências aparecem. Clientes desaparecem. Crises acontecem. O mercado muda. Você tem de ser o mais resiliente possível se quiser se manter no “jogo”.
O risco é, em grande parte minimizado em Scrum, devido à flexibilidade de adicionar ou modificar requisitos em cada iteração durante o ciclo de vida do projeto. Isso permite que a organização possa responder às ameaças ou oportunidades do ambiente de negócios e as necessidades imprevistas, sempre que surgirem, geralmente com custo baixo de gerenciamento.
Feedback regular
Você sabe o que significa a palavra feedback? Retroalimentação. Ou seja, “alimentar de volta”. Do ponto de vista de gerência de projetos, você inicia o projeto “alimentando” (feeding) seu time com informações sobre o projeto e espera que, regularmente, você seja “retroalimentado” (feedbacked) sobre como anda o mesmo.
O feedback regular é útil para diversas situações e estados do projeto, como ajudar a manter o foco no objetivo final, corrigir deficiências nos processos e especialmente no caso de gerenciamento de riscos, ele reduz as expectativas relacionadas com o risco. Isso é útil tanto nos casos em que o projeto está indo bem, quanto no caso contrário, afinal, é melhor saber que há algo de errado o mais cedo possível, e não no dia anterior à entrega, certo?
Sendo iterativo, o framework Scrum dá ampla oportunidade para a obtenção de feedback e definição de expectativas ao longo do ciclo de vida do projeto. Isso garante que os stakeholders do projeto, bem como o time, não sejam pegos de surpresa por má comunicação relacionada aos requisitos, por exemplo.
Empoderamento do time
Existe um vídeo muito famoso na Internet em que um gerente de projeto do Spotify apresenta a cultura de engenharia deles, que é uma evolução do Scrum em conjunto de uma série de técnicas ágeis. Em dado momento no vídeo, ele cita um gráfico de “alinhamento x autonomia” e como isso afeta os resultados obtidos enquanto um time.
Dê pouco alinhamento e pouca autonomia e você será aquele “gerentão” 1.0 que manda e a equipe tem de obedecer (isso ainda funciona no século XXI?), mesmo sem saber porque está trabalhando no projeto. Dê pouco alinhamento e muita autonomia e sua equipe desperdiçará tempo e dinheiro da empresa pois não trabalhará em um objetivo comum. Dê muito alinhamento e pouca autonomia e sua equipe ficará frustrada, pois apesar de saber o objetivo, você ainda quer mandar no dia-a-dia deles e, bem, pessoas inteligentes não gostam disso.
Então o que sobra?
Muito alinhamento, para que todos saibam qual é o objetivo, o que deve ser feito. Mas o “como deve ser feito”, deixe para o time decidir (alta autonomia). Entre tantas responsabilidades que dar poder ao time tira dos ombros do gerente está o das estimativas de software. Deixar para o time estimar o tempo de desenvolvimento cria estimativas mais precisas, aumenta o engajamento e reduz os riscos, permitindo uma entrega oportuna de incrementos do produto.
Transparência
Lembra do que falei sobre a importância do alinhamento no tópico anterior? Para garantir que o time esteja sempre alinhado, e não apenas na reunião de planejamento do projeto, é vital que exista transparência no projeto. Nas decisões, nas métricas, nos objetivos, no andamento, etc. Dentre muitos benefícios de uma gestão transparente do projeto está a redução dos riscos não detectados inicialmente e a resolução proativa de muitos problemas.
O princípio de transparência do Scrum, em torno do qual o framework Scrum é construído, garante que os riscos sejam detectados e comunicados no início, levando a um melhor tratamento e mitigação de riscos. Além disso, quando as Reuniões Diárias do Scrum são realizadas, os impedimentos que um time está enfrentando atualmente, podem ser considerados um risco para outros projetos e times no futuro, e eles devem ser tratados e registrados de forma que não se repitam.
Entrega iterativa
O método de desenvolvimento de software mais tradicional de todos é o Cascata (Waterfall). Ele possui esse nome pois é um método composto por fases bem definidas, onde cada uma acontece de uma vez, em ordem linear, do início ao fim do projeto, ou seja, do levantamento de requisitos até à implantação no cliente. Como você deve saber, existem projetos de software que duram anos e empregam dezenas ou até centenas de desenvolvedores. Qual a chance de uma especificação de software feita há anos atrás ainda representar a realidade do cliente hoje? Ou a realidade do mercado?
O que acontece na prática é que não temos como prever o futuro diante das incertezas da construção de software moderno, principalmente web e mobile. Se começarmos a definir “no detalhe” como o software será daqui há alguns anos, estaremos apenas chutando, na melhor das hipóteses.
Entregar o projeto iterativamente, em ciclos curtos de algumas semanas, gera valor e valida o andamento do projeto com o cliente a cada iteração, reduzindo significativamente os riscos do mesmo, tanto para você, quanto para seu cliente.
Afinal, gerenciar riscos de projetos não é exatamente isso, que todos se saiam bem sucedidos ao final do mesmo? Ou você ainda tem aquele mindset que o Manifesto Ágil condena de ficar se defendendo atrás de um contrato?
Quer conhecer algumas práticas que você pode aplicar em qualquer projeto de qualquer empresa? Leia este artigo e assista ao vídeo abaixo também.
* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso (abaixo) sobre o mesmo assunto!
Olá, tudo bem?
O que você achou deste conteúdo? Conte nos comentários.