Categories
Carreira Etc.

Plano de cargos e salários…

Me incomoda muito o fato de que desenvolvedores precisam virar gerentes ou coordenadores para ganhar mais.

<história>
Era uma vez um desenvolvedor muito bom e muito eficiente. Ao longo da sua carreira ele foi aprimorando suas habilidades e técnicas e se tornou um super desenvolvedor com um conhecimento técnico absurdo, uma vasta experiência em arquiteturas de software e poliglota em linguagens de programação. Nesse momento ele repara que já é um desenvolvedor sênior ++ na empresa que ele trabalha e por isso não tem como ganhar mais do que ele já ganha a não ser que ele vire gerente. Então, querendo ganhar mais, o excelente técnico que programava e resolvia problemas técnicos com eficiência é obrigado a virar um gerente, porque a empresa não dá para ele outra forma de evoluir financeiramente. O detalhe é que ele não tem nenhuma habilidade para gerir pessoas ou projetos, além de que ele odeia fazer isso. O que ele gostava mesmo era de programar, mas ele não teve escolha. Resumindo: a empresa trocou um excelente técnico por um péssimo gerente e ainda está pagando mais por isso!
<história/>

Já repararam como esse padrão se repete nas empresas brasileiras?

Se você nunca parou pra pensar nisso, pense agora: é muito difícil um programador ganhar mais do que um gerente e por sua vez é muito difícil um gerente ganhar mais que um diretor. A lógica do mercado é a velha lógica do plano de cargos e salários: quanto maior for o seu nível hierárquico, mais você ganha.

O problema é que isso não faz sentido. O argumento preferido das pessoas normalmente é que “os gerentes ganham mais porque tem mais responsabilidades”. Eu discordo totalmente. Por exemplo, um amigo me contou ontem que um funcionário da empresa onde ele trabalhava tirou do ar o sistema de transações financeiras de uma grande empresa, causando com isso algumas centenas de milhares de dólares de prejuizo em poucos minutos. Neste caso, um erro de um desenvolvedor provocou uma catástrofe maior do que 10 anos de erros de uma dezena de gerentes juntos. E então, quem é que tem mais responsabilidade nas mãos?

Outra coisa que me incomoda nos planos de cargos e salários são aquelas regras do tipo “gerentes ganham na faixa de R$ X a R$ Y“: se o cara ganha menos que X não pode ser gerente e se ganhar aumento para mais que Y tem que ser promovido a diretor. Isso também não faz sentido. Em todas as empresas que eu trabalhei conheci gerentes excepcionais e gerentes absurdamente idiotas. Por incrível que pareça os excepcionais com toda sua genialidade sempre ganhavam (e ganham) o mesmo que os idiotas, por causa do maldito plano de cargos e salários. Isso pra mim soa como gado: independente das suas características individuais, uma cabeça de gado custa o mesmo que outra.

Eu trabalho e já trabalhei com vários desenvolvedores de valor altissimo. Não falo isso pelo que eles ganham ou ganhavam, mas sim porque em várias situações eles criaram soluções que melhoraram ou mudaram completamente (para melhor) a forma que as pessoas trabalhavam. Algumas dessas coisas foram tão geniais que eu diria que o valor foi inestimável. Eu também já tirei meus coelhos da cartola e sei que eles foram de grande valor para as empresas que eu trabalhei.

Não deveriam ser esses tipos de coisas que determinam o quanto as pessoas devem ganhar?

Em empresas de software, onde é comum encontrar esse tipo de pessoas, deveria ser normal ter desenvolvedores altamente especializados com remunerações maiores que as de gerentes ou diretores, mas isso é tão improvável que eu diria que é praticamente impossível – pelo menos no Brasil. Já em empresas como Google, Yahoo e cia., isso é possível e normal. Na Globo.com temos alguns casos desse tipo, mas são excessões. Isso está em fase embrionária e é muito muito muito longe do que deveria ser.

Naquela história que eu contei no início não consigo pensar em um motivo sequer para a empresa não manter o funcionário como desenvolvedor e dar o aumento que ele merece. Esqueça o plano de cargos e salários e veja como faz sentido: isso seria muito melhor para a empresa – porque o funcionário iria agregar muito mais valor sendo desenvolvedor e iria ajudá-la a lucrar muito mais – e seria melhor para o desenvolvedor – porque ele iria fazer o que gosta, o que é mais experiente e o que estudou sua vida toda para fazer.

