CMMI no olho dos outros é refresco
Publicado em: 27/03/2007
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ó.