Vou começar já arrumando encrenca: Não gosto do CMMI. Pronto.

É isso mesmo, não gosto. Tem gente que não gosta de VB, tem quem não goste de praia, tem quem não goste do Flamengo, e eu não gosto do CMMI, qual o problema?

Depois que li um livro muito interessante chamado “Freakonomics”, percebi como pode ser perigoso esse negócio chamado “senso comum”. E esse é meu principal argumento contra o CMMI.

Como assim? Bom, primeiro vale explicar o que é o senso comum:

Senso comum é algo que a maioria das pessoas acredita, faz muito sentido numa primeira análise, da até uma sensação de bem-estar acreditar naquilo, mas que muitas vezes acaba se mostrando não ser totalmente ou mesmo nem parcialmente verdade.

Ta, mas e daí? E o CMMI?

Vou então contar um caso e depois volto nele. Esse caso aconteceu comigo tem algumas semanas, acompanhe comigo:

Fui chamado a uma reunião com diversos arquitetos, desenvolvedores e gerentes de projeto, com o objetivo de assistir a uma palestra de um gerente de projeto da nossa empresa que conseguiu tocar com sucesso um projeto de dois anos, com uma grande equipe, desenvolvendo uma aplicação bastante heterogênea e complexa. O objetivo era podermos aprender com as melhores práticas que eles usaram.

Sala cheia de gente, todo mundo cheio de perguntas a fazer, inclusive eu, e chega o tal gerente, que calmamente prepara o projetor e começa a contar sobre a complexidade do sistema que eles criaram. Era realmente um projeto que tinha tudo para dar errado, risco altíssimo.

E eu ficava pensando comigo: Nossa... Esse cara deve ser um guru de gerenciamento de projetos, deve saber tudo sobre metodologias, processos, PMBOK, CMMI, RUP, sei lá mais o que, me da até vergonha de fazer pergunta boba.

Antes que eu pudesse perguntar qualquer coisa, outro membro da equipe foi mais rápido:

- Qual ferramenta de gerenciamento de projeto vocês usaram?

E ele, calmamente, respondeu:

- Nós preferimos desenvolver nossa própria ferramenta.

E nesse momento, pode-se ouvir um sonoro “What??” de todos ali presentes. Pensei comigo: Que guru que nada, esse cara é Deus. Deve ter desenvolvido uma super ferramenta por ter se sentido limitado com relação às outras do mercado.

E ele continou:

- Isso mesmo, criamos a nossa. Querem ver? Tenho aqui alguns slides dela.

E trocou para um slide com uma foto da janela da sala dele, cheia de post-its colados nela. E continuou:

- Apresento nossa ferramenta de gerenciamento e acompanhamento de projeto.

Após alguns minutos de gargalhadas gerais, ele continuou as explicações sobre a tal ferramenta, e aos poucos fomos percebendo que aquilo não era uma piada: Ele realmente tinha gerenciado um projeto de dois anos, para uma grande companhia aérea, com diversos riscos tecnológicos, de prazo e escopo com seus post-its colados na janela.

A idéia era muito simples: Cada cor representava um membro da equipe. Como não tinha tantas opções de cor de post-its, ele agrupava por equipe para facilitar a visualização. Cada post-it representava uma tarefa, então tinha o nome da tarefa e a quantidade de horas para terminar, e cada janela representava uma semana. Então ele olhava para a janela da semana atual e podia dizer quais as tarefas para aquela semana, quem estava cuidando de que, e quanto faltava para terminar. Quando algo precisava ser atualizado/modificado eles rabiscavam os post-its, trocavam de posições, ou mesmo colavam novos por cima dos velhos.

Todo dia, pela manhã, eles faziam uma reunião rápida onde cada membro da equipe falava o que tinha feito ontem e o que tinha para fazer naquele dia. Isso era importantíssimo, porque assim todos davam notícia do projeto como um todo e por terem visões diferentes, muitas vezes descobriam erros antes mesmo deles serem implementados e mudavam o curso das coisas.

