需求可行性分析要回答的是“这件事值不值得做、能不能做成、需要什么条件才能做”。支撑结论的依据通常集中在六类：业务价值、技术实现、资源与成本、时间与依赖、合规与风险、组织与运营。本文给出一份可逐项取证的依据清单，并说明从固定需求边界、分配取证责任到形成结论、完成交付检查的操作步骤，帮助分析结论经得起评审追问。
要点总览（TL;DR）
- 可行性分析前先固定需求边界与假设，形成登记表，让每条依据都能对应到具体条目。
- 依据集中在六类：业务价值、技术实现、资源与成本、时间与依赖、合规与风险、组织与运营，每类都要有来源、责任人和结论。
- 按五步推进：确认边界、分配取证责任、收集证据并标注可信度、验证关键不确定项、汇总结论与待办。
- 取证与下结论分开：提出方、技术、财务法务等提供依据，产品人员汇总，决策者确认。
- 交付评审前逐项检查依据完整性、假设状态、结论分类和待办时限，条件与结论写在同一处。
可行性分析先要固定哪些需求边界与假设
可行性分析最常见的失效方式，是分析对象本身还在变化：范围一会儿扩大、目标用户一会儿调整，取证工作就会反复返工。开始收集依据前，先把需求固定成一份可引用的登记表，后续每条依据都能对应到表中的条目。
登记表至少包含五类信息：需求要解决的问题与目标用户、功能范围、非功能约束、已知业务规则与外部依赖、待验证假设。其中“待验证假设”要单独登记，写明假设内容、影响哪类可行性判断、计划用什么方式验证、由谁验证。假设一旦被验证或推翻，登记表同步更新，避免结论建立在过期假设上。
| 登记项 | 填写内容 | 示例 |
|---|---|---|
| 目标与用户 | 要解决的问题、受益角色 | 缩短客服工单首次响应时间，受益角色为一線客服与值班主管 |
| 功能范围 | 本期做什么、明确不做什么 | 本期只做工单自动分派，不做知识库推荐 |
| 非功能约束 | 性能、安全、可用性等硬性要求 | 分派结果需在3秒内返回；操作留痕可审计 |
| 已知规则与依赖 | 业务规则、上下游系统、不可变条件 | 分派规则由业务方维护；依赖现有工单系统接口 |
| 待验证假设 | 假设内容、影响、验证方式、责任人 | 假设现有接口可支撑实时调用，需技术预研确认 |
这张表的作用是给后续取证划定边界：范围外的依据不收集，范围外的结论不写入。登记表确认后，再进入依据清单的填写。
六类可行性依据及取证方法
六类依据分别回答不同问题，缺一类，结论就会留下盲区。每类依据都要落到“来源、责任人、取证状态、结论”四个字段，来源要能指向具体文档、数据、访谈记录或验证结果，避免只写“已确认”。
| 依据类别 | 回答的问题 | 取证来源与动作 | 判断标准 |
|---|---|---|---|
| 业务价值 | 做了有什么收益 | 调取业务指标基线、用户访谈记录、历史工单或交易数据 | 目标指标有基线值，收益测算口径可复算 |
| 技术实现 | 现有条件下能否实现 | 梳理现有架构与接口清单，必要时做技术预研或原型验证 | 关键路径有验证结论，技术约束已写明 |
| 资源与成本 | 需要投入多少 | 人力估算、预算科目、采购报价、上线后运维投入测算 | 投入项有估算依据，口径与财务或采购一致 |
| 时间与依赖 | 何时能交付、卡在谁那里 | 里程碑倒排、上下游系统排期确认、外部供应商交付承诺 | 关键依赖有对方确认的时间点 |
| 合规与风险 | 有没有不能碰的线 | 法规与行业规范核对、数据安全与隐私评估、合同条款审阅 | 风险项有等级判断和应对措施 |
| 组织与运营 | 上线后谁来用、谁来维护 | 角色分工确认、培训计划、运营与支持方案 | 运营责任人和支持流程已明确 |
取证时有两个细节值得注意。其一，业务价值依据要区分“用户说想要”和“数据表明有需求”，前者是访谈记录，后者是数据证据，两者在结论中的权重不同。其二，技术实现依据中，凡是没有经过验证的判断，都标注为“待验证”，并附上验证计划，避免把技术负责人的经验判断直接写成确定结论。
六类依据收集完成后，可以按“支撑结论、存在条件、构成风险”三种状态归类。支撑结论的依据进入结论正文；存在条件的依据写成“有条件可行”的前提；构成风险的依据进入风险清单并指定应对责任人。
按步骤完成一次可行性分析
把依据清单变成一次可执行的分析，需要按顺序推进五个步骤。每一步都有明确的输入、动作、输出和完成标志，避免分析停留在零散讨论。
第一步：确认需求边界与假设
输入是需求提出方的原始描述，动作是与提出方逐项确认目标、范围、约束和假设，输出是需求边界与假设登记表。完成标志是提出方与产品/需求分析人员对登记表内容达成一致，待验证假设全部登记在册。
第二步：分配取证责任人与截止时间
输入是登记表和六类依据清单，动作是逐类指定取证责任人和截止时间，输出是带责任人和时限的依据清单。完成标志是每类依据都有明确的责任人，没有“大家一起找”的模糊项。
第三步：收集证据并标注来源与可信度
输入是分配后的依据清单，动作是按类别收集文档、数据、访谈记录和验证结果，输出是填写完整的依据清单。完成标志是每条依据都能指向具体来源，并标注可信度：已验证、有间接证据、仅有经验判断。
第四步：对关键不确定项做验证
输入是第三步中可信度不足的关键项，动作是按假设登记表中的验证方式执行，例如做原型验证接口调用、用历史数据测算收益、做技术预研确认性能上限，输出是验证记录和更新后的结论。完成标志是关键不确定项要么得到验证结论，要么明确标注为待验证并附验证计划。
第五步：汇总形成可行性结论与待办事项
输入是全部依据与验证记录，动作是按“可行、有条件可行、不可行”三类归纳结论，输出是可行性分析过程记录与结论草案。完成标志是结论中每条判断都能追溯到依据条目，待办事项都有负责人和时限。
在取证和结论汇总环节，需求条目、依据记录和结论草案往往分散在多个文档与沟通记录中。ONES 可以把需求作为工作项管理，将依据清单、验证记录和结论文档与需求条目关联，让每条依据的来源和状态在评审时可以直接追溯，减少会前临时拼凑材料的情况。
角色分工与各环节交付物
可行性分析要避免变成产品人员一个人的书面作业。取证、判断、确认三类动作由不同角色承担，各自交付可核对的产物。
| 角色 | 负责的依据 | 交付物 | 确认时点 |
|---|---|---|---|
| 需求提出方 | 业务价值、业务规则与场景 | 目标指标基线、用户访谈记录、业务规则说明 | 分析启动时提供，结论形成前确认 |
| 产品/需求分析人员 | 组织全部取证、维护依据清单 | 需求边界与假设登记表、依据清单、结论草案 | 各步骤节点更新，评审前定稿 |
| 技术负责人 | 技术实现、技术约束与预研结论 | 架构与接口说明、预研或原型验证记录 | 技术验证完成后 |
| 财务/采购/法务等支持角色 | 成本、合同、合规与数据安全 | 成本估算、合同条款意见、合规评估结论 | 依据收集阶段，结论汇总前 |
| 决策者 | 确认可行性结论与后续动作 | 结论确认意见、后续动作安排 | 结论草案提交后 |
分工的关键是让“提供依据的人”和“下结论的人”分开：技术负责人给出技术判断，产品人员汇总整体结论，决策者确认是否推进。这样结论中的每个判断都有对应责任人，评审时可以直接找到依据出处。
示例：一个需求如何完成依据取证
以下为演示情景，用于说明依据清单的填写方式，不对应具体企业数据。
需求背景：客服团队希望实现工单自动分派，减少人工派单耗时。边界确定为：本期只做按技能组和工单类型的自动分派，不做智能推荐；非功能约束为分派结果3秒内返回、操作可审计；已知依赖是现有工单系统的分派接口。
| 依据类别 | 取证内容与来源 | 结论 |
|---|---|---|
| 业务价值 | 近三个月人工派单平均耗时数据；客服主管访谈记录 | 派单耗时占首次响应时间比例较高，目标指标有基线，支撑推进 |
| 技术实现 | 现有工单系统接口文档；技术预研验证接口响应时间 | 接口可支撑实时调用，需增加失败重试机制 |
| 资源与成本 | 研发人力估算、测试资源安排、上线后运维投入测算 | 投入在预算范围内，运维需增加监控配置 |
| 时间与依赖 | 里程碑倒排；工单系统团队排期确认 | 依赖对方接口变更窗口，时间存在条件 |
| 合规与风险 | 操作留痕与数据访问范围核对 | 需保留分派日志，风险等级低，措施明确 |
| 组织与运营 | 客服主管确认技能组维护责任；培训计划草案 | 运营责任明确，培训需在上线前完成 |
关键不确定项是接口在高并发下的稳定性，验证方式为技术预研加压力测试，验证结论为“需增加重试与降级策略”。据此形成的结论写法是：该需求有条件可行，前提是完成接口重试机制开发、确认工单系统团队接口变更窗口、上线前完成技能组维护培训；待验证事项为高峰期并发下的分派成功率，由技术负责人在开发阶段补充压测数据。
完成检查：可行性结论是否可以交付评审
结论草案提交评审前，用以下检查项逐条核对。任何一项不通过，都应先补充取证或明确标注，再进入评审。
- 六类依据是否均有来源和责任人，没有空白类别或“待补充”占位。
- 关键假设是否已验证，或明确标注为待验证并附验证方式和时限。
- 结论是否区分可行、有条件可行、不可行，条件与结论写在同一处。
- 待办事项是否有负责人和完成时限，能否在评审后直接执行。
- 每条依据是否能追溯到需求登记表中的具体条目，范围外内容是否已剔除。
- 风险项是否有等级判断和应对措施，合规结论是否有对应角色确认。
检查通过后，可行性结论草案、依据清单和验证记录构成一套可交付评审的材料。评审中若出现新的假设或条件变化，回到登记表更新，再同步调整结论，保持依据与结论始终对应。
常见问题
需求可行性分析中，业务价值依据只有用户访谈记录够不够？
访谈记录能说明用户表达了需求，属于间接证据。要让业务价值结论站得住，通常还需要目标指标的基线值和可复算的收益测算口径，例如历史工单、交易数据或响应时长统计。两类证据在结论中的权重不同：数据证据支撑结论，访谈记录用于解释场景和补充判断。若暂时拿不到数据，可以在依据清单中标注为“有间接证据”，并在结论中写明待补数据项和责任人。
技术负责人凭经验判断“能做”，可以直接写进可行性结论吗？
经验判断可以作为初步意见，写入结论前建议标注可信度。凡是没有经过验证的技术判断，在依据清单中记为“仅有经验判断”，并附上验证方式，例如接口联调、原型验证或性能预研。验证完成后更新结论。这样处理的好处是评审时能区分哪些结论已有证据支撑，哪些还依赖后续验证，避免把不确定项当成确定事实推进。
结论写成“有条件可行”时，条件应该放在哪里？
条件与结论写在同一处，不要拆到附录或另起文档。常见写法是先给出结论分类，再紧跟前提条件，例如“有条件可行，前提是完成接口重试机制开发、确认上下游排期窗口、上线前完成角色培训”。每个条件对应一条依据或一个待办，写明负责人和时限。条件发生变化时，回到需求边界与假设登记表更新，再同步调整结论，保持依据与结论对应。
分析进行到一半，需求范围被调整了怎么办？
先更新需求边界与假设登记表，把新增或删减的范围写清楚，再检查已收集的依据哪些仍然有效、哪些需要重新取证。范围变化通常影响时间与依赖、资源与成本两类依据，这两类要优先复核。已经完成的验证结论如果仍适用于新范围，可以保留并注明适用条件；不再适用的标注失效，避免旧结论被继续引用。
可行性分析要覆盖到什么程度才算可以进入评审？
判断标准是结论可追溯、条件可执行。六类依据都有来源和责任人，关键假设已验证或标注待验证并附验证计划，结论区分可行、有条件可行、不可行，待办事项有负责人和时限，每条依据能对应到需求登记表中的条目。达到这些条件，依据清单、验证记录和结论草案就构成一套可交付评审的材料；评审中出现新假设时，回到登记表更新即可。
