Mateus Velloso
velloso_mateus@hotmail.com
www.mateus.info
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 pra 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 pra 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.