Faça corretamente


gerente-projeto-qualidade

A maioria diria que são os membros da equipe de um projeto, e não o gerente do projeto, que criam um produto de qualidade. Eles acreditam que a qualidade significa fazer um trabalho de qualidade, ou, que possa ser testado. Mas, na verdade, o gerente de projeto tem muito a contribuir para um produto de qualidade, começando com o cronograma e a comunicação.

Cabe ao gerente de projeto garantir a entrega de um produto final de qualidade. Uma triste realidade é que muitos projetos falham porque a qualidade do produto final não é aceitável. No entanto, poucos gerentes de projeto têm experiência direta no papel da qualidade. Então, aqui vamos abordar o que um gerente de projeto pode fazer para assegurar que a qualidade seja incorporada ao projeto.

O que é qualidade?

Uma definição bastante comum de qualidade vem de Philip Crosby, que era gerente de controle de qualidade do programa de mísseis Pershing: “Qualidade é conformidade com os requisitos”. É uma definição bem conhecida, com algumas palavras que são cativantes e fáceis de lembrar. No entanto, se você perguntasse o que “conformidade com os requisitos” realmente significa, você provavelmente teria alguma hesitação ou um olhar vazio. A maioria esperaria que fosse auto-explicativo, mas na realidade, eles realmente não entenderam nada.

A palavra-chave nessa definição é requisitos. Crosby quer dizer muito mais do que apenas uma especificação ou uma lista de recursos que descreve o produto final. Em vez disso, ele está falando de todos os requisitos que asseguram a criação de um produto final de qualidade. Isso inclui processos organizacionais, que são requisitos de como executar o trabalho da melhor forma.

A partir de uma perspectiva de gerenciamento de projetos, podemos substituir as necessidades do usuário por requisitos, pois gerenciar qualidade requer saber quem são todos os usuários e o que é que eles precisam para considerarem que trabalho teve qualidade.

A Cadeia de Qualidade

As necessidades do usuário levam para a cadeia da qualidade – conforme produtos intermediários (por exemplo, documentos) vão sendo desenvolvidos, estes são usados para o desenvolvimento dos próximos produtos do projeto corretamente. Ao traçar o fluxo de informações ou resultados reais através do projeto você pode definir quem são os usuários e o que eles realmente precisam.

Considere o seguinte: Quantas vezes você encontrou a documentação para um hardware ou produto de software recém-adquirido sendo inadequada, enganosa ou confusa? A documentação do usuário é freqüentemente gerada por um grupo de escritores técnicos, que contam com informações da equipe de desenvolvimento. Ou seja, eles estão entre os usuários dos documentos da engenharia. Para assegurar a qualidade da documentação do usuário final, os documentos de Engenharia devem atender às necessidades deste usuário, e não da equipe de desenvolvimento. Eles devem trabalhar em conjunto para identificar quais informações são necessárias. Aqui, a engenharia deve assumir a liderança, uma vez que eles entendem melhor o produto. Os profissionais de documentação simplesmente extraem informações dos documentos da engenharia para convertê-los em uma forma mais útil para um não engenheiro.

Documentos de engenharia também são usados para planejar e definir os testes para o produto final. Aqui, as deficiências dos documentos podem resultar em um produto final que não esteja adequadamente testado. Assim, para ter certeza de que as necessidades dos usuários estão sendo atendidas, todos os membros da equipe que usam um determinado documento devem se certificar de que ele esteja de acordo com suas necessidades. O trabalho do gerente de projeto é garantir que este seja o caso, especialmente quando há problemas crônicos e repetidos de qualidade como uma documentação de usuário pobre.

Atividades de qualidade

Atividades de qualidade geralmente caem em duas categorias:

1. Garantia de Qualidade (GQ) é fazer as coisas certas para se ter certeza de que a qualidade esteja incorporada no projeto. Um exemplo seria incluir um passo a passo para o código para garantir que os padrões de codificação estão sendo seguidos.

2. Controle de Qualidade (CQ) é verificar que todas as entregas atendem aos padrões de qualidade – que sejam aceitáveis para seus usuários. É importante saber o que é aceitável (os critérios de aceitação) e depois fazer o que é necessário para atingir os critérios. Revisões de projeto e testes são as principais formas de controle de qualidade.

Os detalhes destas categorias são freqüentemente definidos pelos processos de uma organização, e podem ser bastante específicos. Em seguida, o gerente de projeto deve entender os processos bem o suficiente para ter certeza de que estejam sendo seguidos com base em como eles se aplicam a cada projeto. Deficiências comuns são ignorar os processos que não são conhecidos ou entendidos, ou seguir cegamente processos que não são necessários ou que podem ser simplificados. Qualquer uma dessas deficiências pode resultar em produtos de má qualidade.

As revisões de projeto são um processo de controle de qualidade comum, que podem ser usadas para verificar que o produto a ser revisto satisfaz as necessidades de todos os que o irão utilizar. Um grande desafio em uma revisão de documento é assegurar sua integridade. A maioria dos revisores se concentra na correção porque é mais fácil apenas apontar os defeitos dos outros. Portanto, é importante incluir revisores que sejam capazes de encontrar as lacunas, e então, durante a revisão, perguntarem freqüentemente aos revisores, se alguma coisa está faltando.

