敏捷看板贴满墙，效率反而低了

一、先给结论：看板贴满墙不是敏捷，是集体焦虑的物理投影

做了十五年研发管理，我见过最荒诞的一幕，是在某家中型科技公司的会议室里。三面墙贴满了彩色便利贴，粉的是需求，黄的是开发中，蓝的是测试，绿的是已完成。产品负责人骄傲地跟我说：“你看，我们敏捷做得多彻底。”我问他一个问题：“上个月贴上去的这37张粉色卡片，现在还在原地，你们有人看过它们第二眼吗？”他愣住了。

这就是我想说的核心结论：当看板从“思考工具”变成“展示工具”，效率不但不会提升，反而会出现一种隐性的、系统性的衰退。这种衰退不体现在某一天的站会上，也不会在某一周的燃尽图里暴露出来。它像慢性病一样，蚕食着团队的决策质量、响应速度和成员的心理能量。更危险的是，管理者往往因为墙上花花绿绿、站会每天都开，产生一种“我们正在高效运转”的错觉。这种错觉我称之为“敏捷致幻”，流程跑得越完整，离真正的效率越远。

我并不是在否定看板本身。恰恰相反，我服务过的团队里，看板用得好的人和用得糟糕的人之间，效率差距可以拉到三倍以上。问题从来不是出在那张墙上，而是出在贴卡片的人心里。接下来的内容，我会把我这些年踩过的坑、观察到的规律、以及反复验证过的判断逻辑，完整地拆给你看。

二、场景还原：一张典型的“表演型看板”是怎么养成的

如果你现在走进一个正在“做敏捷”的研发团队办公区，十有八九你会看到这样一幅画面。墙上钉着三四排彩色卡片，每张卡片上写着诸如“用户登录优化”、“订单详情页改版”、“后台权限重构”之类的标题。卡片被整齐地排列在“待办”、“进行中”、“已完成”三列里。每天早上九点半，七八个人站在这面墙前，轮流说昨天干了什么、今天要干什么、有没有遇到障碍。整个过程持续十五分钟，然后大家散去，各回工位。

这套流程，从形式上挑不出任何毛病。Scrum Guide里怎么写的，他们就怎么做。但我告诉你，这套流程跑三个月之后，通常会出现以下现象：

• 已完成列爆满，但产品经理仍然在喊“需求没做完”。因为那些被移到“已完成”的卡片，往往只是开发自测通过，根本没有经过真实用户的验证。
• 站会变成了对领导的述职会。每个人说“我昨天做了什么”的时候，眼神不自觉地瞟向Scrum Master或者技术主管，下意识地在“汇报工作”而非“同步信息”。
• 卡片的粒度越来越细。一个本来可以两天搞定的功能，被拆成六个子任务，每半天移动一张卡片，制造出一种“流转很快”的视觉假象。
• 瓶颈卡在那儿一周没人碰。测试列的卡片越积越多，但没有人站出来说“我们需要暂停开发、集体支援测试”，因为看板上没写这条规则。

这些现象背后，指向同一个本质：团队在用维护看板的动作，替代真正的协作和思考。卡片多、移动快、站会准时，这些显性的、容易被观察到的指标被管理者当作“敏捷做得好”的证据。而那些隐性的、真正决定效率的指标，比如需求从提出到上线的总周期、每周被废弃的无效需求比例、跨角色之间的等待时间，反而没人关注。

这个过程不是一夜之间发生的。它通常是渐进式的。最开始，团队是真的在用看板做协同。但某一次，老板路过办公区看到墙上的卡片，随口夸了一句“不错”，Scrum Master受到了激励，开始把看板维护得更漂亮。某一次，PMO来检查敏捷落地情况，团队把看板整理得整整齐齐以通过评审。某一次，一个新成员加入，老成员教他“我们每天早上站会就是这样开的”，而没有人告诉他为什么要这样开。久而久之，仪式留下了，灵魂走丢了。

三、拆解三个最常见的认知误区

1. 误区一：把“可视化”等同于“透明化”

这是最要命的一个误会。很多敏捷教练在推看板的时候，最爱说的一句话是“让一切可视化”。这句话本身没错，但它的潜台词被很多人理解成了“把东西都贴出来就万事大吉”。于是团队开始疯狂往墙上贴东西：需求卡、任务卡、风险卡、依赖卡、技术债卡……贴到后来，墙上密密麻麻全是信息，反而没人能一眼看出重点在哪里。

