需求分析报告应该包含哪些部分_产品经理学商业分析5.解决方案评价

来源：白猫与黑猫 (ID:Chanpin_sjt) 

作者：白猫与黑猫(授权发布)

在项目产品研发流程中，当产品需求清单被正确跟踪与监督，确保产出的功能和非功能都能映射到具体的商业需要上，且解决方案被项目团队成功开发，并不代表马上可以交付给客户，或直接部署到企业组织的应用环境中，而需要对解决方案是否满足预期，可以满足相关方的程度进行评估，此过程对应为解决方案评价

解决方案评价是商业分析师(Business Analyst，以下简称BA)要关注的工作内容之一，基本包含IT行业的产品经理日常工作中，测试验收、实施部署和效益评估的部分，属于“P-D-C-A”戴明环中的C步骤

  1. 解决方案评价是什么么

定义：解决方案评价，是为确保交付的解决方案能在企业组织中成功实施，并达成既定的项目、商业目标而进行的评价活动，结果会产出其满足相关方商业需求程度，包括定性或定量的评估，比如预估成本和收益与实际成本和收益的比较值

用于对已实施或即将实施的解决方案进行确认，并评估其在多大程度上满足了相关方所表达的商业需求，包括给客户带来的价值，提供了评估一个解决方案是否已达到预期商业结果的能力

2. 为什么要做解决方案评价

评价以便确认已实施 或 即将实施的完整解决方案 或 部分解决方案，决定了其 会在多大程度上满足相关方所表达的商业需求，包括给客户带来的价值

解决方案评价的目的，是评估全套解决方案是否已达到预期的商业效果，是否具备在需要评估阶段，对解决方案预设的能力

(1)评价活动结果是解决方案的定性 或 粗略定量的评估

(2)解决方案的预期结果 和 实际结果之间的比较，通常用定量方式表示

(3)解决方案的非功能特征通常用测量来评价

(4)提供了评估解决方案是否已达到预期的商业结果的能力

(5)发布整个解决方案或其中一部分时，评价提供了通过/不通过商业和技术决策的输入信息

(6)对于适应型项目，评价可以识别盈亏平衡点

 Happy Halloween 

解决方案评价对项目收益的实现有决定性作用，因为只有满足了相关方的商业需求，项目对客户带来价值，才能给企业组织带来收益

3. 什么时候做解决方案评价

评价活动会与多个领域有交集，比如在需要评估阶段，收集确认商业需要的同时，可能要对解决方案有模糊的计划，澄清不可被量化标准的指标；在商业分析规划阶段，就应该包含解决方案的评估计划；在需求分析阶段，根据INVEST原则产出需求清单时，就在潜意识中促使解决方案可被评价；而在需求跟踪阶段，确保需求不偏离“满足商业需要，避免不增值的变更”航线时，也引用了评价思维，只允许对商业需要有价值的需求进行变更，从而避免范围蔓延和镀金的可能

4.  解决方案评价的建议思维

PBA对解决方案的评价，有4点建议：

建议1：尽早并经常评价

越早评价越有可能在真正交付前发现缺陷等问题，经常评价能监控交付物与预测值之间的偏差，及时调整方案，评价标准下来后，可以作为测试策略、计划和用例的输入物，帮助测试团队明确功能和非功能需求的验收标准

对两种典型生命周期的项目而言：

1.预测型项目，评价往往和项目结束相关联(用户验收测试，解决方案发布)

2.适应型项目，评价可能关联到一个时间段的结束(迭代or冲刺)，以及每个用户故事的交付

建议2：将需求分析、跟踪、测试和评价作为互补性活动来对待

1.商业分析规划行动发起人 和 解决方案的开发人员在需求分析阶段协作，以分析商业需求和相关方需求是什么，能满足需要的解决方案需求是什么，开发团队将如何交付解决方案

2.利用需求跟踪矩阵来监督需求始终围绕支持商业目的而加工和被传递，后续的测试用例能覆盖所有功能和非功能需求

3.在分析、跟踪和测试过程中，及时评价解决方案与预测结果之间的差异，并采取相关措施，从而尽早尽快暴露潜在的风险

建议3：牢记借助用途和价值的语境来评价

对解决方案的评价考虑角度，一定要让交付物的用途和价值围绕体现在商业预期的语境中，比如某个解决方案完成后，评价某个功能是否让用户在预设场景下完成一系列操作，从而获得预期结果，分别为用户和企业带来使用价值和商业价值

建议4：确认软件解决方案的预期价值

