O diálogo ao lado (do excelente Geek and Poke) pode ser traduzido livremente assim:

Em se tratando de ROI de software existem 2 tipos de organização: aquelas que não tem a mínima idéia do ROI dos sistemas e aquelas que acham que conhecem o ROI dos seus projetos de software.

Existem culpados?

Sim. A complexidade atual. Quer queiramos ou não, os processos de negócio mudam mais rápido do que o tempo de codificarmos “Hello world!” em PERL:

$ perl -e 'print "Hello World\n"'

As organizações mudam, as motivações e objetivos que definiram a construção de uma aplicação mudam entre o início e o final de um projeto. Isto para não falarmos das aplicações que planejamos e codificamos e no final… …lá se vão milhares de linhas de código para o repositório de “projetos solicitados e nunca sequer utilizados”.

Sejamos realistas. Diante de toda esta inevitável complexidade, será que aquele ROI que está destacado na planilha dos gerente de projetos ou dos departamentos de processos, está minimamente correto?

Em minha opinião, devemos calcular ganhos financeiros, de tempo dos processos, da redução de pessoal (efeito colateral quase sempre inevitável), de redução dos lead time dos processos, “ganhos” de produtividade etc etc etc. O ROI, entretanto, este não é tão simples assim.

Que podemos fazer?

As dicas abaixo foram citadas no blog CIO Dashboard (Chris Curran). Em resumo, Chris sugere 5 ações que podem nos ajudar a chegarmos mais próximo do ideal do ROI de um sistema.

1. Valide e Re-Valide o Business Case

Escopo e fases fazem sentido do ponto de vista do negócio? Você pode ter uma opinião não tendenciosa? Que tal solicitar uma opinião de alguém experiente, de uma área não relacionada com o projeto?

2. Defina um Benefício Mensurável

Pode ser simples, mas é melhor definir um ou mais benefícios mensuráveis do que apresentar apenas “promessas de PowerPoint”. Defina, faça as medições antes e depois e veja o resultado na prática.

3. Cada Projeto deve ter seu Plano de Benefícios

Cada sistema tem propósitos e um ciclo de vida ou roadmap próprio. Da mesma forma, cada um deles deve ter o seu próprio plano de benefícios devidamente documentados.

4. Acompanhe os Benefícios do Portfólio de Projetos

Esta é uma dica para as empresas que tem sistemas complexos de TMOs (Technology Management Offices) ou PMOs devidamente estabelecidos. Um dos mais complexos e abrangentes é o Primavera (adquirido pela Oracle).

5. Crie um Painel (Dashboard) e Exiba os Benefícios do Projeto

Quem não se comunica… …pois é, o projeto traz muitos benefícios, ou potenciais benefícios, e toda esta informação fica restrita à equipe de TI. Existe algum benefício, algum ganho? Utilize a comunicação visual e apresenta-a em formato de dashboard.

Boa sorte!

p.s.: interessado em um livro sobre o assunto? Que tal “Maximizing ROI on software development” de Vijay Sikka (ex-Intel e fundador da Sikka Software Corporation)

Jurgen Appelo é o CIO de uma empresa da Holanda que já foi classificada como a #1 entre empresas que mais se destacaram em inovações tecnológicas. Ele mantém um blog onde escreve sobre tópicos relacionados desde conteúdo para a Internet até a metodologias e gerenciamento de projetos que utilizam metodologia ágeis.

Neste post, Appelo faz uma compilação bastante interessante de 10 princípios que devem guiar todo líder ou gerente de projeto que utiliza as práticas recomendas pelas metodologia ágeis. Discussões à parte sobre a eficácia destas metodologias, o ponto aqui é a discussão do tópico “Gerenciamento de Tempo”, uma das áreas de conhecimento do PMBoK, e um ativo altamente valioso nestes dias.

Vamos ao que interessa:

1. Use uma Definição de “Feito”

