Como Matar a Produtividade de Desenvolvedores

Existem várias formas de não matar a produtividade de desenvolvedores num projeto. Infelizmente, as reais causas nunca são comentadas.

Recentemente vi mais um artigo de "como não matar a produtividades de desenvolvedores", que diz exatamente o que todos os artigos sobre como não matar a produtividade de desenvolvedores diz: Basicamente "Evite interrupções".

Mas será que dá pra evitar interrupções mesmo? Não seria o "ping!" da cafeteira uma interrupção? Não seria a bexiga cheia uma interrupção? Não seria a campainha avisando que chegou a encomenda e/ou a tele-entrega uma interrupção?

Qual é a diferença entre essas e alguém pedindo ajuda?

E fazer menos reuniões? Por que? Porque ninguém se liga de fazer uma pauta de reunião para ter o que decidir? Ou será que é porque os desenvolvedores de frontend não dão a mínima para os problemas que o pessoal de backend está enfrentando e vice-versa?

Seria uma reunião marcada com uma semana de antecedência uma "interrupção"?

Eu não consigo ver que as interrupções em si são o problema. Imaginem o seguinte:

Essa pessoa passou por um onboarding quando entrou na empresa, e foi apresentado ao propósito da mesma, foi apresentado ao produto que a empresa vende e como o produto funciona, foi apresentada à arquitetura do sistema, foi explicado o motivo de cada solução aplicada, foi dado tempo para discutir outras soluções com seus pares, não foi colocado contra a parede para explicar cada minuto de trabalho do seu dia.

Dado isso, vocês conseguem imaginar que alguém fazendo uma pergunta sobre alguma parte do sistema enquanto quem está programando está no meio da função de frobnicar¹ foo? Talvez perca algum tempo para ver em qual ponto parou, mas como a solução já foi discutida, e já se sabe o propósito da funcionalidade sendo introduzida, a interrupção vai afetar muito pouco o resultado final.

Infelizmente, na área de TI, passamos muito tempo sendo vistos como "máquinas" e técnicas de produção são aplicadas diretamente sem considerar que somos pessoas (ou vocês acham que "kanban" nasceu no meio da TI mesmo e não dentro da fábrica da Toyota?).

Uma máquina parada é dinheiro perdido. Parar a produção para manutenção preventiva, sem que a máquina esteja realmente quebrada, tendo desmontar a mesma e verificar cada uma das partes, é dinheiro perdido.

E, infelizmente, quando um programador não está "programando", é visto como dinheiro perdido. E por isso coisas básicas, como explicar o porque o sistema existe, qual a ideia do fluxo de dados dentro do mesmo, deixando que programadores parem e discutam soluções e coisas do tipo são completamente ignoradas: Porque a "máquina" não está produzindo.

E, quando é preciso parar a produção, por qualquer motivo, a produtividade vai lá pra baixo.