大白话就是，为避免手工传抄过程造成信息传递偏差和错误，最好利用软件验证和记录操作数据，再通过数据的测试结果发现异常并去分析

 Happy Halloween 

5. 怎么做解决方案评价

PBA指南中介绍的解决方案评价，在逻辑上表述相对混乱，很多过程、步骤阅读起来很困难，以下内容是根据个人理解，对其进行加工后的输出

评价部分包含7个子活动：

5.1 准备评价计划

定义：针对项目团队已交付的解决方案，根据商业分析规划中既定的评价计划，厘清各部分和彼此关联的方式，采用渐进明细方式，分析出信息结构，为接下来的数据建模做输入

通俗地说，包含以下2个步骤：

step1. 读取评价计划。在商业分析规划步骤中，对解决方案的评价部分已有计划，包括要如何评估、开展哪些活动、应用哪些技术，以及如何分析信息

step2. 分析考虑因素。比如会影响哪些商业目标和风险；由谁承担评价 所花费的时间和工作量成本(一般由质量保证部门，如测试组来承接，他们应在方案评估时要积极参与，提供资源估算)；记录在哪里(每个评价数据都应该被手动录入文档资产，或自动记录到规定的跟踪平台，而且要定义好哪些人可以通过读写权限来获取这些信息，确保信息安全)；评价方法是否有效和相对经济；另外尽可能复用企业组织现有的报告生成工具、模板等过程资产，来汇报和公布评价结果

 Happy Halloween 

5.2 确定评价方法

通俗地说，包括以下5个步骤：

step1. 读取所需信息。评价行为有3个信息输入，分别是：

(1)读取商业目的，从中了解要测量的指标，比如

(2)读取关键绩效指标KPI，KPI通常由高层定义，用来跟踪项目和团队在达成目标层面的进展，所以可以对项目和团队进行考核和评价

(3)读取项目指标，作为评价计划的信息输入，比如在敏捷开发模式中的燃尽图，可以反馈整体的项目进度，以及在每个阶段下是平缓推进，还是先东搞西搞，快到deadline才开始奋起直追

step2. 考虑评价指标。包括

(1)客户指标，比如客户满意度，AI机器人对人工坐席替代比例

(2)市场指标，对新增市场而言，可以考虑整体市场份额增长的预期值范围；而存量市场，可以考虑存量客户业务量的百分比增长范围

(3)运营指标，比如预期达到的日活，减少成本比例，提高的转化率等

(4)功能和非功能指标，比如音视频延迟量，最大并发，可用性，可靠性

step3.确定承担成本。既然要读取的信息和要考虑的指标已经就位，此时要评估这些评价活动的成本估算，再同步给项目团队和企业组织，特别是超出预期时，BA要与财务团队、项目发起人、业务架构师等一起确认是否能够和愿意继续这样做

step4.选择评价时间。对预测型生命周期的项目，一般在周期结束时进行，可以在最终版本发布之前，也可以是发布之后约定时间；而对适应型生命周期项目，可以在每次迭代、冲刺、版本发布结尾时验证，也可以是版本正式发布后，再约一个时间来进行

step5.选择验证方法。PBA给的验证方法很多，调查和焦点小组，探索性测试，用户验收测试，集成测试，财务核算等等，这里介绍IT行业用的比较多的2个方法

(1)生活时光工作测试。由具有精深业务知识的测试人员，选定某一天后，连续24h不间断测试，由一组用例场景、多个用户故事、功能需求组成，针对特定数据段 按顺序依次运用，尽量遍历所有时间段。这种测试一般发生在toC国民级应用身上

(2)系统测试。也叫集成测试，方法是将解决方案置于 与生产环境相同or几乎相同的环境中(即UAT)，这样做的好处很明显，尽可能将因版本迭代和升级给用户带来的干扰降至最低程度，这种测试发生在严谨性要求非常高的行业，比如银行、金融、监管、政企等，相比更新速度，系统的稳健型明显重要

 Happy Halloween 

以上通通准备好，开始实操

5.3 评价验收标准和解决缺陷

定义：通过定义的验收标准 与 实际的结果进行比较，对解决方案与实际评价结果进行比较，记录差异、缺陷，对造成缺陷的原因进行分析 并制定解决方案

通俗地说，包括以下3个步骤

step1. 比较预期结果与实际结果。拿着核对表一条一条过就是，不用多解释

step2. 检查公差范围和确切数字。数据差距出来后，通过对比估算成本和工作量及其实际值，分析出现差异的原因

