Estou lendo um livro muito bom sobre Teoria dos Jogos, de Ronaldo Fiani, e estou entrando em contato com algumas idéias muito interessantes, que tranquilamente podem ser aplicadas a um departamento de tecnologia. Segundo a Wikipedia, a "Teoria dos Jogos é um ramo da matemática aplicada que estuda situações estratégicas onde jogadores escolhem diferentes ações na tentativa de melhorar seu retorno". A palavra chave aí é retorno, também chamado de recompensa.

Ok, e aí? Aí que, através de uma série de modelos, a teoria dos jogos ajuda a entender as reais motivações das pessoas, a maneira com que elas tomam algumas decisões, como elas consideram o ambiente e os outros componentes do jogo, ou interação estratégica.

Pensando nisso tudo, coloquei alguns dos modelos da teoria dos jogos para funcionar com algumas premissas:

1. Todo mundo quer maximizar o retorno;
2. O mercado de tecnologia está muito aquecido. Mesmo nesta crise financeira a demanda ainda supera a oferta de profissionais. Há entre 15 e 70 mil vagas disponíveis no país, não preenchidas por falta de profissionais qualificados (depende de onde você pega a pesquisa);
3. Os terceiros têm uma rotatividade acima da média, já que não podem contar com estabilidade, e aproveitam melhor as oportunidades que aparecem, seja para ganhar mais, seja para realizar um trabalho com melhores perspectivas (aprendizado, promoção, salário, etc);
4. Pela minha experiência, os funcionários CLT de tecnologia também mudam de emprego a cada 4 ou 5 anos em média. É mal visto o profissional com dez anos de empresa na mesma posição. E não é todo mundo que pode (ou consegue) ser gerente.
5. Hoje em dia os departamentos de TI estão tomados por terceiros, muitos inclusive em posição de tomada de decisões, até mesmo as que involvem custos.

Só com essas premissas dá para concluir, utilizando uma generalização, sem tocar nos casos de menor proporção que:

1. As empresas devem contar com a saída de boa parte do seus decisores:
   1. se for um terceiro, em até 3 anos mais ou menos;
   2. se for CLT, em até 5 anos mais ou menos;
2. Como as pessoas trabalham por recompensas, e estas geralmente vêm por entregas mensuráveis como redução de custo, entrega no prazo e índice de erros (entre outros), as pessoas vão fazer o que for necessário para atingir estes objetivos. Frizando: o que for necessário. Vão jogar o jogo da empresa, usando as regras que dispões (e suas brechas) e vão dobrar algumas delas.
3. O que acontece depois que a pessoa sai da empresa não é mais problema dela. Isso quer dizer que os projetos de TI de responsabilidade de uma pessoa devem funcionar somente até a pessoa sair da empresa. Depois disso são problema de outra pessoa.
4. Existem muitos casos em que uma pessoa/equipe é responsável por projetos e outra pessoa/equipe por manutenção de software pré-existente. Nesse caso fica mais fácil ainda: o projeto tem que funcionar somente até a homologação. Depois disso a pessoa de projeto nem precisa sair da empresa: o projeto já é de outro assim que é homologado.

Por fim, a conclusão final é:

Se for necessário, para atender maximizar a recompensa, deve-se remover "empecilhos" como boas práticas de engenharia ou arquitetura, um processo de gestão que funcione na organização (qualquer que seja ele), padrões de codificação, testes, documentação. Afinal, a recompensa é quem manda. Se não for possível remover esse tipo de trabalho "extra", tenta-se pelo menos "facilitar". Isso explica um monte de empresas que já visitei e que hoje não têm padrões, ou não os seguem, ou eles já foram tão entortados que não servem para mais nada. Afinal, colocamos a raposa para vigiar o galinheiro, não é?

Muitos dirão: isso se resolve com processos. A empresa coloca um processo que de deve ser seguido e que é auditado e medido. Exemplos:

1. Toda aplicação deve ter documentação, que siga um padrão pré-determinado.
   Já cansei de ver isso. Só que o tal padrão tem umas 20 folhas, onde o cidadão só preenche umas 3 no meio, e põe o nome no começo. De resto, fica tudo em branco. Preenche de qualquer jeito, só para atender a auditoria. E todo mundo aprova sem ler. Inclusive quem está pagando (o patrocinador do projeto), e quem vai usar (o usuário).
