1. 先搞清楚敏捷里的“需求审批”到底在反对什么1.1 传统审批的机械流程为什么让人讨厌我最早接触敏捷的时候带我的老前辈说过一句特别狠的话“审批一多敏捷就死了。”当时我深以为然因为那时候团队刚从一个重型流程切过来大家对需求评审会、变更控制委员会、签字确认这些词已经烦透了。一张需求单从提出到落地要经过业务部门初审、架构组复核、项目经理审批、测试负责人确认运气好也要一周运气差直接拖到版本排期都定了。最崩溃的不是等待本身而是所有人都在等别人表态没有人真正对结果负责。后来我慢慢想明白敏捷反对的从来不是“审批”这个动作而是反对那种把审批当成“关卡”的思维方式。传统模式里审批的本质是层层设卡防止错误往下游传递。但这种方式有一个隐含前提需求在早期是可以被完全想清楚的业务方知道自己要什么技术方知道怎么做审批只是确认双方想的一致。可现实里需求本身就是一张模糊的草图早期投入再多时间去抠细节等做到一半时真正的问题才浮出来。这时候前面所有审批通过的“确定性”都会变成返工的成本。所以敏捷社区里流传的那个说法是对的与其花大精力审批一份注定要变的需求不如快速做出一个能用的东西让大家对着真实反馈调整。但这并不意味着需求审批应该被完全扔进垃圾桶。我后来的经验是我们需要区分“审批的仪式感”和“需求决策的机制”。前者要砍掉后者必须换一种更轻、更快、更透明的形态活下来。1.2 敏捷对“变更”的真实态度拥抱变化不等于无原则接受“拥抱变化”这四个字在敏捷宣言里出现时本意是欢迎需求发生合理的调整而不是让所有人都拥有随时往迭代里塞东西的权力。这一点在实际执行中经常被误解。我见过不少团队把“敏捷”当成没有流程的遮羞布产品经理随口说一句“这个很急这周得上线”研发就只能被动接受或者老板在外面跟客户喝杯咖啡回来就宣布新增一个需求所有人都得停下来改方向。这种状态的背后不是灵活而是失控。真正的敏捷变更管理应该像河道里的闸门。水需求会一直流你不能堵死但你必须有一个闸口来调节流量、方向和节奏。如果一点约束都没有看起来是自由奔放实际上很快就变成谁嗓门大谁说了算。等到迭代末期的评审会上团队才发现这个迭代既没有完成当初承诺的目标又因为临时需求引入了一堆未经验证的功能然后还要反过来责怪“敏捷不好”。我在后续项目里越来越确定一件事变更本身没问题有问题的是变更没有经过任何评估就进入了执行层。哪怕只是花五分钟讨论一下“这个需求是否比迭代里现有的事项更重要”也比完全放任要好得多。所以问题的关键不是“要不要管”而是“怎么管才不官僚”。2. 现实打脸现场完全去掉审批后团队遇到了什么2.1 需求随口加迭代目标形同虚设有一段时间我被“反审批”的思路带偏了觉得敏捷团队就应该取消所有审批环节让产品经理和开发直接对话。结果实践了不到两个迭代我就被现实狠狠教育了一顿。最典型的表现是需求池开始失控——任何人想到任何点子都可以往里丢每条需求都标注着“重要”“紧急”“客户等着”但没有人做过取舍。产品经理为了不得罪人把所有需求都排进下一个迭代导致迭代计划从两页纸变成十页纸开发看着列表都不知道从哪儿下手。更离谱的是迭代中途还会不断有新需求插进来。有一次我们正做着一个老模块的重构业务方突然说必须加一个导出报表的功能因为某个客户周五要验收。开发团队为了“让客户满意”答应了当天加班做出来。结果周五客户确实看到了报表但功能用的是临时表结构字段口径都没对齐下一周所有下游分析全乱了。这时我们才发现当初拒绝这个需求的成本可能就十分钟而接受它的成本是整个团队花了两周去擦屁股。这类问题反复出现后我开始意识到需求审批本质上是一种“价格标签”——每一份需求都应该被标注清楚代价包括它对其他事项的挤出效应。如果没有这个标签决策就会变成纯情绪驱动。2.2 验收标准缺失技术债和返工堆积没有审批还有一个隐藏副作用很多需求从提出到进入开发始终没有明确的验收标准。传统流程里评审会至少会逼着业务方把需求描述写到“可测试”的程度敏捷过度简化之后很多人觉得反正我们有小迭代、有反馈循环先做出来再调整就行。理论上是这样但前提是团队分得清“做完了”和“做好了”的区别。我参与过一个客户管理系统的改造项目产品经理口头描述了一个功能“用户登录之后要能看到上次访问的时间。”开发顺手就把这个时间存在了浏览器本地两周后客户反馈说换了设备就看不到这就闹笑话了。如果当初开会时有五分钟的审批或确认哪怕是简单问一句“这个时间是存在服务端还是客户端”都不会出现这种低级返工。后来再复盘时团队达成了一个共识每一次需求进入迭代前至少要有“完成定义”也就是能回答“怎么算做完”否则宁可推迟也不要让模糊需求进入开发。这件事让我明白审批不是目的对齐预期才是。敏捷倡导的“面对面沟通”很好但如果面对面聊完就把需求直接塞进迭代不留下任何可验证的结论那下次因为记忆偏差和对信息理解不同产生的返工会比省掉的审批时间多十倍。2.3 一次真实事故最小可行产品变成了“最小可糊弄产品”那次事故我印象特别深。团队接了一个内部工具的开发需求业务方说“给运营同事做一个数据看板能看到每天的订单量和转化率就行”。按照敏捷惯例我们快速开了一次需求梳理会产品经理画了线框图开发估算了一下工作量觉得两周能交付就直接开工了。两周后看板确实上线了从订单量和转化率这两个数字来看完全正确。但运营同事用了三天就开始吐槽不能按渠道筛选、不能看趋势曲线、刷新一下数据还会丢失筛选条件。这些需求其实早就在脑海里存在但因为没有第三个人来审查“这个最小可行产品到底能不能支撑用户完整的工作流”团队所有人都默认自己理解的需求就是全部需求。这事给我的冲击是不是所有需求都值得一视同仁地快速通过。越是看起来简单的需求越需要有人站出来问一句“这真的是一个产品闭环吗用户拿到这个功能之后能顺利完成任务而不是被半吊子功能卡住”如果没有审批和评审的约束机制团队很容易陷入自我满足的幻觉把做了一半的东西当成完整交付。那次之后我给自己定了一条规矩凡是进入迭代的需求必须有一个明确的“验收人”验收人必须来自需求提出方而不是开发团队自说自话。3. 我在实践中调整出的轻量审批与变更管理方案3.1 分层次审批不是所有需求都要开会踩过坑以后我重新梳理了一套需求审批的轻量做法核心原则就是审批力度要和需求大小与风险程度匹配。我把需求分成三类。第一类叫“顺手变更”。比如界面按钮文案调整、字段提示语优化、颜色对齐这类不改变核心业务逻辑、不影响数据结构、工作量在半天以内的需求。这类需求完全不需要正式审批产品经理确认一下开发直接在最近的迭代里顺手做掉就行。真正合理的做法是给它一个低成本通道比如需求池里打上“小改进”标签月底统一回顾是否有遗漏。第二类是“常规需求”。工作量在一个人日到一周之间涉及某个模块的功能逻辑或界面结构变化需要产品经理、开发负责人、测试负责人三方对齐。对齐方式不一定是开会我在远程团队里试过直接在协同卡上写清楚“为什么做、为谁做、怎么做、怎么验收”四个人留评论也可以完成一次有效审批。第三类是“战略级需求”。比如重构核心模块、改变数据模型、引入新技术的需求这类需求会直接影响项目的架构稳定性必须升级到项目核心小组评审。评审不追求走完整套文档流程但一定要有决策记录至少回答清楚“做这件事的收益是什么、不做会怎样、有哪些替代方案”。这个分类看起来简单但执行起来非常考验团队默契。关键是把“审批级别”的判定规则白纸黑字写下来贴在项目看板旁边让所有人都能对号入座。否则就会出现产品经理觉得是“顺手变更”技术负责人觉得是“战略级需求”的扯皮。3.2 变更管理的关键是“单点进入、快速裁决”迭代中途的变更管理我不推荐搞一堆繁文缛节但必须守住两条线一条是入口统一另一条是出口明确。入口统一的意思是所有变更请求都必须在需求池里登记不管你是总经理临时安排工作还是客户发来的紧急邮件谁提了需求都由产品经理作为唯一入口接收和登记。如果变更没有进池子相当于偷渡开发不能接受任何口头交付的任务。我见过很多团队坏就坏在“老板直接找程序员聊需求”程序员碍于面子不好意思拒绝结果做了半天发现产品经理根本不知道这件事排期全乱了。出口明确指的是变更申请需要在短时间内给出裁决结果。我采用过一个“十五分钟裁决”策略每周安排十五分钟给产品经理和开发负责人专门处理当周的变更请求。能当场决定的当场决定不能当场决定的挂起来下次评审再议。这样就可以避免两个极端一个是所有人每天都在开变更会另一个是变更拖到迭代结束才被汇总。这个快速裁决机制还有一个妙用它会倒逼提出需求的人想清楚再说。因为裁决时会问“你要解决什么问题”很多原本张口就来的人一旦要面对追问就会自己发现自己其实没想清楚。这就是审批的筛选价值。3.3 把审批做成协作工具而非控制工具我做了一段时间之后最大的体会是需求审批和变更管理的本质不是控制别人而是帮助团队形成一种共同的判断能力。如果方案设计得像一个关卡游戏每道审批都只是等某个负责人点头那团队就会产生“反正有人会把关”的依赖心理质量反而下滑。所以我后来在设计流程时刻意把“审批”改名为“需求确认”把“变更申请单”改名为“变更输入卡”。名称变化背后是心态变化要大家不是去通过一扇门而是共同评估一件事是否值得做。比如我在变更输入卡里放三个问题给谁带来什么价值不做会怎样需要谁配合当提出需求的人把这三个问题都填完他自己大概率就能知道这个需求该不该提。这种方法还有一个额外好处让审批记录变成了团队的知识库。几个月后无需翻聊天记录直接看历史输入卡就能看到当初为什么做了某个功能为什么拒绝了另一个需求。这些信息对复盘和培养新人非常有价值追问“当初为什么不支持这个方案”时也更容易还原决策时的约束条件。4. 实操要素拆解五个关键问题的处理4.1 谁有权说“不”角色与职责其实可以很轻很多团队一谈审批就头疼因为不知道让谁拍板。我的经验是不要把拍板权集中在某个头衔上而是根据需求类型分配。常规功能需求由产品经理和开发负责人共同签字任何一方的“不通过”都会让需求打回去重新细化没有人拥有单方面强推的权力。技术架构类变更必须在技术小组里达成一致哪怕团队里技术最强的架构师也不能一个人说改就改。这个设计确保的不是“防止错误”而是“防止一言堂”。决策是团队的事虽然可能慢一会儿但它会让后续的执行阻力小得多。因为开发者参与过决策一旦决定做了他就知道自己不是在执行别人的命令而是在完成共同的选择。4.2 优先级变更的联动从需求池到迭代计划的闭环需求审批最大的失败是批完之后谁不记得它被批过。流程必须闭环到迭代计划里。当一个需求通过了审批它的状态会变成“待排期”下一轮迭代规划会把它和现有需求放在一起比较优先级。优先级的比较不是靠“谁喊得响”而是靠一页纸的评分标准。我惯用的标准是三个维度业务收益对客户或收入的影响、成本工作量和技术风险、时效性不做会错过什么节点。三项综合打分分数高者优先进入迭代。这个评分过程本身就实现了二次审批即使某需求在第一轮通过了概念审批如果它在排期时分数垫底依旧可以不安排。所以优先级公式的每一环都需要解释不能拍脑袋打分。业务收益要让产品经理解释给谁带来什么价值成本要让开发估算工作量并拆出风险点时效性要让提出者说出具体时间窗口。这样一轮排期下来不是只有“批不批”两个结果还有“这个阶段要不要做”的权衡。4.3 记录留痕的尺度轻文档与电子卡的平衡很多研发人员讨厌文档但不代表可以彻底不记录。我这里的经验是把所有审批信息塞进一张任务卡片而不是写成一篇正式文档。每张卡上有几个字段需求描述、价值说明、影响范围、验收标准、审批结果、审批人。全部信息不超过一屏滚动一下就能看完。轻文档的关键是要精简字段并且强制填写。字段多到一定数量大家就会开始敷衍。所以我一直在试最小集需求描述一句话、验收标准可勾选条目、变更理由如果是从旧版改来的。其他信息比如项目背景、用户画像放到引用链接里点击就能看到不需要每次都复制粘贴。留痕的作用不仅仅是为了追溯。我常用一个场景是当某件事出了故障大家第一时间翻卡里写的验收标准往往能当场发现标准和实现严重不对齐。这比任何复盘会议都管用。5. 常见问题与避坑指南5.1 要不要保留正式变更控制委员会小团队完全不需要。我在二十人以下的项目里看到变更控制委员会反而拖慢节奏因为决策人不在场开会还得凑时间。更好的做法是“委员会职能虚拟化”也就是把审批权分散在几个固定的角色组合里产品、开发、测试三个人线上碰头处理日常变更。到了大型项目或者牵涉跨系统联调时才需要临时升级成正式评审小组但即使这样开会的频率也应该控制在每两周一次以内。5.2 如何处理紧急需求插进来紧急需求是敏捷项目最大的压力测试。我的原则是评估紧急等级不要看提需求的人有多着急而要看这个需求不做的商业后果。提供一份“紧急插单申请表”字段特别简单能证明紧急的具体事实、截止时间点、若不做的后果。只要填了这张表就有权利插队。但插队是有代价的代价就是原计划里的某些事项会被移出这个迭代。产品经理需要明确说出哪个任务被替代了并且至少要获得开发负责人的确认。这样紧急需求虽然是“单点快速进入”但它并不是免费的它在流程层面占用的资源会被显性暴露。5.3 工具选型与流程落地工具不是核心流程才是。无论用哪款协作平台只要能把需求池、迭代看板、变更记录放在同一个可视空间里基本都能支撑这套方案。需要特别注意的是不要试图在一个工具里塞入所有规则。规则写太多了团队就会靠记忆力执行结果必然是流于形式。我最后补充一个建议如果要引入这套轻量审批方案第一件事不是设计文档而是挑两个真实需求跑一遍。一个跑常规流程一个跑紧急变更一边跑一边调整规则这样试行一两周就能形成团队自己的习惯。你不需要把它变成全公司标准的流程再造只要在你的团队里解决问题就好。我刚把这套做法落地的时候团队里反对声最大的竟然是研发他们觉得这是在走老路。但跑了三个迭代后跟我抱怨最多的也是研发——他们说“以后再也不要让任何需求不写验收标准就进来了。”需求审批和变更管理其实就是这样它们不是敏捷的敌人而是让敏捷真正可持续运行的安全带。你要的应该是自由奔跑而不是翻滚之后浑身是伤。