Estava conversando com o Victor Cavalcante e com o André Dias e o André contou uma história interessante. Ele contou como, uns anos atrás, foi trabalhar com o Fabio Galuppo. Segundo ele, o anúncio do Fabio era mais ou menos assim:

"Quer trabalhar em uma empresa parecida com a Microsoft? Quer trabalhar de bermuda, e com horário flexível? Entre em contato conosco."

De imediato lembrei do anúncio que a Globo.com colocou na sua palestra do Scrum Gathering. Havia um desse em cada cadeira onde os congressistas sentaram:

"Cansado de apertar parafusos? Agora você poderá participar do processo criativo, colaborando com suas idéias em um time multidisciplinar formado por desenvolvedores, dbas, sysadmins, designers, testers. Você vai especificar e implementar esses sistemas, além da manutenção evolutiva e corretiva dos produtos atuais.
(…)
Cansado de ficar preso na jaulinha? Aqui temos diversas máquinas no laboratório para testarmos o que precisa ser feito. Ninguém vai censurar sua internet, e, se você quiser, pode instalar a sua distro preferida. E ainda damos apoio para o desenvolvimento de projetos pessoais. Suas idéias podem virar grandes projetos na Web."

E olha que está resumido. O panfleto ainda cita diversas outras coisas interessantes.

Vocês tem idéia da quantidade de currículos que o Galuppo deve ter recebido? Se você está em busca do top 5%, você precisa de pelo menos uns 20 candidatos para achar 1 do top 5. Não é fácil. O André, que hoje trabalha na Microsoft, contou que na época podia trabalhar de bermuda, com exceção apenas para os dias em que recebiam clientes na empresa. Tinha horário flexível, podia trabalhar de casa, fazia o que gostava, e ainda ganhava para isso!

E na Globo.com, o que vocês acham que vai acontecer? Eu sei de uma coisa: eles vão precisar de um guarda-chuva, vai chover currículo.

Quantidade não é qualidade, mas, para selecionar um profissional de qualidade este profissional precisa, no mínimo, querer trabalhar na empresa - ele precisa se interessar por ela.

Enquanto isso grandes bancos colocam o desenvolvedor na "jaulinha". Sei de um que impede qualquer contato com a máquina de desenvolvimento além do mouse, teclado e monitor – O desktop fica em uma sala separada. Há outro onde o desenvolvedor não pode trabalhar de barba (?!), usar nada no bolso da camisa, ou sequer conversar com o colega do lado. Há outra empresa que conheço onde nenhum e-mail do funcionário sai da corporação, e ele também não tem acesso à webmails públicos.

Acho que nem os militares são assim assim tão rígidos. Qual você acha que é a produtividade de times que trabalham desta forma? Será que há times, ou meras agregações de pessoas? Vale a pena tratar desenvolvedores de software como se fossem operários da década de 50? (Vale a pena tratar operários do século XXI como se fossem operários da década de 50?)

Vou mais longe: Qual é o problema de trabalhar de bermuda? De ter horário flexível? De ter cabelo comprido, barba, piercing, etc? Porque gastamos tanto tempo avaliando itens que não tem relação alguma com a entrega? Pior, porque coagimos nossos funcionários a trabalhar infelizes, e, consequentemente, produzirem menos? Nossa tradição se paga? Tradição é um outro nome para pré-conceito quando ela é exercitada sem questionamento.

Cada empresa que trabalhe como quiser, no entanto, umas trabalham melhor que outras. Em um mercado com falta de profissionais, quem dá as cartas não são as empresas. Continuem elas a seguir este modelo ultrapassado, vão ficar com o resto, porque a nata vai trabalhar aonde se sente mais à vontade. Hoje em dia troca-se de emprego em um estalar de dedos. A opção das empresas "tradicionais" vai ser aumentar o salário, para convencer os profissionais a ficarem. Só que isso só funciona por algum tempo. Além disso, nenhum gerente sustenta internamente um custo acima do necessário por muito tempo, isso acaba sendo questionado, e, eventualmente, a empresa se rende. "Se rende". À que? À coerência?

