BT

Discutindo Agile com um Diretor Financeiro

por Vikas Hazrati , traduzido por Anderson Duarte Vaz em 03 Set 2010 |

O Diretor Financeiro é responsável pelo planejamento, relatórios e análises financeiras, além de gerenciar os riscos financeiros de uma empresa. Qual linguagem seria a melhor do que a financeira, para explicar os benefícios do Agile à um DF?

David Chilcott, iniciou essa interessante discussão no grupo Scrum Development para entender pontos importantes do Agile que interessariam a um DF. Michael Spayd mencionou que ele certamente gostaria de conversar em termos puros de negócio. De acordo com Michael, ele falaria sobre: 

  • Os benefícios dos deploys frequentes por considerar o VPL (Valor Presente Líquido) de um projeto Waterfall e Agile.
  • A habilidade de parar um projeto de sucesso quando ele ultrapassa a sua curva de valor.
  • Capitalização vs. despesas de benefícios em termos de como o investimento em projetos Agile é contabilizado nos 'caixas' das empresas vs. projetos Waterfall.
  • Menor volume de negócios em equipes Agile levando à menor formação e custos de contratação.

Da mesma maneira, John Goodsen sugeriu que ele é mais inclinado a usar o pensamento Lean do que o Scrum, ao conversar com CxO's. De acordo com John,

Primeiramente gosto de ter certeza de que eles entendem a diferença entre custos e contabilidade de ganhos, para então entender qual modelo eles estão usando. Se é o latter, você está firme no chão. Se for o former, então você terá mais trabalho à frente. A conversa então segue para o custo do WIP (Trabalho em Andamento), o custo do atraso e o valor de limitar o WIP para estabelecer um fluxo. Você pode desenhar um gráfico de RI (Retorno do Investimento) sobre o tempo, que compara o desenvolvimento tradicional com ciclos curtos, mostrando que releases frequentes não necessitam de investimentos iniciais profundos de capital, antes que você tenha um retorno.

De acordo com John, quanto mais você demora para entregrar valor e receber dinheiro, mais profundo o investimento fica. Pequenas funcionalidades devem ser liberadas em intervalos frequentes para estabelecer um rápido retorno do investimento. John tem uma imagem interessante que ilustra a diferença de ROI para projetos Agile, versus cenários de projetos Waterfall.

Trond Wingård apresentou seus pensamentos sobre Agile para um DF, comparando o VPL, TIR (Taxa Interna de Retorno), tempo de payback (tempo que o projeto demora para se pagar), e o RI para um projeto Waterfall e um projeto Agile. Ele desmonstrou os critérios para seu projeto fictício como:

Vamos imaginar um projeto:

  • Ele está programado para durar 12 meses.
  • Durante esse tempo ele custará 5 milhões de dólares.
  • O produto final irá fornecer um benefício financeiro de USD 200.000 por mês (receita extra ou corte de gastos, menos qualquer despesa mensal).
  • O produto abruptamente pára de produzir seus benefícios 4 anos depois do projeto ter começado. Pode-se afirmar que existe uma janela de oportunidade de 4 anos para esse produto em particular.
  • (Também estou considerando uma taxa de desconto de 10% nos cálculos de VPL)

De acordo com os cálculos, as estatísticas em usar o modo Waterfall versus fazer um release a cada 6 meses versus fazer um release a cada 3 meses, foram as seguintes:

O quê Waterfall Releases a cada 6 meses Releases a cada 3 meses
Break Even (Payback) 37 meses 34 meses 33 meses
RI (Retorno do Investimento) 44,0 % 56,0 % 62,0 %
Valor Presente Líquido (VPL) USD 920,000 USD 1,477,000 USD 1,758,000
Taxa Interna de Retorno (TIR) 20,7 % 28,7 % 33,5 %

Da mesma forma, Trond comparou a situação quando existir um atraso de 4 meses no projeto. Ainda, conforme os números, lançamentos frequentes justificaram a parte financeira:

