Impressões do 8º Encontro Mensal da ALATS-SP

Ontem ocorreu a oitava edição do já tradicional Encontro Mensal da ALATS-SP, na Av. Paulista em São Paulo.

Tive o prazer de estar presente nesse encontro que teve como tema Modelos da Qualidade e o MPT.BR, onde foram apresentadas duas palestras: a primeira feita pelo José Correia, diretor regional da ALATS São Paulo, com o título de Introdução a Verificação e Validação no CMMI e MPS.BR, e a segunda apresentada pelo Emerson Rios, presidente da ALATS, com o título Introdução ao MPT.BR.

A seguir segue minhas impressões sobre o evento, espero que gostem. 🙂

Organização

A organização do evento foi bem realizada, só ocorreu um problema: a mudança do local do evento na última hora, mas a mesma foi avisada de forma eficiente aos participantes, e o novo local é bem perto (cerca de nem 100 metros) do local que estava previsto a realização do encontro.

A divulgação foi feita com uma boa antecedência, por meio das listas de discussões de Teste e Qualidade de Software, twitter da ALATS-SP, em blogs e além claro na própria página da ALATS-SP.

Local

O evento ocorreu em uma sala da DoMore, que possui uma boa infraestrutura (tem até um XBox 360 na sala de espera rs), boa climatização e espaço adequado para o número de participantes, aliás, a sala literalmente lotou! 🙂

Pré-palestras

Agora vamos parar de lenga-lenga, pois como puderam notar, não sou um bom relator de ambientes (uma pessoa que comenta sobre a presença de um XBox não pode ser levada a séria), e ir para o que realmente interessa, o encontro.

Antes do início das palestras, cada participante fez uma breve apresentação, contando sobre trabalha com Teste de Software, a quanto tempo e em qual empresa.

Após a apresentação ocorreu a posse dos Diretores Regionais Adjuntos (DRA) no mandato 2010, que assumiram o compromisso de trabalhar de formar voluntária em pró do crescimento e aperfeiçoamento da área de Teste de Software e Garantia da Qualidade. O time da ALATS-SP passou de 7 para 12 pessoas, e esse número ainda deverá aumentar no próximo mês, no qual haverá uma nova seleção de voluntários.

Em seguida o José Correia apresentou o balanço da ALATS e da diretoria de São Paulo, e também as metas para o ano de 2010:

• Em 2009 189 pessoas participaram do encontro mensal;
• Para 2010 a meta é de 400 pessoas!
• Os DRAs realizaram 24 palestras em 2009, totalizando um público de cerca de 1.500 pessoas;
• Para 2010 a meta é de 200 palestras, atingindo um público total de 10.000 pessoas!

Um verso que achei bem interessante, colocado pelo José no início da sua apresentação, foi:

Um sonho que se sonha só,

é só um sonho que se sonha só,

mas sonho que se sonha junto é realidade.

(Raul Seixas)

E isso é a pura verdade, por isso que foi e é tão importante o aumento de voluntários na ALATS-SP, que estão cultivando e espalhando a cultura de Teste de Software aqui no estado de São Paulo. E em outros estados isso também é possível, só é preciso união, seja ela por meio de uma associação, grupo de amigos, companheiros de trabalho, etc, e também vontade. 😉

Palestra do José Correia

O José Correia deu uma verdadeira aula sobre modelos de maturidade, e com a já conhecida, excelente didática (cheia de analogias).

O primeiro ponto esclarecedor apresentado sobre modelos de maturidade, foi a desmistificação que as pessoas tem sobre eles:

• Não é algo mágico! Você não irá ter um salto de melhoria grande de “um dia para noite” é preciso tempo e compromisso, até porque não é a toa, que há níveis de maturidade;
• Um modelo de maturidade não tem verdades absolutas;
• Ele é focado no que você faz, NÃO como  você faz. Até por isso ele não te diz como fazer, apenas o que deve ser feito;
• São modelos para você se inspirar, mas como somos preguiçosos, adoramos seguir a risca #fail!
• Busca tornar o desenvolvimento de software mais previsível;
• São uma base, não são completos e abrangentes.

