所谓需求推进，其实是一个项目管理的命题，而项目管理整体上有很多的理论依据可以学习和借鉴，今天的分享并非专业性理论，而是笔者在互联网公司工作几年的时间里作为产品经理落实推进各大项目实践下来的一些实战心得和经验，希望能对刚入行的一些初阶产品经理们在真实的工作中有所帮助。
需要注意的是，一部分公司会有项目管理人员来专门跟进项目推进工作，会让产品经理的在项管性质方面的负担少很多，但这不代表产品就不再过问需求进度，项目管理人员的存在与否代表着产品人员对项目推进的所花费的心力程度，实操上产品经理仍然需要对项目进度有所担当，才能让一个项目有效落地。
那么我们就先从一个产品生命周期中的几个大节点开始看，一般来说一个需求/项目会有其演化的生命周期，基本上按照如下框架进行演化，产品经理要对这样一个流程烂熟于心，再基于这样一套框架之下，分拆每一个大步骤进小步骤进行推进。
【基本节点】：
一、BRD/MRD撰写
二、PRD撰写
三、评审
四、进入开发
五、进入测试
六、产品验收
七、正式上线，才是一种开始
（其中，由于单篇篇幅量不小，本篇会讨论一二三点，四五六七点会在第二篇中进行后续讨论和分享）
【推进正文】：
一、BRD/MRD撰写
要根据项目的性质进行各大件的交付时间节点预估，重要性质项目进行倒推，资源预估；这是推进的起始点
很多时候在实践当中，中小型的需求是不需要BRD和MRD支持的，产品领导（产品总监or更高级领导）在给出基本的需求之后，产品经理就可以开始直接进行PRD的撰写（当然一般以流程图为起始）；
然而如果你作为产品经理接到一个相对体型较大的项目，那么此时你很可能需要至少一份MRD去开始对这个项目进行整体的规划；MRD与BRD的具体撰写和范本本文不再赘述，人人都是产品经理社区等等各大pm社区中有足够的文章分享可以前往搜索学习（MRD传送门、BRD传送门）。
MRD&BRD会很好地帮助你将整个项目的规划，时间线和所需的资源支持展露出来，在项目的启动会议上召到所有相关人（包括你的产品领导）予以说明，那么整个项目的一些细节信息会开始流通进所有相关部门（特别是业务部门）的相关人员当中，如果一些开发工作之外的资源支持需要提早准备，那么其他部门的人员可能就会在本次会议之后依据你的BRD/MRD文档，开始进行相关的资源筹备活动（例如一些文档和视频资源需要业务或者运营筹备，或者第三方公司的开发支持需要BD安排等等）。
这些工作会为你未来的PRD评审做好准备。
这时候如果项目已经被高层领导定下硬性的上线时间点，你就要格外注意后续PRD的撰写了，因为PRD所界定的功能范围会直接影响到开发周期。
<关键词>：
时间线预估，资源预估，倒推
二、【PRD撰写】
划重点！！这一块工作会带来你的颅内高潮(*•̀ㅂ•́)و
撰写PRD可以说是产品经理的工作核心。所以这一块工作的进度，也是你自己最好把控的，因为主输出就是你自己（或者说你的产品团队，如果你阶级稍高一些能组织几个产品人写PRD）
在有BRD/MRD的文档的情况下，你可以根据BRD/MRD当中含带的一些基本描述开始绘制相关的流程图（如果还没有，或者还不够细致）、功能结构图等基础框架。在很多公司的中后台产品经理手上，这个过程很可能涉及业务流程的设计，如果公司没有专门的业务架构师（或类似职能人员），这个工作很可能就交付在产品经理肩上，产品经理需要和业务部门配合对流程做好梳理。
然后你再基于流程图&功能结构图等基础框架进行产品原型的设计，这一块你会花费较多的时间和精力去把很多细节想清楚。在产品原型每页右侧一般会附上本页的需求说明（如果你在用Axure进行设计）。
关于如何撰写一份好的PRD，这一块网上有非常大量的Sample（PRD传送门），但实际操作和演练非常重要，只有在不断反复打磨、日积月累自己的原型设计功力之后（不会只是如何使用Axure等软件，你需要开始懂一些基础的交互/开发原理来方便输出更高质的需求说明），你才能将所谓的PRD Sample真正内化成自己的知识和功力。
在产出流程图、功能结构图和原型图的过程中，产品经理所绘制的每一个功能点都代表着开发量；因而你需要特别注意，如果项目时间较短的话，很多非核心的功能可以考虑留在后续迭代中实现，从而实现对项目的一个MVP式（Minimum Viable Product）的设计，将所需的开发周期压至相对较短，不易延期的周期里。在这里知易行难，功能拆分迭代需要产品对需求深入理解，需要产品经理在这一块反复打磨心法和技能。而如果没有特别重视这一块的话，需求的推进上将会在后续出现较多的难点，也会出现评审中被开发质疑，和后续开发过程中被强行砍杀需求的情况出现。
<关键词>：
业务架构、业务流程、MVP、功能拆分迭代、交互原理、开发原理
三、【评审推进/评审涉及人员范围】
对于很多产品来说，PRD的评审会议最为刺激 :) 。当然这同时也可能是最容易让<初级产品经理>心里紧张的一项活动。在进度把控上，尽量做好前期与各相关部门领导的前期单独沟通和调研，避免后续会议反复，而评审会议则要保持会议的高效不偏题，决策的迅速，重点的文字记录，最终及时将FPRD输出。
评审的次数、人员范围会根据需求大小、每个公司的实际情况、评审确认度而发生变化，甚至于评审的专有名词都在不同公司有所不同。我这里先讲一下两种基本的类型即【业务评审】和【技术评审】。
【业务评审】顾名思义，一般都是以业务人员为主要参与人员进行的评审，但同时也会让设计进行参与（除非你的项目仅仅涉及后台系统，同时后台系统的设计规范都已经定好）先行开始了解项目。由于你的原型一般来说是低保真原型，不对视觉进行定义，此时在后续进入开发之前，开发还需要设计交付一份设计稿，才能算是真正意义上的可以开始开发。
在业务评审完毕且相关方基本确认之后，你的PRD可以开始进入【技术评审】，此时往往是开发同事和测试同事开始进入到会议当中的场合。研发和测试阅读你的PRD时，他们往往对业务流程和项目目标、数据等层面关心不如业务部门，一般知道个大概，理解项目一些基本属性即可，但是他们会对你的PRD的技术实现方案和研发测试周期更为关心，也会在评审上对此进行讨论。
而在正式开【业务评审】和【技术评审】之前，对于产品经理来说一个很关键的步骤就是提前单独接触业务领导和技术领导进行调研，与他们沟通和讨论需求的大致方案，能将业务流程和技术实施的整体方案打磨出一个可行框架出来，这样一个步骤能大概率消掉后续会议中发生扯皮和争论导致的时间浪费、项目拖延的问题。
当然，即便在两种会议开始之前找各方领导做过单独的征询和调研，在会上你仍然很可能会遇见一些对需求点有关的意见冲突的地方，可能之前觉得可以的点，在会议上再多思考了一下又发现新的问题，那么此时需要注意的是，如果争论点你在之前已经有所考虑，可以直接提出你的考虑看对方是否接受，如果对方的考虑更加全面或者这个点无法定论的话，你都需要做好会议笔记，方便会后及时跟进，并考虑对PRD做出合适的调整，方便后续给出最终版的FPRD（Final PRD，作为进入开发前的PRD终稿）。
注意，如果意见冲突较多，PRD改动较大的话，此时是要考虑举行二次评审的。评审结束的判断条件就是一份大家都基本满意的FPRD的产出，后续的开发和测试都会以此FPRD为准开展工作。
当然，还有一种需求情况和流程是，当你接受到的需求体量较小时，或者需求对接部门单一时，很多时候【业务评审】会议可能略过，这样会节省大家大量的时间，可能你将PRD或者需求描述直接与对应部门的负责人对过即可；有时候，一些情况下（多数为需求小且需求十分清晰），甚至【技术评审】会议也可以免除，交付开发负责人直接配给程序员开发也是可以的。这些情况在每个不同大小不同规矩的公司里，实际开展情况不同，灵活多变。产品经理应该根据实际需求情况进行会议的开展推动。
<关键词>：
业务评审、技术评审、前期调研、会议记录、FPRD
---【未完待续】---
四五六七点（进入开发、进入测试、产品验收、正式上线）的实战心得会在第二篇中进行后续讨论和分享，第二篇会尽快到来哦~
