住院系统中隐藏着一个完美的敏捷流程

引子

10岁以后，已经30多年没有躺过医院住院部的病床了。既然住下了，就安心休养吧。

但是，由于我职业病(敏捷教练)一直在作祟，让我无法停止观察。一周下来，在不经意间发现一个隐藏的大秘密。

住院治疗系统的运作方式俨然是一个严密的敏捷流程，而且堪称完美，比普通的软件研发流程还要高效和流畅。

团队

这里有一个以科室主任为leader的高效团队，他领导着手下的团队，奔着一个共同的目标：住院治疗者的早日康复，而持续不断地向前推进。

他的团队成员有：住院医生和住院护士，他们各司其职，承担着医治和护理的明确职责。

如果对照到软件研发团队，医生至少有两个角色：BA和Dev，而护士也有两个角色：Dev和QA。

科室主任(SM)→↓

                            ↓→住院医师(BA、Dev)

                            ↓→住院护士(Dev、QA)

流程

一位住院治疗者从诊断入院到康复出院的全过程，也和软件研发中的需求交付非常相似。

我们做个简单类比：

住院治疗者→用户需求

门诊诊断→需求收集

入院信息收集→用户访谈

诊疗方案研讨→需求分析

治疗方案→设计方案

治疗实施→开发实现

每天查房→验收测试

体征收集→持续度量

康复出院→需求交付

简直可以完美匹配！

医生作为BA角色，也是需求交付负责人，在全过程当中是紧密参与的，每天两次的查房活动，就等同于需求完成情况的持续验收和反馈收集，确保了交付目标(入院者尽早康复)的方向不跑偏。

护士每天持续进行的工作：发药，输液，体征测量，活动收集等，也是一个实施→评估→反馈的循环过程，直至目标达成。

方法

住院治疗和软件研发在方法上也有诸多可以相互对照的内容：

治疗方案→最佳实践

责任医生→BA全程跟踪

当日任务上墙→看板系统

每日费用公示→研发成本透明

固定床位数量→限制在制品规模

最后一条是保证交付质量的关键因素，是用户体验的保障。我发现一个有趣的“7±2”的案例：每位责任医生管理的床位不会超过7个，一般是6+1的模式，6个正式床位和1个加床。

总结

住院系统完美交付的秘密在于两个关键因素：分工明确且协作紧密的团队(医生和护士)；严格限制的在制品规模(固定的床位限制)。

我们软件开发交付是否也能做到这样的水平，收获这样的效果呢？

共同的目标不是问题，协同明确的团队也不是问题，严格限制的在制品规模？这是一个很大的挑战！

我们要控制用户需求的输入规模，乍一看是mission impossible。但是我们细细想想，真的不可能吗？

医院系统为什么划分门诊和住院两大体系？这就是一个很好的启示。

门诊通过许多通用化模式化的方案，极大程度上分流了住院的需求(个性化诊疗)。我们的软件研发是否可以借鉴这个思路呢？完全可以！

当我们的软件产品具备一定的成熟度的时候，可以借鉴这种方式来应对用户需求的冲击。

1、通过提供通用化可配置的系统方案，解决相当一部分非紧急的普通用户需求，控制需求入口的流量；

2、严格控制个性化定制化的需求数量，通过需求分析和价值评估等方法，过滤通用普通需求，保证在研需求的交付质量和用户体验。