可视化的目的是降低认知负荷，而不是增加信息密度。一面贴了超过五十张卡片的墙，和一份五十页的Word文档在信息过载这个维度上没有本质区别。真正的透明，不是把原始数据全部摊开，而是把关键信号从噪声中提取出来，让团队能在三十秒内判断出当前最大的风险在哪里、最需要协作的环节是哪一个。

我见过一个极端案例。某个团队把看板做成了一个“信息黑洞”，卡片上写满了各种缩写、编号、技术术语，非本团队的成员站在墙前根本看不懂。团队内部倒是对此颇为自豪，觉得这体现了“专业性”。结果有一次，测试负责人休假三天，回来之后发现自己在测试列有五张卡片被“退回开发”，而退回理由那一栏写的是“参照TAPD-3342号缺陷描述”。她花了整整一个上午，才搞清楚这五张卡到底发生了什么。这不是透明，这是在用看板制造信息壁垒。

2. 误区二：把“流转速度”当作“交付效率”

燃尽图是一条平滑向下的曲线，迭代评审会上产品负责人点头说“完成得不错”，所有人看着趋于零的剩余故事点松了一口气。但上线两周后，用户投诉接踵而至，数据埋点显示新功能的日活转化率还不如老版本。

这个场景你应该不陌生。它的根源在于：团队在用一个“研发内部的效率指标”去衡量“用户侧的交付价值”。卡片从“待办”移到“已完成”，只代表开发人员写完了代码、自测通过了、代码审查过了，但不代表这个功能真的解决了用户的某个问题，甚至不代表这个功能被正确地部署到了生产环境。在很多传统企业的IT部门，“已完成”只意味着“提交到发布分支”，至于什么时候真正上线、上线后效果如何，那是另一个团队的事，和看板无关。

我自己在带团队的时候定过一条铁规矩：任何卡片只有在生产环境经过48小时无重大故障、且对应的业务指标有可观测的正向变化之后，才允许被移到“已完成”列。这条规矩一开始被团队骂得要死，大家觉得这拖慢了流转速度，让燃尽图变得难看。但坚持了两个月之后，显著的变化发生了，团队开始主动思考“我这个功能上线之后到底怎么验证”，开发人员会在编码过程中就找产品经理确认埋点方案，测试人员会在测试用例里加入业务指标的检查项。流转速度确实从平均每天移动2.1张卡降到了1.4张卡，但有意思的是，产品经理反馈的“真正解决用户问题的需求比例”从不到40%上升到了超过70%。

3. 误区三：把“站会”当成“同步会”

每日站会的标准话术模板是“昨天做了什么、今天要做什么、遇到了什么障碍”。这个模板本身的设计意图是好的，但它有一个致命的漏洞，它天然地把对话焦点引导到“个人做了什么”上面，而不是“作为团队我们接下来该做什么”。

当一个成员说“我昨天完成了订单模块的接口开发”时，其他人的大脑自动进入“与我无关”的模式。因为这不是一个需要他们响应的问题，这只是一条状态信息。十五分钟的站会，八个人轮流汇报，每个人说一分半钟，信息量是充分了，但交互量几乎为零。Scrum Master把每个人说的内容记下来，更新到电子看板上，站会结束，大家解散。这不是站会，这是人肉进度条。

我后来做了一个小实验。我把站会的要求改成：每个人不许说“我昨天做了什么”，只能指着看板上的某张卡片，说“这张卡现在卡在哪里”、“我需要谁帮我把这张卡推到下一列”、“今天有没有外部依赖可能阻塞这张卡”。效果立竿见影。站会时间从十五分钟压缩到了八分钟，但实际产生的协作请求数量翻了将近三倍。因为每个人的发言都成了一个“请求”，而不是一条“状态”。听的人也不再走神，因为他知道随时可能被点到名字。

四、专业判断逻辑：我凭什么说这面墙有问题

做了这么多年研发管理咨询，我发展出了一套自己的“看板健康度诊断框架”。进到一个团队，我不看他们的燃尽图漂不漂亮，也不问他们的敏捷成熟度自评分数是多少。我只看五个信号，五个信号里有三个亮红灯，这个团队的看板基本上就是摆设。

1. 看卡片的“年龄分布”

我会随机抽十张在“开发中”或“测试中”列的卡片，问Scrum Master这几张卡分别贴上去几天了。如果超过一半的卡片在同一列停留超过三个工作日，说明瓶颈已经形成但没人处理。健康的看板应该呈现一种流动感，大部分卡片的停留周期集中在一天到两天，少数复杂卡片停留三到五天，几乎不应该有停留一周以上的卡片。

