时间: 2021-07-30 11:37:50 人气: 10 评论: 0
所谓需求推进，其实是一个项目管理的命题，而项目管理整体上有很多的**依据可以学习和借鉴；今天的分享并非专业性**，而是笔者在互联网公司工作几年的时间里作为产品经理落实推进各大项目实践下来的一些实战心得和经验，希望能对刚入行的一些初阶产品经理们在真实的工作中有所帮助。
虽然一部分公司**有项目管理人员来专门跟进项目推进工作，让产品经理的在项管性质方面的负担少很多，但这不代表产品人员就不再过问需求进度，项目管理人员的存在与否代表着产品人员对项目推进的所花费的心力程度，实操上产品经理仍然需要对项目进度有所担当，才能让一个项目有效落地。
那么我们就先从一个产品生命周期中的几个大节点开始看，一般来说一个需求/项目**有其演化的生命周期，基本上按照如下框架进行演化，产品经理要对这样一个流程烂熟于心，再基于这样一套框架之下，分拆每一个大步骤进小步骤进行推进。
要根据项目的性质进行各大件的交付时间节点预估，重要性质项目进行倒推，资源预估；这是推进的起始点
很多时候在实践当中，中小型的需求是不需要BRD和MRD支持的，产品领导（产品总监or更高级领导）在给出基本的需求之后，产品经理就可以开始直接进行PRD的撰写（当然一般以流程图为起始）；
然而如果你作为产品经理接到一个相对体型较大的项目，那么此时你很可能需要至少一份MRD去开始对这个项目进行整体的规划；MRD与BRD的具体撰写和范本本文不再赘述，人人都是产品经理社区等各大pm社区中有足够的文章分享可以前往搜索学习（MRD传送门、BRD传送门）。
MRD&BRD**很好地帮助你将整个项目的规划，时间线和所需的资源支持展露出来，在项目的启动**议上召到所有相关人（包括你的产品领导）予以说明，那么整个项目的一些细节信息**开始流通进所有相关部门（特别是业务部门）的相关人员当中；
如果一些开发工作之外的资源支持需要提早准备，那么其他部门的人员可能就**在本次**议之后依据你的BRD/MRD文档，开始进行相关的资源筹备活动（例如一些文档和视频资源需要业务或者运营筹备，或者第三方公司的开发支持需要BD安排等等）。
这些工作**为你未来的PRD评审做好准备。
这时候如果项目已经被高层领导定下硬性的上线时间点，你就要格外注意后续PRD的撰写了，因为PRD所界定的功能范围**直接影响到开发周期。
关键词：时间线预估，资源预估，倒推
划重点！！这一块工作**带来你的颅内高潮(*•̀ㅂ•́)و
撰写PRD可以说是产品经理的工作核心。所以这一块工作的进度，也是你自己最好把控的，因为主输出就是你自己（或者说你的产品团队，如果你阶级稍高一些能组织几个产品人写PRD）
在有BRD/MRD的文档的情况下，你可以根据BRD/MRD当中含带的一些基本描述开始绘制相关的流程图（如果还没有，或者还不够细致）、功能结构图等基础框架。
在很多公司的中后台产品经理手上，这个过程很可能涉及业务流程的设计，如果公司没有专门的业务架构师（或类似职能人员），这个工作很可能就交付在产品经理肩上，产品经理需要和业务部门配合对流程做好梳理。
然后你再基于流程图&功能结构图等基础框架进行产品原型的设计，这一块你**花费较多的时间和精力去把很多细节想清楚。在产品原型每页右侧一般**附上本页的需求说明（如果你在用Axure进行设计）。
关于如何撰写一份好的PRD，这一块网上有非常大量的Sample（PRD传送门），但实际操作和演练非常重要，只有在不断反复打磨、日积月累自己的原型设计功力之后（不**只是如何使用Axure等软件，你需要开始懂一些基础的交互/开发原理来方便输出更高质的需求说明），你才能将所谓的PRD Sample真正内化成自己的知识和功力。
在产出流程图、功能结构图和原型图的过程中，产品经理所绘制的每一个功能点都代表着开发量；因而你需要特别注意，如果项目时间较短的话，很多非核心的功能可以考虑留在后续迭代中实现，从而实现对项目的一个MVP式（Minimum Viable Product）的设计，将所需的开发周期压至相对较短，不易延期的周期里。
在这里知易行难，功能拆分迭代需要产品对需求深入理解，需要产品经理在这一块反复打磨心法和技能。而如果没有特别重视这一块的话，需求的推进上将**在后续出现较多的难点，也**出现评审中被开发质疑，和后续开发过程中被强行砍杀需求的情况出现。
关键词：业务架构、业务流程、MVP、功能拆分迭代、交互原理、开发原理
对于很多产品来说，PRD的评审**议最为刺激
