近来，在阅读《大西洋月刊》时，一篇题为“未来软件启示”的文章帮助我在一个新的环境下重新审视“为什么精益转型会失败？”这个困扰着我们的问题。之前，人们通常会用“95%的精益转型都会失败”来回答这个问题或者提出一些应对失败的对策和措施。但是，至今为止还没有人能引用准确的资料来源去支撑这些数据，他们也没有充分地定义“精益转型”或“失败”这样的术语。抛开语义不说，人们确实一直挣扎在将精益实践运用至恰当的地方并使之不断坚持下去，他们付出的努力远比应该做的要多很多。

对于“为什么精益转型经常会失败”这样的问题能有哪些观点可以阐明经验教训呢？事实证明，有，并且相当多。

教训一：精益转型很复杂

建立精益管理体系有很多事情要做。这个体系需要在整个企业中运行，需要全员参与到以客户为导向的问题解决和创新中来，并且这将是一个长期的过程。它需要的远不仅仅是地板的草图，白板上的两根柱子和一个屋顶，或者是可以在45分钟的励志主题演讲中可以交付的东西。“问题在于，我们正试图建立超出我们智力管理能力的系统，”麻省理工航空航天学教授南希•莱韦森(Nancy Leveson)在文章中引用道。换句话说，精益转型是非常复杂的事情！如果我们过分吹嘘、过度简化，或投入大量的热情到精益思想中，但是对于把所有东西放在一起如何起作用几乎没有把握，那么我们就会失败。

教训二：锤子之前的蓝图

获得图灵奖的计算机科学家莱斯利•兰波特说道:“建筑师在砖砌或敲钉子之前就已经画出了详细的计划，但很少有程序员在开始编码之前，就会写出他们的程序的草图。”换句话说，软件充满了错误是因为程序员从一开始就直接跳到了编写代码。人们在对自己正在构建的东西没有清晰概念之前就开始尝试做精益，不论是使用A3问题解决、二次改进想法、改善周、改善套路、价值流等等。客气点说，这都将导致大量的返工、追溯或“学习”。无论是由于缺乏意愿或预算投资于“系统架构师”，或过度吹嘘“精益是简单的”，或仅仅是我们行动的偏差，没有蓝图的锤子往往是精益失败的一个特征。

教训三：只见工具不见系统

精益管理要求我们解决问题，同时也要意识到解决问题的过程，以及我们是否正确地解决问题，而不是直接跳到解决方案上。此外，我们需要反思为什么人们在解决问题时仍然会有心理上的捷径，或者陷入坏习惯的怪圈，并且应该知道接下来该怎么办。期刊的文章中写道：“代码让你只见树不见林:它把你的注意力吸引到单个作品的工作上，而不是更大的蓝图:例如你的程序是如何组合在一起的，或者它应该做什么，以及它是否真的能实现你的想法。”

我们需要用工具去得到我们想要的结果，并且在实践中学习，但是这也可以将我们的注意力从系统的高层结构及其基本逻辑中分离出来。当我们不这样做的时候，我们就会创造出那些无法与可持续结果联系在一起的卓越岛屿，这是一个精益失败的前兆。

教训四：范围蔓延

根据期刊文章所说，软件在没有限制的情况下成长，“因为它可以廉价地改变，软件也在不断地改变。因为它没有任何物理意义:一个比另一个复杂一千倍的程序占用了同样的实际空间”。

即使是在我们开始小改善的时候，精益思维也很难在小的、局限的领域进行实践，因为当我们提供商品和服务时，一切都是相互关联的。在改进了一个过程之后，还必须改进相近的流程，以使第一个收益能够持续。范围必须扩大，但很少有管理团队真正掌握了他们计划和执行复杂项目的能力，从定义上看这些项目将会超出预算并延期执行。项目和倡议除了占用了作战室墙纸外，并不占用物理空间。失败的精益部署倾向于以牺牲执行的代价来最大化项目列表。

教训五：停止测试我们的系统

麻省理工的南希•莱韦森教授说:“当我们有机电系统时，我们就能对它们进行详尽的测试。”

我们可以通过所有可能的配置和联锁来控制列车的移动，把它们放在几张纸上，通过这些配置运行物理列车。我们可以建立、测试，并确切地知道我们在处理什么。然而，精益是一种人类行为系统，它不像机电系统那么可靠。我们不能详尽地测试人们在遇到的每一个新情况下会如何反应。当我们建立一个精益管理系统时，就会出现漏洞。如果我们期望人们总是理性地行动，我们必定会遭遇精益的失败。

教训六：测试系统的难度

正如我上面所讲的错误，我们不能对单个组件进行校对或测试，并期望当我们把它们放在一起时，它们会毫无差错地一起工作。整体总是比局部的总和要大，这在编写文本和代码时基本都是正确的。精益转型只有在整个组织经历并了解了其范围和复杂性之后才会真正起作用。当然，我们不能对组织各个职能部门单独进行改善后，就期望把他们捏合在一起时他们就可以自然而然地配合顺利。当我们仍然满足于优化局部而不是整体时，就会导致内部失调、冲突或无法维持改进的区域，这时精益就会失败。

教训七：需求错误，而不是编码错误

“软件的严重问题与需求有关，而不是编码错误。”

始于明确的需求和来自客户的压力的精益转型是罕见的、却又是幸运的。当一个好的客户能够告诉一个企业他们需要什么，以确保未来的业务和利润的增长时，精益转型就会获得方向和能量。一项以牺牲客户和供应商关系为代价的精益努力，或在没有增长计划的情况下提高产能的努力，终将导致精益转型的失败。

教训八：忠实的追随者，错误的指示

软件确实做到了它被告知要做的事情。它失败的原因是它被告知要做错误的事情。精益可以帮助我们高效地做事，甚至是我们根本不应该做的事情。像软件一样，即使是执行良好，糟糕的设计也会导致精益转型失败。

教训九：问问人们想要什么

根据文中所提，微软的综合开发解决方案Visual Studio使用了大约三分之一的专业程序员，拥有超过5500万行代码。超过98%的内容与用户完全无关，忽略了人们所面临的基本问题。当领导转型的人不去那些每天在这个系统中生活和工作的人，问他们需要什么来帮助他们成功地完成他们的工作时，精益就会失败。

教训十：沟通问题

在软件开发中，沟通可能是最薄弱的环节。程序员们主要的问题不是技术，而是知道要干什么。人们知道如何编码，问题在于编辑什么代码。需求有时可以是模棱两可，允许每个人以略微不同的方式解释。文章认为，更需要研究程序员如何看待软件开发的工具，而不是构建新的工具。精益往往也是如此，通常人们的认知、误解或对精益方法错误的信任会导致精益失败，而不是缺乏足够强大的问题解决方法，套路或是模板。

教训十一：看不见的复杂性

软件不像物理存在的东西，它是看不见的，它的复杂性亦是如此。这就使得问题也并不是可见的。一个扁平的轮胎看起来是扁平的，而破碎的软件看起来和其他软件一样。当问题没有被有力地暴露出来时，精益就会失败，但会被忽略或隐藏。

教训十二：坏掉的问题升级系统

如果我们把安灯或异常信号连接到同一个电源上，这个电源本是用来起到警告作用的，它会如何工作呢？我们将永远也得不到信号。软件的情况是，故障安全和问题警报也是软件，它是错误的，而不是不安全的。这就像把我们最不可靠的、最传统的、准备离职的以及最漠不关心的人放在问题升级链的每一个点上。这样的精益也不会持续太久。

教训十三：与解决问题之间的距离

我们需要问人们，“我们想要解决什么问题?”“如果我们想要建立一个精益管理体系，就得到同样的答案。”

在软件的情况下，程序员们过于专注于编写机器的指令，并让他们的代码正常工作。麻省理工学院软件安全专家莱维森表示:“问题在于，软件工程师无法理解他们试图解决的问题，也不关心。”试图在软件中解决问题的步骤可能是一步也可能是多步。我们和我们的问题之间的距离越远，我们就越不可能理解并解决它们，这是一个精益失败的秘诀。

教训十四：创建使编码不再必要的工具

Eric Bantegnie是Esterel Technologies的创始人，他是安全关键软件工具的开发者，他说：“我不确定编程是否真的存在，或者至少是软件开发人员。对他来说，软件开发人员的角色是创建工具来消除软件开发人员的需求。他把它比喻成手工制造汽车，就像我们在100年前做的那样，因为我们的工程师还没有建造固定装置、工作辅助设备和电动工具。1万行代码的软件可以手工制作，但可以不再需要3000万行。与精益管理的相似之处非常清楚：在成功的精益转型中，领导力的作用是构建采用和调整TPS工具和模型，以减少复杂性，为人们提供成功所需的资源，并为组织建立一个可重用的知识基础。

教训十五：为什么我们不计划失败

在人们为什么选择不使复杂的软件在很多我们知道的领域变得可靠的问题上，文章提供了洞察力：“人类的直觉无法准确估计

“极其罕见的”事件的组合系统在非常大的规模和体积下运行的真实概率”。换句话说，我们高估了我们成功的机会。代码忠实地实现了预期的设计，但设计未能考虑到一个特殊的“罕见”场景。在逐渐变得自满、停止挑战自我、不预留应对未知的能力情况下，精益管理就会慢慢走向失败。

希望以上经验教训的见解可以引起大家对于精益转型失败的反思！