这里补充一个数据观察。我在过去五年里诊断过四十多个百人以上规模的研发团队，发现一个规律：在制品数量超过团队成员数1.5倍的团队，平均需求交付周期是在制品数低于1倍团队的3.2倍。原因很简单，每个人同时背着多张卡，每张卡都做一点，每张卡都做不完。看板上“开发中”列有30张卡，但团队只有15个人，意味着平均每个人手上有两张卡在并行。人脑不是多核处理器，任务切换的认知损耗是实打实的。

2. 看“已完成”列的定义标准

我会直接问产品负责人：“这张绿色的卡，是怎么从‘测试中’移到‘已完成’的？”如果回答是“开发提测了”、“代码合并到主分支了”、“QA点过了”，我会继续追问：“那这个功能现在在生产环境上，有多少用户用过，数据怎么样？”能回答出第二个问题的人我目前为止遇到不超过五分之一。

这不是在苛求团队。而是因为，“已完成”的定义标准直接决定了整个团队的工作终点。如果“已完成”的定义停留在“代码写完”，那团队的大脑就只运转到代码写完那一刻。后续的部署、发布、监控、数据验证，都不会进入团队的思考范围。这些事总得有人干，那就变成了测试团队、运维团队、数据团队的事。跨团队协作的成本，就是这么被“已完成”的标准一刀切出来的。

3. 看站会时谁在说话、谁在看谁

这是我最快的一招。站会开始后我站在角落里观察三分钟。如果超过80%的发言都是对着Scrum Master或者技术主管说的，且说话的人眼神始终锁定在那一个人身上，那这个团队的看板一定有问题。正常的站会，发言应该是轮转的、交互的，说话的人在讲某张卡的时候，会自然地看向和这张卡相关的人，被看的人会点头、接话、追问。如果所有人都在向一个人汇报，那就不是团队协作，是下属述职。

4. 看卡片上的信息是否足够驱动决策

我随手从墙上摘一张卡，看上面除了标题之外还有什么。绝大多数卡片上面只有两样东西：标题和负责人姓名。这离“驱动决策”差得太远了。一张真正有用的卡片，至少应该包含：它要解决谁的什么问题、验收标准是什么、当前阻塞是什么、下一步需要谁配合。如果一张卡上只有“订单详情改版 – 张三”，那它就是一张占位符，不是一个工作单元。

PingCode这类工具在设计卡片模板的时候，默认就包含了验收标准、关联需求、阻塞标记和优先级这几个字段。但我观察到一个非常普遍的现象：大量团队在用这些工具的时候，只填了“标题”和“负责人”两个字段，其余的全部空着。工具给了完整的结构，但团队只用了5%的信息承载量。这就好比买了一台顶配的电脑，只用来打开记事本打字。工具没有错，是用工具的人没有把思考装进去。

5. 看回顾会上讨论的内容类型

迭代回顾是敏捷里面最被低估、也最容易被敷衍的仪式。我会旁听团队的回顾会，给会上讨论的话题分类。如果讨论的话题80%集中在“开发环境又挂了”、“测试数据老是冲突”、“某个人请假导致进度延误”这类具体事件上，而几乎没有涉及“我们上个月做的那个需求到底有没有人用”、“为什么产品经理提的需求有一半最后被废弃了”这种价值层面的反思，那这个团队的回顾会只是在处理表面问题，没有触及效率低下的根因。

真正的回顾会，应该敢于把一张几个月前就贴上去但至今没动过的卡片拿出来，问所有人：“这张卡我们到底还要不要做？如果一直没做但也没人删掉它，说明什么？”这种追问会让人不舒服，但恰恰是这种不舒服，能刺破“看板贴满墙”带来的虚假充实感。

五、案例观察：从中大型团队的敏捷实践中提炼规律

接下来的内容基于我对PingCode服务的中大型企业客户群体的长期观察。PingCode主要服务100人以上的研发组织，这类组织的共同特征是：多条业务线并行、跨团队依赖复杂、已有一定的流程基础但在敏捷转型中普遍遇到“流程跑起来了但效率没上去”的困境。我从他们的实践中提炼了几个案例，隐去了企业具体名称，但保留了关键场景和决策逻辑。

1. 案例一：200人研发中心，看板40张卡，但每周实际上线的只有3张

