Qualidade de Processo

Pergunte a qualquer funcionário de qualquer empresa: “qual a finalidade desta empresa?” e obterá variações da mesma resposta, algo como “gerar lucro através de um produto/serviço que tenha qualidade diferenciada para se perpetuar no mercado”, o que é corretíssimo. Quebrando esta resposta temos três elementos chave: lucro, produto de qualidade e longevidade de negócio.
Ora, se o intuito fosse tão somente obter lucro, o dono, ou sócio capitalista, ou investidor, poderia tão somente dirigir seus recursos ao mercado financeiro, com sua gama de opções mais ou menos arrojadas para ganhar (ou em certos casos – como em qualquer negócio – perder) dinheiro. Então entra aí o elemento diferencial, o produto ou serviço geralmente com o qual o dono do negócio se identifica, seja por herança de família, seja por vocação.
Então temos como elemento chave dessa equação a obtenção de um produto/serviço (que para simplificar vamos passar a chamar somente de “produto”) de qualidade. Nesta medida, a percepção do mercado sobre este produto irá determinar a longevidade do negócio.

Qualidade de Produto

Mas o que seria um “produto de qualidade”, e melhor, como obtê-lo e mantê-lo à frente dos concorrentes? Este assunto será tema de outros artigos de forma mais científica, por enquanto vamos nos ater à noção intuitiva, que nos basta. Na área de TI, um produto de qualidade é aquele que atende às necessidades do cliente, supera suas expectativas, é fácil de usar, confiável em seus resultados e oferecido a um preço justo. Tão simples quanto difícil de obter, e quando se obtém é necessário dar um passo à frente para não ser atropelado por uma concorrência feroz, e para isso a inovação constante é um forte apelo mercadológico. Destes fatores depende toda a sobrevivência da empresa, e das muitas famílias que esta alimenta.
Desta forma, basta trabalhar consistentemente o desenvolvimento dos requisitos para percepção das necessidades explícitas e implícitas do cliente ou mercado a fim de atingí-las e superá-las constantemente, investir esforços numa engenharia robusta que consiga atingir níveis sempre crescentes de performance e testar exaustivamente para minimizar até a ínfima possibilidade de erro, ou até mesmo eliminar efetivamente esta possibilidade em casos críticos como sistemas de suporte à vida ou tecnologia espacial – por exemplo – onde erros podem significar dano à vida humana.
Ainda, um produto de qualidade deve atender a um requisito básico do negócio: ser rentável à empresa que o produz. Assim, controlar esforços, custos e mesmo prazos de entrega são atividades essenciais para que o produto não tenha somente qualidade para o cliente, mas também para a empresa que o criou, atingindo assim sua finalidade como negócio.

Finalidade do Processo

Então, em última análise, o que faz um produto de qualidade é a aplicação de um conjunto agregado de conhecimentos e habilidades que contribuem para o sucesso da finalidade a que se propõem. O grande problema da área de TI é que estes conhecimentos e habilidades são inerentes a pessoas que podem ou não ser retidas pela empresa, e em muitos casos, a perda de profissionais que detém estes conhecimentos ou habilidades pode significar o fim dos negócios, ou pelo menos uma grave crise empresarial.
Daí que a finalidade de um processo dentro de uma empresa é justamente o de transferir estes conhecimentos e habilidades das pessoas para a organização, de forma com que ela possa manter a continuidade da geração de produtos de qualidade independente da pessoa A ou B. Dá para começar a entender o porque de certos profissionais de TI não gostarem nem um pouco de processos, pois – principalmente dentro de uma visão imediatista e estreita – este processo “esvaziaria” o valor da pessoa em benefício da empresa, retirando poder de barganha deste profissional. Como disse, essa é uma visão estreita da questão, pois bons profissionais de verdade serão sempre disputados pela empresa para que desenvolvam cada vez mais o seu processo e não somente o seu produto.

3 elementos do processo

