编辑导语：产品经理在日常工作中会接收到各方递来的需求，对于这些需求产品经理要有判断以及跟进的能力，对于可实现的需求进行落地方案的跟进；本文作者分享了关于B端需求的实现之路，我们一起来了解一下。
前面的文章我从自身产品经历的实际工作中描述了一些产品经理在做的事，也总结了一些产品经理应该做的事；但都是基于从产品经理整体的方向去描述的，针对一些工作过程中的细节并没有过多阐述。
这一篇我就分享一下我所经历的一个需求从客户提出到最后实现的过程，看一下一个需求经历了什么最终成为了产品中的一个功能。
这是我所描述的这个需求从提出到实现的流程图，下面的文章我们就基于这个流程图展开：
一、需求提出我们的新版本手术室麻醉信息系统在设计完成之后，某三甲医院作为第一个客户正式上线了我们的系统，我们系统的简易的标准手术流程图如下：
在使用过程中麻醉科主任针对系统的手术流程提出了一个想法：“希望我们能够在此标准的手术流程外，再有一个针对二次手术功能，并且使其能够识别和记录下该患者是二次手术患者。“
我们系统之前针对患者的二次手术的处理做法是重新创建手术申请，按照一台新的手术继续操作。系统中会有两条该患者的手术记录，这两条记录都以独立手术的形式存在，这样会保证每一个手术流程都是标准的。
如果二次手术与第一次手术进行关联，系统原本的标准手术流程会被打破，比如一个患者本应该状态为手术结束，下一个状态却又变为了手术开始；这个需求由主任提出之后我们的现场实施人员判定无法在现场使用现有功能解决，就反馈到了我们事业部。
二、需求分析事业部在收到客户的这个需求之后，将需求发到了我们产品部门。
我们针对这个需求主要从三个方面进行了分析：
- 该需求是否会影响项目的验收；
- 该客户的影响力；
- 该需求的市场情况；
通过需求分析先判定这个需求响不响应以及如果响应是只针对该客户还是纳入产品标准版中。
1. 该需求是否会影响项目的验收我们参与了实施团队与客户需求沟通的会议，期间提到这个二次手术需求时，与客户再次确定了他们医院的实际业务的确存在该情况，并且她他们主要是想通过此功能加强对手术室二次手术的管理规范。
我们感受到医院管理方面在这个需求的态度还是很在意的，属于强烈的期望需求，会影响到客户的满意度。
2. 该客户的影响力该客户作为某省的三甲医院，在一定区域内具有一定影响力，并且与销售团队沟通得知，后续可能会将该医院作为该地区的标杆医院，用来向其它客户展示我们的系统实际现场使用情况。
3. 该需求的市场情况随着医疗体系的不断完善以及各临床医疗信息系统逐渐精进，二次手术的规范化管理可能会成为市场上大部分三级医院的标准参数。
综合以上几点考虑，我们团队决定在该项目验收前满足客户的需求，并且将这个需求纳入到产品标准版基线中，即以后该功能都将作为产品的标准参数出厂。
三、需求设计确定做该需求之后，就到了需求设计这一步开始设计功能的实现了，并且需要通过原型图的形式将其展现出来。
这个功能的复杂点并不在于简单的单个患者的手术状态变更，而是在整个系统中很多功能都关联着患者的状态信息，如：患者转运、病理标本、安全核查等，这些功能的操作都与患者的手术状态进行关联。
患者增加了二次手术状态后其它功能模块关于手术状态的判断需要进行怎样的变动，这些都要从系统全局角度出发考虑的，所以这个功能是牵一发而动全身。
当时初步构思了两个方向的设计方案，第一个是合，即二次手术的操作基于第一次手术的信息和记录上进行操作；第二个是分，即二次手术的操作与第一次手术保持记录关联但操作分开。和同事初期沟通了之后，我认为合的情况不会对系统的页面显示造成影响，就按照第一种合的方式进行了设计，出了原型图。
我的习惯是评审通过前只出原型图，因为我个人认为在需求设计未评审通过之前，可以通过原型图的方式让大家快速了解我的想法，也方便我后续进行快速更改和迭代。
有的同事在设计好原型图之后就把需求文档写好然后去评审，结果需求设计被驳回时再做更改，之前的文档工作量就浪费了，后续文档的更改工作量有时还不如直接写一篇新的。
四、需求评审在需求设计完成后，就邀请了产品、研发、测试的同事以及相关领导进行需求的评审。
评审的时候尤其是研发提出，这种合的方式对页面的改动的确较小；但是会对其它依靠手术流程节点做判断的功能模块来说，后台需要改动太多，而且无法预估出可能会造成影响的功能bug，所以第一次的评审没有通过这个合的方案。
下来之后从页面改动与牵扯到的其它功能模块一起考虑，我又重新设计了分的方案，这种方案，在点击进行再次手术功能时会独立产生一条二次手术记录，这样手术信息与第一次手术关联，但是手术流程节点在页面中跟着第二次手术走。
这种方案虽然会在所有患者信息显示的页面进行改动新增一条患者的二次手术记录，但是对其它关联功能模块对手术流程的节点判断影响较小；于是又召集第二次需求评审，在第二次需求评审中通过了该设计方案。
其实第一次需求评审没过，决定全部推翻而要设计新的方案时，我同事说“这么可惜，那之前的设计岂不是白做了。”其实我不这么认为，因为知道怎么做固然是一种成长，但是知道为什么不那么做何尝不也是一种成长呢？
另外还有一点，我也作为参与者参加过别人的评审会，我发现我在参加别人评审会时会下意识带有一种想反驳的感觉。
我们的评审会也是很多时候提的需求或者设计会被反驳砍掉一部分，不会被完整的通过；所以我们在准备评审的时候，可以适当的在自己准备的内容之上补充一些一定会被砍掉的设计即满足了别人反驳的欲望又保护了自己真正想做的设计。
五、需求实现评审通过后，就要确定需求的开发人员与开发时间了，我们使用的是线上的项目管理工具，在线上管理工具里录入需求的各种相关信息并且补充上需求的word文档；毕竟为了速度原型图只是对页面和功能进行大概展示，具体的细节还是要在需求文档中描述清楚的。
研发人员开发完成后，测试人员也测试通过后，我们还要再对功能进行核验，因为很多时候测试虽然能测出来功能上的bug，但是一些页面展示以及交互的改进我们还是要产品经理自己再去看一看是否满足我们的要求。
上述步骤全部完成之后这个需求就算是蜕变成了产品中的具体功能了，这个时刻往往也是作为产品经理最有成就感的时刻！
本文由@小游不会游泳 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于CC0协议