做不完的需求 - 这个需求也要这周搞完.docxVIP

产品经理如何理性对待客户需求

编辑导语：产品经理在日常管理工作过程中会遇到很多企业需求，对于学习这些数据来自不同发展方面的需求，产品经理会进行分析判断能力以及筛选；并且在面对一些研究比较紧急的需求时，产品经理也需要一个合理的安排；本文作者分享了关于如何对需求信息进行科学合理排期，我们一起来了解一下。

需要，永远不会结束。

这里的项目进展不如预期，新的需求一个接一个地被提出来，积压的项目越来越多。.

这样的困境，你的同事和朋友应该有一些经验。

就像人来车往的十字路口，如果我们不加控制管理，很容易就会导致出现大拥堵；既占用了企业大量人力资源，又不能产出进行匹配的成果。

所以，就像一个交警指挥控制交通发展一样，我们需要对“需求”进行科学合理排期。

01

当涉及到“需求调度”或“需求管理”时，总是有一种“产品经理从上面指挥团队”的感觉。

为了避免对新产品的误解，我们应该在这里强调一下。

从本质上讲，“需求”需要我们怎么去排期，是由各个企业需求分析自身的情况所决定的。

“先做这个社会需求，后做那个时代需求”，并不是一个基于企业产品经理个人的喜好或权威，而是因为某个需求分析本身发展就是更紧急的、更重要的。

从实践层面来看，需求优先与否是利益相关者共同博弈的结果。

需求方的意见，执行管理团队的情况，领导的态度，现实的限制，等等。

产品经理并不比所有利益相关者有更高的权力。

产品经理只是一个声音，或者说是组织者、协调者和聚合者的角色;因此，如果你想做好“需求计划”，那么保持诚实、敏感的眼光和知道做什么的基本知识是很重要的.

除非你是在管理一个大的产品矩阵，“需求计划”不需要很复杂。

02

首先，我们需要简单地拆解“需求”。

举个例子：

今天我们老板把你叫到办公室，说了自己这么简单一段话：

“你需要制作...出于某些商业原因，a级产品需要引导用户通过x流程购买...是的，从这个页面开始跳到这个页面...嗯？用户信息应该自动显示出来。你为什么要求用户再次填写它...是的，最后一级产品来这里支付...”

你走出办公室，发现需求并不复杂，你决定开始工作。

但是，且慢。

仔细认真想想，这里面我们真的是“1个需求”吗？

其实我们不然，这里工作面有2个需求。

1）a类产品指导用户通过x流程购买。

有一个类别的产品涉及和需求是迫切的“一些商业原因”。

2）进入购买页时，自动带入用户信息。

这涵盖了所有的产品，虽然对于改善用户体验很有帮助，但也不用着急。

更重要的是，“需求2”是否可以实现，完全为了不影响“需求1”！

如果不进行拆解，囫囵吞枣地当做“1个需求”去做，就有可能出问题。

简而言之，有两种可能的情况。

“需求2”涉及面广，需要大量的工作；所以“需求1”虽然紧急，却被不相关的“需求2”延迟，导致上线时间延迟。

团队将“需求1”列为优先事项，并部分上线;由于每个开发周期都有新的紧急项目，未完成的“需求2”被留到了下几个开发周期。

第二种情况，我个人很讨厌。

往往我们需要我花费很多学生精力去沟通工作推进，最终延迟了非常多时间，“需求2”才能进行完成系统上线。

并不是所有需求方的“1次沟通”，就是“1个需求”。

产品经理需要根据需求的范围、工作量、紧急程度等因素对“需求”进行分解和分离。

03

我认为，需求在拆解之后，原则上每个需求都应该单独立项，分开处理。

因此，沟通更加有效，项目管理更加简单和灵活。

当然，也有例外。

大多数学生时候，产品销售经理手上都会积压着若干问题待处理的需求。

在对这些企业需求信息进行排期时，需要通过观察各个需求之间的关系。

有时候，当多个需求一起处理时，效率会更高。

常见情况如下:

1.几个方面需求，都在同一个管理模块内

举个例子：

表单页，新增一个可以上传文件管理模块。

表单页面，优化一个底部弹出窗口。

表单页面，调整混乱的样式。

虽然这几个方面需求发展之间没有社会关系，但是都涉及同一个模块。

如果一个紧急发展程度都差不多，那安排到一起进行处理，效率会高很多。

2.需求的实施影响需求2

比如说：

修改登录注册模块。

新增一种登录方式。

容易想到，如果用户登录系统注册管理模块进行改版了，那在做“需求2”时，就得按照新的样式去策划。

如果，先按照旧的样式把“需求2”搞出一个来了；那等到做“需求1”时，“需求2”也得重做。

这肯定是会被diss的。

因此，这种情况必须合并成一个项目来处理。

另外，如果“需求1”不紧急、“需求2”紧急，那么企业合并后，“需求1”的紧急发展程度也得同步进行提升。

3.可以用一个更大、更通用的需求，把几个关联的小需求cover掉

例如，某个过程收到了