从用户任务和业务能力推导功能架构，核心是把“用户要完成什么”逐层转化为“产品需要具备哪些能力、这些能力如何分层与划界”。整个过程产出四类材料：用户任务链清单、业务能力与依赖表、分层模块草图、可评审的功能架构说明。本文按拆任务链、归纳能力、确定边界与分层、明确角色交付物、示例演示、文档化评审、完成检查的顺序展开，适合正在把功能清单整理为分层结构的 product、业务和技术角色参考。
要点总览（TL;DR）
- 从用户任务推导功能架构，先把目标用户的关键任务拆成含触发条件、关键步骤、完成结果和异常分支的任务链，作为后续能力归纳的稳定输入。
- 把任务链归纳为动宾结构、可独立交付结果的业务能力，标注数据依赖、流程先后和共享规则三类依赖，并反向核对每条任务链与每个能力的双向可追溯。
- 结合目标用户、核心场景和自建与复用判断产品边界，把能力组织为用户接触层、业务能力层、支撑能力层，按高内聚低耦合划分模块。
- 产品经理、业务方、架构或技术负责人、设计分工产出任务链清单、能力依赖表、分层模块草图和架构说明，在任务链完成与分层草图完成两个时点对齐。
- 功能架构说明按目标与范围、任务链、能力清单、分层图、模块边界、依赖关系、待定项组织，评审关注边界清晰、依赖闭环和取舍理由成立，提交前用完成检查清单逐项核对。
先拆用户任务链：功能架构的输入从哪来
功能架构的推导起点是用户任务，功能清单本身。任务链描述目标用户在什么条件下、按什么顺序、完成哪些动作、得到什么结果。把任务链拆清楚，后续能力归纳才有稳定素材；直接从功能名出发，容易得到一张按界面或按团队分工排列的清单，难以讨论模块边界。
任务识别来源
任务来源应覆盖多个角度，避免只依赖单一角色的记忆：
- 用户访谈：让用户按最近一次真实操作复述过程，重点记录卡点和绕行做法。
- 工单与客服记录：从高频问题中提取被反复提及的任务环节和异常场景。
- 使用数据：观察关键路径的完成率、中断点和重复操作，定位任务链中的薄弱环节。
- 场景走查：由产品、设计和业务方共同按角色走一遍完整流程，补齐访谈中遗漏的分支。
任务链的拆法
一条任务链至少包含四个要素：触发条件、关键步骤、完成结果、异常分支。触发条件说明任务何时开始，例如收到审批请求、周期结算到期或客户提交资料；关键步骤按用户实际动作顺序排列，每步写清输入和输出；完成结果定义任务结束的可观察标志；异常分支记录退回、超时、信息缺失等偏离主路径的情况。异常分支往往对应后续需要单独设计的能力，拆解时不要省略。
记录字段与颗粒度控制
建议用固定字段记录任务链，便于后续归纳和评审：
| 字段 | 填写内容 | 示例 |
|---|---|---|
| 任务编号 | 唯一标识 | T-01 |
| 目标用户 | 角色与使用场景 | 区域销售负责人，月度复盘 |
| 触发条件 | 任务开始的事件或时点 | 月度结算数据生成后 |
| 关键步骤 | 按顺序的动作及每步输入输出 | 导出数据→核对差异→提交说明 |
| 完成结果 | 可观察的结束标志 | 差异说明审批通过 |
| 异常分支 | 偏离主路径的情况及处理 | 数据缺失时退回补录 |
颗粒度以“一个用户在一次场景中能连续完成、有明确结果”为准。步骤写到用户可感知的动作层，例如“核对差异”，继续拆到“打开对比页、逐行勾选”就过细，会把界面细节混入架构输入。
两个常见问题
第一是把功能名当任务，例如“使用报表模块”，这类描述没有触发条件和结果，无法推导能力。改写为“月度复盘时汇总各区域数据并形成结论”，任务链才成立。第二是颗粒度过细，把每个点击都列为一步，导致任务链数量膨胀、能力归纳时重复映射。控制方法是先按角色和场景归并，再保留对结果有影响的步骤。
把任务链归纳为业务能力并标注依赖
业务能力是对一组相关任务的抽象，描述组织或产品稳定交付某种结果的本领。能力名称建议用动宾结构，例如“汇总区域经营数据”“校验结算差异”“发起差异审批”，每个能力应能独立说明交付了什么结果，避免用“数据管理”“审批支持”这类无法判断完成状态的名词。
任务链到能力的映射
映射关系通常多对多：一条任务链会用到多个能力，一个能力也会被多条任务链复用。操作时逐条任务链标注其步骤所依赖的能力，再反向统计每个能力被哪些任务链引用。被多条任务链共同引用的能力，往往是后续模块划分的重点；只被单条任务链使用的能力，需要判断是场景特化还是可归并的通用能力。
依赖标注的三种类型
- 数据依赖：能力 B 的输入来自能力 A 的输出，例如差异校验依赖汇总结果。
- 流程先后：能力之间存在固定执行顺序，例如审批发起必须在差异说明提交之后。
- 共享规则：多个能力使用同一套口径或规则，例如统一的组织权限、统一的指标定义。
共享规则类依赖容易被忽略，却直接影响模块边界：如果两个能力共用同一套规则且变更频繁，放在同一模块内维护成本更低；如果规则稳定且被广泛引用，适合下沉为支撑能力。
能力清单字段设计
| 字段 | 说明 |
|---|---|
| 能力编号与名称 | 动宾结构，可独立描述交付结果 |
| 对应任务链 | 列出引用该能力的任务编号 |
| 输入与输出 | 能力执行所需数据和产出的结果 |
| 上游依赖 | 数据来源、前置能力 |
| 下游使用方 | 消费该能力结果的其他能力或角色 |
| 共享规则 | 涉及的统一口径、权限或配置 |
| 覆盖判断 | 自建、复用、暂不覆盖，待边界分析后填写 |
完成标志是：每条任务链的每个关键步骤都能对应到至少一个能力，每个能力都能追溯到来源任务链，依赖关系没有孤立节点。
用产品边界确定能力的取舍与分层
能力清单不会全部进入本期产品范围。产品边界依据目标用户、核心场景和投入方式判断：服务哪类用户、覆盖哪些核心场景、哪些能力自建、哪些通过外部系统复用。边界判断要写成明确理由，例如“目标用户为内部运营，外部客户自助能力暂不覆盖”，而不是笼统标注“后续再做”。
三层结构组织能力
把能力按用户接触层、业务能力层、支撑能力层组织，便于讨论职责归属：
| 层级 | 承载内容 | 判断要点 |
|---|---|---|
| 用户接触层 | 用户直接操作的入口、流程引导、结果呈现 | 按角色和场景组织，避免把业务规则写进界面层 |
| 业务能力层 | 完成具体业务结果的能力，如汇总、校验、审批 | 按能力聚合模块，明确每个模块的输入输出 |
| 支撑能力层 | 被多层共用的规则、数据、权限、通知等 | 只沉淀稳定且被广泛引用的共性部分 |
模块划分原则
模块按能力聚合，追求高内聚、低耦合：同一模块内的能力共享数据和规则、变更节奏接近；模块之间通过明确的输入输出交互，减少跨模块的直接数据读取。划分时可以用“变更是否同步”做检验：如果两个能力总是一起修改，考虑合并；如果一方频繁变更而另一方稳定，考虑分开并定义清晰接口。
边界外能力的处理
边界外能力需要逐项记录处理方式：暂不覆盖的写明原因和重新评估条件；通过外部集成满足的写明对接对象和交互内容；列入后续演进的写明依赖的前置条件。三类处理方式都要进入架构说明的待定项，避免在评审时被当作遗漏。
角色分工与交付物：谁产出什么
推导过程涉及多个角色，职责不清会导致任务链失真或能力清单无人认领。下表给出一种常见分工，实际执行可按团队规模调整，但每项交付物应有明确的责任人和评审人。
| 交付物 | 责任人 | 评审人 | 衔接关系 |
|---|---|---|---|
| 用户任务链清单 | 产品经理，业务方提供场景与异常 | 业务方、设计 | 作为能力归纳的输入 |
| 业务能力与依赖表 | 产品经理，架构或技术负责人参与依赖判断 | 技术负责人 | 基于任务链清单产出 |
| 分层与模块边界草图 | 产品经理与架构或技术负责人共同 | 业务方、研发负责人 | 基于能力表与产品边界 |
| 功能架构说明 | 产品经理统稿 | 跨角色评审会 | 汇总前三项并记录待定项 |
对齐时点建议设在两处：任务链清单完成后，由业务方确认场景和异常是否完整；能力表与分层草图完成后，由技术和业务共同确认依赖与边界。评审会以文档为讨论对象，逐项确认或标注待定，避免在会上重新推导。
这些材料需要在团队间持续流转和版本更新。ONES 可在同一平台中协同管理项目事项、过程信息和关键节点，减少市场、产品、研发等角色之间的信息断层；任务链清单、能力表与评审记录可以作为工作项和文档承载，评审结论与待定项随节点推进更新。具体承载形式需结合团队自身流程规划。
示例：从一条任务链到模块划分
以下为演示情景，用于说明推导过程，不代表真实项目数据。
任务链描述
目标用户为区域运营人员，触发条件为月度结算数据生成。关键步骤：导出各区域结算数据；核对与上期差异；对超阈值差异填写说明；提交区域负责人审批；审批通过后归档。完成结果为差异说明审批通过并归档。异常分支包括数据缺失需退回补录、审批退回需修改说明。
归纳能力
该任务链可归纳出四项能力：汇总区域结算数据、校验期间差异、编制差异说明、发起并跟踪审批。其中“校验期间差异”被季度复盘任务链共同引用，“发起并跟踪审批”被多条任务链引用，属于可复用能力。
分层与模块归属
- 用户接触层：结算数据查看页、差异说明编辑页、审批进度页，按运营角色组织。
- 业务能力层：数据汇总模块、差异校验模块、说明编制与审批模块。差异校验与说明编制共享差异口径，可放在同一模块内；审批被多场景复用，独立为审批模块。
- 支撑能力层：组织与权限、通知、指标口径配置，供上述模块共同引用。
依赖呈现
依赖关系用“能力—输入—输出—下游”的表格或箭头图表达：数据汇总输出结算数据集，差异校验消费该数据集并输出差异清单，说明编制消费差异清单，审批模块消费说明并回写审批状态。共享的指标口径配置被汇总与校验同时引用，标注为支撑层依赖。这样一张图即可支撑模块边界的讨论。
形成可评审的功能架构说明
功能架构说明的作用是让业务、产品和技术在同一份材料上讨论边界与取舍。文档结构建议包含：目标与范围、用户任务链、业务能力清单、分层架构图、模块边界说明、依赖关系、待定项与演进路径。每部分保留来源编号，便于追溯。
评审关注点
- 边界是否清晰：每个模块的职责能否用一句话说明，边界外能力是否都有处理方式。
- 依赖是否闭环：能力之间的输入输出是否都有来源和去向，是否存在无人消费的输出。
- 取舍理由是否成立：自建、复用、暂不覆盖的判断是否与目标用户和核心场景一致。
待定项与版本管理
待定项逐条记录问题、影响范围、责任人和重新评估条件，例如“外部结算系统对接方式待确认，影响汇总模块输入”。评审后按结论修订文档并保留版本号，重大边界调整在版本说明中注明原因，确保后续讨论基于同一版本。
在评审环节，ONES 支持对整体技术方案和子系统设计进行验证，关注技术可行性、接口一致性与风险可控；模块划分与关键节点可作为总体技术方案的组成部分纳入评审记录。评审通过后，架构说明与待定项继续随项目节点跟踪。
完成检查：架构说明是否可用
提交评审前，用以下清单逐项核对，全部满足即可认为架构说明达到可讨论状态。
| 检查项 | 通过标准 |
|---|---|
| 任务链覆盖 | 目标用户的核心场景均有任务链，含触发、步骤、结果、异常 |
| 能力覆盖 | 每条任务链的关键步骤可追溯到能力，每个能力可追溯到任务链 |
| 分层清晰 | 三层结构完整，每个模块归属明确，职责可用一句话描述 |
| 边界明确 | 自建、复用、暂不覆盖均有判断理由，边界外能力有处理方式 |
| 依赖可追溯 | 数据依赖、流程先后、共享规则均有标注，无孤立节点 |
| 待定项记录 | 待定项有责任人、影响范围和重新评估条件 |
| 评审条件 | 业务、产品、技术三方确认范围与边界，遗留问题进入待定项 |
检查中发现任务链缺失，回到第一步补充；发现能力无法归属模块，回到分层步骤调整边界；发现依赖无法闭环，与上下游角色确认输入输出后再修订。完成检查后，文档即可作为后续方案设计和排期的共同基础。
常见问题
任务链拆到多细才适合作为功能架构的输入？
颗粒度以“一个用户在一次场景中能连续完成、有明确结果”为准。步骤写到用户可感知的动作层，例如“核对差异”，继续拆到“打开对比页、逐行勾选”就过细，会把界面细节混入架构输入。判断方法是看这一步是否影响任务结果：影响结果的动作保留，纯操作细节归并到步骤说明里。任务链数量过多时，先按角色和场景归并，再保留对结果有影响的步骤。
一条任务链对应多个能力、一个能力被多条任务链引用，这种情况怎么处理？
多对多是正常情况，不需要强行改成一对一。操作时逐条任务链标注其步骤所依赖的能力，再反向统计每个能力被哪些任务链引用。被多条任务链共同引用的能力，通常是后续模块划分的重点，可以考虑独立成模块或下沉为支撑能力；只被单条任务链使用的能力，需要判断是场景特化还是可归并的通用能力。完成标志是每条任务链的每个关键步骤都能对应到至少一个能力，每个能力都能追溯到来源任务链。
产品边界外的能力，在架构说明里应该怎么写？
边界外能力需要逐项记录处理方式，并写明理由，避免在评审时被当作遗漏。常见三类处理方式：暂不覆盖的写明原因和重新评估条件，例如“目标用户为内部运营，外部客户自助能力暂不覆盖”；通过外部集成满足的写明对接对象和交互内容；列入后续演进的写明依赖的前置条件。三类处理方式都进入架构说明的待定项，并指定责任人和影响范围。
功能架构说明评审时，业务方和技术方关注点不同，怎么组织讨论？
建议以文档为讨论对象，按固定顺序逐项确认，避免在会上重新推导。先确认目标与范围、任务链是否覆盖核心场景和异常，由业务方主答；再确认能力依赖是否闭环、模块接口是否清晰，由技术方主答；最后共同确认自建、复用、暂不覆盖的取舍理由是否与目标用户和核心场景一致。评审结论逐条记录，无法当场确认的进入待定项，注明责任人和重新评估条件。
架构说明评审通过后，后续需求变化导致边界调整，文档怎么维护？
评审后按结论修订文档并保留版本号，重大边界调整在版本说明中注明原因，确保后续讨论基于同一版本。待定项随项目节点跟踪，重新评估条件触发时回到对应章节修订。新增任务链或能力时，同步更新任务链清单、能力依赖表和分层图，保持三者编号可追溯。这样架构说明可以作为后续方案设计和排期的共同基础，而不是一次性的评审材料。
