Criação e Manutenção de Ferramentas Internas para Equipes de DS/ML: Lições Aprendidas

Contribuição: Arthur Kamienski, Caique Lima, Sarah Malaman, Vitor Pinheiro

Introdução

Os profissionais de Ciência de Dados (DS) e Aprendizado de Máquina (ML) usam muitas ferramentas, embora isso nem sempre seja imediatamente óbvio. Sempre que importamos uma biblioteca para um notebook do Python ou executamos comandos como grep, find e sed em sistemas UNIX e similares, estamos aproveitando uma ferramenta que outra pessoa programou.

Mas também podemos programar as nossas próprias ferramentas. As ferramentas geralmente surgem quando alguém detecta uma funcionalidade repetida em vários produtos e projetos. O instinto natural do programador é extrair o comportamento comum para um local separado, a fim de evitar a duplicação e facilitar futuras mudanças. E é assim que nasce uma biblioteca de software.

O uso de ferramentas como bibliotecas (mas também de aplicações baseadas em interface de usuário, plataformas e aplicações de linha de comando) em toda a organização é algo comum nas empresas de tecnologia modernas. Essa estratégia é geralmente chamada de inner-sourcing. Embora ela ofereça vantagens consideráveis, também traz desafios que devem ser cuidadosamente analisados.

A criação de ferramentas de software para uso interno de toda a organização é conhecida como inner-sourcing na mídia técnica

Neste artigo, listaremos as lições que aprendemos ao longo dos anos, usando ferramentas internas no Nubank. Essas lições não são apenas sobre pontos técnicos, mas também questões subjetivas que devem ser consideradas para garantir o sucesso dessas ferramentas, tratando-as como produtos internos. 

Esse artigo foi escrito para equipes que criam e mantêm as ferramentas internas usadas por outras equipes, especialmente aquelas feitas para os casos de uso de DS e ML.

Vamos começar resumindo os porquês do desenvolvimento de ferramentas internas, com uma breve explicação sobre os tipos principais, e então listaremos as lições que consideramos mais importantes, sem ordem específica.

Conheça nossas oportunidades

Por que criar ferramentas internas?

Nós criamos ferramentas porque elas nos tornam mais eficazes e eficientes. Isso é verdadeiro no nível individual e organizacional, pois há muitos fenômenos emergentes e não-lineares que só ocorrem quando alcançamos uma certa escala.

As ferramentas promovem a padronização 

• Se as equipes usam um conjunto de bibliotecas em comum, é mais fácil fazer mudanças no âmbito de toda a empresa. Depois que uma nova versão da biblioteca é fornecida e todas as equipes a atualizam, as mudanças são aplicadas em toda parte. Geralmente, esse é o caso com ferramentas de segurança e logging.
• Se todas as equipes usam o mesmo conjunto de ferramentas, as pessoas podem mudar de equipe e alcançar rapidamente a produtividade.

As ferramentas aumentam o impacto das soluções locais

• As melhorias e otimizações criadas por pequenas equipes (ou até indivíduos) podem ser rapidamente compartilhadas entre todos na empresa. Esse é um enorme efeito amplificador, que fica maior conforme a própria empresa cresce.

As ferramentas codificam o conhecimento tácito

• As ferramentas codificam um conhecimento que, de outra forma, ficaria espalhado entre várias equipes, ou ainda pior, viveria apenas tacitamente na cabeça de algumas pessoas essenciais. Depois que elas saem da empresa, o conhecimento também é perdido.

As ferramentas reduzem o risco e os erros

• Usar um conjunto em comum de bibliotecas/funções robustas e testadas é muito menos arriscado do que exigir que cada equipe construa suas próprias versões. 
• As ferramentas podem ser usadas para impor regras e princípios a toda a empresa, incorporando-os no código. Isso inclui recursos de controle de acesso e logging, por exemplo.

As ferramentas reduzem o TTM 

• Sem analysis paralysis: não é necessário gastar tempo pesquisando qual é a melhor forma de lidar com cada problema quando existe uma ferramenta padrão criada para isso.

Tipos de ferramentas internas

As ferramentas de software são só mais código. Mas se olharmos mais de perto, existem tipos diferentes de ferramentas em relação à interface que elas oferecem aos usuários e os recursos que elas fornecem. Cada um deles tem um papel separado na organização de tecnologia.

