166
京東網上商城
《SAFe 4.0參考指南：精益軟件與係統工程的規模化敏捷框架》SAFe原則
SAFe?原則
2.1 原則#1——采取經濟視角
你可能會忽略經濟，但經濟不會忽略你。——Donald Reinertsen，《產品開發流的原則》
摘要
精益係統構建者的目標是：持續地在最短前置時間內，對人類和社會提供最佳的質量和最優的價值。為了實現這個目標，需要係統構建者對經濟效益有一個基本的了解。如果沒有這樣的認識，即使是一個技術成熟的係統也可能需要很高的研發成本，很長的交付時間，或者由於生產和運營成本太高以至於無法支持經濟有效的價值。
為此，係統構建者們（比如整個產業鏈中的領導者、管理層和知識工作者）就必須完全了解他們所做出決策的經濟影響。傳統的觀點是，隻有那些了解業務、市場和客戶經濟情況的決策者與當局者們，才有必要了解係統構建者的活動與經濟之間的關係。然而，如果這些對經濟相關的理解隻是集中在領導者那裏，就會造成基層員工在處理日常工作問題時做出兩個選擇：（1）不理解經濟關係就進行決策，（2）不做任何決策，而將這些問題升級到管理層。其中第一個選擇會導致僅僅是對經濟成果的局部優化，而第二個選擇會導致延遲價值交付，這都會帶來不好的影響。
詳述
SAFe十分強調經濟效益在成功的解決方案開發過程中所發揮的重要作用。因此，SAFe的第一個精益–敏捷原則就是：采取經濟視角。之所以是排名首位的原則，是因為如果不能滿足客戶或係統構建者的經濟目標，那麼解決方案就無法長期存在。解決方案失敗的原因有很多，其中最主要的原因就是不能滿足經濟要求。本節介紹了通過精益–敏捷方法達到優化經濟成果的兩個主要方麵：一是盡早和經常交付，二是理解每一個項目群和價值流的經濟平衡參數。這兩個方麵在下文中有詳細描述，此外，SAFe將這些原則在各種實踐中進行了實例化，這也是6.3節所闡述的主題。
盡早和經常交付
一般來說，企業做出精益–敏捷轉型的重大決策，是由於當前流程不能滿足生產的需要，或者是他們認為當前流程將來會被取代。在選擇精益–敏捷的道路上，通常是使用基於增量式的模型，盡早和持續交付價值，如圖2.1-1所示。
這樣的決策將會產生顯著的，或許是最基礎的經濟效益，如圖2.1-2所示。
圖2.1-2展示了在這種流程中價值可以盡早交付給客戶。而且，這些價值可以多次集成，客戶持有時間越久，得到的價值就越大。
在瀑布模型中，價值無法在項目早期交付，而隻能按照計劃在開發周期結束時得到交付。這種差異也展示了使用SAFe的經濟效益。此外，圖2.1-2還展示了在瀑布模型中，並沒有考慮解決方案構建者快速得到反饋的收益，而且最終能夠按時交付並滿足要求的概率也會比較低。最後，還有第3個因素最為重要，如圖2.1-3所示。
圖2.1-1 盡早和持續交付
圖2.1-2 增量開發和交付能盡早產生價值
圖2.1-3 早期價值更高，可以在更長的時間內產生更大的收益
圖2.1-3展示了一個關鍵的差異化優勢：隻要質量滿足要求，產品越早投入市場，價值就越高。畢竟，如果足夠早的話，競爭對手還沒有提供相應的產品，因此客戶就願意花更多的錢來購買。隨著時間的推移，產品就會進入同質化和價格競爭，也就沒有了價值差異化，這就是產品發展規律。這就意味著即使是在早期提供給客戶最小可行產品（MVP），也比在後期提供全麵的功能更有價值。所以產生的效果是，方案構建者的累積總利潤就會更高。這是精益–敏捷開發的基本前提，也是精益–敏捷思維實施的堅實基礎，更是解決方案構建者爭取最短的可持續前置時間的驅動力量。
理解經濟平衡的參數
上述討論的主要問題，驅動著解決方案構建者使用這種更加經濟有效的模型更快速地交付價值。然而，當執行項目群時仍然有很多工作要做，而且在解決方案生命周期中的經濟決策也將最終決定交付的成果。因此，有必要更深入地討論多種經濟參數的平衡。Reinertsen（參考資料[1]）描述了5種基本參數，可以用於站在經濟角度考慮特定的投資情況，如圖2.1-4所示。
對5種參數的解釋如下。
開發費用：是指為了實現某種能力所需要的人力和物料成本
周期時間：是指為了實現某種能力的時間（前置時間）
產品成本：是指製造（銷售成本）、部署和運營的成本
價值：是指所實現的能力對業務和客戶的經濟價值
風險：是指解決方案中技術或業務可行性的不確定性
理解經濟平衡的參數，有助於優化生命周期的收益——這也是處理開發中最佳經濟價值的關鍵。但是，這需要對項目有更深刻的理解，以下是兩個例子：
1.一個團隊正在構建一個家庭自動化係統，據估計可以通過增加更多的軟件功能減少100美元的電子部件的成本，但是可能會延遲發布前置時間3個月。那麼團隊應該執行這個項目嗎？顯然無法簡單給出答案。這取決於產品預期的銷售量和如果推遲3個月發布產品的延遲成本之間的對比。在做出決策之前，還需要做進一步的分析。
2.一個大型軟件係統，如果有大量的技術債務，是很難進行維護的。而且開發費用是嚴格固定的。如果專注於現在的技術債務，在短期內將會減慢價值交付，但是從長期來看，會有利於減少將來的特性交付的前置時間。那麼團隊應該采取這種措施嗎？同樣，也無法簡單給出答案，它取決於定量地分析更多的要素，再做出決策。
除了經濟平衡的參數，Reinertsen還介紹了一些關鍵的原則，有助於團隊從經濟的角度出發做出堅實的決策。這些原則如下所述：
量化延遲成本的原則——如果你隻對一件事進行量化分析，那就是延遲成本
持續經濟平衡的原則——經濟有效的選擇必須持續不斷地進行
最佳決策時間的原則——每一個決策都有它的最佳經濟時間
沉沒成本的原則——不要考慮已經花費的成本
第一決策規則的原則——使用去中心化經濟控製的決策規則
以上最後一個原則與SAFe緊密相關，可以推導出SAFe的原則#9——去中心化的決策，該原則將在6.3節進一步描述。
參考資料
[1] Reinertsen, Donald. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.
2.2 原則#2——運用係統思考
係統是必須被管理的，它不會進行自我管理。如果讓其自我管理，各個組件就會變得自私、相互競爭，成為彼此獨立的利潤中心，從而破壞整個係統。係統管理的奧秘就是麵向組織目標，協調各個組件之間的合作。
——W.愛德華茲·戴明
戴明是世界上最著名的係統思想家之一，他一直專注於研究人們構建和部署各類係統時所麵臨的問題和挑戰，這些係統包括：製造係統、社會係統、管理係統，甚至政府係統。一個核心的結論是，在員工開展工作的係統中所麵臨的問題，是由一係列複雜的相互作用的因素驅動的，而這種複雜性往往是被低估的。從更大的係統視角切入，是解鎖係統奧秘的關鍵，並能提高開發流程和產品與服務質量，這也是係統的目標。
解決方案就是一個係統
SAFe的目的就是幫助係統構建者實現最短的可持續前置時間，以及對人類和社會交付最好的質量和價值。因此，主要的焦點就是係統——大型、炫酷、新奇的事情。在這裏，係統是必須被管理的，以下是一些關鍵點：
係統構建者必須清晰理解係統的邊界是什麼，係統自身是什麼，係統如何與周圍的環境和其他係統進行交互，以及係統內的組件如何進行交互從而達成係統的目標，最終服務於客戶的需要。
僅僅優化一個組件是無法優化係統的，相反，係統必須進行整體優化。係統構建者們必須確保組件不能隻顧及自己的利益，也不能獨占所需要的資源（比如計算能力、內存、電力供應等）和其他要素。
為了讓係統的行為表現良好，就必須在實施之前對其有清晰的了解，比如意圖架構和非功能性的係統行為。
一個係統的價值會通過其連接部件進行傳遞，比如接口和接口之間的依賴關係，這些連接部件是提供最終價值的關鍵要素。
一個係統的進化速度取決於係統中最慢的集成點。完整係統的集成和評估越快，係統掌握的實際知識的增長速度就越快。
構建係統的企業也是一個係統
運用係統思考帶給我們的重要的、必然的結果是：構建係統的企業也是一個係統。企業的員工、管理層和職能行政部門，組成了構建係統的係統。
同樣，係統思考的警示在企業係統中也適用，否則也會造成研發和產品係統的各個組件隻考慮自己的利益，互相幹擾價值交付和經濟效益。這也產生了另外一組對係統思考的關鍵理解：
價值跨越組織邊界。想要加快價值傳遞，就需要消除職能筒倉，或者創建可以更好交付價值的虛擬組織。
建立複雜係統是一種社會性工作。係統構建者們必須創造一種環境，使人們可以通過最優的合作方式構建最好的係統。
供應商和客戶都是價值流不可或缺的組成部分。他們必須被視為合作夥伴，建立長久的信任基礎。
領導者必須具備長遠眼光，今天做出的決策會影響未來的結果。為提升能力進行投資，比如基礎設施、實踐、工具和培訓，為未來的價值交付和質量與生產力的進步奠定基礎。
隻有管理能夠改變係統
戴明曾提出過一些相關結論（參考資料[1]）：“每個人都已經盡了最大努力，問題存在於係統之中”“隻有管理能夠改變係統”。
這也為我們提供了最終的理解：係統思考需要采取一種新的管理方式，即經理是問題解決者，他們具備長遠的係統視角，並且積極清除障礙。精益–敏捷管理者同時也是老師，他們的工作如下：
展示和教授精益、敏捷和係統思考的價值觀、原則和實踐。
消除職能筒倉，清除障礙，促進流動。
建立長期有效的供應商和客戶關係。
持續不斷地致力於問題解決和清除障礙。
使用和教授根本原因分析與糾正措施技術。
授權知識工作者，釋放其內在動力（原則#8）和去中心化的決策（原則#9）。
成為團隊的夥伴，共同實現關鍵裏程碑，幫助團隊識別和解決問題。
理解係統思考的方方麵麵，有助於領導者和員工真正明白他們所做工作的目的和內容，以及對周圍的影響。反過來，這也會形成一個更加智慧的企業，可以更好地處理組織結構和解決方案研發的複雜性，從而提升經濟效益。
參考資料
[1] Deming, W. Edwards. The New Economics. MIT Press, 1994.
2.3 原則#3——接受變異性，保留可選項
創造係統級設計和子係統概念的多種可選方案；而不是過早地選擇一個勝出方案，然後消除與之不同的其他可選項。隻有那些存活下來的設計選項，才是最強大的可選方案。
——艾倫 C.沃德，《精益產品和流程開發》
係統構建者們都會傾向於減少變異性。表麵上看起來，你認為自己知道的越多並且已經做出相應的決策，你就會走得更遠。但事實往往並非如此。雖然變異性會導致糟糕的結果，但有些時候也不盡然。變異性的自身無所謂好與壞。相反，是由於時間的經濟效應和變異性的類型決定了最終的結果。如果過早地專注於消除變異性，可能會導致企業萌生厭惡風險的文化，這樣員工也就不能通過試錯和學習來獲取經驗。
精益係統構建者們認識到，在項目的早期除了一些基本的係統目標之外，對項目的實際情況知之甚少。確實，如果能掌握所有信息，那麼係統早就構建成功了。然而，傳統的設計方法往往讓開發人員迅速地開始實現一個單一的方案——而這個方案僅僅是眾多潛在解決方案中的一個——然後再通過修改設計，直到最終滿足係統的目標。這也許是一個很有效的方法——當然，前提條件就是最初所選擇的單一方案不能有誤——然後再通過後續的迭代進行細化，但是最終可能需要花費很長時間才能得到一個並不是最佳設計的解決方案（參考資料[1]）。
如果最初選擇的單一方案不是最優的，那麼後果就是：係統越大、越需要技術創新，所帶來的損失也會越大。一個更好的方法是，可以參考使用基於集合的設計（多個設計構成一組）或者基於集合的並行工程（多個並行工程構成一組）（參考資料[2]），如下圖所示。
在基於集合的設計中，係統構建者們最初會考慮非常廣泛，提出多種設計選項。接下來，他們持續地評估經濟效益和技術難度之間的平衡，在集成的學習點上，可以演示與目標的匹配情況。然後，基於演示的結果和所獲取的經驗，去除那些不太好的選項，收斂到一個最終的設計。
采取這種流程，可以讓設計選項的持續時間盡可能延長，在必要的時候進行收斂，並最終產生更優的技術實現和經濟效益。
參考資料
[1] Iansiti, Marco. “Shooting the Rapids: Managing Product Development in Turbulent Environments.” California Management Review 38 (1995): 37–58.
[2] Ward, Allan C. and Durward Sobek. Lean Product and Process Development. Lean Enterprise Institute Inc., 2014.
2.4 原則#4——通過快速集成學習環，進行增量式構建
產品的集成點，是控製產品開發和提升係統的關鍵支點（杠杆點）。如果沒有處理好集成點的時間，項目就會陷入困境。
——Dantar P. Oosterwal
增量式構建係統
在傳統的方法中，根據“階段–門限”進行開發，項目一開始就立刻投入成本，隨後成本逐漸累積直到最終方案得以交付。通常，在項目執行期間極少交付實際價值，而是直到所有功能完成後才在最後一次性交付價值，有時候項目也會麵臨時間延期或者成本超支的問題。在開發過程中，一般很難收集到有意義的反饋，因為流程並不支持反饋收集；而且係統也並沒有按照客戶需求和能力的逐步提升進行相應的增量式設計和實現。風險在項目執行中會一直存在，直到項目結束，有時候甚至會進入到部署和客戶最初使用環節。這種流程所導致的錯誤和問題，往往會破壞係統構建者和客戶之間的信任關係。其實，係統構建者和客戶也在努力調整這些問題，他們會在項目早期進行需求定義，並選擇“最好的”設計，他們也會執行更加嚴格的“階段–門限”評審。但是，使用這種流程所生成的解決方案，總會產生一些潛在的問題。這是開發流程中存在的一個係統級別的問題，所以必須從係統化的角度去解決這個問題。
集成點可以從不確定性中獲取知識
精益係統構建者解決問題的方式與上述方法有所不同，他們並不是在項目早期選擇單一的需求和設計方案，也並不假設這些設計是完全可行和滿足要求的，相反，他們會基於一定範圍的需求和多種設計選項（原則#3）進行一係列短周期（時間盒）的增量式解決方案構建。每一個時間盒都會產出一個可工作係統的增量，可以交給係統構建者和客戶進行評審。後續的時間盒會在之前增量的基礎上，逐漸交付演進的解決方案，直至最後發布。在集成點上，獲取經驗知識不僅僅是為了技術可行性研究，也可以得到最小可行解決方案或者原型，供市場驗證、建立可用性、獲取客戶反饋等。在必要的地方，這些快速反饋點允許係統構建者找到一個采取下一步方案的“支點”，從而可以更好地服務於目標客戶的需要。
根據意圖設置集成點
基於節奏的集成點逐漸成為係統構建者的主要關注焦點，它可以根據特定的目標設計相應的開發流程和解決方案架構。每一個集成點都會創建一個“拉動事件”，拉動各種方案要素進行整體集成，即使隻解決了係統的一部分目標也會進行集成。集成點也會將利益相關者拉動到一起，定期的同步有助於確保方案的演進，從而解決真正的問題和當前的業務需要，而不是僅僅依賴於在項目開始時建立起來的假設。每一個集成點都會根據技術可行性和當前的設計選項，將不確定性轉化成經驗知識，進而交付一定的價值，而且對於解決方案潛在可行性的經驗知識，都是基於目標進行度量的（原則#5）。
通過更快的周期進行更快的學習
集成點是休哈特（shewhart）PDCA（Plan-Do-Check-Adjust）循環（參考資料[3]）的一個實例，因此它可以作為控製解決方案開發中變異性的主要機製。
集成點越頻繁，學習速度就越快。在複雜係統開發中，本地集成點用於確保係統中的每個元素和能力都能夠服務於滿足整體解決方案的目標，它也必須進一步集成到更高的係統級別中。係統規模越大，集成的層級就越多。係統構建者們明白：最高層級的、發生頻率最低的集成點，提供了度量係統進展的唯一標準，他們也在努力盡可能多地實現這些集成點。所有的利益相關者也明白：如果集成點的時間沒有控製好，項目就會陷入困境。但是即便是這樣，及時獲取經驗知識也會有助於促進對範圍、技術方法和成本的必要調整，也有助於更新交付時間讓項目可跟蹤，從而調整客戶的預期。
參考資料
[1] Oosterwal, Dantar P. The Lean Machine: How Harley-Davidson Drove Top-Line Growth and Profitability with Revolutionary Lean Product Development. Amacom, 2010.
[2] Ward, Allan C. and Durward Sobek. Lean Product and Process Development. Lean Enterprise Institute Inc., 2014.
[3] Deming, W. Edwards. Out of the Crisis. MIT Press, 2000.
2.5 原則#5——基於對可工作係統的客觀評價設立裏程碑
實際上，按時進行“階段–門限”交付與項目的成功並無關係。但有些數據表明，反過來卻是相關的，即成功的項目都是按時進行階段交付的。
——Dantar P. Oosterwal，《精益機器》
“階段–門限”裏程碑的問題
現在，對於大係統的開發需要進行大量投資，可以達到數百萬、上千萬，甚者過億美元的投入。係統構建者和客戶有義務共同確保對於新的解決方案的投資可以提供必要的經濟收益。否則，就沒有理由進行相應的投資。
顯然，利益相關者必須進行協作，幫助確保預期的經濟效益貫穿在整個開發過程中，而不僅僅是“一廂情願”地認為在最終可以達到美好的結果。為了應對這一挑戰，工業界引入了“階段–門限”（瀑布式）的開發流程，這種流程會通過對一係列確定的裏程碑進行度量和控製。而且這些裏程碑也不是任意設置的，它們遵循一定的邏輯性和一係列的流程（發現、需求、設計、實現、測試和交付）。當然，這種裏程碑的設置方法並沒有獲得好的收效，如圖2.5-1所示。
圖2.5-1 “階段–門限”裏程碑的問題
導致這個問題的根本原因是沒有認識到在“階段–門限”顯示的真實進展情況和消除風險的過程中，犯了四個關鍵的錯誤：
1.將需求集中起來，同時進行職能筒倉式的設計決策，導致了在後續的解決方案構建過程中缺乏完整性。
2.過早的設計決策和“虛假的可行性”（參考資料[1]）：一個早期的選擇是在當時做出的最佳選擇，隨後開發流程就假設一切按照計劃進行，直到最後才發現最初的選擇是不切實際的（原則#3）。
3.假設存在一個確定的解決方案，而且隻進行一次嚐試就可以構建成功。這樣就忽視了流程中固有的變異性，並且沒有提供有效的處理方法。改變將是遲早的事。變異性遲早是要表現出來的。
4.在前期就進行決策，創建了大批量的需求、代碼和測試，形成了很長的隊列。這也導致了大量的工作交接和延遲的反饋（原則#6）。
基於客觀事實設立裏程碑
顯然，“階段–門限”模型並沒有像預期的那樣降低風險，所以就需要一種不同的方法。原則#4（通過快速集成學習環，進行增量式構建）提供了解決這一困境的一些要素。
在整個開發過程中，係統進行增量式的構建，每一次構建都是一個集成點，在集成點上可以演示一些已經實現的內容，以驗證當前解決方案的可行性。與“階段–門限”開發方法不同，基於客觀事件所設立的每一個裏程碑都包含研發的所有步驟（需求、設計、開發、測試），從而達到增量式的價值交付，如圖2.5-2所示。此外，這種裏程碑會基於節奏進行（原則#7），一個固定的節奏可以形成一種紀律，確保定期提供可用性和評估，同時能提前確定時間邊界，也可以用來去除那些不太理想的選擇。
圖2.5-2 基於對可工作係統的客觀評價設立裏程碑
在關鍵的集成點上要對哪些要素進行有效的度量呢？這取決於所要構建係統的類型，但是利益相關者可以在整個解決方案開發周期內，頻繁地對係統進行度量、評價和評估。這樣可以提供財務、技術和符合目標的組織治理，從而確保持續的投資可以產生與之相匹配的回報。
參考資料
[1] Oosterwal, Dantar P. The Lean Machine: How Harley-Davidson Drove Top-Line Growth and Profitability with Revolutionary Lean Product Development. Amacom, 2010.
2.6 原則#6——可視化和限製在製品，減少批次規模，管理隊列長度
接近滿負荷地使用產品開發流程是一場經濟災難。
——Donald Reinertsen
為了實現可持續的最短前置時間，精益係統構建者們努力實現持續流動的狀態，即新的係統可以迅速地從概念到盈利。實現持續流動需要消除傳統方法中的基於“開始–完成–開始”的項目啟動和開發流程，也要消除阻礙流動的現行“階段–門限”的方法（原則#5）。
實現流動的三個關鍵點是：可視化和限製在製品，減少工作項的批次規模，以及管理隊列長度。
可視化和限製在製品
團隊和項目群的工作過載，任務量超出了他們所能承擔的範圍，這是一個常見且有害的問題。係統中如果在製品（Work in Process，WIP）過多，就會導致人員複用和頻繁地在不同工作場景之間進行切換。這種情況會使員工工作過載，減少了對正在執行任務的專注度，降低了生產力和吞吐量，並增加了交付新功能的等待時間。
第一步是讓當前的在製品對所有利益相關者清晰可見。這個可視化說明了在每一個步驟的工作總量，也作為對初始過程的診斷，並顯示出當前的瓶頸。在某些情況下，僅需簡單地可視化當前的工作，就可以喚醒開發人員，讓他們開始意識到要解決同時開展工作太多而沒有形成流動的問題。下一步就是處理在製品數量和可用開發容量平衡的問題。如果在執行過程中達到了在製品的上限，就不再承接新的工作任務。
然而，限製在製品是需要有知識、有紀律和有承諾的。甚至有些時候是看起來是反直覺的，比如以前有些人認為放入係統的工作越多，完成得就越多。在一定程度上這是正確的，但是如果超出了一定的限度，係統就會變得動蕩，也會降低流動性。這說明，有效的在製品管理是不可取代的。
減少批次規模
減少在製品和提高流動性的另一種方法是減少工作的批次規模，這些工作包括需求、設計、編碼、測試和其他相關工作。簡單地說，小批量通過係統的速度更快，變異性更小，並能夠促進快速學習。顯而易見，因為隨著批次規模的增加變異性是累積增加的，所以批量越小速度越快。
從經濟的角度上來看，最優的批次規模依賴於持有成本（延遲反饋和價值交付帶來的成本）和交易成本（實現和測試的成本）。如圖所示，說明了“U型曲線”是批次規模的最優曲線（參考資
料[1]）。
為了提高處理小批量的經濟效益，從而增加吞吐量，主要的工作重點需要聚焦在減少批次的交易成本上。通常包括更加關注在基礎設施和自動化上的投資，比如持續集成和構建環境、DevOps自動化，以及係統測試的配置時間。以上這些都是與係統思考的融合（原則#2），也是進行長期優化的關鍵要素。
管理隊列長度
實現流動性的第三個措施是管理隊列長度（一般來說是減少隊列長度）。利特爾法則（基於排隊論的法則）告訴我們，係統提供服務的等待時間等於隊列的長度除以平均的處理效率（這可能看起來很複雜，可是在星巴克排隊買咖啡的時候也會用到這個公式）。因此，假設平均的處理效率一定，隊列越長，等待時間越長。
對於解決方案開發來說，這意味著無論團隊多麼有效地處理工作任務，隻要團隊實現的工作任務隊列越長，那麼等待時間就越長。如果你需要更快地完成，就必須減少隊列的長度或者提高處理效率。雖然提高處理效率是我們都希望達到的共同目標，但是減少等待時間最快的方式是減少隊列長度。在工作中，可以通過保持較短的待辦事項列表和並不過多進行承諾來做到這一點。同時，可視化工作可以極大地幫助過程改進。
減少隊列長度可以減少延遲、減少浪費，增進對於成果的可預測性。可視化和限製在製品，減少批次規模和管理隊列長度，這三種方式對於提高吞吐量非常有效。通過采取這些方式，可以在客戶滿意度和員工參與度方麵達到快速和可衡量的改進，對係統構建者及其客戶也可以帶來全麵的經濟效益。
參考資料
[1] Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas, 2009.
2.7 原則#7——應用節奏，通過跨領域計劃進行同步
節奏和同步可以限製變異性的累積。
——Donald Reinertsen，《產品開發流的原則》
解決方案開發在本質上是一個內在不確定的過程。否則，解決方案早就已經存在了，下一代解決方案的創新也就沒有空間了。這種內在的不確定性與企業活動是相互衝突的，比如企業活動需要管理投資、跟蹤進展、對於未來成果有足夠的把握，從而製訂計劃和承諾一個合理的行動實施。解決方案開發總是處在一個十字路口，它有自己的難題，即交付成果的不確定性和企業需要業務的確定性之間的衝突。這或許正是它的魅力所在。
精益係統構建者需要在安全的環境中工作，這種環境需要有足夠的不確定性提供創新的自由，同時也有足夠的確定性保證企業運營。實現以上結果的主要方式是，真正了解當前所處的狀態。而應用節奏、同步和跨領域計劃，恰恰有助於對當前狀態的了解。
節奏
節奏是流程中可靠的心跳，可以提供一種優雅的節拍模式。節奏讓常規工作有規律地進行，從而使係統構建者可以利用其知識能力管理那些可變的要素。節奏能使不可預測的要素變得可預測，並帶來了很多益處：
使等待時間可預測，如果你所需要的工作交付物不在當前的這個時間盒內，那麼可能就會在下一個時間盒內。
引導計劃活動，使資源使用更加有效。
提供了一個強製函數，同時降低了關鍵活動的交易成本，這些活動包括計劃、集成、演示、反饋和回顧等。
同步
同步可以在同一時刻從不同的角度出發，進行工作任務的理解、解決和集成。
同步用於如下內容：
將係統中的不同資產進行整合，以評估解決方案層級的可行性。
將開發團隊和業務團隊的共同使命協調一致。
將客戶融合到開發的流程中。
總之，節奏和同步，以及其他重要的相關活動，共同幫助係統構建者在不確定的安全環境中可靠地開展工作。
通過跨領域計劃進行同步
在SAFe的所有活動中最關鍵的一環是：所有的利益相關者定期聚集在一起進行跨領域的計劃和同步。這項活動（即SAFe中的發布計劃會議）是所有其他活動的支撐，它也是一個全員會議，用於展示當前的真實狀態。發布計劃會議的三個主要目的是：
1.評估解決方案的當前狀態——通過集成和解決方案級別的演示與評估，確定當前狀態的目標。這項活動通常是在計劃會議之前進行。
2.再次對齊所有利益相關者的共同技術和業務願景——基於當前狀態，業務領導和技術領導一起重新設定使命，考慮最小可能的限製條件（原則#8和原則#9）。這項活動用於對齊所有利益相關者的近期和遠期願景。
3.對下一個項目群增量進行計劃和承諾——基於達成的新共識，團隊對於在接下來的時間盒內要完成的工作進行計劃。計劃和控製的分布式進行，可以授權團隊在給定的約束條件下，為達到最佳可能的解決方案創建出最佳可能的計劃。
大型係統的開發從根本上來講是一種社交活動，這種計劃活動為建立和完善社交網絡提供了一個持續的機會。
解決方案開發的內在不確定性是無法治愈的。如果可以治愈，那麼治愈的結果可能比原來的疾病更糟糕。然而，應用節奏和同步，定期地進行跨領域計劃，為精益係統構建者提供了在安全環境中開展工作所需要的各種工具。
參考資料
[1] Reinertsen, Donald. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.
[2] Kennedy, Michael. Product Development for the Lean Enterprise. Oaklea Press, 2003.
2.8 原則#8——釋放知識工作者的內在動力
看起來，任務的績效提供了內在的獎勵……這種驅動力……可能與其他元素一樣，都是基礎……
——丹尼爾·平克，《驅動力》
精益–敏捷領導者工作在一個相對較新的環境中，對於知識工作者的“管理”其實是一個自相矛盾的說法。正如德魯克指出的：“知識工作者比他們的老板更了解自己所從事的工作”（參考資料[2]）。在這種情況下，員工完全有能力自己定義必要的活動以達成他們的目標，那麼經理們如何進行管理，並協調技術活動呢？
事實上，經理們無法進行管理。相反，經理們能做的是釋放知識工作者的內在動力。下麵將介紹一些實施指導。
利用係統視圖
在進一步了解相關的激勵元素之前，我們需要注意存在一個重要的理解，那就是需要理解SAFe的精益–敏捷原則本身也是一個係統。這個係統的元素相互協作，創建了一個新的授權模式，知識工作者可以跨越職能的邊界進行溝通，基於對經濟效益的理解進行決策，對於有效的解決方案實現快速反饋，參與持續和增量式的學習並提高掌控能力，更多地參與解決方案開發的過程。這就是最強有力的激勵因素之一。
了解薪酬的作用
許多組織的運作仍然基於那些已經過時的、對人員潛力和員工績效的假設，而且大多基於傳統觀念而不是科學。這些組織繼續追求的做法是，短期激勵計劃和按照證據的績效工資支付方式，但實際上這種度量方式並不奏效，甚至會帶來危害（參考資料[1]）。
丹尼爾·平克（參考資料[1]）和彼得·德魯克（參考資料[2]）以及其他一些學者，指出了知識工作者的薪酬激勵因素的一個基本悖論：
如果企業不能支付足夠的工資，員工就不能被激勵。低薪酬是致使動力下降的主要原因。
但是，如果達到了一個臨界點，工資就不再是一個長期的激勵因素了。這個臨界點就是知識自由和自我實現。也就是說，知識工作者可以無償地專注在工作上，而不是金錢上。
如果達到了這個臨界點，增加薪酬反而會變成一個致使動力下降的原因。這可能會成為對知識完整性的一種褻瀆，從而讓員工把注意力隻是放在金錢而不是工作上。
精益–敏捷領導者都很清楚，知識工作者的構想、創新和在工作場所中深入參與工作，是無法用金錢來激勵的，也不會被威脅、恐嚇和恐懼所脅迫。那種基於激勵的報酬，往往體現在個人的目標管理上（MBO），會導致內部競爭，甚至有可能破壞必要的合作，乃至無法實現更宏偉的目標。如果這樣的話，企業就會在競爭中失敗。
提供目標、使命和最小可能約束的自主性
《驅動力》（參考資料[1]）同樣也“驅動了”一個不爭的事實，即知識工作者需要具備自主性——也就是他們與生俱來的自我指導和自我管理的能力。提供自主性，同時把它作為大型企業發展的目標，這一點是領導者的重要職責所在。
經理們和員工們也都知道，自我指導的動力必須存在於更大的目標中。所以，領導者們需要提供一些更大的使命——把員工的日常工作和企業的發展目標聯係起來。
在構建係統時，知識工作者作為團隊的一部分參與其中，所以，成為高績效團隊的一員同樣也是激勵的另一個維度。領導者可以通過以下方式鼓勵團隊做到最好（參考資料[4]）。
確立使命感：要有一個概要的目標和戰略方向，同時也是一個強烈的願景。
對於具體工作和項目計劃，僅給出少量的、最小化的指導，甚至沒有任務說明和計劃。
對於需求和最小可能的約束條件進行檢查，由團隊決定如何實現這些需求
營造一個平等互助的環境
“如果要做到有效地領導，就必須尊重員工並傾聽他們的聲音”（參考資料[2]），而且是在相互平等的環境中（參考資料[4]）。領導者可以營造一個良好的環境，他們可以對員工給予及時的反饋、放下自己的職權影響力，並鼓勵員工按照如下的方式開展工作：
在恰當的地方提出不同意見。
鼓勵員工堅持自己的立場。
讓員工清晰自己的目標並努力達成。
促進管理者和員工共同解決問題。
協商、共識、同意和承諾。
當前的係統構建者生活在一個嶄新的時代，這個時代的特點是員工更加智慧，在具體的工作中比管理者具備更多的知識。釋放這種潛力是改善員工活力的一個重要因素，同時也可以為客戶和企業達成更好的成果。
參考資料
[1] Pink, Daniel. Drive: The Surprising Truth About What Motivates Us. Riverhead Books, 2011.
[2] Drucker, Peter F. The Essential Drucker. Harper-Collins, 2001.
[3] Bradford, David L. and Allen Cohen. Managing for Excellence: The Leadership Guide to Developing High Performance in Contemporary Organizations. John Wiley and Sons, 1997.
[4] Takeuchi, Hirotaka and Ikujiro Nonaka. “The New, New Product Development Game.” Harvard Business Review. January 1986.
2.9 原則#9——去中心化的決策
由知識工作者自己來決定如何開展自己的工作，這是最佳的方式。
——彼得·德魯克
正如我們在精益之屋中所指出的，目標很簡單：在可持續的最短前置時間內交付價值。如果要實現這個目標，就需要快速的、去中心化的決策。任何需要上升到領導層進行的決策，都會帶來延遲，也會導致決策的保真度降低，這是因為缺乏對具體環境的考慮，再加上在等待時間內會發生各種變更。去中心化的決策可以減少延遲，提升產品開發的流動，並能更快反饋和做出更多創新性的解決方案。
然而，這也並不是說所有的決策都是去中心化分散進行的。有一些決策是戰略性的、至關重要的、長期有效的，這些決策最好是集中進行，而且應該被進行管理。由於這兩種決策（中心化集中決策、去中心化分散決策）都是存在的，所以要確保價值可以順利地流動到客戶那裏，建立一個明確的決策框架是至關重要的一步。
戰略性決策集中進行
雖然員工作為知識工作者獲得了授權進行決策，但是這並不能替代管理層對戰略決策和最終成果所擔負的責任。經理之所以能夠處於管理崗位上，是因為他們具有資深的市場經驗，他們具有更長遠的技術視野，他們被委以重任並理解財務狀況，從而能夠引導企業獲得正確的業務成果。所以，經理們可以也應該有權做出這些高層次的決策。
這些集中進行的決策特點是：發生頻度不高、長期有效、對於經濟效益有重大影響。
其他非戰略性決策分散進行
然而，絕大多數的決策並沒有達到需要進行戰略性決策的高度。這些決策發生的頻度很高，通常時間上很緊急，但是沒有重大的經濟效益的影響。
這些決策就可以授權團隊分散進行，因為團隊更加了解具體的執行情況和環境，也具備解決技術複雜度的詳細知識，而且他們的日常工作就是在一線解決這些具體問題和交付價值。
建立決策框架
領導者授權團隊進行決策，並不意味著他們對於決策的成敗可以袖手旁觀。為此，企業應該建立一個可以在不同層級上進行決策的框架。決策框架基於並屬於經濟框架（原則#1）
的一部分，是考慮了決策背後的邏輯性和經濟合理性而建立起來的，決策框架可以授權包括個人和團隊內的各種角色，進行決策的製訂和實施。
一個有效的決策框架可以為企業帶來許多益處，比如更快的上市時間、更高質量的產品和服務。有效的決策框架還有助於釋放知識工作者的內在動力（原則#8），從而帶來更高的員工參與度和更好的員工滿意度，進而有助於帶來企業績效和企業文化非常顯著的提升。
參考資料
[1] Drucker, Peter F. The Essential Drucker. Harper Collins, 2001.
[2] Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.
最後更新：2017-05-19 16:02:13