Mas o que é afinal um processo? Ele é a conjunção de três elementos que interagem constantemente: pessoas, procedimentos e ferramentas. Estes são considerados os ativos que uma empresa possui para que desenvolva seus processos. O erro mais comum que uma empresa pode cometer seria negligenciar um destes aspectos na condução de seu negócio: deixar de capacitar e estimular as pessoas, para que se sintam aptas e motivadas a usar o melhor de seus conhecimentos e habilidades em pról da obtenção de ganhos para a empresa; deixar de avaliar a adequação de seus procedimentos (tarefas, normas, orientações técnicas) ou de evoluí-los para avançar constantemente em sua melhoria; ou ainda deixar de investir em ferramentas que suportem estes procedimentos e facilitem a execução das tarefas pelas pessoas, agregando ao mesmo tempo produtividade, controle e aderência, liberando tempo precioso para atividade criativa, o que finalmente permitirá a inovação constante que espera-se irá manter os negócios na linha do tempo.
Percebe-se então que o processo é a base de um negócio, é seu ativo mais estratégico, o que o diferencia de um mero investimento para torná-lo uma entidade com personalidade própria percebida pelos clientes e colaboradores. Seria óbvio portanto imaginar que todo processo deveria evoluir a partir do planejamento estratégico da organização, maximizando a capacidade empresarial para extrair o melhor resultado das oportunidades e reduzir ao mínimo o risco das ameaças, fornecendo elementos para potencializar os pontos fortes e diminuir as vulnerabilidades do negócio. Seria óbvio, mas em muitos casos o foco da empresa – seja no nível operacional, tático ou estratégico – se desvia para questões mais imediatas, onde a gestão da qualidade perde para a urgência da gestão pelo fluxo de caixa. Quando fazer dinheiro é mais importante que construir um negócio sólido, é o momento em que o barco começa a fazer água e o profissional antenado deve procurar então um porto seguro para continuar sua vida e sua carreira.

Qualidade de Processo

Voltando à questão do processo, é axiomático dizer que “um processo de qualidade gera um produto de qualidade”. Apesar desta ser uma lei consolidada, apoiada em um século de observação e experimentação dentro da administração científica inaugurada por Taylor e Fayol no início do século XX, muitos profissionais e por consequência muitas empresas se perdem nesta questão, mantendo o foco tão somente na qualidade do produto, quando esta é um fim e não um meio em si. Na outra ponta deste cabo de guerra, o engano frequente é imaginar que então, para obter um produto de qualidade é preciso somente um processo (e ponto), e assim gasta-se muito esforço em manter as pessoas amarradas a este processo sem a interação crítica necessária para evoluí-lo. Voltando ao axioma citado no início deste tópico, para um produto de qualidade é necessário um processo de qualidade.
Aplicado ao desenvolvimento de software, podemos intuir que um processo de qualidade deve se ater aos fatores que elencamos – lá no início deste artigo – como elementos de qualidade de um produto de software. Então, para que o produto atinja as necessidades do cliente é fundamental investir num processo de requisitos que perceba e desenvolva criteriosamente estas necessidades, dotado de pontos de controle internos e externos ou, para falar em termos mais técnicos, verificados pela equipe e validados pelo cliente. Para que o produto seja robusto e com boa performance, é necessário um processo de engenharia que desenvolva a arquitetura mais adequada, num código limpo, claro e fácil de manter, cujas etapas sejam revisadas e controladas em pontos chave para corrigir na origem os possíveis erros de projeto. Por fim, para que se obtenha um produto confiável, é preciso estabelecer uma rotina de testes adequada à criticidade e finalidade do produto.
Um processo de qualidade é então aquele que atente para a obtenção da qualidade do produto em todas as suas etapas de desenvolvimento, antecipando falhas e verificando constantemente cada uma destas etapas quanto à adequação aos parâmetros esperados.

Melhoria continua

