Por que os gerentes teimam em se meterem no desenvolvimento ?

Isso é uma pergunta acho que freqüente que vários desenvolvedores fazem.

Por que ? O que motiva um gerente de projetos a se meter a nível de código e soluções no projeto ?

Antes de continuar vamos entender para que “serve” um gerente de projetos, vejamos o seguinte trecho abaixo retirado do Wiki:

Um gerente de projetos é um profissional no campo de gerência de projetos que tem a responsabilidade de planejar e controlar a execução de projetos em diversas áreas de atuação, como a construção civil, arquitetura e desenvolvimento de software, entre outras áreas. É o profissional responsável pela condução do projeto e deve contar com o respaldo de patrocinadores (sponsors, segundo a nomenclatura PMI), normalmente indivíduos que estejam fora do projeto a ser executado.

E ainda temos:

O gerente e sua equipe de projetos planejam e coordenam o desenvolvimento do projeto colhendo métricas, suprindo necessidades, recrutando recursos adequados e mantendo o foco na meta de projeto, além de:

O Milfont fez um post relacionado a esse assunto e o Akita tem um semelhante.

Entendendo o papel de um gerente.

Um gerente é um profissional responsável em lidar com pessoas, ele será a ponte entre a equipe e a diretoria.

Computador lento, cadeira quebrada, prazo do projeto, manter a motivação da equipe, ajudar individualmente cada membro da equipe com qualquer problema que atinja de uma certa forma o projeto, conflitos internos etc, essas são algumas de suas atividades e responsabilidades

Agora eu pergunto novamente.

Por que alguns gerentes teimam em se meter nos projetos a nível técnico ? Ou melhor, por que é “prejudicial” para a equipe o gerente fazer isso ?

Bem, nos já sabemos quais as responsabilidades de um gerente, mas sabemos também que existem gerentes que um dia já foram desenvolvedores e normalmente esses gerentes não sabem mais programar na maioria dos casos.

O gerente não precisa saber informações técnicas, a única preocupação dele é com o projeto como um todo, data de entrega, motivação da equipe etc. E não qual framework a equipe irá utilizar ou o código do desenvolvedor, isso diga-se de passagem, é responsabilidade do líder do projeto, normalmente conhecido por: Líder técnico.

O problema

Quando um gerente tenta se meter na solução proposta de um desenvolvedor eu só vejo um único motivo justo para isso: “O gerente tem a preocupação de que essa solução possa atrasar o projeto ou prejudicar o desenvolvimento do projeto por algum motivo.”

Mas infelizmente não é por isso. O gerente está fazendo porque ele não confia na equipe dele, simples. Isso pode causar um mal estar na equipe e principalmente desmotivação.

Outro problema é quando o gerente se mete a nível de código.

Eu acho que cada um tem um papel dentro da equipe em um projeto e com certeza codificar, escolher soluções, não é um atributo que o gerente deveria se meter. Quem deve decidir isso é a equipe, onde baseado nos conhecimentos dos integrantes eles trilharam o melhor caminho para o desenvolvimento.

Lembro de certa vez que quis utilizar um determinado framework em um projeto. O problema não foi tanto a escolha do framework e sim da maneira que ele estava implementado por mim, pois fiz de uma maneira não muito convencional ao “padrão” deste framework, mas que, comparado ao tradicional dava MUITO mais produtividade e funcionaria da mesma forma.

Foi quando o gerente não quis aceitar essa implementação, alegando que o cliente poderia achar ruim(O_o) e que não era o “padrão de mercado”.

Primeiro pronto: Quem é o desenvolvedor ? Quem vai trabalhar dia a dia no projeto ? Com certeza não será ele, normalmente um gerente não gerencia apenas um único projeto. Então porque ele tinha que se meter na implementação ou solução tecnológica do projeto ?

Segundo ponto: Todos os dias tentamos de várias formas sermos mais produtivos e criar soluções para cada tipo de projeto, onde cada um resolve um problema específico onde irá agregar mais valor ao projeto, então o que é esse “padrão de mercado” ? Por que sou obrigado a ficar preso nele ?

Pra mim isso é medo de mudanças e não confiar na equipe, lembram do:  “estar sempre alerta, mas não avesso a mudanças” ?

Pois é, quando o gerente se mete onde não é da sua alçada acaba acontecendo esse tipo de problema.

O projeto foi entregue em dia (4 dias antes para ser mais exato), mas COM CERTEZA não foi por mérito do gerente, e sim da EQUIPE. Equipe essa que as vezes ignorava muita coisa que o gerente falava, mas não o suficiente. Esse projeto poderia ter sido entregue até bem antes do prazo se o mesmo não tivesse se metido nas soluções e códigos da equipe.