Entretanto, os gerentes de projeto têm mais controle sobre a qualidade do que garantir que os processos de controle e garantia da qualidade sejam seguidos.

Desafios para a Qualidade

Muitos dos desafios diários que um gerente de projeto enfrenta podem ter um impacto negativo sobre a qualidade do produto final quando eles não são devidamente geridos. Alguns dos que eu tenho freqüentemente encontrado incluem:

Prazos irrealistas: Na minha experiência, este é um dos maiores desafios para a qualidade. O prazo é especificado e o gerente de projeto é pressionado a montar uma agenda para cumprir esse prazo. O tempo atribuído para o desenvolvimento e teste não está baseado no trabalho total necessário. Pessoas ou até mesmo equipes inteiras são forçadas a tomar atalhos que comprometem seus trabalhos. As comunicações serão reduzidas na medida em que indivíduos se concentram em seus próprios prazos e não têm tempo para outros membros da equipe. Eventualmente, o projeto cai por terra: as peças criadas pelas pessoas não se encaixam e os testes, que agora levam muito mais tempo, são cortados para tentar se manter próximo do prazo irrealista. Resultado: os diversos defeitos adicionados pelos atalhos e a falta de trabalho em equipe não são encontrados durante os testes, mas são encontrados pelos clientes.

“Nós contra Eles”: Em equipes multi-disciplinares, um grupo (Nós) enxerga a maioria dos problemas causados por um outro grupo (Eles). Ao invés de trabalharem juntos como uma equipe, cada grupo apenas se queixa do outro. Exemplos que eu tenho visto incluem Engenharia vs.Controle de Qualidade; Marketing vs.Engenharia vs. Vendas; Engenharia vs.Produção. Aqui, cada lado vê o outro como “Eles”.

Foco na diversão: Algumas pessoas preferem se concentrar nos aspectos divertidos de seu trabalho e encobrem o que eles consideram ser muito trabalhoso. Uma vez que o resultado desse “muito trabalhoso” é importante para o trabalho do indivíduo, bem como dos outros no projeto, a qualidade sofre. Por exemplo, a falta de dedicar um tempo para projetar corretamente uma interface complexa pode resultar em certas características serem ignoradas, causando retrabalho quando a omissão for descoberta. Retrabalho apressado resulta em uma pobre implementação com defeitos ocultos.

Comunicação pobre: A informação necessária não é compartilhada entre indivíduos e grupos. Isso pode ser o resultado de prazos irrealistas e do que chamei acima de “Nós contra Eles”. Também pode ocorrer quando os membros da equipe estão distraídos por muitas coisas fora do projeto, ou não vêem a importância de todas as comunicações.

Lidar com essas e outras “questões pessoais” pode fazer tanto, e às vezes mais pela qualidade do que garantia e controle da qualidade.

Faça Corretamente

Há um velho ditado: “Não temos tempo para fazer isso corretamente, mas sempre temos tempo para fazer tudo de novo!” Isso é tão verdadeiro hoje como era há 50 anos. Ao concentrar-se no que é preciso para fazer isso corretamente, você pode tanto ter um melhor controle sobre o seu projeto, como entregar um produto de qualidade.

Una toda a equipe o mais rápido possível para perguntas informais e sessões de resposta. Isto irá desarmar as questões “Nós contra Eles” e garantir que todo mundo tenha entendimento do projeto e de seus desafios. Se aqueles que pressionam o prazo puderem ser envolvidos, poderá ajudá-los a ver o que pode e não pode ser feito.

Crie um plano realista que estabeleça as contribuições de cada membro. Ele fornecerá fatos sobre o projeto para abrir um diálogo significativo sobre uma data de conclusão apropriada. Se o prazo irrealista for, de fato real, então o plano irá mostrar onde mais recursos podem ser adicionados de forma produtiva, ou qual funcionalidade pode ser reduzida ou eliminada. Quando criado pela equipe do projeto, o plano realista ajuda a combater o “Nós contra Eles”, já que a equipe cria o plano que destaca o papel de cada participante. O plano também ajuda a lutra contra o “foco na diversão” já que ele reforça o que deve ser feito, e o impacto para os outros sobre o projeto se não for assim.

Certifique-se de que o seu plano inclui uma estratégia iterativa. Concentre-se nas necessidades do usuário final e nas prioridades do projeto para determinar os itens que devem ser feitos o mais cedo possível. Isso garante que, mesmo que você não tenha terminado o projeto, você tem algo que é útil para o seu usuário final.

Inicie cedo a integração e teste para que o teste não seja deixado de lado até o fim. Quando as coisas demorarem mais tempo do que o planejado, e há pressão para apressar e terminar, você deve ter uma grande parte da funcionalidade do usuário final funcionando e testada.

Integração e testes no começo do projeto também ajudam a lidar com problemas de comunicação. Os desenvolvedores têm que trabalhar juntos antes e durante os freqüentes ciclos de integração. Quando a integração é ignorada até as fases finais do e os recursos estão sob pressão para mostrar progresso, eles podem passar muito tempo fazendo um monte de trabalho com comunicação mínima. É responsabilidade do gerente do projeto facilitar a comunicação adequada entre os membros da equipe.

Autor: Vincent McGevna, Gerente de Projetos Senior

Artigo publicado originalmente no site Projects at Work

Publicidade