PMP, o PhD brasileiro!

Havia um tempo “feliz” onde se via os americanos escreverem, Mr Smith, PhD.

Esse simbolo, esse status era para poucos. Apenas os doutores, sofredores, com anos de estudos, mestrado, doutorado, suor e lágrimas podiam ter esse título.

Certo ou errado? Digamos, a avaliar, mas sem dúvida, pelo menos PhD realmente significava algo.

Anos passam, e surgem as certificações de TI. Ganham força com as áreas de rede, com as certificações CISCO da vida, aí a Microsoft explode com o mítico System Engineer (MCSE, que por sinal virou sinonimo de fama até para desenvolvedor).

Depois disso vieram as certificações técnicas de desenvolvimento, o MCSD, depois o mundo java, r por aí vaí.

Muito colocavam lá suas certificações na assinatura do email, como simbolo de proficiência, esforço, orgulho ou pura tiração de onda.

O mundo gira e estamos nos anos 2000, carros voadores e tudo pela janelas. Surge então a chance de virar gerente! Pois é gerente, aquele que ganha muito, aquele que seu salário nunca irá nem chegar aos pés porque a famosa carreira em Y só existe no fim do arco-iris (as áreas de RH devem ter um binoculo que consegue ver lá).

Bom, sem digressões.... Então, voltando a gerência, surge um modo de chegar lá. Os mesmos que faziam beicinho para as certificações técnicas, aqueles que nunca ligaram para elas, descobrem três letrinhas mágicas, atalhos para a gerência! Que se dane o Y!!!!!!!

Pois aí, ai surge o PMP, timidamente no Brasil, explodindo em 2006. Dizem que os PMPs tem crescido mais que os evangélicos no país até!

Contrariando nosso sangue indígena, hoje temos mais gente “preparada” para ser cacique do que indio! Viva! Tomara que consigam fazer as ferramentas de MDA funcionarem (e evoluírem uns 500 anos), aí pode ser que o mercado de informática funcione sem quem bota a mão na massa.

Mas voltando ao inicio, lá onde vimos o arco-iris a primeira vez, de repente, o que era PhD nos USA (yeah baby) começa a virar PMP no Brasil. Sério! Devagar, começam a surgir aquele nomes de pessoa com apêndices, não cthulhianos: Fulaninho de tal, PMP!

Esta vendo? Igualzinho ao PhD? Será? Bom, pelo menos a idéia me parece ser a mesma... Devem estar aprendendo técnicas de propaganda, meditação, turning undead ou auto-ajuda (vá lá, marketing pessoal!).

Aquele PhD que ralou anos, agora é substituído pelo PMP, que estudou 2-3 meses para fazer uma prova, nunca gerenciou um projeto, e apenas coletou assinaturas das empresas que trabalhou atestando uma fantasia.

Ah, não fica nervoso! Mas estatística se faz pelas massa, não? Sempre com suas honrosas exceções? O que vejo como regra nas empresas é o descrito acima, PMP que no fundo não agrega nada nos projetos.

Portanto o que diferencia o PMP de um profissional com outras certs (vamos ser íntimos!)?

Bom, na teoria do PMI deveria ser muito, na prática, vale um PhD? Pois tem muita gente que quer que pensemos assim!

PS: Como um quiz (ah, aprendi ser pedante com um ex-colega de trabalho), pensa aí: dos seus projetos gerenciados por PMPs, conte quantas técnicas do PMBOK eles aplicam em cada projeto? Vamos, faça um esforço que talvez você encontre uma e garanta seu lugar no Guiness! Não vale cronograma, hein!

Agile na CNN

Na segunda edição anual especial da revista Business 2.0, que lista as 50 pessoas, produtos , tendências e idéias que podem mudar o mundo dos negócios, o desenvolvimento ágil de software está em número 18 do ranking!! Tomara que este movimento ganhe mais força por aqui. Confira você mesmo!

Documentação X Burocracia

