CMMI no olho dos outros é refresco

Leia esse texto onde o autor aborda seu ponto de vista sobre o CMMI e a gerência de projetos.

por Mateus Velloso

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?

Pense comigo: Se sua equipe está produzindo código com muitos bugs, criar uma área de testes não vai fazer esses bugs deixarem de ser produzidos. O único efeito que vai realmente acontecer é que agora você vai gastar 10% de desenvolvimento, 50% testando e corrigindo o que foi mal desenvolvido e 40% gerenciando todo o processo, tudo bem controladinho com números bonitinhos para que você possa analisar de mil maneiras diferentes como você está perdendo dinheiro.

E sabe por que isso acontece? Acontece porque muitas pessoas que pensam no CMMI ou em qualquer modelo de processos como solução mágica para os problemas de uma fábrica de software, se esquecem de analisar as reais causas dos problemas que ocorrem ali (que podem, inclusive, ser a falta de processos bem definidos).

O CMMI e essa visão mecanicista de que se pode dividir em pedaços, controlar, monitorar, padronizar e aprimorar o trabalho humano seguindo à risca processos formais, produzindo de forma homogênea, já foi tentada no passado (estou falando do Taylorismo e da administração científica) com resultados, no mínimo, questionáveis. Se você quiser ter uma idéia da essência do que era o Taylorismo, assista “Tempos Modernos”, de Charles Chaplin, que até hoje ainda é um filmão.

A administração científica era fundamentada em: Planejamento, preparação dos trabalhadores, controle e execução (não parece familiar? Olha o CMMI velho de guerra aí).

A preparação dos trabalhadores pressupõe o estudo dos tempos e movimentos, que visa à isenção de “movimentos inúteis” (movimento inútil é o seguinte: Se no meio do trabalho você interrompe suas atividades para coçar o nariz, isso é movimento inútil, a empresa está perdendo dinheiro e você está sendo improdutivo). Isso para mim é CMMI níveis 4 e 5 (gerenciado quantitativamente e otimizado). Acontece que esse modelo de administração já foi estudado, criticado, melhorado e depois surgiram novas correntes que também foram estudadas, criticadas e melhoradas. Estamos falando de 1903 até 2007, tem muito chão aí. E uma das coisas óbvias que se pode concluir do trabalho de Taylor, é que ele peca por ignorar as várias variáveis humanas em um processo produtivo. Nem o melhor pianista do mundo é capaz de tocar duas vezes exatamente da mesma forma uma peça musical, imagina querer que isso se aplique a uma empresa de serviços de grande porte.

O erro dessa visão mecanicista é a banalização da complexidade de um ambiente de produção: É querer que as pessoas se comportem como máquinas. Aliás, depois de ver a Ferrari do Felipe Massa quebrar no GP da Austrália, eu começo a me questionar se até para as melhores máquinas a gente pode querer esse tipo de homogeneidade, previsibilidade e consistência.

Então se você achou ridículo o chapéu de pirata e os post-its na janela, eu aposto que você sequer levou em consideração que os desenvolvedores, DBA’s, analistas e todos daquela equipe são seres humanos e estavam lidando com um prazo impossível, um escopo impossível, com vários fatores para contribuir com o stress e a falta de produtividade, e que coisas como essas ajudam pelo menos um pouco o bom humor e o espírito de companheirismo na equipe. E isso para mim vale mais do que processo, documento ou carimbo.

Se você não levou esse fator em conta antes de fazer um julgamento desse caso, cuidado! Talvez você esteja julgando e concluindo coisas importantes sem a devida visão sistêmica de todos os fatores envolvidos. E olha que eu nem mencionei a cervejinha liberada toda sexta depois do almoço que eles tinham por lá.

Já vi projeto sem documentação dar certo. Já vi projeto sem testes, sem escopo, sem muita coisa dar certo, contra todas as apostas (inclusive a minha). Obviamente não foram todos. Mas nunca, nunca mesmo, vi projeto com equipe desqualificada, com gerentes que tratam funcionários como máquinas, com burocracia em demasia dar certo, seja lá que modelo de processos fosse utilizado.

