项目中遇到问题，产品经理如何解决？

不论我们是瀑布式开发还是敏捷开发，项目中都会遇到各种各样的问题，这时候，如何解决呢？

相信很多刚刚接触产品的新人一定搜索过“产品经理和项目管理的区别是什么”这个问题。

在很多小公司，项目经理和产品经理都是一个人兼任。这经常会让人误以为项目经理和产品经理工作性质相同。同时在无形中也拉低了项目经理和产品经理工作的专业性，给人一种“工作难度不高，随便一个人都能做”的错觉。

我一开始也认为项目经理只是把控项目进度而已，产品经理当然能够兼任项目经理的工作。但真正工作后，尤其是独立做过这么多项目之后，我发现产品经理和项目经理是完全不同的工种。而且产品经理和项目经理的工作都同样具有专业性，很难简简单单地让一个人兼任。

很多人认为产品经理的工作只是画画原型，组织组织评审。但其实不是，产品经理其实在整个项目流程中都是非常忙碌的。在项目前期，产品经理需要沉下心来用户调研、思考方案、产出各种文档，确认好基础方案后，需要组织各式评审，根据各方反馈来不断完善方案。

当然这还是在时间充裕的情况下，如果时间不充裕，产品经理的忙碌程度要加倍：

方案进入开发时，产品需要不断回答开发和测试的疑问，面对意外的技术问题，还需要快速给出替代方案。
项目开发结束，这时候产品经理还需要和测试一起发现问题。
项目上线了，产品经理还需要在现（熬）场（夜）支（陪）持（伴）。
通宵完了，产品经理还不能像开发、测试一样直接请假休息，产品经理还需要挣扎起来做一些后续的工作，例如录入数据、产出培训手册等等。

上述说了那么多，主要是想说明产品经理在整个项目过程中是非常忙碌的。产品工作已经让产品经理焦头烂额了，更不要说在整个项目过程中还需要腾出精力来控制项目进度、协调项目成员沟通等工作。如果产品经理兼任项目经理工作，势必会分散自己工作的精力。所以我认为产品经理和项目经理的人员应该分开来，各司其职，让项目更好更快地上线。

但是这不意味着产品经理不需要了解或者负责项目管理的相关工作。项目经理大多同时会负责多个项目，他只能把控项目的大致进度。而在项目过程中，项目的一些项目经理负责不到的时段“空白时段”，需要产品经理介入，帮助开发、测试快速有效地解决问题。

项目经理在项目管理中，所管理的角色有产品、开发、测试、运维等等全部角色。与项目经理把控全局不同，产品经理在项目中的管理方向，更偏向于对产品和开发、测试合作过程中的自我管理和产品方向的把控。

瀑布式开发和敏捷开发

比较知名的开发方式有两种：瀑布式开发、敏捷开发。

瀑布式开发是传统的、老旧的开发，它需要严格遵守预先计划的需求、分析、设计、开发、测试的步骤顺序进行。各个步骤的成果作为衡量进度的方法，例如衡量产品需求的成果是产品经理的PRD，衡量分析的成果是开发和设计的分析文档，衡量开发的成果当然就是开发团队的开发进度等等。

瀑布式开发是遵循既定步骤的，严格定义了各开发阶段的输入和输出。同时在项目过程中，注重文档的展示和留存。不管是产品还是开发测试，各个阶段都有相应的文档留存，这样对于需求有迹可循。

但是在实际情况中，现在很多公司对产品的采用快速迭代的方法，遵循《精益创业》中提到的MVP原则：开发团队通过提供最小化可行产品获取用户反馈，并在这个最小化可行产品上持续快速迭代，直到产品达到一个相对稳定的阶段。

那这个时候，瀑布式开发就显得过于按部就班、流程僵化了。更为灵活的敏捷开发受到大家的欢迎。在这其中，最有名的Scrum敏捷开发更是被很多公司采用。敏捷开发强调灵活性，充分利用了每个开发者的优势，旨在调动每个人的工作热情。

