O mérito por resolver um problema que não aconteceu, e do qual ninguém se lembra (2001) [PDF]

• As empresas gastam muito para alcançar capacidades operacionais como a manufatura ao estilo Toyota, a qualidade six-sigma e a cadeia de suprimentos ao estilo Dell, mas é raro que programas de melhoria levem a resultados duradouros
• O TQM é um caso em que algo amplamente adotado em certo momento depois perdeu espaço rapidamente; entre as empresas da Fortune 1000, menos de 10% tinham um programa de TQM bem desenvolvido
• A causa do fracasso está menos na escolha de uma ferramenta específica e mais na forma como um novo programa se conecta às estruturas físicas, econômicas, sociais e psicológicas; no fim, a melhoria se torna um problema de sistema
• Quando a lacuna de desempenho aumenta, a organização precisa escolher entre Work Harder e Work Smarter, mas a segunda opção tende a perder espaço por causa dos atrasos e do risco de fracasso
• Shortcuts, que reduzem o tempo dedicado à melhoria, parecem atraentes por elevar a produção no curto prazo, mas o acúmulo de perdas de capacidade que só aparecem depois pode prender a organização em uma Capability Trap

---

O paradoxo do fracasso dos programas de melhoria

• As empresas investem ativamente em melhorias de processo para desenvolver capacidades operacionais em áreas como manufatura, qualidade, compreensão do cliente e gestão da cadeia de suprimentos
• Em 1997, o gasto total das empresas americanas com consultoria de gestão e treinamento passou de US$ 100 bilhões, e uma parte considerável foi usada para alcançar as capacidades operacionais de empresas de destaque
• Apesar de alguns sucessos dramáticos, muitos programas de melhoria não conseguem gerar resultados significativos
• O TQM ilustra bem esse paradoxo
  • Tornou-se uma grande tendência entre empresas americanas, impulsionada pelo sucesso das empresas japonesas nos anos 1980
  • Em meados dos anos 1990, perdeu atenção na academia e na mídia de negócios, ficando para trás diante de novas inovações como re-engineering
  • Empresas que se comprometeram seriamente com a disciplina e os métodos do TQM obtiveram desempenho superior ao dos concorrentes
  • Em um estudo, menos de 10% das empresas da Fortune 1000 tinham programas de TQM bem desenvolvidos
  • Em outro estudo, o TQM era a terceira ferramenta de negócios mais usada em 1993, mas caiu para a 14ª posição em 1999
• Técnicas de melhoria do passado às vezes reaparecem com novos nomes
  • A disciplina central do controle estatístico de processo e da redução de variação evoluiu para o six-sigma
  • quality circle passou a ser chamado de high-performance work team

Mais difícil do que a ferramenta é a estrutura de implementação

• As ferramentas e técnicas de melhoria de desempenho cresceram rapidamente, e com o avanço da tecnologia da informação e o aumento do número de consultores, ficou mais fácil aprender quem usa qual técnica
• Para a maioria dos gestores, a barreira maior não é conhecer um novo método, mas sim implementá-lo com sucesso no trabalho do dia a dia
• Capacidades como um programa de qualidade six-sigma não podem ser compradas como um produto turnkey; elas precisam ser desenvolvidas dentro da organização
• Ao longo de mais de dez anos, foram realizados mais de 12 estudos de caso aprofundados nos setores de telecomunicações, semicondutores, químicos, petróleo, automotivo e produtos de lazer
  • Foram usados observação, entrevistas com participantes, registros documentais e indicadores quantitativos
  • Modelos também foram desenvolvidos em conjunto para capturar a dinâmica da implementação e da melhoria
• O motivo pelo qual a maioria das organizações não obtém plenamente os benefícios das inovações de melhoria tem pouca relação com a escolha de uma ferramenta específica
• Um novo programa de melhoria opera onde ferramentas, equipamentos, trabalhadores, gestores e estruturas físicas, econômicas, sociais e psicológicas se cruzam, tornando-se assim um problema sistêmico

A física básica da melhoria: tempo e capacidade

• O desempenho real de um processo é determinado pelo Time Spent Working e pela Capability do processo que executa esse trabalho
  • Na manufatura, a produção útil líquida é definida pelo produto entre as horas de trabalho por dia e a produtividade, isto é, a produção utilizável por hora trabalhada
• O desempenho pode ser elevado trabalhando mais ou investindo mais em melhoria, mas os resultados das duas abordagens são diferentes
  • Se a jornada semanal aumentar 20%, a produção pode subir 20% enquanto as horas extras forem mantidas
  • Melhorar a capacidade do processo aumenta a produção de todas as horas de trabalho investidas dali em diante
  • Horas extras para retrabalhar produtos com defeito só elevam a produção enquanto continuarem, mas eliminar a causa raiz dos defeitos reduz de forma contínua a necessidade de retrabalho
• A capacidade é tratada como um ativo acumulado (stock) ao longo do tempo
  • O tempo gasto em melhoria aumenta o investimento em capacidade
  • Como encontrar causas raiz e descobrir, testar e implementar soluções leva tempo, há um atraso entre a atividade de melhoria e a mudança de capacidade
  • Capacidade que não é mantida regularmente se deteriora por causa de desgaste de máquinas, desvio de processo, envelhecimento de projeto e obsolescência de procedimentos