Uma distinção importante é entre as ferramentas táticas e estratégicas: aquelas que são usadas por no máximo uma ou duas equipes e aquelas que podem ser compartilhadas com toda a empresa, possivelmente se tornando um ativo importante para a companhia.

Temos os seguintes tipos principais: Aplicativos baseados em interface gráficae linha de comando, bibliotecas e plataformas.

É fácil ver a diferença entre aplicativos baseados em interface gráficae interface de linha de comando, mas isso não é verdade em relação a bibliotecas e plataformas: uma diferença importante é que as plataformas geralmente exigem que o usuário faça uso integral dela. Normalmente, não é possível escolher quais partes da plataforma você deseja usar. Ou você a usa toda, ou não usa. Compare isso com as bibliotecas: você pode usar várias bibliotecas ao mesmo tempo, combinando-as de várias formas, mas depois de escolher uma plataforma, você tem que continuar com ela.

As bibliotecas são coleções de software que permitem que você escolha o que quer usar. De forma geral, as plataformas são rígidas – impondo decisões de design que você não pode recusar.

Outra diferença é que as plataformas geralmente são rígidas. Decisões de design claras são feitas e você precisa aceitá-las, se escolher usar a plataforma. Por esse motivo, as plataformas são ótimas para impor a padronização e as diretrizes da organização que devem ser seguidas por todas as equipes.

Agora que concluímos a introdução, vamos passar ao artigo em si.

As ferramentas internas são produtos e devem ser gerenciadas como tal

As ferramentas internas são produtos e devem ser gerenciadas como tal. É necessário pensar nos usuários internos como clientes, o que às vezes é difícil, devido à proximidade e à informalidade das operações do dia a dia.

Seria ideal ter gerentes de produto dedicados, para entender e interagir com os usuários e definir prioridades conforme as necessidades deles. Se isso não for possível, deve haver pelo menos algumas pessoas com habilidades de gerenciamento de produto na equipe.

O mínimo que você precisa para gerenciar um produto interno é um plano de desenvolvimento claro, feedback estruturado dos usuários e um bom canal de suporte.

• Roadmap: Um roadmap claro e público, com marcos, ajuda os usuários e a equipe de desenvolvimento a entender o que foi planejado e quais tarefas têm prioridade sobre as outras. 

• Rotinas estruturadas de feedback: Você precisa consultar os usuários periodicamente para receber feedback positivo e negativo. Uma combinação de perguntas curtas e objetivas com um espaço aberto para feedback geralmente funciona bem. O feedback anônimo é preferível para garantir que os clientes não deixem de fazer críticas por causa da política de escritório. Deixe claro que qualquer feedback (especialmente críticas construtivas) é bem-vindo.

• Canais de suporte: No início, um canal do Slack pode servir, mas é difícil de escalar conforme o número de usuários aumenta: logo você pode precisar de sistemas de bilhetagem ou acompanhamento de casos para lidar com a carga, o que permite que você quantifique e meça o quão bom é o suporte. 

Exemplos e uma boa documentação ajudam a reduzir a necessidade de suporte 1:1. Além disso, certifique-se de que os usuários saibam como pesquisar no Slack para encontrar respostas a perguntas frequentes.

A divulgação é essencial

Geralmente, as pessoas não querem aprender a usar mais uma ferramenta, ainda mais se as vantagens não forem imediatamente claras. Devemos praticar ativamente a divulgação, promovendo a ferramenta para os usuários em potencial.

Em algumas instâncias, a adoção de uma ferramenta pode ser obrigatória por meio de abordagens impostas pela empresa, como incorporá-la aos objetivos e resultados-chave (OKRs) ou outras estruturas de definição de metas corporativas. Nesses cenários, provavelmente a divulgação não é muito necessária. Mas esse não é o nosso foco: preferimos criar ferramentas que os usuários queiram usar, porque entendem o valor delas, e não porque são forçados a isso.

Uma boa ferramenta que “apenas funciona” e é apreciada sempre precisará de menos marketing do que uma ferramenta detestada pelos usuários. 

Do ponto de vista dos clientes, usar uma nova ferramenta significa ter que aprender a usá-la e, talvez, mudar algum aspecto de seu trabalho. 

Isso pode ser uma barreira importante, porque as pessoas geralmente resistem à mudança, ainda mais quando isso envolve modificar um fluxo de trabalho que já conhecem bem e estão acostumadas. Vários fatores são importantes aqui: as percepções sobre a segurança no trabalho, questões de ego e ideias de perda de influência. As pessoas não gostam de abandonar algo que passaram 2 anos aprendendo, ainda mais se acharem que isso lhes traz status na empresa.