Até quando as empresas vão continuar colocando as pessoas certas nos lugares errados?

Categories
Engenharia de software

Programadores ou apertadores de botão?

Ontem estava conversando com uns amigos sobre os novos programadores que estão surgindo por aí, especialmente os que usam o Visual Studio .Net. O Visual Studio nem parece que foi feito para pessoas que sabem programar. Muitas vezes não dá para fazer certas coisas programando código mesmo, você é obrigado a usar um dos milhares de wizards da ferramenta.

Um dos meus amigos estava contando que quando ele começou a programar estava precisando colocar um combo box numa página e os itens deste combo precisavam ser lidos de uma tabela do banco de dados. Ao procurar na internet para descobrir como isso era feito, as únicas referências que ele encontrou eram de wizards! Simplesmente ele não conseguia encontrar uma página que mostrasse o código para fazer o que ele queria.

Eu ainda não tirei minhas conclusões definitivas sobre isso. Ás vezes eu acho que as pessoas estão ficando preguiçosas, ás vezes eu acho que falta mesmo qualificação para os programadores e ás vezes eu acho que é tudo isso ao mesmo tempo. Ultimamente a quantidade de gente desse tipo tem aumentado muito por aí. As novas ferramentas de desenvolvimento estão tornando os programadores em apertadores de botão!

Programar é uma atividade intelectual que exige conhecimento técnico (linguagens, plataformas, sistemas operacionais, tecnologias), conhecimento específico sobre o negócio para o qual o sistema é desenvolvido, capacidade de resolver problemas e criatividade. Quanto mais as pessoas se preocuparem em aprender sobre ferramentas ao invés de tecnologias e práticas de desenvolvimento, mais vão surgir os apertadores de botão e as características acima vão sendo substituídas por conhecimentos de wizards, opções da ferramenta e botões diversos que fazem coisas mágicas.

Na semana passada saiu um artigo na Artima entitulado Visual Development versus Coding que fala exatamente sobre isso.

A opinião do David Intersimone é a mesma que a minha: é muito legal ter ferramentas visuais para te ajudar a fazer as coisas, note bem, para AJUDAR. Mas se você precisar (e vai), você tem que saber codificar.

Categories
Engenharia de software XP

Como produzir software “coxa”

Acabei de ler um post no blog do Phillip que me lembrou de uma história que eu queria escrever aqui.

A história que você lerá a seguir é uma dramatização do que acontece diariamente no mundo do desenvolvimento de software carinhosamente entitulada Como desenvolver software “coxa”.

Imagine uma empresa que está com necessidades de desenvolver um software. E imagine também que esta empresa (cliente) contratou uma empresa de 3 letras para fazer o trabalho.

Então, o projeto começa com a empresa contratada fazendo uma análise extensa do que será desenvolvido. Caso você não saiba, estas empresas te fazem acreditar que o RUP tem uma fase de análise antes de tudo, quando isso na verdade caracteriza um processo de desenvolvimento waterfall que é bem diferente do processo de desenvolvimento iterativo do RUP.

Depois de analisar exaustivamente tudo que precisa ser feito, eles acham que sabem tudo que o cliente precisa e com isso acham que sabem exatamente quanto tempo irá levar. Baseado nisso é estipulado um prazo de entrega do software para o cliente, assim como é estipulado um preço fixo para o trabalho.

Fechado o contrato, o projeto é iniciado. E quando começa o projeto sempre acontece a mesma coisa: a equipe de desenvolvimento começa a descobrir que certas coisas não são tão simples quanto pareciam ser. A equipe se depara com vários problemas que não haviam aparecido na fase de análise e cada vez fica mais chocada com a quantidade de coisas novas que vão surgindo. Nesse momento a equipe percebe que o projeto, que estimou-se que precisaria de 4 meses para ser desenvolvido, na verdade precisa de 8 meses para ser desenvolvido!

Então alguém surge com a brilhante idéia de contratar mais pessoas para a equipe. Afinal de contas, da mesma forma que nove grávidas conseguem parir um filho em um mês, 20 desenvolvedores conseguem fazer na metade do tempo o trabalho que 10 fariam – parece perfeito!

