Por que seus engenheiros nos odeiam (mas amam nossos resultados)

Muitas equipes de engenharia chegam a um ponto em que a capacidade interna não é mais suficiente. Um produto pode precisar de uma análise de segurança. Um sistema legado pode exigir alguém com rara experiência em plataforma. Um lançamento pode depender de uma tarefa curta que não justifica uma contratação permanente. É aqui que os engenheiros externos podem ajudar. Eles não são um substituto para a equipe principal. O especialista externo certo dá aos seus engenheiros acesso a habilidades, tempo e experiência que talvez ainda não existam dentro da empresa. ## Por que as equipes internas chegam ao exterior Muitas vezes vejo os mesmos pontos de pressão: - Uma equipe pequena deve oferecer suporte tanto a novos recursos quanto a sistemas antigos. - Um projeto precisa de uma habilidade que a empresa utiliza apenas uma ou duas vezes. - Os engenheiros seniores gastam muito tempo resolvendo problemas rotineiros de produção. - Um problema de segurança, nuvem ou dados requer uma análise independente. - Contratar um especialista a tempo inteiro criaria um custo a longo prazo para uma necessidade a curto prazo. Uma empresa pode ter engenheiros de produto fortes, mas ninguém que tenha gerenciado uma grande migração para a nuvem. Outra equipe pode entender bem seus clientes, mas não ter experiência com segurança de pagamentos, desempenho móvel ou pipelines de dados. A diferença nem sempre significa que a equipe é fraca. Pode simplesmente significar que o negócio atingiu um novo estágio. ## Os especialistas externos que sua equipe pode precisar ### 1. Engenheiros de nuvem e de plataforma Os custos da nuvem podem aumentar sem um motivo claro. Implantações lentas, recursos não utilizados e monitoramento fraco geralmente criam trabalho extra para a equipe interna. Um engenheiro de plataforma externo pode revisar: - Uso e gastos da nuvem - Fluxos de trabalho de implantação - Regras de monitoramento e alerta - Planos de backup e recuperação - Permissões de acesso - Confiabilidade do serviço O objetivo não é mover todos os sistemas para uma nova plataforma. Um especialista útil explica o que deve permanecer, o que precisa de atenção e o que pode esperar. ### 2. Especialistas em segurança O trabalho de segurança geralmente aparece depois que um produto já cresceu. A equipe original pode ter se concentrado nos recursos de envio, enquanto os controles de acesso, registro e processos de revisão permaneceram básicos. Um engenheiro de segurança externo pode testar o sistema de um novo ângulo. Isso pode incluir: - Revisão de permissões de conta - Verificação de serviços expostos - Teste de caminhos de ataque comuns com aprovação por escrito - Inspeção do gerenciamento de dependências - Criação de um plano de resposta para eventos de segurança Este trabalho deve ser definido cuidadosamente. Uma empresa deve saber quais sistemas estão incluídos, quais testes são permitidos e como as descobertas serão tratadas. ### 3. Especialistas em sistemas legados Sistemas antigos podem conter anos de regras de negócios. Substituí-los muito rapidamente pode criar mais riscos do que mantê-los. Um especialista que entende a linguagem, estrutura ou banco de dados usado pelo sistema legado pode ajudar a equipe a: - Documentar processos-chave - Identificar áreas frágeis - Adicionar testes em torno de funções críticas - Planejar pequenas etapas de substituição - Treinar engenheiros internos Prefiro essa abordagem a uma reescrita repentina. Um sistema estável com documentação clara costuma ser mais útil do que um sistema novo que a equipe ainda não entende. ### 4. Engenheiros de dados e aprendizado de máquina Muitas empresas coletam mais dados do que podem usar. O problema pode não ser a falta de dados. Pode ser uma estrutura deficiente, propriedade pouco clara ou relatórios não confiáveis. Um engenheiro de dados externo pode ajudar a construir: - Pipelines de dados - Tabelas de relatórios - Verificações de qualidade - Regras de acesso - Modelos de previsão - Painéis internos A questão comercial deve vir antes da ferramenta. Um modelo não resolve um problema quando a equipe não concorda sobre o que medir. ### 5. Especialistas em experiência e desempenho do usuário Os engenheiros podem saber que um produto parece lento, mas podem não saber qual problema afeta mais os usuários. Um especialista pode examinar: - Tempo de carregamento da página - Comportamento móvel - Taxas de erros - Fluxo de checkout - Acessibilidade - Navegação do produto Um exemplo público pode ser visto em grandes projetos de código aberto, como o Kubernetes. O projeto recebeu trabalho de engenheiros de muitas empresas, não apenas da organização que o iniciou. Colaboradores externos trazem habilidades e tempo que ampliam a capacidade da equipe principal de manter o projeto. O mesmo padrão pode funcionar dentro de uma empresa quando as responsabilidades são claras. ## Como decido se a ajuda externa faz sentido, faço quatro perguntas antes de procurar um empreiteiro ou uma equipe de consultoria. ### O problema é específico? “Tornar o produto melhor” não é uma tarefa externa adequada. “Revisar nosso processo de implantação e reduzir as etapas de liberação manual” dá ao engenheiro uma orientação clara. ### A habilidade é necessária por um período limitado? A ajuda externa adapta-se a projetos curtos, análises de especialistas e lacunas temporárias de capacidade. Uma responsabilidade permanente pelo produto pode precisar de um proprietário interno. ### A equipe pode explicar o sistema atual? Um engenheiro externo não pode trabalhar bem com falta de acesso, documentação pouco clara ou tomadores de decisão desconhecidos. A equipe interna deve preparar: - Diagramas de sistema - Acesso ao repositório - Problemas técnicos atuais - Objetivos de negócios - Limites conhecidos - Uma pessoa que possa responder perguntas ### Como o sucesso será medido? Boas medidas dependem da tarefa. Para uma revisão da nuvem, a medida pode ser uma lista clara de ações de custo e confiabilidade. Para uma revisão de segurança, pode ser um relatório de risco classificado com proprietários e datas previstas. Para trabalho de desempenho, pode haver um tempo de resposta mais rápido nas jornadas acordadas do usuário. Evite medir o sucesso apenas pelas horas trabalhadas. O resultado útil é uma melhor compreensão, menos riscos ou um sistema que a equipe interna possa manter. ## Como trabalhar com engenheiros externos O relacionamento geralmente funciona melhor quando o engenheiro externo se junta a um processo definido em vez de receber uma lista vaga de tarefas. Eu recomendo esta estrutura: 1. Escreva um breve resumo do projeto. Descreva o problema de negócios, o sistema atual, o resultado esperado, o prazo e os limites. 2. Nomeie um proprietário interno. Essa pessoa responde perguntas, analisa decisões e mantém o trabalho conectado aos objetivos da empresa. 3. Conceda acesso em etapas. Comece com as informações necessárias para a descoberta. Expanda o acesso depois que o escopo estiver claro. 4. Estabeleça pontos de revisão regulares. Uma breve reunião semanal pode expor confusão antes que ela se transforme em retrabalho. 5. Exigir documentação. Solicite decisões, etapas de configuração, riscos e itens inacabados em um local compartilhado. 6. Planeje a transferência com antecedência. Os engenheiros internos devem compreender as mudanças antes que o envolvimento externo termine. Esse processo também protege a empresa. Limita o acesso, mantém o conhecimento dentro da empresa e reduz a dependência de uma pessoa. ## Erros comuns Algumas equipes contratam um engenheiro externo e esperam que essa pessoa resolva todos os problemas técnicos. Isso cria confusão. Outras equipes não dão contexto ao especialista. O engenheiro então melhora uma parte do sistema, ignorando uma restrição de negócios. Um terceiro erro é escolher com base apenas em uma tarifa horária baixa. Uma contratação mais barata pode levar mais tempo quando o especialista precisa aprender o sistema do zero ou corrigir trabalhos pouco claros. Procuro evidências de experiência relevante, comunicação clara, documentação prática e disposição para explicar compensações. Um engenheiro externo forte deveria se sentir confortável em dizer: “Essa mudança ainda não é necessária”. ## O objetivo é uma equipe interna mais forte. O melhor suporte externo faz mais do que concluir uma tarefa. Ajuda os engenheiros internos a ver o sistema de outro ângulo. Deixa para trás documentação, testes, decisões e habilidades que a empresa pode usar após o término do trabalho. Antes de contratar ajuda externa, defina a lacuna. Decida o que a equipe interna deve reter. Dê ao especialista um problema específico, acesso adequado e um plano de transferência claro. O estranho certo não tira a propriedade dos seus engenheiros. Eles ajudam seus engenheiros a dedicar mais tempo ao trabalho que só eles podem realizar.

