3.7. 需求分析¶
产品60%的错误存在于设计中，而设计的错误60%的源于需求和分析活动。–《代码大全》的作者Steve McConnell 11
Fig. 3.7.1 需求分析¶
需求是前期我们通过来源挖掘出来各个需要。这些需求我们需要进行真伪的辨别。真伪辨别如何做解释，举一个很简单的例子：我想在月球上种西瓜。按照现有的条件无法去满足这么一个点，这种想法暂时无法成立的，我们就归结为伪需求。同时需求我们也需要对它们进行一个优先级的排序。如何进行优先级排序呢？通常我认为影响到流程或者与金钱相挂钩或者可以给产品带来大量用户的需求，优先级比较高。我们针对需求怎么去进行管理，通常我们会建立需求池去管理各个阶段的需求，再针对我们进行需求分析后的需求。13
3.7.2. 需求分解¶
业务需求描述组织为什么要执行系统（组织希望获得的业务收益）。
用户需求描述了用户使用产品必须完成的目标或则任务，并且这个产品要能够为人提供价值。用户需求还包括对用户满意度最为关键的产品特性或特征的描述。
功能需求描述产品在特定的条件下所展示出来的行为，主要描述卡法人员需要实现的功能以便用户能够完成自己的任务（用户需求），进而满足业务需求。
Fig. 3.7.3 Decomposition of demand¶
3.7.3. 报告文档 8¶
需求分类：将需求以需要的类型分门别类的罗列好，并介绍清楚需求本意。
需求分析和判断：在这个部分介绍各个需求决策结果，将可行性需求留下，不可行需求放弃；通常这个部分只介绍放弃的需求和放弃的理由。
需求分位：将可行性需求进行分位表述，表明需求的轻重缓急，这个分位的决定因素有很多，需要参考三大因素进行评估；四象限定位法在普遍的公司里也会这样称呼，重要(紧急)、重要(不紧急)、不重要(紧急)、不重要(不紧急)。
需求分级：根据分位再分优化等级，将需求划分计划，根据不同规划阶段分多个版本实现；如果需求很少，那么就一次性迭代实现了。
3.7.3.1. 需求分类 10¶
功能类：通过人与系统交互的方式，来帮助业务同学解决问题，完成任务。例如：订单修改功能、记录备注功能、线索分配功能等。此类需求需要业务同学具有较好的逻辑思维能力，能把需求逻辑或规则梳理描述清楚。
数据类：主要包括两块内容，一个是数据字段定义，即数据统计口径。很多时候出现数据不准确的问题都是因为数据口径不一致导致的。另外一个是筛选条件，当数据较多时，能够有效地对数据进行筛选。
体验类：C端产品，用户体验直接关系到用户转化和用户留存，关乎到产品的成败，至关重要；B端产品，关系到业务同学的工作效率，可以通过优化操作流程或页面呈现来提升用户体验。
性能类：一般是指响应速度、可靠性、安全性等。例如：页面过很久才能打开，响应速度慢；或者有时候能打开，有时间打不开，可靠性较差；或者可以随意修改数据，安全性较低。
BUG类：是指已上线功能未能按照需求逻辑得到预期结果。业务同学在描述BUG的同时，最好能提供CASE方便技术同学排查。BUG可能会带来未知的损失，需要立即被解决，所以这也是优先级最高的需求。
3.7.4. 如何将用户需求转换为产品需求？¶
首先保持二八原则，只有普遍用户的需求，才能内化为产品的需求。比如某个需求就一个用户需要，其他大多数用户都不需要，你就不需要做。
通过现象看本质，收集用户需求以后，多为自己几个为什么，找到用户的动机。
例如：用户在沙漠中需要水，你就要问自己用户为什么需要水？用户有可能口渴了，那这时候你给他水就好，如果用户是因为太热，你能不能给他防晒服，甚至考虑一下用户体验，觉得防晒服太麻烦，提供防晒霜。有时候一个人并不能完全洞察用户的动机，需要团队的其他人员一起头脑风暴，甚至多问提这个需求的原始用户几个为什么，直到找到真正动机为止，然后结合产品本身衡量需求的性价比，最后综合团队实力，需求急切度确定最终产品需求。
3.7.4.1. 需求提取 5¶
“如果我最初问消费者他们想要什么，他们应该是会告诉我，‘要一匹更快的马！’”
——这是亨利·福特的一句经典名言，如今我们在《乔布斯传》里又见到了它。
客户需求有显性需求和隐性需求两大类。我们通过市场调查得知的往往都是一些诸如“我要一匹更快的马”这类显性需求。客户的显性需求并不是客户真正的需求。企业需要根据所收集的显性需求信息进行深度挖掘和捕获，以了解客户的隐性需求是什么，进而分析出客户的真正需求是什么（例如：用更短的时间、更快地到达目的地）。这就是一个需求分析的过程。
3.7.4.2. Y 模型 6¶
Fig. 3.7.4 Y 模型¶
配图中你可以看到一个大写的字母 Y，有三个线段、四个节点。
“节点 1”代表的是用户需求场景，经常被简称为用户需求。这是起点，是表象，是表面的需求，是用户的观点和行为。
“节点 2”是用户需求背后的目标和动机，是用户言行的原因。不过产品经理在思考用户目标时也要综合考虑公司、产品的目标。
“节点 3”是产品功能，是解决方案，是技术人员能看懂的描述。
“节点 4”是人性与价值观，或者说是用户心智，是需求的最深层体现，是需求的本质。
Y 模型的不同阶段，各自需要回答一些问题，可以总结为 6 个 W 和 3 个 H。
“节点 1”这个阶段的问题主要是 Who（目标用户是谁）、What（需求表现为什么）和 Where/When（何时何地，什么情况下）。
“节点 1”到“节点 2”和“节点 2”到“节点 4”这个阶段，对应的是对用户需求的层层深入。这个阶段要回答 Why 这个问题——要不停地往下深入挖掘需求，了解用户为什么会有这样的言行、为什么会有这样的目标和动机。
“节点 4”到“节点 2”再到“节点 3”的过程中，你要想清楚 How——也就是要想清楚问题应该怎么解决。这个叫浅出，先深入后浅出。
“节点 3”中，要回答 Which、How many、How much 三个问题。
Which 是指选哪一个方案，做哪一个功能，这背后其实是对价值的判断，比如怎么评估性价比和优先级。How many 是指这一次做多少个功能，考验的是对迭代周期，产品包大小的把控。How much 原意是多少钱，这里引申为多少资源，是对时间、金钱、团队等资源的评估。
在一个不成熟的领域或全新的市场，只做“节点 1、2、3”是玩得转的。但表层需求很快就会被相似的跟进产品满足，随着市场的成熟，产品很快会陷入同质化竞争和价格战，最终整个市场变成红海。而破局的方法就在“节点 4”（用户心智）。
作为初创团队，你要做的重要事情只有两件，一是和用户交流，二是开发产品。 ———保罗·格雷厄姆
创新会面临两大风险，一是市场风险，就是说你做的产品有没有人需要，二是技术风险，就是说你能不能把东西做出来。
和用户交流，就是 Y 模型的前半段，是解决市场风险，对应的心法就是用心听；而开发产品，就是 Y 模型的后半段，是解决技术风险，对应的心法是不要照着做。
3.7.4.3. 步骤¶
评估价值、梳理流程、规划产品。14
评估价值的手段，通常就是数据分析。结合业务看下这个功能的数据是否有异常，使用率、使用人数、用户群体的价值是否够高，是否是一个普遍的问题。
梳理流程，是为了能够从宏观的角度看看这个问题的本质是什么，如果只从用户的一个动作，而不是他的前因后果来考虑，那就是盲人摸象。
规划产品，指的是方案要有延展性和周期性。要从系统架构的角度上，更加高的高度来看待这个问题，评估哪些系统应该作出优化、哪些系统应该保持不变。
3.7.4.3.1. 评估价值：痛点剖析 7¶
痛点是个体合适普遍？
痛点的需求是否符合政策导向，是否合规？
痛点的需求是否高频应用？
用户是否愿意为痛点买单？愿意付出多大代价？
感受到痛点的用户是不是具有采购决策权？
3.7.4.3.2. 梳理流程¶
？
3.7.4.3.3. 规划产品：优先级安排 1¶
3.7.4.3.3.2. 对「优先级」的定义关系产品成败¶
苹果早期 iPhone 的设计是优先级控制的典范。手机正面只有一个按键的设计，尽管现在看来似乎是理所当然的，但在当时却是非常勇敢和有争议的决定。我曾深入研究过 iOS 系统早期的设计，在很多地方的取舍做的非常到位，能够大胆砍掉之前手机系统常见的功能和界面元素，让重点变得更重点，让需要突出的内容变得更突出。
而相比之下，同一时期诺基亚的系统尽管拥有大量功能，在呈现给用户时并没有处理好优先级，对于用户相对要更复杂，如果读者还有印象，可以想象一下打开一个联系人，看看与之对应的常常的功能菜单。而那个时候微软的 Windows Mobile 系统，则是大量将 PC 上的体验搬到手机上，用户的认知资源和系统有限的显示和交互资源之间并不匹配。
3.7.4.3.3.3. 结构化优先级¶
信息优先级要关注内容的组织关系和轻重缓急
视觉优先级重在引导用户视线和行为轨迹
交互优先级要区分主线和支线任务
需求优先级要平衡用户目标和商业目标
用户优先级要界定核心用户是谁
3.7.4.3.3.4. 信息优先级¶
余额宝：收益、总金额。字号大，想让你看！麦肯兹金字塔。
3.7.4.3.3.5. 视觉优先级¶
报纸上的文字大小、颜色、区块
海报朝着商品上看。
3.7.4.3.3.6. 交互优先级¶
区分主线和支线，突出主线任务
读书app，点一下会设置，再点一下只能前后。读书！
支付宝，收付钱。
滴滴，预约用车、现在用车。感觉车很多。
建立故事，记忆更深刻。
豌豆荚几亿钱分十几个人！
3.7.4.3.4. 项目范围优先级制定一沟通计划¶
By who、Who、How、Why、When、What。
制定沟通计划的目的是为项目交付周期的交流和相互支持提供指导。在敏捷项目里,面对面交流比文档要好,但是依然会有一些共享文件,比如报告和项目计划,需要留下档案。
3.7.5. 需求分析失败¶
不完整的需求：主要是因为我们撰写的“需求规格说明书”这类文档里面，里面充斥了很多技术术语如：数据字典管理、报表子系统、API接口、写死、耦合、黑白名单、新增客户之类。有时候会让一些技术功底并不深厚的用户很难理解这些技术文档。所以我们建议：要让用户能够更好地参与到完整的需求分析过程，我们需要采用一个“业务导向”的组织结构，而不是让用户将一大堆技术动作翻译成自己的业务场景中。最好是利用树形层次介机构，将宏观信息与微观信息进行有效的剥离。
缺乏用户的参与：在很多产品开发项目过程中，经常会出现缺乏用户参与的问题。出现这样情况主要可能是：需求人员自以为共同清楚用户需求，但不将自己的撰写好的需求文档进行二次确认。不会根据开发进度与客户保持同步沟通确认。当然客户也经常说这样的话：“你们先做，做出来后我们用用，有问题再改吧”。类似还有客户还有认为确认是事不关己、自己利益无关、不感兴趣的事。这时候对于需求分析员而言，真正能够让用户主观能动地参与进来，是要基于业务利益（解决问题、创造机会、提高管控力、推进项目进度等）的沟通
不切实际的用户期望：很多时候，用户总是天真地提出了大量的需求，有些是技术上根本无法实现的，有些是在原本较少费用和时间预算下无法实现的。所以在软件的无形和成本的不透明的情况下，导致我们认为客户在不切实际的需求。作为需求分析人员为了让我们客户提出一些实际可行的需求，应该主动帮助客户更好理解软件产品的成本。也就是说，单单告诉客户我们做不到是无效的，而应该说明为什么做不到才能够解决问题。
需求变更频繁：这就是我们经常碰到客户反悔的情况。客户常常会说：我不就是才提了两个需求，怎么就被你们说成变更很大、变更频繁做不了呢？也就是说用户根本没有意识到你变更对于软件项目工程会带来怎样的负面影响。目前大多数企业的需求分析过程，没有一个需求评审的过程，应该找到所有关键人员一起讨论一些需求到底该不该变、能不能变、能变多少。也有权决绝不合理的需求变更的要求。同时需求变更类型做一个统计，从根源上找出问题，改进整个需求过程
提供了不再需要的：也就是最后做出产品，发现功能不是用户能用上，好似一个鸡肋的伪功能。这真是一个浪费开发资源和时间的错举呀。那么针对这种情况，我们主要是做到事先预防，应该有效地划分需求优先级，真正基于业务领域知识来衡量需求的必要性和充分性。9