一个B端需求的实现之路品牌|升级|周源|屠呦呦|知乎

编辑导语：产品经理在日常工作中会接收到各方递来的需求，对于这些需求产品经理要有判断以及跟进的能力，对于可实现的需求进行落地方案的跟进；本文作者分享了关于B端需求的实现之路，我们一起来了解一下。

文章插图
前面的文章我从自身产品经历的实际工作中描述了一些产品经理在做的事，也总结了一些产品经理应该做的事；但都是基于从产品经理整体的方向去描述的，针对一些工作过程中的细节并没有过多阐述。
这一篇我就分享一下我所经历的一个需求从客户提出到最后实现的过程，看一下一个需求经历了什么最终成为了产品中的一个功能。
这是我所描述的这个需求从提出到实现的流程图，下面的文章我们就基于这个流程图展开：
一、需求提出我们的新版本手术室麻醉信息系统在设计完成之后，某三甲医院作为第一个客户正式上线了我们的系统，我们系统的简易的标准手术流程图如下：

文章插图
在使用过程中麻醉科主任针对系统的手术流程提出了一个想法：“希望我们能够在此标准的手术流程外，再有一个针对二次手术功能，并且使其能够识别和记录下该患者是二次手术患者。“
我们系统之前针对患者的二次手术的处理做法是重新创建手术申请，按照一台新的手术继续操作。系统中会有两条该患者的手术记录，这两条记录都以独立手术的形式存在，这样会保证每一个手术流程都是标准的。
如果二次手术与第一次手术进行关联，系统原本的标准手术流程会被打破，比如一个患者本应该状态为手术结束，下一个状态却又变为了手术开始；这个需求由主任提出之后我们的现场实施人员判定无法在现场使用现有功能解决，就反馈到了我们事业部。
二、需求分析事业部在收到客户的这个需求之后，将需求发到了我们产品部门。
我们针对这个需求主要从三个方面进行了分析：

该需求是否会影响项目的验收；
该客户的影响力；
该需求的市场情况；

通过需求分析先判定这个需求响不响应以及如果响应是只针对该客户还是纳入产品标准版中。
1. 该需求是否会影响项目的验收我们参与了实施团队与客户需求沟通的会议，期间提到这个二次手术需求时，与客户再次确定了他们医院的实际业务的确存在该情况，并且她他们主要是想通过此功能加强对手术室二次手术的管理规范。
我们感受到医院管理方面在这个需求的态度还是很在意的，属于强烈的期望需求，会影响到客户的满意度。
2. 该客户的影响力该客户作为某省的三甲医院，在一定区域内具有一定影响力，并且与销售团队沟通得知，后续可能会将该医院作为该地区的标杆医院，用来向其它客户展示我们的系统实际现场使用情况。
3. 该需求的市场情况随着医疗体系的不断完善以及各临床医疗信息系统逐渐精进，二次手术的规范化管理可能会成为市场上大部分三级医院的标准参数。
综合以上几点考虑，我们团队决定在该项目验收前满足客户的需求，并且将这个需求纳入到产品标准版基线中，即以后该功能都将作为产品的标准参数出厂。
三、需求设计确定做该需求之后，就到了需求设计这一步开始设计功能的实现了，并且需要通过原型图的形式将其展现出来。
【 一个B端需求的实现之路】这个功能的复杂点并不在于简单的单个患者的手术状态变更，而是在整个系统中很多功能都关联着患者的状态信息，如：患者转运、病理标本、安全核查等，这些功能的操作都与患者的手术状态进行关联。
患者增加了二次手术状态后其它功能模块关于手术状态的判断需要进行怎样的变动，这些都要从系统全局角度出发考虑的，所以这个功能是牵一发而动全身。
当时初步构思了两个方向的设计方案，第一个是合，即二次手术的操作基于第一次手术的信息和记录上进行操作；第二个是分，即二次手术的操作与第一次手术保持记录关联但操作分开。和同事初期沟通了之后，我认为合的情况不会对系统的页面显示造成影响，就按照第一种合的方式进行了设计，出了原型图。
我的习惯是评审通过前只出原型图，因为我个人认为在需求设计未评审通过之前，可以通过原型图的方式让大家快速了解我的想法，也方便我后续进行快速更改和迭代。
有的同事在设计好原型图之后就把需求文档写好然后去评审，结果需求设计被驳回时再做更改，之前的文档工作量就浪费了，后续文档的更改工作量有时还不如直接写一篇新的。