2. Toda aplicação deve ter testes unitários.
   Ok, e quem olha isso? Existem ferramentas para avaliar isso (como o Visual Studio Team System), só que a maioria não sabe usar. E mesmo assim, você pode criar um teste inútil. E um teste inútil é muito mais difícil de ser rejeitado do que nenhum teste.
3. Toda aplicação deve seguir um padrão de arquitetura.
   Essa é a mais engraçada de todas. Como se toda as aplicações fosses iguais, as empresas definem então que todas devem seguir o mesmo padrão. E sofre do mesmo problema anterior: as pessoas podem não seguir e ninguém vai ver, ou podem seguir nas coxas e vai ser difícil provar que está errado.
4. O processo de desenvolvimento agora é ágil.
   Aí vem a bala de prata. Como se o processo conseguisse resolver problemas de testes mal feitos, por exemplo. Cai na velha discussão do Scrum: o que é DONE?

Todos esses problemas acontecem porque sempre tem alguém na ponta dizendo que o projeto tem que sair mais rápido, que o custo está alto demais, que o produto não era o esperado. Os gestores conduzem um departamento de tecnologia, de engenharia, de ciências exatas, como se fosse um departamento financeiro: corte, corte, corte. Porque lá em cima alguém disse que o objetivo de TI era isso. No final, fica a empresa inteira insatisfeita, e vem o CEO falar que TI não provê a inovação que deveria, e que os custos são muito altos. Também… com TI sentada em um monte de processos que não servem para nada, criando produtos que custam muito além do que deveriam, tanto para fazer quanto para manter. Não tinha como dar outra.

Por isso o nome deste post: Longo prazo. Não vejo hoje nas empresas uma preocupação de longo prazo no departamento de TI que vá além da escolha do modelo dos servidores ou do ERP. Faz-se software que vai durar 3 anos no máximo, porque em dois anos metade da empresa já foi embora. Até o CIO, muitas vezes.

Como fica o papel do arquiteto de software neste cenário? Fica complicado, difícil. Um das principais tarefas do arquiteto de software é pensar no futuro. Coloco aqui um trecho do meu artigo que vai sair na .Net Magazine do mês que vem, edição 58, onde vou falar muito de arquitetura e padrões, sob uma visão prática:

"Não seria necessário montar uma arquitetura focada em melhores práticas se acreditássemos que a solução teria somente os requisitos apresentados (…). Preparamos uma arquitetura fundada em padrões reconhecidos justamente porque sabemos que a aplicação não vai manter os mesmos requisitos durante toda sua existência. Na verdade, aplicativos do mundo real não mantêm os mesmos requisitos nem mesmo durante o desenvolvimento do projeto inicial, quem diria ao longo de toda sua existência."

Será que gestores e clientes que estão mais preocupados com a empresa em que vão trabalhar daqui a 6 meses do que a que trabalham agora se preocupam com arquitetura de software? Duvido muito. Parece ser muito mais fácil fazer software sem padrões, arrastando e soltando do que ter que se preocupar com infra-estrutura, padrões de projeto, injeção de dependência, mapeamento objeto relacional, DDD, testes, tratamento de erro, etc, etc. Mas não é. Esse tipo de software pode até ficar pronto mais rápido (ou não), mas custa muito mais à empresa, que vai pagar por ele muitas vezes, já que ele vai ter que ser refeito também muitas vezes. Isso sem contar os custos de manutenção entre cada reconstrução. Só que quando esse custo for ser pago, quem tomou a decisão de fazer sem bons padrões de arquitetura já está trabalhando em outro lugar.

Esse tipo de problema não acontece tão frequentemente em empresas pequenas ou familiares, onde o gestor muitas vezes tem participação nos resultados da empresa. Neste caso, o foco dele é o longo prazo. Custa muito caro investir em TI para jogar fora logo depois.

Talvez o grande desafio do arquiteto hoje seja tentar demonstrar às pessoas que software bem feito vale a pena, mesmo se for até elas sairem da empresa. Não adianta argumentar que daqui a 10 anos vai estar rodando bem ainda, se o gestor está preocupado com o curto prazo, e com os bônus que vai receber, e não com a empresa que trabalha.

Lembrando que estou tratando de generalizações. Você pode perfeitamente viver algo que contradiz o que eu estou propondo, sem invalidar nada do que escrevi.

Opiniões, como sempre, são bem vindas.

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.