需求可行性分析通常在需求被理解之后、进入方案设计和排期之前进行，从技术、业务、经济、合规四个维度判断一条需求能否做成、是否值得做、是否被允许做。四个维度各自给出可核验的结论，全部成立或有条件成立，需求才进入后续建模与评审。本文解释四个维度分别回答什么问题、各自要看哪些要点，以及结论如何记录和交接。
要点总览（TL;DR）
- 需求可行性分析在需求被理解之后、方案设计与排期之前进行，从技术、业务、经济、合规四个维度判断需求能否做成、是否值得做、是否被允许做。
- 技术维度看实现路径、架构兼容性、外部依赖、数据可得性与性能安全约束；业务维度看目标用户场景、目标一致性、替代方案与运营承接。
- 经济维度看研发运维成本、收益口径与回收周期、机会成本与不确定项；合规维度看个人信息使用、行业监管、合同与知识产权、内部审批。
- 四个维度是“与”的关系，任一维度不成立即转为不可行或有条件可行，前置条件需明确、可跟踪、可关闭。
- 可行性分析回答能不能做，需求评审检查表达与共识，需求建模负责结构化表达，优先级排序决定先做哪个。
需求可行性分析是什么，判断结论有哪几种
需求可行性分析是对一条已初步理解的需求做出成立性判断的活动。它发生在需求被收集和澄清之后、方案设计与排期之前，回答的核心问题是：这条需求在技术、业务、经济、合规四个方面是否站得住。它的输出是判断结论和支撑依据，方案设计、工作量拆解和排期都在结论之后进行。
可行性分析的结论通常分为四类：
- 可行：四个维度均成立，依据充分，可以进入方案设计与评审。
- 有条件可行：主体判断成立，但存在若干前置条件，例如需要某项外部接口先就绪、需要法务出具意见、需要确认收益口径。前置条件明确、可跟踪、可关闭时，需求可以带着条件推进。
- 暂缓：当前不具备判断或推进的基础，例如关键数据缺失、依赖方尚未确定、时机不成熟。暂缓需要写明重启判断的触发条件。
- 不可行：至少一个维度存在无法绕过的障碍，例如技术路径不成立、合规上被明确禁止、投入明显超出可承受范围。不可行结论同样要写明依据，便于后续复盘和答复提出方。
可行性分析与需求优先级排序、需求评审是不同环节。优先级排序回答“先做哪个”，前提是需求已被判断为可做；需求评审检查需求表达是否清晰、相关方是否达成共识。可行性分析回答“能不能做、值不值得做、允不允许做”，它的结论是评审的重要输入，但不能替代评审中的共识确认。
技术、业务、经济、合规四个维度的判断边界
四个维度各自回答一个独立问题，混用会导致判断失真。例如用“技术上能做”代替整体可行，或用“业务价值大”掩盖合规风险。下表界定各维度的职责范围。
| 维度 | 回答的问题 | 不负责的内容 |
|---|---|---|
| 技术 | 能否实现，实现路径与依赖是否具备 | 是否值得投入、是否合规 |
| 业务 | 是否解决真实问题，是否与产品目标一致 | 具体怎么实现、成本多少 |
| 经济 | 投入产出是否合理，机会成本是否可接受 | 技术方案细节、法律允许性 |
| 合规 | 是否被允许，需要哪些前置条件 | 业务价值大小、实现方式优劣 |
四个维度之间是“与”的关系：任一维度不成立，整体结论就不能是可行，应转为不可行或降级为有条件可行并列出前置条件。维度之间也存在相互影响，例如合规要求可能改变技术方案，经济测算可能反过来压缩业务范围，但每个维度的判断依据应独立记录，避免一个维度的乐观结论掩盖另一个维度的缺口。
每个维度具体要看哪些要点
每个维度都需要落到可核验的要点和证据上，判断才有说服力。以下按维度列出检查要点与常见证据形式。
技术维度
- 实现路径：是否有明确的技术方案或至少一条可验证的路径，关键难点是否已有原型或技术验证。
- 架构兼容性：与现有系统架构、数据模型、接口规范是否兼容，改造范围是否可控。
- 外部依赖：依赖的第三方服务、接口、硬件或合作方是否可用，交付时间是否匹配。
- 数据可得性：所需数据的来源、质量、更新频率是否满足需求。
- 性能与安全约束：在预期数据量和并发下能否达到性能要求，安全要求是否在现有能力范围内。
证据形式包括技术预研结论、原型验证结果、接口文档、架构评估意见。仅有口头判断的技术可行，通常不足以支撑结论。
业务维度
- 目标用户与场景：需求对应哪类用户、在什么场景下使用，问题是否真实存在且有频率。
- 目标一致性：与产品当前阶段目标、路线图是否一致，是否属于本产品应解决的问题。
- 替代方案：现有功能、人工流程或第三方工具是否已能覆盖，新需求的增量价值在哪里。
- 运营承接：上线后由谁运营、如何推广、如何收集反馈，是否有承接方案。
证据形式包括用户访谈记录、反馈数据、场景描述、与产品目标的对照说明。
经济维度
- 研发与运维成本：研发人力投入、后续运维与支持成本，按统一口径估算。
- 收益口径与回收周期：收益如何度量（收入、成本节约、效率提升），预计多久回收投入。
- 机会成本：同样的资源投入其他需求是否产出更高。
- 不确定性敏感项：哪些假设最可能变化，变化后结论是否翻转。
证据形式包括估算说明、收益测算表、敏感性分析。估算需要写明假设和口径，避免用单一数字代替分析过程。
合规维度
- 个人信息与数据使用：是否涉及个人信息收集、存储、共享，是否有合法依据和最小化设计。
- 行业监管要求：所在行业是否有准入、备案、审计等监管要求。
- 合同与知识产权：是否涉及第三方合同约束、开源许可、知识产权归属问题。
- 内部审批制度：是否需要法务、安全、数据治理等部门出具意见或走审批流程。
证据形式包括法务意见、隐私影响评估、合规检查清单、审批记录。合规判断宜在需求早期介入，避免方案成型后返工。
和需求评审、需求建模的区别
可行性分析常与需求评审、需求建模、优先级排序混为一谈，四者在需求流程中承担不同任务。
| 环节 | 回答的问题 | 主要产出 |
|---|---|---|
| 可行性分析 | 能不能做、值不值得做、允不允许做 | 四维度结论与依据、前置条件 |
| 需求评审 | 需求表达是否清晰、相关方是否达成共识 | 评审意见、确认结论 |
| 需求建模 | 需求如何结构化表达 | 用例、流程、数据模型等建模产物 |
| 优先级排序 | 先做哪个 | 排序结果与排期建议 |
可行性结论是评审的输入之一：评审时相关方可以质疑判断依据、补充前置条件，但评审本身不替代可行性判断。建模在可行性成立之后进行，负责把需求表达成可设计、可开发的形式。优先级排序则在可行且已确认的需求之间比较。理清这层关系，可以避免在评审会上反复讨论“到底能不能做”，也避免对尚不可行的需求提前投入建模工作。
一个例子：会员积分兑换需求怎么过四关
以下为演示性情景，用于说明判断过程，不代表真实客户案例。某产品收到需求：会员可用积分兑换合作方提供的商品。下面按四个维度演示判断过程。
技术维度。积分扣减与兑换记录可复用现有账户体系；合作方商品接口需要对接，对方提供测试环境但正式接口上线时间未定；兑换高峰的并发量需要评估。证据为接口文档和一次联调验证。结论：主体可实现，外部接口时间构成依赖风险。
业务维度。用户反馈显示积分长期沉淀、缺乏使用出口，需求对应真实问题；与当前提升会员活跃度的目标一致；现有积分商城仅支持自有权益，合作方商品是增量。证据为反馈数据与目标对照说明。结论：业务成立。
经济维度。研发投入约若干人月，后续需承担对接维护与客服成本；收益按活跃度提升和兑换带来的复购估算，回收周期依赖合作方商品吸引力这一不确定假设。证据为估算说明与敏感性分析。结论：收益口径需进一步确认，属于有条件成立。
合规维度。兑换涉及用户积分与订单数据向合作方传输，需要明确传输字段范围与用户授权；合作合同需约定数据使用边界与责任划分。证据为法务意见与数据字段清单。结论：需完成授权设计与合同条款确认后方可推进。
综合四个维度，该需求形成“有条件可行”结论，前置条件包括：合作方正式接口上线时间确认、收益口径确认、数据授权设计与合同条款完成。常见误解有三类：把技术可行当成整体可行，忽略经济与合规缺口；把合规当作上线前才处理的事项，导致方案返工；用粗略估算代替收益口径说明，使经济结论无法复核。
把四维度结论记录成可交接的文档
可行性结论需要落到文档和工作项上，才能被评审、排期和后续执行使用。一份可交接的结论记录通常包含以下字段：
- 维度：技术、业务、经济、合规，逐项记录。
- 结论：每个维度的判断结果，以及整体结论类型。
- 依据：支撑判断的证据，如原型结果、数据说明、法务意见。
- 前置条件：有条件可行时列出的待满足事项，写明验收标准。
- 责任人：每个前置条件的跟进人。
有条件可行时，前置条件应转为待办事项并跟踪关闭，关闭情况决定需求能否进入排期。判断依据随需求一起流转到评审和设计环节，供相关方查阅和质疑。
在协作工具中承载这套记录时，可以把可行性结论作为需求工作项上的结构化信息维护，将前置条件拆为子任务或检查项，通过状态变化反映关闭进度，并关联结论文档与评审记录，形成从判断到排期的可追溯链路。ONES 支持在需求工作项上记录结论与前置条件，并通过状态与关联文档完成交接；其知识管理能力可将结论文档、评审记录统一沉淀，便于后续检索与复用。具体字段与流程配置可按团队实际需要设置。
常见问题
可行性分析应该在需求流程的哪个时点做，做早了或做晚了会怎样？
合适的时点是需求已被初步理解、但尚未进入方案设计和排期之前。做早了，需求本身还没澄清，判断依据不足，容易得出“暂缓”却说不清重启条件；做晚了，方案已经成型，技术选型和资源投入都已发生，此时发现合规或经济上不成立，返工成本明显上升。
如果需求信息确实不足以判断，可以给出“暂缓”结论，并写明重启判断所需的触发条件，例如关键数据补齐、依赖方确定。这样既不阻塞流程，也避免在信息不足时勉强下结论。
四个维度中有一个不成立，需求是不是就直接否决？
不一定。四个维度是“与”的关系，任一维度不成立，整体结论就不能是“可行”，但具体处理取决于障碍的性质。存在无法绕过的障碍，例如技术路径不成立、合规上被明确禁止，应给出“不可行”并写明依据；障碍可以通过前置条件消除，例如需要法务意见、需要确认收益口径、需要外部接口先就绪，可以降级为“有条件可行”，把条件转为待办并跟踪关闭。
判断的关键是障碍是否可消除、消除成本是否可接受，以及条件关闭前需求能否安全地停在当前阶段。
经济维度的收益很难量化时，可行性分析还怎么做？
收益难以量化时，仍然要把口径和假设写清楚，避免用单一数字代替分析过程。可以按收益类型分别说明：收入类收益给出测算依据，成本节约类收益给出对比基线，效率提升类收益说明度量方式。同时列出最可能变化的假设，做敏感性分析，说明假设变化后结论是否翻转。
如果收益口径暂时无法确认，可以将其列为前置条件，结论写为“有条件可行”，待口径确认后再决定是否进入排期。这样经济结论至少是可复核的，而不是凭印象判断。
合规判断需要法务或安全部门参与，怎么安排才不拖慢需求节奏？
合规判断宜在需求早期介入。可以在可行性分析阶段先做一次初步筛查：是否涉及个人信息收集与共享、是否属于受监管业务、是否涉及第三方合同或开源许可、是否需要走内部审批。筛查出需要专业意见的事项后，再请法务、安全或数据治理部门出具意见。
把合规事项作为前置条件记录，写明责任人和验收标准，与需求工作项关联跟踪。这样合规工作与方案设计可以并行推进，避免方案成型后才集中处理导致返工。
可行性结论记录后，怎么和后续的评审、排期衔接？
结论记录通常包含维度、结论、依据、前置条件和责任人五类信息。整体结论为“可行”时，记录随需求进入评审，作为评审的输入材料；为“有条件可行”时，前置条件转为待办或检查项，关闭情况决定需求能否进入排期；为“暂缓”时，写明重启判断的触发条件；为“不可行”时，保留依据便于复盘和答复提出方。
在协作工具中，可以把结论作为需求工作项上的结构化信息维护，前置条件拆为子任务，通过状态变化反映关闭进度，并关联结论文档与评审记录。ONES 支持在需求工作项上记录结论与前置条件，并通过状态与关联文档完成交接，具体字段与流程配置可按团队实际需要设置。
