Tecnica E Tecnologia

Como unir técnica e tecnologia sem quebrar o que já funciona

A maioria dos artigos sobre o assunto começa defendendo que técnica e tecnologia são complementares. Na prática, o que você vê no dia a dia é bem diferente. A técnica é o conhecimento prático acumulado com tentativa e erro. A tecnologia é o artefato que tenta transformar esse conhecimento em algo reprodutível. Quando os dois se alinham, o resultado é eficiente. Quando não se alinham, você passa dias corrigindo o que uma solução automatizada fez errado.

Já vi times inteiros adotarem uma nova ferramenta de CI/CD porque o vendor prometeria redução de 40% no tempo de deploy. A média desse número varia entre 15% e 30% dependendo da maturidade do time. No caso que conheci, o tempo caiu mesmo, mas só porque o Deploy das 3h da manhã foi desabilitado e o time passou a aceitar jobs mais lentos mas mais confiáveis. A métrica melhorou, o problema real persistia.

Onde tecnica e tecnologia realmente se encontram

O ponto de contato não é o código. É o fluxo. Quando você mapeia um processo manual passo a passo antes de tentar automatizá-lo, descobre que pelo menos três daqueles passos já estão sendo feitos de formas diferentes por pessoas diferentes. Isso é normal. O erro é assumir que a automação resolve isso. Ela só deixa explícito onde estão as inconsistências.

Um exemplo concreto: numa migração de bancos relacionais para NoSQL, a equipe definiu primeiro o modelo de dados com base nas queries mais frequentes, não nas entidades do domínio. Isso invertia a lógica tradicional de normalização. O resultado foi que queries simples de agregação, que antes rodavam em milissegundos com índices compostos, passaram a demandar varredura completa. A técnica de modelagem foi aplicada de forma errada porque a tecnologia impôs uma restrição que ninguém considerou na fase de desenho.

Passo a passo prático

O processo que costuma funcionar melhor não começa com a escolha da ferramenta. Começa com a documentação do fluxo atual. Leva entre dois a cinco dias, dependendo da complexidade. No meu caso, utilizei mapas de processo em formato BPMN simplificado, com notação mínima: eventos de início, atividades manuais, decisões, e eventos de fim. Isso levou cerca de 3 horas para mapear um fluxo que envolvia oito envolvidos.

Depois do mapeamento, você identifica os gargalos. Gargalo aqui significa qualquer ponto onde o trabalho fica parado mais de 24 horas. Em processos típicos de desenvolvimento, os maiores gargalos estão em revisões de código e aprovações manuais. A tecnologia pode ajudar nos dois, mas cada um exige abordagem diferente. Para revisões de código, a estratégia é usar linting automático e checklists obrigatórios antes do humano entrar no processo. Isso elimina 60% a 70% dos problemas superficiais. O tempo médio de revisão cai de 45 minutos para cerca de 12 minutos quando o checklist é bem calibrado. O risco é que problemas estruturais escapem porque ninguém está mais olhando com atenção. A correção é manter um rodízio de revisores seniores que pegam amostras aleatórias.

Para aprovações manuais, a automação funciona quando o critério é binário e documentado. Se o critério depende de julgamento contextual, a automação gera mais retrabalho do que economia. Testei isso com regras de aprovação financeira automatizadas. Em casos onde o valor estava dentro da faixa e o beneficiário era previamente cadastrado, a aprovação ocorria automaticamente. Fora disso, o fluxo seguia para análise manual. O ganho foi de aproximadamente 55% de automação, com uma taxa de erro de 0,8% nos casos automatizados. Esse número parece baixo, mas multiplica rápido quando o volume é alto.

O que ninguém conta sobre a integração

A parte mais difícil não é técnica. É política. Quando você propõe automatizar um processo, pelo menos uma pessoa vai perceber que o automatismo reduz o poder de decisão dela. A resistência não é irracional. É estrutural. A solução que funcionou no meu ambiente foi criar um comitê de governança com representantes de cada área afetada, reunindo-se semanalmente durante as primeiras oito semanas. O custo foi de 2 horas semanais por participante. O benefício foi evitar que mudanças imporadas de cima para baixo gerassem rejeição passiva.

Outro ponto cego: a curva de aprendizado não é linear. Nos primeiros 30 dias após a implementação de uma nova ferramenta, a produtividade cai entre 15% e 25%. Isso é esperado. O que é surpreendente é a duração. Em dois casos que acompanhei, a produtividade só se recuperou depois de 90 dias, não de 30. A lição é simples: não avalie o sucesso de uma adoção tecnológica nos primeiros dois meses. Os números vão mentir para você.

Limitações e quando NÃO usar tecnologia

Existem cenários onde a tecnologia piora o resultado. Um deles é quando o processo é altamente variável e imprevisível. Se cada ocorrência exige decisão contextual única, a automação vai criar exceções que precisam ser tratadas manualmente, resultando em trabalho duplo. Nesse caso, a técnica de treinamento e padronização é mais eficiente do que qualquer ferramenta.

Outro cenário é a dependência excessiva de fornecedores. Quando você centraliza um processo crítico em uma plataforma de terceiros e o vendor faz uma breaking change sem aviso, você para. Isso aconteceu comigo com uma ferramenta de orquestração de contêineres. A atualização quebrou uma API interna que usávamos há dois anos. O vendor corrigiu em 11 dias. Nossos processos parados custaram cerca de R$ 47.000 em produtividade perdida. A alternativa seria ter mantido uma versão isolada ou desenvolvido uma camada de abstração própria. A recomendação prática é: antes de automatizar, pergunte se o processo pode ser simplificado primeiro. Em muitos casos, remover etapas desnecessárias gera mais ganho do que acelerar etapas que já existem. Reduzir um fluxo de sete etapas para quatro, mesmo que cada etapa continue manual, costuma entregar resultados superiores a automatizar as sete sem questionar sua existência.

O equilíbrio entre técnica e tecnologia não se encontra em ferramentas novas. Se encontra em entender o que realmente precisa ser feito antes de decidir como fazer. O resto é detalhe de implementação.