• O atraso da melhoria varia conforme a complexidade técnica e organizacional do processo
  • Em melhorias relativamente simples, como o rendimento de máquinas em um job shop, o atraso pode ser de alguns meses
  • Em processos complexos, como desenvolvimento de produto, o atraso pode ser de vários anos ou mais
  • Em organizações com alta rotatividade de produtos e de pessoas, a vida útil da capacidade melhorada também se encurta

A tensão entre Work Harder e Work Smarter

• A gestão define metas como demanda de clientes, volume de processamento de pedidos de seguro ou número de novos produtos lançados por trimestre como Desired Performance
• A diferença entre o desempenho real e a meta se torna a Performance Gap, e nas organizações estudadas era raro encontrar processos que superassem as expectativas
• Em organizações relutantes em expandir recursos ou contratar mais gente, há duas escolhas básicas para fechar a lacuna de desempenho

• Loop Work Harder

  • Quando há uma lacuna de desempenho, os gestores elevam a pressão de trabalho por meio de aumento do ritmo, horas extras, metas mais agressivas ou penalidades por não atingir objetivos
  • Formas mais sutis, como a frequência das revisões de desempenho, o nível de detalhe dessas revisões e o cargo de quem revisa, também fazem parte da pressão de trabalho
  • Em uma empresa, um vice-presidente sênior analisava o desempenho de máquinas individuais no chão de fábrica, e isso foi entendido como um recado para manter as máquinas rodando a qualquer custo
  • Em outro caso, quando o cronograma de um subsistema atrasou, o gerente de projeto responsável foi obrigado a fazer ligações de atualização a cada hora até que o protótipo atendesse às especificações

• Loop Work Smarter

  • Os gestores podem tentar elevar a capacidade do processo iniciando programas de melhoria, incentivando testes de novas ideias e investindo em treinamento
  • Se der certo, com o tempo a capacidade melhora, o throughput aumenta e a lacuna de desempenho diminui
  • O investimento em melhoria pode gerar efeitos maiores no longo prazo, mas há atraso considerável até os resultados aparecerem, além do risco de fracasso ao descobrir a causa raiz ou aplicar novas ferramentas
  • Em problemas urgentes, Work Harder costuma ser a escolha mais frequente
  • Se uma linha de manufatura que atende um cliente importante para, o gestor tende mais a fazer a linha voltar a rodar e impor horas extras até concluir os embarques do que a investir em treinamento para melhorar a confiabilidade
  • Se, depois da resposta emergencial, a organização não consegue retomar as atividades de melhoria, trabalhar mais duro vira o modo padrão de operação

Loop de reinvestimento e armadilha da capacidade

• Como as organizações quase não têm recursos ociosos, quando a pressão de trabalho aumenta as pessoas reduzem atividades não relacionadas ao trabalho, como descanso, e ampliam as horas extras
• No caso dos trabalhadores do conhecimento, as horas extras muitas vezes não são pagas e avançam para noites e fins de semana, tirando tempo da família e da vida em comunidade
• Quando já não dá para expandir mais o tempo de trabalho, a única saída para acompanhar uma lacuna de desempenho crescente é reduzir o tempo dedicado à melhoria

• Loop Reinvestment

  • Quando o investimento em melhoria dá certo, o desempenho sobe e a lacuna diminui, liberando mais tempo para investir em melhoria e criando um círculo virtuoso
  • Em contraste, responder à lacuna de throughput com pressão de trabalho reduz o tempo de melhoria, deteriora a capacidade e amplia ainda mais a lacuna de desempenho, criando um círculo vicioso de mais pressão e menos melhoria
  • Em casos de melhoria bem-sucedidos, os recursos obtidos pelo ganho de produtividade eram explicitamente realocados para atividades de melhoria, fortalecendo o processo de reinvestimento
  • Em muitas organizações, pressões de custo e prazo levam a downsizing ou a metas de desempenho mais altas, retirando recursos da melhoria e fazendo a capacidade estagnar ou cair

• Loop Shortcuts

  • Atalhos como pular reuniões de melhoria, adiar manutenção preventiva programada ou ignorar exigências de documentação aumentam imediatamente o tempo disponível para o trabalho
  • Como a perda de capacidade não aparece de imediato, esses atalhos parecem eficazes e atraentes no curto prazo
  • Um gestor que adia manutenção preventiva ganha um período de adiamento ao evitar o downtime programado e economizar custos de manutenção, mas depois sofre com queda de rendimento e de tempo de operação por causa do envelhecimento e desgaste do equipamento
  • Um engenheiro de software que pula a documentação pode terminar o projeto no prazo, mas paga esse custo semanas ou meses depois ao corrigir bugs encontrados nos testes

• Capability Trap

  • Work Harder inicialmente aumenta o throughput total de imediato, e o custo da redução do tempo de melhoria aparece mais tarde, criando uma situação de better-before-worse
  • Work Smarter reduz a produção no curto prazo, mas com o tempo o aumento de capacidade compensa a redução do esforço de trabalho e eleva o desempenho, produzindo uma dinâmica de worse-before-better
  • A interação entre Shortcuts e Reinvestment pode prender a organização em uma Capability Trap de deterioração da capacidade

[GN⁺]

Comentários do Hacker News

