一、产品研发流程图
常见研发流程
阶段：需求输入、需求发布、研发阶段、上线阶段、交付阶段、维护阶段。
相关方：业务、产品、设计、研发、运维、项目、运营、售后。
C端或者B端需求管理各有不同，遵循PDCA原则不断完善流程，以及精简使用工具。目标是更快完成需求上线，响应客户问答。根据产品研发流程细化修改了《产品经理成长地图》，在工具方面用到了：
- 需求输入（需求池、设计思路OR头脑风暴思维导图）
- 需求发布&研发沟通（需求管理表、产品流程图、需求文档）
- 上线阶段&交付阶段（验收文档、功能清单、上线说明、产品知识库）
- 售后维护（常见问题、客户案例）
以下将对格式和用法进行说明。
二、需求输入
在需求管理时，考虑有时候相关方使用习惯，以及时间上不方便没有采纳常见的在线管理工具，仅用本地Excel来管理——需求管理表，主要包含迭代进度表、需求池，可拓展研发进度、需求讨论、回收站，设计思路OR头脑风暴可放在需求文档中做灵感来源分析需求使用。
- 需求输入主要来源有业务（销售/项目/产品），在研发过程中研发同事会给到他们的想法和建议，在不影响客户使用情况下，需要结合公司的架构相应的变通。
2.1 文档说明
该表格对整个文档做基础数据说明。
文档名称：填写所在事业部或者部门产品线的名称。
项目：产品各个阶段要实现的目标、项目规划。
特别说明：一般备注记录每次研发上线要注意事项，不常写入需求中的内容。
撰写人：产品经理OR需求分析。
状态：需求研发流程分为（待处理/已编写/开发中/已完成/已上线/已作废），常用待处理/已编写/已上线，已作废需求放到sheet回收站中。
来源：可以填写相关方，如销售OR项目人员，或者需求不同阶段的定义。
优先级：用P1-4（pressing）分别代表不同的紧急程度。
2.2 需求池
需求输入阶段：需求池记录每个相关方反馈来的需求点，细致到哪个菜单页面下的功能点，描述简写功能或原因。根据需求实用和必要性记录优先级、实现的终端属于PC还是移动（APP/小程序），确认需求范围后将要编写的需求更改状态。
上线阶段：验收时右侧新增两列，填写验收第几次或者验收环境，橙色表示未通过需要跟进修改，绿色代表通过可以上线。验收结果截图发给研发测试，或者对应截图反馈到BUG管理工具中（如Worktile）。
明确不做的需求状态为“已作废”，剪切到【回收站】当中。
2.3 需求讨论
记录每次需求启动会OR评审会，参与人员提出的问题，挖掘可以优化的需求放置【需求池】中。
三、需求发布&研发沟通
3.1 进度表
该表格记录每个产品迭代任务有哪些，对比计划与实际完成情况。
任务：任务名称，或者填写产品迭代版本号。
备注：主要完成需求点。
类别：产品名称OR项目名称。
负责人：一般写研发组长，更细化根据不同的需求点写前端/后端/测试人员名称，再加上研发状态可当作研发进度表格来管理。
时间：区分计划/实际，表格实时记录当前与填写时间间隔，右侧甘特图还会有红线标注，便于任务进度跟进对比。
3.2 产品流程图
经常使用图例：功能结构图、信息结构图、角色泳道图、功能流程图。为方便研发理解找到图例，直接用Axure画流程图和原型（输出需求文档），流程图可用Axure当中的Flow组件。（产品流程图汇总到需求文档中）
功能结构图：功能模块、功能点、功能作用是什么。
信息结构图：页面信息、系统对象、相关字段。
角色泳道图：横向表示相关人员或者终端，纵向表示关键阶段，常见元素有：开始（或承接上一个关键步骤）、结尾（结束当前关键步骤）、矩形表示每个动作步骤、菱形表示判断条件、用Y/N表示是否符合条件。
功能流程图：横向表示终端，纵向表示流程，常见元素有：开始结束、子程序、判断条件、操作之后状态变化。
3.3 需求文档
模块迭代版1、模块迭代版2、产品完整版
根据不同情况使用迭代版OR完整版结构，重点要做好每期版本管理&研发完成后的知识沉淀。
- 模块迭代版1：产品的快速迭代每个版本需求不一样，包含BUG修复、功能点优化。
- 模块迭代版2：在迭代版1基础上升级了使用，验收标准结合验收阶段的【需求池】，将其替换成系统算法。（知晓产品完整结构，每期替换“需求说明”即可，需求压缩包命名如：某产品_版本号）
- 产品完整版：在迭代版2基础上升级了使用，用于完整的产品需求整合。首页主要写文档说明和设计思路（要解决用户哪些使用场景），加入功能清单，需求部分区分终端原型设计&需求文档。（需求说明和算法注意更新至最新版本）
已知产品规划建议从V1版本开始，需求文档直接使用迭代版2格式，方便研发了解整体框架和流程，测试更快速找到算法出处。当完整版需求过长时，加入锚点元素，搭配需求大纲可直接定位查找。
用Axure制作导出HTML格式，以下为完整版模板页面截图：
封面：选择终端直接进入需求文档
设计思路：打开菜单内联框架HTML，菜单可找到其他页面。涉及到多角色时展示权限列表，每个角色✔表示拥有该权限。
产品架构：功能结构图、信息结构图、角色泳道图、功能流程图。写需求前梳理结构图更好考虑细节，泳道图/流程图便于研发测试理解需求。
功能清单：系统页面和功能介绍。
历史版本：记录每一个迭代的内容和验收结果，方便上线后编写产品手册，追溯版本需求，可当作目录使用。
系统算法：页面+页面包含的算法。
需求文档：内联框架的需求文档，当需求过长，左侧二级菜单可点击展开收起，方便研发快速定位节省时间（优点：可放大图片，制作交互效果；缺点：无法搜索定位字段）
另还可用Excel写需求，Sheet当作菜单，优点：特定字段搜索，缺点：静态图片无法放大。
产品原型：产量流程梳理完后，每个页面包含哪些元素，可用占位符、图片、矩形以及标签绘制简单的页面流程，并配以交互效果说明制作粗保真原型，也方便UI设计师理解需求。
大致需求启动说明流程：设计思路——产品原型——功能流程图——需求中重要的细节
延伸话题：《如何成功开需求启动会？》
四、上线交付阶段
4.1 上线说明
word文档编辑目录标签，区分终端、功能页来说明成功上线内容——优化/新增/修复（内部项目经理跟进OR客户理解系统操作）。如果是上线的完整功能模块，建议合并到知识库中。查看语雀的更新日志案例
4.2 产品知识库
- 目的——要让客户了解产品怎么使用，可以帮助解决哪些问题（注意是否有隐私要求做脱敏处理，分对内对外版本）。
- 文档说明：基本要素写版本号、对内OR对外、使用场景信息等。
- 产品介绍：类似于《功能清单》格式，简化说明功能模块OR产品线，客户角度写明常用到的角色。
- 快速上手：通过页面数据流转引导，让用户快速了解产品结构和操作步骤。（每个产品下包含快速上手/软件功能/可能还有系统算法）
- 软件功能：每个功能模块下写明包含的功能页面，配上截图和字段说明，以及该页面的功能使用方法。
五、售后维护阶段
5.1 常见问题
相关方与客户交流的积累：遇到的问题，区分类别（操作类/需求类/系统类），定期汇总分类。如果是操作类，考虑到产品交互过于复杂OR客户还不太理解系统使用，那么写明每个操作步骤通俗易懂，进行交流培训；
如果是需求类，汇总到需求池中根据优先级进行研发排期；如果是系统类，突发重要问题优先处理，并总结解决方法到文档中。
当文字描述或场景过于复杂，还可以录视频远程的方式进行沟通，降低用户的理解难度。
延伸话题：其他产品的帮助中心（点击下方文字跳转）
语雀帮助中心 帆软帮助文档 阿里云帮助中心
5.2 客户案例
常见于企业官网底部，会放置合作过的品牌logo，官网中优秀的合作案例描述也可放到客户手册中，一方面增加客户信用背书，一方面方便客户理解使用场景，从而促进付费转化。
延伸话题：品牌建设、产品营销运营
六、分享预告
VOL.3：个人知识库的建立，知识库产品使用测评
~ 一起持续迭代吧 ~
若有收获，就点个赞吧
0 人点赞
