需求分析+用户体验设计. 业务需求-用户需求-产品需求/解决方案需求

第一部分  需求分析

用户跟福特要一匹更快的马，福特却给了用户一辆车。对这个问题，两套解决方案的区别就是，一个是用户需求，一个是产品需求。而这中间的转化过程，就是需求分析…

1、用户需求vs产品需求

用户跟福特要一匹更快的马，福特却给了用户一辆车。对这个问题，两套解决方案的区别就是，一个是用户需求，一个是产品需求。而这中间的转化过程，就是需求分析…

用户需求：用户希望通过使用某一产品或服务而满足的某些需要。用户自以为的需求，经常表达为用户的解决方案。

产品需求：是某一产品或服务能够满足用户某些需要的集合。

需求分析：从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需求的过程。

看一个猪骨头火锅的例子：

小明要吃猪骨头火锅，80块，碰到了大毛。

“真的想吃？”

“想吃！”

“为什么？”

“我饿了……”（找到了本质！）

“哦，这里是两个馒头（产品需求），请你吃，才1块钱。”

“……”

小明无比不爽，但没办法，真的饿，还是吃了。

大毛是这样分析的，想吃猪骨头火锅，这个用户需求无非两个原因——饿了或者馋了。如果他真的是馋了，那就吃吧，不过如果是饿了，那我完全可以用一个低成本的解决方案——馒头。虽然小明眉头紧锁，但现在经济不景气，毕竟节省了98.75%的成本啊！

伟大的需求分析师，可以无视用户想要的东西，去探究他内心真正的渴望，再给出更好的解决方案，或者说是用户真正需要的东西。

看一个买电钻的例子：

小明说，“我要买一个电钻。”这是用户需求，他自以为的解决方案。

这时候，如果他面对的是一个普通的销售人员，也许就把电钻卖给他了，比方说500元。

但，小明遇到了一位产品经理。产品经理会问——“为什么？”

“我想在墙上打一个洞。”

有的产品经理，就此停住，对小明说，那你不用买电钻，我们这里提供上门打洞服务，50元，一下子省了90%。

到此，产品需求是打洞，功能就是打洞服务。如果你的公司定位就在于此，那么这样也很好。不过，有的公司并不是提供这类产品的，那么会继续问。

“为什么？”

“我挂一幅画在墙上。”

好了，又有一批产品经理找到了产品需求。他跟小明说，我们是个集团公司啊，也提供卖画的服务，并且买画可以包上门安装的！你看，50块也省了，并且挖掘到新的机会——对画的需求。可是，我是一婚介所的产品经理啊，只好硬着头皮继续问。

“为什么？”

“因为房间里显得太空旷了，看着不舒服。”

Ok，原来产品需求是家装服务啊，再How到具体的产品功能，比如加个暖色调的壁灯，铺上地毯……不过，小明皱起了眉头，感觉好像不对啊，家里装潢一下貌似还是有问题，感觉不对。

“为什么？”

“是这样的，我是一IT民工啊，忙得没时间找女朋友，晚上加班回家很晚，对着一块大白墙，感觉很凄凉，没有家的感觉，不够温馨。”

“Bingo，哈哈哈哈，为什么？”

二、需求分析的Y理论---【用户需求->产品需求->产品功能】

“需求分析”的过程就是经历图中的“1 -> 2->3”，把“用户需求”转化为“产品功能”。

“Y”的越上面越是解决方案，越下面越是背后的目的。 1-用户需求，大多表现为用户的解决方案，往往是不好的，但好的“3-产品功能”一定是从用户需求转化而来，而不是凭空想出来的。所以要“听用户的，但不要照着做”。同时，也不要误解“创造需求”，你创造的只能是满足用户需求的解决方案——产品功能，而不是用户需求。 1->2，通过问“Why”，逐步归纳， 2->3，通过问“How”，逐步演绎。过程中都要用到各种辅助信息，比如数据、竞品、行业等。

