做好了产品需求管理，PM就不用挨揍了吗？

今天我们聊一聊产品经理该如何做好产品需求管理，以减少挨揍，更开心的投入工作中。

先来一个灵魂拷问：

一、 产品经理为什么会挨揍？

产品经理为什么会挨揍。要先明确一下大家呼声最高的产品经理的“罪状”：

1. 上线前提出不合理需求，挨揍指数：☆☆☆☆☆☆☆（7颗星）

2. 产品需求天天提天天变，挨揍指数：☆☆☆☆☆☆（6颗星）

3. 开发时间短改动幅度大，挨揍指数：☆☆☆☆☆（5颗星）

以上就是产品经理最容易挨揍的因素，如果还有别的，欢迎大家留言补充哈。

二、 什么是产品需求？

既然产品经理经常因为需求挨揍，我们有必要了解下到底什么是产品需求。互联网产品经理收到的需求一般分为业务需求、用户需求和产品功能需求。业务需求主要包含战略性和规则类需求；用户需求一般是用户的真实反馈、真实诉求和吐槽、建议等；功能需求主要围绕产品的旧功能问题升级、bug处理、技术难题、新增功能实现需求等。当然，产品的需求会随着产品开发版本的迭代越来越多，最终形成一款丰满的产品，要管理好这些需求，就要结合每个开发阶段的实际情况而定。

先用事项管理工具飞项做一个脑脉图，你对理解需求就一目了然了：

三、 为什么要做需求管理？

需求管理没做好，可能跟头图一样挨揍（额，玩笑有点大了）。需求管理在产品开发过程是一个非常重要的工作步骤。任何功能的实现都是基于产品的需求上去做的，需求做得好，不但不被挨揍，还可以跟开发小伙伴愉快的玩耍哦。产品需求的重要性一两句话说不清楚，就好比你执行一个活动没有活动方案一样缥缈：不能很难落地。这么说吧，没有产品需求的提出就没有产品上线。一切开发就是基于需求的提出。

下图是需求管理大致流程：

四、 需求管理怎么做？

产品需求管理之前先要做好需求的优先等级处理。上面说了，产品在不同阶段需求也不同，一款产品成功上线，必须要经历几个需求阶段：第一阶段是初级产品（0-1的产品）阶段。我们优先满足产品的基本性需求或必要性需求，然后才是进阶的概念性需求，最后是上升到价值层面的需求。概念性的需求主要以战略必要性和业务需求为出发点，所有的需求都要围绕公司的战略发展目标来定，是最优先满足的。第二阶段是创意阶段。创意阶段的需求要根据公司目前状况、行业环境、市场环境、竞品环境来综合考虑，这款产品应该有了一个创意模型。第三个阶段是研发阶段，这个阶段产品经理跟开发人员开纠缠不清的始相爱相杀了。

从上图可以看出，产品经理和开发人员几乎都会参与到产品研发的每一个流程中，这个阶段也是两者深度互动的阶段，对需求的管理也是最全面、丰富和严谨的。

第四个阶段是内测阶段。这个阶段工作内容主要以发现产品错误和修改错误为主，首先是明确和验收已有的需求是否满足无误。第五个阶段是产品发布后的需求。这个阶段主要以用户反馈为主。例如收集用户对产品使用的真实反馈和建议，甚至吐槽，产品经理要做好信息的搜集和整理，研发人员要迅速给出合理的解决方案。

最后一个阶段是验收阶段。到了这个阶段，产品的一次完整的研发流程基本上走完一圈了，整个项目差不多接近尾声了。这个阶段产品经理需要处理的事情比较多，比如验收测试、销售和市场推广层面。验收的同时需要做大量的文件沉淀，这是我们团队在飞项工具上做的文档的沉淀和复盘，对后期和研发对接交付清单也是非常清晰和简单了。

这点首推飞项工具，飞项在项目模块里面，对每一个事项都把总结、事项重点、过程文档结构化沉淀事项中，还有表格导出让回顾更加简单，项目内成员对每个环节沉淀和确认的文件也一目了然，自然不会出现扯皮现象。

尽管每个阶段都有不同的需求，但我们的最终目标都是让产品尽快上线、顺利运行。只要围绕整体的策略需求，拆解成不同阶段的需求管理进行击破，这就是完整的需求管理过程了。

五、 需求管理为什么难做？

需求管理难就难在内容的描述和排期，产品人员和开发人员最容易引发争执的点也在于开发出来的产品功能跟原本设计需求功能不一致。大部分情况下，写需求的人是清晰的，看需求的人也是清晰的，但是就是做出来的产品不符合预期的要求。因为每个人对同一个需求的理解千差万别，这时需要我们将需求面对面同步，确保理解一致，形成共识，而不是将文档发上去微盘共享就一劳永逸。

好了，大家都理解需求的难度后。接下来又要面对一个问题：需求的变化。

造成需求的变化来源于很多因素，比如客户临时天马行空的想法，比如一开始没有形成共识文件，或者项目进行中发生业务变化，负责人变化导致。也有可能在开发过程中遇到不可控的因素（这个情况极少）。每一个因素都会导致需求变化，这就要求产品和开发人员在下一个版本迭代前要明确需求。

最后一个问题是需求优先级排期，上一个目录有解释，此处不再赘述。

六、 写在后面。

产品经理跟开发可以长久的保持“和平共处”吗？

当然。产品经理跟开发和平共处不难，各自做好本分工作，产品经理做好需求管理，多学习项目管理工具、事项代办工具（如飞书、飞项等）；开发人员认真理解需求，多给建议，并耐心跟产品经理深入互动。

我相信开发人员不会因为产品人员不懂技术就一意孤行，产品人员也不会因为开发不懂客户就乱指派，两者想要获得对方足够的信任，还是需要双方长期的努力。