这段时间我们在推进敏捷，很多同事都会问一个非常核心的问题：

机器人业务的需求，到底应该怎么拆？

以前我们做需求，更多是把需求描述清楚，然后直接给研发团队。现在不一样了。
现在我们要做敏捷，PO、PM、SE、Scrum Master，包括开发团队，都会更早地参与进来。这样做的目的，不是为了增加流程，而是为了让需求更快进入闭环，让交付更确定，让每一次开发都更贴近客户真实场景。

但问题也恰恰出在这里。

机器人业务和互联网业务不一样。
互联网很多需求天然就是页面流、交互流、数据流，适合直接按功能拆。
但机器人业务不是。机器人业务背后往往是：

• 某个行业的工艺问题
• 某个客户现场的堵点
• 某个调试过程中的痛点
• 某个交付环节的效率问题
• 某个算法能力导入后的落地问题

这些问题如果我们还是按“功能点”去拆，最后一定会拆散，拆偏，甚至拆成研发任务，导致团队越做越碎，越做越没有闭环。

所以这次我们内部拉了一个会，专门对齐了一件事：

机器人需求拆解，不能按功能拆，要按场景拆；不能只写需求清单，要写到用户故事和验收标准；不能只追求描述清楚，更要追求可验证。

这是我们当前阶段最重要的共识。

一、为什么我们要重构需求拆解方式

以前我们做需求，基本逻辑是这样的：

1. 收集需求
2. 写需求说明
3. 评审通过
4. 给研发开发

这种方式的问题在于：

• 需求往往停留在“客户想要什么”
• 但没有真正讲清“客户在什么场景下遇到了什么问题”
• 没有讲清“我们到底解决的是哪个最关键的痛点”
• 没有讲清“做到什么程度才算真正解决问题”
• 到了研发阶段才发现理解偏差很大
• 到了测试和交付阶段才发现这个功能其实并没有形成闭环

这在机器人业务里尤其明显。

比如客户提一个“免调参”“一键换型”“操作更简单”“支持快捷键”“支持远程 IO 调参”，这些话本身都没错，但它们都还是需求表象，不是产品化之后的交付单元。

如果我们不往下继续拆，研发拿到的其实还是一句话需求。
一句话需求做不了高质量开发，也做不了高质量验收，更做不了真正的敏捷。

所以我们这次调整的核心，不是“为了敏捷而敏捷”，而是因为我们想把需求从“描述层”推进到“闭环层”。

二、机器人需求拆解，最核心的原则是什么

我认为只有两条，但这两条非常关键。

1. 按场景拆，不按功能拆

这是这次大家达成的第一共识。

什么叫按场景拆？

就是每一个需求进来以后，我们首先不是去想它属于哪个模块，不是去想应用软件、系统软件、算法、测试分别干什么，而是先要问：

• 这个需求发生在什么场景？
• 这个场景里是谁在用？
• 他在做什么动作？
• 他卡在哪？
• 我们要解决的到底是什么问题？

比如“远程 IO 下调参数麻烦”这个需求，如果按功能拆，很容易变成：

• 增加权限配置
• 开放某个参数修改
• 改一个页面交互

但如果按场景拆，就完全不一样了。

这个需求真正的场景是：

终端生产员工在正常生产过程中，发现设备报警，需要在不切换复杂权限流程的前提下，快速调整全局速度或加速度，避免频繁中断，提升故障处理效率。

你看，当场景清楚以后，需求就不再是“改权限”这么简单，而是变成了一个明确的问题闭环：

• 谁：终端生产员工
• 在什么场景：正常生产、发现报警
• 需要做什么：调整全局速度和加速度
• 为什么：避免报警、快速恢复生产

这才是可继续往下拆的起点。

2. 需求拆完以后，最终一定要可验证

这是第二个核心原则。

什么叫可验证？

就是我们最终交付给客户的，不是一个“看起来做了”的功能，而是一个能判断“是否真的解决问题”的结果。