O quê Waterfall, como planejado Waterfall, 4 meses de atraso Releases frequentes, 4 meses de atraso
Break Even (payback) 37 meses Nunca 39 meses
RI (Retorno do Investimento) 44,0 % -4,0 % 29,8 %
Valor Presente Líquido (VPL) USD 920,000 USD -1,280,000 USD 796,000
Taxa Interna de Retorno (TIR) 20,7 % -2,0 % 20,0 %

A planilha de Trond para CFO's pode ser baixada aqui.

Portanto, existem argumentos suficientes para discutir Agile em termos financeiros com um CFO. Os números em diversos cenários adequadamente desmonstraram os benefícios de se usar Agile.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Ainda waterfall? by Constantino Moura

Li o artigo, achei muito interessante e parabenizo a iniciativa da publicação, aprendi bastante ao lê-lo, no entanto reside uma dúvida: Porque comparar Agile com Wartefall? Porque queimar essa energia toda? Ainda existe alguém, em algum lugar do planeta que ainda desenvolva no
método waterfall? Será que por exemplo esse waterfall ai é um desvio para falar do RUP? Não, né? Tenho lido por ai alguns posts principalmente dos que trabalham com SCRUM e pouco conhecem do RUP (não é o caso deste fórum acredito) e negam as múltiplas iterações e as entregas sucessivas que o desenvolvimento iterativo proporciona e acho que não vale discorrer aqui.
Outra dúvida: Como faço para entregar valor real para um negócio no desenvolvimento de um ERP? Pois neste caso pequenas entregas, podem até gerar conforto para o patrocinador que acompanha o andamento, mas resultado e valor mesmo, só ao final, não é mesmo? Em um ERP o que me adianta receber o módulo de Compras, sem o Contas a Pagar? Eu disse valor ao negócio, ok?

De certo mesmo só sei que com Agile ou qualquer outro, melhor ter em mente estes fundamentos:

SEM ENTENDER O PROCESSO: você pode não ter entendimento correto do negócio sob modelagem, impactar nas decisões e sistematizar a coisa errada.

SEM VISÃO: você pode perder o rumo e ser facilmente confundido em desvios.

SEM DIRETRIZES: A equipe pode ter comunicação e entendimento errôneos sobre quem vai fazer o quê e quando.

SEM PLANO: Você não conseguirá acompanhar o andamento.

SEM LISTA DE RISCOS: Você pode estar se concentrando nas questões erradas atualmente e pode explodir em uma mina inesperada daqui a cinco meses.

SEM ARQUITETURA: Você pode não conseguir lidar com questões de comunicação, de sincronização e de acesso a dados, conforme elas surgem. Pode haver problemas com a capacidade de ajuste e o desempenho.

SEM PRODUTO (protótipo): É muito importante colocar um produto na frente do cliente. O simples acúmulo de papéis, reuniões diárias, etc., sem decisão, não garante a você e ao cliente que o produto será bem-sucedido e sem um protótipo aumenta o risco de exceder o orçamento e a programação e/ou de falha direta.

SEM AVALIAÇÃO: Não finja que não é com você. É importante encarar a verdade. Quão próximo você realmente está do prazo? Das metas em qualidade ou do orçamento? Todas as questões estão sendo adequadamente acompanhadas?

SEM CONTROLAR AS MUDANÇAS: Como você acompanha as solicitações dos envolvidos? Como você as prioriza? E impede que as de prioridade mais baixa passem despercebidas?

SEM SUPORTE AO USUÁRIO: O que ocorre quando um usuário tem uma pergunta ou não consegue entender como usar o produto? Com que facilidade se obtém ajuda?

Um grande abraço para todos!

Re: Ainda waterfall? by Constantino Moura

Sobre a Capitalização vs. despesas de benefícios em termos de como o investimento em projetos Agile é contabilizado nos 'caixas' das empresas vs. projetos Waterfall.

Sobre isso, o livro Software Project Management, ROYCE, Walker, USA, Addison-Wesley, Chapter II e seguintes, trata da comparação econômica entre o desenvolvimento tradicional (waterfall) e o desenvolvimento iterativo proposto pelo RUP.

- Achieving ROI across a line of business
- Achieving ROI across a project with multiple iteractions
- Achieving ROI across a life cycle os product release.

Ano 2000.

Abraços

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

2 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT