你真的理解需求过程吗？

题图：来自Facebook，Andy Weir

前言

为什么我们从来没时间把事情做好，却总有时间返工呢？

有资料显示，产品中发现的缺陷有40%~50%是在需求阶段埋下的“祸根”，需求阶段的问题不但造成了大量的无效工作，也间接影响了团队的士气，降低了产品质量和业务价值。

为什么会出现这种情况呢？我们可以试着从需求的定义来找一找原因。

关于需求的定义，有两个比较有代表性：

其一是《探索需求-设计前的质量》这本书中，作者把需求定义为「一个试图发现人们对新产品的期望的过程。」

其二是《需求工程：良好实践指南》这本书中，作者把需求定义为「需求是对我们应当执行的任务的规范说明。它描述系统的行为特性或属性，可以是一种对系统开发进程的约束。」

无论是哪个定义，需求涵盖了来自客户视角的外部系统行为以及来自开发人员视角的一些内部特征。正是因为接口和过程的多样性，给需求管理带来了不确定性和含混性，而产品开发是一门精确的学科，如果我们自己都不知道想要什么，那么开发过程越精确，其结果偏离越大。

本文结合自己踩过的坑，汇总一下探索需求的过程，以及如何尽量减少需求分析过程中含糊不清的地带，达到「明白自己在做什么」的目标。有四个部分可以概括探索需求的内容，本文主要讲人性因素、含混性来源和消除含混性的方法。

一、人性因素

在产品和系统开发方面有经验的人可能有这种体验：产品成功的关键越来越依赖于人的因素，所以他们会花更多的时间来与人打交道，而花较少的时间在技术任务上。

人与人不同

需求的产生，我们可以理解为：某些人会提出一些想法并觉得某些特性应该设计到产品中并通过技术手段去实现。在这个过程中，如果是我们自己的一个想法或许不会产生什么问题，但因为「人」来自不同的群体，针对同样的事情看法可能截然不同，认识到这个差异性是我们探索需求的起点。

比如，有一名大学院长说：“我们需要吸引更多的学生”，如果仅仅理解字面意思，“更多学生”可能是指学生数量，也可能意味着招收更多的优等生等。实际上院长需求背后的动机是提高申请者的拒绝比例来增加拨款。

我之前遇到过一种情况，领导和客户代表沟通后说希望通过一个智能分析算法实现道路车流量检测、统计出一定时间段内道路通行车辆计数功能，然后工程师就把分析算法当做核心工作开始了开发，等做得差不多了的时候去和客户再次沟通，才发现客户并不关心算法，他关注的是统计出的数据能给他带来什么分析和推论，按照这个思路往下走，实际上数据处理、分析和深度挖掘，才是这项工作的真正需求。

人的知识不完善

在需求分析及探索过程中，负责需求的人员见识和技能的不同，结果也会存在较大的差异。在需求调研的开始阶段，用户访谈是比较常见的方式之一，但一个错误的假设或者错误的问题顺序，会导致你给客户的每个解决方案都是正确的，但解决的都是错误的问题。

而在产品开发过程中，人的知识不完善体现得更加明显。没有人是全能的，结构工程师很大概率不懂电气，那在机电结合的环节，就存在一个隐藏的含混性。之前的项目中，结构按照自己的设想设计了一款外观得到所有人称赞的方案，但实际安装环节，发现结构和电气设备之间的配合问题比较多。还有硬件和嵌入式，假如嵌入式想实现一个创新算法，其对硬件的运算速率、有效存储往往有要求，但如果在项目开始前不把这些含混的地方讨论清楚，最终的结果往往是更改设计方案或者被迫放弃新的功能。

群体无意识

个人一旦进入群体中，他的个性便淹没了，群体的思想占据统治地位；而群体的行为表现为无异议、情绪化和低智商。——勒庞《乌合之众》

