需求可行性分析要回答的是“这条需求能不能做、值不值得做、先做什么”，输出一份可复核的结论，而非对需求内容的复述。本文给出一套可复算的评估方法：六个维度、默认权重、证据要求、加权公式与结论映射规则，并说明结论的适用边界。评估过程中的证据与结论需要随需求条目留痕时，可以借助 ONES 的需求条目与文档协作能力承载。
要点总览（TL;DR）
- 可行性分析要回答技术可实现、资源可支撑、时间可交付、价值可回收四个判断，结论统一为通过、有条件通过、暂缓、否决四种形式。
- 评估固定六个维度：技术可行性、资源与产能、时间与排期、成本投入、风险与依赖、业务价值，权重按需求类型给默认值并由评审会调整、记录理由。
- 每个维度先约定证据类型与取数来源，缺失证据标记为未确认并降权或不计分，不用满分或零分填补。
- 总分=Σ（维度得分×权重），权重之和为1，保留一位小数；计算前先做一票否决检查，缺维度时重新归一化权重，缺失核心维度则标注证据不足。
- 得分只反映当前证据下的判断，需做权重敏感性检查，并在依赖、范围、排期变化或超过一个季度时重新评估。
评估目标：可行性分析要回答哪几个问题
可行性分析的对象是一条已经描述清楚的需求，任务是判断它在当前条件下是否值得进入后续设计与开发。分析结论必须落到明确的判断上，否则容易变成需求说明的二次转述。
一条需求需要回答四个判断：
- 技术可实现：现有技术栈、架构和依赖系统能否支撑，是否存在需要预研的关键点。
- 资源可支撑：所需角色、人力和外部配合方在评估周期内是否可获得。
- 时间可交付：在期望时间窗内能否完成，与既有排期是否冲突。
- 价值可回收：预期业务收益是否有依据，投入与收益的关系是否合理。
结论统一为四种形式，便于横向比较和后续跟踪：
| 结论 | 含义 | 后续动作 |
|---|---|---|
| 通过 | 四个判断均成立，无重大未确认项 | 进入设计与排期 |
| 有条件通过 | 总体成立，但存在需在指定节点前消除的前提 | 附带条件进入，条件未满足则回退 |
| 暂缓 | 当前证据不足或资源、时间不匹配，但需求本身有价值 | 补充证据或等待窗口后重评 |
| 否决 | 触发一票否决项，或价值与投入明显不成立 | 关闭或重新定义需求 |
可行性分析与相邻环节分工不同：需求理解解决“需求说的是什么”，需求建模解决“需求如何结构化表达”，需求评审解决“需求描述是否完整、一致、可测试”。可行性分析在需求基本清楚之后进行，只判断条件是否成立，不重新定义需求内容。若评估中发现需求本身含糊，应先退回澄清，而不是用打分掩盖理解缺口。
指标与范围：六个评估维度及权重设定
维度体系的作用是让不同需求用同一把尺子比较。建议固定六个维度，权重按需求类型给默认值，再由评审会按实际情况调整并记录调整理由。
| 维度 | 评估问题 | 默认权重（新功能类） | 调整规则 |
|---|---|---|---|
| 技术可行性 | 现有架构能否支撑，是否需要预研或改造 | 0.25 | 涉及核心链路改造时上调至0.30 |
| 资源与产能 | 所需角色与人力是否可获得 | 0.20 | 依赖稀缺角色时上调 |
| 时间与排期 | 期望时间窗内能否交付，是否与既有计划冲突 | 0.15 | 有硬性对外时间点时上调至0.20 |
| 成本投入 | 研发、采购、运维等投入是否在可接受范围 | 0.15 | 涉及外部采购时上调 |
| 风险与依赖 | 关键依赖方是否确认，主要风险是否可控 | 0.10 | 跨团队依赖多时上调至0.15 |
| 业务价值 | 收益假设是否有依据，覆盖用户规模是否明确 | 0.15 | 合规整改类需求可下调，价值由合规要求直接给定 |
不同需求类型可使用不同默认权重组。缺陷修复类需求通常提高时间与风险权重、降低业务价值权重；合规整改类需求的价值维度由外部要求直接确定，权重可降至0.05，把差额分配到技术与时间维度。权重调整必须在评估记录中写明理由，同一批次需求尽量使用同一组权重，保证可比。
范围界定同样要写清楚。评估范围应明确本次覆盖的需求边界，例如“仅覆盖订单查询接口改造，不含前端页面改版”；同时列出不覆盖项，例如性能压测、上线后的运营投入。范围不清会导致不同评分者评估的对象不一致，加权结果失去意义。
数据口径与证据：每个维度用什么材料支撑
评分必须有证据支撑，否则分数只是主观印象。每个维度提前约定证据类型、取数来源和缺失时的处理方式，评审时逐项核对。
| 维度 | 证据类型 | 取数来源 | 缺失时处理 |
|---|---|---|---|
| 技术可行性 | 原型验证结果、技术预研结论、依赖系统接口说明 | 技术负责人、架构文档、依赖方接口文档 | 标记“未确认”，该维度最高记3分 |
| 资源与产能 | 人力盘点表、历史同类需求工时、排期冲突记录 | 项目管理系统、历史项目数据 | 标记“未确认”，按保守值打分 |
| 时间与排期 | 里程碑计划、依赖方交付时间确认记录 | 排期表、依赖方书面确认 | 无确认记录时按最晚估计 |
| 成本投入 | 投入估算表（人天、采购、运维） | 估算评审记录、供应商报价 | 缺估算时该维度不计分，总分重新归一化 |
| 风险与依赖 | 风险登记、依赖方确认记录 | 风险清单、跨团队沟通记录 | 未登记风险视为未识别，结论标注证据不足 |
| 业务价值 | 目标用户反馈、业务方确认的收益假设 | 用户访谈记录、业务方书面确认 | 无收益假设时价值维度不计分 |
缺失值处理有一条基本原则：标记为“未确认”并降权或不计分，不用满分或零分填补。按满分填补会高估可行性，按零分填补会误杀有价值的需求，两种做法都会让结论失真。证据本身也要标注时间，超过一定期限的预研结论或人力盘点需要重新确认。
在 ONES 中，需求条目可以关联需求文档、评审记录与相关讨论，评估所需的证据材料和结论可以随需求状态一起留存，便于复核时追溯来源。ONES Assistant 可围绕 PRD 质量检查和需求澄清提炼要点与待澄清问题，帮助在评估前把需求描述补完整；具体可用范围以实际部署与配置为准。
计算与评估步骤：从打分到结论的完整流程
评分采用1–5分制，每个维度先对照锚点描述打分，再按权重加权汇总。锚点描述让不同评分者对同一证据给出接近的分数。
| 分值 | 通用锚点描述 |
|---|---|
| 5 | 证据充分且明确支持，无遗留问题 |
| 4 | 证据支持，存在少量可控问题 |
| 3 | 基本可行，但存在需在实施中解决的明确问题 |
| 2 | 存在较大不确定性，需要额外验证或协调 |
| 1 | 证据表明当前条件下难以成立 |
加权得分公式为：
总分 = Σ（维度得分 × 维度权重），权重之和为1，结果保留一位小数。
计算前先执行一票否决检查。合规红线、安全要求不满足、关键依赖方明确无法配合，任一条件成立即直接给出否决结论，不再进入加权计算。否决项应事先在团队内约定并写入评估模板，避免每次临时讨论。
当某个维度因证据缺失不计分时，把剩余维度的权重按比例重新归一化，使权重之和仍为1，并在结论中注明“某维度未纳入计算”。如果缺失维度超过两个，或缺失的是技术、价值这类核心维度，不再强行计算总分，直接标注“证据不足”，结论按暂缓处理。
总分与结论的映射建议如下，团队可根据自身历史数据校准区间：
| 总分区间 | 结论 |
|---|---|
| 4.0–5.0 | 通过 |
| 3.0–3.9 | 有条件通过，需列明前提条件与消除时间 |
| 2.0–2.9 | 暂缓，补充证据或等待资源窗口后重评 |
| 低于2.0 | 否决 |
区间边界只是判定起点，最终结论要结合证据解释。总分3.5但技术维度仅2分且无预研结论的需求，应给出暂缓而非有条件通过，因为核心技术不确定性没有消除路径。
例子：一条需求走完可行性评估
以下为演示情景，用于说明计算过程，数据为假设值。
需求背景：为客服系统增加工单批量导出功能，期望在下一个迭代内上线，供运营团队每周导出数据做分析。评估范围仅覆盖导出功能本身，不含数据仓库侧改造。
| 维度 | 得分 | 证据来源 |
|---|---|---|
| 技术可行性 | 4 | 已有类似导出接口，技术负责人确认可复用，需增加权限校验 |
| 资源与产能 | 3 | 人力盘点显示下迭代有1名后端可用，前端需协调 |
| 时间与排期 | 3 | 与另一需求存在排期重叠，依赖方交付时间未书面确认 |
| 成本投入 | 4 | 估算约12人天，无外部采购 |
| 风险与依赖 | 3 | 导出数据涉及敏感字段，需安全侧确认脱敏方案 |
| 业务价值 | 4 | 运营团队反馈每周手工整理约4小时，收益假设已书面确认 |
按默认权重计算：4×0.25 + 3×0.20 + 3×0.15 + 4×0.15 + 3×0.10 + 4×0.15 = 1.0 + 0.6 + 0.45 + 0.6 + 0.3 + 0.6 = 3.6分。
一票否决检查：不涉及合规红线，安全方案待确认但存在可行路径，关键依赖方未明确拒绝，不触发否决。
结论为有条件通过，附加条件为：安全侧在开发启动前书面确认脱敏方案；前端资源在排期确认会上落实。两个条件任一未满足，需求回退至暂缓并重新评估。
解读与限制：结论怎么用、哪里会失真
得分反映的是当前证据条件下的判断，不代表需求上线后的成功概率。分数高说明证据支持当前推进，不说明收益一定实现；分数低也可能是证据尚未收集完整。把评估得分直接当作团队绩效或需求质量排名，会诱导评分者调整打分而非补充证据。
权重变化会改变结论，评估完成后应做一次敏感性检查：把权重最高和次高的两个维度各上下调整0.05，观察总分是否跨越结论区间边界。若跨越，说明结论对权重敏感，需要在评审记录中说明权重选择的依据，或补充关键维度的证据。
常见失真来源包括：
- 证据缺失被高分掩盖，尤其是技术维度用“应该能做”代替预研结论。
- 不同评分者对锚点理解不一致，同一证据给出相差两分的评分。
- 只计算研发投入，忽略上线后的运维、培训和持续维护成本。
- 价值假设来自单一业务方口头判断，缺少用户侧反馈支撑。
结论需要设定复核时机：关键依赖方变更、需求范围调整、排期窗口变化、或距上次评估超过一个季度时，应重新评估并保留历史版本。评估记录与需求条目关联存放，便于在需求状态流转时追溯当时的判断依据和附加条件。
常见问题
需求描述本身还不够清楚时，能不能先做可行性分析？
不建议直接打分。可行性分析的对象是一条已经描述清楚的需求，它判断的是条件是否成立，不负责重新定义需求内容。如果评估中发现需求含糊，应先退回澄清，把目标用户、使用场景和预期结果补完整，再进入评估。用打分掩盖理解缺口，会让结论看起来完整，实际依据并不可靠。
某个维度缺少证据，是打低分还是先不算？
按维度分别处理。技术、资源、时间、风险这类维度缺证据时，标记为“未确认”并按保守值打分，该维度最高记3分；成本、业务价值缺估算或收益假设时，该维度不计分，把剩余维度的权重按比例重新归一化。缺失维度超过两个，或缺失的是技术、价值这类核心维度，不再强行算总分，直接标注“证据不足”，结论按暂缓处理。
总分落在区间边界附近，结论怎么定？
区间只是判定起点，最终结论要结合证据解释。例如总分3.5，但技术维度只有2分且没有预研结论，应给出暂缓，因为核心技术不确定性没有消除路径，此时给有条件通过会让附加条件落空。反过来，总分略低于4.0但各维度证据充分、遗留问题都有明确解决路径，可以在评审记录中说明理由后按有条件通过处理，并写清前提条件与消除时间。
不同需求类型用不同权重，横向比较还可信吗？
同一批次、同一类型的需求尽量使用同一组权重，这样分数之间才有可比性。新功能类、缺陷修复类、合规整改类的默认权重组不同，跨类型直接比总分意义有限，更适合比较各自是否达到对应结论区间。权重调整必须写明理由并保留在评估记录中，便于复核时判断结论是否受权重选择影响。
评估结论做出后，什么情况下需要重新评估？
关键依赖方变更、需求范围调整、排期窗口变化，或距上次评估超过一个季度时，应重新评估并保留历史版本。有条件通过的需求，附加条件未在约定节点前满足，应回退至暂缓并重新走一遍评估。评估记录与需求条目关联存放，便于在需求状态流转时追溯当时的判断依据和附加条件。
