|
|
|
|
+++
|
|
|
|
|
title = "Como Matar a Produtividade de Desenvolvedores"
|
|
|
|
|
date = 2020-07-20
|
|
|
|
|
|
|
|
|
|
[taxonomies]
|
|
|
|
|
tags = ["desenvolvedores", "programação", "ti", "onboarding",
|
|
|
|
|
"fluxo de dados", "arquitetura", "produtividade"]
|
|
|
|
|
+++
|
|
|
|
|
|
|
|
|
|
Existem várias formas de não matar a produtividade de desenvolvedores num
|
|
|
|
|
projeto. Infelizmente, as reais causas nunca são comentadas.
|
|
|
|
|
|
|
|
|
|
<!-- more -->
|
|
|
|
|
|
|
|
|
|
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[^1] 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.
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
[^1]: Eu não se tem alguma forma melhor de traduzir
|
|
|
|
|
[frobnicate](https://www.techopedia.com/definition/27996/frobnicate)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<!--
|
|
|
|
|
vim:spelllang=pt:
|
|
|
|
|
-->
|
