许多时候我们城市碰着一种“你就这么做”的需求，假如处理惩罚欠好，很大概给本身挖一个大坑。作者总结了3个步调，但愿可以帮到你。

最近事情中老是接到一种需求：我要 XX成果，这么做就行！

也就是需求提出者直接带着办理方案找过来，这种需求在产物的事情中十分常见，假如处理惩罚欠好，很大概给本身挖一个大坑，这篇文章聊一下可以如何接这种需求。本文的描写是基于本身的 C端经验。

从业务部分的一个需求说起

在家办公期间溘然接到业务线老大的一个语音，开门见山的和我说：此刻我们做的直播，想要在直播进程中和用户增加互动，需要在直播中加上答题成果。

详细方案：一次最多 5道题，主持人提倡，(此处省略 500字)，甚至靠山怎么共同都给我说了，然后紧接着问我：什么时候能做完上线？

这种直接带办理方案的需求在产物的事情中，常常会遇到，尤其是业务主导，业务方较量强势的公司中更为常见。假如我们直接执行会奈何呢？

产物司理直接从办理方案出发会遇到的问题

对付这种需求，有时大概习惯性的就随着提出者的办理方案走，直接接头办理方案的逻辑及细节。

趟了屡次坑之后，我发明直接随着办理方案走，很大概会碰着如下两种环境：

（1）需求是公道的，可是提出者给的办理方案并欠好，只是就问题办理问题

这种环境下，提出者的需求是公道的，但由于提出者大概并不具备产物的专业技术，导致方案有缺陷，无法办理问题。

好比，产物的活泼度很低，不康健，于是认真的同事 A找过来：我们产物的活泼太低了，要晋升，我们要多给用户增加推送，天天推送 10条，让用户想起我们，打开我们！

用户活泼度低需要晋升，这个没问题，可是不阐明原因，强行 push，打搅用户，大概初期有一点点结果，但恒久下来，只会让产物的卸载率上升。

（2）需求是不公道的，是提出者想虽然的功效

这种环境，提出者提出的需求是“错误”的，是本身想虽然的，给出的办理方案一定也是错误的。

常见于不思量产物的方针用户，以及用户的实际利用场景，只是纯真的就成果自嗨。

以上两种环境，无论是哪种，假如产物直接随着办理方案走，最终的结果都不会很抱负，甚至会导致项目重复，姑且改观，越做越巨大的环境。

对付这种“你就这么做”的需求如何接

首先我们要知道，办理方案并不便是需求！对付这种环境，我们要回到需求自己，从需求入手。

很重要的一点是：接头问题，以问题取代方案来和提出者接头。

可以分为以下几个步调：

1. 拒绝通报需求，尽大概找到“需求当事人”

在事情中，大概有许多时候，需求是由老大可能业务部分的老大直接提给产物司理的，也就是需求颠末尾其他人的通报，这种环境下，信息内容大概会失真，和开始的需求纷歧致，甚至大概“涣然一新”。

我们在吸收信息的时候会颠末两步：领略与加工；领略中大概会呈现毛病，在不自主的加工后信息的失真会更严重。

在通报中，他人对信息的领略与加工，大概会影响我们的判定，假如直接凭据通报者的说法做，很有大概偏向是错的。

因此，在实际事情中，照旧发起答允的环境下，尽大概的和“需求当事人”直接打仗，相识一线需求。

好比，笔者曾经认真的一个小措施，中间有一个步调需要用户授权昵称以及手机号，但在开拓的时候发明已经不答允同时获取昵称和手机号了，原来规划调解方案，分隔获取。功效一个同事说正好他需要找一下业务，可以资助相同一下，给我返回的功效是他们不要昵称了，但给到业务测试的时候，发明人家原本的意思是：可以在这一步不要昵称授权，而不是可以完全不要昵称。

2. 明晰是业务需求照旧用户需求

对付提过来的需求，我们先大抵分为两个范例：业务需求和从用户角度提出的需求。

之所以要先区分，是因为，这两种需求的出发点是纷歧样的。

对付 C端产物，业务需求凡是来自于运营和市场同学，出发的角度是如何更好的运营用户，是从“KPI”角度出发的；而从用户视角出发的需求，则是认为用户是有这个需求的，这么做是更好的辅佐用户。

因此，我们对接这两种需求的要领也会有所差异。

（1）业务需求

这类需求是业务部分内部的，好比业务部分需要做个勾当，可能要晋升某个指标，需要产物端共同。

文章开头的例子中，运营人员提的直播中答题的成果，就属于这种。