De Sênior à Gerente

Na continuação do post De Júnior à Sênior, o Sérgio Taborda vai além da comparação entre analista júnior e sênior e aborda a “evolução” dos analistas sêniores à cargos de gerentes, o texto também leva a reflexão, por isso também está na íntegra logo abaixo.

Se você é desenvolvedor a algum tempo com certeza já se deparou com a questão da promoção de sênior a gerente. Por algumas razões que iremos analisar as pessoas não só aceitam este fato como esperam por ele.

Não é incomum durante uma entrevista perguntar para o candidato a uma vaga de desenvolvedor onde ele se vê daqui a 5 – 10 anos, e a resposta costuma ser “como gerente”. A razão para isso é simples: dinheiro. Historicamente a pessoa na posição de Gerente ganha mais que a pessoa na posição de desenvolvedor, seja qual for a sua classificação ou maturidade. Mas esse, espante-se, não é o único fator. A chamada da sereia do poder é prazerosa.

As empresas acham que promover a pessoa de desenvolvedor sênior para gerente é uma coisa boa. Não é. E as pessoas na sua extrema visão curta só enxergam essa opção.  Não é segredo que todos queremos ganhar mais, então quando a pessoa diz que quer ser gerente o que ele está dizendo, na verdade, é que quer mais dinheiro. Nesse ponto eu desclassifico o candidato já que ele ainda não deixou de ser júnior e já quer ficar mandando nos outros.

Por razões que o tempo conhece as empresas se habituaram a pensar que criar software é difícil e que a probabilidade do projeto de software dar errado é grande. Portanto, os diretores que não querem ver o seu na reta adotam a política de: 1) por um lado criar bodes expiatórios na pessoa do gerente. Se o projeto der errado eles serão culpabilizados e o diretor manterá o seu emprego; 2) é preciso microcontrolar tudo o que os desenvolvedores fazem para que assim não existam imprevistos e não existam atrasos.

O curioso é que são exatamente essas medidas de “contingência” que fazem o projeto atrasar.

O resultado é que em uma hierarquia de um diretor de produção de software é comum existirem vários “gerentes”, os quais tentam microcontrolar a equipe de desenvolvimento. A pessoa no papel de gerente  rapidamente  sacrifica os membros  da equipe para manter um salário um pouco melhor que eles sendo que ele seria incapaz de realizar o mesmo trabalho. A imagem do feitor de escravos me vem à mente.  O pior de tudo nem sequer é isso. O pior de tudo é que, normalmente, a pessoa na posição de gerente não tem capacidade técnica nem política para desempenhar esse papel. Sim, a pessoa foi desenvolvedor sênior 20 anos atrás. Isso não lhe dá conhecimento nenhum sobre como o software é feito hoje.  Não apenas a linguagem e o paradigma utilizado hoje são diferentes, como também as técnicas e ferramentas em volta (uso de repositório de código, por exemplo). Quanto mais cedo a pessoa passou de sênior a gerente mais óbvio é este fato, no limite absurdo de comparar, por exemplo, a plataforma Java com linguagens como Clipper, Delphi ou VisualBasic. Você já reparou como o seu gerente reduz tudo a operações no banco de dados e desconhece o conceito de “Servidor de Aplicação” ou o confunde com “servidor web” ?

Quanto à parte política, a pessoa na posição de gerente não tem qualquer escrúpulo ou vergonha em pedir ao desenvolvedor para trabalhar extra para manter o (famoso) cronograma. Mas  peraí! Não é o gerente que criou o cronograma? Se houver atraso não é responsabilidade dele? Infelizmente no mundo atual não. Nada nunca é responsabilidade do gerente e ele faz de tudo para que assim não seja. O clássico é pedir que os desenvolvedores estimem o cronograma. Ele pede que “estimem” mas o que ele quer dizer é “assinem com sangue um chute de quanto tempo vai ser necessário”. Depois o gerente faz a seguinte conta: se a “estimativa” é X então como temos N desenvolvedores vai demorar X/N tempo. A estimativa … quer dizer, a corda no pescoço da equipe de escra… desenvolvedores ficou ainda mais apertada. Nestas condições totalmente indecentes a equipa tem zero motivação , zero ajuda, zero autoridade, total responsabilidade e lá para quando faltarem dois meses para o final do prazo do cronograma fajuto a equipa ainda passa a ser chicoteada diariamente com a pergunta “Quantos porcento falta para estar pronto?”. O que revela que a pessoa no lugar de gerente não sabe o estado das coisas, ou seja, ela esteve fazendo o quê enquanto os desenvolvedores criavam o software? Esperar-se-ia que estivesse exatamente calculando quanto tempo falta. Certo ?

O diretor (a pessoa hierarquicamente acima do gerente e que o contratou como bode expiatório profissional) não se preocupa com a performance do gerente. Apenas com a da equipe. Afinal todos os males advém da equipe de desenvolvedores. Esses seres abjetos que o diretor é obrigado a tolerar para poder vender alguma coisa a alguém. Ao diretor tanto lhe faz se o gerente explora os desenvolvedores da mesma forma que o senhor lhe importa um pepino que o feitor chicoteie os seus escravos. Não só isso, como o diretor espera que o gerente aja assim.  Tanto isso é verdade que em empresas maiores (leia-se “com mais níveis de isolamento dos seres abjetos da equipe”) existem uma camada de gerentes. O diretor delega para N gerentes, cada um deles delega para M outros gerentes, que delegam a outros … em um cadeia até que se chega no gerente que controla a equipe. Vejam bem o estado da coisa. O gerente não serve para gerenciar o projeto. Não. Isso é fácil, qualquer excel ou project pode fazer isso. O gerente serve para controlar a equipe em uma mistura de babysiter com capataz e a empresa é tanto maior quanto mais gerentes forem controlados por outros gerentes.

