Menos horas, mais entrega: o que a engenharia de software aprende com Pissarides

Há décadas a engenharia de software se debate entre o culto à carga horária extensa e a busca por entregas de qualidade. Nos últimos anos, com a popularização do trabalho remoto e a pressão por bem-estar, a ideia de reduzir a jornada semanal ganhou força. O economista Christopher Pissarides, vencedor do Prêmio Nobel, trouxe um argumento que ecoa nos corredores de tecnologia: a redução da carga de trabalho provavelmente aumenta a produtividade sem gerar impacto inflacionário significativo. Como reportou a Folha de S.Paulo recentemente, Pissarides aposta que as pessoas ficam mais produtivas com menos horas — uma tese que, para quem vive dentro de squads ágeis e sprints, soa tentadora, mas exige cuidado ao ser traduzida para a realidade de times de produto.

Antes de qualquer entusiasmo, é preciso separar o que é evidência econômica macro do que é prática micro de desenvolvimento. Pissarides observa tendências em países desenvolvidos e aponta que a produtividade horária tende a crescer quando o total de horas cai. Contudo, em times de software, a produtividade não é uma simples relação entre horas e linhas de código. Ela envolve criatividade, colaboração, contexto de negócio e, sobretudo, capacidade de manter o fluxo cognitivo. É aqui que a tese do Nobel encontra seu maior potencial e também seu maior risco de má interpretação.

O que Pissarides realmente disse sobre horas e inflação

O argumento central de Pissarides é que a redução da jornada não precisa gerar pressão inflacionária porque o custo por unidade produzida cai com o ganho de produtividade horária. Em outras palavras, se o trabalhador entrega o mesmo ou mais em menos tempo, o salário por hora pode subir sem que o custo total do produto aumente. Esse raciocínio se sustenta bem em setores industriais e de serviços repetitivos, onde a relação entre tempo e output é mensurável com clareza. No mundo do software, porém, o output é intangível: um bug corrigido em cinco minutos pode salvar uma semana de retrabalho; um recurso mal especificado pode gerar meses de débito técnico.

Pissarides também destacou que a automação e a inteligência artificial podem acelerar esse movimento. Para ele, o ganho de produtividade virá não apenas de trabalhar menos, mas de trabalhar de forma mais inteligente, apoiado por ferramentas que eliminam tarefas repetitivas. Essa afirmação ressoa fortemente com o que vejo na engenharia de software: times que adotam boas práticas de CI/CD, testes automatizados e assistentes de código já experimentam ganhos reais de eficiência. A pergunta que fica é: esses ganhos se traduzem automaticamente em liberdade para reduzir a jornada? Na prática, a resposta depende de como a organização mede valor entregue.

Produtividade em engenharia: muito além do relógio

Uma das armadilhas mais comuns em discussões sobre redução de jornada é supor que a produtividade é homogênea entre indivíduos e ao longo do dia. Qualquer engenheiro sênior sabe que o pico de concentração é limitado a poucas horas — o restante do tempo é fragmentado entre reuniões, revisões de código, comunicação assíncrona e, inevitavelmente, distrações. Reduzir o expediente pode forçar uma priorização mais rigorosa, cortando o "trabalho de baixo valor" que preenche as horas vagas. Já vi squads que adotaram a semana de quatro dias e, de fato, aumentaram a entrega de funcionalidades críticas, mas também vi times que simplesmente comprimiram a mesma carga de trabalho em menos tempo, gerando burnout.

A diferença está na governança. Times que usam métricas como DORA (frequência de deploy, lead time, MTTR) e SPACE (satisfação, desempenho, colaboração) conseguem identificar onde o tempo está sendo desperdiçado. Reduzir a jornada sem antes eliminar gargalos de processo é como apertar o acelerador com o freio de mão puxado. Pissarides fala de um contexto macro onde a produtividade é impulsionada por capital, tecnologia e organização do trabalho. No micro, a engenharia de software precisa primeiro resolver a dívida de processos — reuniões improdutivas, burocracia de code review, dependências externas mal gerenciadas — para que a redução de horas não vire apenas mais pressão.

O papel da IA na equação horas versus entrega

Pissarides acerta ao apontar a automação como alavanca. A inteligência artificial generativa, especialmente modelos de linguagem aplicados a coding assistants, já demonstrou capacidade de reduzir o tempo gasto em tarefas repetitivas: escrever testes unitários, gerar boilerplate, refatorar código simples e até sugerir arquiteturas iniciais. Estudos recentes mostram ganhos de produtividade entre 20% e 55% em tarefas específicas para desenvolvedores que usam essas ferramentas. Se esses ganhos fossem convertidos integralmente em redução de jornada, semanalmente poderíamos trabalhar três dias e meio com a mesma entrega.

Porém, o cenário real é mais complexo. O ganho de produtividade com IA não é automático: ele exige aprendizado, curadoria dos resultados e, muitas vezes, refatoração do que a máquina gerou. Além disso, a qualidade do código gerado depende do contexto fornecido — e contexto é justamente o que consome tempo de um engenheiro experiente. A redução de horas não virá apenas da adoção de ferramentas, mas de uma reorganização do fluxo de trabalho: pair programming com IA, revisões mais enxutas, integração contínua de sugestões automatizadas. Times que implementam essas mudanças costumam ver um aumento de produtividade que permite, sim, pensar em jornadas menores — desde que a liderança esteja disposta a redistribuir o ganho, não apenas acumulá-lo em mais features.

