Joel on Software

Joel on Software   Joel sobre Software

 

Outros artigos de "Joel on Software" em Português

Outros artigos de "Joel on Software" em Inglês

Envie email para o autor (apenas em Inglês)

 

Fazendo as coisas darem certo quando se é apenas um Peão


Por Joel Spolsky
Traduzido por Carlos Duarte do Nascimento
Editado por Gustavo Duarte
25 de Dezembro de 2001

Este site deveria ser sobre gerenciamento de software. Mas às vezes você não tem o poder para criar mudanças em sua organização pela via executiva. É óbvio que se você é um programador peão na parte mais baixa do totem, não dá para sair baixando ordens para que as pessoas comecem a criar cronogramas ou cadastros de bugs. De fato, mesmo que você seja um gerente, você provavelmente descobriu que gerenciar desenvolvedores é como cuidar de um rebanho de onças, só não é tão divertido. Apenas dizer “façam assim” não faz as coisas serem feitas assim.

Pode ser frustrante trabalhar em uma empresa que faz poucos pontos no Teste Joel . Não importa o quanto seu código é bem escrito, seus colegas de trabalho programam tão mal que você fica com vergonha de ser associado ao projeto. Ou a gerência toma decisões erradas sobre o que programar, e você é forcado a desperdiçar seu talento debugando a versão para AS/400 de um jogo infantil de planejamento de aposentadoria.

Creio que você poderia simplesmente sair da empresa. Mas provavelmente existe alguma razão que te mantém preso nela. As opções de ações ainda não foram efetivadas, não há lugar melhor pra trabalhar em Chapecó, ou talvez seu chefe mantenha alguma pessoa que você ama como refém. Em qualquer caso, tocar a vida em uma equipe ruim pode deixar qualquer um furioso. Mas existem estratégias para melhorar seu grupo partindo de baixo, e eu gostaria de compartilhar algumas delas:

Estratégia 1: Simplesmente Faça.

Muita coisa pode ser feita por uma única pessoa para melhorar um projeto. Não temos um servidor para builds diários? Crie um. Configure na sua própria máquina uma tarefa agendada para fazer builds noturnos e enviar os resultados por e-mail. São necessários muitos passos para o build? Escreva o makefile para automatizar o processo. Ninguém faz testes de usabilidade? Improvise os seus próprios testes de usabilidade com o pessoal da cantina usando um pedaço de papel ou um protótipo em VB.

Estratégia 2: Use o Poder do Marketing Virótico

Muitas das estratégias do Teste Joel podem ser implementadas por uma única pessoa em uma equipe que não coopera. Algumas delas, se forem bem feitas, irão contaminar o resto da equipe.

Por exemplo, vamos supor que ninguém na sua equipe possa ser convencido a usar um cadastro de bugs. Não deixe isso te incomodar. Simplesmente mantenha o seu próprio cadastro. Cadastre nele os bugs que você encontrar nos seus próprios programas. Se você encontrar um bug que outra pessoa deveria consertar, atribua-o a esta pessoa usando o cadastro de bugs. Se você tiver um bom software de gerenciamento de bugs , ele irá enviar a esta pessoa um e-mail. Mas agora você pode mandar e-mails continuamente se eles não consertarem o bug. Com o tempo, eles vão perceber o valor do gerenciamento de bugs e começar a usar o sistema como deveriam. Se o grupo de Garantia da Qualidade recusar-se a cadastrar os bugs no sistema, simplesmente recuse-se a receber relatórios de bugs de outra forma. Depois da trezentésima vez que você disser às pessoas “escute, eu adoraria consertar isso, mas eu vou acabar esquecendo. Você poderia cadastrar este bug no sistema?”, eles vão começar a usar o cadastro.

Ninguém na sua equipe gosta de usar controle de código-fonte? Crie seu próprio repositório do CVS, no seu próprio HD se necessário. Mesmo sem cooperação, você pode fazer check-ins do seu código independente do código de todos os outros. Assim, quando eles tiverem problemas que o controle de código-fonte pode resolver (alguém acidentalmente digitou rm * ~ ao invés de rm *~), eles vão pedir a sua ajuda. Com o tempo as pessoas vão perceber que também podem fazer seus próprios checkouts.

Estratégia 3: Crie um Bolsão de Excelência

A equipe não gosta de fazer cronogramas ? Ou especificações ? Escreva-os você mesmo. Ninguém vai reclamar se você gastar um ou dois dias escrevendo uma especificação mínima e um cronograma para o trabalho que você vai fazer em seguida.

Traga gente melhor para a equipe. Envolva-se com o processo de contratação e entrevistas, e recrute bons candidatos para a equipe.

Descubra as pessoas que têm vontade e capacidade de melhorar, e traga-as para o seu lado. Mesmo em equipes de nível muito baixo, você provavelmente tem algumas pessoas inteligentes que apenas não têm experiência suficiente para criar bom código. Ajude-os. Oriente o aprendizado deles. Leia seus check-ins de código. Se eles fizerem algo idiota, não escreva um e-mail arrogante explicando o que há de idiota nos seus checkins. Isso só vai deixá-los irritados e na defensiva. Ao invés disso, inocentemente notifique o erro na aplicação que você sabe que foi causado pelo checkin. Deixe-os descobrir o que está causando o problema. Quando eles encontrarem o bug sozinhos, vão se lembrar muito melhor desta lição.

Estratégia 4: Neutralize os Manés