A nova geração, composta de pessoas que estão se formando agora, e que, com 21 anos, nasceram no final da década de 80 e passaram toda sua adolescência no século XXI, também dará muito trabalho para empresas que não focam no resultado, mas nos itens menores que já citei. Essa geração cresceu com internet e liberdade, e chega ao mercado de trabalho questionando esse modelo antiquado. Apenas os submissos vão encarar essa coação, enquanto os criativos buscam uma empresa melhor para trabalhar. Que tipo de profissional você prefere ter ao seu lado?

A geração seguinte, que virá em 5 anos, será ainda mais decidida. Ela terá crescido com a mobilidade total, com o 3G no celular e no notebook. É a informação 100% disponível, 100% do tempo, em 100% dos dispositivos. Será a geração que cresceu 100% conectada.

Como você vê essa questão?

Meu post anterior resultou em alguns comentários interessantes. Nele eu disse que se um desenvolvedor quer virar gerente de projetos você tem problemas. Como pode ter muita gente que discorda do que eu disse e não comentou, resolvi, em vez de responder aos comentários, fazer este post. Aproveito aos que não comentaram e não concordam, a saírem do modo read-only e comentarem. Assim como os que concordam também.

A maior parte dos comentários passou pelo fato de eu estar generalizando, como de fato estava, e que nem sempre o caso cairia em uma das duas situações. Bom, toda regra tem suas exceções, mas eu sustento que as duas opções que dei atendem a imensa maioria do mercado. Eu resumi as opções assim:

"Em resumo: o cara quer ganhar mais, e você perdeu um desenvolvedor e ganhou um mau gerente; ou o cara não gosta do que faz e você perdeu um desenvolvedor e a empresa pode ou não ganhar um bom gerente."

Vou pular a discussão sobre remuneração, porque ela desperta menos polêmica. Seguindo na outra, bem mais interessante:

Porque eu não acho que uma pessoa com talento para gestão de projetos pode ser também um bom desenvolvedor? Porque eu acho que uma pessoa que ama codificar não dá um bom gerente de projeto? Porque?

Porque, como diz o título deste post, gerenciar projetos não tem nada a ver com desenvolvimento de software. Gestão de projetos sequer devia ser ensinada como parte de um currículo de tecnologia, e sim de administração de empresas, algo que já está começando a acontecer nas melhores faculdades. Gestão de projetos não tem nada, N-A-D-A, em comum com tecnologia. Ainda assim, os cursos nasceram em TI, e seguem focados em TI. E muitos codificadores vêem o cargo de gerente de projetos como progressão natural na carreira. Entendo que algumas pessoas busquem esta profissão, afinal, todo projeto precisa de um gerente de projetos (isso não é verdade, mas vou assumir como verdade e comento no final). Os codificadores estão, o tempo todo, trabalhando lado a lado com um GP. É natural que alguns se interessem.

A questão é que são coisas muito diferentes. As competências exigidas de um GP são absolutamente diferentes - senão opostas - às esperadas em um desenvolvedor de software. O primeiro deve saber lidar muito bem com pessoas, liderá-las, ser extremamente bem organizado, político e ter capacidade de raciocínio subjetivo, adorar se comunicar, gostar de fazer cálculos financeiros e projeções, e ter prazer em trabalhar com regras sociais. Do segundo espera-se análises concretas, lógica apurada, raciocínio rápido, capacidade de trabalhar longas horas focado na solução de um problema, ser interessado em maneiras novas de resolver velhos problemas, amar tecnologia, ser criativo dentro de um padrão lógico. Essas qualidades todas podem existir em uma única pessoa? Podem. É comum que isso aconteça? Não. Em geral são pessoas muito diferentes.