Depois o José falou sobre CMMI (Capability Maturity Model Integration), explicando o seu surgimento, seus níveis e focando em apresentar onde está a área de Garantia da Qualidade de Processo e Produto e as de Verificação e Validação, nível 2 e nível 3 respectivamente.

Abaixo, uma figura apresentando os 5 níveis do CMMI:

O José explicou algo que geralmente não é muito bem interpretado por nós brasileiros, a palavra Capability (o C do CMMI), cuja tradução em português, capabilidade, não traz o mesmo sentido da palavra em inglês. Capability é a capacidade de fazer algo constante, fazendo uma analogia, o McDonald’s tem uma excelente capability, pois o Big Mac tem um Mc de São Paulo é igual ao de um em Campinas, por exemplo.

Após a introdução sobre o CMMI, o assunto em pauta foi o MPS.BR, uma versão brasileira do CMMI, e assim sendo, adaptado a realidade brasileira.

O José começou a sua explicação sobre o MPS.BR, falando do seu surgimento, que ocorreu em 2003, e depois já abordou os 7 níveis de maturidade.

Uma experiência interessante relatada pelo José, foi que algumas empresas utilizam o MPS.BR (Melhoria de Processos do Software Brasileiro), como forma de início para depois poderem estarem melhor preparados para alcançar um nível de CMMI, já que há uma relação entre os níveis do CMMI e o MPS.BR, como pode ser visto na figura abaixo, além disso o custo de um processo de implantação do MPS.BR é mais em conta do que o do CMMI, e esse é um dos principais motivadores de algumas empresas fazerem isso.

Ou seja, a pessoa pode alcançar o nível A do MPS.BR e depois já tentar o nível 5 do CMMI.

E por fim foi comentando um pouco sobre o Modelo V, mais para ilustrar como que pode ser o processo de Verificação e Validação em uma empresa.

Coffee Break

Pra quem já leu sobre os coffee breaks dos encontros passados, fica até sem graça falar que mais uma vez foi excelente, pena que eu já tinha tomado café em casa (rs). Foram 30 minutos para aproveitar pra conhecer o pessoal melhor, enquanto come uns pãezinhos de queijo (e vice-versa rs).

Palestra do Emerson Rios

O Emerson Rios iniciou a sua palestra falando sobre o porquê da criação do MPT.BR (Melhoria de Processo de Teste Brasileiro):

• Necessidade de ter um modelo de melhoria focado na área de Teste de Software;
• Adaptar um modelo de Teste de Software para a realidade brasileira;
• Ausência de implementadores estrangeiros, de outros modelos, aqui no Brasil;
• Criar um modelo leve para Teste de Software.

O MPT.BR é um modelo que ainda está em desenvolvimento, mas já estão sendo feitos 3 projetos pilotos, em três empresas no Rio de Janeiro. Os três estarão se encerrando no mês de março desse ano, portanto a fase de piloto do MPT.BR estará terminada.

O modelo é compatível tanto com a MPS.BR quanto com o CMMI, principalmente pelo fato de ser baseado justamente no MPS.BR, que por sua vez é baseado no CMMI. O MPT.BR propõe-se ser um modelo leve, para que não sejam onerados os processos e para que também seja possível aplicá-lo em áreas de Teste de Software pequenas, que é muito comum existirem no Brasil.

Na sequência o Emerson falou sobre os 5 níveis do MPT.BR, apresentando de forma mais detalhada os dois primeiros:

Nível 1	Gerência de Projetos de Teste – GPT
Nivel 2	Gerência de Requisitos de Teste – GRT
Nivel 3	Aquisição – AQU (opcional)
	Gerência de Configuração – GCO
	Garantia da Qualidade – GQA
	Medição – MED
Nivel 4	Gerência de Recursos Humanos – GRH
	Gerência de Reutilização – GRU (opcional)
	Gerência de Riscos – GRI
Nivel 5	Verificação – VER
	Validação – VAL

