吐医疗器械研发可配置性需求的槽点

医疗器械在某种程度上来说，是非标设备，每一款设备都有特别的地方（同款产品由通量不同产生的不同型号除外），从软件需求角度讲，抽象功能时如果不具备移植性，存在时限性，则价值分析时也应当充分评价。

一、项目经历

第一个是300项目，在研发过程中，由于“硬件和结构”改版，光路方向调转180度，之后提出软件增加反向功能，即硬件原通道#1~#12改为#12~#1。

第二个是20项目，该产品包含20个模块，5个构成一个通道，由于“硬件和结构”改版，温度模块的顺序打乱，之后提出软件增加自定义位置功能。

第三个也是20项目，该产品有一组指示灯，指示灯的顺序为#1~#5，由于“硬件和结构”改版，之后提出软件增加反向功能，即指示灯的顺序由#1~#5改为#5~#1,

二、修改代价

1 由于三次修改的内容都是逻辑性的，复杂度较高，修改和验证时间较长。

2 由于引入外部参数，同时存在版本控制混乱的原因，导致系统测试和外部客户反馈问题频发。

3 设计上，使系统复杂化，对小型团队来说存在很大隐患，后期维护的时候确实很困难。

三、价值分析

1 以上三次修改后，机械硬件定版，之前开放的可定制功能没有修改过。该功能使用频次为0。

2 研发结束的产品，如果要变更导致顺序调整，以上三次都是重大变更，涉及注册（假设强行忽略）、生产工艺调整（不改生产不了，必须改），检验流程（发布文件的检查，功能验证变化）。软件完全有条件一同升版。现有配置方案成本很高。

3 每个项目的需求不同，今天是这个模块要改，明天那个模块要改，这样抽象出来的功能不具备平台性。

四、总结

1 研发过程与硬件和机械配合的协议应当简单明了，而不是“华而不实”的需求。

2 软件的目的是尽可能满足用户需求，而系统开发过程，除了平台性的功能外，其他的“定制功能”应慎重评价其是否有价值。

五、思维扩展

还有两点，一则是以上问题是典型的硬件和机械的问题，图方便拿软件来进行“扩展”的例子。针对这类“管理”问题后续将专题分享。如液位探测。另一则是项目计划相关总结。敬请期待。