Foco no processo, não no objetivo: como autonomia e ferramentas transformam equipes de TI

Pedro Fontes, diretor de Sistemas de Informação e Transformação Digital na EPAL, compartilhou recentemente uma perspectiva que desafia o senso comum da gestão por objetivos. Em vez de concentrar a energia no destino final, ele defende um olhar sistemático sobre o processo – cada etapa, cada decisão, cada ferramenta que capacita a equipe. Essa abordagem não é apenas filosófica; ela se traduz em métricas de produtividade, redução de retrabalho e aumento da autonomia técnica.

No contexto de engenharia de software e infraestrutura em nuvem, o "foco no processo" ganha contornos práticos. Quando uma equipe de desenvolvimento adota práticas como revisão contínua de código, integração e entrega contínuas (CI/CD) e observabilidade desde o início, o resultado final – um software funcionando – deixa de ser uma meta abstrata e se torna uma consequência natural do fluxo. O problema é que muitas organizações ainda insistem em medir apenas o entregável, ignorando a qualidade do caminho.

Fontes enfatiza que a chave para a transformação digital não está na tecnologia em si, mas na capacidade de oferecer às equipes instrumentos que promovam autogestão. Ferramentas de automação, plataformas internas de desenvolvedor e dashboards de métricas de processo são exemplos concretos. O líder técnico que compreende isso consegue extrair mais valor de times multidisciplinares, porque substitui o controle hierárquico por uma cultura de responsabilidade compartilhada.

Contexto técnico ou de negócio

A EPAL, empresa portuguesa de abastecimento de água, enfrenta desafios típicos de uma organização que precisa equilibrar operação crítica com inovação digital. A transformação digital não é um projeto com data de fim; é um processo contínuo de adaptação. Nesse cenário, Pedro Fontes lidera uma equipe que lida com sistemas legados, integrações com sensores IoT, modelos preditivos para manutenção de redes e plataformas de atendimento ao cliente. Cada uma dessas frentes exige um nível diferente de maturidade técnica e cultural.

O foco no processo, nesse ambiente, significa desenhar fluxos de trabalho que sejam resilientes a falhas e que permitam a cada profissional tomar decisões sem depender de aprovações burocráticas. Isso envolve desde a escolha de stacks tecnológicas (linguagens, frameworks, bancos de dados) até a definição de políticas de acesso a ambientes de produção. A autonomia não é dada por decreto; ela é construída com ferramentas que reduzem o atrito operacional.

Por que isso importa

Equipes que operam com foco cego no objetivo final tendem a queimar etapas. Pressionadas por prazos, cortam testes, ignoram dívida técnica e comprometem a segurança da informação. O resultado é um produto que funciona mal, gera incidentes e desgasta a relação com clientes internos ou externos. Em contrapartida, times que dominam o processo conseguem responder a mudanças de requisitos com muito mais fluidez. Em uma era de lançamentos frequentes e arquiteturas distribuídas, a capacidade de adaptação é um diferencial competitivo real.

Desenvolvimento

A abordagem de Fontes ecoa princípios conhecidos da gestão lean e do movimento DevOps. O que a diferencia é a ênfase em ferramentas que fomentem a autonomia. Não basta treinar a equipe em metodologias ágeis; é preciso fornecer um ecossistema técnico que elimine gargalos. Por exemplo, se um desenvolvedor precisa esperar três dias por um ambiente de staging, o processo está quebrado – independentemente de a meta de lançamento ser cumprida.

Na prática, a autonomia apoiada por ferramentas se manifesta em três camadas: infraestrutura, governança e cultura. Na infraestrutura, o uso de plataformas de autosserviço (como backstage ou painéis customizados) permite que os times provisionem recursos sem intervenção centralizada. Na governança, políticas as-code garantem que as decisões sigam padrões sem exigir análise manual. Na cultura, a transparência de métricas (lead time, frequência de deploy, MTTR) cria um ciclo de melhoria contínua baseado em dados reais.

Implicações operacionais

A transformação do processo impacta diretamente a gestão de riscos de segurança e privacidade. Quando uma equipe tem autonomia para alterar configurações de rede ou liberar acessos, o risco de desvios aumenta se não houver registros e alertas adequados. Por isso, a autonomia deve vir acompanhada de observabilidade e rastreabilidade. Ferramentas de logging centralizado, monitoramento de mudanças e trilhas de auditoria são indispensáveis para que o foco no processo não se torne um convite ao caos.

Outra implicação operacional relevante é o impacto no orçamento e na alocação de recursos. Times autônomos tendem a experimentar mais – o que gera mais aprendizado, mas também mais consumo de infraestrutura. Sem um processo claro de revisão de custos, o desperdício pode crescer. Por isso, a autonomia precisa estar calibrada com limites financeiros e alertas automáticos de orçamento.

