经历了一个失败的项目，一个不是非常复杂的后台管理模块从需求到上线历时近2个月，且上线后仅是能用，很多功能未实现，效果非常差。痛定思痛，复盘该项目过程存在的问题，提供前车之鉴。详细的项目管理方法论和流程很多文章都有介绍，就不作赘述。
一、产品经理要不要承担项目管理的职责？
项目管理能力是PM的技能树要求之一，因为产品经理是需求的转化和规划者，产品的变现需要依赖于UI&UE、开发、测试等不同的工种，不进行项目管理再好的想法和规划也难以落地，只是一纸空谈。少部分互联网公司或者外包公司是设置项目经理、PMO岗位的，但多数情况是由产品经理兼任项目管理职责。事后也和对应PM交流，反馈说认知里面开发进度应该由开发负责人统筹管控。
建议：作为产品经理，从为自己产品负责的角度，都要有着清晰的项目管理主人公意识，自己的项目不要把希望寄托在别人身上，自己要有足够的掌控力。有专门的项目经理岗位精力投入少一些，没有则就要更多的精力统筹项目管理过程，保质保量上线，才是项目团队价值的体现。毕业入职第一个月，规划了好几个可视化页面的需求，但初入职场项目资源协调经验为零，开发资源一直排不上，一个多月空有方案没有落地产出。
二、产品落地过程坑点与规避建议
1.PRD质量差
PRD文档是项目团队工作的准绳，属于项目范围管理的范畴。PRD的质量、完整度对项目高效进行至关重要。虽然也组织了产品方案评审，但评审过程以需求点、核心流程为主，交互细节并未深入评审。且评审意见并未及时落实，没对PRD进行更新。
事后制定了产品PRD文档标准，评审流程、评审会议纪要同步规范、评审意见跟进验收，通过流程节点，尽量保证PRD质量符合预期。把PRD文档当作一个产品来做，多一些同理心，考虑阅读者的感受，把需求信息完整、清晰的传递给用户。产品经理可以问问自己，“如果开发按照PRD方案上的内容1:1实现，这个结果是不是能接受的？”，“不进行评审讲解，开发直接看文档能看懂需求的百分之多少？”，“PRD文档直接扔给用户，用户能不能确认方案是否满足了自己的需求？”。
2.开发需求理解不充分
需求排期前也组织了开发评审，但因为优先级调整评审后并未进入开发，开始开发时，参加评审的人已经离职了，负责执行的开发未参与需求评审，只是接受到开发组长指派的开发任务。于是就按照PRD方案和自己的理解开干了，提测时发现，开发并未完整理解需求的目标，甚至连主流程解决什么问题都不清楚，自测也无从下手，提测质量就可想而知。
建议：开发评审前提前把需求文档在项目群同步，请相关开发提前整理问题，带着问题评审，毕竟评审会1个多小时很难把所有内容都讲的非常全面，开发评审目的是各方对需求理解一致，进行技术可行性进行评估，从技术角度评审方案的合理性。看过一些讲“产品经理如何活着走出评审”的文章，个人觉得，从评审的目的出发，把需求讲透彻、问题聊清楚才是最重要的。气氛一团祥和，事后一堆问题，产品目标实现不了的结果更糟。针对中途变更开发的情况，产品经理要及时跟进，重新组织需求评审，保证变现开发充分理解需求。
3.变更管理不规范
再优秀的产品经理也不能保证需求方案完美无缺，实际开发过程也会发现一些更为细节的问题。产品经理的职责之一就是快速地响应问题，给出更优的解决方案。产品和PM沟通碰撞的过程，不可避免的会产生需求的变更。变更过程缺少存档记录、变更内容未及时同步干系人，导致验收环节产品与开发的扯皮。
建议：产品经理要清楚并遵守变更的流程，不能抱有侥幸心理。其中，变更控制、核心干系人变更审批、干系人变更信息沟通存档尤为重要。不随意变更，变更发生后信息及时同步，并留好过程记录，必要时“取证”，否则出问题只能“人在家中坐，锅从天上来”。
4.进度管理形式化
项目排期周期较长（3周），制定的计划是分阶段验收以防最终提测时出现问题没有补救时间。但PM实际执行过程，只是走过场，每周问一下有没有问题和风险，得到的回复往往都是“一切顺利，进度正常”。
建议：
- 统一目标：排期确定后和开发组长、开发团队明确项目总体上线时间，以及阶段性里程碑，并同步项目干系人，加强团队对Deadline的意识
- 进度管理制度，如站会，周会等，站会频度可以一周2次，会议避免只流水账式的讲内容，要重点讲问题和风险。
- 进度日报，重要、紧急且周期比较短的项目（2周内），项目进度可以每日项目群内同步即可，一方面让发起人和业务及时知晓每日最新情况，心里有数，另一方面，也体现产品经理的责任意识和推动能力。跨度过长的项目，可以视情况定。
- 进度周报汇报，内容包括项目总体情况是否正常，主要风险，本周进展，总体里程碑等。主要作用一方面是及时将信息同步干系人，另一方面也将进度透明，团队成员看到老板也会关注项目进度，会对Deadline更加敬畏，出现一定进度偏差可能也会自己主动加快进度。
- 分阶段验收，要切实按照需求拆分的阶段，验收实现是否符合预期，避免仅仅是口头沟通，或者到开发身后看一眼，OK没问题。
5.Deadline意识弱
B端产品用户一般是企业内部同事，产品上线Deadline一般没有C端版本发布管控的那么严格。但久而久之会导致团队的Deadline意识弱，产品经理验收时，将问题提交开发后，开发不仅不慢地修复，什么时候修复完了，通知产品回归一下，发现问题再进行一轮，直到问题越来越少可以上线为止，延期了也就延期了，Deadline成了摆设，当然这也和开发团队没有设定项目延期的绩效考评机制很大关系，在这种情况下，产品经理的责任心和deadline意识就很重要。否则只会一再延期。
建议：首先产品经理自身要对Deadline有敬畏之心，即使是B端产品，给业务的排期反馈一而再再而三的变化，个人的专业度和职业素养无形中也会打折扣。其次，借助自己的软技能，给项目团队灌输Deadline的紧迫感，比如专项背景价值、老板的关注度、业务XX时间节点需要用到该功能等。另外，需求验收环节，要做好问题核对清单管理，尤其是无QA资源产品经理兼职测试。像游戏做任务升级一样，每日统计问题修复进度，并在项目群里总结反馈。如此一方面项目开发及负责人可以清楚地知道目前现有问题，另一方面，也可以看到胜利的终点，而不是不停的改，不停的产生新的问题。测试进度反馈表示例如下，还可以按照前后端、数据责任人再做进一步细分。
三、产品经理常用项目管理工具
工欲善其事必先利其器，借助高效的项目管理工具可以起到事半功倍的效果。选择项目管理工具时可以参考以下几个核心功能维度：
- 协同功能，项目团队可以在线协同，及时更新状态
- 报表功能，直观展现项目任务量，完成度，可细分到功能模块或责任人维度
- 甘特图，清晰地展现各个任务的依赖关系，方便合理安排任务的并行或串行节奏，减少等待时间
- 流程化化，需求状态流转及通知功能，可以方便的指派任务责任人
- 任务清单视图，可以是列表、泳道图、或任务卡
- Buglist，验收时可将Buglist直接与需求任务关联，并且提供Bug统计及燃尽图功能
常用项目管理工具推荐
Jira：比较经典的任务管理工具，是Atlassian公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。
Trello：Trello已经可以帮你整理任何事情，让你的所有任务、想法、资料、讨论通通变得「井然有序」。
Worktile：需求管理、迭代规划、进度管理、缺陷追踪进行管
Tapd：腾讯的需求管理工具，列表式的任务管理
Leangoo：基于看板的项目协作工具。它的核心是看板，通过看板实现团队可视化实时协作
其他还有Tower、teambition等，各个工具基本都是围绕敏捷开发过程（Scrum），进行功能设计，详细的介绍说明可以自行查看。
四、总结
项目管理是一门专业的课程（PMP认证），短短几千字断然无法讲的透彻，本文主要结合一个失败项目踩过的坑分享产品经理在推进产品落地过程涉及到的项目管理技巧。项目管理启动、规划、执行、监控、收尾五大过程组，十大知识领域，各个环节相互影响，某一节点的大意可能都是蝴蝶效应，项目管理过程偷的懒，可能就是产品上线失败流的泪。
启动：获得高层授权，师出有名，提前圈定资源，调动积极性
需求：和主要干系人沟通确认需求，包括业务评审、开发评审，做好记录备忘，信息及时同步
文档：顺利通过开发评审不是终点，项目保质保量上线才是目标，PRD当做产品来做
进度管理：会议、汇报、分阶段验收、信息同步，利用透明的力量强化团队对Deadline的意识
变更：不轻易变更，变更严格按照流程进行
工具：选择合适的项目协同工具