A documentação é algo burocrático? Quase sempre, tenho a impressão de que estou fazendo um trabalho burocrático quando documento um sistema, mas será que esta impressão é falsa? Será que sou muito "anarquista" para os padrões das empresas de informática? Ou será que as empresas e suas metodologias é que são muito rígidas para um tipo de produto que é muito pouco padronizável?

Pensando sobre esta questão me vi obrigado a, antes de mais nada, fazer uma auto-análise. Vasculhando o meu histórico profissional descobri que, dentre todas as queixas que tenho, as mais relevantes são a impessoalidade e rigidez. Decidi então que estes seriam os pontos de partida.

Sempre fui incomodado com a rigidez das metodologias. Elas sempre dizem: quando você está passando da fase A para a fase B você deverá gerar os artefatos X,Y,Z. Mas, quase sempre, me vejo gerando algum documento inútil; não documentos não devam ser gerados, mas sempre geramos muitos artefatos desnecessários. Então por que gerá-los? Apenas para cumprir tabela? Eu sinto que esta é uma queixa bem geral, mas o senso comum diz que documentação é sinonimo de organização. Como se gerar uma pilha de documentos garantisse que tudo está correndo como planejado.

Outra coisa que me incomoda é o foco na impessoalidade. Quando escrevemos a documentação colocamos na cabeça que ela vai ser lida não por uma pessoa, mas por um cargo; no sentido de que ela é escrita, por exemplo, para um analista de sistemas que vai, mesmo sem nenhum conhecimento prévio, conseguir entender todos os conceitos apenas pelas descrições da documentação. Eu, sinceramente, nunca vi isto acontecer. A maioria das pessoas consegue em meia hora de conversa explicar muito mais sobre um sistema do que com uma documentação que levou meses para ser escrita. Não estou querendo dizer com isto que a documentação é inútil, mas apenas enfatizar que ela tem limites e que a impessoalidade aumenta ainda mais estes limites. Quantas vezes perdemos horas tentando entender manuais de produtos eletrônicos sem sucesso e uma pessoa experiente no assunto consegue nos explicar o problema em minutos? Esta é uma característica da linguagem técnica: ela é muito fria, carrega um estigma de que, por ser científica, tem que ser isenta ao máximo, tem que excluir o observador, porque, como traz uma verdade absoluta não pode depender de características humanas. A verdade não pode estar a serviço do homem, este que se vire para entendê-la. Por mais estranho que pareça, quanto mais complicada ela é, mais status de verdade ela tem.

Tomei como base para uma pesquisa estas duas queixas: a rigidez às normas e a impessoalidade; e fiz uma pesquisa nas teorias da administração de empresas. Imaginem a minha surpresa quando encontrei a teoria da administração burocrática! Esta teoria tem, entre os seus princípios básicos, a impessoalidade e a rigidez à norma. Dentro de uma burocracia perfeita não existe lugar para criação. Tudo deve estar previsto em alguma norma e esta deve ser seguida à risca. O trabalho também é perfeitamente dividido, os cargos muito bem definidos e o foco não está nestes cargos mas em seus ocupantes. Não há nada mais burocrático que um manual técnico de um produto. Chega a ser assustador como você pode comprar um celular com um design fantástico e, quando abrir o manual, encontrar aquela linguagem chatíssima! Milhões de dólares no design e nada investido para tornar os manuais menos burocráticos.

Considerando o que diz esta teoria administrativa não há como negar que produzimos documentação de sistemas com uma visão burocrática. A essência do meu incômodo não é a documentação em si, mas os seus excessos burocráticos. Tenho certeza de que poderíamos evoluir muito se tirássemos este modelo da cabeça e pensássemos no que realmente precisamos quando documentamos um sistema, principalmente nos dias de hoje, quando a informação pode chegar ao espectador pelas formas mais variadas possíveis. Por exemplo, imagine se todos os conceitos básicos de um grande sistema fossem gravados em vídeo no formato de teleaula? Quanto de informação não poderia ser passada em uma aula de meia hora? Não seria muito menos impessoal do que uma pilha de papel?

