Tradicionalmente o desenho e implementação de aplicações modernas em linguagens como Java EE e .NET é tratado como um elemento puramente técnico. Um pequeno volume de horas é concedido ao time de desenvolvimento para resolver um problema complexo através de um conjunto de modelos técnicos, linguagens como UML e provas de conceito exploratórias. O foco na ótica gerencial é apenas em custos, o que explica porque pouco times no Brasil exploram o desenho como um software realmente merece. O resultado é publicamente conhecido, como nos relatórios das crônicas do caos na TI, que mostram o pífio desempenho dos projetos de TI por todo o mundo.

E se ao invés de pensarmos no desenho como um custo, pensássemos no mesmo como um investimento financeiro baseado nos conceitos de valor agregado e da prática da indústria chamada de software engineering economics.

O desenho baseado em valor agregado pode ser visto como uma atividade econômica, visto fazer um software não é uma atividade puramente técnica. Arquiteturas conceituais como o SOA mostram a importância de se pensar em software como um elemento de negócio.

Compilo aqui um conjunto de elementos necessários à implementação do desenho baseado em valor econômico em times de software.

1. Times devem ser auto-gerenciáveis. Times auto-gerenciáveis definem coletivamente os passos necessários para produzir os entregáveis técnicos de um projeto, ao invés de receber ordens de gerentes de mais alto nível que não entendem do método construtivo de software. Naturalmente, time auto-gerenciáveis são completamente responsáveis pelas consequências dos seus atos. O SCRUM é um excelente exemplo do uso desta técnica.
2. Todo elemento técnico deve ser pensado no valor agregado que ele produz para o projeto. O raciocínio da análise de valor agregado, difundida nos círculos gerenciais, deve se tornar uma obsessão diária. Por exemplo, a escolha sobre o uso de um estilo de RPC baseado em WS-* versus um estilo REST-* deve ser analisado de forma quantitativa e econômica. O valor agregado deve ser medido através do alinhamento dos benefícios técnicos aos condutores do projeto, ao custo de oportunidade do produto para uma organização e outros elementos organizacionais.
3. Orçamentos de projetos devem ser comunicados aos times técnicos. Times devem ser responsáveis pelo uso adequado do investimento do dinheiro de um projeto. Para criar esta responsabilidade, os orçamentos devem ser divulgados. Já tive a oportunidade de presenciar projetos onde técnicos passaram semanas experimentado tecnologias a seu bel prazer, sem nenhum compromisso com o dinheiro que estava sendo investido pelos patrocinadores.
4. Orçamentos devem ser monitorados diariamente. Por exemplo, um dia de um projeto de um time de cinco pessoas com formação plena no mercado Brasileiro é um investimento da ordem de 2 a 4 mil reais. Qual a contra-partida fornecida tecnicamente para justificar este investimento? Ao divulgar e monitorar o raciocínio de investimentos para desenvolvedores, eles se tornam mais comprometidos, conscientes e criativos no uso do dinheiro.
5. Praticar a mentalidade da abundância, do líder Stephen Covey. Ao comunicarmos investimentos para os times, temos que promover mecanismos de recompensas. Por exemplo, se tivermos um orçamento de 100.000 reais para um projeto e se o time atingir os critérios de qualidade para a entrega no projeto, a sobra de orçamento deve ser dividida pelo time, conforme a participação entre os seus membros.
6. Educar desenvolvedores em práticas de administração. Talvez a mais difícil missão, desenvolvedores devem não apenas conhecer Java, .NET, OO e padrões de desenho, mas também sobre o contexto e a importância do software para as organizações e empresas.

Pensamento dia dia:

“Não somos responsáveis apenas pelo que fazemos, mas também pelo que deixamos de fazer.”, Molière