Eu perguntei o que esperar do CMMI, agora vou falar a minha opinião: A única certeza que você tem quanto ao CMMI é que ele vai aumentar seus custos. O resto são apostas que você faz que podem ou não dar certo, dependendo de um número enorme de variáveis. Daí você tem que se perguntar: Qual meu modelo de negócio? Que tipo de clientes estou querendo? Será que eles vão me preferir, mesmo com custos superiores, ou será que eles vão contratar o Zé da esquina e seus três filhos porque eles fazem por 1/3 do preço? (Depois vou dar um puxão de orelha nos clientes também, agüenta aí)

Eu, aliás, deixei de usar a oficina autorizada para fazer revisão do meu carro no Seu Valdir, um mecânico na esquina da rua de casa. Isso porque o Valdir - que me conhece pelo meu primeiro nome - me liga para falar que descobriu que não precisa trocar a repimboca da parafuseta e me explica detalhadamente o motivo, enquanto eu que não entendo lhufas do que ele está dizendo, fico feliz em ver a dedicação dele em me manter informado e resolver o meu problema da melhor forma possível, enquanto que na autorizada eu tenho que falar com o Call Center que “vai estar encaminhando” minha dúvida para o técnico responsável que “vai estar solucionando” o problema em questão e que “vai estar me retornando” em no máximo 24 horas. Nem!

Cuidado ao correlacionar CMMI com aumento nas vendas, a menos que você esteja atuando em licitações onde isso realmente seja um requisito essencial.

Agora que eu já joguei muita pedra falando daquilo que eu não acredito, quero falar do que acredito, assim você que está lendo pode jogar pedra em mim também:

- Eu acredito em processos sim, mas naqueles que são automatizados. As máquinas que cuidem deles.

- Acredito em usar Frameworks que possibilitem você programar metade, 1/3, 1/10 do que programaria normalmente, tirando a repetição mecânica e deixando a mente humana para cuidar daquilo que realmente só ela sabe fazer.

- Acredito em ferramentas de build e deployment automático (veja MSBuild, NAnt, CruiseControl.Net).

-Acredito em geradores de código (veja CodeSmith, MyGeneration, IronSpeed e outros) para reduzir o trabalho braçal.

- Acredito em testes automatizados, unit (veja Visual Studio Team System e NUnit), load testing (veja o Visual Studio Team System e o ANTS Load), testes de segurança (veja o watchfire appScan), ferramentas de validação do código (de novo o Visual Studio), testes de web services (veja Parasoft), etc.

- Acredito em ferramentas de profiling (veja o red-gate ANTS Profiler, onde você pode ver quantas vezes cada método do seu código executou e quanto tempo levou) para detectar e melhorar os problemas de performance.