所以拆解过程中，用户故事一定不能停留在“更快了”“更方便了”“更简单了”这种模糊描述。
这些话对用户来说是自然语言，对研发和测试来说是不够的。

我们必须继续往下走，把它转成可验收的语言。

比如客户说：

• 圆弧过渡会卡顿
• 行号编辑不好用
• 远程模式调参数很麻烦
• 切换工艺不方便
• 免调参要更智能

这些都不是验收标准，它们只是感受。

真正进入研发和测试语言后，要变成：

• 在什么前提条件下
• 执行什么操作
• 系统应该表现成什么样
• 响应时间、过渡效果、权限逻辑、动作结果是否满足要求

所以我一直在强调：

用户故事是站在用户角度描述问题与结果；验收标准是站在研发和测试角度，把“解决问题”转成结构化、量化、可落地的语言。

三、机器人需求拆解的完整路径到底是什么

这次我们内部其实已经把拆解路径初步统一了。
我把它整理成一条完整链路：

需求 → 客户痛点 → 具体场景 → 解决方案 → 价值判断 → 用户故事 → 验收标准 → 研发任务 → 模块任务

这条链路不是为了增加步骤，而是为了避免我们一上来就从“需求”跳到“开发”。

我逐步讲一下。

第一步：先提炼客户痛点

因为我们当前收集到的大量信息，本质上还是需求列表。
这些需求里面有的来自行业，有的来自项目，有的来自交付，有的来自竞争差距。

但需求不是痛点。

我们要先问：

• 客户真正痛的是什么？
• 他不是想要某个功能，而是想解决什么问题？

比如“免调参”不是痛点，痛点可能是：

• 高速场景下为了兼顾节拍、抖动和寿命，调试人员要反复试错，调起来非常累
• 参数之间耦合强，经验依赖重，小白工程师难以快速上手

这才是痛点。

第二步：把痛点放进具体场景里

光有痛点还不够。
一定要再往前推进一层，问：

• 这个痛点发生在哪个场景？
• 是码垛工艺、点焊工艺、涂胶工艺，还是武汉场景、传统行业场景、汽车行业场景？
• 在这个场景的哪个环节？
• 用户在做哪个动作的时候遇到了问题？

为什么一定要这么问？

因为同一个需求，在不同场景里的含义完全不一样。

“免调参”在锂电高速搬运和在胡汉某个工艺包里的复杂度，可能不是一个量级。
“快捷键”在汽车主机厂的习惯里是刚需，在别的行业里可能就不是第一优先级。
“安全空间”对某些客户是验收必选项，对另一些客户又是阶段性优化项。

所以需求必须放进场景里，才有意义。

第三步：针对这个场景明确解决方案

当场景足够清楚以后，解决方案才会自然浮现出来。

注意，这里的解决方案不是要一下子写成技术方案，而是先回答：

• 我们准备怎么解决这个场景里的核心堵点？

比如远程 IO 这个例子里，解决方案就很明确：

在远程 IO 模式下，开放与示教模式一致的关键参数调整能力，让用户在远程模式下也能修改全局速度、加速度等必要参数，减少频繁切权限的负担。

只要场景和问题明确，解决方案往往不会太虚。

第四步：做价值判断，选当前最优解

这一步我们昨天也专门讲了。

为什么需要价值判断？

因为同一个场景的问题，往往不止一种解决办法。

有的方案做得更彻底，但投入大、周期长；
有的方案做得没那么完美，但能最快闭环、性价比最高。

在敏捷实践里，我们不能天然追求“最完整的方案”，而要追求：

当前阶段投入产出比最高、最能快速闭环、最能尽快验证价值的方案。

所以价值判断不是一句空话，它本质上是在做解决方案的取舍。

第五步：写用户故事

这一步是非常关键的分水岭。

用户故事不是在写规格书，也不是在写研发任务。
用户故事是站在用户视角，去定义：

• 谁
• 在什么场景
• 需要完成什么事情
• 最终达到什么效果

我们现在统一的理解其实很简单，就是“三段论”：

谁，在做什么事情的时候，需要达到什么效果。

比如远程 IO 的例子：

