★ FEATURED ARTICLE 1. 先搞清楚敏捷到底在反对什么前不久一个做金融系统的团队在迭代计划会上吵了起来。产品经理临时提了一个需求说要加一个“资金流水导出”的按钮开发组长立刻跳出来反对“Sprint 都已经排满了这是加塞”两个人把目光投向 Scrum Master问题抛出来敏捷不是说拥抱变化吗怎么现在连加个需求都要扯皮更讽刺的是项目组之前刚砍掉了所有审批流程说是“敏捷就不需要那些重型管理”结果两个月后需求散了一地。这个场景我相信很多团队都经历过。在敏捷转型的过程中关于“需求审批”和“变更管理”的争论几乎是从第一天就开始了。有人搬出敏捷宣言说“响应变化高于遵循计划”所以审批这种东西是瀑布时代的遗物也有人认为如果没有审批需求会失控项目会变成一锅粥。两边都有道理但两边都没说全。我个人的看法是敏捷中不但需要需求审批和变更管理而且比传统项目管理更需要——只不过它们的形式、时机和粒度必须彻底改变。还是那句话敏捷要的不是“没有管理”而是“另一种管理”。为了说清楚这个问题先回到敏捷宣言本身。宣言里有这么一句“响应变化高于遵循计划”。请注意这句话并不是“不要计划”而是“响应变化比死守计划更有价值”。换句话说敏捷承认计划是必要的但计划不能被当成铁板一块。它需要一个能吸收变化的机制。但问题在于很多团队把这句话理解成了“变化就是对的来了就要接”。这就矫枉过正了。我见过一个团队产品经理在Sprint第三天临时加需求开发说不排了产品经理说“敏捷就是拥抱变化啊”开发没话说只好把需求往Sprint里塞结果原来的任务被挤压两个故事点没完成到了Review的时候又有一堆新想法冒出来。一个Sprint下来团队感觉自己什么都干了但什么都没交付干净。所以我一直强调一个观点敏捷反对的是“僵化的前期大审批”而不是“任何形式的审批”。这两件事看起来差不多实际差别很大。前者的特征是需求一次性收集齐全层层签字确认变更需要走一套十几个人的流程耗时一周后者的特征是需求分批进入每次只评价未来一两周的输入变更走轻量级但明确的判定过程不卡流程但卡标准。举个生活中的例子。家里做饭从来不搞“审批”但你真的会早晨起床之后打开冰箱看看里面有什么、什么食材快坏了、家里几个人吃饭然后才决定做什么菜。这个决策过程其实是隐形的“审批”或“变更评估”。不做这个评估直接看到什么就炒什么就会做出四菜一汤全是蛋的悲剧。软件开发也是这个道理不搞审批不代表不评估而是把评估变成了日常的一部分让它无处不在却几乎不花额外的时间。理解了这一点再来看敏捷中的需求审批和变更管理就不会再陷入“要不要”的二元争论而是思考“用什么形式、在什么粒度上做”的问题。接下来的篇幅我会从需求审批的重新定义、变更管理的节奏控制、真实案例复盘、日常落地工具四个维度逐一展开。2. 重新定义需求审批从“关卡”变成“闸门”2.1 传统需求审批为什么在敏捷里失效传统项目管理中需求审批通常是关口式的业务方提出需求分析师写文档管理层评审签字开发照着做。这个模式背后的假设是需求在进入开发之前就能被完全理解并且变化不常发生。这个假设在几十年前的环境下也许成立但在今天几乎不可能。现代产品的竞争环境变化太快。今天的用户反馈、明天的竞品动态、后天的法规要求都会让需求发生偏移。在这种情况下如果在入口处花大量时间把需求“审死”那交付的其实是半年前的理解而不是当下的真实需求。这就是快速失败的前提需求本来就是逐渐清晰的。那是不是说敏捷就不能审了当然能只是要换一种方式。我觉得对敏捷团队来说真正有效的需求审批更像核电站的反应堆闸门而不是海关安检口。海关安检的目标是“不放一个坏人进来”所以严格、材料多、周期长核反应堆闸门的目标是“在安全条件下让反应持续进行”它检查的不是“对不对”而是“是否具备进入下一阶段的必要条件”。对需求来说审批的重心不应该放在“这个功能要不要做”上——那是产品负责人的职责更不应该放在“这么做对不对”上——那需要市场和时间来检验而应该放在“这个需求是否准备得足够充分能否进入开发流程”上。说得直白一点敏捷要审的不是方向而是质量。2.2 三层过滤器把审批拆成日常动作那具体怎么做我比较推荐的方式是把需求审批拆成三个层级对应不同的时间点和参与人员。第一层是入口校验发生在需求进入产品待办列表之前。这个环节主要看三件事用户故事是否足够清晰、验收标准是否已经定义、依赖关系是否明确。如果这三点都做不到说明这个需求还只是“拍脑袋的想法”需要回去打磨而不是直接排期。这一层通常由产品负责人和专业负责人共同完成。它不是正式会议可能只是在看板前的五分钟对话。第二层是准入评审发生在Sprint计划会之前。这也是最接近传统“审批”的环节但它的粒度已经大幅缩小。团队不再看三个月的完整需求列表而是只看接下来一到两周要做的内容。评审的重点是这个故事是否可估、是否有足够的技术准备、是否在这个迭代内能够完成并交付。如果答案是肯定就放入Sprint如果是否定就继续留在产品待办列表里不强行塞入。第三层是退出确认发生在Sprint结束的评审会上。三层过滤之后的需求即使进了开发也可能因为过程中的变化而发生偏差所以在交付前团队需要和干系人确认现在交付的内容是否仍然是当前最有价值的东西。如果发现不如预期那这也是某种意义上的“审批没通过”需求要么裁剪要么退回待办列表要么直接砍掉。这三层过滤器的好处是没有哪一层需要召开一场“隆重的大会”也没有哪一层需要跑一个复杂的工作流。但它确实构成了一个完整的闭环入口把关、准入把关、退出把关。这带来的价值非常大因为需求的质量是从进入队列之前就开始管控的而不是等到开发完才发现“这不是我们想要的”。2.3 入口校验的具体操作用户故事检查清单很多人说入口校验太虚落地不了。其实不是只是大家习惯了口号式管理不习惯把它落到具体的清单上。我自己在实践中整理了一份检查清单每次新需求进入产品待办列表之前产品负责人至少要过一遍这几条用户故事是否遵循“作为…我希望…以便…”的格式。这个格式不是为了仪式感而是强制让需求提出者站在用户角度而不是站在功能列表角度去描述问题。如果一个需求写的是“增加导出按钮”那它不合格而如果写的是“作为财务人员我希望按月导出流水以便对账”那它至少捋清了用户、动作、价值三个要素。验收标准是否写了“可测试的”内容。很多人会把验收标准写成“功能正常”“体验良好”这没法验证没法验证的需求进入开发就是埋雷。我个人比较推荐一条标准对应一个可观察的行为比如“点击导出后生成CSV文件文件名包含当前月份”。是否明确定义了依赖关系。这里的依赖包括两类一类是外部依赖比如是否依赖其他团队提供的接口、设计资源、运营排期另一类是内部依赖比如这个需求拆出来的子任务是否和当前Sprint里其他任务冲突。依赖不明说必然会在Sprint进行中爆炸爆炸的时间通常恰好在容量已经排满的那一天。如果这三条里有任何一条不满足那这个需求绝不进入待办列表更不进入Sprint。这个标准可以不成立文但一定要在团队中形成共识。让它成为团队文化的一部分而不是挂在墙上的“流程文档”。3. 变更管理的核心不控制变化而控制节奏3.1 变更管理到底在管什么很多讨论把“变更管理”理解成“限制变更”这是最大的误区。敏捷产品开发中变化不是敌人无法预测的变化才是。如果产品负责人能准确预判两周后用户会喜欢什么那就不需要敏捷了——直接把需求一次性写清楚不香吗所以变更管理的真正目的不是遏制变化而是为变化建立一个稳定的进入通道让变化在可控的节奏下被吸收而不至于把Sprint变成“无限加塞商店”。你可以把Sprint想象成一条高速公路如果一个入口随时开放随时有车插进来整条路的效率就完蛋了。变更管理要做的是划定入口、规定频率、明确条件而不是彻底封路。那什么样的变化允许在Sprint内进入什么样的变化必须等到下一个Sprint呢我常用的衡量标准是按“距离目标Sprint结束的天数”和“影响的用户故事数量”两个维度来划分处理策略。如果变更发生在Sprint开始后的一两天而且影响范围非常小比如只是调整某个按钮的文字、修改某个字段的校验规则那直接纳入当前Sprint是合理的。因为这时候团队还在热身阶段技术上下文还没完全切换到这轮任务上插入的边际成本最低。如果变更发生在Sprint的第三天到第五天影响中等比如要替换掉一个正在开发的接口那就不建议直接塞进去。更合适的做法是先评估如果当前Sprint还有未交付的冗余容量就和团队商量把低优先级的待办任务交换出来。记住是“交换”而不是“增加”。Sprint的时间盒是固定的放进一个新故事的同时必须移出一个同样规模的故事否则就是在透支团队的精力。如果变更发生在Sprint的后半段尤其是评审会前一两天除非是生产事故级别的问题否则一律推到下一个Sprint。这样做不是冷漠而是尊重团队已经投入的工作量。在一个马上就要展示成果的节点上突然改方向通常会造成已经完成的任务推倒重来团队挫败感爆棚效率急剧下降。3.2 变更卡一条流水线的轻量规则在具体操作上我比较推荐引入一个非常轻的机制——变更卡。跟传统变更管理委员会那种长流程不一样变更卡不是用来“审批”的而是用来“记录决策轨迹”的。它的核心是让所有Sprint内的变更被看见、被量化、被讨论而不是偷偷摸摸地发生。变更卡的字段不需要多我觉得五六个就够了变更标题、提出时间、提出原因、涉及的用户故事编号、预计影响的故事点数、决策结果。当一个新需求在Sprint内被提出时产品负责人填写这张卡开发团队评估影响然后共同决定直接纳入当前Sprint、与某个现有任务交换、还是推迟到下一个Sprint。这个机制的价值有三个层面。第一它让变更显性化避免“口头确认”带来的后遗症。我见过很多团队产品经理在工位上说“这个需求加一下”开发口头说“好”结果Sprint评审会时发现多做了三个需求但板子上没有任何记录。这时候说得好听点叫“高效响应”说得难听点叫管理失控。变更卡只需要两分钟但杜绝了这种模糊状态。第二它让变更的成本成为一个可讨论的话题。每次变更团队都必须评估故事点的影响这会让需求提出方慢慢意识到变更不是免费的。引入一个故事点通常意味着从现有范围内踢掉一个故事点这样才能维持Sprint容量的平衡。这个意识一旦建立产品经理提需求时自然会更加谨慎而不是“先提了再说”。第三它为复盘提供了数据。一个Sprint结束翻一翻这轮产生了多少张变更卡、为什么产生、哪个阶段产生的能非常直观地看到团队的需求稳定性、干系人的协作质量以及产品负责人对业务理解的深度。这些都是传统变更管理做得很重却从不复盘的问题。3.3 和产品负责人以及干系人的对表机制再好的变更管理机制如果干系人不认那就是摆设。我曾经参与过一个项目业务方特别强势周一提需求周三就问“为什么还没做完”。后来我拉着业务方代表开了一次会没有讲什么复杂理论就做了两件事。第一件事请他们看团队过去三个Sprint的真实交付数据。每周团队平均能完成的稳定产出大概是二十八到三十二个故事点而业务方在这三个Sprint里提出的需求如果全部纳入相当于每周要消化四十个点以上。数字摆出来不用我多说一句对方自己意识到“我的预期不太现实”。第二件事我们把“变更窗口”定义清楚。我告诉对方你可以在任何时间提出任何想法这件事我们鼓励但要让它变成Sprint里的正式任务它必须通过变更卡评审并在“不增加团队总容量”的前提下来做。您可以决定优先级可以决定拿哪个故事交换但您不能决定Sprint的容量——因为容量是由团队的客观交付能力决定的。这种对表机制非常关键。大多数干系人之所以抵触变更管理不是因为他们真想搞垮团队而是因为他们从未被清晰地告知“这个流程对双方都有利”。一旦他们发现提出想法不会被压制只是在进入开发前有一个优先级和容量的明确讨论他们的抵触情绪会大大降低。4. 案例复盘审批过严与完全放开的一线实录4.1 案例A审批过严团队被流程捆住手脚先说一个反面的例子。某公司内部有个系统组负责建设一套内部数据报表平台。项目启动时公司层面定的调子是“这是重点项目需求必须层层审批”于是他们设置了一个由部门负责人、业务代表、架构师组成的评审委员会所有需求在进入迭代之前必须开一次至少两小时的评审会评审通过才能进入开发。听起来很正规对吧但实际跑起来问题层出不穷。首先是节奏问题。业务方提需求的时间不固定评审会却是一周只有一次于是所有的需求都被迫积压一周进入开发时的信息已经有些旧了。其次是粒度问题。委员会成员为了体现自己的价值开始抠字眼这个字段叫什么名字要管按钮放在左边还是右边也要讨论。一个仅仅“查询导出功能”的需求评审会硬是开了三轮改了四版原型。结果就是两个月过去了团队只交付了两个报表页面业务方等不及自己用Excel解决了报表平台沦为一个谁都不想用的“半成品”。这个案例的问题在于审批变成了项目流程的目标而不是确保开发质量的手段。需求审批本身没有错但在这个项目里它被设计成了“多一层人为过滤”的部门墙而不是“质量闸门”。每一次审批都在消耗团队的响应速度却并没有让需求变得更清晰。它反而在鼓励一种氛围能拖就拖反正最后会有评审会帮忙把关。4.2 案例B完全放开Sprint变成“市场大集”再看另一个极端。某个移动端App项目团队为了彻底贯彻敏捷精神把所有的审批流程全部砍掉。他们说“我们要拥抱变化”所以只要产品经理在群里提需求开发就无脑接单。第一个月大家还挺开心觉得终于没有流程束缚了。三周后问题开始显现。Sprint内不断有新任务插入每次插入都带来两条副作用一是当前任务被搁置上下文切换让开发效率直降一半二是原本排好的任务被推到了下一个Sprint但没人跟进这些被推迟的任务是否还有人关心。到第二个月结束时产品待办列表膨胀到八十多条其中三分之一是没有验收标准的“半成品需求”还有一部分是同一个需求被反复改换了三种描述方式。更严重的是团队心态崩了。开发人员发现自己永远无法“做完”一个需求因为需求一直在变评审会上展示的永远不是“最完美的版本”而是“目前临时拼凑的版本”。于是很多人开始在开发前主动加“自我保护性设计”把代码写得极具扩展性——这本身不是坏事但过度设计消耗了比原本需求多出两倍的工时。整个团队陷入一种忙碌但低效的状态。这个案例说明没有变更管理的敏捷等于把“拥抱变化”理解成了“没有原则地吸收变化”。实际上敏捷宣言里的“响应变化”指的不是“临时插入需求的能力”而是“快速调整方向的能力”。这两者的区别在于后者也要求团队先明确当前的方向然后评估新方向是否更优再做出决策。如果连评估和决策都省略那响应变化就成了一句空话。4.3 从两个案例看管理边界把两个案例放在一起看你会得到非常清晰的管理启示。审批过严的团队问题出在把关环节的粒度太粗把一切都看成需要审批的对象最终把整个系统压到瘫痪而不审批的团队问题出在把“不审批”本身当成目标忽略了敏捷中本来就需要的轻量治理。我后来在这两个团队中都做了类似的调整效果不错核心思路一致把审批和变更管理从“正式流程”降维成“日常活动”。不需要开大会、不需要走系统流程只需要在一个白板前用十分钟说清楚“这个需求准备好了吗”“这个变更要不要进这轮迭代”。管理还在自觉还在但整套系统运转的速度和灵活性也还在。5. 落地实操一套可以直接照搬的轻量机制5.1 日常工作流中的三层过滤器怎么跑前文提到三层过滤器这里给出更贴近实操的落地细节方便团队直接参考。入口校验不要做成线下审批单建议直接在需求池看板上建立一列“待精化”。产品经理的每一项需求必须先进入“待精化”经过自己和相关开发人员的初步讨论补充完用户故事、验收标准、依赖关系之后才能拖到“产品待办”。这一步不需要开会也不需要签字它只是看板上的一个进度标识。但如果你发现某项需求在“待精化”里放了两周还未有人问津说明它根本没有准备好更不该进入迭代计划。准入评审利用Sprint计划会的前半小时完成。常规的计划会通常是一大段如果团队想保持敏捷节奏我建议拆成两个环节第一个环节叫“待办梳理”只做排序和澄清不讨论技术方案第二个环节叫“行动计划”只做工作量估算和任务拆分。入口校验的完成度可以从“待办梳理”里直接看出来如果故事不清晰开发无法估算那就不会排进Sprint这个机制天然强迫产品经理提高需求的“精化度”。退出确认放在Sprint评审会上但不是让干系人说“这个功能好不好使”而是让他们回答“这个功能解决了你原本的问题吗”。听起来差不多本质区别在于前者是满意度评价后者是价值验证。如果干系人回答说“问题已经不存在了”这正是敏捷想要的反馈——我们的需求可能成功了也可能是过时了但无论如何团队都获得了宝贵的真实信息。5.2 变更卡的模板与操作步骤变更是必然发生的所以重点不是禁止它而是让每个变更都留下轨迹。具体操作时可以在物理看板或者电子看板上专门划出一个“变更卡区”当Sprint内有人提出新需求时团队执行以下五步第一步是记录把变更需求写到一张变更卡上注明提出时间、发起人、业务背景。这里不要内容太多两到三句话把事情说清楚即可。第二步是评估由相关开发人员给出一个相对粗略的故事点和影响范围估算。不用特别精准粗略即可因为此时我们只是判断“它能不能塞进当前Sprint”不是做详细的任务拆分。第三步是比较把变更卡的估算结果和当前Sprint中优先级最低的那张卡放在一起比较。如果变更卡的故事点小于或等于最低优先级那张卡就具备了交换的条件如果大于那就不能直接塞必须另行讨论。第四步是决策团队和产品负责人共同确认。这里没有“试试看”的说法决策要么进、要么不进。如果进必须同时移出另一张卡确保Sprint总点数不变如果不进写明原因放入产品待办列表进入下一个迭代计划。第五步是复盘Sprint结束后所有变更卡汇总到回顾会。看看变更产生了多少、集中在哪几天、主要原因是什么。这个复盘不是为了追责而是为了发现模式。比如某个业务方的需求总是缺细节、某个模块的技术评估总偏乐观这些模式被识别后团队就可以在源头上做改进。5.3 实战中常见的三个问题与应对策略第一类常见问题“产品经理觉得变更卡太麻烦拒绝填。”这种情况在空降产品经理身上尤其常见。解决办法不是强调流程而是展示变更卡对产品经理本身的价值。我通常会把上一个Sprint因变更失控而返工的账单列出来因为没走评估团队多花了多少工时导致哪些需求没有交付。等产品经理看到数字通常就不会觉得“两分钟填卡”是很重的负担了。第二类常见问题“干系人绕过团队直接找开发加上去。”这种情况非常糟心但并非无解。我建议团队约定任何开发者在被直接交付需求时都可以行使一次“暂缓权”——也就是说“我现在不能直接接下请通过产品待办列表”。这个暂缓权不是不做事而是把需求导入到一个能让团队集体决策的通道里。这个能力需要在团队内部形成文化也需要每个开发人员自己坚持。第三类常见问题“按这个流程走会不会太慢丢了敏捷速度”我理解这种担忧但实际操作下来真正浪费时间的从来不是“十五分钟评估”而是“需求做错后返工的一周”。敏捷的速度来自减少返工而不是减少决策。这个道理就像导航软件一样导航每次重新规划路线只需要一两秒但不重新规划路线的后果就是开进一个死胡同然后要多开几十分钟才能绕回来。5.4 常见问题速查表问题场景处理建议注意事项新需求在Sprint第一天提出如果故事点较小可直接纳入必须同时移出一张低优先级故事卡新需求在Sprint中后期提出一律进入产品待办列表除非是生产事故否则不打断当前Sprint需求缺少验收标准不放行到开发回到“待精化”列补完再进干系人绕过产品经理直接找开发开发行使用“暂缓权”不硬冲突先记录再开会讨论变更卡频繁出现在Sprint末期视为需求精化不足的信号在回顾会上分析根因不追责个人产品负责人希望扩大Sprint容量用历史速率数据对话容量由团队能力决定不受意愿影响需求审批变成“反复开长会”拆成三层过滤器每层会议控制在十五分钟以内需求做完后发现方向错了强化退出确认环节评审会聚焦“是否解决原问题”而非“功能是否顺手”一些写在最后的经验我见过很多团队从最初的“要不要审批”之争一路走到成熟的轻量治理模式。他们的共同特点是把审批和变更管理从“管控工具”重新定位成了“学习工具”。需求审批不是为了限制创新而是为了确保每个想法在被执行前团队都对它有足够清晰的理解变更管理不是为了拒绝变化而是为了让变化能够在一个稳定节奏中被评估、被吸收、被复盘。如果你所在的团队正在纠结“敏捷下还要不要需求审批和变更管理”我的建议是不要问“要不要”而是问“现在的做法帮助还是阻碍了价值交付”。这个问题一旦被回答清楚答案自然就出来了。审批和变更管理本身从来不是问题官僚化和失控才是。而这个问题的解法从来不在流程表单的多少而在团队是否真正理解了敏捷背后的价值观持续交付价值并且尽可能快地学习。
阅读完成 · 觉得有帮助？