A primeira coisa que você precisa fazer para saber se você está credenciado ou não para implementar o MPT.BR nível 1, é tratar o Teste de Software como projeto, e se você trata o Teste de Software na sua empresa como um projeto, o próximo passo é responder as questões da Análise de GAP – Nível 1 (disponível na página do MPT.BR).

Na página do MPT há vários documentos que poderão te ajudar a entender melhor o MPT, dentre os quais estão os documentos do Nível 1, Nível 2 e Nível 3 (beta). E o interessante é que como é um modelo que está em desenvolvimento, você pode entrar em contato com o Emerson Rios, para sugerir melhorias, reportas erros, etc.

No final o Emerson Rios passou informações sobre o credenciamento de implementadores, para o qual é necessário que o profissional tenha feito o curso oficial para implementadores da  Riosoft/ALATS e ter o diploma de certificação CBTS.

Conclusão

Confesso, que senti aquela preguiça ao levantar às 6:00 em pleno sabadão, ainda tudo escuro (esse horário de verão é fogo…), mas aí lembrei que é o encontro mensal, ou seja, não é só mais um evento, e sim uma oportunidade de encontrar os amigos e fazer novos, as palestras em si são só uma desculpa pra gente ir (afinal é muito mais fácil você falar pra sua(seu) esposa(o)/namorada(o) que vai em uma palestra de Teste de Software, em pleno sábado, do que falar que vai sair com os amigos…rs).

As duas palestras foram muito boas, ambas cumpriram o que se esperava, e acredito que todos puderam entender melhor porque existem modelos de maturidade, e qual importância que eles podem ter para a sua empresa.

Na minha opinião, eles são no mínimo uma ótima fonte de consulta, e o bom é que tanto o MPS.BR quanto o MPT.BR possuem material para download, em seus sites. Se você deve ou não deve ser certificado em um deles, é uma questão de interesse interno (ação pró-ativa) ou de “pressão” externa (ação reativa).

Tem gente que marca uma cerveja pra conversar com os amigos, outros um futebol, alguns um cinema, e a gente marca uma palestra. 😀 Portanto, se você está aí na sua ilha sozinho, não tem com quem falar sobre Teste de Software, ou simplesmente, gosta de conhecer novas pessoas, participe do encontro mensal que a ALATS-SP promove todo mês, pois você ainda irá poder aprender ou conhecer mais sobre um assunto da nossa área. 😉

Dia 20 de fevereiro é o próximo!

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte imagens:

Cachorro fugindo do gato – http://bit.ly/752y8Z

Remédio Genérico – http://bit.ly/4omlvN

CMMI – http://bit.ly/4HwOx3

MPS.BR X CMMI – http://bit.ly/6uAbeO

8º Encontro Mensal da ALATS-SP

O oitavo encontro mensal da ALATS-SP ocorrerá no dia 16 desse mês (em um sábado) e terá como tema “Modelos da Qualidade e o MPT.BR”. Será um encontro especial, com duas palestras: a primeira uma introdução sobre Verificação e Validação no CMMI e MPS.BR, e terá como palestrante o grande José Correia, diretor regional da ALATS São Paulo; já a segunda será uma introdução ao MPT.BR, ministrada pelo presidente da ALATS, Emerson Rios.

Será uma ótima oportunidade para conhecer como a área de Teste e Qualidade de Software é tratada no CMMI e no MPS.BR, assim como conhecer esse novo modelo de maturidade, o MPT.BR, que tem como foco a área de Teste de Software. E você ainda irá conhecer (se ainda não conhece), esses dois grandes nomes da nossa comunidade, que há um bom tempo, dedicam esforços em pró do crescimento da nossa área no Brasil.

Abaixo, segue maiores detalhes do encontro, retirados do site da ALATS-SP:

Data: 16 de janeiro (sábado)
Horário: 08:30 – 12:00
Local: Av. Paulista, 726 – Auditório – próximo a estação de metro Brigadeiro

Objetivo:
Aumentar o contato entre profissionais da área de Teste de Software e Garantia da Qualidade, bem como estimular a troca de conhecimentos, experiências e práticas de sucesso.