终端生产员工在正常生产过程中，发现电流报警，需要在远程模式下快速调整全局速度和加速度，以便设备后续运行时不再持续报警。

这就是一个典型的用户故事。

第六步：写验收标准

这是把用户语言转成研发与测试语言的关键一步。

验收标准不是简单复述用户故事，而是要把它变成：

• 前提条件
• 行为
• 期望结果

或者说：

• 在什么模式下
• 允许做什么操作
• 做完之后系统应该如何表现
• 哪些边界是允许的，哪些是不允许的

比如：

• 在远程模式下，允许修改全局速度与全局加速度
• 修改后参数即时生效，并在后续运行中按新参数执行
• 不需要额外切换到示教权限才能完成该操作
• 操作过程权限逻辑不冲突，界面反馈明确

这种语言研发一看就知道怎么理解，测试也知道怎么验。

第七步：再往下才是研发任务

到这一步，才轮到研发视角去问：

• 应用软件需要做什么
• 系统软件需要做什么
• 算法需要做什么
• 测试需要做什么

所以研发任务不是前面 PM 和 PO 一拍脑袋就写死的。
它是前面信息足够清楚以后，自然派生出来的。

第八步：再细化成模块级任务

这一层就是开发团队真正进入 Sprint backlog 的颗粒度了。

到了这一步，任务就会变得很细了。
但它必须建立在前面信息足够结构化的前提上。

四、为什么机器人需求拆解比想象中更难

很多同事会觉得：

“这不就是把需求写清楚吗？为什么还要搞这么多层？”

问题就在于，机器人业务不是单一软件业务。

它天然就有几个复杂性：

1. 工艺复杂

同一个需求，在不同工艺场景下复杂度完全不同。
比如免调参，在高速场景和低速场景里就不一样；在胡汉和锂电里也不一样。

2. 需求往往不是一句话能讲清

很多需求表面上只有一句话，但一往下拆会发现里面有十几个痛点、多个环节、多种情况。

3. 用户视角和研发视角天然不同

用户说“卡顿”，研发必须知道卡顿体现在哪个指标。
用户说“麻烦”，研发必须知道是切权限麻烦、切模式麻烦，还是流程跳转麻烦。

4. 机器人需求强依赖场景验证

互联网很多需求做完点一点就能验证。
机器人不是。机器人往往要看工艺动作、控制逻辑、运行反馈、现场可用性。

所以我们这次才会明确：

机器人需求拆解不能追求表面上的快，而要追求结构化、闭环化和可验证。

五、PO、PM、SE、Scrum Master 在需求拆解里的分工到底是什么

这次我们也基本对齐了一个方向。

前半段更偏产品侧主导

从需求到用户故事这一段，重点是：

• 挖痛点
• 定场景
• 选方案
• 做价值判断
• 写用户故事
• 写验收标准

这部分更适合由 PM / PO 主导，必要时拉上 SE、工艺、资深开发一起共创。

后半段更偏研发侧主导

从研发任务到模块任务这一段，重点是：

• 如何落模块
• 如何进 Sprint
• 如何做任务切分
• 如何评估工时和容量

这部分更多由开发团队、SE、Scrum Master 主导，产品侧参与审视和确认。

Scrum Master 的价值是什么

Scrum Master 在这里不是来写需求的，
而是帮助大家建立结构化模板，让信息从产品端传递到开发端时更高效、更少偏差。

这一点在这次讨论里很明确：

形式不是目的，但结构化模板是必要的。
不可能完全没有理解偏差，但我们可以通过模板把偏差降到更低。

我非常认同这一点。

六、我们当前形成的一个非常重要的共识：先走一轮，再持续迭代

这一点我觉得特别重要。

因为现在大家都在问：

• 这种复杂需求到底适不适合按敏捷拆？
• 用户故事到底要写到多细？
• 验收标准到底是三段论好，还是前提/行为/期望结果更好？
• 复杂工艺是不是根本不适合这样拆？

这些问题，单靠讨论永远聊不清。

