产品和项目两手都要抓，两手都要硬，方是真B端产品。
产品流程
产品研发流程大体分为： 立项阶段、设计阶段、开发阶段、测试阶段、上线阶段、运营阶段。
1. 立项阶段
主要分为需求搜集和PMO（或产品委员会）立项。需求搜集阶段可以很长，包括如下内容：
如果是从0到1或者彻底重构的产品，要先进行BRD的输出。包括整体行业的分析，到竞争对手分析，再到roadmap和对应资源匹配。用BRD进行宣讲，才能向上申请资源进行立项。
然后，可能是MRD的输出或者拆解执行。MRD在很多公司会以年度规划的形式提前进行输出，主要是产品roadmap和进度计划。到了某个立项阶段，会根据市场、战略、竞品、技术、渠道等情况，调整版本实现的功能模块以及优先级。当然，还有最重要的项目里程碑计划。
最终输出物基本是立项报告，然后邀请PMO或产品委员会进行立项评审。
2. 设计阶段
主要分为需求池和PRD两大块：
基于立项阶段的MRD、上版本遗留问题和运营反馈的问题，列出概要清单。
然后召集项目成员，进行概要评审。这个评审一般是可行性、优先级以及成本的评审。评审通过的功能，细化成功能清单。
也存在研发业务背景较弱，概要已经要很细，功能清单要更细，以评估合适的工作量。上述的一个概要，需要拆成：
- 列表显示（实体的相关信息、列表需要显示的字段、数据规模以及分页）
- 查询（哪几个条件，条件对应的类型）
- 高级查询（哪几个条件，条件对应的类型）
- 新增（表单录入字段，校验规则）
- 编辑（只读信息、可编辑信息、校验规则）
- 启用（规则）
- 停用（规则）
- 删除（规则）
3. PRD阶段
主要输出物是原型和需求规格说明书，部分小版本甚至不输出需求规格说明书，业务流程、页面流程、交互说明和异常处理都会在原型上体现。
B端比较重视文档，在部分敏捷开发的C端，原型也是以逐个拆解的线框图为主。
这样有以下好处：
- 一目了然，开发、UI设计不容易遗漏页面
- UI设计、研发实现工作量评估更加到位
- UI设计师可以设计更好的UE效果，有更大的发挥空间
- 节省产品经理自己的时间，高保真原型性价比太低
绘制原型之前要进行整体的业务建模，力求梳理清楚全部的业务流程和必要信息。
在绘制草图时，要多和UI设计师交流，找到更合适的呈现形式。
在原型评审的时候，先介绍这些流程，再看具体的原型页面。原型评审结束，前端研发可以开始部分页面的UI开发，UI设计师准备视觉界面的输出。
需求规格说明书，需要拆分各业务领域进行输出。一个产品一个需求规格说明书，整个文档会非常的大。加上大量的修订和批注，产品人员维护起来很痛苦。编写需求规格说明书期间，要保持和架构师（开发经理）的沟通，在文档中完善业务逻辑。为了保障文档质量，目前文档是基于用例的形式编写的：
这样能更好的和测试进行沟通，减轻测试用例输出的工作，更专注于自动化测试。
需求规格输出完成，需要进行需求评审。由于内部项目动辄3个月，这个会议至少需要1-2小时。拿着几十上百页的文档过，开始还好，半小时后大家就注意力涣散了。
目前使用PPT进行需求评审，只关注业务流程和关键因素，反馈效果很好：
具体文档可以回去后进行查看，配合项目管理工具登记具体的问题，产品人员进行修复。
4. 开发计划阶段
主要是进行项目的计划排期，不展开讲。内部有开发经理角色，可以将这个任务交给开发经理。
5. 概要设计
如果不是第一个大版本，基本是业务时序图、数据结构的设计。由研发输出，测试、产品进行评审。
6. 编码实现阶段
该阶段事情最为繁杂的，包括但不限于：
- 原型、交互形式的改动
- 用户需求规格的补充
- 追踪推进进度，进行阶段性的测试验收。如客户管理的列表查询和新增编辑功能今天都能完成，要早上找到对应研发人员询问进度情况。进度理想的情况下，下午让研发先自测，然后去进行检查。进度不理想要找出差距，寻找追赶的办法。
7. 测试验证阶段
主要有以下工作：
- 把握测试环境的部署和更新节奏
- 守好需求验证的关卡。根据主业务流程，编写需求验证清单，对产品进行需求测试。如果连主业务流程都跑不通，没必要让测试人员进行测试。
- 修复前期遗漏的业务逻辑。不排除经过原型评审、需求评审、编码实现，还有部分逻辑不在需求规格说明中。例如某个异常情况，需求规格没写处理逻辑，研发按照自己的想法做了。还是需要产品确认，并在需求规格中补充的。
8. 发布运营
发布运营阶段很重要，工作也比较零散：
- 演示环境的搭建，准备数据的初始化
- 针对营销线的方案宣讲，输出解决方案和功能模块清单
- 针对实施、客服的系统实操培训，输出用户操作说明书
- APP上架文案和相关事项追踪
- EDM的设计
- APP更新机制策略的评估，是灰度发布、提示更新还是强制更新
- 用户的反馈进入需求池，为后续迭代做准备
- 支撑验证客户项目，包括方案讲解、需求调研等
项目流程
B端客户一般有定制化诉求，会以项目交付的形式进行落地。并且公司内部要求每个版本有验证客户，完善产品到实施的知识转移。工作流程如下：
整个大流程里面，产品经理可能会在涉及以下工作：
- 在意向阶段介入，协助售前一起完善解决方案（一般是大客户）。
- 在投标阶段初期切入，替代售前进行解决方案的讲解，以及产品的演示（行业龙头客户）。
- 在投标阶段后期切入，负责客户POC功能的调研和规划落地。需要协调各方资源，在实施开发环境进行功能改造，并追踪整体进度（此时未立项，替代项目经理）。
- 在项目立项阶段切入，作为公司的产品部代表出席立项会，维护客情。
- 在蓝图规划阶段切入，支撑需求调研工作。如出差客户现场，主导调研并输出部分PRD。提供最新产品原型、PRD和组件库，赋能实施人员。最后，还可能参与蓝图方案的输出。
- 在系统建设阶段切入，可标准化的功能将由产品部实现。此时需要分配任务跟踪进度，确保标准功能分批实现，满足客户诉求和各项目上线节点。同时关注客户测试环境，确认稳定可靠。
- 在上线推广阶段切入，主要是客情维护和系统培训。另外，也需要输出产品的用户说明书，为一线实施人员提供弹药。此阶段已上线客户生产环境，需要安排服务经理跟进，并做好出现紧急情况的预案。
作者：道·术 ，邮箱：olivercan.wunban@foxmail.com
本文由 @道·术 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash ，基于 CC0 协议