Dizem que os homens inventam as máquinas e as máquinas reinventam os homens, mas isto não parece ser verdade para os profissionais que trabalham com as máquinas mais fantásticas que o homem já construiu. Estes preferem a prisão de uma visão burocrática de mundo à liberdade de um universo de novas possibilidades.

Google e a Apropriação dos Meios de Produção

Considerando alguns feedbacks em relação ao post anterior resolvi revisitar algumas idéias que achei que não ficaram muito claras e lançar um desafio para mim. Este desafio é mais ou menos um JUnit da minha visão sobre a apropriação dos meios de produção na informática: como o Google apropria os meios de produção? Mas antes de mais nada seguem as minhas novas considerações sobre o que foi dito:

Eu não disse, no post passado, que acho certo que as empresas dependam de um (1) funcionário, depender das pessoas é muito diferente de depender de uma pessoa! Você deve ler a minha visão desta dependência da seguinte forma: a qualidade dos produtos das empresas de informática depende principalmente da qualidade dos profissionais que trabalham na construção dos mesmos!

Isto não quer dizer que a empresa deve se sujeitar a todos os caprichos dos seus funcionários. O que deve existir é uma separação entre responsabilidades: à empresa cabe prover infraestrutura e um bom ambiente de trabalho e ao funcionário cabe produzir artefatos com qualidade e ele deve ser cobrado por isto.

É relativamente comum você encontrar desenvolvedores que não têm o mínimo de cuidado com o que produzem. Fazem implementações e não testam nem mesmo na sua estação. Em uma situação como esta se você estiver contaminado com uma visão de processo industrial vai pensar que esta é uma falha no processo. Se a falha está na não verificação da implementação então basta criar um processo "verificar implementação". Isto porque, como os processos são impessoais, a culpa não pode ser do implementador! Se quem garante a qualidade é o processo então é óbvio que a falha é dele e não das pessoas. Será mesmo? Vale a pena ter uma pessoa que não tem compromisso nenhum com a qualidade na sua empresa? Sinceramente, se for diagnosticado que determinado profissional não tem este compromisso e não se mostra receptivo a mudar esta atitude ele tem que ser demitido! Os piores profissionais vão se esconder debaixo da tonelada de processos e vão fazer exatamente o que a empresa quer: vão transferir a responsabilidade da qualidade para os processos!

Também é incorreto interpretar que eu sou contra processos e documentação. As pessoas estão tão embotadas com a idéia de que os processos definem a qualidade que vêem quem pensa diferente como anarquistas que não gostam de se sujeitar a nenhuma regra e que não se importam com a qualidade do que fazem. Acredito nos processos e na documentação como formas muito eficientes para organizar o trabalho e facilitar a comunicação, mas acho que o máximo que a dobradinha processos/documentação pode fazer é evitar que trabalho seja desperdiçado. Na minha visão o máximo que esta dobradinha pode oferecer na informática é aproveitar bem o capital humano, mas você nunca vai conseguir criar um produto de informática que agregue mais qualidade do que a que as pessoas que trabalharam nele podem agregar. Não é possível criar qualidade do nada.

Quando questiono a alienação causada pela divisão do trabalho não quero dizer que todas as pessoas devem fazer de tudo no projeto, o trabalho pode e deve ser dividido; cada um tem as suas habilidades e deficiências. O que não se pode perder é a visão do todo. A frustração não vem da divisão em si, mas da perda de objetivo do trabalho. Para se ter uma idéia do quanto o trabalho transformador é importante para o ser humano basta dizer que uma das possíveis interpretações para representação de inferno na mitologia grega é a de um lugar onde se realizam trabalhos infrutíferos. Sísifo foi um dos mortais mais astutos e rebeldes contra os deuses. Ele conseguiu enganar e aprisionar até a morte, mas teve uma punição severa: foi condenado a rolar uma enorme pedra de mármore com suas mãos até o cume de uma montanha. Sempre que ele estava quase conseguindo cumprir a sua tarefa a pedra rolava para a base da montanha impulsionada por meio de uma força irresistível e o trabalho começava de novo. Não pode existir alegoria mais significativa para o trabalho alienado.