• Automação de provisionamento: Em vez de abrir chamados para criar novas máquinas virtuais ou bancos de dados, a equipe usa formulários que disparam pipelines. O ganho é a redução do tempo de espera de dias para minutos, mas exige que o catálogo de serviços seja mantido atualizado e seguro.
• Políticas como código: Decisões de governança (quem pode acessar qual ambiente, quais portas estão abertas) são versionadas no git. Isso permite revisão entre pares e rollback rápido, dando autonomia sem abrir mão do controle.
• Dashboards de processo: Métricas como tempo de ciclo, taxa de falha em mudanças e cobertura de testes são exibidas em tempo real. A equipe visualiza gargalos e decide onde investir esforço, sem depender de relatórios da gestão.

Decisões técnicas ou editoriais

Ao estruturar este artigo, optei por não listar ferramentas específicas – como Kubernetes, Terraform ou GitLab – porque o foco editorial é o princípio de gestão, não a tecnologia em si. No entanto, é importante notar que a escolha de plataformas influencia diretamente o grau de autonomia possível. Ferramentas que exigem um time central de plataforma para configurar cada serviço tendem a engessar o processo, enquanto soluções self-service aumentam a agilidade.

Outra decisão editorial foi evitar a tentação de associar "foco no processo" exclusivamente a metodologias ágeis. Embora haja sobreposição, a abordagem de Pedro Fontes é mais ampla: ela se aplica a setores regulados, como o saneamento básico, onde a conformidade legal (como a LGPD) impõe controles que não podem ser ignorados. O equilíbrio entre autonomia e compliance é um dos maiores desafios que a liderança técnica enfrenta hoje.

Para o contexto de IA aplicada, o foco no processo é especialmente crítico. Modelos de machine learning exigem experimentação contínua, versionamento de dados e monitoramento de drift. Sem um processo bem definido, a equipe pode gastar semanas ajustando hiperparâmetros sem gerar valor de negócio. Ferramentas como MLflow ou Kubeflow são exemplos de plataformas que buscam dar autonomia para cientistas de dados, mas exigem maturidade de processo.

Riscos, limitações e perguntas em aberto

Um risco evidente da abordagem centrada no processo é a perda de visão estratégica. Equipes que se concentram demais em melhorar métricas internas (como lead time ou frequência de deploy) podem esquecer que o objetivo final é resolver problemas do cliente. A métrica mais bonita do mundo não vale nada se o produto não atende a uma necessidade real. Portanto, é fundamental que o processo inclua loops frequentes de validação com stakeholders.

Outra limitação é a dificuldade de implementar autonomia em organizações com cultura fortemente hierárquica. Líderes acostumados a controlar cada etapa podem sentir que estão perdendo poder. Sem um patrocínio executivo claro, as ferramentas de autonomia se tornam subutilizadas ou até boicotadas. Pedro Fontes menciona que a transformação digital na EPAL não foi linear – enfrentou resistências e exigiu paciência para construir confiança.

Por fim, uma pergunta em aberto é: como medir o sucesso do processo sem cair na armadilha de criar metas que distorcem o comportamento? Métricas como "número de deploys por dia" podem incentivar deploys vazios ou arriscados. A resposta passa por um sistema de métricas balanceadas (como DORA) e pela revisão periódica dos indicadores com a equipe, ajustando-os sempre que o comportamento observado se desvia do pretendido.

Aprendizados práticos

O primeiro aprendizado é que a autonomia não se decreta; ela se constrói com investimento em ferramentas e treinamento. Uma equipe só pode tomar decisões rápidas se tiver visibilidade sobre o impacto delas. Isso exige dashboards, logs e simulações de custo em tempo real. O líder técnico que ignora esse aspecto corre o risco de sobrecarregar a equipe com responsabilidade sem recursos.

O segundo aprendizado é que o foco no processo não elimina a necessidade de liderança. Pelo contrário: ele reposiciona o líder de "controlador" para "arquiteto de fluxos". O líder desenha os caminhos, remove obstáculos e garante que as ferramentas estejam disponíveis. Esse papel exige menos comando e controle e mais habilidade de design organizacional e comunicação.

O terceiro aprendizado, extraído da experiência de Pedro Fontes, é que a transformação digital é um processo em si mesmo. Não há um ponto de chegada em que "estamos transformados". A cada novo sistema, a cada nova regulação (como a LGPD), o processo precisa ser revisitado. A mentalidade de melhoria contínua, apoiada por dados, é o que garante que a autonomia evolua junto com o negócio.

Conclusão

A máxima de "não me foco no objetivo final, mas no processo" pode soar contraintuitiva em um mundo orientado por metas trimestrais. No entanto, a prática mostra que equipes que dominam o processo entregam com mais qualidade, consistência e capacidade de adaptação. Pedro Fontes nos lembra que a verdadeira transformação digital não está no destino, mas na jornada – e que o papel da liderança técnica é pavimentar essa jornada com as ferramentas certas.

Para profissionais de engenharia de software, IA aplicada e infraestrutura, vale a reflexão: a última vez que você melhorou um processo interno (um deploy, uma revisão de código, um provisionamento) gerou mais valor do que a última feature que você entregou? Se a resposta for não, talvez esteja na hora de reequilibrar o foco. O resultado final será consequência.