Mesmo as melhores equipes podem ter um ou dois manés. A parte frustrante de ter maus programadores no seu grupo é quando o código ruim deles estraga o seu código bom, ou quando bons programadores têm que gastar seu tempo limpando a sujeira dos maus programadores.

Como um peão, seu papel é minimizar os danos, também conhecido como contenção. Vai chegar a hora em que um desses gênios vai passar duas semanas escrevendo um trecho de código que é tão inacreditavelmente péssimo que nunca vai funcionar. Você vai ficar tentado a gastar os quinze minutos necessários para reescrever o código do zero. Resista à tentação. Você tem a oportunidade ideal para neutralizar este estúpido por alguns meses. Basta reportar continuamente erros no código deles. Eles não vão ter escolha e vão ter que ficar se arrastando por meses até você não encontrar nenhum erro. Esses serão meses em que eles não vão poder causar danos em nenhum outro lugar.

Estratégia 5: Livre-se Das Interrupções

Todos os ambientes de trabalho agradáveis são iguais (escritórios individuais, silêncio, ferramentas excelentes, poucas interrupções e pouquíssimas reuniões extensas). Todos os ambientes de trabalho desagradáveis são desagradaveis do seu jeitinho particular.

A má notícia é que é quase impossível modificar o ambiente de trabalho em praticamente qualquer empresa. Aluguéis com contratos de longo prazo podem significar que nem o CEO pode fazer algo a respeito. É por isso que tão poucos desenvolvedores de software têm escritórios particulares. Isso prejudica suas empresas pelo menos de duas formas. Primeiro: isso torna mais difícil contratar os desenvolvedores topo-de-linha, que vão preferir as empresas que lhes derem condições mais confortáveis (quando todos os outros fatores empatarem). Segundo: a quantidade de interrupções pode reduzir dramaticamente a produtividade dos desenvolvedores, que consideram impossível entrar num estado de concentração absoluta e permanecer nele por um tempo significativo.

Procure maneiras de sair deste ambiente. Leve um laptop à lanchonete da empresa, onde há várias mesas que ficam vazias a maior parte do dia (e ninguém vai poder te encontrar). Reserve uma sala de reunião para o dia inteiro e fique lá programando, e mostre através da preponderância de checkins como você faz muito mais coisas quando está numa sala própria. Da próxima vez que cair a casa e o seu gerente perguntar o que você precisa para Fazer Isto Pra Amanhã, você saberá o que dizer. Eles vão arrumar um escritório para você usar naquele dia. E logo vão começar a tentar descobrir o que podem fazer para manter aquela produtividade o ano todo.

Chegue no trabalho tarde e saia tarde. Essas horas depois que o resto da empresa foi pra casa podem ser as mais produtivas. Ou, se você está numa equipe de desenvolvedores que costumam chegar tarde, chegue no serviço às 9 em ponto. Você vai produzir mais nessas duas horas antes do pessoal chegar e começar a te incomodar do que em todo o  resto do dia.

Não deixe seu cliente de e-mail ou instant messenger abertos. Cheque seu e-mail de hora em hora, se quiser, mas não o deixe aberto.

Estratégia 6: Torne-se Valioso

Nenhuma dessas estratégias funciona se você não for um excelente colaborador. Se você não programar bem, e bastante, você só vai ser acusado de ficar brincando com seu cadastro de bugs quando “deveria” estar programando. Não há nada mais perigoso para sua carreira do que ter a reputação de se preocupar tanto com a burocracia que não consegue realizar nada.

Uma vez, quando comecei num novo emprego como um simples programador numa nova empresa, eu descobri que ela estava marcando mais ou menos uns dois pontos no Teste Joel , e estava determinado a consertar isto. Mas eu também sabia que fazer uma boa primeira impressão era crucial. Então resolvi alocar as primeiras sete horas do dia só para programar, que era o que as pessoas esperavam de mim. Não há nada como uma enxurrada de checkins para fazer uma boa imagem para o resto da equipe de desenvolvimento. Mas eu reservei outra hora toda tarde antes de ir pra casa para melhorar o processo. Eu usava esse tempo para consertar coisas que tornavam difícil depurar nosso produto. Configurei um build diário e um cadastro de bugs. Consertei todas aquelas coisas irritantes que já estavam lá há um bom tempo e tornavam o desenvolvimento difícil. Escrevi especificações para o trabalho que fazia durante o dia. Escrevi um documento explicando passo-a-passo como criar uma máquina de desenvolvimento do zero. Eu documentei exaustivamente uma linguagem interna de desenvolvimento importante que até então não tinha sido documentada. Lentamente, o processo foi melhorando cada vez mais. Ninguém além de mim (e da minha equipe, quando me colocaram para liderar uma) jamais fazia cronogramas ou especificações, mas fora isso nós marcávamos quase 10 no Teste Joel.

Você pode melhorar as coisas, mesmo quando não está no comando, mas você tem que ser a Esposa do César: acima de qualquer suspeita. Caso contrário, você vai fazer inimigos ao longo do tempo.

Esse artigo apareceu originalmente em Inglês com o título Getting Things Done When You're Only A Grunt  

Joel Spolsky é o fundador da Fog Creek Software, uma pequena empresa de software na cidade de Nova York. Formou-se na Universidade de Yale, e trabalhou como programador e gerente na Microsoft, na Viacom e no Juno.


O conteúdo dessas páginas reflete exclusivamente a opinião do autor.
Todo o conteúdo Copyright ©1999-2005 Joel Spolsky. Todos os direitos reservados.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky