本文共 3418 字，大约阅读时间需要 11 分钟。
组织改进和确保大家开展真正的学习是管理者的职责。为了真正的学习，你必须接受未知，走出已有的知识领域。荷兰商业银行的Leendert Kalfsbeek 和 David Bogaerts说，敏捷、精益和持续交付有助于提升学习的能力。
\\在峰会上，管理人员Leendert Kalfsbeek以及精益和敏捷教练David Bogaerts讨论了荷兰商业银行的精益领导力之旅。InfoQ以问答、总结和文章全程跟进了本次大会。
\\本届精益IT 2017峰会已于三月14至15日在法国巴黎召开。
\\为应对数字带给工作场所的许多挑战，精益IT提供了一些已得到实际检验过的管理实践。在IT/数字领域如何做精益？本次峰会将探讨这方面的三个主题：
\\InfoQ有幸采访了Leendert Kalfsbeek 和 David Bogaerts，请他们谈了谈在荷兰商业银行应用敏捷和精益IT的经历，以及他们在这段精益之旅中学到了什么。
\\InfoQ：荷兰商业银行应用精益有一段很长时间的历史了。你们可以简要总结一下吗？
\\\\\Leendert Kalfsbeek \u0026amp; David Bogaerts: ING在我们组织中的几个领域都使用过很长时间的精益了。光看IT方面，2010年时互联网和移动部的软件开发部就已经有三个试点在使用敏捷/精益了，至今大约有七年的历史了。在我们的领域中（当前称之为全渠道IT），敏捷和精益已经相互交错无法分开了，它就像在不同家庭中成长的双胞胎一样：可能有时对有些东西的称谓有所不同，但理念和理论却是一样的。当你试图从不同行业和公司直接复制实现方式时，却忽略了自身的现实情况，才会出现概念上的问题。
\\好吧，回到我们自己的经历上。在第一个试点取得成功之后，我们明白了，敏捷/精益真的可以流行起来。工程师们看起来觉得无拘无束了，团队经常自发应用敏捷。尽管带来了一些挑战（比如错误地学习材料），但一般情况下我们可以轻松地构建了，这是件很值得肯定的事。在2011年，实验性经验表明，敏捷会我们会有更多的帮助，于是我们决定将敏捷精益框架用于软件开发。
\\其间，我们开始思考下一步：如何通过减少阶段移交进一步增加团队的自治性？我们再次在互联网和移动领域开始实验，在实验中我们把软件开发和运维聚集到一个团队中，也就是我们那时所谓的DevOps团队（但也只是个名字而已）。然后历史重演：尽管有些经验教训，但它还是非常成功的。这样，我们就合情合理地走向了下一个步：针对ING的整个IT，把Dev和Ops聚到一个团队。在2013年，我们所探讨的可是大约150个DevOps团队。当然，做这么大规模的事必会陷入到相应的挑战。但我们认为这总归会成为一件好事。它把组织中无论如何不得不解决的障碍暴露到了聚光灯之下。现在，我们可以开始动手消除它们了。
\\迄今为止，我们真正理解消除阶段移交的作用了。这带领我们走向大胆的下一步：把深入的客户知识带到团队；不仅是IT产品的产品负责人，而是实际的客户旅程专家。这使得我们变成现在的组织，在其中客户旅程专家和IT工程师聚在一个小团队中（7人左右，上下浮动2人），尽可能地变得自治。还有些人称其为BizDevOps 或 Enterprise Agility。我们只是把它称做“有效的模型”而已。至少，它对我们是有效的。
\\在这段历史中，有两点要特别注意：
\\首先，我们的持续交付之旅与我们的敏捷和精益之旅密切相关。这两方面都需要取得成功。
\\第二，敏捷、精益和持续交付永远都不是目的。回到2010年，我们的驱动力是打造荷兰最好的IT公司，我们的重点是营造卓越的工程文化。敏捷、精益和持续交付仅仅是必要的手段，能帮助我们提高学习能力。
\
InfoQ：在你们的精益之旅中受到哪些问题的困扰了吗？
\\\\\Kalfsbeek \u0026amp; Bogaerts: 没有。虽然，我们得到了一些经验。我们要特别指出两点：
\\1：不愄攀越障碍之艰，但念一览众山之美。
\\如果你开启了这样一段旅程，障碍之山自会矗立于前。翻过一座，又见一座，越来越多。一步一步攀登，不觉变小，反觉越来越大。从中我们学会了不可轻言放弃，而要迎难而上。障碍很可能始终都存在，现在，我们可以正视它们了。我们不再畏惧登山之艰难，而是享受当下，憧憬着登上高山之后将看到的美景，动身与伙伴一起携手翻越下一个阻挡在我们面前的障碍。你猜如何，自从这么想以来，我们睡得也比以前更香了。
\\2：推广之前先深入理解
\\我们的旅程包括一系列大大小小的实验。这些年我们学会了，如果要尝试新鲜事物看它是否有效，在进一步推动它之前要确保理解它有效的真正原因是什么，它是如何运转的，以及为什么会有效。我们希望在把它推广到其他领域之前能对它有深入的理解。在一开始，感觉这么想会让我们慢下来。然而，反过来说，如果你一开始就有正确的理解，那么就能让事情更快地运转起来。所以在推广之前要先深入理解，欲速则不达，想要快就得先慢下来！
\
InfoQ：在ING是如何组织持续改进的？
\\\\\Kalfsbeek \u0026amp; Bogaerts：我们不能代表整个ING来谈，但在 OmniChannel IT内部我们已经实现到一定程度了，至少Scrum把我们带到了一定的层次。我们有了很大的进步，但没有进行任何进一步的提升。评估一下我们当前的现状，我们的团队已经做得不错了，然而，有些东西还没有实现。而在我们的团队不成问题之后，下一步就必须是管理团队了。
\\我们认识到，持续改进光靠两周一次、不系统的团队回顾是不够的。我们需要一个专注于改进的组织，它要关注于为满足最具挑战性的商业目标需要去改进的事上。为做到这一点，我们尝试为组织中的每个人提供上下文，不仅仅是整体方向，还有每个个体的具体信息，以便他（她）可以尽可能不断地得出最佳决策。我们希望通过不断地针对挑战交换意见，遵循计划-执行-检查-行动（PDCA）的科学方法，以做到这一点。我们使用Mike Rother的教练套路对话的模式来帮我们做到这一点。
\\我们发现，PDCA看起来简单，但实际每天做起来却很难。因为我们的旧习惯很难克服，所以需要想些办法。所以我们为此创建了一个工作模式：每个人确保按一定的节奏和程序去讨论挑战，去持续围绕这些挑战开展工作，然后就一天天地变好了。
\\这看起来简单平常，但做起来却难，我们就遇到了许多麻烦。但到最后，它就是工作，是我们的工作和职责，我们决定一直做下去，直到我们作为一个整体达到：改进“每个过程、每个产品、每个人、每一天”。
\
InfoQ: 如何使每个人（员工和管理者）参与到持续改进中来？
\\\\\Kalfsbeek \u0026amp; Bogaerts: 身体立行胜过千言万语。通过实际去做并取得效果，真正学习如何改进我们的改进方式！
\\如果我们被一个需要用结构化的方法来解决的挑战困住了，我们就会试图去找合适的改进者（有天然优势承担这一挑战的人）。我们把持续改进的框架做个简单的介绍，然后开始一起动手去做，与改进者和导师一起。
\
InfoQ: 在持续改进之旅中你们学到了什么？
\\\\\Kalfsbeek \u0026amp; Bogaerts: 我们仍然一无所知，仍然有很多事并不了解，但至少我们正在学习。即使有些事我们并不知道，我们也不会担忧，我们觉得发现新的战场是很自然的事。我们已经习惯在未知的领域上展开真正的学习。同时，我们得到更好的结果并营造出更好的组织。
\\当然，我们也学到了很多。在巴黎三月十四日的精益IT峰会上，我们分享了学到的更多内容。
\
InfoQ：你们能为想要做持续改进的管理者提一些建议吗？
\\\\\Kalfsbeek \u0026amp; Bogaerts: 只有几个字：打造自己的能力。我们不是说你不应该求助外援，但你必须要亲手去完成它。管理者不能简单地把最重要的管理职责“组织改进”和“培训员工”外包出去。如果他们这么做，也就等于把整个管理职责都外包出去了。
\
查看英文原文：
转载地址：http://mhfsx.baihongyu.com/