所谓需求推进，其实是一个项目管理的命题，而项目管理整体上有很多的理论依据可以学习和借鉴；今天的分享并非专业性理论，而是笔者在互联网公司工作几年的时间里作为产品经理落实推进各大项目实践下来的一些实战心得和经验，希望能对刚入行的一些初阶产品经理们在真实的工作中有所帮助。

虽然一部分公司会有项目管理人员来专门跟进项目推进工作，让产品经理的在项管性质方面的负担少很多，但这不代表产品人员就不再过问需求进度，项目管理人员的存在与否代表着产品人员对项目推进的所花费的心力程度，实操上产品经理仍然需要对项目进度有所担当，才能让一个项目有效落地。

那么我们就先从一个产品生命周期中的几个大节点开始看，一般来说一个需求/项目会有其演化的生命周期，基本上按照如下框架进行演化，产品经理要对这样一个流程烂熟于心，再基于这样一套框架之下，分拆每一个大步骤进小步骤进行推进。

基本节点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

四、进入开发，这时候产品需要注意的点

当产品经理的需求真正进入开发的时候，很多产品经理会在此时松上一口气，觉得总算把大担子交到开发测试那里去了，这一块的进度就靠同事们了；

我也曾经这样想过；但是事实是，大部分情况下（除非你的PRD已经写到了完美无瑕地地步，同事也聪明且有经验到极致），开发同事会在你工作的时间段里时不时地找上你咨询一把，一你并没有太多可以放松的时间，二在与开发同事的沟通过程中，一些决策就会影响到项目的实际进度。

此时在项目开发的推进过程中，产品经理可能会遇到的影响进度的3种主要情况分别如下：

需求增量：PRD当中没有考虑周全的逻辑，开发同事在撰写代码的过程中及时发现并提醒了你，开发询问需不需要额外增加逻辑需求量不匹配开发量：在开发周期快结束之前，开发评估一部分页面没有及时完成，大概率是需要增加开发时间，项目需要延期需求减量：开发在开发过程中由于个人疏忽导致遗漏了一部分你已经写入PRD的功能或者页面

针对情况1需求增量，此时你作为产品是需要评估这个逻辑点是不是在本次版本中必须做上的，如果不是，可以考虑放入后续迭代，否则可能改逻辑导致的开发周期拉长，延期原因追溯时可能会追到你增加需求这个事情上；如果是必须做上的，对产品核心流程会产生重要影响的；

笔者认为这是产品经理必须要努力维护的功能点，必须向开发晓之以理地请求将逻辑加上，产生的新增的开发时间，需要后续看开发能否加速，或者按照情况2的处理方法来进行跟进。

针对情况2需求量不匹配开发量，产品经理的及时介入非常之重要，大概率的情况就是开发同事需要此时产品经理去判断目前哪些还没做的功能是可以接受放入后续迭代的，哪些功能是核心功能没做完就不能上线的；

产品在对这两类需求做好判断之后，如果确实有必须在本期要做完的功能然而开发评估在正常工作时间内是做不完的，需要开发领导出面组织开发人员加班加点或者说增派人手进行功能开发，确保交付。

如果在加班加点和增派人手等手段支持的情况下仍然确认项目是会有延期的，则需要及时向更上层上报情况，确认是否可以接受一定时间的延期和后续对策。而至于那些判断是可以放入第二期的迭代中的需求，如果确认本期实属做不完了，那么可以选择需求后置，放入后续的迭代计划中。

针对情况3需求减量，在中小型公司中本情况还是时有发生的，但是一般来说这种情况会在测试期间被测试人员发现，一般以bug问题进行处理，测试会要求开发人员及时补写代码。产品需要介入的情况比较少，所以这一块一般信任测试即可。

而如果以上3种主流情况都没有发生，或者说已经得到了较好的处理，那么恭喜你，项目的进度在开发环节已经得到了较好的把控，可以准备好进入下一环节也就是测试环节。

关键词：维护核心需求，需求后置，迭代计划

五、进入测试，这时候产品需要注意的点

需求进入测试是一个重要节点，这时候项目推进的主人翁变换成了我们的测试同学们，同样的，与开发环节类似，这时候往往也有几种常见情况会发生需要产品介入，产品经理的不同决策往往会对需求进度产生影响。

几种情况分别如下：

需求减量：产品在PRD当中书写的需求，开发同事没有做完整，有遗漏，被测试测出需求争议：产品在PRD当中书写的需求不够明晰，导致开发的理解和测试的理解不同，开发的形态不被测试接受，出现争议，开发和测试要求产品经理出面进行补充说明和决策需求增量：开发在写代码的过程中充满了产品激情，自行给产品上增添了PRD上没有的功能，测试发现后通知产品过来判断