所以我们这次其实形成了一个非常重要的实践原则：

先走一轮。先拆一轮。先跑起来。然后再基于真实交付效果持续优化。

这本身也是敏捷。

不要一开始就追求模板完美、形式完美、颗粒度完美。
如果一个需求比较简单，大家都能看懂，那就不要拘泥于形式。
如果一个需求比较复杂，那就上更结构化的模板。

核心不是形式，而是：

• 能不能把场景讲清楚
• 能不能把价值讲清楚
• 能不能把验收讲清楚
• 能不能高效传递给开发团队
• 能不能真的做成闭环

七、关于资源、优先级和需求拆解，我的几个判断

这次会上还有一个很现实的问题反复出现，就是资源。

这个问题必须正视。

现在很多团队的真实情况是：

• 需求很多
• 资源很紧
• 一些高优需求已经不能再裁
• 架构导入、功能安全、多机等专项又在吃资源
• 大家都担心最后承接不住

我对这个问题的判断是：

1. 不要脱离需求谈资源

这一点会上大家其实也慢慢统一了。

没有拆清楚需求之前，资源讨论很容易失真。
因为大家都只能凭印象评估，最后容易陷入空转。

所以先拆，再看缺口，是对的。

2. 也不要脱离资源谈“全都要”

资源是现实约束。
敏捷不是许愿机制，不是把所有需求都往前排。

所以优先级必须排，而且必须由最懂业务价值的人来排。

3. 当前最重要的是先把 TOP 需求拆出来

不要等所有需求全拆完才启动。
拆一个，给一个；拆两个，给两个。

只要开发团队不在等，我们这套机制就开始转起来了。

4. 最后是否上升资源问题，要建立在拆解结果上

这个也非常关键。

如果我们拆完以后发现：

• 只差 10%、20% 的能力缺口，那可能内部还能兜
• 如果缺口是 100%、200%，那就必须上升，而且是带着结构化结论上升

否则上面也会反过来问你：

• 你们到底要做什么？
• 缺口到底在哪？
• 为什么不够？
• 是需求没收敛，还是资源真不够？

所以，拆解本身也是资源问题上升的前置准备。

八、我现在对“机器人需求拆解”的一个最终定义

如果让我把这次会议和这段实践总结成一句话，我会这么说：

机器人需求拆解，不是把一句需求写得更长，而是把模糊需求逐层拆成“场景明确、价值清楚、用户可感知、研发可理解、测试可验证、交付可闭环”的结构化交付单元。

更具体一点说，就是：

• 从客户需求里提炼痛点
• 从痛点里还原场景
• 从场景里选择最优解
• 从最优解里定义用户故事
• 从用户故事里抽出验收标准
• 再把它交给研发团队去落成任务

这套逻辑一旦走顺，后面 Feature、Story、验收、研发任务、Sprint backlog，整个链条就顺了。

九、接下来我们怎么做

我认为后面就做三件事。

第一，先把 TOP 需求拆起来

不要空谈。
每个领域先把最高优先级的 3~5 个需求拆出来，边拆边交付。

第二，模板先统一，再在实践里优化

先有模板，哪怕不完美；
先能高效传递，再在实践中不断优化。

第三，先跑出第一轮闭环

第一轮不追求完美，追求真实。

我们需要的是：

• 第一个需求拆出来
• 第一个需求交给开发团队
• 第一个需求进入敏捷节奏
• 第一个需求交付出来
• 然后大家一起复盘：哪里对了，哪里偏了，哪里还要改

只有这样，这套方法才会越跑越顺。

十、最后一句话

这次我们推进敏捷，我最希望大家统一的，不是形式，而是思路。

我们不是为了多一层文档，不是为了多几个模板，更不是为了让大家更忙。

我们做需求拆解这件事，最终只有一个目的：

让机器人产品的每一次开发，都更贴近真实场景；
让每一个交付单元，都更能形成价值闭环；
让我们的研发、测试、交付和产品之间，减少偏差、提高效率，把真正重要的需求更快做出来。

这才是我们做这件事的意义。