做的功能已经上线了，运营验收的时候说不是想要的怎么办？

青锋 2023-07-29 05:56:41

相信不少产品经理都遇到过这样的问题，在做原型设计的时候感觉功能已经很完善了，但等上线后，运营验收的时候却说这个功能不是我想要的，然后又提出一堆待优化点和新需求。你可能会疑问，当时是按照运营所提的需求来做的呀，但最后运营为什么会变卦呢？

出现这样的问题，主要原因是因为需求分析不准确，导致产品设计的方向跑偏了，所以最后做出来的功能自然不能满足用户需求了。

笔者在入行前也曾多次遇到这样的问题，当时只觉得运营的需求太善变了。时隔多年，自己也积累了不少项目经验，今天就结合自己的经验做下复盘，分享一下个人感受（运营人员也是我们的用户，所以，以下文章均称为用户）。

《代码大全》的作者Steve McConnell报告说，产品60%的错误存在于设计中，而设计的错误60%的源于需求和分析活动。所以，能准确的挖掘到用户需求，对于产品经理来说是多么重要的事情。

01 用户所说的未必是真的

有一个说法叫“冰山理论”，它指的是一个人的“自我认知”就像一座冰山一样，我们能看到的只是表面很少的一部分，而更大一部分的却隐藏在更深底层，不为人所见，就像漂浮在海面上的冰山一样。

用户的需求也像一座冰山，有很大一部分隐藏在海平面以下，只有很少一部分需求暴露在海平面以上。

有时候我们收到用户需求后，也按他们的要求做了，但上线之后发现所做的东西并不是他们想要的，或者说是不完善的。

这时候如果你如果质问他们“当时怎么不说清楚呢？”，那他们就会反问你“你是产品经理，这些都是你该考虑的，我只负责提需求”。

这时候你应该责怪谁呢，是怪自己还是怪用户。事实上他们所提的需求只是他们已经意识到的，更深层次的需求隐藏在冰面下那些没有意识到的需求，当然没法告诉你了。

这就给我们的需求调研工作带来了很大的困扰，这时候产品经理就应该从自己专业的角度上触发，帮他们找到那些隐藏在冰面下的需求。我们经常所说的需求挖掘，主要就是找到隐藏在冰面下的需求。

所以，用户的需求分成意识到的需求、无意识的需求、进一步的需求三种。

意识到的需求：在海平面以上的需求，通常是一些困扰用户的问题，或者是用户自己能想到的功能。大部分产品经理在调研的过程中获取到的都是这一类的需求；
无意识的需求：它是用户在实际工作场景中“没有意识到的问题”，这种问题需要产品经理对业务有一定的理解才能发现。只有对这类场景能做到“感同身受”的话，产品经理设计的过程中才能够设计出更合理、更高效的方案；
进一步的需求：对于用户遇到的问题，他们毕竟只是普通的工作人员，并不是技术专家。因此对于他们自己遇到的问题也没有办法提出关键的解决方案。因此需要产品经理对问题充分理解的前提下，选择合适的实现方式以创造用户未想到的功能；

举个例子，夏天的时候男生们都喜欢到操场上打篮球，打到中途口渴的时候一般都会到自动售卖机上买饮料。请问，对于打篮球的男生来说他们的意识到的需求是什么？对，他们的需求是想喝水解渴。

那没有意识到的需求是什么？他们想喝水的目的，首先是因为运动激烈，水份消耗过快，所以想要喝水口渴。另外激烈的运动会让身体产生大量的热烈，他们想给身体降温。

那进一步的需求又是什么呢？男生们出去打篮球往往是穿上篮球服，随身带着手机就出门了，但是打篮球总会弄着双手，如果用手机支付的话就会弄脏手机，这时候如果这个售货机能提供刷脸支付的功能，对于男生来说就是解决了他进一步的需求了。因为在刷脸支付技术没有出现以前，他们是不知道不用手机也可以实现支付的。