Os engenheiros não resistem à mudança porque não gostam do progresso. Eles resistem a afirmações pouco claras, evidências fracas, decisões precipitadas e ferramentas que criam mais trabalho para a equipe. Quando um novo sistema afeta a produção, os testes, a manutenção ou a segurança, o ceticismo é uma resposta prática. Os engenheiros sabem que uma pequena mudança em um processo pode criar atrasos em outro lugar. Já vi esse padrão muitas vezes. Um projeto começa com respostas curtas como “isso economizará tempo” ou “a configuração é fácil”. A equipe de engenharia solicita dados de teste, detalhes de integração, limites de falha e planos de suporte. Se essas questões forem ignoradas, a confiança cai rapidamente. Essa reação não é uma barreira. É um feedback útil. Recebo apoio dos engenheiros respeitando a maneira como eles avaliam os riscos. ### Começo com o problema que eles já acham que os engenheiros raramente precisam de outra promessa geral. Eles precisam de ajuda com um problema específico: - Verificações manuais repetidas - Ciclos de aprovação lentos - Dados de produção pouco claros - Manutenção difícil do sistema - Muitos alertas falsos - Ferramentas que não se adaptam ao equipamento existente - Relatórios que levam horas para serem preparados Pergunto onde está sendo perdido tempo, quais erros aparecem com mais frequência e quais tarefas a equipe evitaria alterar a menos que o benefício fosse claro. As respostas moldam a discussão. Uma equipe de manutenção pode se preocupar com menos interrupções. Um grupo de design pode se preocupar com dados de teste mais limpos. Um gerente de fábrica pode se concentrar na produção e no tempo de treinamento. Uma mensagem não pode servir a todas as funções. ### Eu mostro como a solução se adapta ao processo atual A resistência geralmente aumenta quando um produto é apresentado como um substituto completo para um fluxo de trabalho existente. Os engenheiros querem saber o que permanece, o que muda e o que acontece se o novo processo não funcionar conforme o esperado. Explico os pontos de conexão em linguagem simples: - Quais dados o sistema recebe - Com quais equipamentos ou software ele se conecta - O que o operador vê - O que pode ser ajustado - Como os resultados são verificados - Como a equipe pode retornar ao processo anterior Esse nível de detalhe dá às pessoas algo que elas podem revisar. Também revela problemas antes que se tornem caros. Uma demonstração útil não esconde as partes difíceis. Mostra a configuração, o fluxo de trabalho diário e os limites. Se a ferramenta precisar de dados de entrada limpos, eu digo isso. Se o treinamento demorar, incluo isso no plano. ### Deixei a equipe testar a afirmação. Uma apresentação de slides pode criar interesse. Um teste controlado cria confiança. Normalmente sugiro um pequeno piloto com um ponto de partida claro. A equipe seleciona um processo, um grupo de usuários ou um tipo de tarefa. Registramos a condição atual antes de fazer alterações. As medições podem incluir: - Tempo gasto na tarefa - Número de etapas manuais - Correções de erros - Tempo de inatividade vinculado à tarefa - Perguntas do usuário ou solicitações de suporte - Resultados de qualidade após a mudança A equipe então compara os resultados do piloto com o registro anterior. Essa abordagem dá aos engenheiros uma maneira justa de julgar o produto sem pedir-lhes que aceitem uma promessa ampla. Por exemplo, uma equipe de produção pode passar duas horas por semana verificando o mesmo conjunto de registros. Um piloto pode acompanhar quanto tempo leva a verificação com o novo fluxo de trabalho, com que frequência o resultado precisa de correção e se o relatório final permanece preciso. O resultado pode mostrar uma melhoria clara, uma pequena melhoria ou nenhuma mudança útil. Cada resultado fornece informações. ### Eu respondo perguntas difíceis diretamente Perguntas sobre segurança, manutenção, compatibilidade e condições de falha não são sinais de rejeição. Eles mostram que a equipe pensa além da reunião de vendas. Evito respostas que parecem polidas, mas dizem pouco. Se não tiver a resposta, digo que irei verificá-la. Uma resposta cuidadosa ganha mais confiança do que um palpite rápido. Os engenheiros podem perguntar: - O que acontece quando a conexão falha? - A equipe pode exportar seus dados? - Quem cuida do suporte? - Com que frequência o sistema precisa de manutenção? - As configurações podem ser alteradas posteriormente? - O fluxo de trabalho funciona durante picos de demanda? - Quais custos podem surgir após a implantação? Estas questões merecem respostas específicas. Eles também ajudam os tomadores de decisão a compreender o real escopo do projeto. ### Envolvo as pessoas que usarão o sistema Um gerente pode aprovar uma ferramenta, mas operadores e engenheiros convivem com o resultado todos os dias. A sua contribuição pode identificar questões que não aparecem numa revisão formal. Convido os usuários a testar o fluxo de trabalho e descrever o que parece lento, confuso ou desnecessário. Um pequeno detalhe na interface pode afetar dezenas de tarefas todos os dias. A falta de uma opção de exportação pode criar trabalho extra para outro departamento. Quando os usuários veem seu feedback refletido na configuração, o produto parece menos uma instrução externa e mais uma parte viável do processo. ### A celebração vem da evidência. A melhor reação não acontece quando faço a maior promessa. Acontece quando a equipe de engenharia percebe que a solução funciona conforme descrito, se ajusta ao processo existente e reduz um problema que lhe interessa. Às vezes a reação é tranquila. Um engenheiro sênior pode dizer: “Isso é mais fácil de manter do que eu esperava”. Um operador pode parar de solicitar uma solução alternativa manual. Um líder de projeto pode usar o tempo economizado para resolver outro problema de produção. Esses momentos são mais importantes do que uma resposta educada na reunião. Os engenheiros não precisam ser persuadidos por meio de pressão. Eles precisam de um problema claro, de informações honestas, de um plano testável e de controle suficiente para julgarem eles próprios o resultado. Quando forneço essas condições, a resistência muitas vezes se transforma em apoio cuidadoso. A equipe não está comemorando um discurso de vendas. Está comemorando uma solução que se mostrou útil no trabalho que importa.