• Minha memória está um pouco nebulosa, mas há um bom exemplo
  Em uma organização, havia um processamento de pedidos importante, mas não dava para confiar que todas as informações necessárias sempre chegariam ou chegariam corretamente. Então criaram uma lógica de validação que saneava os dados de entrada e alterava a forma de processamento, e registravam como métrica quais validações eram acionadas em cada pedido. Quando uma nova validação era adicionada, ela também recebia a data
  Como essa métrica era pública e compartilhada de vez em quando, quando alguém perguntava “o que acontece se for XYZ?”, era possível responder “isso já foi tratado, e evitou que #### pedidos fossem bloqueados por causa de XYZ”
  Ficava claro que a equipe trabalhava com cuidado, que esse tipo de trabalho era necessário para o sistema continuar funcionando bem, e que isso podia ser sustentado por dados. Com isso, a conversa dentro da organização mudou de “como não pensamos nisso?” para “o que fazemos agora?”, e o reconhecimento pela qualidade preventiva também subiu na hierarquia

  • Há uma genialidade simples, mas incontestável, na ideia de instrumentar quantas vezes cada validação foi acionada
    A maioria das equipes teria parado em métricas como taxa de sucesso dos pedidos, mas usar como métrica a quantidade de dados ruins tratados ajuda a escapar da armadilha em que as coisas boas passam despercebidas

• Passei exatamente pela mesma coisa recentemente no trabalho
  Como tech lead/arquiteto da organização, revisei projetos lançados recentemente e encontrei pontos que precisavam necessariamente ser melhorados por causa de graves problemas de confiabilidade/desempenho. Vários releases de uma equipe estavam no topo da lista, mas o PM, o gerente de engenharia dessa equipe e as pessoas acima deles ignoraram todas as preocupações, dizendo que atualizações de funcionalidade deveriam ter prioridade
  Alguns meses depois, durante minhas férias, tudo explodiu, houve uma escalada sev 1, vários clientes ficaram furiosos e até o CEO/CTO se envolveu. A mesma equipe que escreveu o código malfeito e ignorou os alertas trabalhou dia e noite para restaurar o serviço, e agora virou heroína. Em especial, esse gerente ganhou reputação na empresa por ter se comunicado ativamente durante a falha e demonstrado liderança

  • Às vezes, uma resposta heroica pode ser um sinal de que a pessoa é confiável. Mas, se a resposta heroica é rotina, há grande chance de ser trabalho ruim ou gestão ruim, e isso precisa ser analisado com mais cuidado
    Consertar um problema criado por outra pessoa impressiona mais. Não tenho vontade de encher de elogios alguém que corrigiu o próprio erro, e eu também não esperaria elogios por corrigir meus próprios erros. Eu pediria desculpas a todos por ter estragado as coisas em primeiro lugar
  • Você pode até resgatar um e-mail antigo e reenviá-lo “sem querer”. Pode parecer um pouco mesquinho, mas talvez faça algumas pessoas repensarem os últimos meses
  • Dá vontade de chamar isso de a tragédia do desenvolvimento de software. O incendiário vira bombeiro

• O problema do título me faz pensar continuamente sobre o meu próprio valor
  Se alguém ajuda em 40 minutos com algo em que eu estava travado havia 3 meses, meu valor fica evidente para todos. Mas, se eu trabalho junto o tempo todo para que ninguém fique travado por 3 meses, meu valor se torna nebuloso. Não sei como lidar com esse paradoxo

  • O sistema educacional pelo qual passei foi projetado para ensinar que resultados são quase linearmente proporcionais a esforço e tempo. A primeira lição depois da formatura foi que isso não é verdade
    Muitas vezes, se você dedica mais esforço e mais tempo, a recompensa fica para trás e só se espera ainda mais esforço e mais tempo. Valor e oportunidade estão mais próximos de um processo caótico do que de algo proporcional a esforço e tempo
    No fim, é preciso tentar manter a carga de trabalho leve o bastante para estar mentalmente lúcido quando uma oportunidade aparecer, para poder agarrá-la. Colegas honestos e equilibrados ajudam, mas no fim é algo que cada um precisa fazer por si mesmo
  • Há casos ainda piores. As pessoas ficam travadas com frequência e pedem ajuda imediatamente. Se eu destravo todo mundo, meu próprio trabalho atrasa e, quando o chefe do meu chefe pede métricas de desenvolvedor, eu tenho poucos pontos entregues e poucas linhas de código alteradas
    Mesmo que meu chefe tente explicar, na próxima rodada de demissões a cabeça que pode rolar é a minha
  • Já fiz esse tipo de trabalho como contratado por hora. No primeiro dia corrigi o problema de 6 meses deles e depois esperei que me contratassem para outras coisas, mas disseram que “era só isso que precisavam”
    Até falaram para outras empresas que eu era bom nesse tipo de coisa, mas nada surgiu daí. Foi meu primeiro e último dia trabalhando como contratado para empresas pequenas
  • Um gestor realmente bom compensa esse problema. Ele incentiva trabalho em equipe e colaboração, mas também conhece em detalhe o que cada pessoa faz e como contribui para o todo, e geralmente consegue avaliar com precisão recompensas, promoções e demissões
    Por isso o moral da equipe não afunda. As pessoas da equipe precisam psicologicamente ter suas contribuições individuais reconhecidas
    Esses gestores muitas vezes foram contribuidores individuais competentes antes de virar líderes de equipe e, por dominarem a própria habilidade, estão na melhor posição para avaliar os contribuidores individuais que gerenciam
  • Acho que uma forma subestimada de lidar com esse fenômeno é fazer autopromoção do jeito certo. Você precisa falar sem parar sobre o que fez para evitar desastres
    É preciso descrever de forma vívida os desastres evitados, para que as pessoas consigam formar uma imagem clara

