一个密封圈引发的四部门“混战”：医械研发为何亟需“系统工程思维”？
2026-3-30 11:28|
编辑: 沙糖桔|
查看: 115|
评论: 0|来源: 小桔灯网丨作者：沧海一豆
摘要: 好产品不是某个模块单独赢出来的，而是一整套系统共同打出来的。
| 电话那头语气很急：设备停机了，屏幕弹了一个谁也看不懂的报错代码，样本卡在进样通道里出不来，整条检测线瘫痪。我们的售后工程师当天晚上就飞过去了。背着二三十斤的备件箱，落地已经夜里十一点。到了现场，先看日志——日志只记录了一个模糊的通信超时错误。换了通信板卡，重启，还是报错。再查进样机构，发现推杆电机堵转，轴承卡死。换了电机组件，样本能动了，但检测结果漂移严重，根本没法用。折腾到第二天下午，真正的根因才慢慢浮出水面：进样通道的机械公差和液路接口的密封设计之间存在配合偏差，长期运行后密封圈被挤压变形，电机堵转，而且导至微量气泡混入光路。气泡影响了光学检测信号，软件误判为通信异常，触发了那个莫名其妙的报错代码。一个密封圈的问题，牵出了机械、流体、光学、软件四个专业的连锁反应。客户停机两天半。我们搭进去差旅费、备件损耗、工程师的两个通宵，加起来小几万块。客户对我们的信任打了折扣，这是最致命的。事后复盘，团队里吵了一架。机械说液路接口定义不清楚，流体说密封件选型是按机械给的尺寸来的，软件说报错逻辑是按硬件给的信号规范写的，光学说从来没人告诉他们进样通道可能进气泡。每个人说的都有道理。每个人在自己的模块里都没犯错。这件事让我想了很久。医疗器械项目真正拖垮团队的，往往不是某个模块的技术难题——那种问题反而好办，集中资源攻关就是了。真正要命的，是这种没人看见的系统性失配：需求没对齐、接口没拉通、验证没覆盖，每个人都觉得自己做对了，但组合在一起就是一个坑。医疗器械研发不是拼谁更会做功能，而是拼谁更会统筹复杂性。法规、风险、接口、验证、成本、进度——这些维度同时作用在一个产品上，任何一个维度失控，都可能引发连锁反应。而能在这些维度之间建立秩序、提前看见风险、让团队少踩坑的那套方法，就是系统工程思维。但，它不是少数岗位的专利。它是所有做产品的人，迟早要补上的一课。很多人一听"系统工程"，脑子里浮现的画面可能是：一堆架构图、一摞需求文档、一张密密麻麻的接口矩阵。我见过不少团队，需求文档写了几百页，架构图画得漂漂亮亮，接口表填得整整齐齐——但项目照样延期，现场照样出问题。为什么？因为他们做的是"系统工程的动作"，而不是"系统工程的思维"。系统工程思维的内核只有一件事：在系统还没失控之前，预见复杂性、组织复杂性、收束复杂性。这不是某家公司发明的管理方法。INCOSE（国际系统工程协会）、NASA系统工程手册、ISO/IEC 15288——这些跨行业、跨国界沉淀了几十年的知识体系，核心讲的都是同一件事：当一个系统复杂到没有任何一个人能独自理解全貌的时候，你需要一套方法来驾驭它。你可以把系统工程思维理解成产品开发的"底层操作系统"。软件工程师、硬件工程师、机械工程师、测试工程师——每个人都是跑在这个操作系统上的"应用程序"。应用程序各管各的功能，但如果底层操作系统不稳定，所有应用程序都会崩。一切设计都源自于需求，这是最关键的一环。定义问题边界。听起来简单，做起来最难。太多项目的失败，不是因为做错了，而是因为从一开始就没搞清楚到底要解决谁的什么问题。用户说"设备要稳定"，这不是需求，这是愿望。把愿望翻译成可量化、可验证、可追溯的技术指标——这才是需求工程的真功夫。把一个复杂问题拆成若干个可以理解、可以分工、可以独立验证的子问题。好的架构不是画出来好看的，而是拆出来好干的。每个子系统的边界清晰、职责明确，团队才能并行推进而不互相踩脚。这是我认为最被低估、也最容易出事的一环。模块和模块之间的缝合处，永远是故障高发区。回头看我开头讲的那个案例——机械、流体、光学、软件，每个模块内部都没问题，但它们之间的接口没人管。接口管理的本质，是盯住"缝隙"，而不是只盯"模块"。做出来的东西到底对不对？是不是用户想要的？很多团队把"验证"等同于"做测试"，跑完用例、出了报告就算完。但验证的真正目的不是走流程，而是回答一个问题：我们做出来的产品，放到真实使用场景里，能不能真正解决用户的问题？产品不是交付了就结束了。制造的一致性、售后的可维修性、未来的可升级性、法规变化带来的合规成本——这些如果不在设计阶段就纳入考量，后面每一个都会变成一颗定时炸弹。这五环不是线性的流水线，而是一个不断迭代、互相咬合的闭环。需求变了，架构要调；架构调了，接口要重新定义；接口变了，验证策略要更新。它们之间的联动关系，就是系统工程师每天要操心的事。说到这里，一个关键问题来了：系统工程师在团队里到底扮演什么角色？我常用一个比喻：系统工程师像将军，专业工程师像战士。将军决定仗往哪个方向打、先攻哪个山头、后守哪条防线。战士的任务是把每一个战术动作做到位——枪法要准、阵地要守住、弹药要管好。在产品开发中，系统工程师的职责是自顶向下分解：从用户需求出发，定义系统架构，分解到各子系统，明确接口约束，制定验证策略。而专业工程师的职责是自底向上集成：在各自的专业领域里做深、做透，然后把模块一个一个拼回完整的系统。“指导员”曾经说过：”在战场上，我们要在战略上藐视敌人，在战术上重视敌人”。这句话用在产品开发上一样成立——系统工程师要敢于做取舍、定方向、砍需求；专业工程师要扎实、严谨、对细节较真。两者缺一不可。因为医疗器械不是普通消费品。从第一天起，你的设计就要面对ISO 14971的风险管理要求、21 CFR 820的设计控制规范、IEC 62304的软件生命周期标准。每一份设计输入都要可追溯，每一个风险都要有控制措施，每一项变更都要走流程。在这样的约束下，系统工程不是锦上添花的方法论，它更像地基。刚入行那几年，我的全部注意力都在自己负责的模块上。液路设计、光学信号完整性、验证方案——每天想的就是怎么把参数调到最优、怎么让CV更漂亮。评价标准也简单：指标达标了，功能跑通了，就算成功。那时候我觉得，只要每个人都把自己的模块做好，产品自然就能成。有一次，我负责的检测模块所有指标都完美通过了单板测试。但一装到整机里，和别的模块一联调，问题就来了。信号在接口处出现了意料之外的干扰，软件那边解析出了错误数据，整台设备的检测精度直接不合格。我当时很委屈——我的设计没问题啊。但产品经理说了一句话，我到现在都记得："你的模块是没问题，但产品有问题。"那一刻我意识到，模块做对和系统做对是两回事。系统的问题往往不是出在模块内部，而是出在模块之间的边界、接口、时序配合、场景遗漏。自那以后，我开始有意识让自己去关心"我的模块之外"的事情。上游的需求到底怎么来的？下游的软件打算怎么用我的信号？机械给我留的空间够不够散热？测试打算怎么验证这个功能？这个坎一旦迈过去，看问题的视角就完全不同了。我不再只对自己的图纸负责，我开始对产品的整体结果负责。做了十年以后，我发现系统工程师的价值远不只是解决技术问题。制造端的工艺能力、售后端的维修效率、法规端的合规成本、项目端的资源调度——这些因素都会反噬产品的最终表现。一个系统工程师如果只会画架构图、写需求，那只是"初级版本"。真正成熟的系统工程师，是能在这些维度之间做权衡、建共识、推决策的人。第一句靠需求分解能力，第二句靠方法论积累，第三句靠设计意识、经验判断和组织影响力。三句话对应三种完全不同的能力模型。还有一个我观察了多年的现象，值得单独拎出来说：产品开发的成败，往往取决于两个关键角色的配合——系统工程师和项目经理。系统工程师是技术方向上的将军。他管的是：这个产品的技术路线对不对？架构合不合理？风险大不大？哪些需求该砍？哪些接口有隐患？项目经理是项目执行上的将军。他管的是：进度卡不卡？资源够不够？里程碑能不能按时达成？跨部门的协调是否到位？两个人都在管全局，但一个管"做什么和怎么做"，一个管"什么时候做完和谁来做"。我见过很多项目，只有项目推进的节奏，没有技术判断的把控——结果就是按时交付了一个有严重缺陷的产品。也见过反过来的：技术方案翻来覆去地优化，但没有人收口，项目一拖再拖。两个将军必须配合。一个仰望星空，一个脚踏实地。缺了任何一个，仗都打不赢。几年前，我们团队接手了一个IVD检测设备的开发项目。产品功能不算复杂：自动化样本处理、多通道光学检测、结果判读输出。团队配置也不差：有经验的硬件工程师、算法工程师、机械工程师，项目经理也是老手。但第一代产品的开发过程，只能用"一地鸡毛"来形容。需求是碎的。 市场部给了一份好几页的"用户调研报告"，里面既有"操作要简便"这样的模糊描述，也有"检测精度CV值≤5%"这样的量化指标，但哪些是必须满足的、哪些是期望满足的、不同需求之间的优先级和矛盾关系——没有人梳理。研发拿到手直接开干，遇到矛盾就自己拍脑袋决定。架构是散的。 每个专业组各自出方案，硬件选了自己最熟悉的平台，机械照着上一个项目的结构改，软件觉得架构图"后面再补也来得及"。结果到了联调阶段才发现：硬件给软件的ADC采集通道数不够，机械给光学留的安装空间和光路计算的焦距对不上，液路接口的流量特性和软件预设的参数差了一个数量级。验证是晚的。 整机联调被推到了项目中后期，之前都是各模块"自己测自己"。等整机一跑，问题集中爆发。有些功能在单模块测试时完美通过，到了整机环境下就不行了——因为边界条件变了、干扰源多了、时序关系复杂了。结果是贵的。 第一轮注册检验没过，关键性能指标不达标。返工了三个多月，项目延期半年。团队士气低落，跨部门协作关系一度很紧张。然后我们做了一件事：暂停了所有"救火"行动，花了两周时间，用系统工程思维的方法把整个产品的开发流程重新拉通了一遍。我们把市场调研报告拆成了三级需求——用户需求（URS）、产品需求（PRS）、设计需求（DRS）。每一条需求都有明确的前后溯源和验收标准。更重要的是，需求之间的矛盾关系被显性化了。比如"检测速度要快"和"检测精度要高"之间的trade-off，不再由工程师私下决定，而是在需求评审会上由产品、研发、工程共同确认。从此以后，所有人对"这个产品到底要做成什么样"有了一个共同的理解基准。我们建立了一份系统级接口控制文档（ICD），把机械-流体、流体-光学、光学-电子、电子-软件之间的每一个接口都定义清楚：物理尺寸、电气信号、数据协议、时序约束、公差范围。接口定义不是由某一方单独给出的，而是由相关双方共同协商、共同签字确认。这件事花了不少时间，但效果立竿见影。后来联调阶段出现的接口问题，比第一代产品减少了70%以上。我们在方案设计阶段就启动了系统级FMEA。不是走形式那种，是真的把团队拉到一起，逐项讨论：如果这个模块这样设计，在什么场景下可能出什么问题？影响有多大？我们现在有什么手段来控制？这个过程很痛苦，因为它要求工程师在设计还没完成的时候就去想失败的可能性——这和大多数人"先做出来再说"的思维惯性是冲突的。但正是这种"提前想失败"的习惯，帮我们在设计阶段就砍掉了好几个高风险方案。我们为每一条关键需求都定义了验证策略：用什么方法验证（分析、测试、检查、演示）？在哪个阶段验证？验证通过的标准是什么？判定不通过怎么处理？这条链路从需求出发，贯穿设计、实现、测试全过程，确保每一个关键需求都有证据闭环。不再是"感觉差不多了就提交注册"，而是"每一条需求都有白纸黑字的验证记录"。第二代产品用这套方法跑下来，注册检验一次性通过。开发周期反而比第一代短了两个月——因为返工少了，扯皮少了，方向性错误少了。系统工程思维最大的价值，不是让团队更“忙”，而是让团队少做无效功。返工从来不是发生在验证阶段，它只是到了验证阶段才被看见。真正的问题，早在需求没对齐、接口没拉通的时候就种下了。这些年我接触过不少同行，做IVD的、做影像的、做植入物的、做手术机器人的——行业不同，产品不同，但踩的坑惊人地相似。需求没管好，接口没拉通，验证太晚，变更失控，售后被动——同样的剧本，在不同的公司反复上演。不是因为这些团队不努力。恰恰相反，大多数团队非常努力。问题在于，很多在项目中用血汗换来的经验教训，没有被系统地沉淀下来。一个工程师踩过的坑，下一个工程师照踩不误。一个项目总结过的方法，换一个项目又从零开始摸索。"沧海一豆"是我给自己搭的一个知识沉淀的公众号平台。过去15年，我主导过IVD设备、CGT设备、人工心脏、病理设备等多个产品的完整开发周期。从需求调研到架构设计，从设计控制到DFX方法论，从风险管理到验证确认，从供应链管理到全生命周期——这些在实战中反复验证过的方法和判断，我都在尝试写下来。我想做的，是把那些"真正在项目现场管过用的判断"整理成一套拿来就能用的经验结构。让后来者少走弯路，少交学费。如果你也在这些问题里反复打转——需求总是对不齐、接口总是出问题、验证总是来不及、团队总是在救火——也许这些沉淀能给你一个更清晰的抓手。知识真正有价值，不在于讲过一次，而在于能被团队反复拿来用。它就是一套方法。一套让复杂项目少失控、让团队少做无效功、让产品少返工的方法。这套方法不性感，也不会让你在汇报中多一页PPT。但15年走下来，我越来越确信一件事：好产品不是某个模块单独赢出来的，而是一整套系统共同打出来的。后面的文章，我会一个环节一个环节地拆开讲。需求怎么做、架构怎么拆、接口怎么管、验证怎么闭环、DFX怎么落地——一步一步来。作者简介：Kevin，15年医疗器械系统工程经验，主导过IVD、CGT、人工心脏等多个产品的完整开发周期。 |
声明：
1、凡本网注明“来源：小桔灯网”的所有作品，均为本网合法拥有版权或有权使用的作品，转载需联系授权。
2、凡本网注明“来源：XXX（非小桔灯网）”的作品，均转载自其它媒体，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。其版权归原作者所有，如有侵权请联系删除。
3、所有再转载者需自行获得原作者授权并注明来源。
/3 
浙公网安备33010802005999号 
