Process Improvement - To PI or not To PI

O CMMI e o refresco tem gerado polêmicas e uma boa discussão, que quando levada a sério, pode ajudar a muitas pessoas a formar suas próprias opiniões, assim publicamos uma resposta ao artigo do Mateus Velloso a nós enviada por Roberto Slomka.

por Roberto Slomka

Gostaria de tecer alguns comentários à guisa de resposta ao artigo de Mateus Velloso publicado no "Linha de Código". Com todo respeito à pessoa do autor, creio que o artigo já começa mal com o seu "Não gosto do CMMI. Pronto.", meio pueril, pouco consistente enquanto argumento. Avaliando o perfil publicado junto com o artigo a coisa fica mais clara: o autor tem um perfil fortemente técnico (nenhum demérito nisso). Desde que eu era um jovem programador, não interessa há quantos anos atrás, profissionais de TI não gostam de nada além de código. Querer que gostem do CMMI é utopia.

O autor comete alguns equivocos no artigo como acreditar que o CMMI tem como inspiração o Taylorismo, quando seria muito mais correto associar o modelo com as técnicas de gestão da qualidade surgidas no pós-guerra principalmente sobre as idéias de Deming, "criador" do clássico ciclo PDCA - Plan/Do/Check/Act (Planejar/Fazer/Verificar/Atuar). Se o Taylorismo não funcionou tão bem, na visão do autor, fato de que discordo se for colocado sob o contexto da época em que surgiu, as idéias de Deming ajudaram a fazer do Japão a potência que é hoje, resultado que não pode ser desprezado.

Além disso, "não gosto de CMMI" soa como "não gosto de conselho". Qual prática do CMMI exatamente o autor execra? Seria desnecessário gerenciar requisitos? Projetos não necessitam de planejamento e acompanhamento? Esse negócio de gestão de configuração é besteira? Da forma como está colocado, um leigo pode achar que CMMI é uma panacéia genérica para ser usada como um pó-de-pirlimpimpim que irá transformar seus projetos em casos de sucesso. Alto lá! Seria interessante o autor esclarecer o que no CMMI ele considera estar errado. Me parece que o artigo se limita a bradar "sou contra" como uma forma de rebeldia juvenil.

O artigo não é de todo equivocado: é fato sabido e notório que muitas organizações escrevem processos mastodônticos baseados numa visão distorcida do modelo. É comum ouvir de "lead appraisers" a constatação de que certos processos exageram na interpretação do modelo. Resultado: "burrocracia" ao invés de melhoria de processo. Constatar isso, como citado na definição pela wikipedia é somente constatar a impertinência de alguns processos escritos por quem não entendeu bem o modelo. A existência de vinhos de péssima qualidade não desqualifica toda a arte da enologia.

Mas voltando ao artigo do Mateus, citar uma experiência de projeto bem sucedida sem CMMI para justificar a sua inutilidade é um tanto quanto forçado. Quando o artigo cita os PostIt do tal gestor não deixo de enxergar as práticas de gestão, atribuição de responsabilidades e acompanhamento preconizadas pelo modelo, que não apontam necessariamente para esta ou aquela forma de atingir o objetivo, quando cita as reuniões matinais está relatando a prática da verificação defendida no modelo. Longe de ser "ridículo e irresponsável", o fulano do PostIt está seguindo à risca o CMMI-ML2 e não sabe!! Talvez então o modelo não seja tão inválido assim...

Por outro lado eu poderia citar uma centena de projetos que fracassaram porque não foram bem geridos, ou porque perdeu-se a noção do escopo, ou porque os requisitos não estavam documentados e consistentes, ou porque os testes não foram suficientes para garantir a corretude do produto, ou porque riscos não foram considerados, ou porque alterações vieram meses após o término do projeto e já não se lembravam bem os detalhes do mesmo, ou porque... etc etc etc.

