这篇文章是软件工程系列知识总结的第四篇，前面的几篇文章聊了软件工程的基础理论和项目管理相关的知识。这篇文章，我会将软件工程中关于需求分析相关的知识进行总结梳理，并以自己理解的方式进行阐述。
需求分析在分析什么
做技术的同学对于需求应该是既爱又恨，一方面软件产品的源头来自于需求，另一方面日常工作中面对需求的不明确和经常变更，只能无能狂怒。日常的工作流中，需求分析和需求评审的结果往往决定了这个版本交付质量的好坏。
需求的来源有多种，有用户建议、客诉工单，也有通过对市场调研和判断，得出的一些结果需要进行验证。需求分析是一个过程，这个过程主要有如下三个步骤：
- 挖掘真实需求；
- 提出解决方案；
- 筛选验证方案；
举个例子：
用户客诉：有用户反馈某电商APP下单不方便，给了差评；
挖掘需求：用户常用的支付方式是支付宝，但该APP暂不支持；
解决方案：应该支持多种支付渠道，比如支付宝、微信等支付渠道；
筛选验证：调研活跃和潜在用户使用占比较多的支付渠道，按优先级去接入这些支付渠道；
产品需求的来源不是单一的，而是一系列的需求来解决用户的痛点，不断迭代不断改进，从而做出更好的软件产品。完整的需求分析流程应该是一个闭环，整个过程需要迭代进行，如下图：
收集需求需求进行收集整理（头脑风暴、用户调查、竞品分析）；
分析需求：分析用户需求，挖掘真实需求（表层是支付宝支付，深层是多支付渠道，底层是便捷的购物流程）；
需求评估：对需求进行评估，筛选掉不可行需求（成本、可行性、风险和收益、需求的紧急性和重要性优先级）；
需求设计：针对需求提出解决方案，变成产品设计方案（草图、原型图、MVP产品、演示Demo）；
验证需求：验证产品设计方案是否可行（产品验收、灰度发布、A/B测试）；
如何看待产品原型设计
日常工作中大家都会进行需求评审，这个时候最理想的情况是产品掏出原型图和PRD告诉大家，这里要什么那里是怎样。当然，有时候产品也会甩出一句话：“这个需求很简单，怎么实现我不管”。对于这种一句话需求，技术同学特别是研发和测试同学相信都很恼火。
不明确的需求和需求变更，是大家最不待见的情况，这些问题也会导致研发效率大大降低，进一步影响线上交付质量。所以前期需求阶段就确认好要做的事，后期大家的效率和交付质量往往都会比较好，这就有赖于做好产品原型设计。
原型设计简单来说就是将抽象的需求具像化为可视可见可理解的过程。要做好原型设计，不单单是设计页面，而是要综合考虑很多因素。主要的考虑点有如下几项：
- 页面元素布局；
- 功能交互逻辑；
- 用户使用体验；
产品原型设计的过程，可概括为四个部分：
- 需求分析：挖掘真实用户需求，评估原型设计方案；
- 原型设计：划分原型功能模块，梳理界面之间的交互逻辑；
- 流程梳理：画产品使用流程图，即通过流程图将产品不同界面间的交互逻辑梳理清楚；
- 需求评审：大家比较熟悉的需求评审环节，就是集思广益对产品原型和prd进行反馈调整；
技术同学培养产品意识
产品意识本质上是一种思维逻辑，即能否站在用户和产品角度思考并解决问题。主要包含如下几方面：
- 商业意识：即开发的软件产品能否为企业创造商业价值。技术本身是没有直接价值的，技术的价值需要有一个依附物或者说承载品，这个物品就是软件产品能创造的商业价值（我在和一些同学交流时也经常讲到，技术本身不值钱，要依靠产品和业务的变现来体现技术的价值）。
- 用户意识：即你研发的软件产品是否满足了用户的真实需求，解决了用户的底层痛点，产品使用的感受是否良好。简单来说就是——在能用的基础上是否好用。
- 数据意识：软件产品最终要投入市场让用户使用，然后才能发现不足并且不断迭代优化。无论是灰度发布还是A/B测试，都需要收集数据来验证产品。
技术同学要培养产品意识，可以从如下几方面去实践：
- 打破思维边界：技术思维会关注技术实现和细节，产品思维关注用户体验、商业价值和为什么要某个功能；
- 改变原有习惯：日常工作和生活中，站在产品角度思考接触到的物品，背后的价值、用户体验和使用场景等；
- 多实践多复盘：自己做个小产品或一个原型，找同事朋友试用获取反馈，这样输出输入来培养产品思维；
如何应对需求变更问题
需求变更在日常工作中特别常见，频繁的需求变更会带来很多问题，比如：
- 个人工作成就感降低；
- 需要经常加班赶工期；
- 软件产品的交付质量下降；
- 架构臃肿代码质量降低，很快会变成代码“屎山”；
应对需求变更，常见的解决方案有如下几种：
- 提升需求确定性，在需求分析和需求评审环节做好把控，减少源头的不确定性；
- 增强需求管理手段，严格把控变更流程，让需求变更流程更规范，提高变更成本；
- 通过快速迭代缩短版本周期，每版本仅交付部分需求，降低变更成本，快速响应变更；
