Analisando Processos de Desenvolvimento de Software sob Perspectiva Econômica

Como consultor, tenho a oportunidade de ajudar desenvolvedores, arquitetos e executivos a desenvolver soluções em TI que atendam os objetivos do negócio. Mas quais seriam os “objetivos do negócio”?

Em algumas empresas, ouço que objetivo do negócio é reduzir o time-to-market. Em outras, reduzir desperdícios (retrabalho, etc.). Para alguns executivos, a ideia é melhorar a qualidade (ou reduzir os custos de má qualidade). Há, também, um bocado de gente falando, simplesmente, em melhorar a eficiência. Entretanto, esses “objetivos” são apenas “expressões de dor”.

De forma definitiva, o objetivo do negócio é sempre aumentar os lucros ou proteger o lucro! (assumindo empresas com fins lucrativos, obviamente). As “dores” que relacionei no parágrafo anterior podem impactar os lucros (geralmente impactam). Entretanto, é fundamental que não se perca de vista que toda ação implica em algum tipo de trade-off.

While you may ignore economics, it won’t ignore you. (Donald Reinerstsen)

O excelente livro “The Principles of Product Development Flow” de Donald Reinerstsen (leitura recomendada pelo Rodrigo Yoshima) indica uma excelente abstração que podemos usar como ponto de partida para analisar os impactos da resolução de uma dor sob a perspectiva econômica.

A ideia chave é perceber que uma decisão visando otimizar um fator acaba impactando nos demais e sugere uma reflexão mais aprofundada.

O livro ainda sugere vários princípios que devemos observar. Aqui compartilho três desses princípios:

  1. As ações devem ser selecionadas com base no impacto econômico total. A adição de valor no produto (features que o cliente está disposto a pagar para ter) devem ser superiores aos custos inerentes (Lembrando que: features que não geram valor, só aumentam o custo). Investimentos em Desenvolvimento para reduzir o Cycle Time acabam impactando também nos Custos do Produto. O Custo do Capital associado ao risco impacta no montante do resultado marginal (valor adicionado – custos) mínimo, etc..
  2. As variáveis estão interconectadas. Não dá para tomar uma ação que impacte em uma variável sem que outras sejam impactadas (aqui está o nosso tradeoff).
  3. A medida mais importante é o “Custo do Atraso”. Qual o impacto financeiro em atrasar a implementação de uma feature? Tarefas com maior custo de atraso são, naturalmente, prioritárias (repare que o esforço tem pouca relação com esta variável #ficadica).

Há bem mais princípios no livro. Mas, acho que estes três já são uma excelente base para pensar as prioridades e a organização de nossos processos de desenvolvimento.

Nesta série, vou falar sobre aspectos estratégicos de negócios de TI. Este foi o primeiro post. Até mais.

Compartilhe este insight:

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Elemar Júnior

Sou fundador e CEO da EximiaCo e atuo como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Elemar Júnior

Sou fundador e CEO da EximiaCo e atuo como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Mais insights para o seu negócio

Veja mais alguns estudos e reflexões que podem gerar alguns insights para o seu negócio:

For years, I have known developers who designed beautiful architectures. A lot of them are questioning the need for a...
To write parallel code is not a trivial task. There are details to consider and rules to observe. Could you...
Há anos eu conheço e aceito a ideia de que devemos buscar melhoria contínua. Sei que é natural e aceitável...
In this post, I would like to explain a basic but confusing concept of CUDA programming: Thread Hierarchies. It will...
No post anterior, eu mencionei uma série de post do Mario Fusco questionando a forma como desenvolvedores Java estão implementando os design...
Neste post, apresento o conceito de “Dívida Técnica” (não é débito, é dívida). Explico por que nem sempre elas são...
× Precisa de ajuda?