其实这三种情况的性质简单来讲就是产品经理的需求被做了减法、模糊化和做了加法。而在沟通和处理上的逻辑基本是一致的。

需求减量，一般优先操作都是让开发及时补入代码即可，当然这个前提是不影响项目进度。一般来说这种情况发生错误的责任在开发，一般情况下即使加点班，开发人员还是会及时将需求补进去。需求争议，产品需求不够明晰的情况其实如果对于项目没有影响的话，直接对需求解释清楚即可，需要对文档进行补充的做好补充，并在项目任务中进行备注即可。需求增量，这显然是开发给你出了道产品题。产品经理可以评估开发自行加入的功能是否能够被产品经理接受。

而以上三点处理方式和过程所遵守的基本的原则即是评估是否需要对代码进行一定量的改动，改动的量是否会对项目产生延期影响。但是对于产品经理来说，需求进入测试阶段已经相对比较接近实际上线阶段，产品方面确保以不改动为基本原则，因为你一旦做出了需求改动，不仅带来的是额外的开发的工作量，也是测试的工作量，一些关联的测试用例可能需要测试同学全部重测，项目会冒极大的延期风险，因而此时应该以“收”为主。

产品经理尽量不要养成在测试阶段还有出现需求变更的情况，尽管有时候可能基于维护核心流程的目的或者出于公司高层的要求在本阶段作出需求变更，但请务必三思而后行。

关键词：尽量不改，争议解决，收

六、产品验收，这时候产品需要注意的点

激动人心的时刻终于要到来，也是整个团队最具有成就感的时刻，不过此时仍然应该注意小心翻车。

特别需要注意的是，即便测试和预发环节已经自信做好了测试和验收工作，问题仍然可能在正式环境中爆发，原因是多个层面的，如果是技术层面的那么产品人员也很难协助解决问题。

此时产品经理能够做好的就是将流程验收完整，确保在用户使用的核心流程当中不出现差错。

当然，如果产品经理在验收过程中确实出现问题了，此时应该及时沟通到测试和开发人员确认问题，如果问题较为严重，对产品影响面较广的，应该及时通知运维对新代码进行回滚，恢复至老版本，评估问题并确认是否最终延期，以及下一次发版的日期。

如果问题并不严重，影响面小的，而且开发可以及时修补的，可以尽快当即撰写修补代码(一般这种代码极其少量，可能只有一行或者几行)予以上线修正。

这里值得一提的是，很多时候人都是会犯错的，大型项目里从开发到测试再到产品，还是可能会碰到有遗漏的没解决的问题发上正式环境，因而诞生了一些主流的科学上线方法，例如【灰度发布】方法，即一开始可能只是引入5%（百分比看实际情况而定，也要兼顾数量）的流量进入新版本，观察各项数据表现，在各项数据表现正常之后，再逐步放量至100%。

当然，上面描述的情况和处理做法是针对Web产品而言的，如果你是App发版，那么请务必做好测试工作，因为App并没有像Web这样如此快速的回滚方案（尤其针对原生代码）；

如果出现较大问题，App Store可以利用Expedited Review进入审核快速通道加速修复发版，而Google Play则在一开始就可以利用Staged Rollout灰度发布的方法对问题进行提早曝光，方便控制bug影响范围，及时补救。

如果产品验收过程完全正常，那么恭喜，这个项目就算正式上线啦~

关键词：Bug评估，代码回滚，加急发版，灰度发布

七、正式上线，才是一种开始

不过即便需求己经完整测试验收了，项目也准时上线了，产品工作还远未结束哦。

要记得，产品经理所设计功能的有效于否，刚上线之后仍处于待验证的阶段，此时产品经理需要格外注意每天的埋点数据的变化，如果数据表现不够理想，尽早着手准备后续工作，功能改进是常态；

新功能予以下线都是有发生的（一个经典案例就是Facebook当年完整下线了筹备了大半年的界面改版，就是因为用户反馈和数据表现欠佳，导致灰度发布到一部分的时候便决策予以完全下线，回滚至老版本界面）。而后续工作中，也可以将下一版本的迭代和预估的开发周期计划放入议程。

因而产品经理一定要在心理上做好平常心的准备，不能因为项目一时的上线就以为可以缓下工作，大功能的成功迭代或许可以庆祝庆祝，但心态上要保持一种持续输出的准备，才能在产品路上越走越远。

关键词：数据验证，后续迭代

结语

相信大家在看完本篇之后，对于需求全生命周期的推进过程和进度把控方法有一个较完整的感知了。希望这一份分享，能够给大家的产品工作实战带来实质助力。码字是真的辛苦啊~

本文由 @菠萝饭 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。