Na nossa experiência, é melhor demonstrar valor primeiro. Se você fizer isso corretamente, a decisão de adotar a sua ferramenta será óbvia e fácil. Eis como:

• Projetos-piloto: A própria equipe de desenvolvimento pode executar projetos iniciais usando a ferramenta para gerar as primeiras histórias de sucesso e incentivar a adoção.

• Canais de suporte: Acreditamos que cerca de 30% do sucesso de uma ferramenta vem de um bom suporte. Um canal dedicado do Slack para assistência imediata e sem julgamento aumenta muito a disposição dos usuários de interagir com a ferramenta.

• Recursos acessíveis: Fornecer muitos exemplos e manter um repositório com código-fonte claro e bem escrito ajuda os usuários a entender e usar facilmente a ferramenta. O canal de suporte (por exemplo, Slack) também serve como um repositório pesquisável de soluções, facilitando ainda mais o aprendizado dos usuários.

• Quantificação de benefícios: Demonstrar o possível impacto da ferramenta em termos de economia de tempo e dinheiro ajuda a promover sua adoção de forma convincente. Use valores monetários e estimativas de tempo (como horas-homem economizadas) aproximadas para tornar o impacto mais concreto.

Logging, instrumentação e feedback de usuários

Ao criar ferramentas internas, existe um risco real de supor que sabemos do que os nossos usuários precisam e como eles usam nossas ferramentas.

Em vez disso, use dados. Sem dados, o gerenciamento de produto é reduzido à tomada de decisões baseadas em palpites, o que a transforma em um exercício puramente político, em que a opinião da pessoa com maior remuneração vence.

Coletar informações permite que a equipe de manutenção compreenda como os usuários utilizam a ferramenta. Isso ajuda a medir a satisfação do cliente e a detectar áreas de foco para melhorias, tornando a manutenção mais eficaz.

Nós vemos duas formas principais de coletar informações: implícita e explícita, respectivamente por meio de instrumentação do sistema e pesquisas. Cada uma delas fornece insights a partir de um ângulo diferente e ambas têm vantagens e desvantagens.

Duas formas de coletar dados de uso de ferramentas: implícita (logs e instrumentação) e explícita (pesquisas com usuários)

Colete dados implicitamente por meio de logs e instrumentação. Toda linguagem de programação suporta o registro em log, que pode ser visualizado em ferramentas como Splunk ou Grafana. A maior vantagem do feedback implícito é que ele é impossível de falsificar – mas dá trabalho para configurar.

Aqui estão alguns exemplos de informações que podem ser obtidas com logs:

• Quantos clientes estão usando a ferramenta ao longo do tempo?
• Quais funcionalidades ou componentes específicos são mais usados?
• Mensagens de erro/exceções;
• Detectar usuários que começaram a usar a ferramenta mas eventualmente a abandonaram;
• Medir tempos de carregamento e resposta.

Por outro lado, as pesquisas com usuários são boas para obter feedback de forma explícita, desde que os usuários se sintam confortáveis com isso. O maior risco é que os clientes internos evitem dar um feedback honesto negativo, por medo de retaliação e da política de escritório. Para evitar isso, as pesquisas com usuário devem ser anônimas.

As pesquisas com usuários devem ser anônimas. As pessoas nunca ficarão à vontade para fornecer feedback negativo se acharem que os comentários poderão prejudicar sua carreira na empresa.

Ao escolher pesquisas como Formulários do Google, considere o tempo dos seus clientes: Inclua o máximo possível em um formulário curto. As pessoas têm coisas melhores para fazer do que responder a uma pesquisa de 20 páginas sobre o seu produto.

Dê preferência a perguntas com respostas classificadas numericamente (como a escala de Likert) para permitir comparações ao longo do tempo e que sejam tão específicas quanto possível: “Em uma escala de 1 a 5, quanto você diria que a ferramenta X aumentou sua produtividade ao realizar a tarefa Y?”

Por fim, lembre-se de incluir uma ou duas perguntas abertas para receber opiniões gerais e conselhos dos usuários.

Os exemplos são o melhor tipo de documentação

Ter uma documentação é um requisito comum das ferramentas internas, especialmente quando você precisa atender usuários não técnicos. 

