我们如何用敏捷做B端产品

我们如何用敏捷做B端产品

2019年秋天，我在一家做财税SaaS的公司负责一个大型企业的定制化交付项目。客户是一家拥有2400名员工的制造企业，合同金额不小，但需求清单拉出来足有17页A4纸。当时的交付总监看完之后说了一句话，我至今记得："如果按瀑布模式做，一年以后我们交付的，可能是一个客户已经不需要的产品。"

那是我第一次认真思考一个问题：在B端产品领域，敏捷到底是一套流程工具，还是一种直面不确定性的生存策略？

五年过去了，我先后参与了6个B端产品的敏捷实践，服务过的客户从几十人的创业公司到几千人的行业龙头。我看到的现实是：大多数团队在用敏捷的"形"，却在承受伪敏捷的"痛"。这篇文章不是要教你Scrum的3355，也不是要复述敏捷宣言。我想和你聊的是：当我们面对B端产品那种"需求复杂、决策链长、客户定制多、交付压力大"的典型困境时，敏捷到底应该怎么"跑"，才能真正跑出效果来。

一、B端敏捷的真相：问题从来不出在流程上

先把这个结论放在最前面：B端产品做敏捷，最大的障碍从来不是流程设计得不好，而是角色协作的方式不对。

我见过太多团队在敏捷转型时，第一件事就是找一个敏捷教练，搞一套Scrum流程，拉一个看板，开每日站会。三个月后发现，Sprint目标还是完不成，需求还是频繁变更，业务方还是不满意。然后大家得出一个结论："敏捷不适合我们这种B端业务。"

这个结论错得非常离谱。问题不出在敏捷本身，而出在一个被普遍忽视的根源上：B端产品的本质是"多人决策、长周期价值交付、复杂业务建模"，而你如果只是把C端敏捷那套"快速试错、小步快跑"的壳搬过来，当然会水土不服。

我来解释一下为什么"角色协作方式"才是关键。在B端产品开发中，常规的参与者至少包括：产品经理、技术负责人、开发工程师、测试工程师、业务方代表（可能是客户也可能是内部业务部门）、项目管理者。如果涉及定制化交付，还会有实施顾问和客户成功经理。

这些人的工作语言不同，考核指标不同，对"做完"的定义也不同。产品经理的"做完"是需求文档写完了，开发工程师的"做完"是代码提交了，测试工程师的"做完"是用例跑过了，业务方的"做完"是能用了。这四个"做完"之间，隔着巨大的认知鸿沟。

敏捷的真正价值，不是加速某个角色的工作，而是压缩角色之间的认知鸿沟。当这个认知没有建立起来的时候，你引入再多流程工具都只是在"规范低效协作"，而不是在"改善协作质量"。这就是我接下来要展开的核心逻辑。

二、真实场景还原：一个B端Sprint是如何"伪敏捷"的

为了让你更直观地理解问题，我复原一个我亲眼见过的真实场景。这个场景发生在我曾辅导过的一家做供应链管理系统的公司，团队规模大约40人，已经"推行敏捷"半年了。

他们的Sprint周期是两周，标准的Scrum配置：有产品负责人，有Scrum Master，每天开站会，每两周做评审和回顾。从表面上看，一切都很规范。但当你蹲下来观察一个完整Sprint的时候，你会发现真实情况是这样的：

1. Sprint计划会：需求还是说不清楚

计划会上，产品负责人打开一份38页的PRD，花了40分钟讲解本Sprint要做的功能：一个针对大客户的"多级库存预警规则配置模块"。讲解过程中，三名开发工程师的眼神逐渐涣散。PRD里写了规则触发条件、通知方式、权限配置等11个模块的详细字段说明，但没有一个地方说清楚"用户到底在什么场景下、因为什么痛点、要完成什么任务"。

一个后端工程师举手问："这个规则配置完以后，用户是在哪个页面看到预警结果的？"产品负责人翻了翻文档，说："这个在设计稿里有，稍等我找一下。"找了五分钟，发现设计稿和PRD的版本对不上。