Mas espera aí, o preço já está combinado com o cliente desde o início. Então contratar mais pessoas é a maior furada, porque o cliente não pagará nada a mais por isso e se o custo do projeto for maior a empresa não terá lucro. Pior ainda, a empresa pode ter prejuízo! Neste momento a empresa decide comuncar ao cliente que o projeto terá que atrasar.

Quando a empresa vai dar a notícia para o cliente o cara normalmente quer matar o gerente do projeto, quer se matar, ou OS DOIS (depende do tamanho do projeto)! Afinal de contas ele pagou 50% adiantado e quer logo o retorno do seu investimento. Se o projeto ia demorar 4 meses e agora vai demorar 8, significa que todo o seu planejamento financeiro e de retorno de investimento do software foram por água a baixo. Nesse momento o cliente bate na mesa com força e diz: “se virem, eu não quero nem saber como vocês vão fazer mas eu quero o meu software na data combinada!”.

Exatamente neste momento foi parido um software “coxa”!

Vou explicar fazendo uma analogia: qualquer criança de 10 anos sabe que não existe “bom, bonito e barato”. Ou é bom, bonito e CARO; ou é RUIM, bonito e barato; ou é bom, FEIO e barato. Não tem jeito, é assim que funciona, não é possível ter tudo ao mesmo tempo.

Com software funciona exatamente da mesma forma. Só o que muda são as dimensões: qualidade, tempo e custo. Da mesma maneira que não existe nada bom, bonito e barato, não existe software “bom, desenvolvido rápido e barato”. Ou é bom, desenvolvido rápido e CARO; ou é bom, DESENVOLVIDO EM MUITO TEMPO e barato; ou é RUIM, desenvolvido rápido e barato.

No caso deste projeto repare que duas das dimensões do software não podem ser alteradas: preço (porque já foi combinado com o cliente e está em contrato) e tempo (porque a data de entrega já está estipulada). Sendo assim, como não dá para ter tudo ao mesmo tempo, a qualidade vai para o brejo. Neste momento é que vem a ordem do gerente de projeto: “gente, faz qualquer coisa aí, o importante é entregar o que foi combinado com o cliente, não importa como, faz tudo nas coxas mesmo!!”. E mais um software “coxa” será entregue.

Se eu contar os softwares “coxa” que eu já ví por aí ninguém acredita. O mais bizarro deles e que não poderia deixar de ser citado tinha o seguinte código na tela de autenticação (PHP):

if (($_REQUEST["login"]  == "admin") && ($_REQUEST["senha"]  == "1234")) {
    header("Location: index_autenticado.php");
} else {
    header("Location: index.php?mensagem=Login%20invalido");
}

No final das contas, quando o projeto é entregue, o cliente vê as telinhas e se as telinhas estiverem aparecendo e estiverem no mínimo bonitinhas ele vai dar pulos de alegria! Eventualmente até irá contratar a empresa para outro projeto ou indicar para amigos e outros projetos dentro da sua empresa. Por baixo dos panos existe esse monte de lixo, mais ou menos como um vulcão que pode entrar em erupção a qualquer momento causando efeitos devatadores! Deixa só alguém pedir para trocar a senha do sistema para ver o que vai acontecer…

Para mim é claro como água: não adianta querer prever tudo que acontecerá no projeto e pré-fixar datas e valores. É receita certa para fazer lixo. Já está mais do que provado que não funciona, porque insistir no mesmo erro?

Se você que está lendo se identificou com a história (o que não é nem um pouco difícil), sugiro fortemente que você leia sobre um modelo de contrato de desenvolvimento de software proposto pelo XP que muito me agrada: o Contrato de Escopo Negociável. O artigo é bem grande mas vale apena ler até o final! Você vai perceber que as coisas não precisam ser assim tão tristes nos projetos de desenvolvimento do software.

Categories
Comunidade Mercado

E dá-lhe ThoughtWorks!

Os caras da ThoughtWorks se empolgaram! Não tem nem duas semanas que lançaram o Mingle e acabo de ficar sabendo de mais um, o CruiseControl Enterprise.

Eu acho que eles vão ganhar bastante dinheiro com os dois. E espero que eles ganhem mesmo porque os dois são muito bons. Só espero que eles não parem de produzir as coisas livres legais que sempre produziram (XStream, XFire, PicoContainer, etc) para passar a vender tudo! Bom, pelo menos na enterevista que eles deram no InfoQ disseram que o produto pago irá contribuir com a comunidade também, o que é bem legal. Se continuar assim está bom.