Tema do Encontro:
Modelos da Qualidade e o MPT.BR

Conteúdo:

Visão geral das área chaves dos modelos CMMI e MPS.BR relacionadas com Teste de Software (Verificação e Validação) e Garantia da Qualidade. Apresentação do modelo de Melhoria do Processo de Teste Brasileiro (MPT.BR) em desenvolvimento pela ALATS e SOFTEX.

Agenda:

08:30 Credenciamento e networking entre os participantes
09:00 Balanço das realizações da ALATS São Paulo em 2009
09:15 Posse dos Diretores Regionais Adjuntos no mandato 2010
09:30 José Correia – Introdução a Verificação e Validação no CMMI e MPS.BR
10:30 Coffee break e networking
11:00 Emerson Rios – Introdução ao MPT.BR
12:00 Encerramento

Palestrantes:
Emerson Rios, graduado em Ciências Econômicas pela UFF, pós-graduado em Engenharia de Sistemas pela COPPE/UFRJ, presidente da ALATS, certificado CBTS, diretor do iTeste, instrutor e consultor dos programas MPS.BR e MPT.BR da RioSoft/SOFTEX.

José Correia, graduado em Processamento de Dados, pós-graduado em Gestão Empresarial, diretor regional da ALATS São Paulo, certificado CBTS, CSQA, CSTE e CTFL, consultor e instrutor da Iterasys.

Inscrições:
– Não Associados: R$ 30,00

– Associados ALATS 15% de desconto

A participação na palestra Vale 3 PDTS para a renovação da CBTS
Reserve pelo e-mail sp@alats.org.br

Fique por dentro das novidades, assine o feed do QualidadeBR.

MPT: Melhoria do Processo de Testes

A quinta Mesa Redonda DFTestes foi sobre MPT – Melhoria do Processo de Testes. A discussão teve 13 respostas e 8 participantes: eu, Ueslei Aquino, Shmuel Gershon, Felipe Silva, Edwagney Luz, Robson Agapito, Wesley Baldan e o Wagner Duarte.

Na sequência, segue um resumo da discussão, quem quiser conferir a discussão na íntegra, pode acessá-la no DFTestes.

O MPT.BR

O Ueslei Aquino explanou sobre o que é o MPT.BR:

O MPT é um modelo que está em desenvolvimento, com o objetivo  principal será garantir que áreas de teste de software de tamanho reduzido possam ser avaliadas e estimuladas a alcançarem níveis maiores de maturidade, sem que para isso tenham que incorrer em altos custos de operacionais.

Este Modelo está sendo elaborado com base em algumas áreas de processo do MPS.Br e também com referências ao CMMI e PMBOK (para termos de projeto).

O modelo foi projetado inicialmente com 7 níveis de maturidade, mas possivelmente será alterado para 5 tornando-o assim mais leve que previsto anteriormente (está em fase de aprovação). Mas esta mudança aconteceria do Nível 4 em diante, ou seja os níveis até agora definidos serão mantidos (Nível 1 e 2). O Nível 3 está em fase terminal de desenvolvimento e o Nível 4 em Desenvolvimento.

No meu Blog tem um pequeno post sobre o modelo com sua estrutura inicial, com 7 níveis.

A estrutura com 5 níveis deve ficar da seguinte forma:

• Nivel 1:
  • GPT – Gerência do Projeto de Teste;
• Nivel 2:
  • GRT – Gerência de Requisitos de Teste;
• Nivel 3:
  • AQU – Aquisição (opcional);
  • GCO – Gerência de Configuração;
  • GQA – Garantia da Qualidade;
  • MED – Medição;
• Nível 4:
  • GRH – Gerência de Recursos Humanos;
  • GRU – Gerência de Reutilização;
  • GRI – Gerência de Riscos;
• Nível 5:
  • VER – Verificação;
  • VAL – Validação.

Atualmente 4 empresas encontram-se com processo de implementação do MPT nível 1 (GPT – Gerência de Projeto de Teste). Empresas como DataSus e iTeste (que provavelmente se certifica até o início de 2010), além de outras.