• Outra variação é alocar recursos em excesso para evitar um problema que de fato aconteceu uma vez, enquanto se dá menos atenção a problemas mais graves que ainda não ocorreram
  Isso é um problema de gestão. Porque, mesmo que fosse racional fazer outra coisa mais importante, ninguém quer ser responsabilizado se o mesmo incidente se repetir

  • Já vi isso ser chamado em algum post de blog de cicatriz institucional
    É como substituir um pequeno ferimento por uma organização endurecida e sem flexibilidade. Só porque algo aconteceu uma vez não significa que seja necessário mudar tudo para garantir que nunca mais aconteça, e esse tipo de reação excessiva pode virar um grande peso no futuro
    Pode ser melhor aceitar essa perda e reconhecer que talvez aconteça de novo, em vez de exagerar na prevenção em nome de uma garantia absoluta
  • Boa parte da legislação reativa nos códigos também existe mais porque políticos querem parecer que estão fazendo alguma coisa, e no geral ela é péssima
  • É assim que a burocracia nasce, no fundo. Startups são tão novas que ainda não houve tempo para os problemas acontecerem. Big Techs têm uma base de conhecimento enorme sobre incidentes passados e as proteções criadas como consequência, então cada etapa parece afundada em burocracia
  • É muito fácil inflar a probabilidade e a gravidade de problemas completamente imaginários. Isso pode ser apenas um mau hábito ou uma tática deliberada. De qualquer forma, muito esforço, tempo e dinheiro são desperdiçados
    Uma política de não alocar recursos de prevenção até que algo realmente aconteça é razoavelmente racional
  • Trabalhei a carreira toda em tecnologia financeira, então não sei como é em outras organizações, mas isso descreve o problema com muita precisão. Grandes bancos de investimento reagem exatamente assim
    Passei um ano miserável tentando convencer as pessoas de que estavam reagindo de forma exagerada a falhas e de que havia soluções muito simples para os problemas que realmente ocorreram. Mas, se um gerente sênior acha que a própria posição está em risco por causa de uma recorrência, ele manda o departamento inteiro revisar e corrigir código com problemas semelhantes. E, estranhamente, ouve mais alto quem propõe a solução mais absurdamente superprojetada
    Em outra ocasião, a stack de trading caiu por causa de expiração de senha. Foi absurdo o esforço investido numa solução artesanal ridiculamente complexa para fazer isso “nunca mais acontecer”. No fim, depois de mais de um ano de trabalho, tudo foi descartado e substituído por uma solução centralizada muito mais simples, que era o que deveria ter sido feito desde o começo

• Isso me lembrou um lugar onde trabalhei. Toda vez que eu pedia feedback, repetiam: “aqui nada vira prioridade sem um PIR (post-incident response)”
  Perto do fim, quando apareciam tickets ligados a PIR, eu os marcava como duplicatas de tickets reais que poderiam ter evitado aquele incidente, mas estavam morrendo no backlog. Não ter qualquer influência para evitar problemas previsíveis na nossa área derrubou muito o moral do time
  A maior parte da equipe simplesmente parou de sugerir melhorias. A gerência não permitia que puxássemos tickets por conta própria

• Descreve muito bem o inferno em que o Scrum corporativo está se transformando
  Agile era, literalmente, trabalhar rápido e melhorar a capacidade em ciclos curtos. Mas o Scrum virou uma versão pior do processo de planejamento que pretendia substituir
  A forma como o Scrum quebra o trabalho em problemas imediatos na frente do nariz acaba piorando esse ciclo. No longo prazo, vira um sistema de tickets em que os incêndios sobem para o topo e a dívida técnica é empurrada para baixo
  E ainda cospe números de eficiência fáceis de rastrear, mas sem sentido, perfeitos para consultores e executivos brincarem de otimização

  • Você diz que “o Scrum virou uma versão pior do processo de planejamento que pretendia substituir”, como se isso fosse acidental
    Posso falar isso. Tenho amigos próximos que são scrum masters
  • No fim, parece que Agile virou um jeito de PMs reportarem para a alta gestão, que por sua vez também precisa reportar para cima
    Dá para entender por quê. Entre as muitas coisas que poderiam ser feitas, alguém precisa decidir o que fazer. Essa funcionalidade vai gerar dinheiro? E esse trabalho que não é funcionalidade, mas reduz custo de recursos? E a dívida técnica que desacelera a entrega de funcionalidades?
    Eu não sou executivo, mas no fim alguém lá em cima é responsável por manter a empresa viva, lucrando e pagando nossos salários. E essas pessoas também precisam decidir com a pouca informação que conseguem obter, assim como nós. Então elas precisam de um jeito de comparar “quanto isso custa e quanto vale” com “quanto aquilo custa e quanto vale”
    Precisavam de um jeito de estimar isso, e quando a indústria de tecnologia promoveu o Agile como esse meio, elas agarraram a ideia. De quem é a culpa?
    A partir daí vieram as estimativas frequentes, o acompanhamento de cronograma e os rituais. Tem gente que não acredita que isso precise vir junto, e eu concordo. Mas, de todo modo, esses rituais acabaram virando parte do culto
    Nós abandonamos o Scrum, e também as reuniões de refinement, estimativas de histórias e story points. Agora nos reunimos formalmente com o PM uma vez por mês e olhamos onde estamos apenas no nível do time, com estimativa por tamanho de camiseta. Fora isso, só damos atualizações quando o PM pede ou quando sentimos necessidade. Isso nos dá autonomia, mas também a responsabilidade de avisar a tempo quando a situação parece instável. Ainda precisamos fazer “estimativas”, claro. No fim das contas, a alta gestão precisa tomar decisões. Mas, no geral, ficou bem leve e realmente libertador
  • A ideia de que o Scrum é eficiente quando é bem executado foi verdadeira em uma empresa onde trabalhei
    Todo mundo estava comprometido com o processo, e o time de Scrum reservava 20% do esforço para priorizar dívida. A velocidade de cada um também era bem precisa, então dava para incluir mais 20% para trabalhos de interesse pessoal, e as prioridades dos stakeholders preenchiam os 60% restantes
    Em alguns sprints, quando era preciso concentrar esforços para fechar um épico ou um objetivo do time, ou quando urgências/bugs exigiam mudança de prioridade, nós mudávamos de direção
  • Funcionava melhor ir empilhando Scrum aos poucos, adicionando um pouco de processo quando aparecia um problema e afrouxando o processo quando as coisas estavam fluindo bem
    Colocar um monte de processo só porque se quer colocar processo não gera valor
  • Eu achava que Scrum significava todo mundo se juntar correndo para terminar o trabalho no stand-up semanal

