如何减少需求的含混性（中）
1 如何切入
当我们说起需求时，其来源是多样的，但基本可以理解为这样一个初始过程：某些人提出一个想法认为某些特性应该设计到产品中。比如，你是微信公众平台的产品负责人，有一天你有了一个想法——文本支持Markdown格式，于是这个想法就转成了最初始的需求。
然而，每个人都有其不同的思考方式，同一个观点不同的人存在许多不同的解释和表述方式，并由此产生许多不同的起点，如果参与者从一开始就没有一致的想法，那么可以肯定的是在项目还没有成功的时候就注定要失败了。仍以文本支持Markdown为例，有的同事支持类似于简书、锤子便签那样嵌入的，另外一位同事通过调研显示通过第三方插件支持即可，这就产生了需求的差异。
2 通用做法
我们怎样才能把大量不同的潜在切入点简化并探索需求？一种可能的解决方法是先认为每个设计项目都可能解决一些问题，然后再简化每个起点，直到问题陈述变得非常普通。
问题的最佳定义是：感受到的事情和期望的事情之间的差别——《你的灯亮着吗？》
这个定义可以用来作为一个模板来衡量启动开发项目的每一个想法。如果某个想法不符合这一定义，那么就和想法的提出者一起来使问题通用化，直到符合为止。
3 具体化
通常，我们有很多不同的切入点。比如，来自解决方案的想法，来自技术的想法，来自一个比喻，来自某个标准，来自某个实体模型，甚至一个名称。
最常见的切入点有可能是对某个解决方案的考虑，二爷鉴书（微信号：findbook）的作者邱岳曾在他的专栏中提到：
在开始把时间花在解决方案上容易陷入「X-Y Problem」的错误中，也就是，我们希望解决 X 问题，然后想到了 Y 方案，随后把所有的精力放在 Y 这个解决方案上，而忽略了对要解决问题本身的理解。
正确的做法应该是：把类似的所谓需求当做一个线索，抓住这个线索不断地向上追问背后的需求动机和需要被解决的问题。
回到第2点“通用做法”中的描述，解决方案往往陈述不清该方案具体要解决的是什么问题，即什么是感受到的（谁感受到的）以及什么是期望的。
书中提到一个例子，某大学一名院长说：“我们需要吸引更多的学生。”有些人理解“更多学生”意味着招收更多的优等生，有的人理解“更多学生”意味着可以在某几个部门资助更多的助教，更有甚者认为“更多学生”表达的是院长希望塞满多余的宿舍空间。
实际上，学校希望增大拨款，必须给州议会留下深刻印象，让他们认为学校工作的质量在提高，因此需要提高申请者的拒绝比例。明白了这个目标，老师们找到了几种不同的解决方法，但是没有一种会增加入学学生的数量。
所以，正如书中所说，在需求切入阶段，我们需要更多的前期思考。
未雨绸缪是避免陷入重大错误假设的最佳办法，所以应该学着养成仔细分析切入点的习惯。
怎么做？最基本的想法就是减缓切入阶段的进展，去调查需求，仔细思考需求，就像禅宗所说的要尽可能地保持一个“初学者的念头”。对于初学者而言，所有的事物都是平等的、新奇的、不可能的。
4 利益相关者
二爷鉴书（微信号：findbook）曾在他的另外一篇专栏中提到：
产品分析时的套路就是反复思考：“用什么方法，解决谁的什么问题。”
其中，“谁的？”指的就是“利益相关者”，如何辨别、定位和找到所有相关人员中的参与者，这是了解需求背后主体的过程。
作者在书中给我们列出了一个步骤。
集体讨论一个潜在使用者列表，列出所有可能的使用者，不仅仅是客户，也包括上下游的“利益相关者”。
通过把他们分类成友好的、不友好的以及可忽略的三类来简化列表，并针对定义的用户群设计详细而精确的使用者活动（我理解为使用者的场景）。
使用参与者的三维坐标，为每个你不想忽略的用户群制作一个对策。谁：通过代言人还是使用者的实际抽样，或者彻底参与？何时：其参与是连续的还是仅仅在一些离散的时间段；怎么：其信息是基于经验还是实验？
执行你的参与计划，用你的想象力和机智去获得你所需要的全部的参与。
5 启发
需求中的含混性无处不在，如果我们想要降低问题描述的含混性，就需要一些工具来使我们的脑子转得慢一些，以防止我们玩命似的试图太早来解决问题。
含混性投票：用性能、时间或成本作为度量，让不同的人对这些度量进行评估，并比较和讨论出结果。
记忆启发：对于那些不能够很好地回忆起来的地方很可能是含义不清楚的。（可以在团队会议中，请不同的人陈述，然后看看是否存在理解不一样的地方）
“玛丽从前有一只小羔羊”，把问题描述重复读，每次将重音放在不同的地方，看是否存在不同的理解和解释。
确定在问题描述中起重要作用的词，然后列出其所有可能的解释。
6 下一篇
《探索需求—设计前的质量》计划写三篇，还有一个下篇，会主要写一写如何明确功能点和期望等内容。
相关文章：减少需求的含混性（上）
#2018年第15篇原创文章#
每周最少两篇文章之2018年第26周（2018.6.25-2018.7.1）记录之二：如何减少需求的含混性（中）