Roberto Argento

No últimos anos tenho acompanhado a movimentação para a execução de provas de conceito como um impotante e cada vez mais comum passo na aquisição de ferramentas de engenharia de software.

Entretanto, não pude deixar de notar uma armadilha na qual vi muitas organizações caírem nos mais de 10 anos que trabalho com essa tecnologia. 

Em todas as provas desse tipo, onde o foco é a ferramenta, o resultado é quase sempre o mesmo: ganha a ferramenta pelas quais os técnicos têm mais simpatia.  Em geral por uma margem muito pequena.

Provas como essas vão mostrar basicamente duas coisas: a dificuldade de colocar o ambiente em produção (incluindo a integração com ferramentas legadas) e o quanto o pessoal técnico acha fácil ou difícil o seu uso.  Afinal em termos de funcionalidades não há grandes diferenças entre os concorrentes – em raros casos há impeditivos absolutos que eliminam algum concorrente. 

O problema é que tanto um fator como o outro têm pouca relevância no contexto mais amplo.  As dificuldades do projeto de implantação e adaptação das ferramentas, por maior que elas possam ser, são uma pequena inconveniência de curta duração se comparadas ao objetivo de construir uma plataforma de desenvolvimento eficiente e eficaz que se pretende definir como padrão para vários anos.  Por outro lado essas dificuldades são a razão de ser das provas de conceitos.

Outro desvio muito comum, é a confusão dos conceitos de produtividade dos desenvolvedores com a produtividade da organização de desenvolvimento. 

Todos os estudos mostram que dar produtividade aos desenvolvedores e demais profissionais individualmente podem impactar entre 5% e 15%, no máximo, a produtividade do processo como um todo.  É um número importante mas longe do potencial de transformação que a implantação de uma nova plataforma e um novo processo de desenvolvimento e entrega de software pode trazer. 

Outras questões como: um sistema amplo de indicadores e métricas, capacidade de colaboração, um processo completo de qualidade,
gerência de portfolio de projetos, aplicações e funcionalidades, a ligação com os processos de arquitetura empresarial e da governança de TI, trazem ganhos de 2 a 10 vezes na produtividade (entrega de valor) da organização de desenvolvimento para o negócio.

Focar exclusivamente na produtividade dos desenvolvedores pode não atender aos principais objetivos da empresa com o projeto, apesar da grande influência que esses exercem nesse tipo de decisão.  Mesmo que sejam eles que “vão usar” as ferramentas e portanto devem ser ouvidos, essa decisão é de negócio e não puramente técnica.

Vários fornecedores têm boas ferramentas quando avaliadas individualmente.  A comparação do entre elas leva muitas vezes a um empate técnico ou uma pequena vantagem dependendo do que o time de avaliação quer provar.  Afinal, é só mudar os pesos dos critérios para mudar o rumo da avaliação e  os critérios são criados por times que já são tendenciosos, em geral de forma inconsciente, por suas experiências anteriores, conhecimentos técnicos e preferências pessoais – não há nenhuma sugestão de má fé nessa afirmação.

O que está em questão é a adoção de uma plataforma que possa suportar o problema sobre a mesa no momento e todos os seus desdobramentos futuros, muitos dos quais não conseguimos nem imaginar. 

Somente para citar alguns que devem ser importantes no curto e médio prazos: 

1) Um sistema abrangente de qualidade.

2) Um processo de desenvolvimento que construa aplicações seguras e conformes às normas e padrões da indústria e legais.

3) Um sistema abrangente de métricas que lhes possibilitem avaliar o processo doponto de vista da qualidade, prazo, assertividade, previsibilidade e esforço das entregas, integrado ao sistemas financeiros e de contrato.

4) Alinhamento com a arquitetura empresarial e com a governança corporativa e de TI.

5) Um sistema de gerência de portfolio integrada e bidirecional. Ou seja, uma plataforma que permita que a análise de portfolio seja alimentada em tempo real com dados dos projetos e vice-versa, permitindo a revalidação das decisões tomadas em ciclos muito mais eficientes.

6) Uso de padrões abertos e  o suporte de tecnologias heterogêneas de
desenvolvimento e execução (que podem ainda nem existir hoje). 

7)  Um processo sistemático de REUSO. Estudo da indústria mostram que o retorno dessa prática chega a 30 reais para cada real investido.

Para suportar essa jornada, a plataforma precisa ser desenhada e projetada com essa missão desde o seu nascimento. 

Os fornecedores de ferramentas têm visões e histórias diferentes nesse mundo.  Uns são historicamente focada no desenvolvedor, dando facilidades para o seu trabalho e o seu dia a dia. Outros são focados em entregar às organizações de desenvolvimento a capacidade de entregar mais valor ao negócio, medindo essa entrega de forma objetiva e clara para todos os stakeholders da organização. Simples assim.

Somente com uma análise que combine aspectos técnicos, financeiros e de mercado é que podemos evitar essa armadilha técnica, que pode ser muito cara para a organização no longo prazo.