• Isso me lembrou este quadrinho preso no escritório: https://naksecurity.medium.com/the-detriments-of-hero-cultur...
  Por isso, em muitas culturas corporativas, se um problema não estiver na sua área imediata de responsabilidade, costuma ser mais recompensador não preveni-lo de forma proativa, mesmo que você saiba como corrigir. Basta deixar o problema aparecer, virar a emergência de alguém, e então corrigir
  Claro que, no longo prazo, uma organização assim não tem como dar certo, então também é preciso planejar a saída

  • Acho que, com o tempo, as pessoas percebem quem está promovendo simulados de incêndio todo mês e quem está apenas fazendo o trabalho em silêncio

• Isso me lembra “Ninguém recebe reconhecimento por consertar um problema que nunca aconteceu” (2001) [pdf]
  Sempre penso nisso quando youtubers ou clickbaits de redes sociais afirmam que o bug do Y2K não foi nada demais
  O motivo de não ter sido nada demais é que inúmeros veteranos como eu passaram noites em claro, durante meses, fazendo tudo funcionar
  Ainda lembro da tensão na contagem regressiva da meia-noite em UTC. Depois fiquei tenso de novo na contagem regressiva do horário do leste, e mais uma vez no horário local. Só consegui relaxar de verdade quando chegou o ano 2000 no horário do Pacífico

  • Depende de qual bug do Y2K você está falando, mas esse tipo de coisa realmente aconteceu e é um cenário bastante plausível. Não acho que seja uma situação comparável
  • Ainda não me convence totalmente. Os computadores não usam principalmente epoch time em vez de dd/mm/yy para datas?
    Vamos descobrir em 2038

• Para a mesma época, o Y2K também é um ótimo exemplo. Quase nada visível aconteceu, mas, se as pessoas simplesmente tivessem ignorado, é bem provável que muita coisa teria acontecido

  • Não é “provável”. Eu mesmo trabalhei corrigindo código na BP em 1998. Posso afirmar que coisas ruins teriam acontecido
    Não era porque meu salário dependia disso. Obviamente havia muitas outras oportunidades de trabalho. Era de fato um problema que poderia ter paralisado o setor de energia e teria afetado grandes empresas e as inúmeras organizações que dependiam delas. Pela minha experiência, acho que vários setores, como finanças ou desenvolvimento de recursos, também teriam sofrido impactos semelhantes, direta ou indiretamente
    Então é um bom exemplo. Ainda encontro gente que lembra do Y2K como um alvoroço por nada. Não foi. Se não foi um problema para você, foi porque muita gente trabalhou duro para impedir
    Os problemas não eram extremamente complexos, mas estavam muito espalhados, eram importantes e exigiam um volume enorme de trabalho. Em vez de um problema de engenharia do nível do pouso na Lua para exibir como grande feito da humanidade, era mais como corrigir uma infinidade de problemas idiotas de O-ring do Challenger antes que tudo explodisse
  • É um caso muito importante. Houve um investimento enorme para corrigir o Y2K, e isso começou muito antes da data em si. Por exemplo, produtos financeiros com vencimento após o Y2K precisavam ser corrigidos antes de vencer
    Por isso, no dia em si, restaram só alguns bugs residuais menores. Houve algumas piadas nos jornais, mas o público em geral simplesmente seguiu em frente
    Trabalho na área de clima e eu esperava, ou espero, que aconteça a mesma coisa. Mas parece que em breve isso inevitavelmente vai chamar a atenção de todo mundo
  • É o paradoxo da preparação
    Quando você está preparado, nada interessante acontece, a vida continua, e as pessoas lembram disso como se tivessem só aberto o notebook e apertado alguns botões
    Quando você não está preparado, a rede elétrica do Texas congela, pessoas morrem, perdem suas economias, e vira “ninguém imaginava que pudesse ser tão ruim assim”
  • Já vi até pessoas que deveriam saber mais dizendo que o Y2K não foi nada demais, e que o esforço de prevenção foi um completo desperdício de impostos
    Confesso que eu também participei desse trabalho. O engraçado é que fui chamado de volta a um cliente anterior para corrigir um problema que, literalmente, tinha sido criado pelo meu próprio trabalho no passado. Consertei em 20 minutos assim que vi o problema. E então começou o “já que você está aqui, pode dar uma olhada nisso também...”, e isso durou cerca de 2 anos, até aquele departamento ser fechado e transferido para Nova York
    Pelo menos fui reconhecido em horas faturáveis