Calmamente, ele foi continuando as explicações. Disse que todo dia um membro da equipe cuidava dos problemas mais críticos que eles encontravam pelo caminho. Daí, ele mostra uma foto do sujeito cuidando desses  problemas. Só que na foto o rapaz estava usando um chapéu de pirata enquanto trabalhava!

Risos de novo. Agora sim, isso é piada!

Mas não era piada não. Usar o chapéu de pirata significava duas coisas:

1-Sim, eu estou a par dos problemas críticos e estou trabalhando para corrigi-los.

2-Não me perturbe, a menos que seja algo muito, muito sério.

Bom, não vou ficar aqui detalhando todas as coisas malucas que eles inventaram neste projeto, mas basta dizer que foi muito bem sucedido, dentro do prazo, dentro do orçamento e deixou o cliente satisfeitíssimo.

Isso basta para você? Para mim, basta.

Se você é um cara especialista em processos, fã do CMMI, provavelmente já está aí doido para vir aqui me dar uma surra, além de achar que isso tudo que o tal gerente de projetos fez é ridículo e irresponsável, que se o projeto foi bem sucedido, foi apenas sorte. Seu senso comum está dizendo: É impossível que um projeto termine bem sem um bom modelo de processos, todo mundo sabe disso!

Então deixe agora eu explicar o meu ponto de vista disso tudo:

Ao refletir sobre todos os projetos de desenvolvimento de software bem-sucedidos de que tenho notícia, percebi que eles usaram tecnologias diferentes, metodologias diferentes (isso quando usavam alguma), tiveram abordagens diferentes em todos os sentidos. Alguns, inclusive, aconteceram muito antes de qualquer um de nós ter sequer ouvido falar em CMMI.

Então o que fez esses projetos darem certo?

Eu só consigo lembrar uma coisa em comum em todos eles: Pessoas.

Pessoas competentes, com domínio de conhecimento na área em que atuavam, muito bom senso (que é diferente de senso comum) e trabalhando em equipe.

Enquanto o Brasil inventa leis todo dia para resolver problemas que nunca são resolvidos, só fazendo aumentar a nossa burocracia e criando uma quantidade impossível de regras que acaba levando as pessoas a não segui-las por completo (o que acaba gerando o fenômeno das leis que “pegam” e as leis que “não pegam”), eu não consigo evitar ver o CMMI da mesma forma. E eu não sou o único que pensa assim: “CMMI is often criticized for being overly bureaucratic and for pushing reliability over services provided” - Wikipédia. Aliás, se você quiser ver uma boa crítica a modelos burocráticos como esse, assista “Brazil, o Filme”.

Agora me ajude um pouco, responda a essas perguntas: (interessante que em espanhol, “responder” é “contestar”, que em português seria “manifestar-se contra”, mas aqui eu queria que você realmente se perguntasse seriamente e de mente aberta essas coisas)

- Se seus projetos estão sempre atrasando, você realmente acha que implantando um modelo de processo como prega o CMMI isso vai deixar de acontecer? Você analisou o motivo desses atrasos para saber se eles estão mesmo relacionados a processos?

- Se seus projetos estão caros e você está perdendo sua competitividade no mercado por causa disso, você realmente acredita que o CMMI vai barateá-los? Como?

- Se seus desenvolvedores têm dificuldade em lidar com a complexidade tecnológica com que atuam, por falta de treinamento ou mesmo de perfil, você realmente acredita que com processos que burocratizam seu desenvolvimento isso vai melhorar?

- De que adianta documentar tanto algo que tem grandes chances de mudar na semana que vem? Não lhe parece que a quantidade de artefatos não-código que você produz é diretamente proporcional à falta de flexibilidade, à lentidão e às chances de você ter documentos inconsistentes, não condizentes com a realidade?

- Qual a utilidade de fazer reuniões de “sessão-humilhação” para perguntar para todos por que suas tarefas estão atrasadas em relação ao cronograma original e os processos não estão sendo seguidos? O que sinceramente você espera ouvir como resposta? Será que as pessoas é que estão erradas ou você é que está sendo incompetente em definir processos possíveis e gerenciáveis? Qual a chance desses atrasos deixarem de acontecer só por causa desse tipo de reunião? O que você acha que isso vai causar no ambiente (pessoas) da sua empresa ao longo do tempo?