Escrever código é fácil. Entregar um produto de software continua difícil
Por que código mais rápido raramente significa entrega mais rápida, e o que gerenciar no lugar
Esse post foi traduzido automaticamente do inglês. Se você encontrar algum erro, por favor entre em contato.
Todas as pessoas que lideram times de engenharia têm o mesmo desafio de sempre: como entregar mais valor para os clientes, e mais rápido? Não importa se você é founder, ou se lidera produto ou engenharia.
Esse desafio está mais urgente do que nunca, com a IA revolucionando a forma como software é construído. Mas parece que estamos vivendo um paradoxo. Temos à disposição ferramentas incríveis, capazes de fazer em minutos tarefas que antes levavam dias: código mais rápido, protótipos mais rápidos, praticamente tudo mais rápido.
Mesmo nesse contexto, os ganhos de velocidade muitas vezes não se traduzem nos mesmos ganhos na entrega de valor, porque a velocidade tem consequências não intencionais. Ela pode gerar mais problemas, com a qualidade caindo. Pode gerar desalinhamento, com pessoas correndo em direções diferentes. Ou ainda levar a decisões superficiais, já que todo mundo está ocupado em manter os agentes rodando.
No fim das contas, sempre que o processo muda, o gargalo muda de lugar. E se você não sabe para onde ele foi, é provável que o esforço seja desperdiçado.
Embora seja um exemplo de antes da IA, em uma empresa onde trabalhei eu liderava um time pequeno de startup, com 10 engenheiros. O produto era um líder em ascensão no seu mercado, e o time tinha uma cultura de entregar extremamente rápido.
Para quem estava no time, era óbvio que estávamos pagando um preço de alguma forma. Os engenheiros estavam sempre buscando jeitos mais rápidos de fazer o trabalho, muitas vezes pegando algum atalho, mesmo que sem querer. Mas a liderança da empresa não enxergava isso, já que, do ponto de vista dela, o valor estava sendo entregue.
Até que tive a oportunidade de deixar isso claro. Tínhamos o plano de entregar uma feature grande, e a empresa queria que ela ficasse pronta em 4 semanas, um prazo bem apertado do ponto de vista de engenharia. O resultado foi a situação que aparece na imagem abaixo.
Medimos a quantidade de bugs e tarefas em que estávamos trabalhando por semana, e ficou claro que o período de correria nas semanas 1 a 4 (quando lançamos a feature “com sucesso”) resultou em duas semanas quase só de correção de bugs depois disso. A pressão não estava levando a uma entrega mais rápida, e sim a uma experiência pior para o cliente.
A teoria por trás disso é simples. O fluxo de valor de entregar uma feature não se resume a entregar o código. Ele vai desde entender a necessidade, dar forma à solução e priorizá-la em relação a outras soluções, até executá-la com design e engenharia sem causar mudanças não intencionais, como bugs ou alterações de comportamento em outras partes do sistema. E cada etapa gera um ciclo de feedback para o sistema, validando a etapa anterior. Por exemplo, uma entrevista de pesquisa com usuários valida o design sem precisar construí-lo, e o code review valida que o código está correto sem precisar fazer o deploy.
Na prática, porém, não é simples tornar esse fluxo de valor eficaz. Pessoas diferentes têm incentivos e opiniões diferentes. À medida que o produto cresce, a complexidade cresce junto, aumentando a superfície para problemas. E uma empresa de verdade não constrói uma feature de cada vez, mas várias, o que significa que há várias ideias e mudanças acontecendo ao mesmo tempo.
Aplicar mais velocidade a todas elas, como a IA faz, não necessariamente torna tudo mais rápido, e em muitas situações pode deixar tudo mais lento. É isso que muitos times estão vendo. As mudanças de código ou os protótipos saem na velocidade da luz, mas o resultado final, ou seja, clientes obtendo valor ao usar novas features, nem tanto.
O próximo passo óbvio é jogar mais IA (ou tokens) no problema. Se mais velocidade no desenvolvimento de produto significa protótipos mais rápidos, crie um eval ou um teste A/B para decidir qual é o melhor. Se mudanças de código mais rápidas estão gerando mais bugs, coloque um agente para corrigi-los à medida que aparecem. O problema é que a conta não fecha. Cada correção de bug é mais uma mudança no código, com o risco de introduzir novos problemas. No geral, mais movimento e mais opções só deixam o sistema mais complexo, e essa complexidade vai ser paga em algum momento, mesmo que esse momento acabe sendo um cliente sobrecarregado pelas opções e pelas mudanças constantes no produto.
Esse é o problema mais profundo: deixar uma parte do sistema mais rápida pode sobrecarregar o resto, anulando na prática os ciclos de feedback. É o que alguns times estão vendo com code review agora. Os revisores recebem mais pedidos de revisão do que conseguem dar conta, então aprovam sem olhar. A revisão continua acontecendo no papel, mas não pega mais nada.
O caminho, especialmente quando tudo está mudando, é entender o fluxo de valor de ponta a ponta e resolver um gargalo de cada vez.
Essa foi a conclusão da história acima. Apresentei aquele gráfico para o CEO, explicando que exigir entregas mais rápidas não estava nos dando vantagem de velocidade, já que depois passávamos tempo corrigindo problemas. Além da velocidade, isso estava gerando uma experiência pior para os clientes que tinham que lidar com esses problemas, algo que afeta resultados reais do negócio. Depois dessa conversa, passamos a olhar os mesmos dados regularmente nas nossas reuniões semanais de liderança, para garantir que a qualidade não estava sendo comprometida. Acabamos com um processo mais sustentável para o time e um resultado melhor para a empresa e seus clientes.
Se você quer fazer isso, por onde começar? Há três princípios que, na minha opinião, podem levar você a um lugar muito melhor:
Primeiro, defina os resultados do seu time em termos de valor para o cliente, não de software. Na prática, isso significa definir projetos com base nos seus resultados de negócio, para que o time esteja alinhado com a empresa. Você também deve definir os itens de trabalho em termos de valor para o cliente (com user stories), para que fique claro que o objetivo são os resultados, e não o número de pull requests.
Segundo, entenda e gerencie o fluxo de ponta a ponta do seu time. Com os resultados definidos, você pode gerenciar o time, e a execução dele, com base neles. Na prática, você deve focar no tempo que cada mudança ou feature leva para chegar em produção e se adaptar a isso. Por exemplo, se o planejamento leva mais tempo que o desenvolvimento, o time deveria focar em tornar o planejamento mais rápido, e não em rodar mais agentes de código. O objetivo é reduzir o cycle time da ideia até o valor para o cliente em cada feature, e não manter todo mundo ocupado dentro do seu próprio papel.
Por fim, pense na produtividade do time, não na produtividade individual. Isso tem a ver com o ponto anterior, mas vale destacar, porque os incentivos muitas vezes levam as pessoas na direção errada. Não faz diferença se um engenheiro consegue rodar 100 agentes ao mesmo tempo se isso cria 100x mais trabalho para outra pessoa mais adiante, aumentando o cycle time da entrega. O mesmo vale para decisões de produto e de design. O objetivo é o time entregar o mais rápido possível, e não cada pessoa separadamente.
Fazendo isso, você está gerenciando seu time como um sistema. E, a partir daí, pode experimentar dentro dele. Talvez pular o code review faça sentido, talvez não. Vai depender do seu contexto. Mas, com o resultado em mente, você consegue avaliar isso e tomar uma decisão informada.
Comentários