Avançar para o conteúdo principal

Carreiras

Conhecem decerto o site ActiveTechPros, onde podemos constatar a miséria que os nossos patrões nos pagam, e comparar com a miséria que outros ganham por esse mundo fora.

Só pra chatear aqui ficam os números de alguns países. Quem diria que aqui na Doce e Verde Irlanda se ganha mais do que na Velha Albion! Era como se em Portugal se ganhasse mais do que em Espanha...

Média em k€ para System Developers

Portugal: 21 (334)
Espanha: 31 (256)
Irlanda: 49 (146)
UK: 48 (1235)
USA: 56 (244)

idem, para Project Managers

Portugal: 36 (185)
Espanha: 46 (250)
Irlanda: 65 (46)
UK: 63 (461)
USA: 66 (100)

Da mesma fonte surgiu agora um relatório - Portugal IT Salary & Skills Snapshot 2008 - que revela números semelhantes - 24k para System Developers, 39k para Project Managers, num universo de 399 respondentes de entre os quais 152 pessoas são PM's e 115 trabalham. :)

Agora, eu nao tenho nada contra essa tão nobre classe profissional, se bem que, tal como na estória do "C-Monkey", eu nunca os tenha visto a fazer nada, ou como dizia o outro, "eles falam falam falam falam falam falam falam, mas eu nunca os vi a fazer nada!!!"

Mas agora a sério, eu sei por experiência própria que PM é um trabalho chato, burocrático, "pesado", e eu não o faria nem que me pagassem 39k (ou 65k no meu caso), mas o que acho é que em Portugal são muito poucos os Project Managers que o são por "vocação", que têm "paixão", que são capazes de ficar até às tantas da manhã a fazer, bem, não sei ao certo, aquilo que os PM's fazem...

Pelo contrário, conheço muitos, muitíssimos programadores que possuem essa "chama" que os fazem trabalhar horas a fio, as mais das vezes mal pagos, às vezes a resolver coisas "impossíveis" (que por acaso é o que mais gozo dá) e que se calhar chegam a casa e ainda vão para o computador ver as últimas.

Acho que infelizmente quem vai para PM são pessoas que passam pela programação e, devido à falta dessa paixão, e não quero ser injusto dizendo de capacidade, optam por seguir a via mais fácil e que ainda por cima é (será?) em média mais bem remunerada, e em vez de se andarem a chatear com a chatice da programação, passam a chatear... os programadores!

Porque, ao fim ao cabo, o PM quer mensurar o imensurável, quer meter o Rossio na Rua da Betesga, quer saber o que o principio da incerteza do projecto não permite saber. Quer-nos fazer crer que "não devemos reinventar a roda" - como se os F1 usassem rodas de carroça - quando reinventar a roda é a mais das vezes útil - torna-nos melhores programadores enquanto indivíduos e é a melhor forma de obtermos vantagem concorrencial sobre os nossos competidores enquanto empresas.

Notem que não quero generalizar, até porque em geral é perigoso generalizar, e estou certo que existem muitos e bons profissionais nessa área. Mas ninguém me tira da ideia de que PM's são um dos "males necessários" da Ciência da Informação, tal como, entre outros, os utilizadores e os computadores...

Com tudo isto, pretendo dizer que uma "carreira" como programador é o caminho a seguir por quem "gosta" disto, é uma parvoice tentar seguir o caminho do "management" só porque isso é visto como uma "subida" na carreira, porque o Project Manager ganha mais dinheiro, porque o programador nos tempos que correm é visto já como uma entidade "inferior", ninguem se chama hoje a si próprio "programador" mas "software engineer", "systems architect", "solutions designer" (ou qualquer destas designações em diferentes combinações), toda a gente é sénior com um ano de experiência, e até já existem "consultores juniores", o que me parece a mim uma contradição nos termos.

