研发QA日常反思

一个组织要想健康运作，必然其中的关键人，干系人，项目负责人等是至关重要的。而实际上，经常发生貌似大家都在负责，又好像有的时候，又没有起到应有的作用和价值。

特别是跨部门沟通，对于没有明确划分的事情或者工作内容来讲，各个部门负责人和项目负责人们，可能很容易想到QA来协调这个事情。毕竟，很多时候，都可以联系到质量规范性问题，合规性问题。那么业务部门很容易一致决定，让QA来协调（背锅）这个事情。甚至让QA负责人来做决定，你们QA决定就好了，我们执行即可。

这个时候，坑已经挖好，一旦这个事情出现问题，那么他们会异口同声的会说，QA让我们这么干的，本来这个事情，我想那样干的，可是QA觉得这个事情不合规，可能有风险。

就拿一个研发项目来说，一个项目的成功，必定是各个口子的负责人以及相关人员共同努力的结果，而各个个体在项目成功之后的自我良好感觉，更多的是一种偏见和自负。

拿项目奖的时候，都觉得自己贡献巨大，使出了洪荒之力。

但是当项目出现问题的时候，立马撇清关系。基于这种情形，或者说人的本性天性，我们就在立项之初，就应该有一个相当清晰的目标和职责。你签字，代表你认同，代表你的责任，荣誉。一旦出现问题，也要担负起你应有的责任来。

QA是代替不了业务部门负责人和项目负责人的职责，除非QA是项目负责人，具有完全支配项目奖金和处罚的唯一负责人。

我在这里特别提醒的一点就是，如果出现相关负责人或者项目负责人不负责的行为，你告诉他们，有意见就提，没有意见就放行签字。不提意见不签字放行，就是刁难。

如果说QA替各个部门和项目负责人做决定，是一个错误。那么被其他部门视为障碍，可能更加悲哀。

原因很多，比如做出来吃力不讨好的决定，他们容易甩锅，你又觉得一肚子委屈。以至于后面你消极怠工，其他部门就慢慢地觉得QA是一个障碍，成事不足败事有余。

还比如，特别是项目进度，直属上级领导压制的很，天天催进度，进度，进度。那么如果你这个时候不知趣的去问质量规范性问题，或者去挑一些可能不是大问题的问题，或者他们认为不是大问题的问题的时候，他们心里大比例是视为障碍。

他们会觉得我们QA是给他们添乱，添堵，找麻烦，即使这个规范性问题存在，又如何？你们QA到底想怎么样？

这个问题，冷静下来想想是非常灵活拷问的。我们QA到底想干什么？还只是我们觉得应该这样更好，更完美？

这里就是一个非常关键的环节了。我们在提出疑问的时候，首先要想想我们提出这个缺陷，希望他们整改，到底想解决什么问题？如果这个问题，不解决，不处理，或者这么放着，会造成多大的后果，有没有必要再去试图所谓的完善？

我们不要把本来是质量规范性问题，硬生生整改成真实性问题。在研发阶段，或者在药品全生命周期内，有人的地方，必定是有问题，问题可大可小，可多可少。完全可以理解为是自然而然会发生各种各样的问题。也就是说无法完全避免所有问题的发生。

出现问题是常态，不出现问题才是非常态。因此我们没有必要对于一般性问题，上纲上线，对于一些普通问题，也没有必要细究，更没必要对某些人某个部门某个项目组贴标签，甚至上升到人身攻击。

在研发阶段，研发QA一个比较有挑战的工作就是在推进研发项目进展的同时，把研发的质量规范工作，研发的质量体系搭建起来，完善起来。或者反过来，我们在搭建完善研发质量体系的过程中，帮助项目组成长，把关真正的合规问题，质量规范性问题，真正去控制项目中存在的风险，去把握研发实验室存在的各种问题和隐患。

但是我们QA不要充当研发人员的保姆，提供喂饭服务，尤其是研发阶段，不要把任何环节想得过于细致和完美。

我们不可能穷尽所有可能，为研发人员提供一份完美的填写记录。抓住我们研发项目的本质，也紧紧围绕未来现场核查的侧重的点，以及这个产品样品的关键，不完美才是完美的表现。研发项目的快速推进，更需要我们在设置相关制度流程的时候，时刻保持清醒。

明白我们干什么。对研发项目有非常帮助的事情，我们要多干，对于研发项目和研发实验室没有太多益处的事情，我们尽力少干，或者不干。

那么到底什么是该干的，什么又不是不该干的。其实呢，非常简单。掌握几个基本原则即可，比如监管已经非常明确的要求，那必须掌握和执行到位。比如对于影响实验结果和方向的事情，我们必须把握准确，比如对研发项目造成较大风险的事情，我们尽力不干（比如删除，转移或者覆盖数据等行为）。

在研发阶段处处绣花，必定是作死节奏。

出现障碍，不必过于担忧，只要我们真心诚意为了项目，为了研发实验室，即便短时的委屈，也会迎来美好的未来。