Sua equipe pode ter objetivos claros e ainda assim lutar para seguir na mesma direção. As reuniões são demoradas. As tarefas mudam sem aviso prévio. Algumas pessoas realizam a maior parte do trabalho, enquanto outras aguardam uma orientação mais clara. O problema nem sempre é o esforço. Pode vir de funções pouco claras, feedback fraco ou de um processo que não se adapta mais ao trabalho. Eu não desafio os objetivos que você estabeleceu. Eu desafio os hábitos, suposições e padrões de equipe que tornam esses objetivos mais difíceis de alcançar. Quando trabalho em equipe, começo ouvindo. Quero entender como o trabalho passa de uma ideia até um resultado final, onde aparecem os atrasos e o que os membros da equipe precisam uns dos outros. Uma revisão típica pode analisar: - Como as prioridades são partilhadas - Quem toma cada decisão - Onde as tarefas se tornam pouco claras - Como é dado o feedback - Que reuniões ajudam o trabalho - Que reuniões criam trabalho extra - Como o progresso é monitorizado - O que impede as pessoas de levantarem preocupações Este processo dá à equipa uma visão partilhada da situação. Também ajuda a separar um problema de pessoas de um problema de processo. Um prazo perdido, por exemplo, pode não ser resultado de um comprometimento insuficiente. Uma equipe pode ter recebido três mudanças de prioridade diferentes em uma semana, esperado a aprovação de dois gerentes e trabalhado com base em um briefing de projeto desatualizado. Pedir à equipe que “trabalhe mais” não resolveria a causa. Uma resposta melhor poderia incluir: - Um responsável claro para cada decisão - Um breve resumo escrito do projeto - Uma forma simples de registar alterações - Pontos de revisão definidos - Um caminho direto para levantar riscos - Uma verificação semanal da carga de trabalho e das prioridades Estas mudanças dão às pessoas espaço para se concentrarem no seu trabalho em vez de adivinharem o que deve acontecer a seguir. Também desafio os hábitos da equipe com cuidado. Se uma reunião não tiver um propósito claro, posso perguntar se ela precisa continuar. Se um gestor responder a todas as perguntas, posso perguntar como a equipe pode adquirir mais confiança na tomada de decisões. Se o feedback chegar somente após a conclusão do projeto, posso sugerir pontos de revisão mais curtos durante o trabalho. O objetivo não é fazer com que todas as equipes operem da mesma maneira. Uma equipe criativa, um grupo de suporte ao cliente e um departamento de engenharia podem precisar de ritmos diferentes. O processo útil é aquele que corresponde ao trabalho e ajuda as pessoas a agirem com menos confusão. Um plano prático de melhoria da equipe geralmente segue este caminho: 1. Ouvir a equipe Reúno opiniões de gerentes e membros da equipe. Conversas privadas podem ajudar as pessoas a falar mais abertamente sobre pressão, expectativas pouco claras e bloqueios repetidos. 2. Mapeamos o fluxo de trabalho atual Observamos como as tarefas são atribuídas, revisadas, alteradas e concluídas. Isso muitas vezes revela etapas que não servem mais à equipe. 3. Escolha um pequeno conjunto de mudanças Evito dar às equipes uma longa lista de novas regras. Nós nos concentramos em mudanças que podem melhorar o trabalho diário sem adicionar uma administração pesada. 4. Teste as mudanças A equipe usa a nova abordagem por um período determinado. Observamos o que melhora, o que parece difícil e o que precisa de ajuste. 5. Analise o efeito Usamos sinais claros, como menos reuniões repetidas, decisões mais rápidas, melhor propriedade das tarefas e feedback mais útil. Os números podem ajudar, mas a experiência da equipe também é importante. 6. Mantenha o que funciona Um processo deve permanecer útil após o término do trabalho de coaching ou consultoria. A equipe precisa de hábitos simples que possa administrar sem apoio externo constante. Acredito que desafios saudáveis ​​devem criar conversas melhores, e não medo. As pessoas devem ser capazes de questionar um processo sem serem tratadas como um problema. Os gestores devem ser capazes de receber feedback sem perder autoridade. Os membros da equipe devem saber o que possuem, o que podem decidir e quando precisam de ajuda. Seus objetivos dão direção à equipe. Minha função é ajudar a remover os padrões que atrasam a equipe, expor as lacunas que são fáceis de ignorar e apoiar mudanças que se ajustem à forma como seu pessoal trabalha. O desafio visa o sistema em torno da equipe, não o valor da equipe em si.