这是一家金融科技企业，研发团队超过200人，分成了8个Scrum团队。每个团队都有自己的物理看板，Scrum流程跑得规规矩矩。CTO找我的时候很困惑：“我每个迭代评审都参加，大家演示的功能都不少，但业务方还是在抱怨需求响应太慢。”

我花了两天时间，把8个团队的看板全部拍了下来，做了一件事：把“已完成”列里的卡片编号和过去一个月的生产发布记录做了一一比对。结果大跌眼镜。8个团队在当月的迭代评审中一共演示了47个“已完成”的需求，但真正被部署到生产环境、并且有用户实际使用的，只有11个。剩下的36个需求，有的卡在UAT环境等待业务验收，有的因为依赖的上游系统没准备好而无法上线，有的干脆是业务方在评审会之后改了主意、决定先不上。

问题出在哪里？出在每个团队都把自己看板上的“已完成”当成了终点，但没有一个人或一个机制在确保“已完成”的东西最终流转到用户手上。测试完了就算完了，演示完了就算完了。从“研发侧已完成”到“用户侧已交付”之间，存在一个巨大的真空地带，没有人对这一段负责。

后来的改进措施并不复杂。他们把“已完成”列拆成了两列：“待发布”和“已交付”。“待发布”列的卡片必须由产品负责人确认上线计划，“已交付”列要求附上生产环境的数据验证结果。这个改动推行了两个月后，真正交付到用户手上的需求比例从23%提升到了超过60%。看板上的卡片总数反而下降了，因为那些长期滞留在“已完成”状态下的僵尸卡片被一次性清理掉了。

2. 案例二：300人组织，站会时间越来越长，信息量越来越大，决策越来越慢

这是一家SaaS企业，大概300人的产研规模。他们的Scrum Master团队非常敬业，站会记录做得极其详尽。我翻看了他们一个月的站会纪要，每天差不多有800到1200字，记录了每个人说的每一个细节。

但我发现一个规律：这些纪要里出现了大量“准备去确认一下”、“等XX回复后再看”、“依赖XX团队的接口文档”这类表述，几乎每天都有，但真正被闭环掉的阻塞事项占比不到15%。也就是说，阻塞问题被反复提及，但没有人真正去解决它们。站会变成了一个“阻塞问题播报平台”，而不是“阻塞问题解决平台”。

我和Scrum Master们开了个会，问他们一个问题：“你们记录了这么多阻塞问题，有没有人统计过，这些阻塞问题从第一次被提及到最后被解决，平均需要多少天？”没有人能回答这个问题。因为他们只负责记录，不负责追踪闭环。

后来他们做了一个调整。每个团队在看板上专门划出一小块区域，叫“阻塞墙”。任何在站会上被提出的阻塞问题，立刻生成一张红色卡片贴上去。红色卡片上必须写明：谁负责解决、预计解决时间、如果超过24小时未解决升级给谁。每天站会的最后三分钟，专门用来过一遍红色卡片，逐张确认进展。这个机制运转起来之后，阻塞问题的平均解决周期从7.8天缩短到了1.9天。站会时长反而从平均18分钟缩短到了12分钟，因为不用再每天重复同样的阻塞问题了。

3. 案例三：需求卡片越来越多，产品经理和研发之间的矛盾越来越深

这个案例来自一家电商企业，研发团队大概150人。他们的问题是：产品经理源源不断地往看板上贴需求卡片，研发团队疲于奔命地消化，但两个角色之间的信任度越来越低。产品经理抱怨研发做得太慢，研发抱怨产品经理提的需求大部分没人用。

我去翻了他们过去六个月的需求数据，发现一个触目惊心的数字：在产品经理提交给研发的412个需求中，上线后真正被用户使用超过100次的功能，只有38个。也就是说，超过90%的研发产能被消耗在了低价值甚至零价值的需求上。但问题是，在看板上，这些需求都被正常地走完了“待办-开发-测试-已完成”的完整流程，从流程角度看毫无问题。

根因在于：产品经理提交需求的时候，从来没有被要求提供“这个需求上线后的效果预估”或者“如何验证这个需求是否成功的指标”。研发团队接需求的时候，也只评估技术可行性和工作量，不评估业务价值。双方在“效率”这件事上的定义是割裂的，产品经理定义的效率是“我提的需求被实现的速度”，研发定义的效率是“我写的代码不出Bug的速度”，而真正该被定义的效率是“单位研发资源投入带来的用户价值增量”。