问题诊断：B端产品的需求复杂性决定了PRD其实是一个"信息传递效率很低的媒介"。当你试图在文档里穷尽所有细节时，接收方反而会迷失在细节里，丢失对业务全局的理解。

2. Sprint执行期：开发和业务各自为战

Sprint开始后的第三天，开发团队发现一个技术问题：现有的数据库结构无法直接支持"多级库存"的层级关系，需要做一次数据模型的调整。技术负责人评估后认为影响范围比较大，需要额外3天工作量。

但Scrum Master的回答是："Sprint待办列表已经锁定了，不能在这个Sprint里加新任务。"这符合Scrum的教条，但不符合业务的现实。结果呢？工程师选择了一个"打补丁"的方案，用临时表实现了功能演示，把技术债留到了下个Sprint。

问题诊断：把Sprint待办列表当成"不能动的合同"来对待，是错误的。Sprint待办列表的真正意义是"团队对未来两周交付节奏的共同承诺"，承诺的是目标，不是具体的任务列表。当业务现实发生变化时，承诺的目标才是需要守护的东西，而不是那张任务清单。

3. Sprint评审会：业务方的反馈来得太晚了

两周结束，团队演示了做好的功能。业务方的代表看完之后沉默了一会儿，说："这个预警规则的触发逻辑，和我们实际业务的处理方式不太一样。我们一般是先人工审核一遍库存数据，确认无误之后才会触发采购单，你们这个直接自动触发了，这不行。"

这意味着团队两周的工作成果，有相当一部分需要推翻重做。更致命的是，这个问题完全可以在第一天就发现，但在两周的过程中，没有人让业务方看过中间状态的产品。

问题诊断：B端产品的评审会不应该只在Sprint结束时才开，而应该是高频、碎片化、持续进行的。让业务方在Sprint结束时才看到完整产品，相当于把"验证周期"拉长到了两周，这比瀑布模式好不了多少。

这三个场景映射出B端敏捷中最常见的三个断点：需求理解的断点、技术现实的断点、业务验证的断点。接下来，我会逐一拆解我们在实践中是如何解决这些问题的。

三、需求理解的关键变革：从"写文档"到"共建业务地图"

传统的需求传递路径是：业务方把需求告诉产品经理，产品经理消化后写成PRD，再传递给开发团队。这条路径每传递一次，信息就衰减一次。到开发手里时，他们对业务的理解可能只剩下50%。

我们做的一个关键改变是：把需求理解的过程从"串行传递"变成"并行共建"。

1. 用"用户故事地图"代替PRD开场

我们在Sprint启动前一周，会组织一场"用户故事地图"工作坊，参与者包括产品经理、技术负责人、业务方代表。会议的目标不是"写出所有需求"，而是"画出用户完成一项业务任务的完整旅程"。

举个例子，做"采购订单审批"这个功能时，我们会画出这样一条主线：采购员发起申请 → 部门主管审批 → 财务审核预算 → 超过审批权限则流转到总监 → 最终生成采购单。每一个节点我们会标注：用户此刻在做什么、需要看到什么信息、做出什么决策、担心什么问题。

这个过程的核心价值不做替代产品经理写文档，而是让所有角色对"用户在什么场景下完成什么任务"建立共同的画面感。当开发工程师理解了"财务审核预算"其实是财务人员需要在一个界面上同时看到本期预算余额、历史采购记录和供应商评分，他们对于数据库设计、接口返回字段的设计就有了完全不同的考量。

2. 用"业务价值"而不是"功能点"来做需求优先级

B端产品需求池里通常躺着几百条需求，优先级排序容易变成"谁喊得响谁排前面"或者"销售说这个能签单就排前面"。我们采用的优先级判断标准是三个维度：

1. 是否打通核心业务闭环：这个需求如果不做，用户是不是完成不了核心业务？
2. 是否影响多个客户：这是一个客户的定制需求，还是一类客户的共同需求？
3. 是否带来可量化的效率提升：这个需求做完，用户完成一项任务的时间能从多少降到多少？

这三个维度看起来很普通，但真正操作时你会发现，难度不在于维度本身，而在于团队能不能诚实地面对每一个需求的这三个答案。很多时候我们倾向于高估某个需求的"影响范围"来证明它的优先级。但数据不会骗人，当你要回答"影响的客户数量"时，你就必须去查数据，而不是凭印象。

