近來，在閱讀《大西洋月刊》時，一篇題為“未來軟件啟示”的文章幫助我在一個新的環境下重新審視“為什么精益轉型會失敗？”這個困擾著我們的問題。之前，人們通常會用“95%的精益轉型都會失敗”來回答這個問題或者提出一些應對失敗的對策和措施。但是，至今為止還沒有人能引用準確的資料來源去支撐這些數據，他們也沒有充分地定義“精益轉型”或“失敗”這樣的術語。拋開語義不說，人們確實一直掙扎在將精益實踐運用至恰當的地方并使之不斷堅持下去，他們付出的努力遠比應該做的要多很多。

對于“為什么精益轉型經常會失敗”這樣的問題能有哪些觀點可以闡明經驗教訓呢？事實證明，有，并且相當多。

教訓一：精益轉型很復雜

建立精益管理體系有很多事情要做。這個體系需要在整個企業中運行，需要全員參與到以客戶為導向的問題解決和創新中來，并且這將是一個長期的過程。它需要的遠不僅僅是地板的草圖，白板上的兩根柱子和一個屋頂，或者是可以在45分鐘的勵志主題演講中可以交付的東西。“問題在于，我們正試圖建立超出我們智力管理能力的系統，”麻省理工航空航天學教授南希?萊韋森(Nancy?Leveson)在文章中引用道。換句話說，精益轉型是非常復雜的事情！如果我們過分吹噓、過度簡化，或投入大量的熱情到精益思想中，但是對于把所有東西放在一起如何起作用幾乎沒有把握，那么我們就會失敗。

教訓二：錘子之前的藍圖

獲得圖靈獎的計算機科學家萊斯利?蘭波特說道:“建筑師在磚砌或敲釘子之前就已經畫出了詳細的計劃，但很少有程序員在開始編碼之前，就會寫出他們的程序的草圖。”換句話說，軟件充滿了錯誤是因為程序員從一開始就直接跳到了編寫代碼。人們在對自己正在構建的東西沒有清晰概念之前就開始嘗試做精益，不論是使用A3問題解決、二次改進想法、改善周、改善套路、價值流等等。客氣點說，這都將導致大量的返工、追溯或“學習”。無論是由于缺乏意愿或預算投資于“系統架構師”，或過度吹噓“精益是簡單的”，或僅僅是我們行動的偏差，沒有藍圖的錘子往往是精益失敗的一個特征。

教訓三：只見工具不見系統

精益管理要求我們解決問題，同時也要意識到解決問題的過程，以及我們是否正確地解決問題，而不是直接跳到解決方案上。此外，我們需要反思為什么人們在解決問題時仍然會有心理上的捷徑，或者陷入壞習慣的怪圈，并且應該知道接下來該怎么辦。期刊的文章中寫道：“代碼讓你只見樹不見林:它把你的注意力吸引到單個作品的工作上，而不是更大的藍圖:例如你的程序是如何組合在一起的，或者它應該做什么，以及它是否真的能實現你的想法。”

我們需要用工具去得到我們想要的結果，并且在實踐中學習，但是這也可以將我們的注意力從系統的高層結構及其基本邏輯中分離出來。當我們不這樣做的時候，我們就會創造出那些無法與可持續結果聯系在一起的卓越島嶼，這是一個精益失敗的前兆。

教訓四：范圍蔓延

根據期刊文章所說，軟件在沒有限制的情況下成長，“因為它可以廉價地改變，軟件也在不斷地改變。因為它沒有任何物理意義:一個比另一個復雜一千倍的程序占用了同樣的實際空間”。

即使是在我們開始小改善的時候，精益思維也很難在小的、局限的領域進行實踐，因為當我們提供商品和服務時，一切都是相互關聯的。在改進了一個過程之后，還必須改進相近的流程，以使第一個收益能夠持續。范圍必須擴大，但很少有管理團隊真正掌握了他們計劃和執行復雜項目的能力，從定義上看這些項目將會超出預算并延期執行。項目和倡議除了占用了作戰室墻紙外，并不占用物理空間。失敗的精益部署傾向于以犧牲執行的代價來最大化項目列表。

教訓五：停止測試我們的系統

麻省理工的南希?萊韋森教授說:“當我們有機電系統時，我們就能對它們進行詳盡的測試。”

我們可以通過所有可能的配置和聯鎖來控制列車的移動，把它們放在幾張紙上，通過這些配置運行物理列車。我們可以建立、測試，并確切地知道我們在處理什么。然而，精益是一種人類行為系統，它不像機電系統那么可靠。我們不能詳盡地測試人們在遇到的每一個新情況下會如何反應。當我們建立一個精益管理系統時，就會出現漏洞。如果我們期望人們總是理性地行動，我們必定會遭遇精益的失敗。

教訓六：測試系統的難度

