这是猫猫的第28篇原创文
在项目产品研发流程中，当已经从相关方和应用场景中获取需求明细，且获得目标用户和关键相关方的认可，并不代表下一步可以交付设计和研发部门开工，而需要对原始需求进行加工整理，转化为项目团队能看懂和熟悉的文件，此过程对应为需求分析
如前文所述，需求分析是商业分析师（BusinessAnalyst，以下简称BA）的核心工作内容之一，基本可以对应产品经理日常工作中，目标用户群体需求分析加工整理的工作，即将用户需求转化为产品需求的环节，属于“P-D-C-A”戴明环中的D步骤
和需求启发一样，需求分析同样是最能体验BA技术含量的工作组成之一，建议采用“分析-建模-确认-分析-...”多次细化和确认需求，经相关方的核实和批准后，推出最终的需求分析结果：
1.首先，分析在启发过程中获得的相关方需求，理清各部分和彼此的关联方式
2.然后，对需求进行建模，产出模型化的信息结构与模型
3.接着，与项目发起人、需求提供者、系统架构师、研发经理等确认模型是否真实有效反映了业务诉求和商业需要，并对其中不合理、不充分、有遗漏的结构进行调整，如此反复，确保需求分析的结果，能直接被项目团队承接过去进行设计和开发
4.最后，有条件的话可以找BA同行进行文件规范的审核，并得到高级相关方的书面批准
1.需求分析是什么
定义：需求分析是基于需求启发得来的信息，进行的结构化分析、数据建模、确认核实工作，反映真正的相关方需求和解决方案需求，从而确定接下来的项目中要设计、开发、测试的具体工作
从项目发起人、目标用户和客户处收集得来的启发信息，并不能被后续的项目团队直接应用，BA要与系统架构师理清信息的结构关系，并进行对应建模，产出模型化的图纸、表格、结构等，从而输入项目团队去产出设计稿、交互稿、测试用例等
2.为什么要做需求分析
与需求启发一样，在任何行业的任何项目活动中，需求分析的地位相当重要且不容置疑，如果不经过需求分析，直接将启发得来的客户or用户需求作为项目团队的资料输入，项目团队的阅读理解成本很高，很明显是不科学的工作方法
e.g.在外卖行业，用户需求是要方便快捷获得工作餐送货上门的服务，在经过需求启发后明确项目目标是做一个支持在手机上点单和派送的APP，此时直接丢给项目团队一定是一脸懵逼的。BA要确定订单、用户身份、商家管理等系统内部的信息流转逻辑；假设用户画像，整理出应用登录、选择店家、浏览菜品、购物支付等用户故事；根据运营需要规划满减活动、banner位定价等商业规则；出页面跳转逻辑交互等等，只有把这些信息传递给项目团队，促使他们产出后续文件和推动项目工作，才是正常和合理的工作模式
3.什么时候做需求分析
需求分析一般在项目问题、商业需求和目标即已明确、面向相关方的需求启发和收集工作已经完毕的前提下进行，所以通常聚焦于相关方需求，通过分析、建模产出解决方案需求，提供给项目团队进行设计和开发
4.怎么做需求分析
PBA中介绍的需求分析子活动，在逻辑上不是很清晰，按照需求分析的实际操作安排，包含以下3个子活动：
4.1准备需求分析计划
定义：针对启发得来的信息，根据商业分析规划中既定的需求分析计划，厘清各部分和彼此关联的方式，采用渐进明细方式，分析出信息结构，为接下来的数据建模做输入
通俗地说，包括以下2个步骤：
step1.读取需求分析计划。在商业分析规划步骤中，对需求分析已有计划，分析和记录从相关方处获得的哪些信息、选用什么数据模型建模、与谁一起确定建模的效果、将和谁一起评审文档规范、需求分析的结果需要由谁给予批准
step2.对信息进行清洗后建模。由于从相关方启发得来的信息往往零散和无序，而且对方会以自己的立场表述诉求、期望功能、场景故事、业务阻塞问题等，BA需要剥离可能造成干扰的无效信息，再进行数据建模
4.2模型化与优化需求
定义：将需求信息进行可视化处理，构建图、表、结构化的信息树和文本结构，在信息中心发现差距和识别信息，提供环境让信息更清晰地传递
按照PBA的定义，模型分为5大类共21种，分别是
1.范围模型：用于结构化和组织其特征、功能和正在分析的商业域边界的模型（确定项目范围），包括目的和商业目标模型、生态系统图、系统交互图、功能模型、用例图共5种
2.过程模型：描述干系人参与过的业务过程及方法的模型（确定操作路径、业务流程），包括过程流、用例、用户故事共3种
3.规则模型：定义或约束业务各方面，以加强建立商业*策的概念和行为的模型（确定业务规则和相关细节），包括商业规则目录、决策树、决策表共3种
4.数据模型：用于记录过程或系统及其生命周期的数据的模型（确定数据相关要求），包括实体关系图、数据流图、数据字典、状态表、状态图共5种
5.接口模型：辅助理解特定系统及它们在解决方案中的关系的模型（确定成果与相关系统之间的接口定义），包括报告表、系统接口图、用户界面流、线框图、显示-操作-响应共5种
模型的选择需要考虑项目生命周期特征、抽象程度，而且在每个大类中至少要有一个。对大多数项目而言，模型化和优化需求不会一次性做完，BA通常要与系统架构师多次反复确认分析模型化的结果
e.g.以说客英语的Talk和直播工具eclass为例，在梳理完典型用户的需求后，决定分别在5大领域中采用以下建模
1.范围：由于Talk要对接自研教育直播工具eclass、远在菲律宾的教学基地、营销平台和教学管理系统，所以采用生态系统图的方式建模，方便展示跨系统的数据交互，定义系统高层级的相关接口，以及与系统交互的人机界面系统
2.过程：面对有一定自研能力的客户，eclass以SDK形式嵌入对方的客户端，用户（老师、学生、助教）从进入客户端开始，到进入教室，上课交互，直到课程结束回到客户端，整个流程相对清晰，直接用过程流进行建模
3.规则：以一对多教学课堂为例，为保障上课质量，去除干扰，需要对发言进行管控，相应规则如下
4.数据：为说明系统、用户和数据之间的关系，产品需要采用数据流图进行建模，识别过程中的数据输入和输出
5.接口：以答题器的策划为例，对用户界面流，采用互联网行业最常用的快速原型设计工具——axure进行原型建模
在IT行业，这个步骤可以理解为将产品需求加工成解决方案需求，即功能需求和非功能需求，前者是产品能满足商业需要所必备的功能和特征，如登录、购物车、支持线上支付、即时通讯，后者是其所拥有的的质量和属性，比如可靠性、处理效率、最大负荷、安全性、兼容性、可靠性等等
对IT产品经理来说，最熟悉的应该是敏捷开发模式下的用户故事，而用户故事在编辑时应该遵循INVEST原则，分别是：
Independent独立性：尽量让每个用户故事彼此间相互独立，否则可能对计划的制定、优先级划分、工作量预估造成干扰
Negotiable可协商：用户故事并不等于不可修改章程，部分细节是可以被协商的
Valuable有价值：每个用户故事必须给客户或企业带来具体的价值，要么描述了详细的项目问题发生场景，要么描述用户通过操作可以给企业带来什么商业上的经济or非经济价值
Estimable可估算：开发团队拿到用户故事后可以以此评估具体的工作量，从而由项目经理安排排期
Small短小：用户故事一般是一个简短概述，太过于细节没有必要，且颗粒度一定要小，在一个迭代或冲刺中足以完成
Testable可测试：每个用户故事必须有验收标准，可以映射到具体的测试用例中
4.3整合需求分析结果
定义：对需求分析结果进行记录、确认、核实以及批准的过程
4个步骤分别如下：
step1.记录需求。通常以表格形式，或者线上协作平台（trello、tapd、飞书...），来记录需求；通常每个企业组织有对应的需求记录规范（触发条件、错误条件、假设条件、制约条件、反应、结果等），并通过在商业分析规划活动中定义的需求优先级排序规则，标注需求的优先级；还有一部分有价值但本次不会执行的未完项清单
step2.确认需求。目的是保证项目的产出物确实满足了商业需要，能正确反映相关方的需要、意图和期望。如果有条件，最好采用原型法向相关方演示，能获取即时反馈
step3.核实需求。目的是确保需求本身满足质量和组织标准，一般在确认需求后在进行核实，确保只对有意义的正确需求进行核实，以节省资源
指南建议让BA同行参与评审，检查即已建模的需求文件、跟踪和监督计划、验收标准等商业分析成果，是否表达准确、完整，满足企业组织的标准，以及通用的编写规则，一般在评审过程中直接修改文档
step4.批准需求。解决方案得到认可后，BA应该获得业务负责人、承接解决方案需求团队的接收人的签字确认
商业负责人认同需求文件完整、准确地对项目问题or商业机会进行了正确的描述；研发团队确认需求文件为接下来即将实施的解决方案提供了足够多和详细的信息；BA负责准备交付物
对整个需求分析来说，最终的交付物是批准的相关方需求和解决方案需求，构成在项目生命周期中，设计和研发工作的基础
ps：IT行业常用的需求优先级考虑原则有MoSCoW、kano模型、多重投票、时间盒法、加权排序
MoSCoW是将所有需求区分为“必须有、最好有、可以有、本次不会有”4种
e.g.猿题库某次迭代的典型需求划分如下
kano模型是将所有需求区分为“基本型、期望型、兴奋型、反向型、无差异”5种
e.g.珍爱网的典型需求划分如下
多重投票是根据与会者的影响力、经验水平等，分发一定数量的选票（比如A有两张票，B有一张票，C有半张票），投票汇总后，根据每个需求所获总数进行排序
时间盒是在确定项目范围和进度要求的前提下，从工作量方面卡死总的工作量，再将需求一个个放进时间盒中，直到塞满为止
加权排序则是事先规定考虑需求优先级的若干个维度，并赋予一定的权重，对每个需求的加权总分进行排序（商业价值，实现难度，紧迫性...）
e.g.百果园的某次迭代计划中有送货上门、营养搭配推荐、生鲜团购3个需求，在排优先级时要考虑如下4个方面的影响因素，方便用加权排序来处理
对IT行业实际充当BA角色的产品经理们来说，需求分析和加工能力是岗位技能的基本功，日常工作无外乎围绕产品需求来做，与客户、与老板、与设计、与开发、与测试、与运营斗智斗勇，如果拥有出色的建模能力，可以清晰明白地将用户需求转化为产品需求，再表达为产品的功能和非功能需求，让团队这艘航班沿着既定方向航行，最终交付的成果可以达到商业目标，解决实际问题，为企业带来收益，此时老板看你的眼光越发带着一丝欣赏的味道，升职加薪自然就不远咯
PS：附上需求分析的方法过程，需要清晰版的童鞋，在后台回复xqfx，获取链接咯
注：本文为学习心得，图片来自百度图库，欢迎转载，猫猫会持续为大家带来高品质原创文，感谢大家的