四、重构团队角色：让每个人都对业务结果负责

这是整篇文章最想强调的观点：在B端敏捷中，角色的重新定义比流程的重新设计重要十倍。

传统模式下的角色分工是这样的：产品经理定义需求，开发工程师实现需求，测试工程师验证质量，业务方验收结果。这条流水线的问题是：每个人只对"自己的环节"负责，但没人对"用户拿到的最终价值"负责。

我们的改变思路是：把"流水线分工"变成"作战小组配置"。具体来说，我们重新定义了三个关键角色。

1. B端产品经理：从"需求翻译者"变成"业务价值的守门人"

在B端敏捷中，产品经理最核心的能力不是写PRD，而是有能力回答"这个需求做完，用户的工作方式会发生什么变化"。这意味着产品经理必须花大量时间泡在客户现场，理解用户的完整工作流，而不是坐在办公室里研究竞品功能。

我和PingCode的产品团队有过深度交流。他们在做敏捷开发解决方案时，产品经理不是先画原型，而是先到客户的研发现场旁听站会、看开发面板、翻阅迭代回顾记录，理解研发团队真实的协作痛点和信息断层。这个过程产生出来的需求，自带"场景基因"，开发团队理解起来几乎没有障碍。

我观察到一个细节：优秀的产品经理在Sprint计划会上不讲功能，讲故事。他们会说"我们的用户张经理每天早上到公司第一件事是打开项目看板看昨日的开发进度，现在他需要打开四个页面才能拼凑出一个完整画面"，而不是说"我们需要一个聚合视图功能"。前者让开发团队瞬间理解了"为什么要做"以及"做成什么样才叫好"。

2. 技术负责人：从"架构审批者"变成"技术可行性的早期参与者"

很多团队的技术负责人是在PRD完成后才介入的，他们的工作是在需求评审会上"审"需求。这个时点介入太晚了，一旦发现技术可行性有问题，只能让产品经理回去改需求，浪费大量沟通成本。

我们要求技术负责人在用户故事地图工作坊阶段就深度参与。当产品经理画出用户的业务旅程时，技术负责人会同步判断：哪些节点涉及到数据模型变更、哪些需要对接外部系统、哪些环节复杂度较高需要预留技术调研时间。这些判断会直接影响到Sprint的拆分方式和排期安排。

更重要的是，技术负责人在这个过程里承担了一个关键角色：把"技术约束"翻译成"业务可理解的选项"。举个例子，在做一个数据看板功能时，技术负责人不是直接说"实时计算做不了"，而是说"如果要求实时刷新，我们需要引入一套流处理框架，开发周期增加三周，系统维护复杂度也会提升，可以接受吗？还是说小时级刷新也能满足业务需求？"这种翻译让业务方参与到技术决策中，而不是被动接受技术结论。

3. 开发工程师：从"任务执行者"变成"方案共建者"

这是最难改变的一环，也是效果最显著的一环。传统模式下，开发工程师的工作模式是"接任务、写代码、提交、关闭任务"。很多工程师跟我说，他们经常写了三个月代码，不知道自己写的功能用户到底是怎么用的。

我们推动的改变是：让开发工程师参与Sprint开始前的需求拆分，并对自己所负责的用户故事的"完成定义"发表意见。以前"完成定义"是产品经理或者测试定的："功能能跑通就是完成"。但现在，开发工程师自己会思考："这个功能跑通只是第一步，异常情况的处理、边界条件的测试、数据量大的时候会不会崩，这些都是我必须考虑的问题。"

我见过最极致的案例是，一个资深后端开发在评审会上主动提出："这个采购审批流程里有一个逻辑漏洞，如果审批人在提交单子的时候刚好离职了，单子就卡死了。我可以在代码里加一个超时自动转交的逻辑，这个不需要写到需求文档里，但实际场景里一定会遇到。"这个判断来自他对B端业务场景的理解，而不是来自需求文档的说明。

五、Sprint设计与执行：以"可交付业务闭环"为最小单位

