本文为《构建之法》需求分析一章的内容整理，加上一些自己工作中遇到问题的理解，如需要了解更多可以看原文
今天分享的主题是”详解需求分析“，主要目的是帮助大家梳理关于这方面的思考框架和部分方法论，那么接下来就进入今天的分享
提出一个问题
首先提出一个问题，当接到一个需求的时候，你第一时间会想到哪些东西？
下面是我自己思考的答案：
- 第一个反应是这个需求是否靠谱
- 其次这个需求我如何执行落地
今天的这篇分享，基本会围绕着这两点进行，需求分析 + 需求落地
什么是需求分析
上图是一个非常经典的软件开发生命周期，瀑布模型，可以看到它分为7个模块，但是根据所属性质不同，大概可以定义为三个阶段：
- 定义阶段 - 开发计划，产品需求，需求分析
- 开发阶段 - 程序设计，编码，测试
- 维护阶段 - 发布，维护
可以看到需求分析是定义阶段 - 开发阶段的一个转折点
需求分析的目的是什么？
我个人理解需求分析是一个转义环节，将产品语言（用户需求，市场分析…）转换成研发可理解，可执行的动作（这里也可以了解下产品经理职位出现的背景）
- 首要目标，是达成共识，共识包含：对prd的共识，对研发排期的共识
- 次要是拆解**为可执行动作或行为**，即拆分需求
通过上述了解了需求分析的目的，下面的分享将开始告诉大家我们如何通过一些方法，确实的达成我们的目的，最先开始的环节就是我们需要了解需求是如何产生的
需求是如何产生的
一般来说需求产出大致离不了下列5项：**
- 软件企业本身业务（业务需求），软件企业 = 软件 + 商业模式
- 软件 -> 发掘 + 实现用户需求 = 实现自身价值
- 商业模式 -> 盈利
- 技术团队本身（技术需求），比如小程序怎么做跨平台
- 趋势预测，比如GPS定位技术，私家车和智能手机的普及，利用手机给汽车做导航将是一个普遍的需求
- 效率管理，比如钉钉，企业微信
- 更好的了解用户需求，比如埋点，ab Test
当我们产出了一个需求，回到我们分享会第一个问题，我需要知道这个需求到底靠不靠谱，下面有一个通用思考框架
竞争性需求分析框架 — NABCD模型
N= need 需求
A = Approach 做法
提出方法，如何解决问题，
不光是技术上解决，商业模式，人脉，成本，
举个栗子：首页feed要挑选优质内容，一定要算法解决么？
B = Benefit 好处
假设你的做法能够解决用户需求，那能够带来的收益是什么？
是增加日活，提高留存？
C = Competitors 竞争
D = Delivery 推广（实际上是启动 + 运营）
你做的非常好，那么怎么让用户使用你的产品/需求？
作为执行方需要关注的点
NABCD模型，其实更多的是关于创造方的一些分析，如果你是作为一个执行方，那么有没有更明确些的分析方法，下面使我根据自身经验总结出的一些东西
关键词
首先我抽出了4个关键词：目标，量化，成本，结论；
四个问题
当接到一个需求，可以想一想下面四个问题：
- 必须明确提出这个需求的目标？
- 如何量化，从哪些角度进行分析？
- 实现的时间和资源成本到底要多少？
- 结论是什么? 验证收益 , 收获认知
接到需求的时候一定要想清楚这4个问题，如果有疑问及时向授予方提出问题，如果授予方都没有想明白，那么我认为是有权利拒绝当前需求，并要求授予方想清楚再进行评审的
举个例子：点赞功能
目标：促活，产生社交行为
量化：基本的pv，uv，圈子的生命周期是否延长（3日留存，7日留存）
成本：3天 1人工时，不需要第三方服务
结论：
- 量化结果，判断是否达成目标
- 收获新的认知（喜欢点赞的人群，什么样的内容容易获得点赞）
- 是否保留功能，是否需要持续迭代
需求评审
需求评审其实就是达成共识的过程，这一步主要分为两个面：
- 跟相关利益方沟通达成共识，通过分析报告，原型，调研结果，样例演示
- 确认后续开发流程，包括：定义优先级，排期，估时，任务拆解
在需求评审中，一定要保持”不懂就问”的原则，把模糊的事情弄清楚是重中之重，只有这样达成的共识才有意义，不然只是纯粹浪费时间，甚至会出现不符合需求定义的情况
软件项目中的角色（相关利益方）
软件工程师必须明白，他们想要从需求中获得什么
- 用户，直接使用软件的人
- 客户，接收软件，为软件买单的人，例如产品，上级，老板
- 运营/Bd/客服，公司内部人员，直接代表用户的”某个方面的需求“
- 监管机构，对我们来说就是微信
- 系统/应用集成方，提供第三方技术服务，咨询，支持的企业，团队或个人，比如微信，阿里云，用的第三方包，工具
- 软件团队，公司内部提供一个特定软件或服务的团队
- 软件工程师，实际的开发者
定义优先级
定义优先级这件事情在执行时，需要明白定优先级的目标是什么，为什么定义它，根据什么定义优先级
优先级排序
根本目标：**在资源有限的情况下收益最大化
分析维度（以小打卡为例）：**
- 核心功能，打卡功能
- 外围功能，主题，话题，猫圈，抽奖
- 必要需求，发布日记，上传多媒体文件
- 辅助需求，地理位置信息，添加话题
可以借助四象限分析图进行分析：
第一象限，代表核心功能，必要需求，优先级最高
第三象限，代表外围功能，辅助需求，优先级最低
第二四象限，优先级在不同的场景下，会互有高低，但一定低于第一象限，大于第三象限
排序：
第一象限 > 第二 || 第四象限 > 第三象限
针对优先级的做事方法
一般在资源有限情况下，面对不同功能有哪些办法
- 维持 - 以最低成本维持此功能
- 抵消 - 快速达到“足够好”，“和竞争对手差不多”
- 优化 - 花大力气做到并保持行业内最好
- 差异化 - 产生同类产品比不了的优势或功能,我有人无，或量上的一个数量级的差距
- 不做 - 砍掉一个功能
如何估时
现状：没有任何办法可以得到一个100%正确的估时
难点：最大的难点在于难以预料前方可能出现的问题，最终估时不准
- 参考前人经验
- 快速原型法，先用一小段时间进行调研，产出demo，从而估计大概的风险，随后进行确切估时
- 合理拆分需求 ，使每个节点相对可控
补充要点：
- 目标，估计（客观估计），决心（主观判断）**，一定要区分明确**
- 敏捷开发的项目中，团队一般不过分强调估时的价值，本质上估时就是猜字，猜的准不是团队的首要目标
- 团队的目标是把软件写出来，让用户和客户满意。如果猜错了，没关系，及时调整项目进度即可，不要为了“猜得准”踌躇不前；不要为了让当初的猜测看起来靠谱而不如实报告进度
课外参考：经验公式
Y ：实际花费的时间， X：估计时间， N：做过类似工作
Y = X ± X ÷ N，
当N = 0 时，即没有做过类似的事情时，有两种情况：
- 3 + (3 ÷ 0)，Y=无穷大，需求难度过高脱离实际解决问题的能力
- 3 - (3 ÷ 0)，Y=无穷大，非但未完成，还会搞出新的bug，拖累许多老员工帮忙解决
当N = 1时， 实际估计的花费范围是【0 .. 2X】之间，随着N增大，取值范围越来越小
拆分需求
拆分需求首先不是拆，而是需要理出到底有多少个需求，产品需求只是你接收到的业务需求，还包含衍生出来其他方面的需求
第一步：明确需求类型
- 产品功能性需求，必须完成的需求，比如实现打卡功能，不能发表日记
- 产品开发过程中的需求，例如产生文档，在某个时间点到达某种状态
- 非功能性的需求（质量需求），例如我feed未分页一次性拉了50条，并且同时渲染，结果就是首屏渲染5s
一定要确定每个关键节点需要交付程序的需求完整性
第二步：拆分子需求
通常从最终的产品开始，一层一层向下，把大目标分割为小型，具体的交付件，类似于树状图
拆分要点：
- 保证所有子节点覆盖了全部的父节点
- 保障各个子节点不要相互覆盖
- 子节点保障足够小，在一个里程碑中完成（到底有多小，需要团队内部达成共识）
- 所有利益相关方**达成共识**
- 从结果出发进行拆分，每个节点描述的是要交付的**产品或文档（关键结果**），而不是开发团队的努力或花费，
这是过程，但是可以以次要形式展现
如何评估需求？
其实本质上就是在看需求的可交付性，个人认为下列三点:
- 完成度
- 质量
- 缺陷数量/影响程度
- 代码质量
- 是否准时
总结
整篇关于需求分析的分享到此结束，需求分析在整个项目开发过程中是最开头的一环，同时也是非常重要的一环，希望各位同学看完之后可以更熟练的把控自身的工作节奏，避免出现一些开发外的事情
若有收获，就点个赞吧
0 人点赞
