quinta-feira, 19 de fevereiro de 2009

Desmistificando o MPS.BR – Introdução

MPS.BR é a sigla de Melhoria de Processos do Software Brasileiro. Mas o que é isso afinal de contas?
O MPS.BR é uma adaptação para as empresas brasileiras – em especial micro, pequenas e médias empresas – de um modelo de maturidade de processos de desenvolvimento de software conhecido internacionalmente como CMMI-DEV.
Muito se fala sobre esses modelos. Mas, após pesquisar exaustivamente sobre o assunto, cheguei a uma triste conclusão: praticamente tudo o que existe escrito sobre o assunto carece de clareza. Parece que os escritores sofrem de uma terrível síndrome que chamo de “diz-muito-sem-dizer-nada”. Inclusive, os próprios guias de implementação desses modelos parecem ter sido escritos por pessoas de outro planeta.
Revoltado com isso e indignado com a manada de consultores e empresas que estão deitando e rolando de ganhar dinheiro com isso, se aproveitando da inocência de profissionais bem intencionados, resolvi tentar desmistificar esse assunto. Como estou no Brasil, nada mais lógico do que começar pelo MPS.BR – vou deixar o CMMI-DEV para um segundo momento.
Pensei em escrever esse artigo de diversas formas e cheguei à conclusão que a melhor seria por meio de perguntas e respostas. Não que você já se tenha feito essas mesmas perguntas (o material disponível sobre o assunto é tão obscuro que muitos não chegam nem no nível da dúvida). Mas as perguntas nos ajudam a raciocinar e esclarecer o assunto.
Este primeiro artigo é apenas uma breve introdução sobre o MPS.BR de forma geral. No próximo artigo falarei especificamente sobre a implementação do Nível G – o primeiro – e dos processos de Gerenciamento de Projetos e de Requisitos. Boa leitura!
01. O que é o MPS.BR?
É um modelo de maturidade de processos relacionados com o desenvolvimento de software. Esse modelo foi adaptado de um outro modelo conhecido internacionalmente como CMMI-DEV para a realidade das empresas brasileiras. Isso foi necessário por que o CMMI-DEV prevê o amadurecimento dos processos em apenas 4 níveis. E, com o tempo, percebeu-se que a coisa tinha de funcionar de forma mais gradual e lenta aqui no Brasil. Daí quebraram os 4 níveis do CMMI-DEV em sete, que vão do G ao A, e fizeram uns pequenos ajustes.
02. O que é um modelo de maturidade de processos?
Toda empresa ou indivíduo que desenvolve software já faz isso por meio de algum processo. Esse processo pode ser caótico, obscuro e até mudar constantemente, mas não deixa de ser um processo. E isso nada mais é do que uma seqüência de atividades. Mesmo que você não se dê conta disto, tudo que você faz no trabalho de desenvolvimento de software segue uma seqüência de atividades. Às vezes essa seqüência não é fixa. Às vezes essa seqüência não segue uma ordem lógica. Às vezes essa seqüência provoca algum retrabalho. Mas perceba que sempre existirá uma seqüência. Às vezes essa seqüência já é eficiente, mas ninguém mais além de você sabe como funciona. Um modelo de maturidade de processos serve para corrigir esses e muitos outros problemas.
O MPS.BR descreve um modelo de amadurecimento gradual dos processos de desenvolvimento de software. Ou seja, você não precisar melhorar tudo de uma vez. Pode fazer isso aos poucos, de forma gradual. É para isso que servem os níveis de maturidade.
Vale ressaltar que o MPS.BR é apenas um modelo. Ninguém é obrigado a segui-lo a risca. Mas...dizem que ele é uma coletânea das melhores práticas relacionadas com o desenvolvimento de software. Assim, talvez valha a pena considerá-lo se não no todo, mas em parte. Entretanto, como ele é uma adaptação do CMMI-DEV, essas melhores práticas foram coletadas em outros mercados, talvez nos EUA e Europa. E isso pode por em dúvida a aplicabilidade dessas supostas melhores práticas a nós, brasileiros. Essa dúvida, porém, só o tempo poderá dirimir.
03. O que é um processo maduro?
Ótima pergunta! Dizer que um processo é, ou não, maduro pode gerar muita polêmica. Na minha opinião, um processo é maduro quando atinge os melhores resultados ao menor custo possível. Espero que concorde comigo nessa idéia (se não, é melhor você parar por aqui). Mas a dificuldade é justamente medir os resultados e o custo.
Portanto, para saber se um processo é ou não maduro, precisamos primeiro conseguir medi-lo. E é justamente esse o objetivo final do MPS.BR: conseguir medir os processos. Na teoria, uma empresa no Nível A do MPS.BR é capaz de medir plenamente seus processos de desenvolvimento de software. Em outras palavras, toda essa história de modelo de maturidade NÃO serve para tornar o processo realmente maduro, mas para saber se ele é ou não. Ao descobrir que um processo qualquer não é maduro, cabe à empresa encontrar formas de amadurecê-lo DE FATO. Mas não fique decepcionado com o MPS.BR. Na prática, as empresas já terão subsídios para amadurecer os processos desde o Nível F. Ou seja, não se precisa esperar até o Nível A para tomar alguma ação corretiva. Que ações a empresa precisa tomar? O MPS.BR não diz. Ainda bem!
E para que um processo possa ser medido e corrigido ele precisa ser transparente e gerenciável. Esse é o ponto mais importante do MPS.BR, por isso vou repetir: para esse modelo de maturidade de processos, um processo é maduro quando é transparente e gerenciável. Tudo o mais gira em torno disso. Se um processo não é transparente, então não pode ser medido. Se não pode ser medido, então não temos como saber se os seus resultados são os melhores possíveis ao menor custo. Se um processo não é gerenciável, mesmo que se possa medi-lo, então não se pode corrigi-lo, melhorá-lo. Se não podemos melhorá-lo, não podemos amadurecê-lo. Essa é a lógica da coisa toda.
04. Maduro para quem?
Maduro para todo mundo, ora bolas!, mas especialmente para os seus superiores hierárquicos. Lembre-se: quando vir a palavra maduro, pense em transparente e gerenciável. Transparente e gerenciável. Nunca esqueça isso.
05. Porque meu gerente está especialmente interessado nisso?
Lembra do transparente e gerenciável? Pois é. Se o processo é transparente, o seu gerente sabe exatamente o que você está fazendo ou deve fazer. Sabe se você está enrolando o serviço. Sabe se você precisa de ajuda para cumprir o prazo. Pode até conferir o que você já produziu. Se o processo é gerenciável, o seu gerente pode aproveitar o que você já produziu e te substituir por outra pessoa. Pode colocar mais alguém para te ajudar. E pode até pedir para você refazer algo antes que seja tarde demais.
Quando o processo é transparente, ele deixa de ser aquela caixa preta que ninguém além de você sabe como funciona. Quando o processo é transparente, fica mais fácil saber quais são os bons funcionários e quais não são. Um processo maduro depende menos dos indivíduos. Afinal, tem muita gente aí fora precisando de emprego.
06. Ah, então devo me preocupar com o meu emprego?
Sim e não.
Se você é um mau funcionário, o MPS.BR vai deixar isso mais evidente pois, como já falei, os processos vão ficando cada vez mais transparentes. Mandar-te embora é uma decisão do seu gerente – o MPS.BR não obriga nenhuma empresa a fazer isso!
Acontecerá justamente o contrário se você for um ótimo funcionário. O MPS.BR vai deixar isso mais evidente e, talvez, você seja até promovido. Na pior das hipóteses, você vai continuar se destacando como bom funcionário. Note que o MPS.BR pretende tornar os processos menos dependentes de indivíduos. Repito: indivíduos. Todo processo sempre dependerá de uma boa equipe. E bons gerentes escolhem bons funcionários para as suas equipes. Ou seja, se é bom funcionário, está dentro!
07. Ok, mas onde entra a documentação nisso tudo?
Sabia que você ia tocar nesse assunto. Após a implementação do MPS.BR, seja qual for o nível, não é raro os desenvolvedores reclamarem da quantidade de documentação que eles precisam produzir. Esse problema, contudo, varia de empresa para empresa.
O MPS.BR não obriga nenhuma empresa a produzir os artefatos X, Y ou Z. Só que ele exige algum resultado para se provar que certos processos foram executados e para permitir o seu gerenciamento. Algumas empresas utilizam formulários de preenchimento manual. Outras utilizam ferramentas onde o preenchimento é quase automático. Se você não está contente com a forma como alguns artefatos são produzidos, procure a área responsável e sugira melhorias. O MPS.BR só é viável se todos se comprometerem com o modelo. Se isso não está acontecendo na sua empresa, a alta direção deveria promover isso com incentivos concretos. Só treinamento não basta.
08. Para que serve essa documentação toda?
Já que você insiste no assunto, vamos lá! Pessoalmente, também não sou muito fã desses artefatos. Nada é melhor que um código bem comentado, um diagrama de componentes e fluxogramas com as regras de negócios. Mas acredito que sempre há uma forma mais fácil e simples de produzir a documentação implícita no MPS.BR.
Vou falar mais sobre isso nos próximos artigos, quando estiver comentando sobre cada processo e seus resultados esperados. Mas em linhas gerais, essa documentação toda serve para tornar o processo mais transparente. Como assim? Explico.
Imagine que você costume anotar em um diário tudo o que fez e fará. Se em um dado momento do dia o seu gerente ler o seu diário, vai saber exatamente o que você fez e o que está por fazer. Se você fez algo e foi bem sucedido, o seu gerente pode entregar uma cópia do seu diário para outra pessoa e pedir para ela seguir os mesmos passos que você. Ainda bem que não se exige de nós um diário na vida real, mas, na prática, temos que registrar o que fizemos e o que pretendemos fazer com alguma freqüência. Tudo isso tem a ver com a transparência que o seu trabalho precisa ter para os seus colegas e seu gerente.
Se mesmo assim você continua achando que a documentação exigida não vale a pena, aguarde meus próximos artigos onde irei dar algumas sugestões práticas de como produzir a documentação com o menor esforço possível e falar um pouco sobre os benefícios de se fazer isso. Ou seja, não é tão ruim assim.
09. Ouvi dizer que tudo precisa ser um projeto; isso é verdade?
É verdade sim. Mas isso é um problema para você? Faz diferença a forma como rotulamos o nosso trabalho? É apenas um rótulo: projeto. Poderia ser demanda, solicitação, pedido, requisição, etc. Mas o pessoal resolveu escolher a palavra projeto. Simples assim.
O que é um projeto afinal de contas? Projeto é um trabalho com escopo, início e fim determinados. Dizem que um projeto só pode ser considerado como tal se o objetivo for desenvolver algo de novo. Mas isso é óbvio! E na verdade tudo que é desenvolvido é algo novo. Se não é novo, já existe e, portanto, não precisa ser feito. Logo, o que precisa ser feito é sempre algo novo em menor ou maior escala. Pense sobre isso. Tirando a correção de erros, TUDO é novo no desenvolvimento de software.
Assim, perceba que não faz diferença chamar o seu trabalho de projeto. Concordo que é um erro do MPS.BR exigir uma rotulação para os trabalhos. Mas, já que não faz diferença, o que custa atender?
10. Ah, mas um projeto é mais burocrático...
Pode até ser. Mas não necessariamente. Como já disse, tudo depende da sua empresa. Algumas atividades são necessárias não por simplesmente existir um projeto, mas por que o processo precisa ser transparente e gerenciável. Nunca esqueça disso.
Aguarde meus próximos artigos onde vou dar sugestões de como desburocratizar essas atividades de projeto.
11. Preciso de alguma ferramenta?
Não. Mas o uso de algumas fica implícito no MPS.BR. Ou seja, não é algo obrigatório, mas muitas vezes é desejável. Aguarde meus próximos artigos que falarei mais sobre isso.
12. O que a empresa ganha com isso?
Bom...não existe nenhum estudo que indique que o valor de uma empresa aumenta após a implementação de algum nível do MPS.BR. Como já disse, a aplicação desse modelo não amadurecerá os processos por si só. Mas dará subsídios para a gerência adotar ações de melhoria com base nas medições dos resultados dos processos.
Vale aqui uma palavra de cautela para aquelas organizações que buscam o MPS.BR: cuidado com a burocratização. Implementar esse modelo não significa necessariamente aumentar a burocracia. É preciso manter o pé no chão e achar formas inteligentes e flexíveis de implementar o modelo sem prejudicar a execução do serviço. É possível? Sem dúvida. Falarei mais sobre isso nos próximos artigos.
Conclusão
Este texto é apenas uma breve introdução ao assunto – o  melhor está por vir.
Vimos que o MPS.BR (e por extensão o CMMI) não é esse bicho de sete cabeças que as pessoas imaginam. Isso vai ficar mais claro nos próximos artigos. A chave de tudo, na minha opinião, é a transparência e gestão do processo – com a conseqüente medição.
Contribua com seus comentários; vamos desmistificar esse assunto!