改进做法是把“价值假设”前置到需求入库的节点。产品经理在往看板上贴一张需求卡之前，必须在这张卡上写清楚三件事：这个需求解决谁的什么痛点、上线后用什么指标来衡量成功、如果上线两周后指标没有任何变化我们该怎么办。这个做法一推行，产品经理主动撤回的需求比例达到了35%。因为他们自己在写这三条的时候，发现有些需求其实根本没想清楚。

六、不同场景下的行动建议

前面花了大量篇幅讲问题、讲案例、讲判断逻辑。这一节我要给出可操作的建议。但请注意，不同规模、不同阶段的团队，适用的解法完全不同。我不相信存在一套放之四海而皆准的敏捷实践方案。以下建议按场景分类，请根据你的实际情况选择性采纳。

1. 场景A：团队小于30人，刚引入Scrum不到半年

这个阶段的团队，最大的敌人不是流程缺失，而是过度设计流程。很多年轻Scrum Master一上来就搞全套：故事点估算、燃尽图、速率追踪、回顾会打分矩阵……团队成员光学习这些仪式的时间就占用了大量本应用来写代码的时间。

我给这个阶段团队的建议只有三条：

• 把看板列简化到极致。只保留“待办、开发中、已完成”三列，不要搞花里胡哨的“待评审”、“待合并”、“待部署”等中间列。让流动路径尽可能短，让每个人一眼就能看懂。
• 卡片上只写三样东西：标题、验收标准、负责人。别的都不要填。不要故事点，不要优先级数字，不要标签。在团队还没形成基本的协同节奏之前，额外的信息字段全是噪音。
• 站会只回答一个问题：“有没有什么事情需要别人帮你才能推进的？”如果答案是没有，你可以不说话。不需要每人轮流说昨天干了什么。这个阶段最重要的是让团队成员建立起“互相求助”的习惯，而不是“互相汇报”。

我在一家30人左右的初创公司推过这套极简做法。头两个月PMO觉得“太不正规了”，但团队三个月内的需求交付周期稳定在6天左右，比同期另一家引进了全套敏捷工具的兄弟团队快了将近一倍。那位兄弟团队的Scrum Master后来跟我复盘时说了一句话：“我们的Jira配置花了两个月，结果发现团队根本用不全那些功能。”

2. 场景B：团队50到150人，敏捷跑了一年多但感觉遇到了瓶颈

这个规模的团队是最容易出现“表演型看板”的阶段。流程基本都跑通了，站会、评审、回顾一个不落，但效率感就是上不去。问题通常不出在单个团队内部，而出在跨团队协作的交接面上。

跨越这个阶段，我建议做三件事：

• 把“已完成”的终点重新定义到生产环境。这件事我已经在案例里讲过了，这里不再展开。唯一补充一点：这个改动会遭到研发团队的本能抵触，因为这意味着他们要对“代码写完”之后的环节负责。你需要争取CTO或者技术VP的明确支持，否则推不下去。
• 建立跨团队的“依赖看板”。每个团队自己的看板只管自己的一亩三分地，但跨团队的依赖关系没人管。一个简单的做法是在公共区域立一面“依赖墙”，任何团队识别到需要其他团队配合的事项，贴一张橙色卡片上去，写上依赖方、被依赖方、预计交付时间。每周各团队的Scrum Master一起过一遍橙色卡片。
• 让产品经理参与回顾会。很多团队的回顾会是研发内部的“闭门会议”，产品经理不参加。这是一个巨大的浪费。产品经理是需求价值的定义者，如果他们不参与反思“哪些需求做出来没人用”，研发团队自己反思再多也没用。

3. 场景C：团队超过200人，多条业务线，多层级汇报关系

200人以上的组织，敏捷做不好的根因通常不在执行层，而在管理层对“效率”的认知偏差上。高层管理者需要看到“效率在提升”的证据，于是中层管理者就用看板上的流转速度、站会的出勤率、迭代的速率等指标来向上汇报。至于这些指标和真正的业务结果之间有没有因果关系，没人在意。

这个场景下的解法，技术层面已经不重要了，重要的是把管理层的注意力从“研发过程指标”迁移到“用户价值指标”上。具体做法：

