Não são Riscos, são seus olhos

Todos os projetos de desenvolvimento de software tem riscos. Não interessa tamanho, domínio, experiência da equipe ou recursos, os riscos estão ai, sempre estiveram e sempre vão estar. Alguns acreditam que gerenciar riscos é gerenciar projetos eu discordo dessa opinião, pois deixa as coisas de uma maneira muito simplista e de facto não é.

Não estou falando de rabiscos quando falo de riscos. Estou falando de perigos, ameças e tudo aqui lo que pode prejudicar o sucesso do seu projeto. Então vamos associar a palavra riscos com a palavra perigo ou se você preferir: danger!




Um exemplo de Risco


Mas cuidado! Essa é boa não? Bom você não pode ficar entrar em paranóia, mas também não pode seguir o seu projeto sem pensar em como mitigar riscos.


Alguém sabe o problema dessa figura?

Ela é extrema, claro que é uma sátira. Não existe a menor possibilidade de você estar lidando com todos os riscos do projeto é simplesmente impossível! De forma divertida é isso que a figura a cima mostra.

Mas você deve lidar com riscos, não todos, não poucos mas o suficiente, o que é o suficiente? Bom essa é a parte difícil, depende do contexto, não é seguindo agile ou RUP ou qualquer outra cosia que você sabera o que é o suficiente, somente o seu bom senso pode lhe dizer. Alguns anos de experiência de facto ajudam também :)


Não criemos pânico!

Não há motivo para você se desesperar existe práticas e orientações para lhe ajudar nessa tarefa e é disso que vou falar neste post. Vamos começar simples, de forma fácil e sem muito esforço vou mostrar como podemos gerenciar riscos de forma efetiva.

A Idéia Principal

A idéia principal sobre o gerenciamento de riscos é muito simples, nos precisamos lidar com os riscos antes de que eles aconteçam ou quando isso não é possível, evitar que os riscos acabem matando o projeto. Para fazer isso você terá que ser acima de tudo honesto, para expor uma fraqueza da equipe ou até mesmo sua(como gerente).

Se você fizer um bom trabalho no gerenciamento de riscos irá aumentar as chances de sucesso do seu projeto e também estará poupando recursos financeiros. Como disse antes cada projeto pode ter seus próprios riscos, mas no geral vários projetos podem apresentar riscos quanto:
  • O quão são bons os skills da equipe para esse projeto
  • A tecnologia é estável, existe documentação, suporte, SLA, pessoas no mercado
  • O Design aplicado é o correto
  • A solução atende as necessidades dos stakeholders
  • A Comunicação interna é boa, funciona de facto
Esses são bons pontos, até mesmo perguntas que você pode se fazer para averiguar se existe risco nesses pontos ou não. Como disse pode ser que esses não sejam problemas para seu projeto, como pode ser que sejam, pensar sobre esses itens não é um problema.

Quem deve trabalhar com riscos?

Toda equipe! As analogias quanto a times esportivos com times de desenvolvimento em um projeto são válidas em alguns pontos de vista. Um ponto de vista é que assim como em um time de futebol não adianta um jogador jogar melhor que os outros, não tem como um ganhar, ou o time todo ganha ou o time todo perde.

Por isso gerenciar riscos não é atividade única e exclusiva do gerente de projetos, todos devem se envolver com os riscos. Isso significa que todos devem identificar e mitigar riscos. Não pense por que você é um desenvolvedor ou testador que essa não é uma atividade sua.

Um barco no mar de riscos



Imagine que o projeto é um barco e que vocês estão em uma tempestade, por que diabos você não falaria para o seu capitão que existe um problema? Sim o gerente é o capitão mas ele não pode ver tudo e fazer tudo, você deve ajudar com os riscos.

Como você pode ajudar?

Identificando riscos, discutindo esses riscos de dentro e fora da equipe. Você não pode ter medo do feedback pois esse pode ajudar muito com os seus riscos. Planejar quando você vai atacar determinados riscos e como é uma excelente idéia!

Isso ai meu amigo, você não será capaz de lidar com todos os riscos ao mesmo tempo. Então isso tem que entrar no seu planejamento, ai você pode planejar e decidir quando e como tratar os riscos, mas sempre procurando identificar se não existem outros riscos. Riscos são como pragas, logo elas podem voltar.

Como documentar riscos?

Pode ser com um documento word, ou com uma planilha, até mesmo uma folha de papel A4! O importante é que isso fica visível a todos! Isso mesmo! Não estou louco esses riscos devem estar visíveis do sponsor ao desenvolvedor. Não há motivo para esconde-los!

Não seria melhor deixar os riscos internamente apenas?

Definitivamente não! Você não deve fazer isso. Alguns podem achar que assim estamos expondo os problema do time ou até mesmo a incompetência do gerente, muitas vezes é isso mesmo, mas somente expondo os problemas é que teremos mais chances de resolver os problemas e em alguns casos é melhor cancelar o projeto ou mudar o rumo das coisas. Esconder o que de ruim está acontecendo não é honesto e nem mesmo saudável!

Uma planilha Excel é um excelente inicio. Mas quantas colunas eu devo ter e quantos riscos devem estar lá? Ok primeiro quantos riscos, não mais do que 50, senão vai ficar realmente complicado de gerenciar isso. E quantas quais/colunas?
  • Nome do risco ou título
  • Uma "Breve" descrição, breve mesmo
  • Impacto
  • Probabilidade de ocorrência
  • Magnitude
  • Responsável/identificador
  • Estratégia de ação
Bom algumas considerações. Quanto ao impacto seria bom usar apenas 3 valores tipo: baixo, médio e alto, esse é o estrago que o riscos pode fazer no projeto. Na probabilidade use valor com porcentagem mas algo do tipo: 10%, 30%, 50%, 80% e 100%. Por que não ter o 15%? Por que pode ficar algo difícil de decidir que no final das contas só vai tomar seu tempo e saber se é 1% a mais ou a menos não irá fazer diferença.

A magnitude é o risco X o impacto. Isso é util para ter uma única coluna para pesquisa/decisão. A estratégia é o que você esta fazendo para mitigar esse risco ou o que você vai fazer caso ele aconteça. Não coloque coisas do tipo "Aceitar Passivamente" se essa for a sua única ação remova o risco ou pense melhor, recomendo que pense melhor!

Uma prática rápida e efetiva

Além de ter o excel com os riscos você pode eleger os Top 10! Que seriam os 10 riscos mais complicados/difíceis/perigosos para o seu projeto! Essa lista com os Top 10 recomendo a você que ela fique visível a todos isto significa que seria muito bom coloca-la na parede! Quanto mais visibilidade melhor!

E que tal um gráfico?

Melhor ainda só se for 2! Um gráfico de exposição aos riscos é algo muito útil, de facto isso pode gerar incomodo nas pessoas e é isso que vai ajudar elas a quererem matar os riscos. Um risco pode mostrar a soma de todos os riscos expostos e o outros pode mostrar a exposição aos Top 10.

Nesses gráficos você teria a magnitude em uma eixo e no outro eixo o tempo. Fazer ele no excel é válido, mas se você deixar a equipe faze-los a mão vai ter mais envolvimento com isso, como são gráficos simples e rápidos de fazer de preferência a faze-los a mão.

Se você gostou deste post pode ler outros posts relacionados a esse a baixo:


Popular posts from this blog

C Unit Testing with Check

Having fun with Zig Language

HMAC in Java