Outro exemplo é quando temos em um projeto um determinado problema e como todo bom desenvolvedor iremos pesquisar a melhor solução para aquele problema. É ai onde o gerente metido a desenvolvedor se mete mais uma vez, não deixando que o desenvolvedor aplique aquela solução.

Isso é totalmente prejudicial, isso além de desmotivar o desenvolvedor acaba de uma certa forma “atrofiando” o mesmo, pois ele não se sente apto a aplicar alguma solução, pois o mesmo sempre é barrado pelo gerente.

Ele deve confiar na equipe dele e não desconfiar da capacidade dela, ele deve instigar a equipe a ser mais dinâmica e ser de uma certa forma auto gerenciável.

Motivos

Medo de mudanças, saudades do tempo de programador, falta de confiança na equipe ?

Bem, não sei ao certo, mas com certeza na maioria dos casos é a plena falta de confiança na equipe.

Se o gerente não confiar na equipe dele, ele se acha no direito de saber de TUDO que está acontecendo no projeto para se poupar de eventuais problemas futuros ou atrasos.

Outro ponto é a vontade de ter o poder, de sentir que está no controle e que todos dependem dele para executar alguma tarefa.

Gerente não é desenvolvedor

O gerente tem que ter em mente que ele não é mais desenvolvedor, ele está em outra área agora, isso não lhe pertence mais.

Nada de tentar decidir qual melhor framework para o projeto, nada de tentar saber com detalhes a nível de código porque aquela funcionalidade não está pronta ou fazer com que o desenvolvedor explique com detalhes os problemas técnicos na reunião diária.

Ai você pode falar: “Mas se deixarmos cada desenvolvedor colocar todas as possíveis soluções no projeto, ele pode ser sim prejudicado e o seu desenvolvimento e manutenção sofreram sérios problemas”.

Sim isso é uma verdade, mas o problema ainda não é do gerente, é da equipe.

Se a equipe não é uma equipe madura, nem o melhor gerente do planeta irá resolver esse problema e o projeto cairá em desastre com ou sem a sua intromissão.

A equipe deve se comunicar bastante e conversar sobre qualquer nova implementação ou solução, devem discutir e nesse ponto o gerente não precisa entrar ou muito menos se meter no sentido de decidir algo, ele pode sim dar alguns palpites baseado em sua experiência, mas NUNCA decidir alguma coisa, isso fica para a EQUIPE.

As pessoas custam a entender que os membros MAIS IMPORTANTES dentro de um projeto não são os Analistas e definitivamente não é o gerente, são os  DESENVOLVEDORES.

São eles que farão a funcionalidade que o cliente tanto quer, são eles que iram procurar e implementar a melhor solução para aquele problema, onde a solução irá prover qualidade e produtividade no desenvolvimento.

Não tem na prática como o gerente saber o que é ou não é mais produtivo pelo simples fato de que: ELE NÃO ESTÁ NO DIA A DIA DO DESENVOLVIMENTO.

Para ser um gerente não necessariamente ele precisa ser o técnico mais experiente ou conhecer a tecnologia que o projeto irá utilizar, basta que ele cumpra com suas responsabilidades de gestão e que não interfira no processo de desenvolvimento do software.

O profissional tem que decidir se ele quer entrar na área de gestão ou continuar na área técnica, fazer as duas juntas NUNCA vai funcionar.

Conseqüências

Nas metodologias ágeis o cliente tem como comunicador o desenvolvedor e não o gerente, o gerente não irá decidir ou ao menos saber qual tecnologia ou solução foi escolhida para aquele problema.

Quando o gerente começa a se meter nestes casos que citei é gerado um clima chato e desagradável na equipe com a presença deste gerente.

Ele acaba passando uma imagem negativa para a equipe, como uma pessoa autoritária, intrometida e que “pega no pé” mais do que deveria.

A equipe para de respeitá-lo, para de vê-lo como facilitador do seu trabalho e começa a ver ele como “peso” no projeto, a equipe fica totalmente desmotivada e no fim, quem será prejudicado é o projeto e depois os desenvolvedores que como sempre, levam a culpa.

Então você está me dizendo que não precisamos de um gerente no projeto ?

Não, definitivamente não. Estou dizendo que NÃO PRECISAMOS DE UM GERENTE QUE SE META NA ÁREA TÉCNICA EM GERAL.

Precisamos sim de um gerente, um gerente que se abstraia ao máximo da área técnica e que torne viável e possível um bom ambiente de desenvolvimento para a equipe.

Conclusão