• Como este texto foi escrito logo depois, achei que seria sobre Y2K
  Durante alguns anos no fim dos anos 90, trabalhei em projetos de Y2K ajudando a garantir que infraestruturas críticas do Reino Unido não parassem à meia-noite. Por exemplo, sem o nosso esforço, o País de Gales teria ficado sem água ou gás
  Mas depois ouvi coisas como “já que nada aconteceu, claramente não era um problema, então por que gastaram tanto dinheiro com Y2K?” ou “Y2K foi uma fraude inventada pela indústria de TI”
  Nós vencemos. Impedimos com sucesso o bug do Y2K, foi um trabalho duro, e nem tínhamos certeza de que teríamos pego tudo até a meia-noite. Mas, em vez de sermos parabenizados, alguns viram isso como prova de que tínhamos superfaturado. As pessoas são estranhas

  • Conheço vários problemas assim. Eu também fiz com que a pontuação máxima de um videogame em que eu trabalhava funcionasse direito
    O irritante é que, com a mudança climática, o melhor cenário é igual a esse. Se realmente conseguirmos evitar o apocalipse, todos os “negacionistas do clima” vão sentir que estavam certos

[GN⁺]

Comentários no Hacker News

• O título me lembrou uma interessante anedota da China antiga. Também é um pouco irônico que a Toyota tenha se envolvido recentemente em um escândalo: https://www.bbc.com/news/articles/c1wwj1p2wdyo
  Quando o rei Wen de Wei perguntou a Bian Que: “Se os três irmãos são médicos, qual deles é o melhor?”, Bian Que respondeu: “Meu irmão mais velho é o melhor, o segundo é o próximo, e eu sou o pior”.
  O irmão mais velho percebia a doença antes mesmo de ela tomar forma e a eliminava discretamente, por isso seu nome era conhecido apenas dentro da família; o segundo tratava a doença quando ela estava prestes a se manifestar, então seu nome não ia além dos becos da vila; já o próprio Bian Que furava vasos sanguíneos, usava remédios fortes e cortava a carne, e por causa dessas ações visíveis seu nome se espalhou entre os senhores feudais.

  • Dá para aplicar isso diretamente a uma organização de software: “O irmão mais velho impede o bug antes que ele exista, então só a própria equipe de desenvolvimento conhece sua habilidade; o segundo conserta o bug discretamente assim que ele aparece, então todo o departamento técnico conhece sua habilidade. Eu vivo correndo para apagar incêndios por toda parte, então a empresa inteira me conhece”.
  • É o mesmo princípio do ditado de que uma onça de prevenção vale mais que um quilo de cura.
  • Chamar o escândalo da Toyota de “recente” é forçar um pouco, já que essa matéria é de junho de 2024.
  • Em termos mais simples: “Um ponto dado a tempo economiza nove… mas eu sou pago pela quantidade de pontos”.
  • Fiquei curioso sobre a fonte dessa anedota. Tentei encontrá-la no Zhuangzi, mas não consegui.

