Gerenciando Programadores Com Eficacia

Gerenciando programadores com eficácia Quando gerenciando uma equipe de programadores, uma das primeiras coisas que você deve aprender a fazer direito é alocação de tarefas. Este termo é apenas uma maneira mais elegante para dar coisas para as pessoas fazerem. Ele é conhecido coloquialmente em Hebreu como “empilhar pastas” (porque você empilha pastas nas mesas das pessoas). E como você decide que pastas colocar em que mesas é uma área onde você pode conseguir benefícios incríveis de produtividade se você fizer corretamente. Se fizer errado você cria uma daquelas situações desconfortáveis onde ninguém consegue fazer nada e todos reclamam que “nada fica pronto por aqui.” Como este é um site para programadores, vamos aquecer os cérebros um pouco com um problema de programação. Suponha que você tenha duas tarefas para executar, tarefas A e B. Cada uma delas requer 10 segundos de CPU. Você tem disponível uma CPU que, para efeitos desse problema, não tem mais nada em sua fila de execução. Nessa CPU, multiprocessamento é opcional. Então você pode executar as tarefas uma após a outra... Processamento Sequencial Tarefa A 1

2

Tarefa B 3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

... ou, você pode executá-las concorrentemente. Quando usando multiprocessamento, essa CPU executa cada tarefa durante 1 segundo, e não gasta tempo algum para trocar entre tarefas. Multiprocessamento 1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

Qual forma você usaria para fazer esse processamento? A maior parte das pessoas intuitivamente escolhe usar multiprocessamento. Em ambos os casos, é necessário esperar 20 segundos para obter as duas respostas. Mas considere quanto tempo demora para conseguir o resultado de cada tarefa. Em ambos os paradigmas, o resultado da tarefa B (mostrado em azul) é obtido após 20 segundos. Mas observe a tarefa A. Com multiprocessamento, ela termina de executar após 19 segundos... mas com processamento seqüencial ela está terminada em apenas 10 segundos. Em outras palavras, nesse pequeno exemplo artificial, o tempo de execução médio é mais baixo (15 segundos invés de 19.5 segundos) quando o processamento é feito de forma seqüencial, e multiprocessamento não é usado. (Na realidade, esse exemplo não é tão artificial assim – é baseado em um problema real que o Jared precisou resolver no trabalho). Método

Tarefa A demora

Tarefa B demora

Média

Seqüencial

10 segundos

20 segundos

15

Multiprocessamento

19 segundos

20 segundos

19.5

Assumimos para esse exemplo que uma troca entre tarefas nessa CPU não gasta tempo algum. Na realidade, em CPUs reais, uma troca entre tarefas demora um pouquinho... basicamente o tempo necessário para salvar o estado atual da CPU e carregar o estado dela para a outra tarefa. Realisticamente, esse tempo é o mais próximo de desprezível possível. Mas vamos tornar o problema um pouco mais interessante e imaginar que cada troca de tarefas demora meio segundo. Agora o quadro fica ainda pior:

Método

Tarefa A demora

Seqüencial

10 segundos

Multiprocessamento

19 + 18 troca de tarefas = 28 segundos

Tarefa B demora 20 + 1 troca de tarefas = 20.5 segundos 20 + 19 troca de tarefas = 29.5 segundos

Média 15.25 28.75

Agora ... apenas por diversão, sei que isso é absurdo ... e se cada troca de tarefas demorasse um minuto inteiro? Método

Tarefa A demora

Tarefa B demora

Seqüencial

10 segundos

20 + 1 troca de tarefas = 80 segundos

Multiprocessamento

19 + 18 troca de tarefa = 1099 segundos

20 + 19 troca de tarefas = 1160 segundos

Média 45 segundo s quase 19 minutos!

Quanto mais longa a troca de tarefas, pior é a penalidade por se usar multiprocessamento. Isso, por si só, não é tão abalador, é? Logo eu estarei recebendo emails irritados de imbecis me acusando de ser “contra” multiprocessamento. “Você quer voltar para a época do DOS, quando era necessário sair do WordPerfect para executar 1-2-3?” eles vão perguntar. Mas esse não é o meu argumento aqui. Eu quero apenas que vocês concordem comigo no seguinte: a) processamento seqüencial obtém resultados mais rápido em média, e b) quanto maior o tempo para troca entre tarefas, maior a penalidade de se usar multiprocessamento Ok, de volta ao tópico mais interessante de gerenciamento de humanos, não CPUs. A sacada aqui é que quando se gerencia programadores, especificamente, troca entre tarefas demora muito, muito, muito tempo. Isso é devido ao fato de programação ser o tipo de tarefa onde é necessário que se mantenha muitas coisas na cabeça simultaneamente. Quanto mais informação você lembra de uma vez, mais eficaz você é em programar. Um programador escrevendo código a todo vapor está mantendo zilhões de coisas na cabeça por vez: desde nomes de variáveis, estruturas de dados, APIs importantes, nomes de funções utilitárias que ele escreveu e usa frequentemente, até mesmo o nome do subdiretório onde ele guardou o código fonte. Se você mandar um programador passar férias em Creta por três semanas, ele vai esquecer tudo isso. O cérebro humano aparentemente move essas informações da RAM de curto prazo e coloca em uma fita de backup onde demora uma eternidade para resgatar. Quanto tempo? Bem, minha empresa de software recentemente largou o trabalho que estávamos fazendo (desenvolvendo um produto de software cujo codinome era CityDesk) para ajudar um cliente com uma situação urgente durante três semanas. Quando voltamos para o escritório, pareceu demorar outras três semanas para voltarmos a velocidade total de desenvolvimento do CityDesk. No nível individual – já reparou que você pode atribuir um serviço a uma pessoa, e ela vai fazer um trabalho excepcional, mas se você atribuir dois serviços para a mesma pessoa, ela não vai conseguir realmente terminar nada? Ela vai ou fazer um serviço direito e esquecer o outro, ou fazer os dois de forma tão lenta que uma lesma parecerá ágil. Isto é porque tarefas de programação demoram tanto tempo para serem trocadas. Eu sinto que quando eu tenho dois serviços envolvendo programação simultaneamente, a troca de um para o outro demora cerca de 6 horas. Em um dia de trabalho de 8 horas, esse multiprocessamento diminui minha produtividade para 2 horas por dia. Bastante desanimador.

Ao fim e ao cabo, se você der duas coisas para a mesma pessoa fazer, você deveria ficar feliz se ela se focar completamente em uma das tarefas e esquecer a outra, porque dessa forma ela será mais produtiva e em média vai terminar as tarefas mais rapidamente. De fato, a real lição a ser aprendida disso tudo é que você não deveria nunca deixar pessoas trabalharem em mais de uma coisa por vez. E tenha certeza de que elas saibam no que estão trabalhando. Um bom gerente vê suas responsabilidades como remover obstáculos para que pessoas possam se focar em uma única coisa e realmente cumpri-la. Quando uma emergência surgir, pense se você é capaz de resolvê-la sozinho antes de delegá-la a um programador que está submergido profundamente em um projeto. Artigo original em inglês escrito por Joel Spolsky - http://www.fogcreek.com Sobre o Tradutor: Guilherme Otranto é engenheiro de computação formado pela USP, atualmente trabalha na Olympya TI em desenvolvimento de games e suporte aos softwares da Fog Creek, www.fogcreek.com.br que são comercializados com exclusividade no Brasil pela http://olympya.com