Scrum敏捷开发中有三大角色：Product Owner（产品负责人）、Scrum Master（流程管理员）、Scrum Team（开发团队）。大家根据产品需求列表进行开发，同时在整个开发过程中开展各种简短的会议，了解每位成员前一天的工作以及遇到的问题。通过这种细小结构的会议和管理，实现对整个项目进度的管控。Scrum敏捷开发更灵活，更强调每位成员对项目的参与和了解。

瀑布式开发只需要项目经理对整个项目流程进行把控，而敏捷开发则是产品负责人、流程管理员、开发负责人形成“三足鼎立”的形式，对整个项目进行把控。

产品经理在项目中遇到的问题

在项目开发过程中，和开发、测试的合作过程中，产品经理很容易会遇到一些问题。这个时候需要产品经理根据实际情况，及时调整沟通流程。

问题1：开发人员不会认真看PRD

在项目开发中，会有一些开发不认真看PRD，对方案和细节都不了解。这会导致在开发过程中，开发、测试频频找产品经理确认需求。这不仅会让产品人员焦头烂额，同时还会影响整个开发效率和开发质量。

开发们不认真看PRD的原因有很多，一个是个人习惯的原因，喜欢先凭着感觉写，到时候测试侧出问题再改；还有一个是在评审时，不管是PRD评审还是技术评审，这种大会形式，很难让开发有效地去研读PRD、熟悉功能。

在这种项目经理无法把控到的“空白模块”，产品经理可以小结构地去优化流程。在评审前，产品经理应该把PRD提前把PRD发出来，让开发和测试有时间对PRD进行研读和分析，这样在评审时，就能将一些重要问题提前暴露出来。

在项目经理组织的评审会议完成后，产品经理应该找到对应模块的开发、测试人员，牵头组织一次小型会议，向开发、测试更详细地讲解PRD上的功能以及业务逻辑。

这个时候由于会议人数少，且都是具体人员，这时候大家就可以把各自的疑问和PRD上的问题提出来，产品收集反馈，后续尽快完善PRD。

问题2：产品、开发、测试消息不协同

在开发过程中，经常会出现这样的情况：测试找到产品反映一个问题，产品给测试解答后，产品再去告诉开发，确定了后再告诉测试。反之如果开发有问题，产品也需要去不断地通知测试。

在这个消息传达的过程中，产品经理在很大程度上是一个“传话筒”。这样不仅极大地分散了产品经理的精力，同时还会让其他人误以为产品就是传话的，削弱产品经理的专业性。

遇到小问题时，可以简单地通知一声。但是稍复杂的问题，在传达时很容易出现信息失误。所以在讨论问题时，应该把相关的开发、测试凑在一起，共同讨论问题现状和解决方案。在这个过程中，产品可以了解开发的技术难度，开发也可以知晓产品的方案思考。

这样的话，减少了产品传话的概率，提高了消息协同的效率。

当然，在开发时，任何改动的需求都应该在确定后发在项目群里，通知所有项目成员。

问题3：如何让产品以外的人了解方案

Scrum敏捷开发中，产品负责人在Product Backlog（产品需求池）中，需要描述好User Story。

我认为产品在向开发、测试讲解需求、功能时，需要善用User Story，让开发、测试有代入感地去认同这个需求的合理性。尤其是SaaS产品的需求，开发、测试自身不是用户，对用户也不了解，很难理解用户的想法和需求。这个时候需要产品向他们描述用户故事，让他们更了解这个方案的设计思路。

例如：

开发问我为什么小程序中管家的新增带看功能可以补录以前的新增带看，这个补录的意义在哪里，忘了提交带看就忘记了，反正带看也不计入业务。

我当时告诉他：如果租客在看房后对这套房子不感兴趣，那不补录带看任务确实没什么问题，对整个系统没什么影响。但是如果租客看完房子后，想要签约这个房子。目前签约的前提条件是有带看记录。那这个时候这个补录带看的任务就是必要的。所以补录带看这个任务的口子是要留着的。

在面对一些不符合常规认识的功能，产品经理在描述时，需要给出具体的、存在的场景。这样听的人就很容易理解这个功能的设计。