Aos que discordam de mim, e vão seguir este caminho, deixo uma mensagem clara: investigue, dentro de si mesmo, se você quer abandonar o Visual Studio, e passar a usar o Word e o Outlook o dia inteiro como principal ferramenta de trabalho. Se é capaz de, em vez de executar, somente assistir à execução. De ficar de fora do caminho de quem faz, e, na verdade, auxiliá-lo quando ele tiver problemas. Gerenciar não é mandar, é facilitar. Diante disso, acredito muito na figura do líder servidor. Você é capaz de servir à equipe, de, em vez de mandar, correr atrás do que eles precisam? Você vê um dia de trabalho que o dia inteiro foi gasto em reuniões de orçamentação como um dia divertido? E outro dia passado revisando performance do time com o RH? E outro ainda realizando resolução de conflitos interdepartamentais? Essas são tarefas de um gerente, e é bom que ele goste, ou vai viver infeliz, como acontece frequentemente. O trabalho tem uma visão interessante, quase romântica, mas será que os que o aspiram já se imaginaram nele pelo resto da vida? E se vê, então investigue em si mesmo o oposto: você realmente gosta de codificar? É algo que faz por paixão, do qual sente falta se fica algum tempo sem fazer? É algo que te dá prazer e gratificação?

Se você se vê nessa posição de gerente e gosta do que vê, perfeito! No entanto, não entendo ser possível que o ideal de felicidade de alguém seja ao mesmo tempo passar o dia em orçamentação e passar o dia codificando. São coisas muitos diferentes. É por isso que eu disse: uma das duas coisas essa pessoa não vai gostar de fazer. Eu jamais recomendo a uma pessoa que é apaixonada por codificação que trabalhasse em um cargo gerencial. Como não recomendo a alguém apaixonado por gerenciar pessoas que codifique.

Há uma pergunta que costumo fazer à pessoas que entrevisto: Você codifica nas horas vagas? Se a resposta é não, eu quero saber o porque. Isso diz muito sobre o quanto você gosta do que faz. Da mesma forma que gerentes apaixonados pela gestão financeira fazem planilhas para controlar seus gastos pessoais, programadores apaixonados às vees automatizam pequenas coisas com programas que fizeram, avaliam uma nova linguagem só porque ela parece interessante, e quando vêem um código na tela do cinema tentam entender o que ele quer dizer.

Apenas para fechar: Volto ao tema de projetos de software precisarem de um gerente de projetos. Não precisam. O mundo de TI está começando a perceber agora, conforme as metodologias ágeis afundam a figura do gerente de projetos e escancaram o fato de que times autogerenciáveis são muito mais eficientes. Esse perfil em TI vai virar peça de museu conforme percebe-se que o modelo baseado na figura controladora, responsável por ações de comando-e-controle, que o GP representa na maioria das organizações, é improdutiva, além de dispensável. Você pode até não concordar, mas somente se já viveu dos dois lados do muro (e nesse caso gostaria de ouvir suas experiências concretas).
Eu? Acredito na figura do facilitador de projetos, do derrubador de barreiras, algo que em Scrum chamamos de ScrumMaster. E ele não é um gerente de projetos.

Estava conversando com um cliente sobre um projeto. Ele me contava que tinha um desenvolvedor sênior trabalhando em algo importante para a empresa.

Perguntei:
- Sênior mesmo? - como quem já desconfia quase sempre que algum desenvolvedor de .Net se declara sênior…
A resposta dele:
- É, sênior, ele é um cara sério, está estudando e quer até virar gerente de projetos.
Minha resposta:
- Você está com problemas.

Se você tem um desenvolvedor na sua equipe que "quer virar" gerente de projetos você está com problemas. Sabe porque? Porque há apenas duas possibilidades para a origem desta aspiração:

1. Ele não gosta do que faz agora, ou;
2. Ele acha que ganha pouco.