我们在需求分析过程中，经常会遇到这样的情况：拿着一份需求分析报告，在和同事、领导沟通的过程中，在尖锐的问题、不同的观点交相碰撞中败下阵来。一方面可能是我们对需求的研究不够深入，没有发现需求的真正意图；另外一方面，人是群体性动物，当面临同事的质疑、领导的强势时，我们很容易就妥协了，从而进入「群体无意识」状态。

比如：一款产品，按照设计路线图，可能需要三个版本才能实现的一个功能，领导可能要求在第一版就实现。这中间就缺少了过渡和缓冲，就如婴儿出生与成长一样，很多事情需要时间和成长空间。

有一个故事是这么说的：

“给我们用最低的成本解决。”
“在最短的时间内搞定。”
“我们必须尽可能以最好的方法完成。”

放在健康人身上，优化神经收到这些请求后，会给嘴发送一个脉冲，让它回答：“那你愿意牺牲什么呢？”

可在群体中，这部分神经通路被切断了，嘴里就会吐出一些扭曲的话语，比如：“好的，老板。我马上去办，老板。”

探索需求的方法论和原则

和其他很多事情一样，在探索需求的过程中，人几乎是一切问题的根源。站在个人的角度来说，我是我大多数问题的根源。

探索需求需要遵循的原则离不开人性因素，如果一开始就想到了人与人之间存在差异，个人力量有限，我是引起大多数问题的原因，在群体中容易陷入对权威的无意识跟随，那么在需求探索的过程中，我们就可以有针对性地去避免这些问题。

有一个方法是将自己保持为“初学者状态”，对初学者而言，所有的事物都是平等的、新奇的、不可能的。

二、含混性来源

在我们日常工作中，需求的获取方式主要来自访谈、工作坊、焦点小组、观察、问卷调查、系统接口分析、用户界面分析、文档分析等。结合第一部分介绍，需求含混性的来源非常多，比较常见的有以下几种。

1、观察和回忆错误（需求调研前后，对用户行为的观察和回忆错误）

2、解释错误（看到一种现象，用自己的观点而非客观事实来解释）

3、错误来源的混合（比如设计一款产品，不仅仅需要考虑直接用户，还需要考虑投资人的期望，需要关注产品上下游维护和现场支持人员的功能及非功能需求。如果我们把需求方弄混淆了，或者把用户的需求嫁接到投资人身上，其结果往往南辕北辙。）

4、人们交互的作用（我们在分析问题时，鼓励相互独立，但在听到一个不同的见解或新的问题解释，我们改变了初衷。但这种初衷的改变并不是提高了观察力，而仅仅是被他人影响。）

5、问题陈述的含混性，有一类案例比较有代表性：玛丽曾经有一只小羊羔，这是今年我看过的最好的电影，我真的没有骗你。试试把重音放在不同的词语上，带来的结果差异。

在参与需求工作时，我们可以采用直接使用回忆启发的方法来验证含混性。只要简单地拿走书面的需求文档，再请每个参与者根据记忆写出其中所指的内容就可以了。那些有回忆差异的地方就是文档中有含混性错误倾向的部分。这一步非常重要，因为几乎很少有人会在工作中实际参考那些需求文档，他们更喜欢根据他们记忆中的文档内容来办事。因此，易于正确回忆起来的文档很少会带来设计错误。

三、消除需求含混性的方法

需求带来的模糊地带如此之多，有什么好方法能够尽量减少错误的发生呢？我们可以从两个方面来提升。

其一是需求的目标，需求记录要做到：完整、正确、可行、必要、无二义、可验证、定出优先级；需求规格说明书要做到：完整、一致、可修改、可跟踪。

其二从需求的内容着手，将功能、属性、约束、偏好、期望等循序渐进地明确下来，得到一个比较精确的定义“产品是做什么用的”。正如冯·诺依曼说的：“我们只有知道自己在讨论什么，对其强求精确才是有意义的。”

