今天接着把在产品经理的工作流程-上篇中，没写完的内容续上。剩下的模块包含：功能设计、需求评审和测试迭代。
我在上篇说到，产品经理完整的工作流程是：获取需求——需求分析——用户画像——竞品分析——业务流程——功能导图——原型设计——需求评审——需求文档——上线测试——持续迭代。
我们将竞品分析后面的流程分为三大模块，分别是「功能设计」、「需求评审」和「测试迭代」。
其中「功能设计」模块中，涉及业务流程、功能导图、原型设计、需求文档的输出；「需求评审」模块涉及需求评审会、PRD修改；「测试迭代」模块，涉及上线测试、持续迭代的工作。
这并不意味着，产品经理的工作只有上述流程的内容，这里只是将我对产品经理的理解进行一个抽象，形成一个可学习、可梳理的流程化说明，切不可生搬硬套，要有自己的理解。
接下来，就分别对这三个模块展开说明。
01 功能设计
在上篇中，我们做的工作，都属于前期调研的范畴。前期调研结束，确定好了产品功能范围和用户画像后，就可以进入功能设计阶段了。
功能设计包含，业务流程、功能导图、原型设计这三部分。在画原型图之前，我们需要先完成业务流程图和功能导图，这样在画原型的时候，可以减少原型中，元件布局紊乱、信息架构不当或功能点遗漏等情况的发生。
业务流程图
业务流程图是以业务需求为出发点，以图形的方式描述系统任务和业务流程。一个好的业务流程图，可以帮助团队成员快速理解业务和需求，提高团队协作效率，降低沟通成本。
业务流程图，主要体现完成一个任务需要经过哪些流程，而不描述流程中的具体功能和操作。以滴滴打车乘客侧为例，简单的业务流程图就是：
滴滴打车中，每一个出行场景对应的业务流程都不一样，正确的业务流程图，是要将各业务场景的流程都体现出来。
业务流程图，最好可以清晰地体现核心业务流程。比如即时体验类的App，高德地图的核心功能是导航，那么业务流程图中用户使用导航的流程要表达完整，其它的附属功能如生活服务、离线地图、路书等功能，不必体现。
业务流程图，比较好的工具有visio、Prosess on，使用Axure自带的Flow元件库也可，但对于跨职能的业务流程没有上述两种直观。
功能导图
功能导图是以思维导图的形式，将各功能进行分组归类，形成信息架构。在前期构想的时候，我们可以发散地将所有功能都穷举出来，然后再对功能进行信息分层处理。以 微信-我 功能导图为例。
原型设计
对着流程图和功能导图，我们基本可以在脑子里构想出产品雏形了。使用原型工具，可以将我们的设想中的产品形态具象地表达出来。
原型图中，我们需要先对一级功能进行合适的布局，即搭产品框架，如微信的底部导航栏——首页、通讯录、发现、我，就是微信的一级功能，在一级功能下还有二级、三级等子功能。
在上图中，我们可以发现，微信在“我的”一级信息层级下，对二级信息进行了功能分类和布局，将不常用的“设置”功能放在了最下面；为了让用户更常使用视频动态的功能，微信将摄像机icon放置在了右上角，比较显眼且用户手指好触达的地方。
原型图中，不要求界面多么美观，但求布局、功能分层、业务逻辑流畅。
02 需求评审、测试迭代
原型设计完成，一般会先和产品总监再确定一下产品形态，确定完成后才进入产品需求文档（Product Requirement Document ，俗称PRD）撰写阶段。
曾经的我，也在PRD形式上纠结了很久，到底哪一种PRD模板更好？是直接在原型里面写逻辑，还是在word里面写呢？
不管哪一种形式，文档只是用来保证成员对产品需求理解的一致性，什么形式主要取决于成员的阅读习惯，但如何让文档更易于阅读，确实是需要产品经理们多花心思研究的。比如能用流程图的，不用表格，能用表格的不用文字，使用伪代码语言更利于开发阅读。
PRD完成后，需要组织相关人员开需求评审会。如何组织需求评审会议呢？
1、确定会议上要用到的材料已准备好，一般就是PRD、业务流程图、 功能导图；
2、定好会议室和会议时间，提前1-2天通知相关人员参加，并提前将PRD发送给相关人员查看；
3、产品经理需要保证对所提需求理解透彻，能够回答其他人的质疑；
4、控制会议节奏，在会议上5分钟之内没有结果的议题，会后讨论；
5、向开发人员获取开发工时（单位：人/天或人/时），以确定排期。
所以，成功的需求评审会产出的结果是：成员已了解产品需求、明确工期。
剩下的工作就是，跟踪开发进度和测试了，上线后持续迭代。
03 写在最后
产品经理的工作流程基本就是这些了，每个公司对产品经理的要求不同，涉及的工作内容也不同，所以产品经理的工作流程并没有标准的SOP这一说。
不管工作流程是怎样的，产品经理在工具、文档形式上无须太过纠结，多提高行业认知和产品思维能力，拉开差距的永远是思维层面上的，而不是工具层面上的。
THE END
在跌跌撞撞中成长，在此记录工作思考和读书思考，便于巩固。
如内容有不足之处，欢迎交流，一起学习、成长。