sábado, 21 de fevereiro de 2009

Desmistificando o MPS.BR – Adendo à Introdução

No meu último artigo sobre MPS.BR, fiz uma breve introdução ao assunto na forma de perguntas e respostas. Tentei esclarecer alguns conceitos desse modelo de melhoria e enfatizar alguns objetivos chaves. Se você ainda não leu a introdução, recomendo que a leia antes de considerar este adendo (clique aqui). Se você achar a introdução muito longa, leia pelo menos a primeira parte e se concentre nas perguntas que achar mais relevante.
Na introdução, para deixar o texto simples, apresentei apenas uma versão simplificada do MPS.BR. Algumas coisas foram deixadas de lado a favor daquilo que, de acordo com a minha experiência, é mais importante: enfatizar que esse modelo é sobre tornar o processo de desenvolvimento de software mais transparente e gerenciável. Em outras palavras, o MPS.BR não diz “como” se deve melhorar o processo. Mas as implementações propostas por esse modelo, se observadas, permitem aos gestores avaliar a necessidade de melhoria e saber onde o processo deve ser melhorado.
Entretanto, mal acabei de publicar o primeiro artigo, já recebi mais algumas perguntas sobre o assunto. E percebi que algumas coisas precisam ser mais bem esclarecidas antes de partir para uma desmistificação de cada processo (como havia prometido, meu próximo artigo iria falar especificamente sobre o Nível G do MPS.BR). Sendo assim, vamos lá! Vou responder mais estas quatro importantes perguntas.
Se o MPS.BR serve apenas para mostrar SE o processo deve ou não ser melhorado com base nas medições, por que não ir direto ao ponto e corrigir logo o processo?
Pergunta interessante. Ela questiona a real necessidade do MPS.BR. Em outras palavras, ela quer saber se, já que eu disse que o MPS.BR apenas indica SE o processo deve ou não ser melhorado, por que não esquecer esse papo de maturidade e implementar de uma vez por todas um processo mais eficaz e eficiente?
Em primeiro lugar, menti quando disse que o MPS.BR apenas indica se o processo deve ou não ser melhorado. Na verdade, em um primeiro momento, omiti essa informação por razões didáticas. A transparência e a gerenciabilidade, no fundo, JÁ são uma melhoria de processo. Portanto, por simplesmente implementar o MPS.BR, a empresa já está conseguindo alguma melhoria, mesmo que pequena. Ocorre que, como disse no primeiro artigo, um processo REALMENTE maduro é aquele que obtém os melhores resultados ao menor custo possível. E isso vai muito além da transparência e gerenciabilidade. Só que menti quando disse que era só isso. Esses são os pontos chaves. Só que o MPS.BR vai mais além. A maturidade proposta por esse modelo contribui para a redução de riscos e, portanto, para diminuir a incerteza e a possibilidade de prejuízos dos processos. Logo, o MPS.BR por si só, no fim, também contribui para reduzir os custos dos processos.
Segundo. Se a sua empresa resolver ignorar o MPS.BR e ir direto ao ponto, pode ser que cometa alguns erros. E digo isso por diversas razões. Pode ser que o seu processo já esteja bom e nem precise ser melhorado, mas você não sabe disso por que ele não é transparente. Pode ser que você implemente ações de melhoria no ponto errado do processo. Por último, mesmo que o seu processo precise ser melhorado e você consiga isso, como garantir que ele vai continuar assim se não for transparente e gerenciável? Como você vai controlá-lo? Sem controle, pode ser que um processo bom hoje fique ruim no futuro. Se isso ocorrer, o investimento se perderá. O MPS.BR evita esses problemas, pois mostra se o processo precisa ser melhorado, em que ponto e garante que ele continue assim por meio de processos de controle e melhoria constante.
Terceiro. Você precisa ter números para justificar um investimento em melhoria para a direção de sua empresa. Eles vão querer saber qual o retorno sobre o investimento, dados da situação atual e da situação desejada. Sem a medição preconizada pelo MPS.BR, fica muito difícil conseguir esses números.
Em suma, ir direto ao ponto é arriscado e o barato pode sair caro.
Já que o MPS.BR não fala “como”, o que fazer para melhorar o processo?
Como você mesmo disse, essa pergunta foge do escopo do MPS.BR, que é um modelo de melhoria do processo. Mesmo assim, vou te dar uma dica. Para melhorar o processo DE FATO, utilize um modelo DE processo. Em outras palavras, para ir além da transparência e da gerenciabilidade, aplique um modelo de processo.
Existem vários à disposição: RUP, XP, Scrum, o método preconizado pela 37signals (que vou chamar carinhosamente de M37), etc. Qual é melhor? É difícil responder. Gosto muito do foco na arquitetura e nos casos de uso proposto pelo RUP, porém ele é muito burocrático. Acho legal a programação em pares do XP, mas ele deixa a arquitetura um pouco de lado. Já o M37, da 37signals, é interessante por focar na prototipação e no marketing – mas fica muito longe do MPS.BR. Assim, o melhor talvez seja aproveitar o melhor de cada um. Muito vai depender do que os números revelaram após a implementação do MPS.BR. Vou exemplificar.
Suponha que os números revelem que os produtos não estão satisfazendo os desejos dos demandantes e isso estiver provocando constantes alterações de escopo. Se esse for o caso, talvez seja o caso de adotar a prototipação do M37 que tem se mostrado útil para reduzir o risco de o produto final não ser o que o cliente queria.
Vale ressaltar que esses processos não são certificados pelo MPS.BR nem pelo CMMI-DEV. Ou seja, implantar esses processos não é garantia de atender 100% ao MPS.BR, mesmo em se tratando do burocrático RUP.
Bom. Já fugi demais do assunto. Vamos voltar ao MPS.BR.
Por que o MPS.BR?
Por falta de opção, talvez. Como mostrei no primeiro artigo, o MPS.BR é baseado no CMMI-DEV, que é um padrão internacionalmente aceito como uma boa prática. Mas existem diversas críticas a esses modelos de melhoria. Aconselho analisar bem essas críticas para saber se é isso que você realmente quer para a sua empresa. Como já disse, ninguém é obrigado a implementar um modelo de melhoria. Lembre-se que não existe nenhum estudo indicando que o valor de uma empresa aumenta com o MPS.BR. A não ser que sua empresa seja uma softwarehouse e o mercado esteja exigindo algum nível de maturidade para contratá-la, talvez seja o caso de ajustar o MPS.BR à sua realidade. Ou, quem sabe, inventar um modelo melhor.
O MPS.BR fala sobre o desenvolvimento de coisas novas – e a manutenção, como fica?
Antes de responder a essa pergunta, preciso deixar bem claro o conceito de manutenção que uso aqui. Manutenção é tudo aquilo que NÃO é REALMENTE novo. Ou seja, qualquer alteração de requisitos, funcionais ou não funcionais, não é manutenção. Manutenção tem a ver com manter o que já existe funcionando de acordo com os requisitos que foram considerados na sua criação. Em outras palavras, manutenção é basicamente correção de bugs de codificação ou erros relacionados com falhas de hardware. Para executar um trabalho de manutenção, teoricamente, não é necessário receber nenhuma solicitação. Afinal de contas, você está apenas cumprindo com o prometido: entregar algo que funcione de acordo com o que foi requisitado. Ficou claro? Espero que sim.
Apesar de não se meter muito na manutenção, o MPS.BR tem forte influência sobre ela. Como assim? Explico. Com a melhoria do processo, você vai ter melhores condições de entregar um produto com qualidade, que atenda realmente a todos os requisitos. E isso, conseqüentemente, vai diminuir a necessidade de intervenções, de manutenção. Em outras palavras, MPS.BR é igual a menos manutenção. Pelo menos em teoria.
Qualquer outra solicitação que envolver alteração em requisitos deve ser tratada como algo novo e, portanto, deve ser tratada na esfera do MPS.BR.
Quanto a garantir que esse produto continue funcionando, isso é assunto para outros padrões, como o ITIL. Fico devendo falar mais sobre isso em futuros artigos.
Conclusão
Em uma primeira análise, o MPS.BR pode parecer algo desnecessário. Contudo, quando analisamos o assunto com mais cuidado, percebemos que considerar a maturidade dos processos é melhor do que se imaginava.
Esse modelo de melhoria não é perfeito. Mas é o melhor que temos até agora.
Esclarecer esses pontos nos convence da importância do MPS.BR e isso é a base para prosseguirmos com a análise dos níveis de maturidade. Até o próximo artigo.

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!