Em qualquer dos casos você tem um problema na mão. Um problema que tem que ser resolvido.

Se for o segundo caso, o problema não é só seu ou da sua empresa. No Brasil entende-se que o superior hierárquico tem que ganhar mais que o subordinado, por diversos motivos que não vale a pena entrar agora. Não se admite que o "recurso do projeto" ganhe mais que o arquiteto ou que o gerente do projeto (deste muito menos, ele até usa gravata!). Não há o que fazer, uma pessoa do seu time quer ganhar mais, e a não ser que você queira inverter a maneira natural de pensar do brasileiro, você vai ter que deixar ele fazer algo que ele não gosta, não quer, ou não tem talento para fazer, para que ele possa ganhar mais. Afinal, esta é a única maneira de ganhar mais em alguns casos. Isso é um problema para você porque você vai perder um bom desenvolvedor, e a empresa vai, em geral, ganhar um mau gerente. Mais comum impossível. Quem não conhece um gerente sem a menor qualidade para gerenciar pessoas que era um bom técnico?

Se for o primeiro caso, então a empresa tem a oportunidade de ganhar um bom gerente. A má notícia é que você tem alguém no time que joga no Flamengo e está namorando o Real Madrid, ou seja, está com a cabeça em outro lugar. E, pior, trabalha sem emoção, sem paixão, sem envolvimento, já que o trabalho atual é só um meio de ele chegar aonde vai fazer o que realmente gosta. Há duas opções neste caso: você vê potencial e promove o cara, e deixa a empresa feliz com seu novo gerente. Ou manda ele virar gerente em outra empresa, já que você precisa mesmo é de um desenvolvedor.

Em resumo: o cara quer ganhar mais, e você perdeu um desenvolvedor e ganhou um mau gerente; ou o cara não gosta do que faz e você perdeu um desenvolvedor e a empresa pode ou não ganhar um bom gerente.

Como eu disse, em qualquer dos casos você está com problema: você vai perder um desenvolvedor. Que seja mais cedo do que mais tarde.

Não, não é spam. É um post que surgiu de uma discussão no .Net Architects, que eu gostei de escrever, e adaptei para cá.

Gostaria de introduzir uma idéia que você provavelmente nunca parou para pensar:

1) Você não recebe de acordo com seu conhecimento.
2) Você não é valorizado por quanto você sabe.

Esse é um conceito que vem da economia. Você recebe de acordo com a sua raridade. Quanto mais raro você for mais você vai ganhar.
Isso fica evidente com os consultores de SAP. SAP é chato pra caramba, mas não é nenhuma ciência nuclear. Só que os caras ganham muito bem para trabalhar com ele. E a cada ano ganham menos. Porque? Porque há poucos consultores de SAP no mercado, mas a cada ano mais gente entra no mercado para pegar uma fatia desse bolo, o que faz com que o salário de todos diminua.

Certificação te ajuda a ser mais raro. Se há 5% de profissionais certificados, então ele já é 1 em 20. Em uma seleção, seria o mais raro sob esse aspecto. Às vezes compensaria outra falta, como não conhecer NH, por exemplo.
Mas o contrário também é verdade, o cara pode conhecer NH, mas não ser certificado.
Nos dois casos, a raridade é quem manda. Só uma observação: tem menos gente que conhece NH do que gente certificada, ao menos no Brasil.

Meu conselho? Especialize-se. Se você quer um diferencial com a certificação, não pare por aí. Conheça mais que os outros, estude, mas encontre maneiras de deixar isso visível para o mercado. Como era o ditado? "Não basta a mulher do rei ser honesta, ela tem que parecer honesta."
Torne-se raro.

Quantas pessoas escrevem em revistas? Quantas pessoas participam de grupos de usuários? Quantas pessoas conhecem IoC? Quantas pessoas são certificadas? Quantas pessoas são formadas? Quantas conseguem demonstrar o quanto conhecem, e que não fazem parte da média?

