近五年來， Agilean 一直在幫助某大型股份行實施精益看板轉型。從全面導入到落地深化，從基層賦能到量化改進，該行目前電子看板使用率已達90%，為國內領先水平。在此過程中，我們將精益思想和看板方法進行了更有機的貫通，形成了一個幫助企業快速提升研發效能的改進體系 FLEET（精益效能提升思維框架，Framework of Lean Efficacy Enhancement Thinking）。我將結合落地經驗，對FLEET進行全方位闡釋。
以下為FLEET 的的6條核心思路：
- 看見：高效知識工作的最大敵人，是知識工作過程和成果的不可見性。首先要利用看板可視化，構造管理現場；
- 整流：由於知識工作「不可見」，處理過程中很容易造成工作擁堵。建立需求優選機制，減少並行工作，可以保持專注，提升流動效率；
- 細粒：進行整流之後，如果需求顆粒度過大，需求也無法快速流動。這就要進一步減小需求顆粒度，從而加速流動，提升質量反饋速度；
- 潤滑：需求交付質量低會造成返工，加劇需求並行度，使彼此之間產生「摩擦」。強化需求澄清、質量前移等質量活動，可以減小需求間的摩擦，緩解過程中的阻力；
- 小批：定期的需求選擇會、澄清會、版本移交等批量活動，會減慢端到端的流動速度，造成等待。應儘量減小批量，減少等待時間；
- 降本：交易成本是批量存在的根本原因。通過推進自動化迴歸測試、自動化部署等活動，降低交易成本，使批量減小成為可能。
Agilean 精益研發管理 FLEET 框架
看見：為管理者構造管理現場
知識工作管理者通常會有一種焦慮感，管的人越多越容易焦慮。在諸多原因中，缺乏有效的可視化管理手段是重中之重。越看不清，就越躊躇，越催生焦慮。陷入焦慮的管理者，往往採用更嚴格的管理手段，又引起下屬更多遮掩和隱瞞，工作狀態的不可見被進一步強化，從而形成一個惡性循環。
與製造業相比，知識工作可視化要求不同
在斯坦利•麥克里斯特爾（前美軍特種作戰司令部指揮官）所著的《賦能》一書中，作者提出一個很好的思路：“雙眼緊盯，雙手放開”。能夠做到雙眼緊盯，才敢把雙手放開。FLEET 的第1個核心思路——用看板實現知識工作的可視化，便是要賦予管理者“看見”的能力。經過良好設計的看板，可以為研發團隊管理者提供重要的管理現場。下圖是我在2014年輔導的一個創新項目研發看板，該項目在4個月內完成了一個創新金融 APP 從0到1的過程。「可視化」實踐裡最大的挑戰，在於對團隊實際工作情況進行價值流的梳理和建模。
一個創新金融項目可視化看板實例
整流：建立需求優選機制
請看下圖並回答：直覺上，你覺得這是什麼地點？
第一感覺，這是什麼地方？
在其它城市培訓時，學員往往認為是火車站；生活在北京的學員卻一眼看出，這是龍澤或西二旗地鐵站。站外的鐵欄杆就是地鐵系統的整流措施——雖然讓個體多走了些路、多了些等待，卻保證了整體（每個個體）花更少時間候車。
在長期不可見的情況下，大多數研發團隊處於高並行的過載狀態，其特點就是持續打斷、大量並行。有研究表明，軟件研發的流動效率通常只有1%-5%。在流動效率很低的研發過程中，必須引入需求優先機制，即優先級選擇。以下圖看板為例，“開發”列之前為“選擇”隊列（紅框），將積壓需求停留在研發系統之外，避免進一步加劇流程中的阻塞，確保研發流程得以快速優化。
建立需求優選機制，將積壓擋在研發系統之外
小團隊比較容易建立需求優選機制。對大型組織而言，建立需求優選機制的主要挑戰，在於如何有效平衡各業務方的訴求。我們在實踐中發現，部落制是解決這個問題的有效方式。將研發組織和業務組織拉通（可採用虛擬方式），將研發資源合理分入不同部落、面向不同業務方，然後在部落內建立合適的需求優選機制。
P.S. 流動效率、部落制等話題均較複雜，未來我們將專文詳述。
細粒：需求拆分加速流動
需求優選機制運行起來後，下一個改進點是減小需求顆粒度，將需求拆分成更小的可驗收可測試單元。規模過大的單元，不利於透明其執行過程中的等待、阻塞和風險。對於大型組織，我們建議採用需求、系統任務、個人任務的三級體系，系統任務控制在10人天，個人任務拆至2-3人天。
下圖為之前提到的創新項目快速啟動現場（研發正式開始前的啟動環節，通常為2-3天）。業務和IT共同拆出350多個粗粒度用戶故事，據此制定了迭代計劃和關聯繫統計劃，完成看板建模，形成風險應對方案。團隊在其後的三個月裡完成6個迭代，項目準時上線，產品內容、功能和質量都獲得了高度認可，在當年贏取了國內若干重要銀行獎項。
一個創新項目實例
潤滑：降低需求摩擦
需求顆粒度減小後，通過降低需求彼此之間的摩擦，可以讓研發過程流動更加順暢。什麼是需求摩擦？看圖——
需求摩擦的常見場景
這段對話熟悉嗎？對不少研發同學來說，本來正在做A需求，中間被叫去評審B需求，過會兒又要修改C需求的缺陷，需求之間就產生了摩擦。有很多方法可以降低需求之間的摩擦：
- 實例化需求，提升需求初始質量；
- 產品經理制度，專人負責與業務澄清需求；
- 需求研發雙迭代，需求澄清迭代和研發迭代並行，澄清迭代的輸出是研發迭代的輸入；
- 建立開發自冒煙制度、代碼評審制度，提升初始移交質量，減少測試摩擦。
小批：盡一切可能減小批量
加速流動的一個有效方法是減小批量。「批量」指在某些環節中多件事情一起處理，比如多個需求一起澄清，多個設計一起評審，多個功能一起上線，這些都是批量。批量必然導致一些需求等待另一些需求，減慢端到端的需求流動速度。
批量減小對交付時間的影響
批量減小後，需求可以更快速地從開發流動到測試和UAT環節，儘早對質量產生反饋。如上圖，通過減小批量，原來3個月完成600個需求，現在變成每兩週完成100個需求，前置時間縮短到原來的1/6，交付速度大大加快。因此，我們應尋找一切可能的機會減小批量。例如，IT和業務團隊不在一個職場的時候，要每週約定開會澄清需求；如果能在一個職場集中辦公，澄清需求變得容易很多，就消除了周澄清會所造成的批量。
降本：與合理批量達成最優解
消滅所有批量，實現單件流，最大限度減少等待造成的浪費，這是一種理想狀態。在現實中，由於交易成本的存在，形成合理的批量大小，才是我們要尋求的最優解。
交易成本指在做一件事的過程中，需要付出的額外附加成本。例如，需求澄清要預定會議室，要協調參會者時間；版本發佈要回歸測試，要進行評審，要熬夜發版，這都是交易成本。
交易成本與批量之間存在關聯
交易成本越高，人們就傾向於形成越大的批量。為了減小批量，很多時候需要先降低交易成本。自動化迴歸測試、自動化部署、減少不合理的流程制度，這些都是降低交易成本的手段。
FLEET 是一套幫助企業快速定位問題、推動初始優化和改進的思維框架，其目標是為企業快速帶來改善。我們將 FLEET 與過往實踐經驗互相印證，形成的精益效能提升實踐體系，已幫助多家大型組織實現了「優化衝刺、提速增質」的目標。
閱讀更多 Agilean 的文章
