DISSECANDO PROJETO E DESENVOLVIMENTO

...

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.

Para facilitar o planejamento do projeto e desenvolvimento, desenvolvi em conjunto com um engenheiro de desenvolvimento um check-list que facilita bastante as definições iniciais e o acompanhamento de qualquer projeto. Para cada etapa, você tem total liberdade para expandi-la e detalhar, ou mesmo informar que ela não se aplica.

PARTE 2

Hora de mais uma parte do 7.3. Trataremos agora das entradas de projeto e desenvolvimento, o item 7.3.2, cujo texto está destacado em vermelho:

7.3.2 Entradas de projeto e desenvolvimento

As entradas relativas a requisitos de produto devem ser determinadas e registros devem ser mantidos (ver 4.2.4).

Essas entradas devem incluir

a) requisitos de funcionamento e de desempenho,

b) requisitos estatutários e regulamentares aplicáveis,

c) onde aplicável, informações originadas de projetos anteriores semelhantes, e

d) outros requisitos essenciais para projeto e desenvolvimento.

As entradas devem ser analisadas criticamente quanto à suficiência. Requisitos devem ser completos, sem ambigüidades e não conflitantes entre si.

Se você baixou o formulário que indiquei no artigo anterior, verá que ele tem campos para todas as entradas. Se não baixou, leia o artigo anterior antes clicando aqui e aproveite para pegar o seu.

As entradas relativas a requisitos de produto devem ser determinadas e registros devem ser mantidos (ver 4.2.4).

Antes de mais nada, é importante saber que a norma pede que existam registros do projeto desde o seu início. Portanto, o planejamento já é o começo deste registro. O formulário sugerido é uma boa solução porque já mantém estes registros desde o início. Antes de falar mais sobre isso, vamos ver cada tipo de entrada que um projeto pode ter.

a) requisitos de funcionamento e de desempenho,

Para um produto fica fácil. É o que se espera dele, quanto deve durar, o que deve resistir (Será a prova d’água? Irá suportar quedas? Vai funcionar a bateria ou não? Precisa suportar pressão?). São as características esperadas para o produto que será criado.

Para um serviço isso fica mais subjetivo, mas ainda assim dá para determinar seu funcionamento e desempenho. Um bufê por exemplo, que fornece seu trabalho para eventos, precisa saber quais os requisitos que terá que atender. Quantos garçons vão ser necessários? Quanto de bebida e quais? Que tipo de convidados estarão no evento? Esses são alguns exemplos de entradas que caberiam nessa alínea.

E quem fornece projetos (hidráulicos, elétricos, civis…)? Os requisitos de funcionamento e desempenho incluiriam número de pontos de tomadas, tipos, pontos de iluminação, onde precisaria de dimmers, essas coisas…

b) requisitos estatutários e regulamentares aplicáveis,

Esta alínea inclui normas aplicáveis que precisarão ser consideradas no projeto. Voltando ao exemplo do bufê, poderíamos considerar o traje dos funcionários, o menu… E se for preciso ter garçons que falem inglês para atender convidados internacionais? Esses não são requisitos legais, mas fazem partes de normas sociais que para um bufê funcionam como leis, não é mesmo?

c) onde aplicável, informações originadas de projetos anteriores semelhantes

Pode ser que algumas características do produto ou serviço já foram atendidas com sucesso em projetos anteriores, então por que não aproveitar? Na hora de atender essa alínea é que percebemos o quanto pode ser útil manter um histórico dos projetos já executados e validados! Num projeto de software, por exemplo, é comum se aproveitar bibliotecas de funções criadas para programas já existentes. Soluções consagradas em serviços anteriores poupam muito trabalho e oferecem um ganho de agilidade no novo projeto. Só devemos tomar cuidado, pois nem sempre o que foi válido em um caso será garantia de sucesso em outro. Avalie criteriosamente antes de decidir.

d) outros requisitos essenciais para projeto e desenvolvimento.

Aqui entram as particularidades de seu