【敏捷 FAQ 番外篇】正确的道理行不通时……甲方或高层不愿倾听时的生存策略

 感谢您阅读本文。我是所属敏捷小组的藤井智弘。这次同样为大家带来一篇没有预告的番外篇。
 我曾在第 8 回的最后写道：“在利益相关者一方无论如何都不愿行动的环境中该如何应对，也会在这个连载的某个地方谈到”，而这次就是那个“某个时候”。

 虽说如此，这其实也是一句毫不留情的话：“因为上面不理解，所以没法敏捷？别唧唧歪歪了，直接干啊。”

 这个连载中的建议很有参考价值，但其中很多最终都会落到“与甲方协商”或“向组织提出诉求”上。说实话，我们这边的甲方和管理层根本不愿意听。“按现行方式做”“所以，多少人天？”“敏捷？那种流行玩意儿就算了”，对话到此就结束了。在正确的道理（我并非说全都是，但在我看来很多都很有道理）行不通的环境中，敏捷最终是否还是无法实现呢？

 并非无法实现。不过，需要调整顺序。如果你把这个连载中的建议理解为“先在协商中获胜，再去实践”，那就反了。先在能够实践的地方开始做，创造实绩，再带着实绩去协商。协商不是最初的关卡，而是最后的收尾工作。
 而且，希望你记住的是，这个连载中的建议里，不需要任何人许可的事情，远比你想象得更多。

 在进入令人恼火的话题之前，先冷静地观察一下对方。不愿倾听的一方，通常也有其结构性的原因。

• 没有实绩的提案看起来只是一种风险：对你而言，敏捷是合理的提案；但对对方而言，这等于是在要求“把自己的责任押在一种不太了解的做法上”。站在那个人的立场，拒绝反而是更负责任的判断。
• 不改变才是最优解的评价结构：在维持现状不会受到任何惩罚的组织里，变更提案会成为一种不对称的赌博：“成功是理所当然的，失败则是提案者的责任”。
• 过去曾因“片假名流行概念”而失败：几年前曾被另一个三个字母的缩写坑过的组织，光是看到招牌就会严阵以待。

 也就是说，对方往往并不是反对你的逻辑，而是在反对提案中包含的不确定性。既然如此，应对方式就不是“解释得更正确”，而是降低不确定性——也就是，拿出小规模的实绩。第 5 回中我写过，如果用正确道理强行推进，在对方看来会成为“应然论的强加”，反而会变成阻力。如果你停留在“明明已经正确说明了却没通过”，那你正陷在同一个陷阱之中。

 这次不是平时那种“处方”。而是原则。

第一原则：从不需要许可的领域开始
 请尝试按“是否需要许可”重新分类这个连载中的建议。记录插单工作（第 12 回）、在回顾会议开头确认上一次的 Try（第 7 回）、从看板最右端开始推进（第 6 回），以及计划在今后的文章中介绍的：盘点已作出的决定、记录改修交付周期、写下 10 行 ADR（决策记录）……这些全都不需要任何人的许可。在团队内部即可完成的改进，以及记录与测量，从今天起就可以开始。
 为避免说得太绝对，我需要补充一点：只有审计或合同要求必须制作的文档，不在自主决定的范围内。同样地，如果要在适用公司内部开发标准的项目中改变推进方式本身，那应当走标准适用豁免的流程，而不属于“不需要许可的领域”。
 请冷静地重新审视一下。“因为上面不行动，所以什么都做不了”，大多数时候并不是事实。

第二原则：先有实绩，后谈协商
 从小处开始，拿到数据后再去沟通。不要说“请让我们导入敏捷”，而要说“过去这 3 个月，我们记录了插单工作，发现它占用了 40% 的产能。请允许我们从下个月起统一受理入口”。前者会变成理念之争，后者则是事实之争。理念可以凭喜好驳回，但事实不容易被驳回。这个连载反复强调“先测量”，是因为测量不仅是改进的工具，同时也是没有权限之人的谈判力来源。

第三原则：摘下招牌，落实内核
 如果“Scrum”“敏捷”这些词会让对方关上大门，那就不用这些词好了（坦白说，我有一种偏见：越是做不成事的人，越喜欢把方法论的名称摆在最前面）。不叫 Sprint，而说“我们每两周以一个周期举行确认会”。不叫 Retro，而说“这是月度业务改进会议”。不叫 Backlog，而说“按优先级排列的问题清单”。当内核开始运转并产生成果时，名称就无关紧要了。比起忠于招牌，更重要的是实践内核。
 为避免误解，我补充说明：这不是指悄悄绕过既定的程序。只是在被赋予的自主权限范围内，将称呼调整为对方习惯的语言。因此……

• 应向直属上司说明“我们正以更换称呼的方式来运作”
• 如果提案书或合同中明确写明了开发方法论，应先确认与该表述的一致性
• 如果要求按开发标准中的交付物名称进行汇报，应准备一页团队内部称呼与其对应关系的对照表

 如果缺少这三点，就无法与规避程序区分开来。反过来说，能否不使用名称也把事情讲清楚，本身也是检验自己是否真正理解其内核的方法。

第四原则：记录失败的协商，将其作为再次挑战的弹药
 如果提案被否决，就平静地记录被否决的事实，以及之后发生的事情（预测的风险是否真的发生）。记录的位置不要是个人笔记，而应是团队的问题管理表、阻碍事项清单（将团队障碍汇总列出的正式记录）等正式场所。不夹杂情绪，不写成怨言，只记录事实。“4 月曾提议统一受理入口，未被采纳。5～7 月的插单工作平均每月 ○ 件，其中 ○ 件直接导致交期延误”。当这样的记录累积两三次后，同一项提案获得通过的概率会显著改变。
 组织往往会拒绝最初的提案，但会向不断积累的事实让步。从组织自身的生存策略来看，这也是合理的。请以此为前提做好准备。

第五原则：即便依然不动，也要投资于可以带走的资产
 遗憾的是，确实存在无论你竭尽全力也不会改变的组织。此时希望你记住，至今为止的这些实践——测量的习惯、记录的纪律、小范围完成工作的技术、在没有招牌的情况下解释本质的语言——全都是积累在你和团队身上的资产。即使留在组织中，它们也会继续累积；无论去往怎样的环境，也都可以带走。即使无法改变组织，你自身的能力与市场价值也确实已经发生了变化。
 这并不是建议你跳槽，而是在谈选择投资对象的问题。组织是否会行动并不在你的控制范围内，但自己学习什么则在你的控制范围内。

 因为“没有权限的人试图从现场改变组织”这一格局，本身就是软件开发的历史。请回想一下：敏捷并非由管理层自上而下创造出来的方法论。那些深受重量级流程之苦的现场实践者，从没有权限的地方开始进行小规模实践，汇集实绩，为其赋予语言，最终推动了整个行业——这是一场草根运动。

 也就是说，“面对不愿倾听的对象，依然从小处开始”，对于敏捷而言并不是例外情况，而是它诞生时的姿态。你如今所在的位置，正是 30 年前（或者更久以前）前辈们所在的位置。而他们的武器，也和如今的你相同。
 小小的实践，以及被记录下来的事实。
 仅凭这些，应该就足以开始了。

下次：“PO 很忙，无法来到团队中”／正篇连载列表请参见第 1 回。