大家都在谈如何进行需求分析？都有哪些步骤？而本文主要讲的是关于需求的前世今生，它从哪里来，到哪里去。
一、需求收集
需求分析的前提是已经存在了需求，那么需求都是从哪里来的呢？我们怎么去收集需求呢？
被动告知需求：
主要业务部门，包括市场部、运营部、财务部、管理层等主要业务部门，需求目的是为了上线某一个新业务或者是新活动，这时候产品要做的是了解新业务或者新活动的内容，梳理出业务流程，整理涉及到的逻辑出demo等等；
客服，需求目的是解决某一类用户问题，当存在一类用户频繁咨询或投诉这类问题，客服是会把这类用户问题提交给产品组，产品来评估从业务和产品角度怎么进行优化此类问题；
QA，针对于视觉或者交互的细节QA在测试过程中，会遇到一些细节的小问题（主要是历史遗留），这时候会提交给产品，一般此类需求等级较低；
用户意见反馈，每月收集整理用户提交的意见反馈（吐槽或建议），分析用户吐槽的问题是否具有普遍性还是个例，用户的建议是否能实现，背后想解决什么样的问题；
主动收集需求：
竞品分析，主要是在研究竞品或者同类型产品中，发掘比较好的功能且适用于自己产品（能解决一部分用户的需求或者能为企业带了一定的收入）
用户研究，自己在论坛、贴吧、微博等内容社区，了解社区里那些属于自己产品的目标用户或潜在用户都在吐槽或者期待产品的哪些内容，产品要做的是了解这些问题背后的原因是什么，其次是怎么能解决这些吐槽或者满足用户需求。
数据分析，根据用户的业务数据和行为数据进行分析，挖掘背后可优化的需求点。
二、需求描述
需求是什么？需要进行描述，描述的目的是了解它的前世今生，以后预测未来可能会是什么样？如：需要简化乘地铁流程
现在的样子
现在的乘地铁的流程是：先买票，再凭票进站。买票有两种普遍的方式，一种是地铁储值卡，另外一种是买单程票。现在这两种方式有什么问题呢？地铁储值卡存在着预缴押金且退还押金不便捷，而买单程票的方式一般是在售票机上购买。而售票机仅支持零钱购买且售票机数量较少，热门地铁站时常存在排长队买票。
未来的样子
根据现在乘地铁的现状，可以优化的两个方面就是简化买票流程和乘车流程。那么未来乘地铁可能会是什么样子呢？
地铁储值卡电子化，可在网络上进行购买地铁储值卡，支持押金+余额秒退。简化购买储值卡的流程。
乘车码，可在网络上购买单程票，支持扫码进/出站。简化购买单车票的流程。
人脸识别进/出站，买完车票之后，进/出站不用再进行刷卡或扫码进/出站，只需要识别乘车人面部即可快速进/出站，简化进/出站流程。
......
三、需求全景图
需求全景图即将需求池内所有需求进行筛选排序，明晰各个需求的优先级，确保呈现出来的一副相对完整的需求全景图。
企业-用户获利四象限
影响企业获利的因素
企业收益，简单点理解企业收益可以分成两类，一类是无形的资产，如市场战略、企业品牌、企业口碑等；另外一类则是有形的资产即存在具体货币收入。虽然无形资产最难衡量价值，但是对于企业来说属于长期收益，重要性不言而喻。
企业成本，也可以简单分成两类，一类是开发成本，如需求上线前的开发成本，其中技术实现成本占比最大；另外一类为维护成本，需求上线后的维护所花费的成本，其中运营维护成本占比最大。所以在考虑企业成本方面可具体衡量技术实现和运营维护这两大类成本。
影响用户获利的因素
一般都是通过KANO模型（基本型需求、期望型需求、兴奋型需求、无差异型需求、反向型需求）来分析用户需求进行分类和排序，但是在网上看到将KANO模型进行具象化，即用户对于某一需求评价是怎样的来进行需求分类和排序。按照用户评价结果分类的优点是直观，易于他人对于需求分类及优先级的理解。（出处见知乎better-worse系数值介绍）
注：“你”泛指大多数用户
如何判断需求优先级
可以给企业获利因素和用户获利因素进行赋值，然后进行计算。如：
企业获利因素：企业收益（1-10分），企业成本（1-10分）；
用户获利因素：基本型需求（2-5分）、期望型需求（6-8分）、兴奋型需求（9-10分）、无差异型需求（1分）、反向型需求（0-负1）
需求优先级=（（企业收益-企业成本）/企业成本）*用户获利值。如果要精细化需求优先级，可将原有基础上乘以满足此需求用户占比，即需求优先级=（（企业收益-企业成本）/企业成本）*用户获利值*目标用户占比
四、非功能性需求
非功能性需求基本上包括性能需求、可靠性需求、易用性需求、安全性需求、 运行环境约束、外部接口、可保障性需求等等，其中对于产品来说，比较重要的几点分别是易用性、兼容性、异常处理、可扩展性。
易用性，就拿to C的产品来说，新需求上线可能会更改老用户原有的操作习惯，所以页面上的蒙层指引显得尤为重要，另外是对于客服来说，需要给到相关上线需求的操作文档，以便客服能熟知后就解决用户反馈的问题。
兼容性，若某一需求只针对于APP产品，那么需要考虑到的兼容性可能有两个方面，一方面是平台的兼容性，另外一方面是APP新老版本的兼容性。举例，新版APP将上线扫码购买地铁票的需求，那么在其他平台如PC、H5、小程序等平台的商城中则不能显示地铁票，不然没法进行扫码购买。另外对于老版APP而言，因为之前无扫码功能，则在老版APP商城中也不应该出现地铁票。
异常处理，即出现异常后系统该如何提示，并处理？前期需要确认几点，一、什么情况下会出现异常？二、异常提示样式是怎样的？toast还是dialog等样式？三、异常提示内容是什么？四、多个环节中某一环异常，那整个流程是继续还是停止？
可扩展性，上线时类型只有一种，但是上线后可能会存在多种类型，那么APP页面样式是否能支持自适应？
运行环境约束，最常见的是移动网络和wifi之间是否会进行区分，如网易云音乐，在移动网络打开APP则显示我的音乐，在wif情况下打开APP则显示发现音乐；另外还有摩拜扫码取车，可以使用网络请求也可以使用蓝牙请求，移动网络和蓝牙同时打开时，优先运行哪种环境，这些都需要额外进行说明。
五、需求分解
需求分解可以通过用户故事来进行内容分解，用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：
角色：谁要使用这个功能。
活动：需要完成什么样的功能。
商业价值：为什么需要这个功能，这个功能带来什么样的价值。
还是原来的例子，简化地铁乘地铁流程
故事一：
角色：使用地铁储值卡乘地铁的用户
活动：可在线上进行地铁储值卡的充值以及购买
商业价值：减轻地铁售票员的工作量以及方便用户购买和充值地铁储值卡
故事二：
角色：使用地铁单程票乘地铁的用户
活动：可在线上进行单程票的购买
商业价值：减少地铁售票机投放以及方便用户购买单程票。
故事三：
角色：刷卡进/出站的用户
活动：可在进/出站进行识别人脸，允许已买票的用户进行刷脸进/出站
商业价值：减少用户刷卡进/出站操作以及缓解进/出站拥堵情况
故事四......
将一个需求按照不同场景来描述用户故事，从而将原始需求进行一步步分解，一方面是将需求细化，另一方面是需求拆解成较多可落地的方案。
六、细化用户故事
一个好的用户故事应该遵循INVEST原则：
独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。
可协商性（Negotiable）— 一个用户故事的内容要是可以协商的，用户故事不是合同。
有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。
可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。
短小（Small）— 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。
可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。
细化用户故事的目的满足小步快跑，快速迭代。快速迭代最大的优点是及时的用户反馈，这样可以快速的调整产品的方向和验证产品的合理性，减少风险。也就是说真正的迭代必须把每一个迭代周期的成果交给用户，而且每次的成果都是完整可用的。快速迭代往往会注重当前用户故事实现，最合理的应该是分解已知所有用户故事，进行相关规划后，再针对某一用户故事的快速迭代。确保后续用户故事的上线不存在推翻已有的架构，造成开发资源的浪费。
七、需求表达
在需求表达过程中，包括产品团队内部，公司内部（产品和开发、运营、QA等），公司外部（产品和客户）进行需求的传递，需求的交流和分析，需要将需求准备的表达出来，以便对方可以进行很好的理解。需求表达的方式有很多，excle、word、ppt、视频、demo原型等，目的是通过某一种或多种表达方式，将需求完美、准确的表达呈现给用户，以致于用户能很好地理解需求。
八、测试上线
一般都有专门的QA团队来进行需求测试，而产品测试的目的，主要是有两点，
确认异常问题是否存在，如果你在上线前担心某种异常情况的发生，那么它就更有可能发生（墨菲定律）。所以在上线有必要主动去测试所担心的异常情况，确认它是OK的，做到心中有数。
操作体验，上线前的对于功能的仅仅局限于理解层面，上线前可以通过demo测试，去真实的体验操作，，一方面是确保前期的需求表达内容均已实现，另外一方面是将前期需求未表达到的细节点进行优化处理。
本文由@董小白 授权发布于管理圈，未经许可禁止转载
公众号：小白的产品之路
粤公网安备 44010602010970