Como saber se você está construindo as ferramentas internas corretas

CHICAGO – Os engenheiros adoram construir coisas legais. Essa é a razão pela qual eles são engenheiros em primeiro lugar. Mas como eles sabem se o que estão construindo — o que estão construindo em particular para os usuários de sua própria organização — é algo que as pessoas usarão?

Neste episódio de The New Stack Makers, Rob Skillington, cofundador e CTO da Chronosphere, compartilhou algumas de suas experiências, tanto positivas quanto nem tanto, na criação de ferramentas e sistemas destinados a seus colegas, e o que aprendeu e que aplica para sua empresa atual.

Muitas vezes, disse Skillington, os engenheiros pensam que a questão das ferramentas se resume a uma decisão de “construir ou comprar”. Mas é muito mais sutil do que isso e nem é a pergunta correta. Afinal, a menos que você esteja codificando seu próprio sistema operacional do zero e fabricando seus próprios microchips, você já estará construindo com base no trabalho de outra pessoa.

A primeira pergunta a fazer, disse ele à apresentadora do TNS, Heather Joslyn, é “Quais são as diferentes abstrações? E depois de entender as abstrações do que você está tentando fazer, você poderá começar a entender bem onde estão os limites nos quais você pode construir e comprar. E combine a construção e a compra em uma solução que resolva todo o problema.”

Também é importante construir não apenas no curto prazo, acrescentou. “Você não está resolvendo apenas hoje, no curto prazo. Você está resolvendo a longo prazo porque entende melhor todo o cenário.”

Pensar nesse sentido, disse Skillington, ajuda os inovadores a descobrir quais componentes individuais da solução proposta podem ser adquiridos e quais precisam ser personalizados. E eles também devem considerar se criaram um caminho para personalizar e dimensionar ainda mais suas ferramentas conforme as necessidades mudam.

“Se eu quiser rever esta decisão, poderei fazê-lo sem ter que alterar a interface entre as abstrações?” ele perguntou. “Os protocolos ainda continuarão funcionando?

Este episódio On the Road de Makers, gravado na KubeCon + Cloud Native Con North America em novembro, foi patrocinado pela Chronosphere, uma plataforma de observabilidade nativa da nuvem.

Lições da Uber e da Microsoft

Skillington citou um exemplo de sua época na Uber, a plataforma de compartilhamento de viagens. Sua equipe estava construindo uma plataforma de visualização para os engenheiros da empresa. Apesar do trabalho na nova plataforma, apenas cerca de 60 engenheiros a utilizavam diariamente.

Por outro lado, cerca de 1.000 engenheiros continuaram a usar diariamente a plataforma que as novas ferramentas deveriam substituir.

A lição aprendida: conheça seu público/base de clientes, inclusive quando os clientes são seus colegas de trabalho.

“Deveríamos realmente ter entendido isso como um KPI entrando no projeto, certo?”, Disse Skillington. “Não deu certo no final, ‘Oh, sim. Alguém está usando isso? É muito importante pensar um pouco antecipadamente.”

Outro obstáculo para que os colegas adotem novas ferramentas pode ser a síndrome do “não foi inventado aqui”: algumas organizações evitam qualquer coisa que não construíram.

Skilington iniciou sua carreira na Microsoft, cuja cultura tinha um forte caso de “síndrome do não inventado aqui”. A empresa muitas vezes melhorou os produtos que personalizou, reconheceu. “Mas eles estavam construindo coisas que não creio que necessariamente precisassem ser reconstruídas, pelo simples fato de serem reconstruídas.”

As empresas mais jovens, como o seu antigo empregador, o Uber, têm uma cultura mais rápida de agir e podem ter menos impulso para construir as suas próprias ferramentas, sugeriu ele.

Onde uma organização de engenharia se enquadra no espectro “não inventado aqui”, “aparece nas conversas com muita facilidade”, disse Skillington. “Como quando você está ao redor de uma mesa, um grupo de engenheiros no Zoom ou algum outro software de conferência, apenas vendo onde está o centro de gravidade quando as pessoas começam a propor maneiras de resolver problemas. Você pode ver se eles gravitam em torno de ‘devemos verificar como outras pessoas fazem isso ou devemos apenas pular para uma solução?’

Confira o episódio inteiro para saber mais sobre o que Skillington aprendeu com a construção de ferramentas e plataformas internas — incluindo M3, a plataforma de observabilidade que começou na Uber e se tornou a base do Chronosphere.

Você também pode conferir sua aparição anterior no TNS Makers.