三、用户需求VS产品功能

先看下面的例子。

我：我要转账，把这张建行卡里的钱转到招行（用户需求，表现为“伪功能”——转账，用户自以为的解决方案）---用户需求和用户解决方案---

MM：转账的话要1%的手续费，最高50元，如果你用网银的话最高25。

我：但是我没有网银，算了，我是把钱全部转出去，只操作这一次，就柜台转吧。（双方陷入对解决方案的讨论）

MM：对了，你是要把钱转到招行账号里吧？（产品经理意识到，应该深挖用户目的，即真实要解决的问题）

我：是啊，要转账（作为一个不懂银行业务的小白用户，分不清转账和转钱的区别）

MM：隔壁就有一个招行，我可以给你开个本票，手续费只要0.8元（产品经理给出优化的解决方案）

我：本票？我从来没听说过，那和转账有啥区别？

MM：对你来说没啥区别，呵呵，只是手续费成本50变0.8，不过，额外增加的成本是要再跑一趟隔壁的招行，反正近嘛。

我自己想了一下，确实，我的真实需求是转钱，甚至还有把现金全部取出来，再到隔壁招行存进去的办法。当然，这样虽然连0.8的手续费都没有，但是增加了风险。

通过这个例子，我们看到，一个“用户需求”，可以用很多种“产品功能”来解决，各有优劣。产品经理的水平高低就在这儿了。

再比如一个产品需求是：我想知道自己的位置。

产品功能：

• 将用户位置显示在地图上  ；通过电话通知用户位置；通过短信通知用户位置； 通过邮件通知用户位置； 等等……

1个产品需求会有N个解决方案。在特定的场景下，提供给用户最好的解决方案，就是一个好的功能。产品功能的实现要考虑技术、成本、工期、风险等因素。

第二部分  用户体验设计