B端产品和C端产品在Sprint设计上有一个根本性的区别：C端产品的MVP可以是某个单一功能，但B端产品的MVP必须是"用户能完成一项完整业务任务的最小闭环"。

什么意思？举个简单例子。做C端电商产品，MVP可以是一个商品详情页的改版，用户看完就能判断有没有价值。但做B端进销存系统，如果你在MVP里只做了一个"入库单录入"而没有"入库单查询"和"库存数量更新"，用户什么都做不了，也验证不了任何东西。

这就要求我们在拆分Sprint时遵循一个原则：每个Sprint交付的增量，必须是一个独立的、用户可以上手使用并给出反馈的业务闭环。

1. 怎么判断一个Sprint目标是"业务闭环"？

我们内部有一个简单的自检清单，回答三个问题：

1. 用户能不能用这个增量完成一个具体的工作任务？（不是"看到"一个功能，是"完成"一个任务）
2. 用户完成这个任务后，产出的结果是有效的吗？（数据能被下一个环节正常使用）
3. 用户能不能在5分钟内告诉我们这个增量做得好不好？（能快速给出反馈）

如果三个问题答案都是"是"，这个Sprint目标就是一个合格的最小业务闭环。如果有一个回答是"否"，就需要要么缩小范围，要么重新设计Sprint目标。

2. Sprint周期：到底多长合适？

Scrum指南里说Sprint应该是1到4周，很多人就把这个当教条来用。但我的实践经验是：B端产品的Sprint周期应该由"业务闭环的大小"决定，而不是反过来。

对于PingCode这类服务中大型企业的产品，我观察到的实际经验是：2周的Sprint更适合产品稳定迭代期，3周适合需要一定技术调研的功能模块，4周适合涉及多个子系统联动的复杂功能。不是你选了哪个周期就固定不变，而是每个Sprint根据目标灵活调整。

但这里有一个铁律：不管Sprint是2周还是4周，中间都必须在第3-5天安排一次"业务快速验证"。具体做法是，开发出一个能演示的中间版本，花15分钟让业务方代表看一下。不需要完整的功能，不需要漂亮的界面，只需要一个能跑通的流程。这个15分钟暴露出来的问题，经常能帮团队避免后半段的大量返工。

六、每日站会与进度可视化：减少汇报感，增强协同感

每日站会可能是被误解和滥用最严重的敏捷实践。无数团队把站会开成了"微型汇报会"，每个成员对着Scrum Master或者技术负责人汇报昨天做了什么、今天打算做什么。汇报完了，别人的内容没注意听，各自解散干活。

站会的真正价值不是"同步状态"，而是"发现阻碍并当场决定谁来解决"。

1. 我们怎么开站会

我们有三个具体规则，和常规做法不太一样：

第一，站会围绕"用户故事"展开，而不是围绕"人"展开。看板上有哪些用户故事正在开发中，我们就一个一个过。谁在这个故事上做了什么事，直接在这个上下文中说出来。这种围绕"事"而不是"人"的站会结构，天然让团队成员更关注任务本身的进展和阻碍，而不是个人的表现。

第二，发现卡点必须当场定人定时间。如果一个问题不在站会上被解决，站会结束后很可能就被拖到第二天。我们的规则是，只要出现了阻碍某个用户故事前进的问题，Scrum Master必须当场问："这个问题谁来解决？今天几点前能给出结论？"然后把这个事项记在看板的"站会决议"区域，第二天的站会第一个检查的就是这个决议的完成状态。

第三，站会不超过15分钟，但15分钟必须聊透所有"异常信号"。一个Sprint有10个用户故事在并行，正常推进的故事不需要讨论，一句"正常"就过。但开发者如果说"有一个技术上的不确定点"，就要深挖下去。哪怕15分钟只讨论了一个故事的状态，也比走马观花过完所有故事有价值。

2. 用PingCode迭代看板做进度透明化

我们在使用PingCode进行Scrum项目管理的时候，发现一个非常有价值的设计：它的迭代概览页面可以实时展示当前Sprint的用户故事完成比例、剩余故事点以及燃尽图趋势。这不是一个给管理者"盯人"的工具，而是一个给团队自己做决策的"信息看板"。