O gerente tem um papel muito importante no início de projeto. Com as conversas iniciais com o cliente, prover treinamento para a equipe, resolver conflitos, entender porque o membro faltou e tentar gerenciar isso da melhor forma para não prejudicar o projeto e nem desmotivar o membro, manter a equipe motivada e focada no projeto, agendar reuniões, facilitar a vida do desenvolvedor para que o mesmo fique bem motivado e com isso faça um excelente trabalho no projeto.

Um bom gerente irá lhe dar um suporte necessário para que você tenha “liberdade” dentro do projeto e um bom ambiente e infra estrutura de trabalho.

No final temos um sucesso: projeto entregue, cliente feliz, desenvolvedor motivado  e um gerente respeitado.

Então se você é um gerente não tenha ódio por mim, acredite estou fazendo um bem para você, não se meta no desenvolvimento deixe isso para a sua equipe, já pensou se um técnico de futebol (odeio futebol 😛 ) não confiasse no seu time ?

Pense nisso e seja um GERENTE e não um PESO.

Abraços

38 Comments on “Por que os gerentes teimam em se meterem no desenvolvimento ?

  1. Isso acontece não apenas na área de TI, em tudo que envolve projetos hoje em dia sempre tem um gerente que quer “se meter”, em todos os níveis do projeto, eu anteriormente trabalhava com automação industrial e sempre em outras equipes de desenvolvimento havia esta insatisfação por conta da falta de confiança do gerente.

  2. Um gerente pode ficar bem mais confortável quando há um líder técnico ou um desenvolvedor mais senior ajudando a orientar e direcionar a equipe e, por que não, manter a sua motivação. Usando a sua analogia com o futebol, todo bom time também tem um bom capitão.

    Na ausência desse profissional, por mais bem intencionada que esteja a equipe, não há como deixar todas as decisões técnicas sob responsabilidade apenas dela. Democracia não funciona no desenvolvimento de software como “funciona” em outros tipos de equipe.

    Tive excelentes líderes técnicos que permitiram que meus gerentes ficassem tranquilos, mas também trabalhei em equipes em que cada desenvolvedor queria “atirar numa direção diferente” e o projeto ficou com enormes pecados em termos de desempenho. No primeiro caso, a interferência técnica de um gerente teria sido tão maléfica quanto o que você descreve, mas, poderia ter sido bastante bem-vinda (ou bem vinda, sei lá) no segundo.

  3. Olá Daniel.
    “Um gerente pode ficar bem mais confortável quando há um líder técnico ou um desenvolvedor mais senior ajudando a orientar e direcionar a equipe e, por que não, manter a sua motivação. Usando a sua analogia com o futebol, todo bom time também tem um bom capitão.”

    Exato, falo isso no parágrafo que cito sobre ter um time maduro, seja toda a equipe ou ter um líder técnico. Mas mesmo tendo um líder técnico se a equipe for ruim, nada ele vai poder fazer. O que adianta ter um time com um excelente técnico, ótimo capitão, se os jogadores são pernas de pau ?

    Entendeu o ponto ?

    “Na ausência desse profissional, por mais bem intencionada que esteja a equipe, não há como deixar todas as decisões técnicas sob responsabilidade apenas dela. Democracia não funciona no desenvolvimento de software como “funciona” em outros tipos de equipe.”

    Isso não é democracia, é puro bom senso. Como disse, se a equipe não tem maturidade, não tem gerente que faça o projeto dar certo.
    As decisões devem sim ao meu ver serem de responsabilidade da equipe, e não do gerente.

    Ele não está no dia a dia do desenvolvimento, ele em muitos casos não conhece o fluxo de desenvolvimento que a equipe trabalha, por isso não concordo com esse ponto que você citou.

    Trabalhei com grandes equipes, que com conversas entre si definiam o melhor caminho. Quando temos um time pensando junto é bem melhor do que somente uma única pessoa tomando decisões, sem falar que isso ainda de maneira implícita “força” a EQUIPE assumir as conseqüências/erros que possam vir. Fazendo com o que a equipe fique mais unida e focada no sucesso do projeto.

    “Tive excelentes líderes técnicos que permitiram que meus gerentes ficassem tranquilos, mas também trabalhei em equipes em que cada desenvolvedor queria “atirar numa direção diferente” e o projeto ficou com enormes pecados em termos de desempenho. No primeiro caso, a interferência técnica de um gerente teria sido tão maléfica quanto o que você descreve, mas, poderia ter sido bastante bem-vinda (ou bem vinda, sei lá) no segundo.”

    Exato, mais uma vez o problema não é o gerente, é a equipe. Equipe que não tem foco ou maturidade não adianta ter líder de projeto e excelente gerente.

    Não sei se você comentou e colocou a ordem ao inversa, mas quando você fala que “líderes técnicos que permitiram que meus gerentes ficassem tranquilos,”.
    Acho que é ao contrário, esse é o trabalho do gerente, manter a equipe tranquila e ajudar no que for preciso para que a equipe possa fazer um excelente trabalho.

    Você concorda comigo que um gerente não precisa conhecer a tecnologia do projeto que ele está gerenciando ?

    O papel do gerente é claro, é apenas gerenciar os “recursos”, é trabalho de gestão e não técnico.

    Por isso muitos confundem, acham que existe um escadinha de plano de carreira, o cara é estagiário, desenvolvedor, analista e no fim ele vira gerente.
    Isso está errado, gerencia não tem nada a ver com desenvolvimento em si, é muito complicado e eu NUNCA vi um gerente ser técnico ao mesmo tempo e isso dar certo.

    Existem excelentes técnicos que são péssimos gerentes, e vice versa.

    Ele pode sim, caso ele conheça a tecnologia, dar seus palpites e algumas dicas baseado na sua experiência, mas NUNCA decidir por imposição algo técnico no projeto, isso é sim de responsabilidade da equipe.

    Abraços e obrigado pelo seu comentário.

  4. Concordo bastante com seu último parágrafo.

    “Ele pode sim, caso ele conheça a tecnologia, dar seus palpites e algumas dicas baseado na sua experiência, mas NUNCA decidir por imposição algo técnico no projeto, isso é sim de responsabilidade da equipe.”

    É que no primeiro post, parecia ser um absurdo que o gerente “desse seus palpites e dicas”. Acho que nem sempre isso ocorre.

    Infelizmente, em muitas empresas existe mesmo a “escadinha” que você citou, inclusive empresas grandes e boas. E isso se reflete no orgão mais doído do ser-humano, o bolso. E quando começam a chegar as crianças, quem não quer ter um orçamento familiar maior?

    Espero ainda poder dar bons palpites e dicas quando estiver no degrau de gerência.

    Abraços.

  5. “É que no primeiro post, parecia ser um absurdo que o gerente “desse seus palpites e dicas”. Acho que nem sempre isso ocorre.”

    Isso, mas eu tinha comentando sobre isso rsrsr, mas blz que você entendeu. O problema não são os palpites e compartilhamento de experiência e sim quando ele quer impor determinadas coisas.

    “nfelizmente, em muitas empresas existe mesmo a “escadinha” que você citou, inclusive empresas grandes e boas. E isso se reflete no orgão mais doído do ser-humano, o bolso. E quando começam a chegar as crianças, quem não quer ter um orçamento familiar maior?”

    Mas você acha que não tem desenvolvedor ganhando o mesmo ou mais que um gerente ? Acredite, isso é possível sim e já é uma realidade, até para o Brasil, estamos aos poucos mudando isso, mas já está mudando.

    Abraços

  6. Handerson,

    Sei que vc é um especialista em DWR e o jeito mais rápido de falar contigo era por aqui..

    Já li vários artigos seus e me motivei a usar DWR principalmente por causa deles! PARABENS!

    Agora, tenho duas perguntas. Será q vc teria um tempinho pra responder? são fáceis..

    A primeira é:

    Vc já teve problema com o reverseAjax, utilizando Browser.withSession ?? Pq ao inves dele mandar para uma session especifica, ele manda para todas que estão naquela pagina. Inclusive até achei um bugreport(http://bugs.directwebremoting.org/bugs/browse/DWR-329)
    Mas vc sabe de algo a respeito?

    A segunda é

    sobre o dwr.util.addRows(), vi em vários artigos seus exemplos e tudo mais.. mas eu queria imprimir a lista de uma forma que eu não to conseguindo achar uma maneira..

    a idéia é, eu vou passar uma lista para o addRows, que tem atributos, inclusive um deles, é uma outra lista.. dae eu queria imprimir mais ou menos assim
    exemplo – imprimir uma lista de entidades e atributos de um modelo relacional de dados.

    então eu teria:

    ENTIDADE A – NOME LOGICO – NOME FISICO
    ATRIBUTO 1
    ATRIBUTO 2
    ATRIBUTO 3
    ATRIBUTO 4

    ENTIDADE B – NOME LOGICO – NOME FISICO
    ATRIBUTO 1
    ATRIBUTO 2

    ENTIDADE C – NOME LOGICO – NOME FISICO
    ATRIBUTO 1

    entao? como eu poderia fazer isso?

    pq qndo eu passo uma var de funções (cellFuncs) como parametro do addRows, para cada funcao ele faz um

    saberia me ajudar?

    desde ja!

    abraçao!

    valw

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

*

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.