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)

 

Duas Histórias


Por Joel Spolsky
Traduzido por Gustavo Duarte
Editado por Rodrigo Quaresma
19. 3. 2000

Eu quero te contar duas histórias da minha carreira que na minha opinião são ilustrações clássicas da diferença entre empresas de tecnologia bem gerenciadas e empresas que são um desastre. A diferença se resume em confiar nos seus empregados e deixá-los realizar tarefas, ao invés de tratá-los como peões que devem ser monitorados e controlados todo o tempo, para que não comecem a andar sem rumo e sabotar tudo.

Meu primeiro projeto no meu primeiro emprego foi na Microsoft, onde eles me disseram para inventar uma nova linguagem de macro para o Excel. Rapidamente, eu escrevi o primeiro rascunho das especificações para o "Excel Basic" (que mais tarde evoluiu para o Visual Basic for Applications, mas isso é outra história). De alguma maneira, um grupo misterioso na Microsoft chamado "Arquitetura de Aplicações" ouviu falar das minhas especificações, o que provavelmente os preocupou, porque por alguma razão eles pensavam que eles eram os responsáveis por coisas como linguagens de macro, e eles pediram então para ver minhas especificações.

Eu perguntei ao meu redor. Quem é esse grupo de Arquitetura de Aplicações? Ninguém parecia achar que eles eram realmente sérios. No fim das contas, eles eram um grupo de apenas quatro pessoas, recém-contratados com PhDs (muito raro na Microsoft). Eu mandei-lhes uma cópia da minha especificação e fui conversar com eles, no caso de eles terem algo interessante a dizer.

"Blah blah!" disse um deles. "Blah blah blah, blah blah blah!" disse outro. Eu não acho que eles tinham algo realmente interessante a dizer. Eles estavam encantados com a idéia de subclassing e achavam que pessoas fazendo macros em Excel queriam fazer subclassing em várias tarefas. De qualquer maneira, um dos sujeitos disse, "Bem, isso é interessante e tudo. E agora? Quem tem que aprovar a sua especificação?"

Eu dei uma gargalhada. Apesar de eu estar trabalhando na Microsoft fazia poucos meses, eu sabia que não havia ninguém para aprovar minhas especificações. Diabos, ninguém tinha tempo para ler minhas especificações, quanto mais aprová-las. Os programadores me cobravam todo dia para dar-lhes mais páginas para que pudessem escrever mais código. Meu chefe (e o chefe dele) deixaram claro para mim que ninguém mais entendia de macros ou tinha tempo para trabalhar em macros, então o quer que eu fizesse deveria ser bem feito. E ali estava esse PhD trabalhando em um estranho grupo de pesquisas na Microsoft que assumiu que as coisas eram mais formais do que aquilo.

Eu rapidamente compreendi que o grupo de Arquitetura de Aplicações sabia ainda menos do que eu sobre macros. Pelo menos eu havia conversado com um punhado de desenvolvedores de macros e alguns veteranos do Excel para ter uma idéia do que as pessoas realmente faziam com macros de Excel: coisas como recalcular uma planilha diariamente, ou reagrupar dados de acordo com um certo padrão. Mas o grupo de Arquitetura de Aplicações havia meramente pensado sobre macros como um exercício acadêmico, e eles não conseguiam dar nenhum exemplo do tipo de macros que pessoas iriam gostar de desenvolver. Sob pressão, um deles teve a idéia de que, já que o Excel já tinha sublinhado e duplo-sublinhado, talvez alguém gostaria de desenvolver uma macro para triplo-sublinhado. Pois é. MUITO comum. Eu então decidi ignorá-los da maneira mais diplomática possível.

