Produtividade pra que, quem e como? - /dev/Kico
Kico (Henrique Lobo Weissmann) 27/10/2014 27/10/2014 4 Comments on Produtividade pra que, quem e como?
Diversas vezes caio nestas conversas em que a palavra produtividade pula como pipoca. Terminado o diálogo me afasto das pessoas, relembro o que dissemos e fico com a certeza de que só falamos bobagem. Por que?
O que é produtividade afinal?
Se você trabalha com desenvolvimento de sistemas ou qualquer outra atividade que envolva a geração de algum produto o termo produtividade sempre surge em conversas com gestores ou colegas ao tratarmos o modo como executamos nossas tarefas. E sabem o que é mais interessante? Não é raro vermos alguém sair chateado destas conversas. Quem é esta danada? Da forma mais ingênua possível, poderíamos defini-la como
Quanto você produz em determinado período de tempo.
Quantas linhas de código, funcionalidades, casos de uso, módulos, textos, imagens você produz por dia? Será que você consegue superar sua média? Existe uma meta em nosso ambiente de trabalho: será que você vai conseguir batê-la nesta sprint?
Percebem algo errado em todas estas perguntas e na própria definição? Eu sim: são vazias. Por que vazias? Por que raríssimas vezes tem um contexto. Não existe produtividade, mas produtividades.
As produtividades
Existe ferramenta de mais alta produtividade que o velho copiar e colar? Precisamos criar uma série de páginas, o tempo é mínimo, seu aperto máximo, sua mente em transe te diz para copiar e colar diversos trechos de código HTML e JavaScript em todas aquelas páginas. Você não pensa, age! O relógio, assim como você, não para: ctrl-c pra cá, ctrl-v pra lá, executa aqui, executa ali e voilá: as páginas estão prontas no prazo e você conseguiu! Algum gestor passa por você e te encara com satisfação naquele momento de cumplicidade efêmera.
Aquele dia foi de imensa produtividade, mas sempre a criatura volta para visitar seus pais cobrando as falhas de sua formação. E de repente o criador se vê sofrendo buscando tratar os traumas de sua criatura. Você fica horas (quando não dias ou meses) pagando o preço da sua economia porca.
A criatura sempre volta
No nosso amigo copiar e colar vemos um tipo específico de produtividade: a de curtíssimo prazo. É possível ter altíssima produtividade a curto prazo de tal modo que nossa criatura, ao visitar-nos, traga boas notícias? Sim, mas são raras estas situações.
Há também aquela outra ferramenta interessante que nos permite uma produtividade média a curto prazo (para a aflição dos gestores ansiosos) que nos propicia entregar bem próximo do prazo o que nos foi proposto fazer: se chama "pensar com calma". A usamos quando projetamos aquilo que desejamos obter. Por algum tempo nossa criatura não irá se mostrar de forma concreta, e dependendo de quão rico é o seu conhecimento a respeito do problema, pode ser que o prazo não seja cumprido.
A diferença é que sua criatura é melhor formada: as cicatrizes quando existem são mais discretas e fáceis de serem corrigidas. Seu cliente pode estar até chateado devido ao leve atraso, mas ele a vê funcionando e, ainda mais legal, você sente orgulho da sua criatura e mostra suas entranhas para seus colegas!
Todos sabemos que a maior parte da vida de um software ocorre após este ter sido entregue (em média 85% do tempo é gasto em manutenção). Aquele seu custo inicial transforma-se em lucro. Sua produtividade agora é altíssima na época que mais importa: manutenção.
Há uma balança aqui: alta produtividade no início, baixa no fim e vice-versa. Claro: quando você reaproveita conhecimento é possível ter altíssima produtividade durante todo o ciclo de vida do seu sistema, mas infelizmente estas situações são muito raras (ainda).
Kico: aonde você quer chegar com este papo?
Produtividade e valor. O que é valor?
Este é o ponto fundamental deste post. O termo produtividade só possuí sentido quando pensado como valor. "Valor" é outra destas palavras que usamos em vão. Algum tempo atrás passei a buscar seu real significado e isto mudou radicalmente (e de forma muito positiva) minha visão do mundo. Segue sua definição:
Valor é a justificativa por trás da escolha.
Por que você diz que seu Macintosh vale mais que um PC? Por que pagar mais pelo produto ou profissional X? Quanto vale Y? Produtividade por que? Pra quem? O que quero com isto?
Você comprou um Mac talvez por que considere uma máquina melhor montada, com excelentes componentes e um sistema operacional superior que não irá estragar tanto quanto o oferecido pela concorrência. Você pagou a mais pelo profissional X por que sabe que ele lhe entregará um resultado positivo dentro dos seus padrões e expectativas de qualidade. Estas razões são justificativas. Valorizar é apresentar justificativas para uma escolha. O tal do valor agregado? Um conjunto de justificativas a mais que mostrem que você estava certo.
Quando tratamos produtividade como valor a história muda. Aqui seguem dois exemplos baseados nas situações que falei acima:
Pode usar e abusar do copiar e colar, pois o que você está fazendo será usado uma única vez para em seguida ser jogado fora e não temos dinheiro o suficiente para algo melhor elaborado. (uma justificativa tosca, mas uma justificativa!)
Invista na arquitetura do seu sistema o máximo que puder pois queremos algo que durará 10, 15 anos e sabemos que 85% deste tempo será gasto em manutenção.
Percebe agora por que aquela conversa com seu gestor sobre produtividade te incomodava? Este é o tal do "contexto" que falei acima: as justificativas necessárias para que lhe seja cobrado determinado nível de produtividade.
Ainda mais importante: para quem você está sendo produtivo? Será que todos os seus clientes exigem o mesmo nível de produtividade? Esta questão deixo como dever de casa para você.
Ouvimos muito o termo produtividade quando o assunto é ferramental. "Programadores .net geram X pontos de função por hora, enquanto profissionais Java Y". Sério? Em quais contextos e restrições? Entende agora por que estas métricas normalmente não fazem sentido?
É aquela velha história da ferramenta certa para o trabalho certo. Programadores Java escrevem X linhas de código por hora. Me pergunto quanto produzirão caso precisem escrever algo de baixíssimo nível. Será que se aplica? Acho que o cara do Assembler ganha hein?
E tem também toda aquela história sobre o mito da bala de prata que o Fred Brooks fala com absoluta autoridade no "Mythical Man Month". O que é uma ferramenta valiosa?
É aquela que você adota em um dado contexto e se sente seguro com sua escolha por ter se baseado em um número significativo de justificativas. Dica: uma justificativa isolada não é suficiente para adotar um framework/linguagem/etc. E se a justificativa for apenas preferências pessoais… abre o olho!
A mensagem é simples: não existe produtividade em si. O termo produtividade só faz sentido com base em uma série de justificativas que, na prática, serão as restrições do seu problema.
E a produtividade? Em si é outro valor. Você a usará como um dos parâmetros para delinear seu caminho. Ela te responderá coisas do tipo: "este projeto é viável no prazo que recebi pois minha produtividade, baseada nestas justificativas, é X".
Uma justificativa, baseada em justificativas: uma meta-justificativa. :)
Como salvei /dev/Kico dos spammers
4 comments on "Produtividade pra que, quem e como?"
Rafael 28/10/2014 at 07:23
Kico (Henrique Lobo Weissmann) Post author 28/10/2014 at 08:07
Rene 28/10/2014 at 12:43
O que você consideraria produtividade para um líder técnico de equipe? O texto foi bastante focado no papel de um programador.
"Estou aparentemente sendo mais improdutivo para fazer com que minha equipe seja mais produtiva."
Como conseguir justificar uma afirmação dessas?
Kico (Henrique Lobo Weissmann) Post author 28/10/2014 at 12:48
Oi Rene, obrigado!
No caso, sempre são os requisitos do seu projeto. O que disse foi usando um programador como exemplo, mas na prática se aplica a qualquer situação.
Esta frase aí é meio perdida também né? No caso, dá para ver claramente que quem a disse está perdido. A questão é: por que sua equipe não está produzindo tanto quanto vocês esperavam? Qual a dificuldade? Qual produtividade vocês esperam? Como querem trabalhar? O que deve ser produzido?
Estas são as perguntas que deveriam ser feitas neste caso (ao menos o que me parece em uma primeira leitura)