Riscos e planeamento: mais restrições exigem mais agilidade

Por: Mark Schwartz, enterprise strategist na Amazon Web Services

Muitas vezes perguntam-me: Mark, sei que as metodologias Agile e DevOps favorecem a aprendizagem e a adaptação face a seguir um plano rígido. Mas o nosso processo de orçamentação bloqueia antecipadamente as nossas despesas (e, portanto, o nosso plano anual) e o nosso processo de gestão de investimentos trava necessariamente os níveis de gastos e o calendário de cada projeto. Nesse caso, como vamos conseguir ser ágeis se os nossos gastos estão bloqueados com muita antecedência?

Como faço muitas vezes, vou enquadrar este tema numa perspetiva de risco, embora haja muitas outras formas de pensar sobre isso. Os orçamentos ou a limitação da duração dos projetos não são, por si só, um problema: simplesmente acrescentam um risco que deve ser mitigado.

Agilidade dentro do orçamento

Vamos analisar o cenário orçamental em particular, mas a lógica aplica-se a qualquer outra restrição “não ágil”. Digamos que a empresa, no seu processo anual de orçamentação, bloqueia os gastos para uma determinada categoria no início do ano ou até antes.

À medida que o exercício orçamental se desenrola, haverá alguma diferença entre as despesas orçamentadas e as despesas que vão sendo executadas à medida que o ano avança e as circunstâncias mudam. Se a empresa fez um trabalho perfeito, então a diferença será zero. Sabemos que isto não é realista. O que muitas vezes não reconhecemos é o quão irrealista é. A era atual é de rápida mudança, incerteza e complexidade.

Por exemplo, digamos que a partir de meados do ano, a empresa está a cumprir exatamente o seu objetivo em termos de orçamento para infraestruturas informáticas.

Entretanto percebe que se gastar mais 1.000 euros em infraestruturas antes do final do ano poderá servir mais 100 clientes e aumentar as receitas em 1.000.000 de euros. Se a empresa estiver a gerir rigidamente o orçamento, renunciará a esse aumento de receita, o que é mau. Ou digamos que ao gastar mais 1.000 euros para além do orçamento de TI, poderá implementar código que reduzirá os custos em 1.000.000 de euros. Ou talvez alguém na empresa tenha uma ideia brilhante para um novo produto ou funcionalidade que irá impulsionar receitas significativas. Mais uma vez, o limite orçamental pode impedir a empresa de implementar a ideia.

Estes são eventos prováveis ou improváveis? Algures entre os dois. Mas com a quantidade de mudança e complexidade que vemos hoje, é muito provável que algo cause uma discrepância entre a execução e o orçamento – seja para mais ou para menos.

Restrições acrescentam risco (num ambiente de incerteza)

Devido à incerteza, gosto de pensar nesta discrepância como um risco e não como um certo custo. Quando a empresa bloqueia os gastos de TI, está a correr o risco de ter uma execução diferente do orçamento. Em si mesmo, não há nada de errado em correr riscos. Nos exemplos acima referidos, estamos a falar sobretudo de custos de oportunidade. Mas os riscos podem ser mais graves e diretos. Imagine que um concorrente faça um movimento concorrencial repentino e a empresa fica relutante em responder devido à rigidez orçamental. Nesse caso, o risco pode ser perder todo o negócio.

“Quando a empresa bloqueia os gastos de TI, está a correr o risco de ter uma execução diferente do orçamento”

Consideramos os orçamentos muito valiosos porque são mecanismos de controlo. Mas pode haver formas alternativas de realizar o mesmo objetivo com menos risco. Há formas de antecipar as despesas relacionadas com projetos, permitindo refazer o processo de decisão à medida que a empresa vê os resultados das primeiras fases do projeto. Mas vamos supor que a empresa não está disposta a renunciar a orçamentos anuais.

Mitigação do risco do orçamento

Isto leva-nos a outra questão, como mitigar o risco de decidir sobre um orçamento ou um plano de projeto muito cedo, antes que as circunstâncias reais do ano sejam visíveis. Essa é precisamente uma área onde as metodologias DevOps e Agile brilham. Com a antiga abordagem em cascata, exceder o orçamento sempre foi uma possibilidade séria, porque há um compromisso antecipado com um conjunto de requisitos e depois continua-se a gastar até os atingir. Com uma abordagem Agile, pode comprometer-se com um nível de gastos (ou capacidade da equipa), e depois continuar a dar prioridade aos itens de trabalho para obter o maior valor até que o orçamento seja gasto, altura em que o trabalho para.

Também pode gerir o risco de ter escolhido um nível de gasto fixo, construindo arquiteturas de TI (provavelmente microserviços) que proporcionam o máximo de flexibilidade possível, ou formando os seus colaboradores para serem generalistas. Poderá então reduzir o risco do seu nível orçamental fixo, tirando partido das flexibilidades de que dispomos dentro desse nível orçamental.

“Com a antiga abordagem em cascata, exceder o orçamento sempre foi uma possibilidade séria, porque há um compromisso antecipado com um conjunto de requisitos e depois continua-se a gastar até os atingir”

Outra possibilidade é aceitar excedentes orçamentais — mas apenas quando estão correlacionados com aumentos de receitas. Ou seja, pode tentar tirar mais partido dos custos variáveis em vez dos fixos, para que cresçam com as receitas como parte do custo dos bens vendidos. Aqui, a nuvem fornece grande parte da “magia” necessária, uma vez que a infraestrutura e o uso do serviço variarão com o volume de negócios, que por sua vez dependerá das receitas. Por exemplo, com a nuvem da AWS, uma empresa paga pela tecnologia de infraestrutura que está a usar a cada momento, com um enorme aumento de flexibilidade — podem adicionar ou subtrair servidores instantaneamente, ou alterar o poder de processamento conforme a necessidade dos seus negócios. Usar técnicas sem servidor é outro exemplo, como o serviço Amazon Lambda da AWS, porque uma empresa ganha mais flexibilidade e não precisa de provisionar mais servidores virtuais, mas ganha uma magnitude mais flexível. Não é mais necessário que a empresa provisione servidores virtuais. Simplesmente designa qual o código que deve ser executado e sob quais as condições, e a AWS lida com tudo o resto. A empresa paga apenas pela execução do código.

“A nuvem fornece grande parte da ‘magia’ necessária, uma vez que a infraestrutura e o uso do serviço variarão com o volume de negócios”

As abordagens ágeis são uma forma de viver dentro do orçamento, enquanto a cascata é uma forma de se recusar a fazê-lo. O seu pressuposto é que os custos previstos serão iguais aos custos reais, pelo que não há qualquer problema. Mas isso é uma má suposição em tempos de incerteza. A metodologia Agile, por outro lado, diz que se descobrirmos que estamos a ficar sem orçamento, então faremos menos coisas da nossa “lista de desejos”, e uma vez que continuamos a ajustar as prioridades, sabemos que teremos feito as tarefas mais importantes e de elevado retorno antes de ficarmos sem dinheiro.

Por isso, quando me perguntam como podem ser ágeis, mesmo perante os constrangimentos fixos impostos antecipadamente, especialmente os constrangimentos orçamentais, sugiro que revertam a questão. Dadas estas restrições, como podem não ser ágeis? Não há razão para não ser ágil com restrições orçamentais, mas há muitas razões pelas quais não consegue ser ágil.

Sim, parece estranho pensar no orçamento como um risco, mas aí está (também pode argumentar que não fazer um orçamento também tem riscos).