CMMI no olho dos outros refresco

Vou comear j arrumando encrenca: No gosto do CMMI. Pronto.

isso mesmo, no gosto. Tem gente que no gosta de VB, tem quem no goste de praia, tem quem
no goste do Flamengo, e eu no gosto do CMMI, qual o problema?
Depois que li um livro muito interessante chamado Freakonomics, percebi como pode ser
perigoso esse negcio 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 anlise,
da at uma sensao de bem-estar acreditar naquilo, mas que muitas vezes acaba se mostrando no
ser totalmente ou mesmo nem parcialmente verdade.
Ta, mas e da? E o CMMI?
Vou ento contar um caso e depois volto nele. Esse caso aconteceu comigo tem algumas semanas,
acompanhe comigo:
Fui chamado a uma reunio 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 aplicao
bastante heterognea e complexa. O objetivo era podermos aprender com as melhores prticas 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 comea a contar sobre a complexidade do sistema que eles
criaram. Era realmente um projeto que tinha tudo para dar errado, risco altssimo.
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 rpido:
- Qual ferramenta de gerenciamento de projeto vocs usaram?
E ele, calmamente, respondeu:
- Ns preferimos desenvolver nossa prpria 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 relao 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.
Aps alguns minutos de gargalhadas gerais, ele continuou as explicaes sobre a tal ferramenta, e
aos poucos fomos percebendo que aquilo no era uma piada: Ele realmente tinha gerenciado um
projeto de dois anos, para uma grande companhia area, com diversos riscos tecnolgicos, de prazo
e escopo com seus post-its colados na janela.
A idia era muito simples: Cada cor representava um membro da equipe. Como no tinha tantas
opes de cor de post-its, ele agrupava por equipe para facilitar a visualizao. Cada post-it
representava uma tarefa, ento tinha o nome da tarefa e a quantidade de horas para terminar, e cada
janela representava uma semana. Ento 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 posies,
ou mesmo colavam novos por cima dos velhos.
Todo dia, pela manh, eles faziam uma reunio rpida onde cada membro da equipe falava o que
tinha feito ontem e o que tinha para fazer naquele dia. Isso era importantssimo, porque assim todos
davam notcia do projeto como um todo e por terem vises diferentes, muitas vezes descobriam
erros antes mesmo deles serem implementados e mudavam o curso das coisas.
Calmamente, ele foi continuando as explicaes. Disse que todo dia um membro da equipe cuidava
dos problemas mais crticos que eles encontravam pelo caminho. Da, ele mostra uma foto do
sujeito cuidando desses problemas. S que na foto o rapaz estava usando um chapu de pirata
enquanto trabalhava!
Risos de novo. Agora sim, isso piada!
Mas no era piada no. Usar o chapu de pirata significava duas coisas:
1-Sim, eu estou a par dos problemas crticos e estou trabalhando para corrigi-los.
2-No me perturbe, a menos que seja algo muito, muito srio.
Bom, no 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 oramento e deixou o cliente
satisfeitssimo.
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, alm de achar que isso tudo que o tal gerente de projetos fez ridculo e
irresponsvel, que se o projeto foi bem sucedido, foi apenas sorte. Seu senso comum est dizendo:
impossvel que um projeto termine bem sem um bom modelo de processos, todo mundo sabe
disso!
Ento 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
notcia, 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 ns ter sequer ouvido falar em CMMI.
Ento o que fez esses projetos darem certo?
Eu s consigo lembrar uma coisa em comum em todos eles: Pessoas.
Pessoas competentes, com domnio 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 so resolvidos, s
fazendo aumentar a nossa burocracia e criando uma quantidade impossvel de regras que acaba
levando as pessoas a no segui-las por completo (o que acaba gerando o fenmeno das leis que
pegam e as leis que no pegam), eu no consigo evitar ver o CMMI da mesma forma. E eu no
sou o nico que pensa assim: CMMI is often criticized for being overly bureaucratic and for
pushing reliability over services provided - Wikipdia. Alis, se voc quiser ver uma boa crtica a
modelos burocrticos como esse, assista Brazil, o Filme.
Agora me ajude um pouco, responda a essas perguntas: (interessante que em espanhol, responder
contestar, que em portugus seria manifestar-se contra, mas aqui eu queria que voc
realmente se perguntasse seriamente e de mente aberta essas coisas)
- Se seus projetos esto 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 esto mesmo relacionados a processos?
- Se seus projetos esto 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 tm dificuldade em lidar com a complexidade tecnolgica 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?
No lhe parece que a quantidade de artefatos no-cdigo que voc produz diretamente
proporcional falta de flexibilidade, lentido e s chances de voc ter documentos inconsistentes,
no condizentes com a realidade?
- Qual a utilidade de fazer reunies de sesso-humilhao para perguntar para todos por que suas
tarefas esto atrasadas em relao ao cronograma original e os processos no esto sendo seguidos?
O que sinceramente voc espera ouvir como resposta? Ser que as pessoas que esto erradas ou
voc que est sendo incompetente em definir processos possveis e gerenciveis? Qual a chance
desses atrasos deixarem de acontecer s por causa desse tipo de reunio? 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 cdigo com muitos bugs, criar uma rea de testes no
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 nmeros 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 soluo mgica para os problemas de uma fbrica 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 viso mecanicista de que se pode dividir em pedaos, controlar, monitorar,
padronizar e aprimorar o trabalho humano seguindo risca processos formais, produzindo de forma
homognea, j foi tentada no passado (estou falando do Taylorismo e da administrao cientfica)
com resultados, no mnimo, questionveis. Se voc quiser ter uma idia da essncia do que era o
Taylorismo, assista Tempos Modernos, de Charles Chaplin, que at hoje ainda um filmo.
A administrao cientfica era fundamentada em: Planejamento, preparao dos trabalhadores,
controle e execuo (no parece familiar? Olha o CMMI velho de guerra a).
A preparao dos trabalhadores pressupe o estudo dos tempos e movimentos, que visa iseno de
movimentos inteis (movimento intil o seguinte: Se no meio do trabalho voc interrompe suas
atividades para coar o nariz, isso movimento intil, a empresa est perdendo dinheiro e voc est
sendo improdutivo). Isso para mim CMMI nveis 4 e 5 (gerenciado quantitativamente e
otimizado). Acontece que esse modelo de administrao j foi estudado, criticado, melhorado e
depois surgiram novas correntes que tambm foram estudadas, criticadas e melhoradas. Estamos
falando de 1903 at 2007, tem muito cho a. E uma das coisas bvias que se pode concluir do
trabalho de Taylor, que ele peca por ignorar as vrias variveis humanas em um processo
produtivo. Nem o melhor pianista do mundo capaz de tocar duas vezes exatamente da mesma
forma uma pea musical, imagina querer que isso se aplique a uma empresa de servios de grande
porte.
O erro dessa viso mecanicista a banalizao da complexidade de um ambiente de produo:
querer que as pessoas se comportem como mquinas. Alis, depois de ver a Ferrari do Felipe Massa
quebrar no GP da Austrlia, eu comeo a me questionar se at para as melhores mquinas a gente
pode querer esse tipo de homogeneidade, previsibilidade e consistncia.
Ento se voc achou ridculo o chapu de pirata e os post-its na janela, eu aposto que voc sequer
levou em considerao que os desenvolvedores, DBAs, analistas e todos daquela equipe so seres
humanos e estavam lidando com um prazo impossvel, um escopo impossvel, com vrios 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 esprito de companheirismo na equipe. E isso para mim vale mais do
que processo, documento ou carimbo.
Se voc no levou esse fator em conta antes de fazer um julgamento desse caso, cuidado! Talvez
voc esteja julgando e concluindo coisas importantes sem a devida viso sistmica de todos os
fatores envolvidos. E olha que eu nem mencionei a cervejinha liberada toda sexta depois do almoo
que eles tinham por l.
J vi projeto sem documentao dar certo. J vi projeto sem testes, sem escopo, sem muita coisa dar
certo, contra todas as apostas (inclusive a minha). Obviamente no foram todos. Mas nunca, nunca
mesmo, vi projeto com equipe desqualificada, com gerentes que tratam funcionrios como
mquinas, 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 opinio: A nica certeza que voc
tem quanto ao CMMI que ele vai aumentar seus custos. O resto so apostas que voc faz que
podem ou no dar certo, dependendo de um nmero enorme de variveis. Da voc tem que se
perguntar: Qual meu modelo de negcio? Que tipo de clientes estou querendo? Ser que eles vo
me preferir, mesmo com custos superiores, ou ser que eles vo contratar o Z da esquina e seus
trs filhos porque eles fazem por 1/3 do preo? (Depois vou dar um puxo de orelha nos clientes

tambm, agenta a)
Eu, alis, deixei de usar a oficina autorizada para fazer reviso do meu carro no Seu Valdir, um
mecnico na esquina da rua de casa. Isso porque o Valdir - que me conhece pelo meu primeiro nome
- me liga para falar que descobriu que no precisa trocar a repimboca da parafuseta e me explica
detalhadamente o motivo, enquanto eu que no entendo lhufas do que ele est dizendo, fico feliz em
ver a dedicao dele em me manter informado e resolver o meu problema da melhor forma possvel,
enquanto que na autorizada eu tenho que falar com o Call Center que vai estar encaminhando
minha dvida para o tcnico responsvel que vai estar solucionando o problema em questo e que
vai estar me retornando em no mximo 24 horas. Nem!
Cuidado ao correlacionar CMMI com aumento nas vendas, a menos que voc esteja atuando em
licitaes onde isso realmente seja um requisito essencial.
Agora que eu j joguei muita pedra falando daquilo que eu no acredito, quero falar do que
acredito, assim voc que est lendo pode jogar pedra em mim tambm:
- Eu acredito em processos sim, mas naqueles que so automatizados. As mquinas que cuidem
deles.
- Acredito em usar Frameworks que possibilitem voc programar metade, 1/3, 1/10 do que
programaria normalmente, tirando a repetio mecnica e deixando a mente humana para cuidar
daquilo que realmente s ela sabe fazer.
- Acredito em ferramentas de build e deployment automtico (veja MSBuild, NAnt,
CruiseControl.Net).
- Acredito em geradores de cdigo (veja CodeSmith, MyGeneration, IronSpeed e outros) para
reduzir o trabalho braal.
- 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 segurana (veja o watchfire
appScan), ferramentas de validao do cdigo (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 mtodo do seu cdigo executou e quanto tempo levou) para detectar e melhorar os
problemas de performance.
- Acredito na evoluo das linguagens de desenvolvimento para que suportem contratos (veja o
spec# da Microsoft) que aumentam a robustez do cdigo.
- Acredito em fazer intervenes em servidor de produo apenas por meio de scripts (VBS ou de
preferncia Powershell, veja um exemplo de como usar o Powershell para deployment) ou pacotes
automatizados (veja WIX), assim voc consegue replicar as mesmas alteraes em qualquer
servidor depois, em segundos. Para que roteiro de instalao se seu roteiro legvel pela prpria
mquina?
- Acredito em processo de desenvolvimento com zero artefatos no cdigo, por meio de
ferramentas grficas/cdigo, como WF, SDM, DSL e DTS/SSIS, entre outros.
- Acredito que se voc sabe que tal funo no pode levar mais de 10 segundos para executar, que

tais sistemas precisam estar funcionando sempre, que tal regra de negcio no 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 esto mesmo funcionando como
especificado. Isso vale mais que documentos de mil linhas que ns dois sabemos que ningum vai
ter pacincia de ler detalhadamente.
Isso tudo processo sim, mas automatizado, onde voc aperta um boto 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 documentao nenhuma nem
processo nenhum, examina tudo como um bom e velho mdico de famlia 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 qualificao, conseguindo
maior competitividade no mercado (olha a administrao cientfica e o estudo de tempos e
movimentos de novo... Ser que estamos passando pela revoluo industrial da informtica e
estamos condenados a cometer os mesmos erros que foram cometidos l? Ser que a seqncia de
acontecimentos repetir mais um ciclo, do homem-mquina ao crash econmico de 29?), eu s
consigo ver empresas crescendo graas 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 funcionrios
sumirem to facilmente se voc mand-lo embora para cortar custos. No por m f, mas porque
no fundo, no fundo, seus clientes no esto 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 preo mais baixo, mesmo quando esse preo obviamente irracional, no
reclame que seu ambiente de TI seja um desastre. Se algum tentasse me vender uma BMW 0 km
por R$ 600,00 eu no compraria, porque obviamente tem algum trambique a. Ento por que voc
insiste em ser o pato ao contratar sistemas dessa forma? Deixe de ser bobo! Pea detalhes,
investigue, interrogue se for preciso! E principalmente: Questione sobre a qualificao 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 certificao, o atendimento foi bom? Pois eu j fui atendido
pessimamente por empresas com essa certificao, 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: No vejo problema nenhum, nem no CMMI nem em nenhuma outra
abordagem parecida, contanto que se tenha em mente tudo que mencionei acima. Alis, o CMMI
pressupe People with skills, training and motivation (mas no fala como diabos voc vai
conseguir manter as pessoas motivadas com essa montanha interminvel de regras, a os gerentes
comeam com os prmios financeiros, igualzinho a turma do Taylor defendia. Depois veio o
Abraham Maslow que mostrou que motivao muito mais complicada que isso). Isso, alis, faz o
maior sentido, j que o CMMI te diz o que voc tem que ter, mas no como conseguir, ento

novamente a essncia do sucesso do CMMI no est baseada no processo, e sim as pessoas. Ento
qualquer bom resultado obtido com o CMMI no pode ser creditado a processos exclusivamente. E
a vem o grande erro dos fanticos por CMMI, porque geralmente eles se esquecem desse detalhe.
Ao ler sobre o CMMI nvel 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 servios obter sucesso que no seja
por causa de pessoas competentes?
E se esse texto longo foi difcil de ler at o final, imagina ento aqueles seus documentos de
especificao de casos de testes, diagramas de fluxo, requisitos funcionais, no funcionais, viso
escopo, memria de reunio, planilha de horas... que nem so to divertidos?
Tenha d.
Mateus Velloso
Mateus Velloso - MVP de Visual Developer - Solutions Architect
Bacharel em administrao de empresas, ex-scio e consultor em tecnologia da Flag Intelliwan,
atualmente atua como Principal Software Architect na Telecom New Zealand, possui tambm as
certificaes: MCP, MCSA, MCAD, MCSD, MCSE, MCDBA, MCT, MCTS SQL 2005, OCP,
SCJP e SAP Business One Consultant. Atua em projetos de tecnologia, construo de frameworks
de desenvolvimento e tambm na rea de automao industrial.
Read
more:
http://www.linhadecodigo.com.br/artigo/1262/cmmi-no-olho-dos-outros-erefresco.aspx#ixzz3Fl7xmD9d