To B软件产品的开发流程—阶段关口模型

本文纯属学习总结，具体细节没有展开，还望各位有想法的大佬能提出宝贵意见，批评指正。

To B类软件产品应用“阶段-关口模型”的场景

1.产品周期长（半年以上）

有时间做规划

2.产品改变了B端的业务流

确认各个部门都能接受改变，并愿意配合调研

3.产品的数据来源于多个部门

确认各个部门愿意协作，提供数据或者模板

To B类软件产品应用“阶段-关口模型”的步骤

1.输出概念描述文档

1.获取信息方式：客户现场访问

由于访问对象是甲方老大，所以访谈目的是确定客户痛点，最好能确定解决方案。切记此时不要聊业务细节，因为老大很可能会指派一个业务员聊细节，此时聊细节做出来的东西很可能不满足甲方老大的需求而导致白做。

客户现场访问时要注意区分客户说的是“他自己想的解决方案”还是“用户痛点”。要多问为什么，明确客户为什么有这个想法。深挖用户痛点，当感知他痛点是什么并有解决方案时，要记得和客户确认自己想的是否满足客户要求。找客户痛点要找各个角色都关心的，都涉及/提出来的问题（老大的上下左右）。另外，客户往往由于种种原因说的问题并非属于自身痛点，比如他自己也说不清楚或者不方便说出，所以要多问！

2.注意事项：不要让自己的脑袋是空的！否则会破坏与客户的关系；调研获取的信息也会不可靠（认知不到位）

要么储备一定的行业知识，积累项目经验（尤其是设计被打回的经验）；要么是做竞品分析：To B软件产品的直接竞品比较少，因为B端都有定制化需求，但间接竞品不少，非定制化的需求的直接竞品，或者互联网行业等其他领域的竞品都可以作为间接竞品。

3.输出BRD、MRD尤其是MRD

这里输出的是“主业务流程”，目的是让老大拍板这个业务就要这么做，这样其他部门才能积极配合。

上图是为企业园区做订餐系统的主业务流程，该系统解决的痛点是员工不满意餐厅并经常投诉餐厅，投诉原因是园区的饭菜样品少。

2.输出产品设计规范

常见文档是PRD,举例如下：

需要注意的是，这步是产品级需求描述！

首先要把主业务流程涉及的角色的用例图画出来，然后逐步完善，把容易漏掉的角色的用例逐步完善：

如图中，蓝色部分是容易漏掉的角色的用例（领导、管理员、外部系统）。最后要把已有用例的异常情况完善：

3.输出技术规范

对安全性要求很高的客户或者外企的客户会输出如下图所示的技术规范文档：

为了节省时间提高效率，也可以使用如下图所示的技术规范：

需要注意的是，输出PRD阶段中的一个用例就对应如下图所示的一个活动图：