Isso aparentemente irritou um sujeito chamado Greg Whitten que era o chefe do grupo de Arquitetura de Aplicações. Agora, Greg era algo como o empregado número 6 da Microsoft. Ele sempre trabalhou na Microsoft; ninguém podia realmente apontar algo que ele tivesse feito mas aparentemente ele almoçava com Bill Gates frequentemente e o GW-BASIC foi batizado em sua homenagem. Greg agendou uma REUNIÃO IMPORTANTE e reclamou que o time do Excel (significando eu) estava atrapalhando a estratégia de macros. Nós o pressionamos para fornecer razões específicas mas seus argumentos simplesmente não eram convincentes. Eu achei legal o fato de que lá estava eu, um recém-empregado saindo fresco da faculdade, argumentando com o empregado número 6 e aparentemente vencendo o argumento. (Você consegue imaginar isso acontecendo em uma empresa de Terninho de Flanela Cinza?) Meu time de programadores, liderado por Ben Waldman (agora um Vice Presidente na Microsoft) me apoiou completamente, o que era tudo o que importava, porque o time de programadores escrevia o código e tinha então a palavra final em como as coisas eram feitas.

Eu estaria perfeitamente feliz em deixar as coisas morrerem ali. Se o grupo de Arquitetura de Aplicações precisava de carinho e atenção e precisava argumentar sobre as coisas, tudo bem, eu argumentaria com eles o tanto quanto quisessem desde que eles deixasse os programadores livres para fazer o seu trabalho. Mas então algo ainda mais interessante ocorreu que simplesmente me deixou estupefato. Eu estava sentado almoçando com alguns colegas, no sol de Redmond, quando Pete Higgins veio até mim. Pete era então o Gerente Geral para o Office -- eu sabia quem ele era, claro, mas não esperava que ele me conhecesse muito bem.

"Como estão as coisas, Joel?" ele perguntou. "Eu soube que você está tendo problemas com o grupo de Arquitetura de Aplicações."

"Ah, não!", eu disse. "Nada que eu não possa tomar conta."

"Não precisa dizer mais nada", ele disse, "Eu entendo." Ele se foi. No dia seguinte o rumor chegou até a mim: o grupo de Arquitetura de Aplicações foi desmembrado. Não só isso, mas cada membro do grupo foi mandado para um departamento diferente na Microsoft, o mais longe possivel um do outro. Eu nunca tive notícia deles de novo.

Eu estava estupefato, obviamente. Na Microsoft, se você é o Program Manager trabalhando na estratégia de macros do Excel, mesmo se você só esteve na empresa por seis meses, não importa - você é o DEUS da estratégia de macros do Excel e ninguém, nem mesmo o empregado número 6, pode atravessar o seu caminho. Ponto Final.

Isso realmente carrega uma mensagem forte. Primeiro, isso faz com que todos sejam muito mais conscientes quanto ao seu trabalho. Eles não podem esconder-se atrás da idéia de que "a gerência aprovou a especificação", já que a gerência realmente não deu uma boa olhada na especificação. Tudo o que a gerência fez foi contratar pessoas inteligentes e dar a elas algo a fazer. Segundo, isso faz com que o ambiente de trabalho seja extremamente agradável. Quem não quer ser o Rei do seu próprio domínio? Software, por sua natureza, é muito fácil de se dividir em componentes menores e menores, então é sempre possível dividir responsabilidades entre pessoas e deixar pessoas serem donas de uma área. Essa é provavelmente a razão pela qual profissionais de software amam trabalhar para a Microsoft.


 

Os anos passaram. Eu me encontrei trabalhando para a Juno, uma empresa de serviços on-line e provedor de email gratuito. Dessa vez, a experiência foi o extremo oposto do meu trabalho na Microsoft. Eu tinha dois programadores sob meu comando, mas meu próprio gerente constantemente pisava na minha (limitada) autoridade indo diretamente aos meus funcionários e dando-lhes coisas para fazer, muitas vezes sem falar nada comigo. Até mesmo para pedidos triviais como dias de férias, meu gerente achava que era o seu dever aprovar ou desaprovar o pedido.

Após dois anos na Juno, eu estava trabalhando na função de ativação de novos usuários. Para o Juno 3.X, uma versão importante, eu estaria encarregado de uma completa reforma do processo de registro e ativação. A essa altura, eu era um membro relativamente sênior da equipe técnica; eu tinha ótimas avaliações de performance, e meus gerentes pareciam apreciar o trabalho que eu estava realizando. Mas eles simplesmente não conseguiam confiar em mim. Comando e controle.

Uma parte do processo de ativação pedia aos usuários para digitar sua data de nascimento. Isso era apenas um pequeno passo de um longo processo de ativação que durava algo como 30 telas enquanto o Juno te espremia sobre sua renda, seus esportes favoritos, quantos filhos você tem e suas idades, e outras mil perguntas. Para tornar o processo um pouquinho mais fácil, eu queria mudar o campo de data de nascimento para um formato livre, de modo que você pudesse digitar "12/8/74", ou "8 de Agosto de 1974", ou "12/Agosto/74" ou seja o que for. (Você já usou o Outlook? O campo funcionaria como o Outlook, onde você pode digitar datas em praticamente qualquer formato e ele as aceita).

Sem entrar em muitos detalhes, meu gerente decidiu que ele não gostava disso. Isso se tornou uma questão de ego para ele. Primeiro ele gritou com o designer que estava trabalhando naquela página (sem ao menos conversar comigo). Então, ele gritou comigo. Então, ele me relembrou todo santo dia que eu tinha que mudar o campo e fazê-lo do jeito que ele queria. Então, ele conseguiu que o CEO da empresa olhasse a questão, e fez um enorme show pelo fato de que conseguiu que o CEO da empresa criticasse meu novo design. Até mesmo o CEO da Juno está perfeitamente feliz em interferir no trabalho feito no mais baixo nível na empresa. De fato, esse é o padrão operante.

Eu fiquei furioso, naturalmente. Era algo pequeno, uma questão de gosto, na verdade. Algumas pessoas preferiam meu jeito. Algumas pessoas preferiam o jeito dele. De qualquer forma, a mensagem era clara: você VAI fazer como mandado aqui, porra. Era uma mentalidade de Command and Conquer [NT: jogo onde você move suas peças como peões] que era mais uma batalha de egos do que uma discussão de interface com o usuário.

Eu nao diria que essa é a razão pela qual eu deixei a Juno, mas ela ilustra a razão pela qual eu deixei a Juno: era a noção de que não importa o quão duro você trabalhe, não importa o quão inteligente você seja, não importa se você é "responsável" por algo ou não, você não tem absolutamente qualquer autoridade sobre a menor das coisas. Nada. Pegue o diabo das suas idéias, educação, cérebro e inteligência, tudo aquilo pelo qual nós estamos te pagando, e enfie... E na Juno havia bastante gerentes, algo como 1/4 de todos os empregados, e então eles tinham bastante oportunidades para meter o dedo em toda e qualquer decisão, e garantir que eles estavam no comando. O contraste com a Microsoft, onde os Vice Presidentes herdaram o Prédio 9, para deixar claro que você tem a autoridade de fazer as coisas, era gritante.

Hanging Tree in Jaffa, Israel

Até certo ponto, o processo de gerenciamento grotescamente inepto da Juno é uma característica dela ser uma empresa de Nova Iorque, e não uma empresa da costa oeste, então estilos modernos de gerência ainda não a atingiram. É também um problema causado pela profunda inexperiência dos gerentes, e isso vem do topo - o CEO, um rapaz de 29 anos que nunca trabalhou fora da D.E. Shaw, que interfere em tudo o que ele pode meter o dedo, incluindo mensagens de erro que aparecem quando as coisas dão errado; o CTO [NT: Chief Technology Officer - o munda chuva em questões tecnológicas] regularmente grita com seus empregados se eles ousam questionar sua sabedoria; eles então descontam nos programadores, que vão para casa e chutam seus cachorros. Compare isso com a Microsoft, onde as coisas são feitas no mais baixo nível, e a maioria dos gerentes age como se sua tarefa mais importante fosse correr pelas salas, movendo os móveis para fora do caminho, de modo que as pessoas possam se concentrar nas suas tarefas.



Esse artigo apareceu originalmente em Inglês com o título Two Stories  

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