Ser certificado MPT vale a pena?

Segundo o Ueslei Aquino:

O modelo está em “gestação”, mas aqueles que gostam da área de processo e/ou pretendem investir nessa área, acho que é uma boa sim.

Por que os “selos” de qualidade e melhoria, são tão criticados hoje em dia, principalmente pelos agilistas?

O Ueslei Aquino acredita que:

Pelo fato de muitas empresas buscarem o selo apenas para serem melhor colocados em licitações mas depois que o avaliado vira as costas engavetam toda documentação e volta a vida normal. Implantar processo seguir práticas é um tanto quanto burocrático, se na organização não tiver o apoio da alta gerência para q tudo seja seguido nada funciona. Acredito que MPS resolveu essa situação colocando validade de 3 anos para a certificação, se uma empresa não se re-certificar sai da lista dos certificados em determinado nível.

Segundo o Shmuel Gershon:

Os agilistas não inventaram as críticas aos selos de qualidade… As reclamações são antigas, é só olhar para as críticas ao ISO9000 e ao Six Sigma.

Uma das limitações de todos os processos uniformizados, é, bem, a uniformidade do processo :). Como ele é estático e uniforme, quem tem que se adaptar é a empresa e os empregados. Empresas não são  uniformes, e elas são compostas por interações não uniformes entre pessoas não uniformes.

Empresas são diferentes, e programam software diferentes. O processo para tratar de qualidade é o mesmo em um produto web-based e embedded? Um controlador de equipamento médico e um administrador de conteúdo? Uma empresa com 700 empregados e uma com 7?

O comentário do Ueslei aparece como uma boa surpresa, pois o foco em “áreas de teste de software de tamanho reduzido” implica na fé de que existem contextos diferentes e o tamanho é um dos parâmetros – uma boa novidade na área de estandardização de processos, que tende a ver tudo como ‘tamanho único’.

Por outro lado:

a) O tamanho da empresa é um parâmetro fraco sobre seu contexto;

b) Comumente empresas com tamanho reduzido sentem menos a falta de processos do que grandes;

c) O comentário implica que tamanho reduzido resulta em níveis menores de maturidade

Sobre a limitação citada pelo Shmuel, acredito que é uma verdade, e o pior é como alguns profissionais encaram esses selos. Infelizmente, muitos ganham os seus uniformes (adorei essa analogia rs) e percebem que ficam bonitinhos com ele, daí então, a sua maior preocupação é deixar o uniforme bem limpinho.

Mas… e o cliente? ahh… ele terá uma primeira impressão muito boa da empresa uniformizada, e como dizem a primeira impressão é a que fica (ou não)

No entanto após um tempo, o cliente vai perceber que as aparências enganam.

O mais importante para qualquer fornecedor é atender bem o cliente, isso é tão “lógico”. Selos, certificações profissionais, etc são plus, primeiro você tem que comer o feijão com arroz, pra depois comer a sobremesa!

O Edwagney também fez um comentário sobre as colocações feitas pelo Shmuel, a respeito da padronização dos processos:

Excelente exemplo Shmuel,