Porém, custa muito caro criar e manter uma boa documentação. Acrescentar recursos às ferramentas sempre terá prioridade sobre a atualização dos documentos. Então, a ferramenta evolui e a evolução fica defasada.

É comum que a documentação fique ultrapassada com o tempo e sofra uma morte lenta, eventualmente chegando ao ponto em que ninguém mais confia nela. Às vezes, ela se torna abertamente enganosa: instruções que não fazem mais sentido, referências a recursos que foram alterados, etc.

Além disso, ninguém quer ler a documentação. Os usuários querem resolver as coisas o mais rápido possível. Geralmente, a forma mais rápida é ver exemplos e tentar descobrir como adaptá-los para o seu próprio caso de uso. Facilite a vida deles com um conjunto de exemplos canônicos como parte da documentação oficial.

Hoje em dia as pessoas têm uma capacidade de atenção reduzida e ninguém tem tempo ou vontade de ler a documentação para aprender como algo funciona, exceto como último recurso. Em vez disso, foque nos exemplos.

Além dos benefícios acima, um bom conjunto de exemplos também ajuda a reduzir o esforço do suporte. Isso evita que as equipes de suporte tenham que lidar com perguntas que poderiam ser respondidas indicando um exemplo.

Os exemplos também podem servir como  testes de integração para as ferramentas, garantindo que os exemplos sejam sempre validados com as novas versões, como parte do seu fluxo de CI/CD. Agora, a sua documentação é testável, o que é o melhor de dois mundos, impedindo que ela fique desatualizada.

Por fim, os exemplos ajudam a impedir a propagação de “más práticas” entre a base de usuários. É surpreendente quantos usuários copiam e colam o código de outras pessoas para tentar fazer as coisas funcionarem.

Os exemplos são o melhor tipo de documentação, especialmente para ferramentas internas que serão usadas por pessoal técnico, como profissionais de dados. Eles são mais fáceis de criar, validar e manter do que o texto escrito. Eles estão mais próximos da origem (o código-fonte) e são consumidos mais rapidamente. Os exemplos só ficam abaixo do próprio código.

Manter a consistência

Quando alguém usa uma ferramenta, ele precisa criar um modelo mental de como ela funciona. Um único exemplo é a configuração dos pedais em carros manuais. 

As marcas de carro variam muito em relação às cores e tamanhos, e até o lado onde fica o volante, mas são consistentes em relação à configuração dos pedais: depois que você criou um modelo mental de como usá-los, você pode confiar no modelo independentemente do carro que estiver dirigindo.

Agora, imagine se cada marca de carro tivesse uma configuração de pedais diferente. Ao dirigir um novo carro, você não saberia o que esperar e precisaria criar um novo modelo mental, reaprendendo a dirigir.

Os carros diferem muito em relação às cores, estilos e tamanhos, mas são consistentes na configuração dos pedais: o modelo mental (embreagem, freio e acelerador) geralmente não varia.

As ferramentas internas como bibliotecas e plataformas também são assim. Quanto mais consistente for uma ferramenta, usando os mesmos padrões, nomenclatura, estrutura e convenções em todas as partes, mais rápido os usuários poderão criar um modelo mental, e mais intuitiva a ferramenta será.

Isso ajuda a impedir erros, reduz a necessidade de suporte e, mais importante, reduz a carga cognitiva da sua ferramenta. Usar uma ferramenta consistente significa que depois de aprender a realizar uma tarefa específica, você terá aprendido todas elas, como acontece com os carros e a configuração dos pedais.

Todos nós conhecemos ferramentas que parecem fáceis e intuitivas, e aquelas que nunca nos lembramos de como usar (e precisamos procurar exemplos no Google constantemente). Pandas e Matplotlib são bons exemplos: embora sejam bibliotecas muito boas, há alguma inconsistência nos nomes, na ordem dos argumentos e na semântica das funções.

Uma boa regra para seguir é o princípio da menor surpresa, onde você, o mantenedor da ferramenta, sempre escolhe estruturar as coisas de uma forma que pareça mais natural ou menos surpreendente para o usuário.

O princípio da menor surpresa: no design de interfaces, sempre faça a coisa menos surpreendente.

A maior vantagem da consistência é reduzir a carga mental dos usuários, mas descobrimos que isso ajuda até na capacidade de descoberta: os usuários são capazes de explorar melhor as suas ferramentas se as coisas tiverem nomes e estruturas consistentes.

Aqui estão algumas dicas práticas sobre como alcançar a consistência nas ferramentas internas:

