前两天一个朋友在后台留言说医疗行业搞敏捷就是bullshit，今天聊聊医疗行业到底能不能做敏捷。
医疗行业不好做敏捷？
先说说为啥大家固有的印象是医疗行业不好做敏捷。这种观点其实不奇怪，多年前我自己也曾持过这种观点。
医疗行业有其特殊性，这是一个法规严监管的行业，对软件开发而言需要符IEC 62304的要求。该法规要求软件开发生命周期符合v-model的要求，根据不同的器械风险等级需要在v-model的不同阶段进行相应的活动。
然而法规只告诉了企业应该做什么，而并没有告诉企业应该怎么做。实际操作层面，企业需要根据法规要求设立质量体系来告诉开发人员怎么做，在这个过程里将软件开发分为几个阶段。
这就带来了问题，每个阶段的工作没完成就不能往下走。医疗行业里有句话叫“没有记录就没有发生”，说的就是严格的质量记录是非常重要的，即便是代码编写都已经完成依然不能“退关”。而且，即便都完成了还有漫长的注册过程，才能真正交付到临床。也就是说，这种交付一定是长周期的。看上去这似乎本身和做敏捷实践就是冲突的。
医疗行业如何做敏捷？
那么，医疗领域到底该如何做敏捷呢？一边是没法商量的法规要求，一边是对市场变化要及时响应，这事是挺为难。
我认为，破局的关键是重新理解什么是“交付”。
如果只是狭义的理解为最后产品卖到客户那才算交付，那么我觉得确实无解。所以应该将“交付”的范围扩大，变成广义的交付。亦即将开发过程中的软件对开发团队外的展示都认为是一次交付，而这个交付要按照最后的注册上市交付的“质量”要求来。
这并不是说在每次软件发布时候都需要按照质量体系要求去更新记录文件，频繁的更新记录文件并不会产生价值，而且会增加协调成本、事务成本。而质量体系要求的文件的更新应该在合适的时候进行，但应该注意在开发过程中做好清晰配置管理、单元测试等必要记录，以备将来整理发布记录文件使用。
简单的说，我们完全可以按照敏捷开发的节奏来“增量式”交付软件，并且在适当的时候再提供正式的质量记录。
你可能会质疑这样做的合理性。即便是医疗软件本身的质量流程也要求符合多个程序文件要求，例如生命周期管理、配置管理、缺陷管理、网络安全管理、风险管理、变更管理，这些程序文件一般都可以独立去做计划、执行、报告的活动。我们只需要假设敏捷项目管理方法也是一个医疗器械软件开发的程序文件即可，这样敏捷开发和质量体系完全就是兼容的。
欢迎转发和后台讨论。
---------------------------------
看板研习社-看板实践者分享
主题：看板踩坑实践 （医疗行业）
分享嘉宾：大力老师
医疗器械企业研发经理｜看板方法实践者
时间： 2023 年 12月3日 周日 20:00
参与方式：扫码入活动群，群内发布腾讯会议链接
#YesWeKanban