本文章的主要目的是帮助大家梳理关于这方面的思考框架和部分方法论。
提出一个问题
首先提出一个问题，当接到一个需求的时候，你第一时间会想到哪些东西？
下面是我自己思考的答案：
- 第一个反应是这个需求是否靠谱
- 其次这个需求我如何执行落地
今天的这篇分享，基本会围绕着这两点进行，需求分析 + 需求落地
什么是需求分析
上图是一个非常经典的软件开发生命周期，瀑布模型，可以看到它分为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 人点赞
