最近有两个洞察，它们跟需求沟通有关，也跟人有关。
第一个洞察是产品经理日常沟通中，绝大多数人（包括客户、销售、实施、客服、客成等），都不知道什么是需求，他们只是以需求之名，在给你提解决方案，期望让你这个“傀儡”去帮TA实现自己的目标。
比如销售同学会跟你说：
境哥，客户的需求是希望工资报表导出公式，这个如果二开的话，需要多少人天？客户对接人说，如果没有这个支持的话，可能会影响合作😂😂😂
再比如客成会跟你说：
咱们薪资设置跟自定义报表页面，希望可以取到员工计薪周期最后一天的工时制类型，否则会影响客户算薪
再比如客服主管跟你说：
咱们工资、考勤的字段计算逻辑比较复杂，客户会有很多客诉问题，导致客服效率比较低，咱们可以结合现有系统，做一个单独的页面，把这些字段的计算的公式、规则都清楚显示给客户吗？
你觉得“工资报表导出公式”、“自定义报表支持工时制类型”、“单独一个页面显示计算公式”是需求吗？
不是。
可他们明明跟你说的是“找你沟通个需求啊”。
想到这里，就让我发现了第二个洞察：绝大多数人都喜欢抽象表达，而不喜欢具象化（哈哈，当我写下这句话的时候，就是对这个洞察最好的印证）。
人们好像觉得抽象化表达，可以隐藏自己的真实想法，避免有一种被人看透的感觉，期望保持对对话的绝对掌控感和主导权，仿佛一旦开口就把自己的问题（或目的）说出来，瞬间就输了一样。
比如那位销售同学，TA其实想说的是：
境哥，我们最近在跟进一家做人力资源外包的A类客户，他们跟多个公司合作，如果采购咱们的系统的话，他们需要每个月导出对应的工资、考勤报表，让每个合作方确认，担心直接给结果会导致对方有疑问时，反复追问，所以最好是可以把对应公式一并导出，她们线下就是这么干的。
那位客成同学想说的是：
客户会有综合工时制、标准工时制等不同工时制员工，如果当月发生过转岗时，希望可以在工资报表中，有效进行筛选与区分，便于最终工资分别核算。
而客服主管想说的是：
咱们系统的工资字段计算逻辑复杂，导致客诉问题较多，最近3个月相关客诉问题有13起，每次客服都需要花10分钟以上才能解释清楚逻辑，你这边有什么好的解决方案吗？
方案 ≠ 需求
方案不等于需求，就像观点不等于事实一样，可情感脑总会战胜理智脑，让你懒得分辨。
什么是需求？
需求是目的，是回答“为什么”的问题。用一个公式表达就是：需求 = 用户 + 场景 + 问题。
一般会有两种表现形式：
第一种是大白话式。即谁在什么情况下遇到了什么问题，产生了什么样的情绪感受。
比如我最近两天遇到了上述三个案例，每次都需要反复追问（获取有价值信息）和解释（避免对方觉得你是拿鸡毛当令箭），才能获取到所需要的信息，产生了一种心累、不想反复解释的心情。
第二种是用户故事式。即作为一名[角色]，我期望在做[XX]的时候，有一个[XX]功能，以便于实现[XX目的]。
比如作为一名产品经理，我期望客户（或销售/客成等）在提需求时，可以直接去且具体的说问题，以便于我可以快速了解需求本身，寻求不同解决方案。
什么是方案？
方案是手段，是回答“怎么办”的问题。用公式表达的话，就是：方案 = 问题 + 工具/服务。
换句话说，方案是服务于问题本身，不能独立存在，而它的形态可能是一个工具或一项服务。
比如针对上述三个案例，我可以提供一个标准化的解决方案：需求池+提需求模板解决。
如果你有需求，按需求模板（即描述清楚遇到的问题、现在的解决方案、期望解决方案）先提需求池，我基于需求进行回复，避免过多私聊。
如何判断是需求，还是方案？
第一，如果用户描述“需求”时，完全跟系统/产品相关，那就是方案。比如“导出报表“、“自定义报表新增工时制”等，本身就蕴含了“系统”在里面，基本就可以判断它是方案。
它们之间的关系，就有点像用户问题跟产品之间的关系，用户的目的不是使用产品，而是解决自身问题。
第二，如果用户描述“需求”时，完全没有提到人（或角色）、完全没有提到问题（或困扰），那就是方案。反之，则是需求；
如何解决用户总是提方案，而不提需求的问题？
如果是口语沟通的话，可以追问三句话：
- 第一句：“咱们现在是遇到了什么问题？”
- 第二句：“咱们现在是怎么解决的？”
- 第三句：“咱们期望的结果是什么？”
如果是书面沟通的话，可以提供一个需求模板：
- 请描述你当前遇到了什么问题？
- 请描述当前你是怎么解决的？
- 请描述你期望的理想结果是什么？
总结
今天主要跟你分享了两个洞察：
- 绝大多数人（包括客户、销售、实施、客服、客成等），都不知道什么是需求，他们只是以需求之名，在给你提解决方案；
- 绝大多数人都喜欢抽象表达，而不喜欢具象化。
如何有效识别是需求，还是方案？根据用户提“需求”时，是否隐含了“系统”在内？或是否没有描述遇到的问题？如是，则是方案；
如何有效解决提方案，而不提需求的问题？请使用关键三问（即遇到什么问题、现在如何解决、期望结果是什么）。
