当你在聊需求时，到底在聊什么？

———— / BEGIN / ————

最近有两个洞察，它们跟需求沟通有关，也跟人有关。

第一个洞察是产品经理日常沟通中，绝大多数人（包括客户、销售、实施、客服、客成等），都不知道什么是需求，他们只是以需求之名，在给你提解决方案，期望让你这个“傀儡”去帮TA实现自己的目标。

比如销售同学会跟你说：

境哥，客户的需求是希望工资报表导出公式，这个如果二开的话，需要多少人天？客户对接人说，如果没有这个支持的话，可能会影响合作（😂😂😂）

再比如客成会跟你说：

咱们薪资设置跟自定义报表页面，希望可以取到员工计薪周期最后一天的工时制类型，否则会影响客户算薪

再比如客服主管跟你说：

咱们工资、考勤的字段计算逻辑比较复杂，客户会有很多客诉问题，导致客服效率比较低，咱们可以结合现有系统，做一个单独的页面，把这些字段的计算的公式、规则都清楚显示给客户吗？

你觉得“工资报表导出公式”、“自定义报表支持工时制类型”、“单独一个页面显示计算公式”是需求吗？

不是。

可他们明明跟你说的是“找你沟通个需求啊”。

想到这里，就让我发现了第二个洞察：绝大多数人都喜欢抽象表达，而不喜欢具象化（哈哈，当我写下这句话的时候，就是对这个洞察最好的印证）。

人们好像觉得抽象化表达，可以隐藏自己的真实想法，避免有一种被人看透的感觉，期望保持对对话的绝对掌控感和主导权，仿佛一旦开口就把自己的问题（或目的）说出来，瞬间就输了一样。

比如那位销售同学，TA其实想说的是：

境哥，我们最近在跟进一家做人力资源外包的A类客户，他们跟多个公司合作，如果采购咱们的系统的话，他们需要每个月导出对应的工资、考勤报表，让每个合作方确认，担心直接给结果会导致对方有疑问时，反复追问，所以最好是可以把对应公式一并导出，她们线下就是这么干的。

那位客成同学想说的是：

客户会有综合工时制、标准工时制等不同工时制员工，如果当月发生过转岗时，希望可以在工资报表中，有效进行筛选与区分，便于最终工资分别核算。

而客服主管想说的是：

咱们系统的工资字段计算逻辑复杂，导致客诉问题较多，最近3个月相关客诉问题有13起，每次客服都需要花10分钟以上才能解释清楚逻辑，你这边有什么好的解决方案吗？

方案 ≠ 需求

方案不等于需求，就像观点不等于事实一样，可情感脑总会战胜理智脑，让你懒得分辨。

什么是需求？

需求是目的，是回答“为什么”的问题。用一个公式表达就是：需求 = 用户 + 场景 + 问题。

一般会有两种表现形式：

第一种是大白话式。即谁在什么情况下遇到了什么问题，产生了什么样的情绪感受。

比如我最近两天遇到了上述三个案例，每次都需要反复追问（获取有价值信息）和解释（避免对方觉得你是拿鸡毛当令箭），才能获取到所需要的信息，产生了一种心累、不想反复解释的心情。

第二种是用户故事式。即作为一名[角色]，我期望在做[XX]的时候，有一个[XX]功能，以便于实现[XX目的]。

比如作为一名产品经理，我期望客户（或销售/客成等）在提需求时，可以直接去且具体的说问题，以便于我可以快速了解需求本身，寻求不同解决方案。

什么是方案？

方案是手段，是回答“怎么办”的问题。用公式表达的话，就是：方案 = 问题 + 工具/服务。

换句话说，方案是服务于问题本身，不能独立存在，而它的形态可能是一个工具或一项服务。

比如针对上述三个案例，我可以提供一个标准化的解决方案：需求池+提需求模板解决。

如果你有需求，按需求模板（即描述清楚遇到的问题、现在的解决方案、期望解决方案）先提需求池，我基于需求进行回复，避免过多私聊。

如何判断是需求，

还是方案？

第一，如果用户描述“需求”时，完全跟系统/产品相关，那就是方案。比如“导出报表“、“自定义报表新增工时制”等，本身就蕴含了“系统”在里面，基本就可以判断它是方案。

它们之间的关系，就有点像用户问题跟产品之间的关系，用户的目的不是使用产品，而是解决自身问题。

第二，如果用户描述“需求”时，完全没有提到人（或角色）、完全没有提到问题（或困扰），那就是方案。反之，则是需求；

如何解决用户总是提方案，

而不提需求的问题？

如果是口语沟通的话，可以追问三句话：