Devemos sempre tentar combater esta alienação no nosso trabalho. Se você é gerente, mostre aos seus funcionários como eles contribuirão para a sua estratégia gerencial; se você levanta requisitos explique para o seu analista projetista quais as expectativas do seu cliente; se você é analista projetista converse com o seu desenvolvedor sobre como o desenvolvimento está contextualizado dentro do sistema. Faça também o caminho inverso: cobre este tipo de posicionamento do seu gerente, do seu analista, etc. É este envolvimento que vai fazer com que o seu trabalho seja diferente do trabalho de Sísifo. O fim da alienação não quer dizer que você vai deixar de carregar pedras todo dia, a grande diferença é que Sísifo as carregava e não produzia nada e você vai produzir.

Agora retornando ao que motivou o post passado e este: a apropriação dos meios de produção na informática. A minha crítica não foi ao modelo capitalista ou a apropriação dos meios de produção. A minha crítica foi direcionada à apropriação dos meios de produção na informática com a definição de processos com uma visão industrial. A apropriação dos meios de produção é um fundamento do sistema capitalista. Em uma visão simplificada seria o diferencial que a empresa apresenta sobre o seu contingente de funcionários. É algo que a empresa oferece que o grupo de pessoas que trabalham para ela não pode oferecer se trabalhassem por conta própria. Bom, aí entra o desafio: como o Google apropria os meios de produção? O que o Google oferece que é mais do que simplesmente a soma das pessoas que trabalham para ele?

Bem, eu não conheço ninguém que trabalhe lá, então não dá para perguntar para os funcionários. Mas isto não é o mais relevante. Acho que dá pra ir pelo que ele vende junto com a sua marca e pela forma como ele se vende para a imprensa. Em nenhuma das duas fontes você encontra alguma referência a processos garantidores de qualidade, modelos de qualidade, etc.; o que já serve de base para concluir que não é pelo caminho dos processos com visão industrial. Mas por outro lado o ambiente de trabalho é sempre propagandeado como muito livre e incentivador da criatividade; e é nesta linha que vai o meu palpite. Eu acho que o Google apropria os meios de produção vendendo a idéia de que ele criou um ambiente de trabalho tão bom que vai atrair os melhores cérebros e que, somente em um ambiente como esse, eles vão poder exercer todo o seu potencial criativo.

Imaginando que você é um excelente profissional, onde você gostaria de trabalhar? Em um lugar onde os processos "garantem" a qualidade e o seu trabalho pode ser facilmente substituído? Ou em um lugar onde as condições para que o seu trabalho seja bem realizado sejam maximizadas? E você acha que as empresas que tem CMMI nível 5 são capazes de produzir os softwares que o Google produz?

CMMI e a Apropriação dos Meios de Produção

Por que, no mundo da informática, tudo que gira em torno de processos tem ganhado uma força tão grande nos últimos tempos? Por que o CMMI tem sido visto como algo que pode tirar as empresas, segundo o próprio CMMI diz, do caos?

Uma das explicações possíveis é que o CMMI tem um valor em si, ou seja, ter o certificado vai ajudar a empresa a conquistar clientes e ganhar concorrências públicas. Isto já justificaria, para a diretoria de qualquer empresa média ou grande, o esforço e o custo para tirar o certificado. Mas uma explicação como esta seria muito simples e eu penso que a coisa não é tão simples assim.

Eu acho que a principal razão está em um dos fundamentos do sistema capitalista: a apropriação dos meios de produção. Apropriar os meios de produção é ter controle sobre o que é necessário para que se produza algo. É como ser o dono da bola! Se as pessoas não seguirem as suas regras ninguém joga! Em uma indústria é ser o dono das instalações físicas, máquinas e processos de produção. Quanto mais eficiente a empresa for em apropriar os meios de produção menos importante o empregado vai ser. Por que valorizar um tipo de trabalho que pode ser executado por qualquer pessoa? Isto garante que a empresa possa aumentar a diferença entre o que ela recebe pelo produto e o que os empregados recebem para produzí-lo. Resumindo: é a apropriação dos meios de produção que justifica os lucros no sistema capitalista, garantindo que a qualidade do produto não dependa de quem o produz.