下面选几个不同阶段的方法讨论一下这个过程。

找到相关人员

在开发活动中最为常见的单个错误可能就是在过程中遗漏了某个必需的人物。所以第一个需要问的就是“谁是客户？”客户决定产品的外部属性，比如产品值多少钱。其次是找到产品的使用者，使用者是真正使用产品的人，产品的成败由他们决定，我们身边有非常多的例子，有分析指出，很多公司购买了各种软件工具，但70%被束之高阁，除非产品找到了真正的使用者，否则一切都是镜花水月。

一种方法是我们先列出所有可能的使用者，利用我们的“共情能力”，对用户立场和偏好进行深刻理解，理解他们的关注点，然后根据设计方案将使用者群体分为「对他们非常友好」、「忽略他们」、「对他们非常不友好」几类，这些角色的定位除了对单一功能点的分析有价值外，也会决定需求的优先级。

需求评审

我一直认为需求评审就像少林弟子闯十八铜人阵，你只有过得了这一关，才有可能出师或者去研习更高深的武学。

需求评审串起了前期的需求收集和分析，不同利益相关方的博弈，以及后续项目落地实施的计划管理等各个方面，评审会议本身只是露出水面的一角，想让评审更有效，事前和事后都要做不少工作。

需求评审如果完成得好，则后续项目可能会比较顺利，如果完成得不好则给后续环节带来了更多的混乱。

一个比较好的做法是：产品经理全权负责，充分做好前期准备，把文档、原型图、解决方案、会议等组织好。一方面我们通过需求评审会去验证自己对于用户深层需求的挖掘是不是正确；另外一方面是向实现产品的团队，包括开发、测试等讲清楚需求的背景和来龙去脉，以及产品为什么这样做，同时向他们交代产品的解决方案，让设计师、工程师弄清楚自己将要制造一个什么东西，长成什么样子，怎样运转，有哪些特性等。

技术复审

有两个基本途径使得需求信息会发生错误：不充分或者不正确。技术复审可以有效地解决需求信息不正确这个错误，技术复审可以分为非正式和正式复审，非正式复审可以将问题反馈提供给需求制作者以帮助改进产品，正式复审则将最终结论提供给管理者。

举一个例子：比如一款产品想实现车辆在1米范围内的精确测量，我们以普通的72km/h来计算，系统需要的分析时间为50毫秒；而如果想实现5厘米范围内的精确测量，仍以72km/h来计算，系统的分析时间则需要做到500微妙。这种量级的差异，会导致设计方案完全不一样。这就是技术复审的意义所在。

需求驱动测试

在需求的定义阶段，我们还可以使用测试中常见的概念：黑箱测试。因为在需求阶段，设计解决方案是一个真正的黑箱，我们在此阶段，可以先不用过分关注如何实现，先将关注点放在输入和输出上，尝试不同的输入会导致什么输出。也就是“如果X发生了，产品应该做Y事。”

之所以提这个，是因为在实际工作过程中，我们经常会将「解决方案」定义为「问题」。这种错误也被称作 X-Y Problem，也就是，我们希望解决 X 问题，然后想到了 Y 方案，随后把所有的精力放在 Y这个解决方案上，而忽略了对要解决问题本身的理解。这是我们讨论的可能已经不是“需求”，而是偏离了需求的“解决方案”。

总结

需求要求我们在开发前期付出更多的时间和精力，但是一旦时间拉得过长，我们就容易陷入自以为是的境地，很多需求分析和过程就变成了走过场。但我们也知道一点：造成混乱的原因就是丢掉谨慎。

需求过程开始于含混性，但总是要有结束的时候。有时候，需求过程就像是王尔德某次说的：“我整个上午都在推敲我的一首诗，最后去掉了一个逗号。而在下午，我又把逗号放了回去。”

希望你在探索需求的过程中，也能体会到王尔德说这句话时的煎熬和美好。