• Já passei por uma empresa em que o “departamento que sofre” recebia elogios e aumento de orçamento no trimestre seguinte por ter heroicamente remediado os problemas que eles mesmos criaram.
  Enquanto isso, o meu departamento, que funcionava bem em silêncio, mal conseguia manter as luzes acesas.
  A desconexão entre a gestão não técnica, que mal entende um duplo clique, e a engenharia que realmente sustenta a empresa é um problema sério neste setor. Fora fazer com que a liderança venha da engenharia, não consigo pensar muito em solução.

  • É preciso colocar sinais de dor no sistema. Assim como, se uma mão se machuca mas não envia dor ao cérebro, você não muda o comportamento ou as prioridades que causam dano, numa organização também nem sempre é melhor corrigir tudo em silêncio e impedir que os problemas subam.
    Alguns problemas precisam enviar esse sinal de dor para cima antes do conserto, para que virem oportunidade de aprendizado para a liderança.
    Claro que desenhar os incentivos é difícil, e a alta gestão não pode criar uma estrutura em que subordinados e departamentos sejam impedidos de mostrar dor e problemas. Também é comum haver gente bem-intencionada escondendo os sinais, então em organizações grandes talvez seja mais eficiente deixar alguns problemas se desenrolarem e orientar para que não se reaja de forma excessivamente reativa.
  • Em mais de 35 anos trabalhando com TI, uma das atitudes que mais detestei foi a de bancar o herói. Em compensação, sempre achei que uma equipe precisa de engenheiros “destruidores”.
    Quando todos projetam assumindo condições normais e operação perfeita, é importante haver alguém que descubra como quebrar o design, o serviço, a infraestrutura e o aplicativo.
  • Num emprego antigo, o CEO e dono teve a ideia de dar um bônus de cerca de 20% da economia do primeiro ano para quem encontrasse redução de custos.
    Um colega de TI poderia ter recebido pouco mais de 2.000 euros ao trocar certificados comerciais por Let’s Encrypt e eliminar exigências de EV, mas no fim não recebeu. Disseram que isso era “parte do trabalho”.
  • Já vi um gestor fracassado continuar sendo promovido até acabar, na prática, responsável por toda a engenharia. Todos os projetos falhavam, mas ele ganhava mais orçamento e mais desenvolvedores para ampliar e reiniciar tudo, e no fim passou a operar tudo.
    As equipes que construíam serviços que realmente funcionavam tiveram orçamento congelado e ainda perderam gente.
  • Como ponto de partida, acho bom rastrear e reportar tudo o que foi feito de forma proativa. Assim, alguém pode perceber por que está tudo quieto: porque os problemas foram previstos e evitados antes de começarem.
    Quando estoura um problema em outra equipe, a nossa consegue mostrar, com a lista de trabalhos concluídos, por que não tivemos o mesmo problema. O trabalho já tinha sido feito, só que num momento melhor, que permitia evitar indisponibilidade.

• Isso acontece muito. Gosto especialmente da ideia de que soluções elegantes, vistas depois, quase sempre parecem simples.
  Você passa um tempão pensando, encontra uma solução inteligente e, ao explicá-la, a outra pessoa reage com um “sim, claro”.
  Já a pessoa ao lado, que tornou o problema desnecessariamente complicado, acaba sendo elogiada por ter criado algo tão difícil.

  • A frase de Blaise Pascal cai como uma luva: “Escrevi mais longo do que o habitual porque não tive tempo de fazer mais curto”.
  • Tenho a sensação de que a programação com IA está empurrando o trabalho de todo mundo para uma complexidade de solução maior. Por isso, em vez de admirarem a complexidade dos outros, as pessoas parecem ficar mais defensivas e mais avessas a ela.
    Grandes empresas talvez ainda estejam atrasadas, ainda admirando a complexidade, mas para quem recebe resultados de IA, direta ou indiretamente, a complexidade já não impressiona como antes.
  • Por outro lado, eu já não ajudo mais as pessoas com problemas no computador. Quanto mais difícil o problema, seja recuperação de dados ou qualquer outra coisa, mais tempo leva; e quanto mais tempo leva, menos admiração há.
    Quanto mais milagrosa a recuperação, mais ouço histórias do tipo “meu sobrinho resolveu um probleminha na hora”, como se isso servisse para destacar que eu não consegui fazer o mesmo.
  • Houve recentemente no HN uma discussão sobre como os artigos de Claude Shannon eram cheios de explicações claras. Alguém comentou que uma solução elegante para um problema poderia ser explicada de forma curta e bela, a ponto de um estudante do ensino médio entender, ou de forma prolixa e complicada.
    O responsável aconselhou usar a versão complicada, porque assim seria publicada. Não é que a solução fosse inteligente; é que ela precisava soar complexa para ser reconhecida.
    Isso se encaixa perfeitamente com a realidade em que se elogia o processo complicado em vez da solução bonita, e provavelmente é assim que a burocracia também nasce.
  • Gestores percebem complexidade pelo quanto algo os confunde. Agora, mais para o fim da carreira, acho que desperdicei incontáveis horas tentando escrever código limpo, amigável ao usuário e fácil de manter.
    Esse código era esquecido 15 minutos depois do lançamento e ninguém mais o lia, embora continuasse em uso por anos. Por isso acho que a IA pode tirar empregos muito mais rápido do que muita gente imagina.
    Código limpo, separação de responsabilidades e manutenibilidade — justamente onde mais gastávamos tempo — na prática nunca foram valorizados. Se estiver “bom o suficiente”, o gestor fica satisfeito, e quando der problema a IA pode remendar, nem que seja em estilo espaguete.

• No meu emprego anterior havia um problema parecido. Eu gastava quase todo o meu tempo com trabalho administrativo de bastidores, como marcar reuniões e garantir que as pessoas tivessem as informações necessárias antes delas
  Mas, na avaliação de desempenho, só importava que eu não tinha concluído muitos story points porque estava ocupado impedindo que o trabalho desmoronasse
  Então parei totalmente com o trabalho administrativo e foquei só em concluir story points; uma ou duas semanas depois, o gerente perguntou ao time: “Por que todas as reuniões estão dando errado? Quando entramos na reunião, ninguém sabe o que está acontecendo”

  • É parecido com imaginar o que teria acontecido com o 4077th MASH se o Radar O’Reilly tivesse sido transferido

