[Este artigo foi otimizado pela equipe editorial do InfoQ Brasil]
O gererenciamento de riscos é um assunto quente em TI. Processos para o gerenciamento efetivo de riscos e para apoiar decisões de investimento permitirão às técnicas Agile escalarem para toda a organização. Sem esses processos, o Agile estaria confinado ao desenvolvimento de software.
O gerenciamento de riscos em TI é ainda subestimado, apesar da existência de muitas referências sobre o assunto. Nos próximos anos, ao olhar para trás veremos que as "melhores práticas" estão longe de ser as melhores. O avanço do Agile expôs o gerenciamento de riscos como uma área que precisa ser melhorada. Com as práticas ágeis, ocorrerão muitas mudanças no gerenciamento de riscos em TI nas próximas décadas.
Quando consideramos o gerenciamento de riscos em projetos de TI, a única preocupação é com o investidor; todas as outras perspectivas são subordinadas à do investidor. A equipe do projeto, os administradores de TI e os usuários voltam-se à geração de retorno ao investidor; nada mais importa da perspectiva de TI.
Sem o conhecimento apropriado dessa realidade, algumas formas de gerenciamento de riscos criam novos problemas. Minimizar o risco para parte da equipe geralmente significa transferir o risco para outra parte, o que é conhecido como otimização local. Um exemplo disso é o "controle de mudanças" que protege as entregas, caso o investidor mude de ideia em relação a elas; mas que ao mesmo tempo aumenta o risco para o investidor na medida em que ele não pode redirecionar seus investimentos fácil e rapidamente.
Tipos de riscos
Da perspectiva do investidor, pode-se considerar que existem três categorias de riscos:
1. Risco na entrega. Risco de o software não ser entrego dentro do prazo e orçamento ou que não possua a qualidade requerida.
2. Risco para o valor de negócio. Risco de que o projeto não entrege o valor esperado.
3. Risco para o modelo de negócios. Risco de que o projeto prejudique a organização atual.
As técnicas de Agile e Lean para desenvolvimento de software solucionam a primeira categoria de riscos. Técnicas como Feature Injection, Lean Startup e Business Value estão começando a tratar a segunda categoria. E a técnica de Opções Reais pode ser utilizada para gerenciar os três tipos de riscos.
A literatura consagrada sobre gerenciamento de riscos em TI tem foco no risco da entrega. O exemplo anterior sobre controle de mudanças indica que o risco na entrega está relacionado a outras duas categorias de riscos; todas as três devem ser consideradas de modo abrangente. Enquanto o gerenciamento individual de cada risco pode trazer vantagens para a empresa, é o gerenciamento integrado dos riscos com uma estratégia holística traz os verdadeiros benefícios.
É necessário estabelecer um sistema de gerenciamento de riscos em TI, em vez de considerar uma única ferramenta isolada. Para que esse sistema funcione, vários grupos devem participar e compartilhar seus entendimentos sobre os riscos. É importante que o gerente de riscos de TI implemente um sistema com ciclos de feedback e ferramentas de suporte.
Esse artigo tem foco na mais importante, embora subestimada, categoria de riscos: o risco de prejudicar o modelo de negócios existente.
Risco para o modelo de negócio
Os projetos em si trazem riscos para a empresa como um todo: o risco para o modelo de negócio. Um exemplo famoso (no Hemisfério Norte) é a promoção de viagem grátis da Hoover, empresa que anunciou uma oferta especial, "Compre uma máquina de lavar e ganhe uma viagem para os EUA" (saindo da Inglaterra). A promoção teve tanto sucesso que quase destruiu a empresa. Embora esse artigo não pretenda discutir decisões de negócio, nosso foco é mostrar como as escolhas em TI podem afetar a organização. Em casos trágicos, uma falha de TI pode até mesmo resultar em mortes, como o que ocorreu no Serviço de Ambulâncias de Londres.
Uma das primeiras coisas que aprendemos em Opções Reais é identificar quando estamos fazendo uma escolha. Se você está prestes a fazer uma escolha, verifique se é possível voltar atrás e identifique quanto tempo será necessário para reverter a escolha. Além disso, pondere sobre o tempo que a organização consegue sobreviver até que se reverta a escolha feita. Considerando que é impossível prever o que será necessário para consertar um problema inesperado, a única coisa que podemos ponderar é o tempo necessário para a reversão.
Perguntas para análise dos riscos
1. A escolha é reversível?
2. Quanto tempo é necessário para voltar atrás?
3. Quanto tempo a organização consegue sobreviver com a solução escolhida?
Se o tempo necessário para reverter a escolha é menor do que o tempo em que a organização pode sobreviver sem o sistema, então não há problema. Se o tempo para reverter a escolha é maior que o disponível, então é necessário criar alternativas.
Compromissos e decisões reversíveis
Ao implementar uma mudança de sistema, considere se a mudança é um compromisso ou uma decisão reversível. Esclarecemos com alguns exemplos:
1. Considere que você está dirigindo em uma área desconhecida. Virar para o lado errado...
a) É uma decisão reversível se você está numa rua de mão dupla, e portanto sempre pode voltar e refazer seus passos.
b) É um compromisso, quando você está numa rua de mão única e não se pode mais voltar atrás.
2. Considere que você está perdido em uma mata e encontra um buraco de três metros de profundidade. Você pode entrar, mas não há como subir depois.
a) É uma decisão reversível quanto se tem uma corda ou algo que ajude a subir de volta.
b) É um compromisso quando se pula para dentro do buraco sem estar preparado para subir de volta.
3. Considere a modificação da estrutura do seu banco de dados de forma que o código antigo continue a funcionar.
a) É uma decisão reversível se você possui backup do seu banco de dados, que pode ser restaurado, caso ocorra algum problema.
b) É um compromisso quando a atualização na estrutura do banco de dados é permanente e você não tem como criar backups.
Portanto, a regra é: a ação é reversível? Caso positivo, não há problemas. Se for um compromisso, assegure-se que possui soluções efetivas para voltar atrás. Se o deployment do seu sistema envolve apontar uma URL para um executável em vez de outro, a reversão, claro, é apontar a URL novamente para o executável original; não há problemas.
Porém, se o deployment é mais complexo, então deve-se definir um plano de reversão (rollback). É ao criar esse plano que são identificadas as ruas de mão única e os buracos de três metros.
Estratégias de reversão
Podemos criar opções para reverter as escolhas realizadas. Fazer o planejamento de reversão não significa que iremos utilizá-lo. O custo de planejar e criar opções é o custo adicional que pagamos para ter a chance de reverter uma decisão, caso necessário.
Nossa primeira preocupação na reversão é o tempo, seguida pelo custo. O gerenciamento de riscos está relacionado ao tempo. Ou seja, trata-se de criar alternativas que não pretendemos utilizar, mas que podemos utilizar caso necessário. O tempo disponível para reverter os passos, a reversão, determinará a sua estratégia.
Sempre faça um plano de reversão, mesmo que não vá precisar dele. Prepare esse plano à medida que fizer o planejamento das entregas, e a cada estágio das entregas, pergunte: "Isso é um compromisso? Isso é um buraco de três metros?" Se for, garanta que existe uma alternativa para reverter a decisão. O momento para fazer essas perguntas é antes de pular no buraco.
Analogamente, o momento para pensar em planos de reversão é antes de iniciar o release. Nessa hora há tempo e calma. A maioria dos erros acontece quando estamos pressionados pelo tempo e somos forçados a tomar decisões. O melhor momento para decidir é quando temos tempo; por isso faça o plano de reversão antes de iniciar o release, de forma que não seja surpreendido e levado a tomar decisões durante a execução.
Quando executar a reversão
Agora temos a seguinte questão: "como sabemos que é hora de fazer a reversão?" Um dos maiores riscos é o de que problemas sérios passem desapercebidos enquanto o software já está em produção, e sem ninguém perceber algum problema sério. Para mitigar esse risco, o sistema deve ser testado imediatamente antes de ser liberado para produção, para provar que funciona corretamente.
Se testes abrangentes exigirem um tempo muito grande, pode ser melhor realizar um pequeno subconjunto dos testes (chamados de smoke tests), para ao menos testar a funcionalidade fundamental do sistema.
Com o objetivo de reduzir o risco de liberar código de baixa qualidade no ambiente de produção, recomendamos que as seguintes políticas sejam obedecidas:
1. Usar o mesmo processo para liberar o software para testes e para liberá-lo para produção. Idealmente, esse processo deve ser automatizado.
2. Liberar o mesmo software para testes e para produção.
3. Procurar fazer apenas as modificações necessárias e manter o controle das mudanças em um repositório comum.
4. Observar cuidadosamente os ambientes de testes e de produção, pois a falta de integração entre eles cria riscos para o sistema.
5. Manter o ambiente de testes o mais parecido possível com o ambiente de produção.
Observe que o risco associado às entregas na produção não é constante e depende do contexto. Dessa forma, os investidores e outros interessados no projeto devem sempre estar envolvidos na definição de quando as entregas serão feitas.
Prazo das entregas
Quando o prazo é crítico para os interessados e falhas podem custar caro, o intervalo para reverter as mudanças se reduz. Aqui está uma lista de dias ou datas em que aumenta o risco de falhas para o investidor:
- Final de períodos fiscais;
- Véspera de Natal ou outras datas importantes;
- Época de indisponibilidade de pessoas essenciais da equipe;
- Momento em que estão ocorrendo mudanças significativas na empresa;
- Momento em que a empresa está sofrendo auditoria.
A entrega é uma decisão de negócio complexa
Para reduzir os riscos de entregar o sistema no momento errado, deve-se estabelecer um processo para assegurar que todas partes interessadas sejam notificadas e se comprometam com a decisão. Os responsáveis pela liberação da entrega devem ter sido apontados no início do projeto.
Riscos e mudanças não planejadas
Nem todas as mudanças, é claro, são planejadas. Muitos anos atrás, lembro meu pai contando sobre uma empresa aérea que teve seu centro de processamento de dados destruído num incêndio. A empresa não tinha backups e o resultado foi a falência após seis meses. Decorridos trinta anos, no entanto, os computadores e a infraestrutura das empresas passaram a ser incluídos no "Plano de Continuidade de Negócios" e no "Plano de Recuperação de Desastres".
Ao lidar com os desastres, as questões que você deve fazer são as mesmas a serem feitas ao reverter um release de baixa qualidade. "Quanto tempo levo para ativar meu plano de backup?" e "Quanto tempo meu negócio pode sobreviver sem meu sistema?"
A recuperação de desastres e a continuidade dos negócios são caras. Por isso é necessário considerar quais sistemas são realmente críticos. Com relação a riscos, o maior problema é sempre o tempo.
Conclusões
Em resumo, o prejuízo dos riscos para o negócio é uma das categorias fundamentais de riscos a serem tratadas. As empresas precisam reagir em tempo, para que os estragos não se tornem irreparáveis. Portanto, antes de assumir compromissos, a pergunta que deve ser feita é, "seria possível transformar o compromisso em uma decisão reversível?".
Uma competência essencial para um gerente de riscos em TI é ser capaz de identificar compromissos, para depois ser capaz de criar decisões reversíveis através de Opções Reais. Antes de pular num buraco de três metros, certifique-se que é possível subir de volta.
Sobre os autores
Chris Matts é analista de negócios e gerente de projetos com experiência em sistemas bancários. Sua abordagem para o gerenciamento de riscos em TI é baseada na experiência em bancos de investimento.
Olav Maassen trabalha na Xebia como consultor em Agile. Seu interesse principal é em novas ideias que possam ajudar outros profissionais a se melhorarem.