• 用一条完整的“从需求提出到价值验证”的价值流图替代迭代速率报告。每个月向管理层汇报一次，图上标注每个需求从提出到上线、再到数据验证的完整周期，以及中间各环节的等待时间占比。让管理层亲眼看到，研发写代码的时间可能只占整个周期的30%，其余70%都耗在等待和返工上。数据比任何敏捷理论都有说服力。
• 设立“价值交付经理”角色，独立于Scrum Master和研发经理。这个角色的职责只有一个：确保每个迭代交付到用户手里的东西真正产生了价值。他有权在产品经理提的需求没有清晰价值假设时拒绝其进入开发流程，也有权在功能上线后追踪数据并提出“回滚或优化”的建议。这个角色不承担研发管理职责，直接向CTO或CPO汇报。
• 在PingCode这类工具中，强制要求“已交付”状态的卡片关联生产环境的数据验证结果。这不是一个技术问题，而是一个管理意志问题。如果管理层不下决心把“已交付”当成硬约束，下面的人永远有办法绕过去。

七、什么时候该坚持看板，什么时候该果断“减少看板”

这篇文章的标题是“敏捷看板贴满墙，效率反而低了”，但我必须非常明确地表达一个观点：我反对的不是看板，而是不会思考地使用看板。看板本身是一个极其强大的工具，用对了能成倍提升团队的协同效率。问题在于，很多人不知道什么时候该用看板、什么时候该减少看板上的信息、什么时候干脆把一部分卡片撕掉。

下面这张表，是我根据自己的实践经验总结的一套决策参考框架。不是什么权威理论，但在我带过的团队和诊断过的客户那里屡试不爽。

这张表的核心理念只有一句话：看板是为团队服务的，不是团队为看板服务的。当你发现团队在花大量时间维护看板、但看板上的信息并没有帮助团队做出更好的决策时，不要犹豫，减少它。一面只有十张关键卡片的看板，比一面贴了五十张卡片的看板有价值得多。

我自己有一个习惯，每个迭代结束时，我会和团队一起做一件仪式感很强的事：从墙上撕掉那些超过一个月没动过的卡片。这个过程刚开始会让人不舒服，因为撕掉某张卡在心理上等同于“承认这个需求我们做不完了”或者“这个需求没人要了”。但正是这种不舒服，逼着团队直面一个事实：有限的精力只能聚焦在有限的事情上。如果你不愿意撕掉任何一张卡，说明你还没有真正做好优先级排序。

八、下一步怎么做：一个可落地的最小行动方案

读完这篇文章，你不需要回去把整个敏捷流程推翻重建。那既不现实也没必要。我建议你从以下四件事里挑一件，在下周一就开始做：

第一件：花半小时，把看板上超过三十天没动过的卡片全部拿下来。别扔，放在一个盒子里。如果一个月内没人从盒子里把某张卡捡回去，那就说明这张卡确实不需要了。这个动作不涉及任何流程变更，纯粹是清理信息垃圾，但效果立竿见影，看板瞬间清晰了，团队盯着墙的时候不再有那种“事情永远做不完”的窒息感。

第二件：在明天的站会上试一次“禁止说昨天干了什么”。规则很简单，每个人只准说两件事：当前有没有阻塞、今天需要谁配合。如果有人习惯性地开始汇报，Scrum Master温和地打断。试一次你就知道，站会的信息密度和协作浓度会发生什么变化。

第三件：打开你们的项目管理工具，统计一下过去三个月“已完成”的需求里，有多少真的被用户用起来了。这个数字很可能让你不舒服。但不舒服就对了。把这个数字贴在团队看板旁边，下次迭代规划的时候，所有人再看那一排待办需求，心态就不一样了。

第四件：如果你是Scrum Master或者技术管理者，去和产品负责人坐下来聊一个问题：“我们上季度做的需求里，哪些是你觉得做完之后其实没啥用的？”不要带着问责的语气，就是单纯地好奇。你会发现产品负责人心里其实门儿清，只是以前没人问，或者说没有合适的场合讨论这个话题。把这个对话常态化，每个迭代回顾会上留十分钟专门聊“价值回顾”，比任何流程优化都管用。

敏捷搞了这么多年，真正能持续高效的团队少之又少。不是因为敏捷理论错了，而是因为绝大多数团队在“怎么做”上花了太多时间，在“为什么做”上花的时间太少。看板是一面镜子，它反映的不是任务的流转状态，而是团队是不是真的在思考、在协作、在对齐。当你站在那面贴满卡片的墙前面时，不要数上面有多少张卡，不要算燃尽图还剩多少点。你只需要问自己一个问题：这面墙，是在帮我们想得更清楚，还是在替我们想得更少？

如果你的答案偏向后者，那就从撕掉第一张不必要卡片的那一刻开始，把思考的权力从墙上拿回自己手里。