软件项目里最贵的从来不是写代码而是把到底要做什么讲清楚。一句我想要一个 XX 系统从业务方嘴里说出来到开发能动手做中间隔着十几次澄清、几十个边界判断、上百条规则确认。资深 BA 之所以稀缺是因为这份工作同时需要三件事业务领域知识、结构化工作流程、与各方沟通的能力。团队里这样的人可能只有一两个但每个项目都需要。Engineering Skill Warehousemcp.smartmoves.com.cn 把这件事工程化成了可复用资产。其中 BA Master 是面向业务需求澄清的技能集目标只有一个把资深 BA 的方法论装进每个项目让初级 BA、新人、甚至业务方自己也能产出同样质量的需求资产。一、背景和问题业务需求为什么总是说不清1.1 三层困境业务需求澄清在工程上是道分水岭概念层——业务方说我想做一个云收银系统开发一脸茫然什么场景、什么角色、什么数据、什么边界澄清层——业务方自己也不知道要什么需要有人带着问主线流程是什么异常情况怎么处理角色权限怎么分数据口径以谁为准交付层——需求文档写完了开发做完才发现原来你要的不是这个意思。返工、扯皮、合规审查没过全部集中在这一层。资深 BA 的价值就体现在穿越这三层的能力上。问题是这种能力很难规模化。1.2 资深 BA 为什么稀缺一个合格的资深 BA 需要三件事的合集——业务领域知识、结构化工作流程、沟通与澄清能力。三者合一需要 5 年以上实战积累。团队里这样的人可能只有一两个但每个项目都需要。每个项目都靠同一个人注定不可持续。1.3 一句话生成 PRD的浅层模式风险过去两年AI 在需求文档上的应用普遍停留在浅层模式用户输入一句话模型输出一份看起来完整但经不起问的 PRD。这种模式有三个典型问题范围不清、数据实体缺失、没有合规视角。浅层模式的风险在于它让团队产生已经有了 PRD的错觉跳过了真正的澄清工作。等到开发返工、合规审查被驳回时代价已经付完。二、解决方案把资深 BA 方法论工程化为 Skill 资产2.1 Engineering Skill Warehouse 的整体思路Engineering Skill Warehousemcp.smartmoves.com.cn 把软件工程中三类核心方法论封装为三个 Master 技能集BA Master定义做什么——业务需求澄清。SA Master设计怎么做——技术架构落地。PM Master编排何时交付——迭代计划与三维并行。三个技能集通过 MCP 协议接入主流 AI 开发环境一次封装、多端分发。任何团队只要在 Agent 客户端里加载 ba-master.zip就能立即获得资深 BA 的方法论能力。2.2 BA Master 的定位与边界BA Master 的核心职责是划定需求范围——通过结构化提问和领域知识注入把概念级需求下沉成可被下游消费的结构化资产。职责边界清晰✅ 需求分析相关辅助工作澄清范围、提取数据、绘制流程、编写用户故事、生成 UI 规格、做合规审查。❌ 不做代码实现、不做技术架构设计、不做 UI 视觉设计。❌ 不确定的业务规则标记为待确认不编造。2.3 接入方式在 mcp.json 中加三行配置即可{ba-agent:{url:https://mcp.smartmoves.com.cn/ba/mcp,transport:streamable-http}}适配 OpenClaw、Hermes、Workbuddy、Qoder 等主流平台也可下载 ba-master.zip 直接导入。2.4 与 SA / PM 的协作BA MasterPRD → SA Master架构 → PM Master迭代计划MCP 协议在每次交接时记录结构化契约下游 Agent 按字段解析不重新理解上下文。整条概念 → 需求 → 架构 → 计划链路可追溯、可评测、可回归。三、BA Master 的六项核心技能点3.1 需求规格说明书PRD从一句话概念到结构化 PRD。8 阶段交互产出包含场景分析、流程描述、数据实体、系统边界。解决概念到 PRD最大的鸿沟。详见需求规格说明书。3.2 业务流程建模为每个场景产出四张图/表泳道图、状态机图、时序图、决策表。泳道图讲角色协作状态机图讲生命周期时序图讲消息交互决策表讲规则组合。详见业务流程建模。3.3 数据字典从场景分析中提取数据实体定义表结构、字段规范、ER 图和数据流图统一数据口径。详见数据字典。3.4 用户故事文档把 PRD 拆解为标准故事卡As-I-Want-So-That Given-When-Then构建故事地图、排列优先级。每张卡都是一个可独立验收的开发单元。详见用户故事文档。3.5 UI 规格逐场景逐页面定义 UI 组件映射、数据转化规则、阀门条件、操作链。在设计师做原型前把交互逻辑讲清楚避免设计完了发现逻辑漏了。详见UI 规格。3.6 合规审查报告从数据安全、资金安全、业务合规、技术合规四个维度扫描 PRD输出结构化审查报告。是 BA Master 的安全阀。详见合规审查报告。四、案例说明连锁餐饮门店收银系统的需求澄清全流程4.1 案例背景某连锁餐饮有 30 家直营门店正在用单机版收银系统希望升级为云端多门店版本。业务方最初提的需求是“我想要一个云收银系统要支持扫码点单、外卖对接、会员积分、退款。”——典型的一句话需求。4.2 第一步8 阶段需求澄清 → 完整 PRDBA Master 进入 8 阶段交互根目的发现——多门店数据互通、远程管控、避免每家店独立维护。领域知识加载——餐饮收银涉及发票合规、食品安全法、外卖平台对接规范。三维度澄清——场景维度堂食 / 外卖 / 自提、角色维度顾客 / 服务员 / 收银员 / 店长 / 后厨、规则维度退款时限、积分有效期、优惠券叠加规则。异常分支——断网时如何处理外卖订单取消时如何退款会员手机号不一致时如何合并数据实体初稿——门店、桌台、订单、菜品、会员、优惠券、支付流水。系统边界——本系统负责收银与会员营销活动由 CRM 系统提供接口。非功能需求——日订单峰值、响应时延、数据备份频率。结构化输出——按标准 PRD 模板输出。4.3 第二步业务流程建模 → 四张图泳道图顾客、服务员、收银台、后厨、外卖平台——展示一次扫码点单的完整协作。状态机图订单创建 → 已支付 → 已接单 → 已出餐 → 已完成再到申请退款 → 退款中 → 已退款 / 已驳回的所有迁移。时序图服务员扫码 → 系统生成订单 → 后厨打印出单 → 顾客支付 → 系统回调 → 库存扣减。决策表下单 30 分钟内 未出餐 未接触发票 → 全额退已出餐 未上桌 → 90% 退已上桌 → 走客服审批。四张图落地后开发团队对做什么就基本对齐了。4.4 第三步至第六步资产沉淀与下游交接数据字典展开核心实体门店表、订单表、订单明细表、会员表、支付流水表——每个字段标注类型、是否可空、是否加密配套 ER 图和数据流图。用户故事拆解为标准卡片例如“作为服务员我希望能在顾客扫码点单后立即收到新订单提醒Given 顾客已扫码下单When 后厨尚未接单Then 服务员手机应在 3 秒内收到推送”。UI 规格明确扫码点单页的组件映射、价格取数规则、按钮置灰条件、提交操作链。设计师拿着这份规格做原型不会漏掉关键交互。合规审查做四维扫描会员手机号加密存储、退款操作幂等、发票抬头与税务系统对接、敏感操作二次确认与 180 天审计日志。4.5 产出与价值经过 BA Master 全流程处理原本一句我想要一个云收银系统取成了一组结构化、可交接的需求资产一份完整 PRD含场景、流程、数据、边界、非功能。四张业务流程图。一份数据字典。50 张用户故事卡。多个页面的 UI 规格。一份四维合规审查报告。这套资产可直接交给 SA Master 做技术架构也可直接交给 PM Master 做迭代计划。下个项目再启动时BA Master 会基于已有领域知识库加速澄清而不是从零开始。结语业务需求澄清不是 BA 一个人的事而是整个项目能否顺利交付的起点。把资深 BA 的方法论装进团队的 Agent 客户端本质上是在做软件工程早就该做的事让最稀缺的经验成为可复用、可版本、可评测的工程资产。BA Master 是这条路径上的第一步。它不替代真实 BA 做最终决策但能让每个项目都拥有同等的资深 BA 能力起点。当需求澄清从靠人变成靠资产下游的架构设计、迭代计划、开发实施才有了一个可靠的前提。参考资料Engineering Skill Warehousemcp.smartmoves.com.cnBA Master 需求规格说明书BA Master 业务流程建模BA Master 数据字典BA Master 用户故事文档BA Master UI 规格BA Master 合规审查报告
把资深 BA 装进团队：BA Master 工程化实战手册
发布时间：2026/7/8 15:47:52
软件项目里最贵的从来不是写代码而是把到底要做什么讲清楚。一句我想要一个 XX 系统从业务方嘴里说出来到开发能动手做中间隔着十几次澄清、几十个边界判断、上百条规则确认。资深 BA 之所以稀缺是因为这份工作同时需要三件事业务领域知识、结构化工作流程、与各方沟通的能力。团队里这样的人可能只有一两个但每个项目都需要。Engineering Skill Warehousemcp.smartmoves.com.cn 把这件事工程化成了可复用资产。其中 BA Master 是面向业务需求澄清的技能集目标只有一个把资深 BA 的方法论装进每个项目让初级 BA、新人、甚至业务方自己也能产出同样质量的需求资产。一、背景和问题业务需求为什么总是说不清1.1 三层困境业务需求澄清在工程上是道分水岭概念层——业务方说我想做一个云收银系统开发一脸茫然什么场景、什么角色、什么数据、什么边界澄清层——业务方自己也不知道要什么需要有人带着问主线流程是什么异常情况怎么处理角色权限怎么分数据口径以谁为准交付层——需求文档写完了开发做完才发现原来你要的不是这个意思。返工、扯皮、合规审查没过全部集中在这一层。资深 BA 的价值就体现在穿越这三层的能力上。问题是这种能力很难规模化。1.2 资深 BA 为什么稀缺一个合格的资深 BA 需要三件事的合集——业务领域知识、结构化工作流程、沟通与澄清能力。三者合一需要 5 年以上实战积累。团队里这样的人可能只有一两个但每个项目都需要。每个项目都靠同一个人注定不可持续。1.3 一句话生成 PRD的浅层模式风险过去两年AI 在需求文档上的应用普遍停留在浅层模式用户输入一句话模型输出一份看起来完整但经不起问的 PRD。这种模式有三个典型问题范围不清、数据实体缺失、没有合规视角。浅层模式的风险在于它让团队产生已经有了 PRD的错觉跳过了真正的澄清工作。等到开发返工、合规审查被驳回时代价已经付完。二、解决方案把资深 BA 方法论工程化为 Skill 资产2.1 Engineering Skill Warehouse 的整体思路Engineering Skill Warehousemcp.smartmoves.com.cn 把软件工程中三类核心方法论封装为三个 Master 技能集BA Master定义做什么——业务需求澄清。SA Master设计怎么做——技术架构落地。PM Master编排何时交付——迭代计划与三维并行。三个技能集通过 MCP 协议接入主流 AI 开发环境一次封装、多端分发。任何团队只要在 Agent 客户端里加载 ba-master.zip就能立即获得资深 BA 的方法论能力。2.2 BA Master 的定位与边界BA Master 的核心职责是划定需求范围——通过结构化提问和领域知识注入把概念级需求下沉成可被下游消费的结构化资产。职责边界清晰✅ 需求分析相关辅助工作澄清范围、提取数据、绘制流程、编写用户故事、生成 UI 规格、做合规审查。❌ 不做代码实现、不做技术架构设计、不做 UI 视觉设计。❌ 不确定的业务规则标记为待确认不编造。2.3 接入方式在 mcp.json 中加三行配置即可{ba-agent:{url:https://mcp.smartmoves.com.cn/ba/mcp,transport:streamable-http}}适配 OpenClaw、Hermes、Workbuddy、Qoder 等主流平台也可下载 ba-master.zip 直接导入。2.4 与 SA / PM 的协作BA MasterPRD → SA Master架构 → PM Master迭代计划MCP 协议在每次交接时记录结构化契约下游 Agent 按字段解析不重新理解上下文。整条概念 → 需求 → 架构 → 计划链路可追溯、可评测、可回归。三、BA Master 的六项核心技能点3.1 需求规格说明书PRD从一句话概念到结构化 PRD。8 阶段交互产出包含场景分析、流程描述、数据实体、系统边界。解决概念到 PRD最大的鸿沟。详见需求规格说明书。3.2 业务流程建模为每个场景产出四张图/表泳道图、状态机图、时序图、决策表。泳道图讲角色协作状态机图讲生命周期时序图讲消息交互决策表讲规则组合。详见业务流程建模。3.3 数据字典从场景分析中提取数据实体定义表结构、字段规范、ER 图和数据流图统一数据口径。详见数据字典。3.4 用户故事文档把 PRD 拆解为标准故事卡As-I-Want-So-That Given-When-Then构建故事地图、排列优先级。每张卡都是一个可独立验收的开发单元。详见用户故事文档。3.5 UI 规格逐场景逐页面定义 UI 组件映射、数据转化规则、阀门条件、操作链。在设计师做原型前把交互逻辑讲清楚避免设计完了发现逻辑漏了。详见UI 规格。3.6 合规审查报告从数据安全、资金安全、业务合规、技术合规四个维度扫描 PRD输出结构化审查报告。是 BA Master 的安全阀。详见合规审查报告。四、案例说明连锁餐饮门店收银系统的需求澄清全流程4.1 案例背景某连锁餐饮有 30 家直营门店正在用单机版收银系统希望升级为云端多门店版本。业务方最初提的需求是“我想要一个云收银系统要支持扫码点单、外卖对接、会员积分、退款。”——典型的一句话需求。4.2 第一步8 阶段需求澄清 → 完整 PRDBA Master 进入 8 阶段交互根目的发现——多门店数据互通、远程管控、避免每家店独立维护。领域知识加载——餐饮收银涉及发票合规、食品安全法、外卖平台对接规范。三维度澄清——场景维度堂食 / 外卖 / 自提、角色维度顾客 / 服务员 / 收银员 / 店长 / 后厨、规则维度退款时限、积分有效期、优惠券叠加规则。异常分支——断网时如何处理外卖订单取消时如何退款会员手机号不一致时如何合并数据实体初稿——门店、桌台、订单、菜品、会员、优惠券、支付流水。系统边界——本系统负责收银与会员营销活动由 CRM 系统提供接口。非功能需求——日订单峰值、响应时延、数据备份频率。结构化输出——按标准 PRD 模板输出。4.3 第二步业务流程建模 → 四张图泳道图顾客、服务员、收银台、后厨、外卖平台——展示一次扫码点单的完整协作。状态机图订单创建 → 已支付 → 已接单 → 已出餐 → 已完成再到申请退款 → 退款中 → 已退款 / 已驳回的所有迁移。时序图服务员扫码 → 系统生成订单 → 后厨打印出单 → 顾客支付 → 系统回调 → 库存扣减。决策表下单 30 分钟内 未出餐 未接触发票 → 全额退已出餐 未上桌 → 90% 退已上桌 → 走客服审批。四张图落地后开发团队对做什么就基本对齐了。4.4 第三步至第六步资产沉淀与下游交接数据字典展开核心实体门店表、订单表、订单明细表、会员表、支付流水表——每个字段标注类型、是否可空、是否加密配套 ER 图和数据流图。用户故事拆解为标准卡片例如“作为服务员我希望能在顾客扫码点单后立即收到新订单提醒Given 顾客已扫码下单When 后厨尚未接单Then 服务员手机应在 3 秒内收到推送”。UI 规格明确扫码点单页的组件映射、价格取数规则、按钮置灰条件、提交操作链。设计师拿着这份规格做原型不会漏掉关键交互。合规审查做四维扫描会员手机号加密存储、退款操作幂等、发票抬头与税务系统对接、敏感操作二次确认与 180 天审计日志。4.5 产出与价值经过 BA Master 全流程处理原本一句我想要一个云收银系统取成了一组结构化、可交接的需求资产一份完整 PRD含场景、流程、数据、边界、非功能。四张业务流程图。一份数据字典。50 张用户故事卡。多个页面的 UI 规格。一份四维合规审查报告。这套资产可直接交给 SA Master 做技术架构也可直接交给 PM Master 做迭代计划。下个项目再启动时BA Master 会基于已有领域知识库加速澄清而不是从零开始。结语业务需求澄清不是 BA 一个人的事而是整个项目能否顺利交付的起点。把资深 BA 的方法论装进团队的 Agent 客户端本质上是在做软件工程早就该做的事让最稀缺的经验成为可复用、可版本、可评测的工程资产。BA Master 是这条路径上的第一步。它不替代真实 BA 做最终决策但能让每个项目都拥有同等的资深 BA 能力起点。当需求澄清从靠人变成靠资产下游的架构设计、迭代计划、开发实施才有了一个可靠的前提。参考资料Engineering Skill Warehousemcp.smartmoves.com.cnBA Master 需求规格说明书BA Master 业务流程建模BA Master 数据字典BA Master 用户故事文档BA Master UI 规格BA Master 合规审查报告
