Uma Percepção do Controle de Projeto

Controle de Projeto – já posso sentir daqui alguém torcendo o nariz 😛

Afinal, o que querem dizer o capítulo 4 da RDC 16/2013, a seção 7.3 da ISO 13485 e a seção 820.30 do CFR 21, dentre outros requisitos por aí que falam sobre o famoso (e infame) controle de projetos?

Para responder a essa pergunta nós certamente usaríamos inúmeros artigos, mas há alguns pontos de partida possíveis e interessantes nesse momento em que eu consigo ver daqui o mar de partes interessadas que seguem confusas com definições, conceitos, inter-relações, responsabilidades, processos, etc.

Por isso, resolvi fazer um artigo inicial referenciando uma pergunta muito comum, que ouço por aí com mais frequência do que gostaria. Logo abaixo da pergunta eu inseri a resposta em sua versão simples, que dá conta do recado para quem quer sair de situações confusas básicas.

Droga! O que aquele pessoal do/da [insira aqui sua autoridade competente ou organismo certificador preferido] quer que eu mostre? O que eu tenho que fazer? Que inferno!

Aqui, precisamos primeiro diferenciar dois conceitos importantes: requisitos x especificações. Não, eles não são a mesma coisa. Na verdade, eles funcionam assim:

Sei que não parece nada complexo e não é para ser mesmo. O que eu quero que você entenda aqui é que aquele pessoal (comumente referenciado utilizando adjetivos pouco amigáveis em momentos de fúria descontrolada) pede REQUISITOS. Você, caro colega, amigo, dono de empresa, diretor, gerente, sofredor, etc. responde com ESPECIFICAÇÕES.

Eu quero que você pare por um momento e reflita sobre o que eu estou dizendo aqui. Sério.

Quando alguém te diz: o carro precisa andar, a tampa precisa abrir, a luz precisa acender, isso é um REQUISITO.

Toda a base de componentes, configurações, materiais, conhecimentos, testes, aplicações, software e etc. que você vai planejar, selecionar, preparar, verificar e implementar para que aquilo ali em cima aconteça do jeito requisitado é um problema exclusivamente seu e se chama ESPECIFICAÇÃO.

O que acontece é que para os nossos amigos que nos regulam e nos certificam, e que vão te deixar fora do mercado sem cerimônias se preciso, existe um REQUISITO que é o maior de todos:

Você deve demonstrar segurança e eficácia do produto.

E note que eles são bem legais e deixam isso bem claro, emitindo outros documentos, como a RDC 56/2001 da ANVISA e os Essential Requirements da União Europeia (presentes tanto nas MDDs antigas como nas revigoradas MDRs), entre tantos outros. Aí cada território terá os seus, com suas especificidades.
Mas o foco aqui é você perceber que, para satisfazer um requisito, você precisa projetar especificações e demonstrar que elas serão consistentemente atingidas pelos seus produtos, seguindo essa lógica abaixo:

De novo, olhe com cuidado e reflita: você entra com algo, testa esse algo e observa se o que sai, o resultado, atinge a especificação que você definiu. Mas como sempre, tem uma sacada. Seu teste precisa conter duas coisas muito claras:

• Método: como eu testei? Note que as autoridades estão de olho nisso, afinal, você pode suavizar as coisas o quanto quiser, então é sempre recomendado utilizar NORMAS, pois se não for assim você também terá que explicar por quê seu método serve, mas esse é outro assunto.

• Critério: contra o que eu testei? De novo, as autoridades vão olhar isso com atenção, afinal, você novamente pode suavizar o quanto quiser, então… Já sabe, né? NORMAS! Aqui, no entanto, algo que acontece muito é existir uma norma para o método, mas que não tem critérios, ou que não se aplica inteiramente ao seu produto. Nessa hora, você terá que criar seu critério e, de novo, demonstrar que ele é adequado e isso é outra história também.

O que eu quero deixar claro para você nesse momento inicial é que cada pequena coisa que seu cliente espera, que o regulador demanda, que o médico quer, que a sociedade anseia, etc. são REQUISITOS.

E cada pequena coisa dessas, seja ela explicita ou não, se desdobra em outros REQUISITOS e depois em outros, em outros…

Cada uma delas o P&D vai ter que traduzir em ESPECIFICAÇÕES que respondem a todos eles e que precisarão ser verificadas.

De repente as coisas ficam assim:

E, perceba, as especificações começam a se conectar e interferir umas com as outras… Perceba também que tudo isso aí precisa ser verificado no projeto…

(Nesse momento, eu preciso parar e dizer: é isso que o pessoal do P&D fica lá fazendo e, deuses, parece que o projeto nunca sai! :P)

Mas volta aqui comigo! Vem pra cá!

O que eu quero deixar claro é que as autoridades competentes e organismos de certificação avaliam o REQUISITO, ou seja, não é exatamente, somente, exclusivamente o resultado do teste, mesmo que a tampa tenha aberto lindamente 100 vezes seguidas. Também não é o desenho, nem o certificado de matéria prima, nem nenhum relatório isoladamente ou aquele FMEA famoso que vai lá no meio (outro assunto para outro momento).

As autoridades competentes e organismos certificadores avaliam:

• A suficiência da sua demonstração de atendimento aos requisitos

• A adequação dos métodos e critérios utilizados para demonstrar o atendimento

Eu recomendo que você releia essas duas frases, depois leia o texto de novo até aqui, especialmente se forem questões com as quais você tem se debatido e se gestão de projetos é um tópico pouco usual para você.

Esses pontos acima são cruciais para entendermos que quase nunca é uma questão de certo e errado, mas sim de domínio e aplicação correta de conceitos e, acima de tudo, de profundo conhecimento sobre aquele projeto e o produto que vai nascer dele. Se não conhecemos o projeto a fundo, se não sabemos o que queremos dele, se não gastamos um tempo especificando como responder aos requisitos vamos sofrer muito nesse vai e vem e, mais, qualquer pessoa que chamarmos para “resolver o problema” vai sofrer também.

E se essa pessoa resolver sem domínio técnico e tecnológico real do produto, sem informação vinda de um P&D no qual se possa confiar, ainda incorremos na situação (complicadíssima) de colocar um produto no mercado passando adiante um kit de informações provavelmente imprecisas e perigosas, que podem afetar a segurança de médicos e pacientes.

O propósito da SQR Consulting também passa pelo combate a essa situação.

Mas isso é conversa para outro dia 😉

————————————————————————————————————————————————-

Bruno Oliveira | Regulatory Client Manager – SQR Consulting

Atuo como Regulatory Client Manager na SQR Consulting e sou um apaixonado pela escrita.

Se você gostou desse conteúdo e ele ressoa com os seus valores, não deixe de interagir, comentar, compartilhar e fique à vontade para me chamar para um bate-papo!