DISSECANDO PROJETO E DESENVOLVIMENTO

DISSECANDO PROJETO E DESENVOLVIMENTO – PARTE 1

Vamos dar uma olhada mais detalhada no requisito 7.3, já que é nele que se encontram as maiores dúvidas de interpretação dos leitores do blog. Já havia escrito outro artigo falando sobre ele, mas não tão aprofundado. O texto da norma estará transcrito aqui em vermelho, para facilitar o acompanhamento. Tentarei dar dicas que atendam projeto de produtos e de serviços.

Como será um texto longo, dividirei em partes. A primeira, que é esta, já poderá dar bastante esclarecimento sobre o que fazer para atender o 7.3:

7.3.1 Planejamento do projeto e desenvolvimento

 A organização deve planejar e controlar o projeto e desenvolvimento de produto. Durante o planejamento do projeto e desenvolvimento a organização deve determinar:

 a) os estágios do projeto e desenvolvimento,

 b) a análise crítica, verificação e validação que sejam apropriadas para cada fase do projeto e desenvolvimento, e

 c) as responsabilidades e a autoridade para projeto e desenvolvimento.

Sempre que vir a palavra produto neste requisito considere que ela equivale a serviço, se for o seu caso. As três alíneas acima não são tão complicadas quanto parecem. Um dos maiores erros ao interpretar o 7.3 é achar que cada item dele deve ser aplicado individualmente em todos os projetos, o que não é verdade. Partes dele se aplicam ao processo de gerenciamento dos projetos portanto, uma vez definidas, já estão atendidas a cada vez que se cria um novo projeto. Vamos olhar cada uma agora:

a) os estágios do projeto e desenvolvimento,
Estes estágios podem variar a cada projeto ou não, dependendo do tipo de projeto. As fases ou estágios podem ser, por exemplo:

Especificação: Requisitos iniciais que deverão ser atendidos pelo produto ou serviço. Faz parte das entradas de projeto e definem as necessidades existentes e que o produto ou serviço deverão atender.

Design e/ou Materiais: Onde definimos os materiais pretendidos ou recomendados para atender as especificações estabelecidas. Pode incluir a escolha de cores, texturas, tamanho, etc… Num projeto de construção civil por exemplo seria o memorial da obra.

Inspeção: Os pontos onde, durante o desenvolvimento do projeto ou do serviço, podem ser feitas inspeções para garantir que a execução está correndo conforme o projetado. São as análises críticas e verificações de que fala a alínea “b”. As análises críticas também ocorrem quando temos que mudar algo no projeto por algum motivo.

Esses são apenas alguns exemplos de estágios (ou fases) do desenvolvimento de um projeto. Cada área tem suas particularidades e, quando se fala em projeto e desenvolvimento do produto ou serviço, elas devem ser consideradas.

b) a análise crítica, verificação e validação que sejam apropriadas para cada fase do projeto e desenvolvimento,
Cada fase do projeto, da criação de um produto ou da execução de um serviço, podem precisar (ou não) de análise crítica e verificações. A análise crítica trata basicamente de constatarmos se estamos indo na direção correta e prevista. Pode ser feita por um determinado profissional que acompanha os trabalhos ou por um grupo, em reuniões. A melhor forma só pode ser determinada considerando-se a complexidade do projeto. Uma reforma pode ser acompanhada e analisada por um arquiteto. A construção de um foguete terá uma infinidade de profissionais envolvidos e tarefas sendo executadas simultaneamente… A análise crítica se baseia geralmente em informações e as verificações em acompanhamento local do trabalho.
A validação é outra coisa. Significa garantir que o resultado esperado foi alcançado ou superado. Pode ser feita no final do desenvolvimento ou pode ser necessária em determinados estágios. Quer um exemplo simples? Para pintar uma parede é necessário verificar se o acabamento de base está adequado. O pintor verifica se foi passado um selante, testa se ele está suficientemente seco, e só então começa a aplicar a tinta. Antes de dar outra demão de tinta, ele verifica novamente se a camada anterior está seca. Nesses momentos ele está fazendo uma verificação do projetado, e também uma validação da etapa anterior. Através de uma conversa entre ele e o arquiteto (uma análise crítica), podem decidir não aplicar mais demãos de tinta, ou o contrário. Essas decisões alteram de alguma forma o projetado.

c) as responsabilidades e a autoridade para projeto e desenvolvimento.
Cada fase pode ter um responsável pela execução, pela verificação, pela validação… É a mais simples das alíneas, pois basta definir desde o início do trabalho quem é responsável pelo quê, para cada fase. Já viram um desenho de peça? Num dos cantos tem sempre uma espécie de tabela onde constam o nome de quem desenhou, quem verificou e quem aprovou aquele desenho. É uma evidência de que as responsabilidades e a autoridade foram definidas.

A organização deve gerenciar as interfaces entre diferentes grupos envolvidos no projeto e desenvolvimento, para assegurar a comunicação eficaz e a designação clara de responsabilidades.
As saídas do planejamento devem ser atualizadas apropriadamente, na medida em que o projeto e o desenvolvimento progredirem.
Esta parte do 7.3.1 pode estar definida em um procedimento, no Manual da Qualidade, ou em alguns casos até mesmo no próprio projeto! O importante é que seja estabelecida uma forma clara de comunicação entre os membros de uma equipe e entre várias equipes que porventura estejam envolvidas num mesmo projeto. Pode ser definido por exemplo que todos os assuntos serão tratados por e-mail, ou que será feita uma reunião semanal e lavrada uma ata… Um pouco antes comentei que a construção de um foguete envolve muita gente. Já pensou se isso vira uma Torre de Babel? – O foguete não vai sair nunca e o que vai para o espaço é o projeto! Por isso a ISO volta a frisar que as responsabilidades devem estar claramente definidas desde o início do projeto. E afirma também que desde o início deve ter alguém responsável por manter atualizadas as saídas do projeto e desenvolvimento na medida em que aconteçam. Essas atualizações poderiam ser reportadas pelo líder de cada equipe e centralizadas no responsável maior pelo projeto, que acompanha os cronogramas e os atualizaria conforme o andamento dos trabalhos.

NOTA: Análise crítica de projeto e desenvolvimento, verificação e validação têm propósitos distintos. Estas atividades podem ser conduzidas e registradas separadamente ou em qualquer combinação, na forma adequada para o produto e a organização.
Esta nota serve apenas para alertar que a ordem das atividades não precisa obedecer necessariamente uma estrutura rígida. Quantas e quais análises críticas serão necessárias, quais verificações e validações deverão ser feitas e em quais momentos, tudo isso pode ser livremente definido pela organização e não pode ser questionado. Dependendo da complexidade do projeto, volto a dizer, essas atividades podem ser feitas simultaneamente, num mesmo momento.