15 comentários:

ciciliaartista disse...

Oi Samuel, trabalho em Fortaleza com desenvolvimento de Sofotware, á trabalhei na implantação do nível G do MPS.BR numa empresa, achei ótimo seu artigo, parabéns pela iniciativa!

Samuel Diniz Casimiro disse...

Cicília, obrigado pelo comentário. Se você fizer parte do LinkedIn, gostaria de adicioná-la à minha rede para trocarmos experiências sobre implantação do MPS.BR. Um abraço!

Rafael Izidoro disse...

Olá,
excelente artigo...parabéns pelo blog!

Aline de disse...

Prezado Samuel, sou professora de Engenharia de software e venho solicitar autorizaçao para utilizar seu material em minhas aulas. Achei sua abordagem muito didatica, estou aguardando mais material.
Atenciosamente,
Aline

Samuel Diniz Casimiro disse...

Prof Aline,

É um prazer autorizá-la a utilizar o conteúdo do meu blog. Se precisar de algum material sobre um tópico mais específico do MPS.BR, fique à vontade de sugerir algum artigo. Terei enorme prazer em tentar escrever algo que seja útil em suas aulas. Por hora, já estou preparando um novo artigo para introduzir o Nível F.

Samuel

Ricardo disse...

Olá Samuel, seu artigo é muito esclarecedor e permite uma visão bastante clara do todo. Espero que você continue escrevendo sobre os níveis de melhorias de processos, sobre como avaliar o grau de maturidade e etc...

