产品经理必知必会：项目管理避坑指南

数据干饭人 2023-07-30 03:52:10

经历了一个失败的项目，一个不是非常复杂的后台管理模块从需求到上线历时近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），进行功能设计，详细的介绍说明可以自行查看。

产品经理，产品经理网站