Eu costumava pensar que um bom trabalho de engenharia falaria por si. Se o design fosse limpo, o código fosse bem estruturado e a explicação técnica fosse forte, eu esperava que as pessoas reconhecessem seu valor. Muitos engenheiros pensam assim. Passamos horas melhorando um sistema, testando casos extremos e resolvendo problemas que a maioria dos usuários nunca vê. Então os resultados chegam. Um serviço mais rápido chama mais atenção do que um belo diagrama de arquitetura. Uma ferramenta que elimina três etapas manuais ganha mais suporte do que um longo relatório técnico. Um recurso que ajuda os clientes a concluir uma tarefa com menos erros geralmente é mais importante do que o número de ideias inteligentes por trás dele. Essa lição pode parecer desconfortável, mas é útil: as pessoas raramente julgam a engenharia apenas pelo esforço. Eles julgam pelo que muda depois que o trabalho é lançado. ## A lacuna entre um bom trabalho e um trabalho útil Certa vez, trabalhei com uma equipe que passou semanas melhorando uma ferramenta de relatórios internos. A equipe limpou o código, adicionou filtros flexíveis e reconstruiu diversas telas. O resultado parecia polido. O uso quase não mudou. O principal problema não era a interface. A maioria dos funcionários não precisava de mais filtros. Eles precisavam que o relatório carregasse mais rápido e fosse exportado em um formato que seus gerentes pudessem ler. A equipe melhorou o produto do ponto de vista da engenharia, mas não resolveu o problema diário. Uma atualização menor mudou o resultado. Reduzimos o tempo de carregamento, adicionamos uma opção de exportação e removemos uma etapa do fluxo de trabalho. Os funcionários passaram a usar a ferramenta com mais frequência porque ela se adequava à sua rotina. A lição não foi que faltava valor ao código limpo. O código limpo ajudou a equipe a manter o sistema. O erro foi tratar a qualidade interna como o mesmo que valor para o usuário. Eles estão relacionados, mas não são idênticos. ## Os resultados dão um direcionamento ao trabalho técnico Quando inicio um projeto, procuro definir o resultado antes de discutir a solução. Um objetivo vago é assim: “Melhorar a plataforma”. Um objetivo útil é: “Ajudar a equipe de suporte a encontrar o registro de um cliente em menos de um minuto”. O segundo objetivo dá à equipe de engenharia algo para testar. Também ajuda a equipe a rejeitar trabalhos que parecem impressionantes, mas que não alteram o resultado. Esta abordagem ajuda em três áreas: - Dá às decisões de design um propósito claro. - Torna as compensações mais fáceis de explicar. - Dá à equipe uma forma de verificar se o trabalho ajudou. Um resultado não precisa ser um grande número de receitas. Pode ser um tempo de resposta mais curto, menos pagamentos mal sucedidos, menos tickets de suporte, custos operacionais mais baixos ou um processo mais seguro para a equipe. A medida deve corresponder ao problema. ## Etapa 1: Encontre o problema antes de escolher o recurso Os engenheiros geralmente recebem solicitações de recursos na forma de solução. “Adicionar um painel.” “Criar uma API.” “Crie um alerta automatizado.” Estas solicitações podem ser úteis, mas não são o problema em si. Pergunto o que as pessoas estão tentando fazer, onde o processo é interrompido e o que acontece quando ele é interrompido. Uma equipe pode solicitar um painel porque os gerentes não conseguem ver os pedidos atrasados. A melhor solução poderia ser um simples relatório diário. Outra equipe pode solicitar automação porque a entrada de dados demora muito. Um formulário com padrões melhores pode resolver o problema com menos manutenção. O pedido é um ponto de partida. A dificuldade do usuário deve nortear o trabalho. Quando converso com os usuários, prefiro perguntas como: - Qual tarefa leva mais tempo? - Onde acontecem os erros? - O que você faz quando o sistema falha? - Qual etapa você evita? - O que tornaria esse processo mais fácil de concluir? Estas questões muitas vezes revelam uma solução menor e mais útil. ## Etapa 2: Conecte o trabalho técnico a um resultado visível As tarefas técnicas podem parecer desconectadas dos resultados de negócios. Refatoração, alterações no banco de dados, cobertura de testes, registro em log e atualizações de segurança podem não criar um recurso imediato voltado para o usuário. Isso não os torna menos valiosos. A conexão precisa ser explicada. Uma alteração no banco de dados pode reduzir erros de tempo limite durante períodos de maior movimento. Um melhor registro pode reduzir o tempo necessário para diagnosticar um incidente. Um conjunto de testes pode permitir que a equipe libere alterações com menos defeitos. Uma correção de segurança pode proteger os dados do cliente e reduzir o risco operacional. Procuro descrever o trabalho neste formato: “Estamos mudando X para que Y possa melhorar”. Por exemplo: “Estamos melhorando o índice de pesquisa para que a equipe de suporte possa encontrar registros sem esperar por uma consulta lenta”. “Estamos adicionando testes automatizados em torno de novas tentativas de pagamento para que as transações com falha possam ser tratadas com menos verificações manuais.” Essa linguagem ajuda os parceiros não técnicos a entender por que o trabalho é importante. Também ajuda os engenheiros a questionar tarefas que não têm um propósito claro. ## Passo 3: Escolha uma medida antes do lançamento Uma equipe não pode aprender muito com um projeto se ninguém souber o que assistir. Antes do lançamento, escolho uma ou duas medidas úteis. Muitos números podem ocultar o sinal real. Para um recurso de pesquisa, eu poderia rastrear: - Tempo médio de pesquisa - Abandono de pesquisa - Recuperação de registros bem-sucedida - Solicitações de suporte relacionadas a registros ausentes Para uma alteração de checkout, eu poderia rastrear: - Taxa de conclusão de pagamento - Frequência de erros - Tempo necessário para concluir o pagamento - Contatos de suporte ao cliente sobre pagamentos falhados A medida deve ser fácil de coletar e conectada à tarefa do usuário. Uma alta contagem de visualizações de página pode parecer positiva, mas pode significar que as pessoas continuam voltando porque não conseguem encontrar o que precisam. Os números precisam de contexto. Um resultado não é útil quando a equipe não sabe qual comportamento o produziu. ## Etapa 4: Envie uma versão pequena e ouça. Projetos grandes criam grandes intervalos entre o esforço e o feedback. Durante essa lacuna, as suposições podem aumentar. Prefiro uma versão menor quando o risco é administrável. Uma versão limitada permite que a equipe observe o uso real, colete perguntas e ajuste o plano. Certa vez, uma empresa de logística testou um alerta de entrega com um grupo de motoristas em vez de liberá-lo para toda a operação. A equipe esperava que os motoristas quisessem mais tipos de notificação. O teste mostrou uma necessidade diferente: os motoristas queriam menos alertas, com instruções mais claras. Esse feedback mudou o produto antes de uma implementação mais ampla. Pequenos lançamentos não visam reduzir os padrões. Eles são uma forma de aprender antes de gastar mais tempo com detalhes errados. ## Etapa 5: Trate o feedback como informação do produto O feedback negativo pode parecer pessoal, especialmente quando um engenheiro investiu muito tempo em uma solução. Tento separar o trabalho da pessoa. Se os usuários ignorarem um recurso, isso não significa que o engenheiro falhou como profissional. Significa que a equipe aprendeu algo sobre o problema, o momento ou o design. Um usuário que diz “Eu não uso isso” pode estar dando um feedback incompleto. Um usuário que diz: “Não consigo terminar minha tarefa porque este botão só aparece depois que eu insiro os dados”, dá à equipe um caminho claro para investigar. Procuro comportamento, não apenas opiniões: - Os usuários completam a tarefa? - Eles criam soluções alternativas? - Eles pedem ajuda? - Eles voltam ao processo antigo? - Eles utilizam o recurso da maneira que a equipe esperava? O comportamento real muitas vezes conta uma história diferente da discussão em uma reunião. ## Passo 6: Manter qualidade e resultados juntos Os resultados não devem se tornar uma desculpa para uma engenharia fraca. Uma solução apressada pode apresentar uma melhoria a curto prazo, ao mesmo tempo que cria custos mais elevados posteriormente. Tempos de resposta lentos, códigos frágeis, propriedade pouco clara e segurança deficiente podem transformar uma pequena vitória num problema maior. Eu uso duas perguntas ao mesmo tempo: “Isso ajuda o usuário?” “Podemos apoiá-lo de forma segura e confiável?” Ambas as questões são importantes. Um recurso rápido que perde dados do cliente não é um bom resultado. Um sistema estável que ninguém possa usar não é um produto útil. A qualidade da engenharia apoia resultados duradouros, enquanto os resultados do usuário ajudam a equipe a decidir onde o trabalho de qualidade deve receber atenção. O equilíbrio muda com a situação. Uma questão de segurança precisa de testes cuidadosos. Um experimento interno simples pode precisar de um processo mais leve. O bom julgamento vem da compreensão do risco, e não da aplicação de uma regra a cada projeto. ## Por que os engenheiros às vezes resistem a essa ideia Alguns engenheiros temem que o foco nos resultados signifique que o julgamento técnico será ignorado. Essa preocupação é razoável. A pressão empresarial pode levar as equipes a alcançar números de curto prazo e soluções rápidas. A resposta não é rejeitar a medição. A resposta é escolher medidas melhores e explicar o custo de decisões erradas. Se uma equipe quiser reduzir o custo do servidor, os engenheiros podem mostrar como um orçamento menor pode afetar o tempo de resposta ou a confiabilidade. Se uma equipe quiser lançar rapidamente, os engenheiros poderão identificar quais verificações protegem os usuários e quais etapas podem esperar. Uma cultura baseada em resultados deve criar melhores conversas e não silenciar preocupações técnicas. Meu papel como engenheiro não é apenas construir o que foi solicitado. É para ajudar a equipe a entender o que a solicitação mudará, o que não mudará e quais os riscos que isso acarreta. ## O trabalho fica mais fácil de explicar Quando os resultados orientam o projeto, as atualizações de status se tornam mais úteis. Em vez de dizer: “Concluímos o novo serviço de pesquisa”. Posso dizer: "O novo serviço de pesquisa reduziu o tempo médio de pesquisa de 18 segundos para 6 segundos no grupo piloto. Três casos de falha permanecem em análise." Essa frase dá às pessoas uma imagem mais clara. Mostra progresso, evidências e a próxima área de trabalho. Também protege a equipe de elogios vazios. Uma tarefa concluída nem sempre é um resultado bem-sucedido. A versão precisa ser testada em relação ao motivo pelo qual foi construída. ## O que melhores resultados não significam Melhores resultados não significam perseguir todas as métricas. Eles não significam cortar atalhos. Não significam construir apenas o que pode ser medido em uma semana. Alguns trabalhos de engenharia protegem a confiabilidade futura, apoiam a acessibilidade, melhoram a segurança ou reduzem riscos. Seu valor pode aparecer através de problemas que nunca acontecem. Esse valor ainda precisa de uma explicação clara. O objetivo não é transformar cada decisão de engenharia em um discurso de vendas. O objetivo é conectar o esforço com uma necessidade real e tornar visível o compromisso. Aprendi a respeitar mais um bom trabalho técnico quando consigo ver quem ele ajuda, quais problemas ele reduz e como a equipe saberá se funcionou. Um design limpo é útil. Um sistema bem testado é útil. Uma ideia técnica forte torna-se muito mais valiosa quando melhora o trabalho de uma pessoa, reduz a frustração do cliente ou ajuda uma empresa a operar com menos desperdício. O código é importante. O resultado nos diz se o código foi importante da maneira que pretendíamos. Para qualquer dúvida sobre o conteúdo deste artigo, entre em contato com Hu Peng: 756759203@qq.com/WhatsApp +8613867775312.

Nicole Forsgren, Jez Humble e Gene Kim, 2018, Accelerate: The Science of Lean Software and DevOps Gene Kim, Kevin Behr e George Spafford, 2013, The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win Martin Fowler, 2018, Refatoração: Melhorando o Design do Código Existente Eric Ries, 2011, The Lean Startup: How Os empreendedores de hoje usam a inovação contínua para criar negócios radicalmente bem-sucedidos Google, 2023, Site Reliability Engineering: How Google Runs Production Systems NIST, 2018, Framework for Improving Critical Infrastructure Cybersecurity versão 1.1