Parabéns pelo blog!

Samuel Diniz Casimiro disse...

Ricardo, obrigado pelo comentário. Pretendo sim dar andamento a essa série de artigos. Inclusive, penso até em escrever um livro sobre esse e outros temas relacionados à Gestão de TI. Acredito que exista muita teoria no mercado e, por isso, gostaria de apresentar algo mais prático e realista. Grande abraço e confira também meu twitter (http://twitter.com/samueldc).

Juliano Antonio disse...

Parabéns! estou estudando MPS.BR, até o momento considero o material mais didático.

Mayconsan disse...

Parabéns pelo artigo. Sou professor de Projeto de Sistemas e gostaria de saber se você ou seus visitantes teriam algum material mais específico sobre o MPS.BR. Quem quiser trocar uma idéia a respeito me add no skype.
Skype: mayconsan

Abraços e parabéns mais uma vez.

Igor disse...

Muito bom seu artigo, estou iniciando na área da web e vi que algumas agências de site que usam o MPS BR o site não é devidamente validado tanto em css como em xhtml, portanto o que gostaria de saber se o mps br atrapalha em algo??
Desde já agradeço

Samuel Diniz Casimiro disse...

Igor, obrigado pelo elogio. MPS.BR trata de melhoria de processos de desenvolvimento de software. Já validação de CSS e XHTML está relacionada a Web Standards. Sugiro dar uma olhadinha no w3.org. Obrigado pela visita!

Marcos disse...

Sensacional, muito bom Samuel. Concordo com você quando diz que (o material disponível sobre o assunto é tão obscuro que muitos não chegam nem no nível da dúvida). Irei fazer um artigo científico e pretendo fazer citações a tua publicação. Aproveito para perguntar se gostaria de me sugerir o objetivo do artigo uma vez que o tema que escolhi é mps.br.
Forte abraço, e parabéns pela iniciativa.

Marcos

Samuel Diniz Casimiro disse...

@Marcos obrigado pelos comentários. Sugiro escrever sobre fatores críticos para uma implantação bem sucedida do MPS.BR. Abraço.

Monica disse...

Estou trabalhando em um projeto de implantação do CMMI em uma empresa de pequeno porte, em conjunto com minha tese de graduação e uma das minhas dúvidas era justamente sobre a obrigatoriedade da documentação. A maioria dos guias e textos sobre o assunto são realmente pouco esclarecedores e nada didáticos. Obrigada pela iniciativa e parabéns pelos textos, estão me ajudando muito.

Raquel Lima disse...

Estou fazendo um trabalho de conclusão de uma disciplina na faculdade, sobre esse assunto.. e seu arquivo me ajudou muito, obrigada.