Isso vem ao encontro de um texto que escrevi em meu blog sobre padronização com o título: “Padrão, todos nós deveríamos ter um.” (https://itqualityview.wordpress.com/)

Minha visão é exatamente essa. O ponto crucial de alguns processos de qualidade, e processos em geral, não darem certo em algumas organizações é que elas não lançam mão da sua cultura, da sua política, não usam o que tem de melhor. Não adaptam um determinado padrão aos padrões já existentes na empresa.nas empresas nas quais trabalhei, vi acontecer muito isso. A questão era: “Vamos implantar isso de qualquer forma.” Conhece o ditado: “Top-guela-down”? é mais ou menos por aí… 🙂

Usar padrões e processos faz parte da inovação e da melhoria da qualidade, porém, arrisco dizer que 80% do sucesso de um projeto nesse sentido, se ganha usando o lado bom do conhecimento e cultura da empresa.

Qual a posição do mercado em relação as empresas certificadas?

O Shmuel Gershon acredita que:

Em um primeiro momento, pareceria uma questão de oferta e demanda. É igual ISO9001… se a empresa vai perder mercado por falta de certificação, enão certamente vale a pena. Se a empresa consegue manter diferenciação comercial sem o certificado, então não vale a pena. Certo?

O único problema na situação descrita é que no caso de uma certificação sobre testes, quem cria a demanda são as próprias empresas certificadas.

Assim como nas certificações de indivíduos, existe tanta confusão ao redor do que testes e testadores fazem, que é fácil apresentar uma certificação e dizer “Aqui oh, não se preocupe, nos somos certificados, por isso somos melhores que a concorrência”. Ao criar a demanda, criamos um circulo vicioso aonde quem não se certifica fica pra traz.

No fim das contas, se uma empresa acredita que deve passar pelo processo de certificação, tudo bem, mas com cuidado e delicadeza…

É muito importante que o processo seja guiado por alguém (interno ou externo) que está atento as interações e os métodos implícitos no dia-a-dia, para que o processo não estraguem alguma área que já anda bem – ou para que o processo não esconda a realidade sobre uma área aonde existe incompetência.

No cenários em que a certificação representa um diferencial competitivo para a empresa, mas irá “atrapalhar” os processos internos da empresa, costuma haver uma grande resistência interna, um exemplo bem básico:

Se você é o Gerente de Teste e acaba de ser informado que a sua empresa irá tentar se certificar em um selo X, e sabe que isso irá trazer um grande impacto para o processo atual de Teste de Software, talvez você possa ser resistente a essa decisão, pois está olhando só para o seu nível.

Agora se você for analisar num nível macro a decisão, você poderá perceber que o selo X irá trazer grandes benefícios a nível de negócio para a empresa, podendo resultar em contratos importantes, que ir.

Moral da história: Precisamos sempre buscar ter uma visão ampla do nosso mundo. Para alcançar o sucesso, é necessário sacrifícios. (“O importante é termos a capacidade de sacrificar aquilo que somos para ser aquilo que podemos ser.” – Charles Dubois)

Para uma empresa cujo core business não é o Teste de Software, é interessante a certificação?

Para o Ueslei Silva:

Bom, se esta empresa usa SW e possui profissionais que testam o SW, acredito que sim. Trabalhei em uma empresa que mantém no mercado um grande ERP. A empresa possui uma fábrica de desenvolvimento de aproximadamente 70 desenvolvedores e um departamento de teste com 8 testadores, para o mercado seria interessante mostrar para os clientes que a qualidade do SW é assegurada por processos estabelecidos, maduros, etc. (eu era o gestor da área de testes, mas a empresa não estava preparada culturalmente para implantar um processo assim).

Para o Shmuel Gershon depende:

Uma possibilidade: Sim! – pelo menos vai ter um processo mais estruturado.

Outra: Não! Aonde existia incompetência caótica, agora existirá uma incompetência organizada e rigorosa. O problema desta última, é que agora ninguém mais percebe que tem que melhorar.

Ou ainda: Depende! Pode ser que o dono da empresa se sente inseguro e a certificação vai deixá-lo mais cordato para guiar a empresa. Ou pode ser que a equipe é madura o suficiente para não deixar a certificação ou o rigor do processo atrapalhar a operação. Pode ser que o gerente de testes não quer a certificação de jeito nenhum, e certifica-se vai criar rixas desnecessárias. Pode ser que a equipe é tão madura e com ótima performance que inserir as mudanças da certificação vai atrapalhar. Tudo pode ser.

A melhor resposta depende de cada empresa, gerente, líder e equipe. A equipe deve se conhecer o suficiente para escolher.

A respeito do caos citado pelo Shmuel, nessa semana ouvi uma história interessante, de um amigo meu, sobre uma grande empresa que estava se preparando para o CMMI:

Ele trabalhava na empresa XPTO, e essa empresa estava se preparando para o CMMI, daí o cliente X, pediu uma nova funcionalidade no sistema dele, esse cliente estava acostumado com o processo antes o CMMI, sabe aquele processo padaria? (me ver um pãozinho aí = me ver uma funcionalidade X), porém o Gerente do Projeto, não podia mais seguir o processo padaria, e para explicar isso para o cliente? rsrs (para não chorar)

Alguém já participou de uma avaliação, avaliando ou sendo avaliado? E poderia relatar a experiência.

O Ueslei Aquino compartilhou um pouco da sua experiência com o MPT:

Eu mesmo conduzi as reuniões de implantação das práticas do nível 1 na iTeste, num projeto em que o Cliente encontra-se na Bélgica, o Desenvolvimento na Índia e os Testes são feitos aqui no Brasil (RJ). Detalhes:(1) O desenvolvimento utiliza scrum e ja estava com 1 ano iniciado sem muitas documentações. Foi necessário mapear casos de uso para que os casos de testes fossem realizados; (2) A fábrica de Teste não Fala com o Desenvolvimento, a comunicação é direta com o cliente e este passa os bugs para o Desenvolvimento. Apesar de todo este cenário, o Projeto está andando muito bem e seguindo as práticas do MPT nível 1.

O Shmuel Gershon compartilhou a sua experiência com o TPI:

Eu participei de processos TPI (Test Process Improvements), e no meu departamento tiramos nossas próprias conclusões sobre o que ajuda e o que deveríamos ignorar. Também faço parte de um grupo para a discussão de metodologias, mas não seguimos nenhum processo público. Judy Bamberger foi uma das autoras do CMM, e ela escreve que “acredito que ele (o CMM) não foi concebido para ser usado de maneira em que determinada empresa tem que alcançar o nível X em determinado tempo, ou que a empresa precisar “ser” um certo nível antes que outros negociem com ela” (tradução minha). Ou seja, as documentações normalizadas de processos são apenas auxiliares, mas não devem dominar o procedimento.

A CQA

Para o Felipe Silva:

“A hora” de certificar-se é quando o ambiente está pronto. Fazendo uma analogia, a empresa é um quarto, pode estar bagunçado e cheirando mal ou arrumado e cheiroso, a certificação seria uma placa que você colocaria do lado de fora da porta “Quarto organizado”, dai já dá pra tirar as conclusões de quando tentar colocar a placa ou não e os impactos de tentar colocar a placa no momento errado, já pararam pra pensar se o cliente resolve abrir a porta e ver como está realmente este quarto por dentro e vê algo assustador?

O fato é, se o quarto está arrumado, por que não sinalizar isso ao mercado? Sim, vale a pena para a empresa estes selos.

A respeito do ponto de vista do Felipe Silva, o Shmuel Gershon fez o seguinte comentário:

Seu exemplo é muito bom, mas eu gostaria de adicionar que ele falha em perceber a limitação das certificações de processos. Por exemplo: Meu jeito de arrumar o quarto e o de minha esposa são diferentes, os métodos de trabalho e os critérios de qualidade de nos dois difere também. Porém, ela performa com rapidez e segurança no seu modo – e consegue encontrar qualquer coisa em um piscar de olhos.

Se eu criar a CQA (certificacao de quarto arrumado), ela terá que mudar seu modo de trabalho – o quarto vai ficar do jeitinho que eu quero (e defini na documentação)… Mas será que ela vai estar executando a tarefa com a mesma satisfação? Será que ela vai encontrar as coisas com a mesma agilidade agora que as roupas estão guardadas por ordem alfabética?

E, mais importante: Será que a imposição de um método não natural a sua personalidade não vai afetar uma serie de outras áreas que a CQA não mede? Ou que eu não percebi serem cruciais para  o bom funcionamento da família?

Enquanto o método de melhoria de processo de testes estiver aí para ensinar e guiar e deixar cada empresa criar seu próprio caminho para a excelência, maravilha. Mas ao tratar o conteúdo como uma ‘certificação’, o material acaba se tornando mandatório e standardizado – e o que pode ser bom para uma empresa pode ser perigoso para outra.

A resposta ao “vale a pena?” é “depende” – cada empresa e equipe deve analisar sua situação e necessidades.

Experiências com o MPS-BR

O Robson Agapito compartilhou a sua experiência com o MPS-BR:

Vou contar uma história verídica que aconteceu conosco na Mega em relação ao MPS-Br… estávamos procurando melhorar a qualidade de nosso produto, e buscamos o conhecimento oferecido pela Softex chegando então a certificação do Nível G… mas desde o início lutamos não pela certificação, e sim pela melhor qualidade e melhor controle de tudo que entrava (solicitações) pelos clientes e tudo que saia (melhorias e correções) do desenvolvimento/testes. E tínhamos em mente que a certificação seria uma conseqüência da melhoria de nosso processo.

Com certeza no inicio “travou” um pouco, mas com o andamento dos projetos e adaptações ao modelo proposto, melhorias foram identificadas durante o andamento do trabalho, e esta melhoria foi identificada por todos, inclusive pelos clientes que hoje sentem um produto final mais maduro e com uma melhor qualidade.

Então digo, o importante não é a certificação (claro que ajuda muito em uma venda), mas sim o conhecimento e a bagagem na melhoria da qualidade que conquistamos na implantação de processos para garantir a maturidade de nossos processos… a certificação foi conseqüência. Mas a cada dia batalhamos pela melhoria do processo, pois sempre podemos melhorar e jamais se acomodar.

Creio que o MPT vem para se tornar um apoio à todos da área de testes, ajudando a criar e melhorar processos de testes pelo Brasil, e futuramente pela América Latina.

O Wesley Baldan também compartilhou uma experiência com o MPS-BR:

Onde eu trabalho, foi um pouco diferente. Para obtermos o nível F (se eu não estou enganado, enfim, é o 2º nível) do MPS-Br a principal preocupação era com a aprovação, mas por conseqüência houve uma grande melhora… Claro, se está se preparando para obter um nível de qualidade as mudanças tem que ocorrer e por conseqüência há melhoras no produto final.

No começo foi muito difícil, porque antes era organizado, mas não tanto, então travava muito no começo o processo, mas depois de um tempo todos perceberam a melhora que aconteceu… É aquela coisa de quebrar a rotina, quando há uma mudança muitas pessoas não gostam.

Depois de obtido o nível, a empresa foi adquirida por outra e um dos pontos positivos da área de Desenvolvimento era a atenção com a qualidade.

Para encerrar o “resumo”, segue abaixo o comentário do Wagner Duarte, que levantou um ponto muito importante a atitude das pessoas, principalmente, dos que estão liderando a implementação:

Essa questão (mudança cultural) é e sempre foi um obstáculo na implementação de quaisquer melhorias e/ou mudanças em qualquer tipo de grupo.

Creio eu, que o problema não está apenas em quebrar paradigmas, mas principalmente no perfil daquele que propõem as mudanças.

Vejo hoje, que têm muitos “líderes” que não têm perfil ou apenas que não aprenderam algumas das boas práticas de um “bom líder”, para exercer tal atividade.

• A forma em que a solução/mudança é proposta pode causar discordância e desmotivação dos membros da equipe;
• Um “bom líder” tem que ter visão – para analisar um “Modelo” proposto e verificar o que se adéqua melhor à sua empresa/instituição;
• Os membros que participam da implantação das mudanças/melhorias devem ter qualidade nas veias, para proporem ainda mais melhorias e não, contaminarem e desestimularem o restante do grupo, por não gostarem de mudanças e serem comodistas.

O ponto levantado, faz-se bastante pertinente ao dizer que “o MPT diz o que deve ser feito e não como”, ou seja, isso o torna um modelo proposto que, para se  alcançar um determinado nível faz-se necessária a implementação/modificação de uma metodologia. Porém, como a empresa fará para se atingir o nível esperado, depende muito do “líder” que conduzirá o movimento.

Se você quiser saber mais sobre o MPT.BR, recomendo o blog do Ueslei e a página oficial do MPT.BR.

Fique por dentro das novidades, assine o feed do QualidadeBR.