• Convenção antes da configuração: Popularizada pela estrutura Ruby on Rails, essa dica diz que as coisas precisam seguir alguma convenção por padrão. Por exemplo, as classes devem ser nomeadas como FooBar (CamelCase) e a tabela correspondente no banco de dados deve se chamar foo_bar (snake case).

• Ordenação consistente de parâmetros: Mantenha consistente a ordem dos argumentos das funções! Se você tem várias funções em que cada uma recebe um nome e um caminho_do_arquivo, faça isso de forma que a ordem de parâmetros seja sempre a mesma! Por exemplo, nome será sempre o primeiro argumento e caminho_do_arquivo será sempre o segundo.

• Estrutura consistente: Se você estruturar uma biblioteca em pastas, certifique-se de que todas sigam os mesmos padrões, por exemplo: países/áreas de negócios/grupos. Isso ajuda os usuários a encontrar as coisas com mais facilidade.

• Ordenação consistente: Ao listar qualquer coisa, ordene as coisas da mesma forma. Encontrar as coisas é muito mais fácil se você souber que elas estão em ordem alfabética, por exemplo.

• Use os mesmos nomes para as mesmas coisas: Se a sua ferramenta usa elementos visuais e você decidiu chamá-los de “elementos“, sempre os chame de “elementos”, no código-fonte, na documentação e em todos os lugares. Não use “componentes visuais”, nem “widgets”. Usar nomes diferentes para as mesmas coisas (ou, inversamente, o mesmo nome para coisas diferentes) dificulta para os usuários a compreensão de ferramentas complexas.

Cuidado com as dependências

Conforme as pessoas começam a usar as ferramentas que você cria, elas inevitavelmente começarão a depender dessas ferramentas para fazer o trabalho. Se a ferramenta mudar de formas inesperadas, isso afetará os usuários e os impedirá de trabalhar.

Na verdade, isso é um problema positivo, pois significa que as pessoas estão extraindo valor suficiente das suas ferramentas para integrá-las em seus fluxos de trabalho. As únicas ferramentas sem problemas de dependência são aquelas que ninguém usa.

Mas as dependências são um problema porque limitam a capacidade de mudar e melhorar as ferramentas: as atualizações podem atrapalhar os fluxos de trabalho que dependem atualmente das ferramentas.

Como qualquer software, as ferramentas internas precisam mudar e evoluir, conforme mais recursos são adicionados. Porém, quanto mais forte o acoplamento que o usuário fizer entre a sua ferramentas e os fluxos de trabalho, mais difícil será adicionar recursos e fazer as alterações necessárias para combater a entropia e a obsolescência do software.

Você precisa limitar o acoplamento entre os usuários e as ferramentas, para que quando chegar o momento de adicionar recursos e refatorar, seja possível fazer isso com segurança.

Mais especificamente:

• Você precisa de testes de integração abrangentes para validar que a API voltada para o usuário continue estável conforme você adiciona recursos e faz alterações. Sem os testes de integração, os mantenedores jamais terão confiança suficiente para fazer grandes mudanças na base de código, o que leva à degradação e obsolescência do código. Você também ganha pontos de bônus se os adicionar aos seus fluxos de trabalho de CI/CD.

• Use o controle de versões desde o início. Para bibliotecas, use semver (controle de versão semântico), que ajuda os usuários a escolher versões específicas das ferramentas para usar de forma previsível. Para outros tipos de ferramentas, certifique-se de que os usuários saibam com qual versão (v1, v2 etc.) da ferramenta estão trabalhando. Isso permite que você, o mantenedor da ferramenta, crie novas versões, além de manter as antigas ainda ativas.

• Nas bibliotecas, limite o uso de elementos públicos, como classes e funções. Em linguagens dinâmicas, como Python, os usuários ainda são capazes de invocar elementos privados, mas sabem que estão operando por sua própria conta e risco.

• Desacople a API pública da implementação interna. Isso inclui padronizar a sintaxe e criar estruturas melhores de importação para invocar a funcionalidade central da ferramenta. Isso permite que você faça as mudanças necessárias nas partes internas da ferramenta, e tudo funcionará desde que a API pública continue a mesma. 

A Lei de Hyrum é uma interpretação extrema do problema da dependência. Ela define que os clientes dependerão não só da API pública exposta pela sua ferramenta, mas também de qualquer comportamento observável que possa ser inferido ou visto de fora. 