Eu poderia traduzir este princípio como “defina a tarefa como concluida se, de fato, ele estiver”. Se couber a palavras “mas” no final do seu discusso, esqueça, a atividade não foi feita, incluindo toda parte burocrática da atividade (apontamento de horas, levantamento de custos etc

Ele recomenda a leitura do artigo “The Definition od Done“. Neste texto o auto, de forma bem humorada, conta que seu pai era contador e tinha um grande aviso na parede da sala para os engenheiros desavisados. Neste aviso, havia um desenho de um papel higiênico e o texto acima: “The Job is not done until the paperwork is done”. Ou seja, na definição dele, o trabalho não estava finalizado se a papelada não foi preenchida. Perfeito.

2. Solicite Prazos bem Definidos e Exija o Cumprimento

Parece óbvio, mas não é: uma vez definido o prazo, não permita que estes se alterem.

Minha experiência pessoal inclui um tempo trabalhando em projetos de desenvolvimento no exterior, morando lá por algumas temporadas. Pelo menos nos EUA, nas empresas onde passei, isto é levado muito a sério. Você passou o prazo? Ok. Então você vai cumprir, “no matter what happens…“, é uma questão que remota a princípios culturais difícieis de explicar neste post, mas é assim que funciona.

Leitura recomendada: “Time Boxing is an Effective Getting Things Done Strategy”

3. Não Adicione “buffers” nas Tarefas

9 entre 10 líderes de equipe fazem isto (I Know!). É uma “praga” e, infelizmente, associa-se esta prática aos prazos de TI, que são sempre classificados como “não condizentes com a velocidade do negócio”. Quando o desenvolvedor ou o técnico passa a sua estimativa, ela(e) já informe com uma certa “margem de segurança”.

Isto nos leva ao “Paradoxo Tostines”. TI é culpada por errar estimativas, então aumentamos nossas estimativas para errar menos que, por sua vez, remete à questão de que TI demora muito para liberar as soluções… …percebeu?

(fonte: http://www.focusedperformance.com/articles/CCPM.htm)

Leitura recomendada: “Critical Chain Scheduling and Buffer Management…”

4. Não Tome as Decisões antes do prazo estabelecido

Em vista de toda discussão, parece paradoxal, mas tem uma razão. Se você tem um prazo até dia “D”, o autor sugere que você responda no dia “D”.

Qual o risco de responder antes? Mudanças de última hora podem ocorrer (e ocorrem!) e você terá que refazer o planejamento que já tinha feito. A não ser que a questão não deixe nenhuma margem para mudanças, aconteça o que acontecer, conte até 10 antes de responder imediatamente a questão. Isto pode trazer mais problemas que não compensa a sua intenção de “agilizar” o processo.

Leitura recomendada: “ ‘Real Options’ Underlie Agile Practice”

5. Reduza os Ciclos dos Processos

Quase um “mantra” das metodologias ágeis, nunca esqueça dos ganhos em reduzir os ciclos iterativos do processos.

Uma resposta rápida (feedback) vai retroalimentar mais cedo o processo e reduzir riscos.

Leitura recomendada: “Lean software development: Why reduce cycle-time?”

6. Limite a Quantidade de Tarefas que estão “in progress”

Quanto maior o número de tarefas em andamento, maior o risco de “escorregamento” destas atividades. Não existe um número mágico. Isto depende do porte do projeto, da experiência dos participantes e da equipe que gerencia o projeto, do ferramental disponível para acompanhamento do progresso das atividades etc.

Leitura recomendada: “Managing the Pipeline”

7. Mantenha a Disciplina

As regras de ouro aqui são: “resolver um problema tardiamente irá custar muito mais caro” e “começar certo, desde o início”.

Leitura recomendada: “The Power of Process” (recomendo!)

8. Limite o Intercâmbio de Tarefas

Sonho de 10 entre 10 gerentes de projeto, a mensagem aqui é evitar, a todo custo, tarefas intermediárias que farão uso “apenas por um dia, prometo….” dos recursos do projeto.

Leitura recomendada: “Human Tasks Switch Considered Hamful”

9. Atenção para as Horas-extras Frequentes

Na minha opinião, se isto é rotina no projeto, ou empresa, é um forte Indicativo de que algo está muito errado. Revisite as estimativas o tamanho da equipe, as fases do projeto, a experiêcia técnica dos recursos etc. Isto, quando comum, só gera desgate na equipe e perda de produtividade.

leitura recomendada: “The Case Against Overtime”

10. Separe Urgência de Importância

Atividade Urgentes e Atividades Importantes: escolha uma das duas. Realiza-las ao mesmo tempo é “embarcar em uma canoa furada”.

A prática diz que insistir em realiza-las ao mesmo tempo fará com que a tarefa Importante não será finalizada, gerado custos adicionais que poderião ter sido evitados.

Leitura recomendada: “A 10 Second Guide To Smoother Projects: Urgent vs. Important”

Boa sorte! Abraços,

Davi