正如我上面所講的錯誤，我們不能對單個組件進行校對或測試，并期望當我們把它們放在一起時，它們會毫無差錯地一起工作。整體總是比局部的總和要大，這在編寫文本和代碼時基本都是正確的。精益轉型只有在整個組織經歷并了解了其范圍和復雜性之后才會真正起作用。當然，我們不能對組織各個職能部門單獨進行改善后，就期望把他們捏合在一起時他們就可以自然而然地配合順利。當我們仍然滿足于優化局部而不是整體時，就會導致內部失調、沖突或無法維持改進的區域，這時精益就會失敗。

教訓七：需求錯誤，而不是編碼錯誤

“軟件的嚴重問題與需求有關，而不是編碼錯誤。”

始于明確的需求和來自客戶的壓力的精益轉型是罕見的、卻又是幸運的。當一個好的客戶能夠告訴一個企業他們需要什么，以確保未來的業務和利潤的增長時，精益轉型就會獲得方向和能量。一項以犧牲客戶和供應商關系為代價的精益努力，或在沒有增長計劃的情況下提高產能的努力，終將導致精益轉型的失敗。

教訓八：忠實的追隨者，錯誤的指示

軟件確實做到了它被告知要做的事情。它失敗的原因是它被告知要做錯誤的事情。精益可以幫助我們高效地做事，甚至是我們根本不應該做的事情。像軟件一樣，即使是執行良好，糟糕的設計也會導致精益轉型失敗。

教訓九：問問人們想要什么

根據文中所提，微軟的綜合開發解決方案Visual?Studio使用了大約三分之一的專業程序員，擁有超過5500萬行代碼。超過98%的內容與用戶完全無關，忽略了人們所面臨的基本問題。當領導轉型的人不去那些每天在這個系統中生活和工作的人，問他們需要什么來幫助他們成功地完成他們的工作時，精益就會失敗。

教訓十：溝通問題

在軟件開發中，溝通可能是最薄弱的環節。程序員們主要的問題不是技術，而是知道要干什么。人們知道如何編碼，問題在于編輯什么代碼。需求有時可以是模棱兩可，允許每個人以略微不同的方式解釋。文章認為，更需要研究程序員如何看待軟件開發的工具，而不是構建新的工具。精益往往也是如此，通常人們的認知、誤解或對精益方法錯誤的信任會導致精益失敗，而不是缺乏足夠強大的問題解決方法，套路或是模板。

教訓十一：看不見的復雜性

軟件不像物理存在的東西，它是看不見的，它的復雜性亦是如此。這就使得問題也并不是可見的。一個扁平的輪胎看起來是扁平的，而破碎的軟件看起來和其他軟件一樣。當問題沒有被有力地暴露出來時，精益就會失敗，但會被忽略或隱藏。

教訓十二：壞掉的問題升級系統

如果我們把安燈或異常信號連接到同一個電源上，這個電源本是用來起到警告作用的，它會如何工作呢？我們將永遠也得不到信號。軟件的情況是，故障安全和問題警報也是軟件，它是錯誤的，而不是不安全的。這就像把我們最不可靠的、最傳統的、準備離職的以及最漠不關心的人放在問題升級鏈的每一個點上。這樣的精益也不會持續太久。

教訓十三：與解決問題之間的距離

我們需要問人們，“我們想要解決什么問題?”“如果我們想要建立一個精益管理體系，就得到同樣的答案。”

在軟件的情況下，程序員們過于專注于編寫機器的指令，并讓他們的代碼正常工作。麻省理工學院軟件安全專家萊維森表示:“問題在于，軟件工程師無法理解他們試圖解決的問題，也不關心。”試圖在軟件中解決問題的步驟可能是一步也可能是多步。我們和我們的問題之間的距離越遠，我們就越不可能理解并解決它們，這是一個精益失敗的秘訣。

教訓十四：創建使編碼不再必要的工具

Eric?Bantegnie是Esterel?Technologies的創始人，他是安全關鍵軟件工具的開發者，他說：“我不確定編程是否真的存在，或者至少是軟件開發人員。對他來說，軟件開發人員的角色是創建工具來消除軟件開發人員的需求。他把它比喻成手工制造汽車，就像我們在100年前做的那樣，因為我們的工程師還沒有建造固定裝置、工作輔助設備和電動工具。1萬行代碼的軟件可以手工制作，但可以不再需要3000萬行。與精益管理的相似之處非常清楚：在成功的精益轉型中，領導力的作用是構建采用和調整TPS工具和模型，以減少復雜性，為人們提供成功所需的資源，并為組織建立一個可重用的知識基礎。

教訓十五：為什么我們不計劃失敗

在人們為什么選擇不使復雜的軟件在很多我們知道的領域變得可靠的問題上，文章提供了洞察力：“人類的直覺無法準確估計

“極其罕見的”事件的組合系統在非常大的規模和體積下運行的真實概率”。換句話說，我們高估了我們成功的機會。代碼忠實地實現了預期的設計，但設計未能考慮到一個特殊的“罕見”場景。在逐漸變得自滿、停止挑戰自我、不預留應對未知的能力情況下，精益管理就會慢慢走向失敗。

希望以上經驗教訓的見解可以引起大家對于精益轉型失敗的反思！

文章來自網絡，版權歸作者所有，如有侵權請聯系刪除