Simples, não? Basta então percebermos o que é necessário para obter este produto que queremos fazer e então temos um processo perfeito que deve ser elaborado, sustentado, mantido como um tóten sagrado, repetido como um mantra pela organização afora, certo? Errado. É praticamente impossível obter tal nível de qualidade partindo do zero e não se pode esperar uma eternidade para que este processo esteja pronto antes de começarmos a “rodar” o nosso negócio.
A solução é começar com o que se sabe, conhecer e estabelecer o processo natural da empresa e então passar a executá-lo, monitorá-lo e melhorá-lo constantemente num ciclo sem fim, para que se mantenha a empresa sempre à frente das demais (eis Deming novamente, com seu ciclo PDCA, tão simples quanto absoluto em termos de filosofia da qualidade). Até porque as pessoas mudam de empresa e então bastaria contratar um profissional que conhecesse bem o processo do concorrente para se obter o mesmo nível de qualidade deste e então poder lutar por sua fatia de mercado, ainda que levasse algum tempo. Justamente por isso é tão importante a melhoria contínua do processo e do produto, focando sempre na inovação, fazendo o cliente perceber necessidades que antes ele nem sabia que tinha e fazer com que ele sinta que não pode mais viver sem aquilo. Nem preciso citar exemplos na área de tecnologia para ilustrar isso, basta olhar à sua volta, caro leitor. Quando se obtém esse nível, o concorrente pode se esforçar por copiá-lo que quando conseguir o seu negócio já estará em outro patamar, de forma que a concorrência estará sempre “correndo atrás”.

Conclusão

A esta altura, esperamos ter sensibilizado o leitor para a efetiva importância de um processo de desenvolvimento de produto dentro de uma organização. Seu papel como fator estratégico para obtenção de diferencial mercadológico e portanto para sobrevivência do negócio da organização. Este é o cerne, o núcleo da gestão da qualidade, que é o tema deste blog, e que obviamente não se esgota nestas poucas linhas, mas que tem seu fundamento, seus alicerces, nestes conceitos.
Mais adiante vamos esmiuçar este universo para desvendar os inúmeros fatores que contribuem para o sucesso de um negócio, por enquanto foi fundamental compreender isso: um produto de qualidade não se obtém do nada, e não basta para uma organização o talento e esforço de um indivíduo para obtê-lo. Estes talentos, traduzidos em conhecimentos, habilidades e atitudes – ou resumindo, capacidades – devem ser absorvidos pela empresa, tornando-se ativos perenes desta e em constante desenvolvimento. O caminho para isso é um só: processo organizacional.

To PI or not to PI

Reproduzo abaixo artigo postado em maio/2007 no site Linha de Código, O texto foi enviado como resposta ao artigo "CMMI no olho do outros é refresco", de Mateus Velloso. A repercussão foi tal que o site resolveu publicar como artigo, pelo que fiquei muito grato. Vale lembrar a polêmica:

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 !!

O Que é Qualidade

O termo QUALIDADE é hoje utilizado quase que massivamente em vários contextos: qualidade de vida, qualidade nas relações, processos de qualidade, controle da qualidade, etc. Mas pergunte a qualquer pessoa não especialista e você terá diferentes visões ou definições do que seja qualidade. Justamente porque qualidade não é algo tangível, mas uma percepção, um sentimento, e como tal pode variar tanto em relação a sua definição quanto em relação a sua percepção de pessoa para pessoa.
No âmbito empresarial, a questão da qualidade começou a ser abordada durante os anos 50, na reconstrução da indústria japonesa do pós-guerra, ironicamente por dois americanos que não encontraram terreno para suas idéias nos EUA de então: Juran e Deming. A grande colaboração de ambos se deu no fato de colocarem a questão da qualidade como uma questão gerencial e não operacional, como a teoria clássica da administração tratava o assunto até então.
W. Edwards Deming definia a qualidade como um conjunto de características de um produto ou serviço desejadas e percebidas pelo cliente. Pela sua formação acadêmica foi pioneiro na utilização de métodos de controle estatístico para a gestão da qualidade ainda durante a guerra nos EUA, nos anos 40, e apesar de não o ter formulado, foi quem deu notoriedade ao ciclo PDCA, criado por Shewhart, que norteia todo e qualquer plano de melhoria contínua. É considerado como o principal responsável pelo renascimento industrial japonês e dá nome a um prêmio neste país dado às empresas que se destacam na área da qualidade. Joseph Juran ampliou a definição da qualidade com foco em dois aspectos distintos: a satisfação das necessidades do cliente - como Deming - e a ausência de defeitos.
Apesar de ser um conceito abstrato e intangível, a qualidade pode ser medida através da definição de seus atributos para um determinado produto ou serviço, atributos que podem ser objetivos - como a autonomia de vôo, o tempo médio entre falhas, etc - ou subjetivos - como o conforto, a elegância do design. Desta forma, devem ser estabelecidos métodos de aferição da qualidade que estejam de acordo com os requisitos percebidos pelo cliente.
A indústria do software passou a se interessar pelo tema da qualidade a partir dos anos 1980, em resposta à chamada "Crise do Software" definida no início da década anterior, evidenciada pelo aumento da demanda de software e pelo fato de constantemente os projetos de software fracassarem, seja em termos de estouro de prazos ou de custos, pela redução das funcionalidades entregues em relação às esperadas, pela alta incidência de defeitos ou até mesmo pelo não atendimento da demanda, ou seja, a não entrega do produto contratado. Entre os fatores que motivaram esta crise estava a falta completa de uma disciplina de engenharia de software, sendo que o desenvolvimento até então era uma tarefa basicamente empírica.

