需求可行性分析要回答的是一组具体判断：这条需求在业务、技术、成本与资源、合规与风险、进度上分别成立到什么程度。做法是先拆可行性类型，再为每类设定可核验的指标与证据来源，按统一口径打分或给出通过/不通过结论，最后说明结论的依据与限制。本文给出一套可复算的评估方法，适用于需求理解阶段的判断，不涉及需求建模与正式评审流程。
要点总览（TL;DR）
- 需求可行性分析先把笼统的“可行吗”拆成业务、技术、成本与资源、合规与风险、进度五类判断，并写明结论用于立项、排期还是取舍，再决定评估深度。
- 每类可行性配指标时要写清单位、时间窗、分子分母和数据来源；定性判断列出证据类型并标注已验证、有初步证据、仅有假设三个等级。
- 结论按“单项归一化或分级—加权汇总—通过标准与阻断项—异常处理—复核”的流程生成，阻断项单独判定，高分不能掩盖硬性障碍。
- 演示示例中综合得分 76.25 分高于阈值，但安全审批未完成，结论为“有条件可行”，说明评分只反映评估时点的证据判断。
- 权重调整、证据等级偏低和需求范围变化都会影响结论，报告需写明权重依据、置信度和复评触发条件。
评估目标：这次可行性分析要回答什么
“这条需求可行吗”无法直接回答，因为它把五类不同的问题压缩成了一句话。评估开始前，先把问题拆开，并确定结论将用于什么决策，这决定了评估做到多深。
五类可行性各自回答的问题
- 业务可行性：需求服务的用户群体是否真实存在、规模是否值得投入，预期收益按什么口径计算，与现有业务规则是否存在冲突。
- 技术可行性：实现该需求需要依赖哪些系统与接口，关键技术点是否已通过验证，是否存在尚未攻克的技术障碍。
- 成本与资源可行性：需要投入多少人力和时间，是否涉及外部采购，现有团队能否承接。
- 合规与风险可行性：需求是否触碰数据、隐私、安全或行业监管约束，需要哪些审批，失败或延期会带来什么后果。
- 进度可行性：在期望的时间窗内，依赖项能否就绪，关键路径是否留有缓冲。
结论用途决定评估深度
同一需求，用于立项决策时需要五类全部评估并给出量化结论；用于排期确认时，重点在技术依赖与进度；用于多需求取舍时，则需要各需求使用同一套指标，保证横向可比。评估开始前写明结论用途，可以避免评估做完才发现口径不匹配。
评估对象要锁定
明确本次评估的是单条需求，还是一组需求。评估需求集合时，需说明集合的边界和内部依赖关系；评估单条需求时，需说明它所属的父需求或版本背景。对象不清会导致后续指标取值范围漂移。
完成这一步的交付物是一份判断问题清单：每类可行性列出要回答的具体问题，并注明结论用途和评估对象。
指标与范围：每类可行性用什么指标衡量
拆完问题后，为每类可行性配置指标。指标要写明单位、统计时间窗和数据来源，使不同人按同一口径取值能得到相同结果。下表是一份可直接套用的指标框架，具体阈值需结合组织实际设定。
| 可行性类型 | 指标示例 | 单位 | 时间窗 | 数据来源 |
|---|---|---|---|---|
| 业务 | 目标用户覆盖数；预期收益口径与金额；与现有业务规则的冲突数 | 人；元/年；项 | 上线后12个月；评估当期 | 用户调研、运营数据、业务规则文档 |
| 技术 | 依赖系统数量；接口就绪度（已就绪接口数/所需接口总数）；关键技术验证结论 | 个；%；通过/不通过 | 评估当期；验证完成时点 | 架构文档、接口清单、技术验证记录 |
| 成本与资源 | 人力投入（人月）；外部采购金额；交付时间跨度 | 人月；元；周 | 整个交付周期 | 排期计划、采购报价、团队产能数据 |
| 合规与风险 | 约束条件数量；需审批事项数；高风险项数 | 项 | 评估当期至上线 | 合规清单、法务意见、风险评估记录 |
| 进度 | 关键依赖就绪时间与期望上线时间的差值；关键路径缓冲占比 | 天；% | 期望交付窗口 | 依赖方排期、项目计划 |
范围边界要写清
指标表之外，另附一段范围说明：本次评估纳入哪些功能点、哪些依赖系统、哪个时间段的收益测算；不纳入哪些内容，例如后续版本才考虑的扩展能力、由其他团队负责的配套改造。范围说明的作用是防止评估过程中对象悄悄扩大，导致结论无法对应原始需求。
这一步的交付物是可行性指标表，含指标名称、单位、时间窗、数据来源和纳入/不纳入范围。
数据口径与证据：结论靠什么支撑
指标定义清楚后，还要规定每个数值怎么来。可行性结论的可信度，取决于证据本身的质量，因此数据口径与证据等级需要与指标同步确定。
定量指标的口径规则
每个定量指标写明分子、分母、统计周期和缺失值处理方式。例如“接口就绪度”定义为：统计时点已通过联调验证的接口数 ÷ 需求所需接口总数 × 100%，统计周期为评估当周，未开始联调的接口计入分母但不计入分子。分母为零时（如需求不涉及外部接口），该指标标记为“不适用”，不参与汇总，也不按满分处理。
定性判断的证据类型
技术验证结论、业务规则冲突、合规约束这类判断，需要列出支撑证据：技术验证记录（含验证环境与结论）、用户或业务方访谈记录、规则文档条款、法务或安全团队书面意见。仅有口头共识的判断，应标注为假设而非结论。
证据等级划分
| 等级 | 含义 | 对结论的影响 |
|---|---|---|
| 已验证 | 有可复查的记录或数据支撑 | 可作为结论的主要依据 |
| 有初步证据 | 有样本数据或单次验证，尚未覆盖全部场景 | 结论需注明适用范围 |
| 仅有假设 | 依赖推断或口头信息，无书面记录 | 结论置信度低，需列为待验证项 |
数据不可得时怎么办
某项数据暂时拿不到，不要用估计值填充后当作实测值使用。处理方式是：标注“数据缺失”、写明缺失原因和补数计划，并在结论中降低该项的权重或将其列为待确认条件。缺失项较多的需求，结论应表述为“有条件可行”，而非直接判定可行。
这一步的交付物是证据清单，逐项标注来源、采集方式、证据等级与缺失说明。
计算与评估步骤：从指标到可行性结论
指标和证据齐备后，按固定流程汇总。流程的核心是把不同单位的指标转换为可比较的分值，同时保留阻断项的独立判定权，避免高分掩盖硬性障碍。
第一步：单项指标归一化或分级
连续型指标可用线性归一化：得分 =（实际值 − 最差值）÷（最优值 − 最差值）× 100，最优值与最差值由组织根据历史数据设定，不套用外部通用线。离散型指标直接分级，例如接口就绪度 ≥ 90% 记 100 分，60%–90% 记 60 分，低于 60% 记 0 分。分级标准需在评估前确定并写入评估说明。
第二步：加权汇总
综合得分 = Σ（单项得分 × 权重），权重之和为 100%。权重依据结论用途确定：用于立项决策时，业务与技术权重可设高一些；用于排期确认时，进度与依赖权重更高。权重需在评估前公布，评估后调整权重必须重新计算并说明原因。
第三步：通过标准与阻断项
通过标准由两部分组成：综合得分达到预设阈值（例如 70 分），且阻断项全部通过。阻断项是无论总分多高都必须满足的条件，例如合规审批未通过、关键技术验证失败、关键依赖方明确无法在窗口内交付。阻断项不参与加权，单独判定，任一阻断项不通过即结论为“不可行”或“需调整后重评”。
第四步：异常处理规则
- 分母为零：指标标记“不适用”，从加权中剔除，剩余权重按比例重新分配。
- 数据缺失：按缺失项处理，不填估计值；缺失指标超过总数三分之一时，不出具综合得分，只出具分项结论。
- 指标不可比：不同需求使用不同口径时，先统一口径再比较；无法统一的，分需求单独出结论，不做排名。
第五步：结论复核与异议处理
评估结果由需求提出方、技术负责人和评估执行人共同复核。对某项取值有异议时，记录异议内容、双方证据和最终采纳意见；异议未解决前，结论标注“存在未决异议”。复核记录与评估表一并归档，作为后续复评的基线。
这一步的交付物是评估步骤说明，含公式、权重、阈值和异常处理规则。
例子：一条需求如何完成可行性判定
以下为演示情景，数据为虚构，用于说明计算过程。
需求背景与范围
某内部系统提出需求：为订单页面增加批量导出功能，期望在下一个季度版本上线。评估范围包括导出功能本身、与权限系统的对接、以及导出文件的存储方案；不包含后续的数据分析看板。
指标取值与证据
| 指标 | 取值 | 证据来源 | 证据等级 |
|---|---|---|---|
| 目标用户覆盖 | 约 120 名运营人员 | 运营团队名单 | 已验证 |
| 预期收益 | 每月节省人工整理约 40 小时 | 抽样访谈 5 人 | 有初步证据 |
| 接口就绪度 | 所需 4 个接口，已就绪 3 个，75% | 接口清单与联调记录 | 已验证 |
| 关键技术验证 | 大数据量导出性能验证通过 | 测试环境验证记录 | 已验证 |
| 人力投入 | 约 1.5 人月 | 技术负责人估算 | 有初步证据 |
| 合规约束 | 导出数据含用户信息，需安全审批 | 安全团队书面意见 | 已验证 |
| 进度缓冲 | 剩余接口预计 2 周就绪，窗口内缓冲 3 周 | 依赖方排期 | 有初步证据 |
计算过程
按预设分级标准：接口就绪度 75% 落在 60%–90% 区间，记 60 分；其余指标按组织设定的最优/最差值归一化后分别得 90、80、85、80、70 分。权重设为业务 25%、技术 30%、成本 20%、合规 15%、进度 10%。综合得分 = 90×25% + 60×30% + 80×20% + 85×15% + 70×10% = 22.5 + 18 + 16 + 12.75 + 7 = 76.25 分。
结论与限制
综合得分 76.25 分，高于 70 分阈值；阻断项中，安全审批尚未完成，属于未通过状态。因此结论为“有条件可行”：技术、成本、进度均满足条件，需在安全审批通过后方可进入排期。限制说明：预期收益基于 5 人抽样访谈，证据等级为初步，实际收益需在上线后按真实使用数据复核；剩余 1 个接口的就绪时间依赖外部团队，存在延期风险。
解读与限制：结论怎么用、哪里不能外推
可行性评分反映的是评估时点、基于现有证据的判断，它说明“按当前掌握的信息，这条需求值得推进或需要调整”，不保证实施后一定达到预期收益。把评分当作结果保证，是对结论的误用。
权重变化会改变结论
上例中若将技术权重提高到 40%、业务降到 15%，综合得分变为 90×15% + 60×40% + 80×20% + 85×15% + 70×10% = 13.5 + 24 + 16 + 12.75 + 7 = 73.25 分，仍高于阈值但余量明显收窄。权重设置本身是一种判断，评估报告应写明权重及其依据，便于他人复核结论对权重的敏感程度。
证据等级决定置信度
结论中应标注整体证据等级：多数指标为已验证时，结论置信度较高；多项关键指标仅有假设时，结论应表述为初步判断，并列出待验证清单和验证时点。低置信度结论适合用于决定“是否值得继续投入验证”，不适合直接作为立项依据。
复评触发条件
- 需求范围发生实质变化，新增功能点或依赖系统。
- 关键假设被推翻，例如技术验证失败或依赖方排期变更。
- 合规约束或审批结论发生变化。
- 评估时标注为缺失的数据补齐，或证据等级提升。
- 距上次评估超过预设有效期（如一个季度）。
满足任一条件即触发复评，复评沿用原指标表与权重，仅更新取值和证据，保证前后结论可比。
在评估执行层面，需求条目、证据附件、评分记录和评审结论需要放在同一处管理，才能保证复评时有据可查。ONES 可承载需求条目与工作项，将评估证据作为附件关联，评审意见与结论状态随需求流转；ONES Assistant 能理解项目、工作项与 Wiki 页面等工作上下文，围绕需求澄清提炼待确认问题与拆解建议，帮助评估前的信息准备更完整。具体字段配置以实际部署为准。
常见问题
需求可行性分析和需求评审是什么关系，两者会重复吗？
两者关注点不同。可行性分析回答“这条需求在业务、技术、成本、合规和进度上是否成立”，产出的是判断依据和结论；需求评审侧重对需求内容本身的质量检查与确认，例如表述是否清晰、是否完整、是否一致。实际工作中可以先做可行性判断，再进入评审确认，也可以把可行性结论作为评审材料的一部分。本文只覆盖可行性判断这一层，正式的质量检查流程不在本文范围内。
组织里没有历史数据，最优值和最差值怎么定？
没有历史数据时，不要直接套用外部通用线。可行的做法是先由技术、业务和评估执行人共同商定一组初始参照值，并在评估说明中写明这组值来自专家判断而非实测，同时标注为待校准项。评估运行一到两个周期后，用实际结果回看初始值是否合理，再逐步替换为基于历史数据的取值。初始值不确定时，可以同时给出乐观和保守两套取值，观察结论是否稳定。
阻断项和综合得分冲突时，以哪个为准？
以阻断项为准。阻断项是无论总分多高都必须满足的条件，例如合规审批未通过、关键技术验证失败、关键依赖方明确无法在窗口内交付。综合得分用于在阻断项全部通过的前提下比较不同需求的优先级，它不能抵消硬性障碍。出现冲突时，结论应写为“不可行”或“需调整后重评”，并说明是哪一项阻断项未通过、需要什么条件才能解除。
评估做完后需求发生变更，需要全部重算吗？
不需要全部重算，但要判断变更影响哪些指标。范围新增功能点或依赖系统时，相关指标需要重新取值；关键假设被推翻时，对应分项和阻断项要重新判定；只是描述措辞调整且不改变范围与约束时，可以沿用原结论并记录变更说明。复评沿用原指标表和权重，只更新取值和证据，这样前后结论才可比。若变更导致权重本身需要调整，则要重新计算并说明调整原因。
低置信度的可行性结论应该怎么用？
低置信度结论适合用于决定“是否值得继续投入验证”，不适合直接作为立项或大额投入的依据。使用时在结论中标注整体证据等级，列出待验证清单和验证时点，并把仅有假设的关键项列为前置条件。等这些项补齐证据、等级提升后，再按复评流程更新结论。这样既不会因为证据不足而搁置有价值的想法，也能避免把初步判断当成确定结论使用。