step3. 记录和解决缺陷。不同于普通的bug，基于严谨性考虑，评价过程中发现的缺陷也应该通过额外的需求分析、影响分析和变更请求来解决；如果在此过程中发掘出以前未发现的缺陷，也应该记录并分配解决

 Happy Halloween 

5.4 决策通过与否

完整的解决方案即已出来，验收标准和缺陷清单即已就位，影响范围也已分析，此时应该将评价结果以表格、图表等直观形式呈现给 对解决方案具有批准和签字权限的那些决策人，尽可能通过面对面会议的方式展开讨论，以确定方案是否通过，这样可以让所有相关方知晓决策的理由，提高沟通效率

对解决方案的决策无非就是4种：决定实施解决方案、规划纠正措施 来修补带有部分缺陷的解决方案再实施、推迟实施，以及取消项目，不再实施

5.5  获得解决方案的签字确认

决策过后，让指定的关键相关方签字从而显得流程规范，这个很容易理解；不是所有项目交付物的实施都需签字，PBA也例举了必须签字的场景：

(1)项目具有业务范围or企业组织范围内的影响，牵一发而动全身

(2)产品错误或公差范围内的失败，可能导致死亡或不可接受级别的生命财产赔付能力的风险(基建工程)

(3)严格遵循预测型生命周期的项目，要在项目结束时，予以签字

(4)监管严格的行业，如银行、保险、医疗设备、临床研究、制药

(5)公司文化的有签字确认的规定

 Happy Halloween 

5.6 评价长期绩效

评价长期绩效是评估通过实施解决方案实现的 商业收益的一部分，在解决方案正式发布之前，通过较长一段时间内定期进行内评，识别一系列监测指标绩效的变化趋势，从而预估正式发布后的长期绩效

通俗地说，包括以下5个步骤：

step1. 认清评价指标。确定哪些指标要被长期内评

step2. 测量记录指标。测量并将这些指标在不同时期的表现值记录下来

step3. 分析指标表现。通过趋势，分析这些指标是表现平稳，在预计范围内，还是表现异常；对异常指标部分，通过鱼骨图、5why法、流程分析等根本原因分析法，找根本原因

step4. 反推方案的局限性。表现异常的指标，能帮助确定方案的局限性

step5. 采取建议措施。根据过程中对问题的理解，采取建议措施，用来提高解决方案的完整性和合适性

 Happy Halloween 

5.7 适时对方案进行替换/淘汰

通常来说，任何解决方案都是在指定项目背景下，利用可利用资源开发出的具有一定缺陷的方案，不可能一本万利解决一切问题；同时随着客户场景和企业发展的需要，也可能提出新的商业诉求，所以必定存在对已有解决方案的替换或淘汰措施

对已不适用的解决方案的替换淘汰措施，无非就是4种：

(1)一次性替换，在安装替换方案并淘汰以前方案的所有东西之前，进行大规模的一次性割接

(2)分段式替换，淘汰以前方案的所有东西之前，分段式割接，此时替换方案和淘汰方案会共存

(3)时间盒，在一定时间内共存，之后最终割接

(4)永久并存，但新业务使用替换方案

 Happy Halloween 

当满足了商业需求、相关方需求的解决方案需求，被BA正确转译成产品的功能和非功能需求，提出解决方案，并被项目团队成功开发，在交付前的评价部分，可以指导和验证解决方案是否真的满足最原始的商业需求，而且可以根据测试结果定义过渡需求，包括与相关方进行充分沟通部署实施的时间和其他条件、提供培训资料、完成标准操作流程SOP和工作指导书等

相对需要评估、商业分析规划、需求启发、分析、跟踪与监督领域，IT行业的产品经理在解决方案评价部分参与度偏低，比如测试验收部分，一般由测试部门承接，但合格的产品经理不仅要负责挖掘、启发、分析和跟踪需求，还要能对解决方案交付出去后，能以正确的方案实施，且对投入运营后的长期绩效进行预估，特别是在toB行业，不仅管产品的开发，还要管交付和长期运营，随着客户的业务发展需要，当发现交付的解决方案在某个阶段已经不再适用，就可以重新挖掘需求，更新情境说明书，由此采取行动，推出新的解决方案，从而完成“P-D-C-A”戴明环中，最后的A行动环节，形成生生不息的螺旋上升环，为客户创造使用价值的同时，持续为企业组织带来商业价值，这就是一名实际承担商业分析工作的，优秀的产品经理，所必须具有的职业能力

了解更多商业分析经验，请关注：