举个例子：在Sprint进行到第5天的时候，燃尽图显示剩余故事点仍然很高，曲线偏离了理想线。团队自己在站会上就能看到这个信息，然后主动讨论："我们是不是要重新评估一下优先级，把高价值的先确保交付？"这个过程不需要管理者的干预，信息透明本身就会驱动行为。

七、评审与回顾：把仪式变成"反馈引擎"

Sprint评审会和回顾会，在大量团队里已经变成了"走过场"。评审会上业务方随便看看，说一句"还行"；回顾会上大家象征性地贴几张便利贴，然后下个Sprint依然老样子。

我们花了很大的力气才把这两个会议从"仪式"变成"反馈引擎"。

1. 评审会：不是"看演示"，是"验假设"

传统的评审会是"团队演示功能，业务方观看"。但我们把评审会改成了"团队演示增量，业务方在真实数据上操作，然后给出是否能用的判断"。区别在哪里？前者是表演，后者是验证。

具体操作上，我们在评审会前准备三样东西：

1. 可操作的演示环境：不是看截图或看视频，而是让业务方亲手操作。操作过程中暴露的问题，往往比口头反馈多得多。
2. 本Sprint承诺的用户故事清单：逐条核对，完成的打勾，没完成的不打勾。不要有"差不多完成了"这个状态，B端产品的"差不多"到后面全是坑。
3. 下个Sprint的初步计划：评审完之后马上看下个Sprint要做什么，让业务方在"新鲜反馈"的状态下参与优先级判断。

这里有一个我和PingCode产品团队交流时获知的细节，我觉得非常有参考价值。他们做迭代评审时，会把评审过程中业务方提出的意见直接录入需求管理系统，标注为"评审会反馈"，然后在下个Sprint规划时作为优先级输入之一。这个动作看似简单，但却解决了"反馈说了就忘"的问题，让评审会真正连接到后续的迭代。

2. 回顾会：不是"找问题"，是"定改进项"

很多团队的回顾会是"好的、不好的、改进的"三板斧。问题提了一堆，但到下个Sprint什么都没变。

我们做的核心改动是：回顾会产生的每个问题和改进动作，都必须被写入下个Sprint的任务清单，并且指定负责人和检查时间。

举个例子，某次回顾会上，测试工程师提出："最近几个Sprint的测试用例覆盖不全，因为需求评审时我没有参与，对业务逻辑理解不够。"如果只是把这句话贴在"需要改进"一栏里，那等于白说。我们的做法是：把这个改进项变成一个可执行的任务，比如"从下个Sprint开始，测试工程师参与Sprint计划会的用户故事地图环节，作为强制要求"，然后把它挂在看板显眼位置，下个回顾会时第一个检查。

回顾会的价值不是开会那40分钟，而是会后那个Sprint里改进项到底被执行了多少。

八、多版本并行与定制化交付：B端敏捷的"地狱模式"

前面讲的是相对理想的情况：一个产品团队服务一个标准产品版本。但现实中的B端产品，尤其像PingCode这样服务中大型企业客户的场景下，通常会面临一个更具挑战性的局面：你要同时维护一个标准版本和多个客户的定制化版本，而且这些版本的迭代节奏彼此独立。

我见过很多团队在这种情况下选择了"笨办法"：哪个客户的交付压力大就先做哪个版本，结果产品版本失控，代码分支一堆，标准版本的规划被定制化项目淹没。

我们摸索出来一套相对有效的应对方式：

1. 用"产品化思维"对待定制需求

当一个企业客户提出定制化需求时，不要习惯性地直接进入开发。先做一步判断：这个需求是否能抽象为通用能力，让更多客户受益？

如果是，那就把它纳入标准版本规划，在下一个Sprint或者下下个Sprint里作为标准功能交付。这样既满足了定制客户的需求，又增强了标准产品的竞争力。如果不是，再单独评估定制开发的成本和排期。

这一步判断非常关键，因为很多看起来是"特殊定制"的需求，实际上反映了一类客户的共同痛点，只是之前没有被认真识别出来。

2. 多版本并行的迭代节奏管理