Pera lá, mas o "ganha mais dinheiro" faz jeito, ou nao? É uma falsa questão. Ninguém ganha mais dinheiro porque "é" isto ou "é" aquilo. Ganha-se mais dinheiro porque se é bom a fazer as coisas que se fazem. Porque o nosso trabalho pode fazer a diferença, especialmente num mercado tão competitivo como IT.

E acreditem, no final é o programador que faz a diferença, não o gestor de projectos...



Comentários

  1. Estás tão enganado, Mota!

    Sim. Era bom que as tarefas dos projectos fossem exclusivamente programação. Que delícia, passar o dia todo a ensinar o computador a fazer malabarismos para sacar o "UAU!". :-)

    Só que... os projectos envolvem clientes e, geralmente, mais do que um programador egocêntrico. Para cúmulo, o projecto tem objectivos, e tem um orçamento (que raio... o cliente faz questão de não pagar mais do que lhe foi prometido que o projecto custaria). ;-)

    Que chatice. Os projectos não precisam só de programação. Precisam de Engenharia!

    E a Engenharia, Mota, não se limita a ser uma disciplina tecnológica. Significa gerir contratos, pessoas, expectativas, para além do obrigatório domínio da tecnologia. E como a maior parte dos programadores têm graves lacunas nestas competências, é preciso arranjar quem seja capaz e tenha disponibilidade mental para fazer este tipo de tarefas.

    Essa piada de que os gestores de projecto não fazem nada está gasta e perpetua um preconceito que mais do que inútil é prejudicial. As equipas de sucesso são multidisciplinares.

    Quanto ao dinheiro que ganha um PM ser geralmente mais do que um programador, a resposta é simples. Passa-se o mesmo com os vendedores. É a lei da oferta e da procura. Havendo mais gente com competências de PM, o preço baixa.

    Tu, que me conheces, sabes o valor que dou à capacidade técnica. Mas denegrir as outras profissões para destacar a tua não é o caminho certo. O que é preciso é que todos reconheçamos o papel fundamental de cada um e que valorizemos as competências necessárias que os outros trazem às equipas.

    ResponderEliminar
  2. Bem, eu não quis estar a "destacar a minha" nem a "denegrir a dos outros", até porque no fundo quer a "minha" quer a "dos outros" serve para a mesma coisa, a "satisfação" dos "clientes"...

    E eu próprio afirmei, em concordância com o que agora dizes, que o trabalho de um PM é necessário - um mal necessário, disse eu.

    O problema é que, para juntar o insulto à injúria, os PM são, como tu dizes, pessoas que "gerem contratos, pessoas, expectativas" (a propósito, pensava que isso era do domínio da Política Empresarial, ou quando muito de PR, não da Engenharia), mas que infelizmente as mais das vezes fazem-no mas às avessas.

    Ele não analisa as necessidades reais do desenvolvimento e apresenta prazos e valores consoante essa análise. Ele tenta "descobrir" quanto é que o cliente está disposto a pagar e quanto tempo está disposto a esperar pelo resultado. E tenta "descobrir" quanto é que os seus concorrentes directos estão dispostos a apresentar. Não tem nada a ver com a tecnologia mas sim com o mercado.

    E isso está certo, dado que temos que vivemos no mercado. Mas não se pode é depois assacar responsabilidades por não cumprimento de prazos e orçamentos a quem não os fez, e nem sequer foi ouvido na sua elaboração.

    Numa das empresas em que trabalhei, e uma das mais profissionais, tivemos uma reunião para estabelecer prazos para os vário módulos de uma aplicação. A aplicação no seu tudo já estava negociada, incluindo prazos e valores. Acredito que as pessoas quem fizeram o orçamento eram pessoas qualificadas para o fazer, dado que aquela companhia tem uma reputação acima de qualquer suspeita. Quando chegou a minha vez o PM perguntou-me quanto tempo é que eu achava que o módulo X demoraria a desenvolver. Eu do melhor que consegui analisar disse 3 semanas. O PM olhou para o seus papeis e disse "3 semanas? Porquê 3 semanas? Eu tinha previsto 1 semana para essa tarefa..." Ao que eu respondi "se tens isso nos teus papeis e já previste esses prazos, para que estás então a perguntar a nós, que "apenas" temos que que passar as coisas do papel para a realidade?"

    Está claro que o prazo que ficou foi de uma semana, e eu fiquei porreiro com isso. Eu acredito que o cliente tem sempre razão mesmo que a não tenha, e que se pra se ganhar um contrato é preciso fazer numa semana o que demora três, eu sou todo a favor. Afinal é de aí que nos vem o vil metal/plástico.

    Eu de vez em quando vou para o fogão ("le pianno" como nós lhe chamamos :) e preparo umas omeletes. Sei preparar uma omelete em 5 minutos, mas normalmente demoro 20. Agora, se o cliente quer a omelete em 5 minutos, depois não se venha queixar a mim porque o exterior está tostado o interior cru. Se o cliente se quer queixar, vá-se queixar ao gajo do balcão que disse que a omelete de 5 minutos era tão boa como a de 20 e que era eu que tinha a mania que era "un Chef". Aí se esse meu estimável colega me vier depois chatear, eu digo-lhe o que fazer com a omelete de 5 minutos...

    O que eu quis afirmar - e creio que o fiz claramente - é que passar do desenvolvimento para "management" não é uma subida na carreira, nem uma promoção social, e nem sequer uma garantia de melhor remuneração como infelizmente muitas vezes isso é pintado. E acho que é uma perda (com "m") que se percam bons programadores para se ganharem maus gestores de projecto, só por que isso é mais "fashionable".

    Eu falo por experiência, já geri projectos, já geri equipas, já geri clientes, já geri contratos. Só o meu dinheiro é que é mais difícil de gerir... Não devo andar longe da verdade se disser que praí 80% dos projectos que falham, falham devido a erros do "management" ao criar expectativas irrealistas nos clientes. E dos restantes 20%, praí 80% são bem sucedidos apesar dos erros do "management" ao criar expectativas irrealistas nos clientes. Graças à dedicação, esforço e paixão dos programadores, que normalmente não é reconhecida e muito menos recompensada. Como diz aqui o meu chefe, nesta área existem dois tipos de profissionais. Programadores, e Programadores com responsabilidades políticas. Tudo o resto é "paisagem", pra "inglês ver"...

    E atenção que não está no meu feitio andar a "destacar a minha" e a "denegrir a dos outros", nem necessito disso porque tive a sorte e a possibilidade de estar onde escolhi e a fazer o que gosto. E a ser relativamente bem pago por isso. E nem gosto de destaques porque também sei por experiência própria que é verdade que "quando estou bêbedo todos me apontam, quando tenho sede ninguém me vê".

    O que eu creio é que é tempo de devolver ao "programador" a dignidade profissional que parece ter perdido para os "software designers", os "system engineers", os "solution architects" - que na realidade não são mais (ou não deveriam ser) do que programadores a desempenhar cargos ligeiramente diferentes. E nem para os Project Managers, os Program Manager, os Team Managers, os Quality Managers. Todos estes títulos pomposos deviam ser usados para designar cargos (roles), não devem ser postos como na tropa.

    Não vejo como é que posso estar "tão enganado" nisto...

    ResponderEliminar
  3. Se queres devolver a dignidade ao programador, estou contigo.

    Mas não querias generalizar e generalizaste. Não querias denegrir e entraste no bota-abaixo.

    Decide-te pá. :-)

    ResponderEliminar
  4. A dignidade e os salários altos, pá...

    ResponderEliminar
  5. === Caso 1 ===

    Existem Project Managers fantásticos em Portugal. Tenho a sorte de ter um por perto e de todos os PMs com que trabalho actualmente terem um bom nível de entendimento do que é o trabalho técnico.

    Os PMs com quem tenho trabalhado compreendem as características do trabalho técnico, tentam ajudar-nos a encontrar soluções, tentam remover obstáculos e proteger o nosso trabalho.

    ...o que não quer dizer que não nos lixem o juízo com a pressão dos prazos quando é preciso.


    No entanto não vejo que, em Portugal, seja dado o devido valor aos dois melhores PMs que eu conheço (um que trabalha comigo e outro que não)


    === Caso 2 ===

    Por outro lado também me aconteceu ter trabalhado, há uns anos largos atrás, para uma grande consultora num projecto importante para uma das nossas telecoms, e ver ser dada carta branca ao PM mais incompetente que já encontrei na vida.

    A equipe técnica era de excelente nível mas o PM descoordenava o projecto em vez de o coordenar. Descoordenava no sentido mais esquizofrénico do termo (a mão esquerda não saber o que faz a mão direita...). Em vez de os vários módulos estarem a ser orientados para encaixarem como peças de Lego, pareciam estar a ser construídos para se destruírem mutuamente (estilo robot war?).

    A coisa chegou ao ponto de o DBA do projecto tomar a iniciativa de validar o impacto de cada alteração que lhe era pedida para tentar evitar destruir o trabalho de parte da equipe.

    Eu próprio tive algumas semanas (3 ou 4) a trabalhar num módulo cujas tabelas já estavam obsoletas quando iniciei o meu trabalho.

    Basicamente, esse senhor nem deixava trabalhar a excelente equipe que tenha e destruiu todas as possibilidades de sucesso do projecto.

    Quando se tornou evidente que o projecto se estava cada vez mais a afastar de qualquer possibilidade de sucesso, veio finalmente um administrador da empresa ... pregar um sermão à equipe técnica (que andava a trabalhar muitas horas extra não pagas e dava honestamente o seu melhor "against all odds").

    Ficou claro que o Senhor Administrador não tinha dúvidas nenhumas de que o problema era da falta de boa vontade dos técnicos - e talvez até considerasse os sucessivos pedidos de transferência e as queixas que alguns deles chegaram a fazer como sintomas dessa má vontade.


    O insucesso deste projecto foi encoberto, este PM foi mais tarde elogiado pelo seu excelente trabalho na festa de aniversário da empresa e vários dos técnicos ficaram chamuscados por terem reagido com desagrado à actuação do Senhor Gestor de Projecto.


    === Finalmentes: ===

    Creio que é uma questão de cultura empresarial.

    Em algumas empresas (caso 1) compreende-se minimamente o valor do trabalho dos técnicos (mesmo quando a empresa tende a poupar no que lhes paga) encontra-se uma postura em que o PM delegas as decisões técnicas nos técnicos e tenta tornar o projecto viável negociando a funcionalidade a obter.

    Noutras empresas (caso 2) deixa-se que o PM julgue ser um pequeno senhor feudal, que tudo pode e que tudo sabe. Que impõe decisões técnicas para as quais apenas está preparado pela sua graça semi-divina (que pelo estudo e pela prática não é certamente).

    No caso 1 "responsabilidade" é o PM extrair os melhores resultados dos que trabalham na sua equipe, exigindo rendimento mas também facilitando e respeitando o seu trabalho.

    No caso 2 "responsabilidade" é para os técnicos. "Responsabilidade" é o técnico obedecer cegamente o PM e assumir as culpas pela porcaria que o PM faz. "Responsabilidade" é o PM fazer o que quer desde que bajule devidamente as suas chefias, assim como espera (ou exige) que os "seus" técnicos o bajulem a ele.


    Um bom PM tem um valor gigantesco, e potencía enormemente o trabalho dos técnicos da sua equipe.

    Um mau PM destrói o trabalho de qualquer equipe por melhor que esta seja.


    Um bom PM deve ser pago a peso de ouro. Um mau PM devia ser despedido.

    Infelizmente, em Portugal:
    - Continuo a ver uma predominância da cultura que referi para o caso 2);
    - Continuo a ver mal compensado o valor dos bons PMs;
    - E continuo a ver maus PMs que destroem projectos e carreiras mas a quem tudo é perdoado.


    Como já disse no momento nem tenho razões de queixa, mas o panorama geral é mau.

    Mas a sua causa base é a má cultura de gestão empresarial que ainda predomina no nosso país.

    ResponderEliminar
  6. Que grande confusão! Um gestor de projecto a definir como se fazem as coisas... há aí uma grande confusão de papéis. Diria, que não consigo descrever melhor o papel de um gestor de projecto como o Fernando Fernández o fez.

    Agora definir como é que os módulos encaixam e que módulos existem... isso diria que é trabalho de um Arquitecto de Software. O GP tem a responsabilidade de falar com o Arquitecto para alocar trabalho e controlar prazos.

    Contudo esqueçam lá isso do GP e afins... e passem a jogar com os três papeis do SCRUM - Product Owner, Scrum Master e Team... é simples e funciona para qq tipo de projecto (grande ou pequeno

    ResponderEliminar

Enviar um comentário

Mensagens populares deste blogue

[Off-topic] "Novas" tendências de gestão

Afinal as novas tendências de gestão não são de agora. E as suas consequências também já são conhecidas há muito. Vejam esta carta do Senhor Vauban , Engenheiro Militar e Marechal de França, dirigida ao Senhor Losvois, Ministro da Guerra de Luís XIV, datada de 17 de Julho de 1683. "Monsenhor: ... Há alguns trabalhos nos últimos anos que não acabaram e não acabarão nunca, e tudo isso, Monsenhor, porque a confusão que causam as frequentes baixas de preços que surgem nas suas obras só servem para atrair como empreiteiros os miseráveis, malandros ou ignorantes e afugentar aqueles que são capazes de conduzir uma empresa. Digo mais, deste modo eles só atrasam e encarecem as obras consideravelmente porque essas baixas de preços e economias tão procuradas são imaginárias, dado que um empreiteiro que perde, faz o mesmo que um náufrago que se afoga, agarra-se a tudo o que pode; e agarrar-se a tudo, no ofício de empreiteiro, é não pagar aos fornecedores, pagar baixos salários, ter os piores

Conferência Europeia da Comunidade Alfresco

Já foi há quase quinze dias, mas julgo que ainda será relevante abordar a Conferência Europeia da Comunidade Alfresco, que decorreu em Barcelona no dia 22 de Abril. Com uma audiência de mais de 200 pessoas (a sala reservada estava cheia) vindas de vários pontos da Europa, este evento serviu para que muita gente desta comunidade se encontrasse pela primeira vez face a face. A Alfresco Inc. é uma empresa recente, que apostou em criar uma solução de gestão documental de topo de gama usando o modelo open-source . Considerando que a empresa, no seu terceiro ano de actividade, já atingiu o break-even , parece ter sido uma boa aposta. No arranque da conferência esteve John Powell, CEO da empresa, que falou um bocado sobre a excelente evolução da empresa e abordou a "guerra" entre o modelo de negócios proprietário e o modelo de código aberto. Exemplificou este conflito com o Microsoft SharePoint, que ele designou como "a morte da escolha", justificando o epíteto pelo facto

O que é uma POOL ?

Tenho andado a fazer implementações de mecanismos de pooling em Java 2 Enterprise Edition. Como me parece um conceito algo lato tentei a abordagem do dicionário. Alguns mostram que de facto a palavra é usada para muita coisa. A definição mais comum é "piscina". A que mais me agradou foi o que descobri na wikipedia , onde pooling é apresentada como uma técnica para guardar qualquer coisa que já não é necessária em determinado sitio (a que se chama pool ) com o objectivo de a usar quando necessário optimizando assim a utilização de recursos disponíveis. Partindo para a computação, existem vários tipos de pools: Thread Pool - Conjunto de threads livres que se vão adicionando a um fifo quando não necessárias e retirando quando se quiserem usar. Memory Pool - Conjunto de blocos de memória, todos da mesma dimensão, que se alocam inicialmente e usam à medida que necessário garantindo que o tempo de alocação de memória é constante e a fragmentação minima. Connect