明明都签了字，IVD产品为什么还是做歪了？
2026-8-23 23:14|
发布者: 小桔灯网|
查看: 176|
评论: 0|来源: 来源：小桔灯网丨作者：沧海一豆
摘要: 三年前，我们团队在做一个IVD检测设备。项目节奏很紧，从立项到设计验证给了十个月。
三年前，我们团队在做一个IVD检测设备。项目节奏很紧，从立项到设计验证给了十个月。团队配置不差——硬件、软件、机械、光学都是跟过至少两个项目的老手，产品经理也是从临床转过来的，对应用场景很熟。需求阶段花了六周。产品经理带着市场部的调研报告，和临床端做了三轮访谈，输出了一份看起来相当完整的用户需求规格书。二十多页，覆盖了功能、性能、操作流程、法规合规，每一条都有编号，有优先级标注。需求评审会开了一整天。研发、临床、市场、质量，四方代表逐条过。有几条大家争论了一会儿，但看了看进度计划，最后都签了字。评审纪要存档，项目进入方案设计阶段。十个月后，样机出来了。临床评价准备阶段，我们请了三家目标医院的操作人员来做试用评估。第一家医院的检验科主任看完操作流程，皱了皱眉，说了一句话：「这几个功能，我们用不上。」我们以为是个别情况。第二家也来了，反馈更直接：「你们这个自动清洗模式，我们科室从来不用自动清洗，都是手动的。但你们的手动模式藏在三级菜单里，每次要点五下才能进去。」第三家的反馈最致命：「急诊场景下，我们需要3分钟内出结果。你们的开机自检流程就要4分钟。」三家医院，同一个结论：大约三成的功能和临床实际对不上。有的功能临床根本不需要，有的关键场景反而没覆盖，有的功能有但操作路径完全不符合现场习惯。项目经理翻出评审纪要，白纸黑字，各方签字确认。可结果就是偏了。复盘会上吵了一架。市场说：「我们写的需求是从竞品分析来的，竞品有的功能我们都列了。」临床说：「当时访谈问的是'你想要什么功能'，我们说了，但你们没追问使用场景。」研发说：「我们是照着需求文档做的，文档里写'操作简便'，我们做了自动模式，怎么就不对了？」需求从用户嘴里说出来，到写进文档，再到工程师脑子里，至少经历三次"变形"。每变形一次，就离真相远一步。如果换个角度理解需求管理：它本质上是一次"信号处理"。这个过程听起来不复杂。但真正的麻烦，往往不在技术层面。你见过这种需求评审会吗？所有利益相关方围坐一圈，需求文档投在屏幕上，产品经理逐条过。有人觉得哪里不对，但看了看进度计划——下个月就要出方案了——没吭声。签字的时候，大家签的不是"我认可这份需求"，签的是"我不想因为不签而耽误进度"。我自己也干过这种事。早年做第一个IVD项目的时候，评审会上有一条需求我觉得数值定得有问题，但想了想，提出来意味着要重新调研，至少延期两周。当时项目压力大，我选择了签字。三个月后，那条需求果然出了问题，返工花了六周。后来我慢慢养成了一个习惯：评审会上只要心里有疑问，就一定要说出来。哪怕只是一个问号，也比一个错误的签字便宜得多。这些年我看下来，需求评审会上最危险的一句话不是"我反对"，是"我没意见"。说"我反对"的人至少在思考，说"我没意见"的人只是在保护自己。还有一个隐藏的推手：谁提出改需求，谁就得为延期负责。所以大家倾向于"先签了再说，后面有问题再改"。结果就是——问题被推到了验证阶段才爆发，代价翻了十倍不止。更深一层的问题是结构性偏差。同一份需求文档，三个部门看到的画面完全不同：市场理解成：比竞品快，在指标对比表上有优势。研发理解成：算法响应时间短，跑一个样本的计算周期控制在2秒以内。临床理解成：操作步骤少，不需要频繁确认弹窗。用户真正的意思是什么？是急诊科的场景下，从样本上机到报告输出，全流程不超过3分钟——因为急诊病人等不了。一个形容词，四种翻译。没有一个完全错，但拼在一起就是一个"四不像"的产品。 | | |
|---|
| | 去现场观察用户实际操作，记录每一个停顿、皱眉、重复动作 |
|---|
| | "戴双层手套条件下，3步操作≤15秒完成样本加载" |
|---|
| | |
|---|
左边那列，是大多数团队的日常。右边那列，是踩过坑之后“逼”出来的方法。说句可能得罪人的话：产品经理如果没有在临床现场蹲过一整天，写出来的需求规格书不敢直接信。不是不相信这个人，是不相信二手信息。用户最不擅长描述的，恰恰是对他们最重要的东西——因为太习惯了，习惯到自己都意识不到。你问检验科的操作员"有什么需求"，他说"操作简便"。但"操作简便"不是需求，那是一个形容词。但如果你跟着他在B级洁净区里走一圈，看着他戴着双层手套、穿着防护服、额头冒汗，操作一个本来只需要三步的动作却因为按键太小而反复按错——你立刻就知道"操作简便"到底意味着什么。用户说"要快"。为什么要快？急诊场景时间压力大。时间压力大到什么程度？从开机到出结果，全流程不能超过3分钟——因为急诊分诊有时间窗口，超了就影响临床决策。追到第三层，才触碰到真实需求的边界。停在第一层，你拿到的只是一个形容词。我们后来把这个方法固化成了一条规矩：需求评审会上，每条需求后面必须追问"这个数是怎么来的"。刚开始产品经理觉得烦，但做了两个项目之后，便再也没人抱怨了——因为追问省下来的返工时间，远远超过评审会多花的那半小时。如果这句话回答不了，说明需求还没想清楚。"操作简便"的成功判据是什么？"戴双层手套条件下，3步操作≤15秒完成样本加载"——这才是一条工程输入。不能转化为测试用例的需求，不叫工程输入，叫用户愿望。我见过一份需求文档里写着"界面美观大方"。测试工程师拿到这条需求，直接来问我：这条怎么验？我说，不能验的需求就不应该出现在设计输入里。后来我们把它改成了"界面字体≥14pt，关键操作按钮面积≥15mm×15mm，色彩对比度符合IEC 62366可用性标准"。把需求写成可以被证伪的陈述："如果设备不在恒温环境下使用，这条需求是否还成立？"这种写法能把藏在需求背后的默认假设逼出来。很多项目到了高原医院、到了野战急救场景才出问题，就是因为当初没人把"恒温环境"、"稳定电源"、"标准操作人员"这些隐性假设写出来。我们有个血液分析仪项目，所有性能指标都是在海平面、25℃恒温实验室里定的。后来一台设备发到了海拔3600米的西藏某医院，气压低，进样泵的吸力不够，样本吸入量不足，检测结果全飘了。追根溯源，需求文档里没有一条写过"适用海拔范围"。所有人都默认设备在"正常"环境使用，但没人定义过"正常"是什么。源头的需求抓到了，还不够。从用户嘴里到工程师手里，需求还要经历三次翻译、四个角色：用户的痛点 → 产品经理定义产品方向（URS）→ 系统工程师拆解为系统指标（PRS）→ 专业工程师落地为设计参数（DRS）系统工程师翻译成"腰部支撑力≥15N，坐垫压力分布均匀度≥85%，连续使用4小时后腰部疲劳评分≤3/10"。结构工程师翻译成"腰托高度可调范围200-280mm，记忆海绵密度45-55kg/m³，坐垫曲率半径R≥400mm"。四个角色，三次翻译。每一层都是一次信息压缩和重新编码，都有丢失和扭曲的风险。产品经理和专业工程师之间，有一个巨大的"翻译鸿沟"——产品经理说的是"久坐不累"，专业工程师需要的是"腰托高度和海绵密度"。这两句话之间差着十万八千里。系统工程师就是填这个鸿沟的人——把定性的产品意图翻译成可量化、可分解、可验证的系统级指标。没有这一层，产品经理的"久坐不累"就会被工程师翻译成一把腰托很好但座垫很硬的椅子——因为工程师只听到了"腰"，没听到"久坐"。 | | |
|---|
| | |
|---|
| | PRS写"支持5种样本"，但URS只提了3种——多出来的2种是谁加的？ |
|---|
| | 所有人都假设"设备在恒温环境用"，但没人写下来——到了高原就出问题 |
|---|
我们团队吃过一次"逻辑性"缺失的亏。有个项目，产品需求里写着"支持5种样本类型"，但追溯回去，用户需求里只提了3种。多出来的2种是产品经理根据竞品分析自己加的，没有跟临床确认。结果研发花了两个月做这两种样本的适配，到了临床验证才发现——那两种样本在目标科室根本不用。两个月的工作量，白费了。需求文档里最可怕的不是写错的需求，是那些没人问"为什么"就通过的需求。写错的需求迟早会暴露，没人追问的需求可能会一路潜伏到验证阶段。自此之后，我们在需求评审时加了一条硬规矩：每条PRS必须标注它是从哪条URS推导出来的。标不出来的，就不能进入设计输入。任何一条需求变更，必须向上追溯：影响了哪条URS？向下追溯：影响了哪些DRS？哪些测试用例要改？哪些接口定义要联动更新？不做影响分析的变更，就是盲改。盲改多了，整个需求体系就成了一团乱麻，谁也说不清产品到底要做什么。我见过一个项目，做到后期变更了十几次需求，但每次都只改了产品需求层，没有向下追溯到设计需求和测试用例。最后验证阶段一跑，发现测试方案和产品需求对不上——因为测试方案还是基于三个月前的旧需求写的。每份需求文档里，必须有一节叫"不做什么"（Out of Scope）。明确边界比罗列功能更重要。很多项目膨胀失控，不是因为需求太多，是因为从来没人敢说"这个不做"。一旦边界模糊，每个人都往里塞自己的诉求——市场想加远程联网，研发想做AI辅助诊断，临床想要语音控制——产品就变成了一个谁都不满意的大杂烩。在需求文档模板里，"不做什么"和"做什么"的篇幅可能几乎一样长。这不是浪费纸，这是在画红线。某IVD项目，需求来自市场部的一份PPT。二十多个功能点罗列在四页幻灯片上，配着竞品对比表格，花花绿绿的。没有优先级划分，没有使用场景描述，没有成功判据——每一条需求都长得像一句广告词："超高速检测"、"一键操作"、"智能质控"。研发团队拿到这份PPT，开了个会，决定"照单全收"。理由也很朴素：市场部做过调研，客户确认过，我们按这个做就行。于是硬件按"超高速"设计了采集链路，软件按"一键操作"做了深度集成的自动流程，机械按"智能质控"预留了自动清洗模块的空间。每个模块的工程师都在自己的理解里把活干了。"超高速"做到了——单样本检测时间确实比竞品快30%。但操作人员说，他们的瓶颈不在单样本速度，而在进样切换：每次换批样本要手动确认三次弹窗，反而比竞品慢。"一键操作"也做到了——开机一键启动自动流程。但临床说，他们的操作环境是B级洁净区，操作人员戴着双层手套，根本没法精确点触那个12号字体的小按钮。"智能质控"更有意思——自动清洗模块做了精密的液路设计，花了三个月开发。但目标科室跟我们说：「我们从来不用自动清洗，都是手动清洗，因为审计追踪要求每次清洗都要有人确认签字。」约三成的功能和临床实际对不上。有的功能临床根本用不到，有的关键场景反而没覆盖。代价：项目延期4个月。重新对齐需求、修改设计、补充验证。团队士气降到谷底，跨部门的信任关系一度很紧张。第一件：源头观察。不是坐在会议室里听客户讲需求，而是派了两个人驻点目标医院。跟着检验科的操作人员走完了整个工作流程：从样本接收、编号登记、上机检测、结果审核到报告打印。47个操作节点，逐一记录。记录不是用录音笔，是用计时器。每个操作节点花了多少秒，操作人员在哪个环节停顿了、皱眉了、重复操作了、骂了一句脏话了——全部记下来。3天下来，识别出9个高频痛点。这9个痛点里，有6个从来没出现在市场部的调研报告里——因为操作人员自己都习惯了，觉得"就是这样的"，不会主动当作"需求"提出来。第二件：三层转化审查。URS到PRS到DRS，逐条追溯。每条产品需求后面都标注了它来自哪条用户需求。标不出来的，不允许进入设计输入。同时补齐每条需求的成功判据，标注"不做什么"的反向边界。举几条当时实际做的追溯，看看需求是怎么一层层“翻译”下去的： | | | |
|---|
| | 含开机自检在内，样本上机到报告输出总时间≤3min | 开机自检≤30s；光学采集≤30s/16通道；算法处理≤60s；报告生成≤5s |
|---|
| | 触控按钮≥15mm×15mm；字体≥14pt；核心流程≤3步 | 电容屏手套模式灵敏度≥95%；确认/取消按钮间距≥20mm；UI控件最小触控热区≥18mm×18mm |
|---|
| | 海拔4500m、气压57kPa条件下进样量仍满足最小要求；10℃时光学性能仍达标 | 进样泵泵力裕量≥30%（含海拔降额）；光源模块含低温补偿电路；出厂校准增加低气压模拟测试 |
|---|
从左到右看这张表：用户痛点是定性的，URS开始量化边界，PRS拆解为系统级指标，DRS再进一步分解到各模块的具体参数。每一列都比前一列更具体、更可测试。最后一行的"高原场景"，就是前面提到的那个血液分析仪项目——如果当初有这张表，进样泵的问题在需求阶段就会被发现。但设计评审通过率从上一个项目的60%提升到90%以上。验证阶段几乎零返工。而需求阶段省下的每一天，验证阶段都会以周为单位还回来——而且利息越来越高。类似的教训，我见过太多次。一个项目踩过的坑，下一个项目照踩不误。一套被验证有效的方法，换个团队又从零摸索。过去15年，我主导过IVD设备、CGT设备、人工心脏、病理设备等多个产品的完整开发周期。从需求调研到架构设计，从设计控制到DFX方法论，从风险管理到验证确认——这些在实战中反复验证过的方法和判断，我一直在尝试系统地写下来。你的需求，上一次被临床或市场质疑"这不是我们要的"，是什么时候？你的团队里，最后一次亲自去现场观察用户操作——不是坐在会议室里听汇报，是真正穿上防护服、戴上手套、跟着操作员走完全流程——是什么时候？你的需求文档里，有多少条能追溯回一个具体的用户痛点场景？又有多少条，其实是从竞品对比表上抄过来的？但如果这三个问题让你停顿了一下，说明有些事值得重新审视。需求的话题，我们已经讲完了，但需求对了，就万事大吉了吗？不一定。下一个最容易翻车的地方，不是设计，不是测试，而是架构。你选了什么样的架构，就决定了后面能走多远、改得动多少。一个好的架构，能让团队在需求变化时从容调整；一个差的架构，会让每一次小改动都变成牵一发动全身的灾难。作者简介：Kevin，15年医疗器械系统工程经验，主导过IVD、影像设备、人工心脏等多个产品的完整开发周期。
|
声明：
1、凡本网注明“来源：小桔灯网”的所有作品，均为本网合法拥有版权或有权使用的作品，转载需联系授权。
2、凡本网注明“来源：XXX（非小桔灯网）”的作品，均转载自其它媒体，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。其版权归原作者所有，如有侵权请联系删除。
3、所有再转载者需自行获得原作者授权并注明来源。
/3 
浙公网安备33010802005999号 