Nos anos 90 consolidou-se - em paralelo com a consolidação das disciplinas de engenharia de software - o modelo de maturidade conhecido como CMM (hoje CMMI), em resposta à demanda do departamento de defesa americano em relação a definição de requisitos para avaliação de fornecedores de software, ou seja, o CMMI nasceu como um check-list para identificar boas práticas na indústria de software. Em suma, foi uma demanda dos clientes e não da indústria do software. Em meados dos anos 2000, a agência fomentadora do software brasileiro (Softex), em conjunto com a COPPE/UFRJ, desenvolveram o MPS-Br, integrando o CMMI a outras normas mais abrangentes, notadamente a ISO 12207 e 15504. Trataremos destes modelos em outros artigos.
No contexto de TI o conceito de qualidade se expande em várias perspectivas, além da percepção do cliente, existem atributos de qualidade para os gestores (menor custo, previsibilidade dos projetos) e para os desenvolvedores (facilidade de manutenção, inteligibilidade de código), que expandem o conceito tradicional de qualidade e exigem mais ferramentas para sua obtenção.

Não é difícil perceber o quanto os conceitos da gestão da qualidade permeiam o modelo americano e seu derivado nacional, e o quanto as disciplinas da engenharia de software são voltadas ao atendimento destes conceitos: Desenvolvimento e Gestão de Requisitos (percepção das expectativas do cliente), Verificação e Validação (ausência ou diminuição de defeitos), Medição e Análise, Análise Causal, Gestão Quantitativa (controle Estatístico de Processos), além das disciplinas gerenciais, intimamente ligadas à questão da qualidade, compõem o arcabouço que sustenta o atual modelo de desenvolvimento de software. Metodologias de gestão e desenvolvimento de projetos mais recentes - que não devem ser confundidas com o modelo de desenvolvimento, mas o complementam -, como o Manifesto Ágil, o Seis Sigma, as técnicas de pensamento criativo, de gestão de serviços - como o ITIL - e de gestão integrada de TI - como o Cobit -, complementam o leque de ferramentas à disposição do gestor de projetos de TI e serão também abordadas neste blog.
Estão todos convidados à viagem.

Leia também estes bons artigos que localizei:
Os Papas da Qualidade
A Crise do Software

A Título de Preâmbulo

Criei este blog como uma forma de expor e debater conceitos e idéias sobre o tema da gestão da qualidade no contexto da melhoria de processos de software (MPS ou SPI, no inglês), e assuntos correlatos.
O intuito é o de manter um compêndio de informações em linguagem acessível, quase coloquial. O desafio de manter o didatismo associado a uma prosa mais fluida é - confesso - grande para mim. Conter a verve acadêmica e manter o foco na clareza de exposição de idéias é o objetivo.
Ao longo dos últimos anos atuando na área de MPS foram muitas as vezes que precisamos revisitar e repassar os conceitos sobre os temas expostos, seja em palestras, treinamentos, mentorias, seja no trabalho do dia-a-dia. Desta forma, este blog serve como um repositório destes conteúdos, à disposição dos consultantes.
Pretendo no decorrer do tempo identificar e nos associar a outros autores que discorrem sobre o tema, deixando desde já a anuência para a utilização de qualquer texto aqui postado, pedindo somente o crédito e quando possível o link para divulgação deste blog.
Conhecimento só é válido quando compartilhado.
Abraços, Roberto Slomka.