O autor diz que a única certeza que se pode ter com o CMMI é que seus custos irão aumentar. De onde vem essa afirmação? Tem números para corroborar ou é só mais uma impressão? Será que grandes empresas de todo o mundo entrariam nessa "onda" somente por moda, sendo que os resultados certamente seriam custosos e inúteis (na visão do autor)? Este texto é curto para explicar a curva de custos de todo o ciclo de vida de um software, teria que escrever outro artigo somente com este foco, mas vamos pensar um pouco: implementação de processos de melhoria passa necessariamente pelo patrocínio da alta gestão das organizações. Este povo não está interessado em técnicas, modelos ou padrões, está interessado em três letrinhas: ROI - retorno sobre o investimento. Uma simples consulta ao site do SEI para verificar os ganhos de longo prazo com a adoção de processos enterraria a "certeza" que o autor tem sobre o CMMI. Insisto: é claro que isso depende da qualidade do processo a ser definido com base no modelo. Grandes crimes já foram cometidos sob as melhores das intenções. Aí sim mora o perigo.

Argumentar que processo não ajuda porque projetos são desenvolvidos por pessoas é ignorar a importância que o CMMI dá ao recurso humano. Ninguém lidera projetos, ninguém lidera tarefas, os gestores lideram pessoas, seja lá qual for o negócio da organização. Achar que o CMMI não considera o aspecto humano e vê-lo como prática puramente burocrática e documentacional é passar recibo de desconhecimento básico daquilo que se está criticando.

Tudo aquilo que Mateus diz acreditar em seu texto mostra bem a sua visão sobre o tema: máquinas podem realizar tarefas mais rapidamente, frameworks e geradores de código podem aumentar sua produtividade, linguagens robustas podem aumentar a segurança e confiabilidade do código mas não existe automação para o pensamento, para a inovação, para a compreensão daquilo que cliente espera que nós entreguemos. Afinal, não programamos pelo prazer de usar aquela tecnologia que adoramos, programamos para atender à necessidade de alguém, comumente chamado cliente.

Ora, falamos numa novidade: programadores não gostam do CMMI! E meus filhos pequenos não gostam de injeção!! Vale lembrar que o CMM - filme que deu origem a série - não surgiu da vontade dos desenvolvedores de software, mas de um check-list pedido pelo Departamento de Defesa norteamericano para avaliação de fornecedores para seus projetos. Ou seja, CMMI não nasceu da vontade de quem faz software, mas por uma exigência de quem os compra. Meus filhos jamais tomariam a injeção por vontade própria, é a obrigação da vacina que se impõe a eles.

Perdi a conta de quantas vezes barganhei melhorias salariais por deter o conhecimento dos requisitos ou da engenharia de uma determinada solução. É claro que projetos podem ser bem sucedidos se baseados somente na experiência, competência e qualidade das pessoas que compõem a equipe, sem prescindir de uma pitada de sorte, claro. Mas estes projetos acabam reféns das pessoas que o desenvolveram, na maior parte das vezes, se não estão bem documentados e desenvolvidos segundo um processo repetível por qualquer outro profissional qualificado. Claro que nessas condições eu também não gostaria nem um pouco do CMMI.

Para terminar, procure quantas vezes aparece a palavra "código" (code) no texto do modelo e quantas vezes aparece a palavra "negócio" (business) e você terá uma noção do foco do CMMI. Economizo teu tempo: a palavra "negócio" aparece mais de 200 vezes, enquanto "código" não chega a 20 vezes, ou seja, um décimo daquela. Moral da história: CMMI não veio para ser querido pelos programadores - para isso existe "a melhor tecnologia de todos os tempos da última semana", seja ela qual for esta semana -, mas para ser um balisador de gestão do negócio de desenvolvimento de software. Afinal, desenvolver software não tem como finalidade afagar o ego criador de nós desenvolvedores: é um negócio !!

Abraços,
Roberto Slomka
Analista de Sistemas
Consultor de Melhoria de Processos
Implementador MPS-Br