Implementando a mentalidade focada em ferramentas de tecnologia: primeiros passos

Um líder de tecnologia que queira padronizar as ferramentas usadas na empresa certamente enfrentará opiniões contrárias com frases do tipo “Tenho três times de engenharia, é melhor deixá-los escolher a maneira como querem trabalhar”. A questão é que não existe um conjunto de ferramentas ideal, porque para determinadas tarefas um tende a ser mais eficiente que o outro. 

A resposta para esse dilema é que é pior que a companhia fique paralisada esperando um sistema perfeito, porque se cria um cenário em que cada time de engenharia fica com seu próprio conjunto de ferramentas, e a empresa toda deixa de receber os benefícios da comunalidade que a padronização proporciona. É preferível ter um conjunto de ferramentas bem escolhido e bem definido, mesmo que ele não seja ideal para algum dos times ou para alguns cenários.

Para uma empresa já estabelecida que queira, então, investir na uniformização das ferramentas e compensar um passado técnico mais heterogêneo, a primeira providência é criar um time interno dedicado ao arcabouço ferramental de engenharia. A função dessa equipe não está diretamente ligada ao diferencial de negócio da empresa, pois seu grande objetivo é tornar os desenvolvedores mais produtivos. 

Na prática, pode-se estabelecer 10% do total da equipe de engenharia para cuidar das ferramentas de engenharia. É fundamental que esse grupo seja composto de ótimos profissionais, porém sua contratação pode oferecer desafios, devido à escassez de gente com esse perfil em um mercado que valoriza pouco a atuação de bastidores. A equipe precisa ter capacidade e prestígio suficientes para impor a padronização em todos os níveis.

Dependendo do tamanho da empresa, o projeto de reorganizar o ferramental de engenharia pode virar um plano de longo prazo, que demanda investimento pesado, pois exige limitar o número de linguagens de programação, escolher, contratar e migrar ferramentas e plataformas, além de rever a organização dos repositórios. E isso tudo tem que acontecer sem paralisar a produção de novo código e as atividades corriqueiras da companhia.

É preferível ter um conjunto de ferramentas bem escolhido e bem definido, mesmo que ele não seja ideal para algum dos times ou para alguns cenários.

Pode não ser nada fácil justificar para o CFO (chief financial officer) de uma empresa com 200 desenvolvedores que é preciso montar um time novo de 20 pessoas para definir e gerir as ferramentas de engenharia. A simples – e verdadeira – justificativa de que “a colaboração vai ser muito melhor no futuro” dificilmente vai convencer sem uma argumentação cuidadosa. 

Uma vantagem fácil de explicar é a possibilidade de desenvolvedores conseguirem executar tarefas de programação em prazos muito menores, se houver ferramentas para facilitar essas tarefas, e repositórios compartilhados e sincronizados. 

Vencendo resistências à padronização

Impor padrões costuma gerar resistência, por isso é preciso promover junto uma transformação cultural para convencer as pessoas da importância da iniciativa. A padronização das linguagens de programação é um ponto especialmente sensível. A decisão sobre quais linguagens privilegiar e adotar não pode ser trivial. É preciso usar critérios como:

• A popularidade da linguagem dentro da empresa
• O quão fácil é contratar pessoas que usem aquela linguagem
• O quão conhecida a linguagem é no mercado
• O quanto de abrangência de ferramentas existe para aquela linguagem 

É recomendável também olhar para o mercado e entender o que está sendo feito, preparar um benchmark cuidadoso, trocando ideias com outros protagonistas do mercado nacional e internacional e  com os fornecedores de tecnologia, além de fazer prova de conceito com protótipos e testar. Se uma solução parecer ser muito eficiente mas ninguém do mercado a estiver adotando, vale procurar  entender o porquê. Pode não valer a pena se comprometer com um caminho radicalmente original.

No tópico de linguagens de programação, por mais que as escolhas de linguagem possam ser encapsuladas por time, já que toda a interface entre sistemas é feita por APIs, para linguagens mais exóticas é possível que não exista um arcabouço computacional tão variado quanto o que está disponível para outras. Talvez, por exemplo, não haja um ambiente de testes adequado o suficiente e seja necessário criar um próprio para a empresa. Uma linguagem mais “popular” terá mais ferramentas para escolher, mais sistemas de código aberto, mais bibliotecas e assim por diante.

Não é preciso adotar medidas radicais. A sensibilidade dos gestores pode indicar os caminhos, por exemplo determinando uma linguagem para cada ambiente.

Mudança de cultura: restrição como via à inovação

Por mais que os critérios que se usem para a padronização de linguagens e ferramentas sejam racionais, quem é afetado tende a sentir uma imposição onde antes não havia restrição nenhuma.

A uniformização é necessariamente impositiva, e é por esse motivo que sempre que possível deve ser feita o quanto antes, porque, uma vez impostas as restrições, para cada pessoa nova que chegar à empresa elas já não serão restrições, serão apenas o padrão daquele lugar. Para quem já estava na empresa, a resistência só será atenuada se houver uma liderança de engenharia prestigiada e um trabalho de cultura fundamentado sobre a mentalidade de crescimento, o growth mindset.

Mostrar na prática à equipe o quanto de flexibilidade a padronização permite ajuda no esforço de convencimento. Ferramentas são globais e com elas as pessoas conseguem trabalhar de forma assíncrona e remota, em fusos horários diferentes, com ganhos à qualidade de vida e à saúde mental. Quase sempre se ganha pontos em trocar uma reunião por uma colaboração assíncrona: engenheiros gostam muito mais de fazer engenharia do que de fazer reunião.

Uma empresa baseada no princípio de tecnologia intencional tem uma comunicação eficiente, feita sempre que possível através de ferramentas padronizadas o bastante para que os desenvolvedores se sintam ágeis e produtivos, cuidem do código e estejam abertos a colaborações, em um ambiente que valoriza o aprendizado, a mobilidade entre os times e a construção de plataformas que levarão a inovações.

Ferramentas são globais e com elas as pessoas conseguem trabalhar de forma assíncrona e remota, em fusos horários diferentes, com ganhos à qualidade de vida e à saúde mental.