Trade-offs de implementar jornada reduzida em times de produto

Reduzir a carga horária sem planejamento cuidadoso pode gerar externalidades negativas. O principal risco é a perda de sobreposição de horários. Em times distribuídos, a janela de colaboração síncrona já é limitada. Se cada membro escolhe um dia diferente para folgar, o tempo de alinhamento cai drasticamente, aumentando o tempo de resposta a incidentes e a fricção em decisões técnicas. Uma abordagem mais eficaz é a adoção de jornada compactada, com todos no mesmo horário reduzido, ou a implementação de dias de "foco total" com reuniões zero.

Outro trade-off é o impacto sobre o aprendizado e a mentoria. Engenheiros mais novos precisam de tempo exposto a discussões técnicas, code reviews aprofundados e sessões de design. Se todos trabalham menos, a oportunidade de aprendizado incidental diminui. Soluções como documentação assíncrona, sessões de design gravadas e rotação de pares podem mitigar, mas exigem investimento em disciplina. Em startups enxutas, onde cada desenvolvedor já acumula múltiplas responsabilidades, reduzir a jornada pode comprometer a velocidade de experimentação e validação de hipóteses — o coração da cultura de produto.

Implicações práticas para operação e carreira

Para líderes técnicos e CTOs, a reflexão trazida por Pissarides deve inspirar uma mudança de métrica: deixar de medir presença e passar a medir impacto. Isso significa que redução de jornada só faz sentido se acompanhada de um sistema de avaliação focado em resultados, não em horas registradas. Ferramentas de OKRs, NPS do desenvolvedor e análise de ciclo de entrega são mais úteis do que trackers de tempo. Times que conseguem implementar essa transição relatam maior retenção de talentos e redução de turnover — algo que, em um mercado competitivo, vale mais do que o custo de uma hora extra.

Na carreira individual, engenheiros que dominam automação e sabem gerenciar o próprio tempo tendem a ser os maiores beneficiários de uma eventual redução generalizada da jornada. A capacidade de entregar com qualidade em menos horas se torna um diferencial competitivo. Por outro lado, profissionais que dependem de longas horas para compensar falta de foco ou processos ruins podem se sentir pressionados. A tendência é que o mercado recompense cada vez mais a eficiência, não a disponibilidade.

Riscos, limitações e pontos de atenção

É importante não idealizar a redução de jornada como solução universal. Pissarides mesmo reconhece que o impacto é mediado por fatores como investimento em tecnologia e qualidade da gestão. Em empresas de software que ainda operam com entregas orientadas a prazo fixo (contratos de consultoria, projetos governamentais), a redução de horas pode simplesmente deslocar a pressão para fins de semana, criando um "trabalho invisível". Além disso, setores como suporte 24x7, operações críticas e segurança cibernética têm restrições de horário que limitam a aplicação de jornada reduzida universal.

Outro ponto: a produtividade ganha com menos horas pode ser temporária, fruto de um efeito Hawthorne (melhora induzida pela novidade). Para que o ganho perdure, é preciso atacar as causas estruturais de baixa produtividade: processos manuais, débito técnico, falta de autonomia. Sem isso, a redução de jornada pode ser revertida quando os resultados não se sustentarem. Empresas que tentaram a semana de quatro dias e voltaram atrás frequentemente citam a dificuldade de manter a cultura de entrega sem aumentar a carga.

Perspectiva pessoal: o que aprendi com times que reduziram a carga

Acompanhei de perto a implementação de jornada reduzida em duas empresas de produto digital. Na primeira, a adoção foi top-down: um decreto da diretoria de que sexta-feira seria dia de desenvolvimento individual, sem reuniões e com carga opcional. O resultado foi ambíguo: os engenheiros mais seniores adoraram a liberdade, mas os juniores se sentiram perdidos, sem a estrutura de reuniões diárias para alinhar dúvidas. A produtividade média subiu cerca de 12% nos dois primeiros meses, mas caiu para o patamar anterior após quatro meses, quando o débito técnico acumulado começou a pesar.

Na segunda empresa, a redução veio acompanhada de uma reestruturação do fluxo de trabalho: eliminaram a daily de 15 minutos e adotaram check-ins assíncronos, reduziram o número de sprints paralelos e investiram pesado em automação de testes e infraestrutura. A jornada passou de 40 para 36 horas, mas o tempo focado em código produtivo aumentou. Os resultados se mantiveram estáveis por mais de um ano. A diferença crucial foi o investimento em processos antes de apertar o botão da redução de horas.

A tese de Pissarides é sólida como orientação macro, mas sua aplicação no mundo do software exige cirurgia fina. Reduzir horas sem aumentar a eficiência dos meios de produção é receita para frustração. A boa notícia é que a engenharia de software tem hoje métricas e ferramentas para fazer essa transição de forma inteligente. Cabe a líderes e times encarar a jornada reduzida não como benefício, mas como um desafio de redesign do trabalho. Se conseguirmos, o resultado será uma indústria mais saudável, com entregas de maior qualidade e profissionais menos esgotados. Vale o esforço.