Não precisa ir muito longe, há uma pergunta que já elimina muita gente, e mal demanda esforço: quantas pessoas vão a uma conferência que seja por ano? Um evento presencial? Há dois eventos grandes (grandes mesmo) no país que falam sobre .Net (que eu conheço): o TechEd - 2000 pessoas, e o da Devmedia (que um ano é um WebDays e no outro um Webmobile TechWeek) - 500 pessoas. Quantas pessoas foram neles? 2500. Some aos da comunidade, onde poucos são como será o .Net Architects Day, de dia inteiro, multidisciplinares, e vocês verão que o universo de diferenciação é muito pequeno. Não deve dar 5000 pessoas. A maioria faz parte do médio, do comum. Depois perguntam como ganhar mais. Sabe como? Diferencie-se. Torne-se raro.

É engraçado porque não parece óbvio. A maioria acha que esforço paga bem. Não paga. Nem conhecimento. Conhecimento muito especializado, muito amplo, ou ambos, esse bem, paga bem, porque poucos o tem. Desde que seja visível.
Em vez de ficar virando hora na empresa para ganhar 10% a mais no fim do mês, façamos um curso e vamos ganhar 30% a mais fazendo algo mais legal, e que paga melhor, sem precisar virar hora!

Estou colocando uma visão de carreira, que nada tem a ver com conhecimento. É bom entender que são coisas diferentes, e as duas devem ser valorizadas, pois as duas trazem coisas boas.

Será que um profissional de tecnologia, um programador ou arquiteto de software, precisa saber escrever corretamente? Mais que isso, será que precisa saber escrever bem? "Bem" é algo subjetivo, eu definiria que um texto bem escrito é um texto que prende minha atenção, não me dá sono, é educado, não parece que foi escrito por uma criança ou adolescente, e me dá vontade de ler até o final.

Eu acho que escrever corretamente é fundamental. Quando vejo um desenvolvedor que comete erros fundamentais de português, não tenho como deixar de imaginar como foi o resto da educação dele. Se não sabe nem escrever, será que sabe programar? Não saber escrever corretamente também é reflexo de algo muito mais sério: falta de leitura. Uma pessoa que trabalha com desenvolvimento de sistemas e não queira ficar para trás precisa estudar. E para isso, a leitura é fundamental. Logo, se o profissional não lê, isso quer dizer que não estuda, e que a chance de estar desatualizado é razoável. Para um profissional pleno isso é menos importante, para um sênior é crítico. Ele até pode aprender a usar um novo datagrid, mas não vai muito além disso. E um sênior não é feito de saber usar datagrids, ou que conhece o .Net Framework 3.5, é uma composição de coisas, entre elas o interesse por diversos assuntos, que demandam leitura.

Agora, de nada adianta o cidadão escrever corretamente. Não posso pedir a um programador que escreve apenas corretamente para escrever a um diretor. Se o profissional escreve corretamente, mas escreve sem clareza ou como um adolescente, ou seja, não sabe se comunicar, escolho outro que saiba para escrever ao tal diretor.

Imagine a situação: você pode ser um ótimo programador, mas eu convido o seu colega, que é um programador médio, para se comunicar com alguém alto na hierarquia. Ruim, não é? Você acaba de perder uma oportunidade de fazer um pouco de networking.

Só tem um remédio: leia! E escreva também. Pode ser um blog, um diário, cartas para um familiar distante, não interessa. Exercite a escrita. Isso muda não só sua maneira de escrever, mas também a de ler, e até de pensar.

Leitura é algo fundamental. Muita gente não pega num livro o ano inteiro, não lê nada. Só que a leitura é um hábito que qualquer um pode criar. Então, se você não está acostumado a ler, é bem simples resolver: acostume-se. No começo é um remédio amargo; depois que você acostuma passa a gostar, e ler se torna uma experiência, no mínimo, prazerosa.