我们的做法是：标准版本保持固定的迭代节奏（如每2周一个Sprint），定制化版本按项目里程碑排期，但定制化版本的功能模块必须尽量复用标准Sprint的增量。

具体来说，标准版本的每一个Sprint产出的增量，在评审通过后会同步告知所有正在进行的定制化项目负责人。如果某个定制化客户需要的功能正好在标准Sprint里被实现了，那就直接引用标准版本，不需要再做一遍。

这种模式对技术架构有要求，需要从一开始就设计好模块化、可插拔的系统结构。但如果架构基础打得好，这套机制可以把定制化项目的交付压力降低30%以上。

九、团队文化与领导力：敏捷转型最难的一环

写了这么多方法论和实践经验，我必须坦诚地说一句：以上所有方法和工具，在一个不愿意放权的管理层和被KPI绑架的团队文化中，都不会奏效。

敏捷的本质是对不确定性的拥抱和对团队自驱力的信任。如果一个管理者每天盯着燃尽图问"为什么今天故事点没下降"，那这个团队的敏捷就已经死了。燃尽图是用来帮助团队做自我调整的信号灯，不是管理者监控效率的摄像头。

我在企业辅导中观察到一个规律：敏捷转型真正成功的团队，管理层做了三件反直觉的事。

1. 管理层对"失败"的容忍度变高了

一个Sprint的目标没完成，传统的管理反应是追问责任。但敏捷型管理者会问的是："这个Sprint暴露了什么问题？下一个Sprint我们能调什么？"两种提问方式决定了截然不同的团队心态。

2. 管理者不再直接分派任务

在敏捷团队中，任务的认领权利要交还给开发者。管理者最应该戒掉的习惯是"你来负责这个，他负责那个"。当开发者主动认领任务时，承诺感和责任感是完全不同的程度。

3. 给"重构"和"技术债清理"预留空间

B端产品迭代久了，代码里一定会积累技术债。如果不给团队专门的时间清理技术债，交付速度会从"快"变成"看起来很快实际很慢"。PingCode团队的经验是，每隔3-4个Sprint安排一个"技术改进Sprint"，专门处理性能优化、代码重构和自动化测试覆盖率的提升。短期看牺牲了功能交付速度，长期看保护了系统的可持续迭代能力。

十、从知道到做到：给你一份可执行的启动清单

如果你读到这里觉得"道理都对，但不知道怎么开始"，我最后给你一份可以直接操作的启动清单。

1. 先用一个Sprint做"试点"

选一个相对独立的产品模块或者一个明确需求的任务集，用2-3周时间按照本文描述的方式跑一个Sprint。不需要全团队推行，不需要喊口号。就用一个小组、一个模块、一个Sprint来验证"并行协作、业务闭环交付、高频业务验证"这套模式在你们团队是否有效。

2. 只关注三个核心指标

第一个Sprint结束后不要急着做全面复盘，只看三个指标：

1. Sprint目标完成率：本Sprint承诺交付的业务闭环，全部完成了吗？
2. 返工时间占比：因为需求理解偏差或技术实现方向错误导致的重做，占用了总工时的多少？
3. 业务方反馈的时效性：业务方最早在什么时候给出了关键反馈？是Sprint中间还是结束后？

这三个指标比任何"敏捷成熟度模型"都更能反映你们团队真实的敏捷水平。

3. 连续跑三个Sprint再谈流程优化

很多团队第一个Sprint跑完觉得"效果不明显"就放弃了。第一个Sprint通常是用来暴露问题的，第二个Sprint用来修正，第三个Sprint才能看到初步的改善趋势。至少跑满三个Sprint，再做是否继续的决策。

最后我想说：B端产品的敏捷，从来不是"更快地写代码"，而是"更早地发现该不该写这段代码，以及写完之后到底有没有解决用户真实面对的问题"。把敏捷当工具用，它是个框架；把敏捷当思维方式用，它才是你的生存能力。

现在，去找一个最让你头疼的需求，试着不要先想"怎么做"，而是先问一个问题："这个需求被满足之后，用户完成一项业务任务的方式，会发生什么变化？"如果你能回答这个问题，你的敏捷就已经开始了。