Faca Na Caveira: Por Que Desenvolvimento de Software é Diferente de Operações de Esquadrões de Elite

---

Tem sido uma prática comum associar equipes de desenvolvimento de software com esquadrões de elite da polícia ou do exército. No Brasil, depois do fenômeno cultural iniciado pelo filme Tropa de Elite, esses tipos de esquadrões tem sido usados como referência de trabalho em equipe e garantia de entrega. Porém, essa associação esconde aspectos do trabalho dos esquadrões de elite que não deveriam ser trazidos nem para a área de desenvolvimento de software nem para o mundo corporativo em geral.

A primeira diferença entre esses tipos de equipe é o tipo de problemas com os quais elas tem que lidar. Um esquadrão de elite da polícia é acionado para situações extremamente sensíveis nas quais medidas extremas são necessárias. Esses times são treinados e especializados em entrar e resolver situações que saíram completamente do controle das autoridades; situações nas quais medidas de prevenção ou negociação já não são mais viáveis. Em outras palavras, essas equipes são acionadas depois que tudo deu completamente errado e a única solução possível é eliminar bandidos/terroristas com a maior precisão possível, sabendo que civis inocentes podem ser pegos no fogo cruzado.

Situações comparáveis a essas são perfeitamente possíveis durante o desenvolvimento e manutenção de software, especialmente quando algum grave problema emerge em ambiente de produção. Nesses casos, é normal que a atuação seja o mais rápida e direta possível, deixando para depois preocupações de médio e longo prazo. Porém, uma equipe de desenvolvimento que é especializada em resolver esse tipo de problemas (ou seja, “apagar incêndios”) tem a tendência natural de tratar qualquer problema como uma emergência. Qualquer demanda que chegue ao backlog dessa equipe será tratada como uma crise que precisa ser resolvida o mais rápido possível, com pouco planejamento ou análise de impacto. Se a solução adotada tiver algum efeito colateral indesejado, essa será apenas mais uma emergência com a qual a “super-equipe” terá que lidar.

Mas não é possível desenvolver um software de alta qualidade de crise em crise. Medidas de prevenção e previsão de problemas são mais do que necessárias. É por isso que desenvolver software está mais próximo de construir uma ponte ou levantar um prédio do que de eliminar ameaças de forma rápida e precisa. Se há lições que nós desenvolvedores de software podemos aprender com outras áreas, especialmente a Engenharia Civil, é como planejar e executar projetos de alta complexidade. E, ainda assim, temos que nos adaptar ao fato de que o cenário sobre o qual devemos construir nossas soluções são bem mais variáveis do que os de outras áreas.

Além disso, a Engenharia Civil aplica conhecimentos e experiências que vem sido melhorados ao longo de milênios. Em escala de tempo, a Engenharia de Software está mais próxima da Engenharia Aeronáutica. A grande diferença é que essa última atingiu um altíssimo grau de segurança e confiabilidade graças a processos bem estabelecidos de investigação e prevenção de falhas. Processos semelhantes existem na Engenharia de Software, mas o aprendizado acumulado pela área pode ser simplesmente ignorado por “chefes”, gerentes ou desenvolvedores, levando-os a cometer os mesmos erros do passado e ainda ficarem surpresos com o resultado. É por isso que uma equipe especializada em lidar com crises e apenas isso jamais será capaz de construir um software estável e confiável.

É conveniente para os níveis mais altos de gerência pensar na equipe de desenvolvimento como um esquadrão de elite. Basta passar uma “missão” e esperar o resultado dentro do prazo estabelecido. Para alguns deles, os requisitos não-funcionais estão subentendidos e saem “naturalmente” durante o desenvolvimento. Quando o software feito às pressas não atende requisitos de performance ou segurança não informados previamente, eles ainda ficam surpresos. O que eles não entendem é que um software feito às pressas agora provavelmente vai sair mais caro depois, seja porque sua manutenção será mais custosa ou porque ele terá que ser inteiramente reescrito.

Alguns deles defendem que o software não precisa ser perfeito para ser lucrativo, o que, até certo ponto, é verdade. O principal exemplo disso é o Microsoft Windows, um sistema operacional cuja qualidade tem sido alvo de muitas críticas ao longo dos últimos 20 e poucos anos, mas que ainda assim foi um dos carros chefes para tornar Bill Gates um dos homens mais ricos do mundo. Porém, a realidade do Windows é muito diferente da realidade do Software as a Service (SaaS): além de, por muito tempo, não ter grandes concorrentes, aquele era um sistema de prateleira que na maioria das vezes era vendido junto com o hardware. Se muitos usuários tivessem uma experiência catastrófica com ele, o máximo que poderiam fazer era reinstalá-lo e esperar pelo melhor. Na era do SaaS, uma única experiência catastrófica pode trazer à baixo toda uma organização.

Quando não conseguem/tentam formar as super-equipes para as quais “missão dada é missão cumprida”, muitas organizações procuram os chamados programadores SuperStar (ou RockStar, ou Jedi, etc.), que na maioria das vezes são programadores comuns com excesso de autoconfiança. Dentre as muitas desvantagens dessa abordagem, destaca-se a dependência que a organização terá dessa única pessoa. Não são poucas as histórias de pequenas e grandes empresas que não podem demitir ou “desagradar” funcionários de comportamento tóxico porque eles detêm a maior parte do conhecimento técnico ou de negócio de sua equipe.

Vale lembrar que, apesar da Síndrome do Impostor ainda ser um grave problema no ambiente corporativo, o excesso de autoconfiança também é uma questão que não pode ser ignorada, especialmente nas engenharias. Uma das causas do desastre nuclear de Fukushima foi justamente a insistência de engenheiros e cientistas em não implementar as medidas adicionais de segurança sugeridas pelo fabricante do reator. Nesse caso, os engenheiros chegaram ao cúmulo de subornar inspetores para que eles não reportassem as irregularidades encontradas. Desse artigo analisando a situação:

Um sistema não pode ser resiliente, isto é, ser capaz de lidar com situações severas, se ele está limitado a apenas funcionalidades projetadas. O excesso de autoconfiança limita a imaginação dos engenheiros, e impede a justificativa de medidas corretivas usando como base argumentos econômicos ou filosóficos. Tal excesso de autoconfiança é comum entre os especialistas da indústria nuclear, assim como em outras indústrias.

A habilidade mais importante que uma empresa de tecnologia pode ter é a capacidade de formar boas equipes. A alta rotatividade do atual mercado de trabalho não permite que uma empresa forme uma boa equipe e então foque apenas em tentar mantê-la. Mais importante que isso é desenvolver a capacidade da organização de selecionar e treinar novos talentos de forma a minimizar o impacto de mudanças no time. Uma vez que a troca de um único integrante pode alterar completamente o perfil de uma equipe, o desafio da organização é garantir que ela irá manter (ou, é claro, melhorar) seus níveis de desempenho e qualidade. Em outras palavras, mais importante do que tentar manter os integrantes é tentar manter as práticas e a cultura de equipes de altos desempenho e de alta qualidade de entrega.

Por fim, enquanto os esquadrões de elite tentam resolver problemas por meio da eliminação de criminosos ou destruição de alvos militares (prédios, veículos, etc.), as equipes de desenvolvimento de software lidam com eles por meio da construção de soluções que devem atender requisitos funcionais e não-funcionais de um determinado grupo de usuários. Se formos nos comparar com outros tipos de profissionais, é mais adequado que sejam com pedreiros e mestres de obra do que com soldados de elite.

---

---