用户体验要素以用户为中心的产品设计(第2版) [(美]Jesse James Garrett

	用户体验五要素图 1. Ui设计层 2. 页面结构+导航+界面 3. 功能呈现的行为+内容     每个功能的信息页面结构+界面字段 +（交互要求） 4. 范围层：落实目标     功能(属性)+内容 5.战略层：关注业务目标-

1. 产品架构图= 产品功能架构图 +（内容） + 产品信息架构图 

产品愿景---目标---功能模块+操作属性+内容----每个功能的页面结构+界面字段+导航

产品结构图囊括了产品的功能与信息，同时也可以在图中示意功能之间的逻辑跳转关系。

产品功能结构图的重点是梳理产品的功能逻辑与功能模块。这个阶段各功能模块及其子功能之间，可能没有体现必然的关联性，这部分有待处理的任务就会交给信息架构图完成，产品经理在构思需求时经常需要绘制功能结构图。

产品信息架构图的重点是梳理页面结构及页面的字段信息。

具体到界面时，页面之间的关联需要清晰的呈现出来，这个阶段也是为绘制原型、信息排版布局打基础。交互设计师在一些项目中输出交互稿之前，需要提前绘制信息架构图。

什么是信息架构图？信息架构的核心是探讨用户对信息的认知过程，对于产品设计而言，信息架构关注的是“呈现给用户合理且有价值的信息”。清晰明确的信息架构图，能够在界面层面清楚的表达产品的功能模块和整体的逻辑路径，有利于产品设计者从宏观角度审视：不同业务模块如何落实到界面结构，以及不同功能模块之间的关联性。

2. 微信的产品架构图

说两个架构图之前，先从软件研发流程说起。如下面两张图所示，无论是软件还是智能硬件研发流程，都有设计和研发两个环节。

信息架构图是交互设计视角，为什么是交互设计视角？

站在用户角度，用户如何使用这个产品（用户体验），以及我们希望用户如何使用这个产品（商业策略）。

高阶产品设计都是在商业和用户体验上去平衡点。没有商业，不赚钱。没有用户体验，用户不会高频使用产品，甚至没有用户用。没有用户用的话，也就没有机会收用户钱。用户视角比较大，比较抽象，方便你理解就具体为交互设计视角（切记，一定要想清楚谁与谁交互：用户与产品交互）这个是产品设计核心之一。

3. 绘制信息架构图需要注意的事项

1）. 按照总分结构确定关键的一级节点

比如我们要绘制一款移动App的信息架构图，那么主体自然是这款应用，其中关键的一级节点是指这款应用最主要的信息模块，关键节点是围绕主体中心点拓展开的。通常一级节点的个数不会太多，例如目前移动App的各个功能是围绕底部导航tab的数量展开的，我们在绘制时可以将底部tab作为一级节点，其余功能及内容囊括在这几个一级节点中。

2）. 先绘制单个一级节点模块的信息架构图，之后再逐个完善

将上图中一级节点“功能模块1”的内容绘制之后，再继续绘制其余的信息模块。

由于页面中某个主功能可能包含多个子功能，顺延至某个子功能也有可能包含多个子子功能，以此类推可能延伸的节点较多。因此我们此处需要注意：

依据我们的需求确定绘制的层级。比如下图中信息模块1绘制到了第4级节点。一般绘制层级达到5级左右，基本涵盖了产品信息架构的主体界面。

3）. 若某个页面在不同的一级节点内出现，建议明确标识

某个页面或功能经常在一个应用内由不同的路径触达，比如电商应用中“商品详情页”就是许多不同路径入口触达的最终落地页面。因此在绘制信息架构图时特别注意以下两点：

• 该功能只需在某个信息模块内展开即可，当其他信息模块也用到时，只填写名称无需再次展开。
• 不同的一级节点信息模块内，使用到相同的页面时，建议明确标识，以便快速辨识。

第三部分  需求分析管理

项目范围是着手进行项目计划的主要入手点。定义项目边界很重要的，这样项目干系人就不会对在项目范围之外的任何内容做出错误的假设。一旦完成了需求讨论会、需求收集、范围定义，项目范围说明书，项目范围应尽量避免变化。但那些被允许变更的项目范围，都应该遵循一个变更控制的流程，以便它们能被记录、评审、然后被批准。批准的变更使得项目范围文档得以更新。

项目范围定义的输出：

1、项目范围说明书（详细）--五部分内容--。

2、项目和范围的目标 ，项目范围目标包括衡量项目成功的可量化标准。项目可能具有多种业务、成本、进度、技术和质量上的目标。

3、产品范围描述，产品范围描述了项目承诺交互的产品、服务或结果的特征。

4、项目边界， 项目边界严格的定义了项目内包括什么和不包括什么。

5、项目的可交付物，可交付物包括项目的产品和附属产出物。

6、产品可接受的标准

7、项目的约束条件

8、项目的假定，项目的假定描述并且列出了特定的与范围相关的假设，和这些假设被证明为假时对项目的潜在影响。

9、初始的项目组织

10、初始被定义的风险

11、进度里程碑

12、量级成本估算

13、项目配置管理需求

14、已批准的请求

项目范围说明有六个组成部分

1. 项目范围描述。项目范围是对可交付成果的描述，是指项目要创建的东西。项目范围定义了需求范围、期待的可交付成果和详细设计文档等等，这些组成了项目可交付成果清单。最终，这些可交付成果是要作为项目团队完成项目范围的结果而被用户接受的。
2. 项目验收准则。项目验收标准清楚地定义了项目必须创建什么、并且满足什么样的功能需求才能被用户接受和认可，才能被认为已经完成。项目验收标准很重要，因为模糊的项目验收标准使得项目持续时间不确定。项目经理和用户必须在项目开始时就项目验收和结束的交付成果达成一致。随着项目开发和测试的循序渐进，项目验收准则需要阶段性地进行review来保证最终可交付成果的顺利验收和被用户认可。
3. 项目可交付成果。项目实施将以完成项目范围的形式创建客户能接受的可交付成果（Deliverable）。包括但不限于：系统/产品、工具、详细设计、产品/系统使用手册、维护说明文档以及其他的辅助的可交付成果。
4. 项目约束。约束（Constraint）是指任何限制项目经理选择的事物。预定的预算、截止期限、资源、供应商和采用的技术等等都是约束的例子。项目管理通常有三个约束：时间、成本和范围。这些有时被称作项目管理的三重约束。项目经理应该识别并记录所有已知的项目约束，才能对项目范围做更好的管理，实现成功的项目交付。
5. 项目假设。作为项目计划的一部分，一些假设（Assumption）必须被提出以便更有效而及时地进行计划。关于硬件软件兼容性、资源可用性、解决方案持久性、干系人对项目的配合和承诺等假设都是常见的假设。如果项目假设被证明是假的话，它们对项目的影响。所有的项目假设都应该在稍后的计划中被评估，以便确定如果假设证明为假时，它们对项目造成的风险，从而项目管理计划应该做相应的更新。
6. 除外责任

 需求收集（考点）：want不等于need
➢ 看题干中：需要实施项目，首先应该收集需求；需求是范围、进度、成本的基础。
➢ 看到题干出现收集需求，需求不合理，首先应该想到需求是否详细记录。
✧ 需求收集(把客户想要的转为需要的)：为了实现目标而确定、记录并管理相关方的需要和需求的过程；
✧ 需求获得途径：让相关放积极参与需求的探索和分解工作(分解成项目和产品需求)，并仔细确定、记录和管理对产品、服务或成果的需求，能直接促进项目成功；
✧ 收集需求五部曲：数据收集-数据分析-数据决策-数据表现-数据建模；
✧ 数据收集包含：头脑风暴、访谈、焦点小组、问卷调查、标杆对照、德尔菲法；（考点：区分这些会议区别）
➢ 头脑风暴：短时间内获得大量创意，创意的产生和创意的分析，不评价、追求数量；
➢ 访谈：通过交谈来了解高层级需求、假设条件、制约因 素、审批标准以及其他信息。；
➢ 焦点小组：召集预定的相关方和主题专家。有主持人引导大家进行讨论，数据收集技术；
➢ 问卷调查：受众广，快速收集信息，非常适用于以下情况：受众多样化，需要快速完成调查，受访者地理位置分散，并且适合开展统计分析；
➢ 标杆对照：将实际产品与其他可比组织的实际进行比较，进行改进意见。主要目的：
理解和收集客户需求的数据，以便集中注意力在满足客户需求上；
➢ 德尔菲法：多位专家反复多伦论证，得出唯一结论（匿名）,达成一致。
✧ 数据决策包含：投票、独裁、多标准决策分析；
➢ 多标准决策分析（名义小组）：通过投票排列最有用的创意，对众多创意进行评估和排序（塑料姐妹花）；

名义小组技术是用于促进头脑风暴的一种技术，通过投票排列最有用的创意，以便进一步开展头脑风暴或优先排序。名义小组技术是一种结构化的头脑风暴形式。

由五个步骤组成：

（1）向集体提出一个问题或难题。每个人在沉思后写出自己的想法。

（2）主持人在活动挂图上记录所有人的想法。

（3）集体讨论各个想法，直到全体成员达成一个明确的共识。

（4）个人私下投票决出各种想法的优先排序。　通常采用 5 分制，1 分最低，5 分最高。 ​

（5）为减少想法数量、集中关注想法，可进行数轮投票；每轮投票后，都将清点选票，得分最高者被选出。

➢ 数据表现包含：亲和图、思维导图、引导；
➢ 引导式研讨会三个特点：跨部门、快速、一致意见/达成一致；
➢ 亲和图：用来对（头脑风暴）大量创意进行分组、分类的技术，以便进一步审查和分析。 （收集需求）；
➢ 思维导图：把从头脑风暴中获得的创意整合成一张图，用以反映创意之间的共性与差异，激发新创意。 （收集需求）。
✧ 数据建模包含：系统交互图、原型图。
✧ 原型法的用法：（创建原型，没有经验），指在实际制造预期产品之前，先造出该产品的模型，并根据此征求对需求的早期反馈；

高层级需求/业务需求， 整个组织的高层级需要：    ■ 解决业务问题或抓住业务机会    ■  实施项目的原因 ✧ 相关方需求     ➢ ​相关方或相关方群体的需要。     ➢ 根据《相关方登记册》，登记不同相关方的期望和需求。 ✧ 解决方案需求， 为满足业务需求和相关方需求，产品、服务或成果必须具备的特性、功能和特征。 解决方案需求又进一步分为功能需求和非功能需求： ■ 功能需求 功能需求描述产品应具备的功能，例如，产品应该执行的     <1> 操作  <2> 流程  <3> 数据  <4> 交互 ■ 非功能需求 非功能需求是对功能需求的补充，是产品正常运行所需的环境条件或质量要。例如， <1> 可靠性  <2> 保密性  <3> 性能  <4> 安全性  <5> 服务水平  <6> 可支持性 <7> 保留或清除 ■ 业务解决方案 相关方的需要。 ■ 技术解决方案 指如何实现相关方需要。 ✧ 过渡和就绪需求 ​ ➢ 这些需求描述了从“当前状态”过渡到“将来状态”所需的临时能力，如 ■ 数据转换 ■ 培训需求 ✧ 项目需求，项目需要满足的行动、过程或其他条件，例如 ■ 里程碑日期 ■ 合同责任 ■ 制约因素 ✧ 质量需求，​​用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准，例如 ■ 测试 ■ 认证 ■ 确认 ✧ 沟通需求 ➢ 需求文件可能包含项目相关方对沟通的需求。​ ✧ 资源需求 ➢ 严格说，资源需求不算在需求文件之内，因为需求文件时在项目规划开始就需要的文件。 ➢ 还没有提及具体资源，在完成活动资源估算后才会形成。 ➢ 我们在之后，单独描述资源需求的内容。到时更新链接。 ■ 资源类型 ■ 资源数量

✧ 需求跟踪矩阵内容：
➢ 从需求到业务需要、机会、目的和目标
➢ 从需求到项目目标
➢ 从需求到项目范围/WBS中的可交付成果
➢ 从需求到产品设计
➢ 从需求到产品开发
➢ 从需求到测试策略和测试脚本
➢ 从高层级需求到详情需求
✧ 1.题干描述产品是否满足客户需求，需要查看需求跟踪矩阵
✧ 2.题干出现可交付成果不满足相关方期望，需要查看需求跟踪矩阵
✧ 3.题干中出现关键词：客户需求、客户期望、需求等。首先需要查看需求跟踪矩阵

✧ 需求跟踪矩阵定义：需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格(需求→生产制造→可交付成果)，可以把每个需求与业务目标或项目目标联系起来，并且此表格提供了整个项目生命周期中跟踪需求的一种方发；
✧ 需求跟踪矩阵的作用：
➢ 查看产品是否满足客户需求、可交付成果是否满足相关方期待等（比较）；
➢ 把需求与业务目标或者项目目标联系起来，有助于确保每个需求都具有商业价值
➢ 确保需求文件被批准的每项需求在项目结束的时候都能交付
➢ 为管理产品范围提供了框架

✧ WBS词典：
➢ WBS词典是在创建WBS过程中产生并用于支持WBS的文件。WBS词典对WBS组成部分(包括工作包和控制账户)进行更详细的描述；
➢ 词典的内容包括：账户编码、工作描述、负责的组织、进度里程碑清单、相关的进度活动、所需的资源、成本估算、质量要求、验收标准、技术参考文献、合同信息等；
✧ 关键词:工作描述、详细描述、评估进度等，如果题干要确定哪份文件描述，找"WBS词典"
✧ 关于工作包、规划包等详细描述都是在WBS词典中