Parece então óbvio porque um desenvolvedor quer virar gerente: 1) mais dinheiro no fim do mês; 2) menor ou nenhuma responsabilidade sobre o projeto ou o software; 3) direitos de fustigar a equipe como e quanto quiser; 4) receber todos os louros dos superiores quando o projeto dá certo; e 5) nunca ser “castigado” por nada.

Parece muito melhor que a vida de um desenvolvedor que 1) ganha pouco para aquilo que faz e a responsabilidade que tem; 2) tem toda a responsabilidade sobre o resultado mas nenhum autoridade para guiar o processo; 3) é interrompido a todo o momento com perguntas idiotas que não são da sua responsabilidade responder como “Quantos porcento do projeto já está completo?” 4) nunca recebe o agradecimento real de ninguém nem o reconhecimento real do esforço (eu disse real e não aquele tapinha nas costas ou aquele e-mail de agradecimento modelo B) e 5) é sempre “castigado” por tudo no limite de ser despedido por justa causa por erros cometidos pelo gerente, pelo diretor ou até pelo erro estratégico da empresa como um todo.

Se você teve estômago para ler até aqui, parabéns. Vejamos agora um pouco do outro lado. Afinal, nem todo o mundo é mentecapto e alguma pessoas querem realmente ganhar dinheiro a sério e não apenas para pagar as contas. Qualquer economista, por muito ruim que seja, sabe que uma forma de ganhar mais é gastar menos. É fácil gastar menos com desenvolvimento de software.

Primeiro, foque no que dá dinheiro. No caso do software o que dá dinheiro é o software, funcional e entregue. Muito importante o entregue.

Segundo, desenvolvedores são pessoas com educação superior e qualificadas a resolver problemas lógicos e matemáticos complexos. Não os trate como animais de curral. Converse com eles e ouça o que eles dizem. Melhor que ninguém eles sabem quais são os problemas com o software. E ninguém melhor que ele sabe como traduzir o que é esperado pelo mercado em código. Eles podem ajudá-lo não apenas a resolver problemas técnicos mas até problemas que impactaram na venda do software ou na aceitação pelo público. O seu foco é fazer software, então dê recursos aos desenvolvedores para o fazerem. O foco da empresa é o software e todos devem ajudar a conseguir que ele seja feito nas melhores condições de mercado possíveis.  Simplifique os processos. Coloque no lixo a hierarquia militar de passar ordens entre níveis.  Muita informação se perde dessa forma quando o assunto é complexo como um software. Pode até funcionar para a guerra onde as ordens são simples, mas não numa empresa de software.  Uma muito boa forma de conseguir isto com facilidade, sem gastar dinheiro e com um retorno imediato é substituir todos os que se dizem gerentes por desenvolvedores sênior (realmente sênior e não apenas júniors disfarçados). Implementar Scrum também não é má ideia, mas se você tem um outro processo que realmente funciona para a sua empresa (eu disse, realmente – o que significa que todo o mundo na empresa acha que funciona) então mantenha esse.

Implemente um mecanismo de carreira. Não separe os desenvolvedores por anos de trabalho  e sim preveja que todos têm mais do que uma habilidade. Não é demérito para ninguém só saber programar bem. Saber escrever código limpo, bem estruturado, que aproveita ao máximo as funcionalidades da linguagem não é pecado. Nem todos têm  de ser arquitetos. Não é demérito para ninguém ser um bom tester que sabe escrever testes automáticos com boa cobertura.

A vida de um desenvolvedor têm várias partes e não são: júnior , sênior, gerente. São: programador, engenheiro,  tester, designer, analista e arquiteto. E isto não é uma sequência. Cada um pode ser mais do que uma coisa. Aliás tem que ser mais do que uma. Existe o básico que é ser programador (saber programar não é suficiente) e existe o complexo: analise é uma tarefa ao mesmo tempo técnica, interpessoal e até política onde poucos engenheiros e arquitetos se sentem bem. Moral da história, monte uma equipe multidisciplinar sem gerentes fustigadores mas com pessoas que ajudem a resolver os problemas políticos, burocráticos e administrativos e deixe o desenvolvimento com quem entende.

A próxima década não terá pena de quem não se ajustar à nova ordem. Quem ainda quiser ficar fuçando no código como se fazia à 20 ou 30 anos atrás não vai chegar a lado nenhum diferente da falência. A concorrência é maior que nunca e o mercado de tecnologia é maior do que nunca. Quem não primar pela qualidade não vai vingar.

A escravatura das fábricas de software tem que acabar. O primeiro passo é que você, desenvolvedor,  não aceite esses termos.  Aspire a ter capacidades de análise, conhecimento de arquitetura, design ou teste, e não a ser um gerente mentecapto e escravocrata.  Afinal, você gostaria que pensassem de si o que você pensa do seu gerente?