De acordo com a Lei de Hyrum, cada detalhe público que possa ser visto – ou inferido – de fora eventualmente causará dependência em alguém, conforme o número de clientes aumenta.

Inicialmente, a lei era sobre dependências entre módulos de software, mas a analogia ainda é válida. É impossível garantir que nunca haverá mudanças disruptivas quando você atualiza as suas ferramentas. Ainda assim, há muitas coisas que nós, mantenedores da ferramenta, podemos fazer para reduzir os riscos, mantendo as APIs estáveis e garantindo que a ferramenta seja atualizada sempre que necessário.

O raciocínio 80/20

As boas ferramentas não tentam incluir o mundo todo. Elas têm um equilíbrio entre quanta liberdade e quantos limites vão expor aos usuários: se os limites forem poucos demais, as ferramentas serão muito desestruturadas e difíceis de usar. Se forem em excesso, os casos de uso avançados ficarão de fora.

Você deve se concentrar em garantir que os 80% de tarefas comuns apenas funcionem de forma natural, intuitiva e eficiente. Mas você também deve deixar espaço para os casos de uso avançados: os 20% restantes. Isso significa suportar algum nível de personalização a fim de atender usuários avançados, que às vezes têm casos de uso complexos e incomuns que você nunca chegou a considerar.

Com uma boa ferramenta, os 80% dos casos de uso são facilitados, enquanto os 20% restantes tornam-se possíveis.

Os usuários sempre darão um jeito de fazer o trabalho. Se não puderem adaptar a sua ferramenta para o caso de uso deles, eles não vão usá-la. Ponto final. Como mantenedor, é sua responsabilidade criar uma ferramenta que apenas funcione para os casos de uso mais simples, mas que possa ser personalizada para os mais avançados.

As ferramentas de aquisição interna têm o código aberto dentro da empresa. Portanto, a primeira forma de incentivar a personalização é seguir boas práticas de ES e criar código limpo, para que os próprios usuários possam entendê-lo e contribuir com Pull Requests (PRs) para a base de código. 

Para nós, três estratégias foram especialmente úteis:

A orientação a objetos permite a sobrescrita fácil da funcionalidade padrão

A programação orientada a objetos não é adequada para todos os casos de uso, mas funciona bem quando você quer expor componentes que podem ser ampliados pelos usuários, se necessário. Isso é ainda mais fácil em linguagens dinâmicas, como o Python (a língua franca do mundo de CD/AM), em que você pode estender as classes centrais e sobrescrever (override) o comportamento padrão durante o tempo de execução apenas adicionando métodos.

Isso já se mostrou útil em muitas ocasiões. Muitos usuários avançados sabem programar, então eles hackeiam uma forma de conseguir o que quiserem, criando subclasses levemente modificadas em seu próprio código.

Padrões sensatos

A maioria das ferramentas possui opções de configuração. Pode ser um arquivo “config”, uma tela de opções em um aplicativo ou algo assim. As opções de configuração permitem a personalização pelo usuário, então você precisa delas. Mas não é desejável que os usuários precisem configurar opções para cada uma das tarefas. 

As opções de configuração devem ter padrões sensatos que atendam à maioria dos casos, mas também devem permitir a personalização quando isso for apropriado. Decidir quais valores padrão devem ser usados exige que você compreenda o usuário médio e como ele usa a sua ferramenta. Descubra isso entrevistando-os e estudando as necessidades deles.

Facilidade de uso antes da elegância do código, sempre

Quando você tiver que escolher entre a facilidade de uso e a elegância do código interno, escolha a facilidade de uso, mesmo se isso causar uma dívida técnica.

É mais difícil se recuperar da perda de usuários do que da perda temporária de qualidade no código, que deve ser fácil de corrigir se você isolar o código adaptador das regras de negócios centrais, como sugerimos na seção Cuidado com as Dependências desse blog post.

Conclusão

Há muitas formas de evitar, ou ao menos minimizar, os problemas ao criar e manter ferramentas internas, especialmente para usuários técnicos como Cientistas de Dados e Engenheiros de Aprendizado de Máquina.

Se tivéssemos que fazer o menor resumo dessas lições, diríamos: 

• (a) Trate as ferramentas internas como produtos e os usuários como clientes. Tudo começa aqui;
• (b) Compreenda os incentivos. É melhor usar a cenoura do que o chicote;
• (c) Tenha formas de rastrear como a sua ferramenta está sendo usada, tanto implícita quanto explicitamente.