所以通过这样的场景设想，我们就可以整理出男生打球的过程中意识到的需求是喝水接口，无意识的需求是想要喝冰水，进一步的需求是刷脸支付。

02 如何抽丝剥茧，抓住真正的需求

首先，我们应该把用户需求做个分类，只有将需求做好分类，我们做需求挖掘时才能有的放矢。

我们可以将用户的需求可以分成基本需求、期望需求、兴奋型需求。

基本需求就是一个产品必备的需求，这类需求是即使用户不说，在做产品设计时也应该考虑的。
期望型需求就是用户期望做到的，一般是用户能比较清晰的知道的，一般是用户提出来的。
兴奋型需求就是超预期的需求，一般是用户没有意识到的，也就是隐藏在冰山下面的需求。

一个产品一般会经过导入期、成长期、成熟期和衰退期四个阶段。

在产品的导入期应该着重满足用户的基本需求。在产品的成长期应该选择性地去满足用户的期望型需求，并且完善原有的需求。在产品的成熟期关注更加细节方面的需求、体验性的需求，以及挖掘其他隐性需求，也就是超预期的需求。产品的衰退期，这时候产品经理需要考虑怎样去挖掘更多新的需求去满足用户，甚至开拓新的产品项目。

那么，我们应该怎么去挖掘用户的需求呢？我们怎么判断他们所提的需求就是他们想要的呢？

首先让我们先来看个例子，妈妈带小明一起出门逛街，小明突然说“妈妈，我我渴了，想喝水”，这里的想喝水是小明的基本需求。因为小明说的“口渴”是现状，而水能解渴，应该顺便给他买瓶矿泉水。

所以我们通过上面简单的案例可以看出，需求分析的第一步就是逻辑推理。通过用户所提的需求进一步进行逻辑推理。小明“口渴了”案例逻辑推理就是：口渴—水能解渴—买矿泉水。

但是，如果妈妈给小明买瓶矿泉水真的能满足他的需求吗？不一定，那如果他刚出门才喝过水，刚一出门路过奶茶店就说自己渴了，那可能是他想喝奶茶了。如果给他买瓶矿泉水就不能满足他的需求了。

所以，完全通过逻辑推理并不能他需求挖掘完整，也许还会出现错误的需求，我们还要加入情景分析才能挖掘出正确的需求。

综上所述，我们可以将需求挖掘整理以上公式：

【什么人】（角色）

【什么业务场景】-【遇到什么样的问题】-【客户有什么需求】

【现在是什么样的】-【期望的步骤】-【可选的解决方案】-【最终方案】

基于这个公式，我们在挖掘需求的时候，可以先在合理的范围内，设定不同的用户和不同的场景，然后将不同的用户匹配到不同的场景，就像排列组合一样，分析他们的目的。

03 听取用户意见，但别照着做

在通过各方收集到相应的需求之后，产品经理还需要懂得如何对需求进行管理。收集到需求的时候，注意建立需求池对需求进行记录和整理。

我们在做产品设计时还有一个很大的误区，就是全盘听取用户意见，用户提什么需求我们就做什么需求。

产品的需求可以说是无上限的，大量的堆积需求，会使得产品非常臃肿，而且毫无特色，而需求的过多，还会导致工期过长，拖慢了产品推出市场的进度，对产品百害而无一利。

因此，产品经理需要了解产品的加减法。需求如何处理？在什么时候需要加？什么时候减？在需求收集阶段，我们一直在做需求的加法，不断地增加需求的量，增加所有能够得到的需求。在进行需求分析、需求评审的时候，我们则需要不断地对需求做减法，确认了需求之后，需要对需求进行优先级排序。减掉的需求并不代表这以后都不会使用，所以记得先保留着不删。

我们应该听取用户意见，但不要照着做。正确的做法是听取各方意见，准确分析他们的需求和期望，结合各方意见最终做出最产品价值最合理的决策，这才是产品经理的职责所在。

我们应该紧盯我们的产品目标，对于产品目标有利的需求和建议就采纳，对于产品目标不利的需求和建议就舍弃。