As empresas de informática não são diferentes, elas têm que apropriar os meios de produção para justificarem os seus lucros. E, dentre elas, as fábricas de software são as que têm maior dificuldade para se justificarem. Elas não têm know how em nenhuma área de negócio específica. Então por que pagar muito para uma empresa que não agrega nada além do trabalho dos seus funcionários? E já que ela não está agregando nada, por que não contratar diretamente as pessoas? Ou seja, qual a justificativa para o lucro se a empresa não apropriou os meios de produção?

Aí entra o CMMI, ele é a grande justificativa destas fábricas de software. O que ele vende é que com a definição de um modelo de maturidade de processos a qualidade vai passar a ser propriedade das empresas e não dos seus funcionários. Com ele as fábricas vão ficar mais confortáveis para cobrar muito, pagar pouco e o mercado vai engolir isto. Com o CMMI as empresas vendem a idéia que apropriaram os meios de produção de software e podem justificar lucros cada vez maiores. Os clientes não vão mais fazer questionamentos do tipo: "A baixa qualificação das pessoas que vão trabalhar no meu projeto não vai afetar a qualidade?" ou "A sua alta rotatividade de mão de obra não vai afetar a qualidade?". E, mesmo se os fizerem, vão ouvir uma resposta padrão:"Não se preocupe nós somos CMMI nível x. A qualidade está garantida pelos nossos processos!".

O que não está sendo levado em conta na adoção deste modelo são os problemas que a sua implantação gera. Alguns já são problemas clássicos da produção industrial tradicional e outros são decorrentes da sua aplicação na produção de software. Dentre os problemas clássicos podemos destacar a alienação do trabalho e dentre os específicos da informática a perda de qualidade.

É o trabalho que diferencia o ser humano dos outros animais, somos o que somos pela nossa capacidade de transformar o meio que nos cerca. É isto que nos realiza e não é por acaso que as grandes civilizações sempre realizam grandes obras, das pirâmides do Egito às torres gêmeas do World Trade Center, tudo isto para mostrar a força do seu trabalho. Quem não sente prazer ao realizar algo que considera interessante? Por isto quando trabalhamos no modelo industrial no qual o nosso trabalho é dividido, nós perdemos a visão do todo e passamos a ter a impressão de que o nosso trabalho não transforma nada, não serve para nada! O reflexo disto é um altíssimo nível de insatisfação e consequentemente alta rotatividade. O trabalho no sistema industrial passa a ser uma obrigação, sem realização pessoal e prazer; é simplesmente trabalho alienado, substituível e sem importância!

Apesar da alienação no trabalho a produção industrial é muito eficaz porque, mesmo com a insatisfação dos trabalhadores, a apropriação dos meios de produção garante a qualidade. Já na informática a qualidade não pode ser atingida simplesmente com a adoção de processos, porque o grau de subjetividade das atividades é muito grande em comparação com uma indústria tradicional. Por exemplo, em uma montadora de automóveis é possível definir um processo para pintura de um carro que vá conter exatamente a lista de atividades que o empregado deve fazer, mas eu pago para ver um processo de criação de modelo de entidades e relacionamentos (para citar um artefato bem simples) que tenha uma lista de atividades que o empregado vai seguir que gerará um modelo com qualidade. As empresas que adotarem este modelo vão ficar no pior dos mundos porque a rotatividade vai aumentar, os melhores profissionais vão sair e os processos não vão conseguir garantir a qualidade.

Em resumo: é impossível, hoje, apropriar os meios de produção na informática com uma visão industrial de processos porque os processos na informática têm um grau de subjetividade que impede a sua divisão em tarefas simples e objetivas. Além disto esta visão industrial de processos é incompatível com valorização da mão de obra. Você não pode investir em processos indutriais e em mão de obra, você investe em processos industriais para não investir em mão de obra. E, na falta desta, a qualidade não pode ser atingida. Por isto o software ainda depende da habilidade e experiência de um bom profissional. Felizmente produzir software ainda não é como apertar parafusos em um linha de montagem!