• Depois de passar quase dois anos fazendo uma quantidade enorme de trabalho de rede, hardware e TI por causa da preparação para o Y2K, comecei a migrar para marketing. No fim, como “nada aconteceu”, quase todas as empresas consideraram que aquele tempo e dinheiro tinham sido desperdiçados
  Uma empresa chegou a exigir reembolso total, e quando eu disse que reembolsaria se pudesse desfazer o trabalho que tinha feito, eles concordaram. No dia seguinte, todo o sistema da empresa entrou em colapso
  Também era difícil assumir o suporte de rede da empresa do meu pai porque ele se recusava terminantemente a pagar meus honorários. Depois que outras duas pessoas não conseguiram resolver o problema e eu consertei em 15 minutos, ele ficou ainda menos disposto a pagar justamente porque só levou 15 minutos
  A capacidade de manter as coisas funcionando sem quebrar não era reconhecida; só era reconhecido consertar depois que quebrava. Marketing pagava melhor, e eu podia justificar meu salário todos os dias com números concretos. Gosto muito menos, mas sou mais respeitado do que em qualquer trabalho de TI que já fiz

  • Se você contratou um familiar ou amigo, acho que deveria pagar pelo menos o que essa pessoa normalmente cobra. Se é mesmo seu amigo, você deveria querer que ele se desse bem; e, para isso, precisa pagar o valor habitual ou simplesmente não incomodá-lo e procurar outra pessoa
  • Antes de entrar nessa área, há uns cinco anos, eu respeitava programadores porque programação e tecnologia pareciam um mundo mágico. Depois que entrei, a magia desapareceu completamente, e conheci muita gente insuportável a ponto de eu não querer falar com programadores na vida real
    O que recebe reconhecimento são coisas simples, como consertar impressoras, resolver problema A/B/C no computador e um Android Sudoku sem anúncios que fiz para amigos
    O trabalho principal, aquele pelo qual se recebe dinheiro, não recebe reconhecimento. Em vários setores, quando dinheiro entra na equação, cumprir seu papel contratual passa a ser visto como algo óbvio, então a gratidão diminui
    Quem não entende de tecnologia acha que desenvolvedor trabalha de casa e só trabalha 30 minutos por dia, e a IA piorou ainda mais essa imagem

• Ian Rush resumiu bem isso ao dizer: “O atacante é o melhor. Pode errar cinco vezes e, se marcar o gol da vitória, vira herói. O goleiro pode fazer defesas brilhantes, mas, se tomar só um gol, vira vilão”
  Em todo lugar onde trabalhei, recompensavam mais os bombeiros do que quem evitava o incêndio. O pior é que todo mundo, exceto as pessoas que definem os incentivos, sabe claramente que a conta é essa

  • Então como dá para desenhar esses incentivos? É quase uma questão de definição: é difícil recompensar trabalho invisível
    Também existe o outro lado. Há pessoas que gastam todo o tempo se preocupando com coisas que nunca vão acontecer, então não é um problema que se resolva simplesmente recompensando postura defensiva

• É assim que acontecem promoções no trabalho. A pessoa quebra alguma coisa, o caso é escalado, ganha visibilidade, chega um e-mail ao executivo. Depois, quando ela “conserta”, todo mundo agradece e diz que fez um ótimo trabalho
  Outra versão é adiar por muito tempo algo que já deveria ter sido feito, só para aumentar a visibilidade. Os executivos não veem o trabalho de quem assume a responsabilidade e encerra tudo antes de virar problema
  Em vez disso, lembram o nome de quem quebrou algo e “salvou” o dia

  • Também existe a apunhalada sociopata pelas costas. Alguém quebra alguma coisa, joga a culpa em você, suja seu nome, aumenta o problema e depois vai “consertar”, piorando ainda mais por incompetência
    Enquanto isso, puxa saco do executivo e diz coisas como “é melhor não deixar com o doublerabbit” ou “acho que ele não é um team player”. E isso apesar de toda a infraestrutura ser minha
    É por isso que as pessoas perguntam por que eu odeio seres humanos

• Eu já tinha aprendido isso no primeiro ano do ensino fundamental. As crianças que ficam quietas na aula e fazem a lição não consomem muito tempo nem esforço da professora
  Quem recebe a atenção da professora são os alunos-problema, que não seguem as regras e precisam de elogio constante sempre que fazem o mínimo esforço para estudar

  • A expressão que eu sempre ouvi para isso é: “A roda que range é a que recebe graxa”

• O tempo que passei em TI oscilou entre dois extremos
  “Está tudo funcionando bem por aqui. Por que estamos pagando TI?”
  “Está tudo quebrado. Por que estamos pagando TI?”
  Pessoalmente, eu prefiro o primeiro caso ao segundo. Eu costumava dizer: “Se eu fizer meu trabalho direito, nem vão saber que eu estou aqui”. Mas fui demitido por causa disso
  Num nível de carma, continuo em contato com pessoas da antiga empresa, e hoje aquilo está um caos completo. Isso pelo menos traz algum consolo

• Depois que você conhece a armadilha da competência, começa a vê-la em todo lugar
  Sterman, Repenning e outros colaboradores escreveram vários artigos depois deste, e todos são interessantes, mas quase todos deprimem
  Isso fica ainda pior pelo fato de que a MIT Sloan, onde a dinâmica de sistemas primeiro se firmou como disciplina acadêmica, fica logo ao lado da Harvard Business School, onde a dinâmica de sistemas foi ignorada pela primeira vez

  • A parte do conceito de armadilha da competência que não entendo é por que se espera que uma empresa que é boa em uma coisa também seja boa em algo novo. Fico me perguntando exatamente o que faz da armadilha uma armadilha