- Acredito na evolução das linguagens de desenvolvimento para que suportem contratos (veja o spec# da Microsoft) que aumentam a robustez do código.

- Acredito em fazer intervenções em servidor de produção apenas por meio de scripts (VBS ou de preferência Powershell, veja um exemplo de como usar o Powershell para deployment) ou pacotes automatizados (veja WIX), assim você consegue replicar as mesmas alterações em qualquer servidor depois, em segundos. Para que roteiro de instalação se seu roteiro é legível pela própria máquina?

- Acredito em processo de desenvolvimento com “zero artefatos não código”, por meio de ferramentas gráficas/código, como WF, SDM, DSL e DTS/SSIS, entre outros.

-Acredito que se você sabe que tal função não pode levar mais de 10 segundos para executar, que tais sistemas precisam estar funcionando sempre, que tal regra de negócio não pode ser violada, melhor mesmo é escrever unit tests e outros scripts que automatizem os testes, assim você pode repeti-los sempre que mudar algo e garantir que as coisas estão mesmo funcionando como especificado. Isso vale mais que documentos de mil linhas que nós dois sabemos que ninguém vai ter paciência de ler detalhadamente.

Isso tudo é processo sim, mas automatizado, onde você aperta um botão e as coisas acontecem.

Mas ainda falando do que eu acredito: Eu acredito demais naquele sujeito que, quando seu servidor capota e seu sistema para de funcionar, ele chega, olha, e sem documentação nenhuma nem processo nenhum, examina tudo como um bom e velho médico de família e resolve o problema. Isso porque ele é bom no que faz.

E enquanto tiver gente que ache que com bons processos conseguirá manter o “custo” da equipe baixo, precisando de pessoas apenas para tarefas repetitivas, sem muita qualificação, conseguindo maior competitividade no mercado (olha a administração científica e o estudo de tempos e movimentos de novo... Será que estamos passando pela revolução industrial da informática e estamos condenados a cometer os mesmos erros que foram cometidos lá? Será que a seqüência de acontecimentos repetirá mais um ciclo, do homem-máquina ao crash econômico de 29?), eu só consigo ver empresas crescendo graças às pessoas, seja lá qual for o custo delas.

Você deve economizar com tudo, menos com o ingrediente essencial do seu sucesso. Esse você tem que tratar bem, mimar mesmo, porque ele é sua vitrine. Ele é que vai arrancar elogios do seu cliente, vai encantá-los, vai salvar sua pele mil vezes e vai fazer seus clientes e funcionários sumirem tão facilmente se você mandá-lo embora para cortar custos. Não por má fé, mas é porque no fundo, no fundo, seus clientes não estão nem aí para a sua marca, sua empresa ou mesmo você, o que eles gostam mesmo é de serem bem atendidos.

E quanto a você, senhor cliente (falei que ia puxar a orelha), enquanto você insistir em contratar sempre aquele que faz o preço mais baixo, mesmo quando esse preço é obviamente irracional, não reclame que seu ambiente de TI seja um desastre. Se alguém tentasse me vender uma BMW 0 km por R$ 600,00 eu não compraria, porque obviamente tem algum trambique aí. Então por que você insiste em ser o “pato” ao contratar sistemas dessa forma? Deixe de ser bobo! Peça detalhes, investigue, interrogue se for preciso! E principalmente: Questione sobre a qualificação da equipe que vai desenvolver seu sistema.

Você já foi atendido por alguma empresa com ISO 9000? E será que todas as vezes que você foi atendido por uma empresa com essa certificação, o atendimento foi bom? Pois eu já fui atendido pessimamente por empresas com essa certificação, sabe por quê?

Pessoas.

Lembre-se das pessoas, coloque um papel na parede da sua sala, se for preciso, e escreva: “Prometo que sempre vou me lembrar das pessoas”.

E agora, sendo justo: Não vejo problema nenhum, nem no CMMI nem em nenhuma outra abordagem parecida, contanto que se tenha em mente tudo que mencionei acima. Aliás, o CMMI pressupõe “People with skills, training and motivation” (mas não fala como diabos você vai conseguir manter as pessoas motivadas com essa montanha interminável de regras, aí os gerentes começam com os prêmios financeiros, igualzinho a turma do Taylor defendia. Depois veio o Abraham Maslow que mostrou que motivação é muito mais complicada que isso). Isso, aliás, faz o maior sentido, já que o CMMI te diz o que você tem que ter, mas não como conseguir, então novamente a essência do sucesso do CMMI não está baseada no processo, e sim as pessoas. Então qualquer bom resultado obtido com o CMMI não pode ser creditado a processos exclusivamente. E aí vem o grande erro dos fanáticos por CMMI, porque geralmente eles se esquecem desse “detalhe”.

Ao ler sobre o CMMI nível 1, encontrei um trecho interessante: “Success in these organizations depends on the competence and heroics of the people in the organization and not on the use of proven processes”. Agora me diga: Tem como uma empresa de serviços obter sucesso que não seja por causa de pessoas competentes?

E se esse texto longo foi difícil de ler até o final, imagina então aqueles seus documentos de especificação de casos de testes, diagramas de fluxo, requisitos funcionais, não funcionais, visão escopo, memória de reunião, planilha de horas... que nem são tão divertidos?

Tenha dó.