精益之識別和消除研發過程中浪費的思路和模式
本文基於精益思想和精益軟體開發，針對研發過程中的“浪費現象”進行深入分析。浪費分成存粹的浪費和必要的浪費，其中存粹的浪費需要消除，而必要的浪費可以進行壓縮。結合日常研發過程，本文對如何識別這些浪費、如果消除存粹的浪費以及如何壓縮必要的浪費進行剖析，並提供思路和模式。
一．理論基礎
精益思想來自制造業，引入軟體行業不過10年，目前很多理念還是停留在理論階段，很難在實際研發過程中進行直接應用和推廣。精益的很多思想個人認為是對軟體行業有參考價值的，例如本文的主題“消除浪費”。關於軟體研發過程中的浪費現象可以總結為：
- 部分完成的工作：部分完成但沒有最終落地的工作
- 未應用特性：開發完成但沒有被客戶應用的特性
- 額外過程：開發過程中不需要的流程和中間產物
- 再次學習：人員、環節變動導致反覆重新學習
- 資訊移交：隱性知識資訊的傳遞總是伴隨資訊丟失
- 任務切換：多工工作會導致效率下降
- 資源依賴：因任務或資源相互依賴而導致工作停滯
- 系統缺陷：解決缺陷活動本身就是浪費
二．如何識別浪費？
我們有了理念，下一步是行動，首當其衝就是要識別研發過程中的浪費，個人總結如下識別浪費的模式：
1. 價值流圖
價值流圖（Value Stream Mapping, VSM）是精益思想中用於消除浪費的主要工具，其作用就是幫忙我們找到研發流程中哪些環節中存在浪費現象，整個生命週期中有多少時間是用在創造價值，又有多少時間是存粹的浪費。傳統的軟體研發過程價值流圖可以抽象成如下（下方座標中凹下去的部分代表產生價值的時間，突起的部分表示浪費的時間）：
2. 專案輸入過濾
研發過程通常面向產品，而企業級應用或半網際網路半企業級應用的產品最終通過專案進行實施和落地，這樣專案線就成為研發過程的一個重要輸入，而專案經理們站在專案線和客戶的立場上提出來的需求和計劃往往會和產品線、研發線有一定出入。如果本不應該進入研發環節的輸入最終進入了研發環節就勢必會導致浪費。如何通過規劃和分析去把控來自專案上的輸入，讓專案線需求能夠儘量和產品線一致是降低研發成本、消除浪費的一個重要方面，所以專案輸入也是我們尋找浪費的一個來源。
3. 會議聚焦
我們不得不經常召開這種或那種會議，那開會是一種浪費嗎？個人覺得很多時候是的。會造成浪費的會議通常會有一些共性，典型的有：
- 輸入輸出不明確
- 缺少主持人或主持人不善於引導
- 會議不是結果導向、無法形成有效決策
- 會議議程空泛而不能收斂
- 會議雖然能達成一致，但沒有具體工作安排和責任人制度
- 即使有工作安排但缺乏跟蹤和監控機制
- 會議相關的資料沒有充分準備，也沒有提前交付到參會人員
具有上述特點的會議很大程度上不會有實質性的成果，開完一次之後還需要開第二次，如果把握不好浪費的不但是時間還是團隊的氣氛，需要進行分析和識別，看看我們每天的會議中是否具有以上“smell”。
4. 資料傳遞有效性對比
目前主流的研發管理方法論中普遍認為溝通和協作是研發成功的關鍵性因素，而溝通和協作的背後體現的實際上就是資料傳遞過程的有效性。如果有兩個研發團隊，其中一個團隊中資料從團隊中的一個人傳遞到另一個人的過程無論在時間上或空間上都比另一個團隊有效，那兩個團隊的戰鬥力無疑是不一樣的。資料傳遞在溝通模式、媒介、工具等各個方面都可能存在效率不高甚至不合理的地方，浪費也就在這些地方不斷的滋長，從而消耗著研發團隊的戰鬥力。
5. 管理活動梳理
有人說團隊如果足夠“自組織”，那我們就不需要管理了。這句話雖然聽起來有一定道理，但未必太過虛無縹緲。但從管理工作本身入手分析在工作流程、文件管理、任務分配等各個方面上是否存在冗餘或者不合理的管理活動確實不失為一種識別浪費的實踐。管理是需要成本的，管理做的好、做的精細更加需要成本，但管理過程本身也可能向程式碼一樣需要隨著研發過程和團隊的演變不斷進行重構，重構的前提也就是需要我們對管理活動進行分析和梳理，找出其中的浪費之處並進行消除或壓縮。
6. 流程執行力
無論是好的管理模式和理念，還是適合團隊的研發模型，要想取得令人滿意的效果，歸根揭底還是需要執行力。執行力來自很多方面，如合理的團隊組織架構、優秀的人才、高效的工具、良好的團隊氣氛等，這些通常都不是技術所能起決定作用的領域，卻實實在在影響著團隊的執行力。流程本身可能是合適的，但因為執行的人不行、或因為工具使用不當導致效率降低，這通常都是屬於無法避免但是需要進行壓縮的浪費形式。三．如何消除存粹的浪費？
通過本文第二部分的識別工作，團隊中的浪費現象已經攤在大家面前。其中有很大一部分的浪費屬於存粹浪費，這些浪費需要通過一定的思路和工作模式進行消除。個人總結以下9條作為消除浪費的主要實踐：
1. 專案線的介入時機
首先我們來看研發團隊的外圍介面，這裡把專案線看作是與產品研發線並列的另外一條工作線，這樣專案線介入產品研發的時機就非常重要。參考“如何識別浪費”中提到的價值流圖，我們可以看到第一步是專案線提出開發要求，然後第二步召開需求評審會議，第三步才是正式啟動技術開發工作。如果專案線介入時機不合適的話，在第一步和第二步之間可能會有一個時間區間，第二步和第三步之間也可能會有一個時間區間，一方面步驟之間的時間區間本身就是浪費，而且對二步而言，需求評審之後如果技術開發遲遲不能開始，無論從需求管理和風險管理上而言都存在變數，這些變數的表現形式就是步驟內容需要調整甚至重新來過，從而造成浪費。
2. 研發範圍管理
範圍管理是消除浪費過程中比較容易聯想到的關注點，因為範圍決定著開發工作量。從專案管理上講，避免範圍“鍍金“和範圍”潛變“是範圍管理的一個課題；從研發過程上講，現在”簡單設計“、”湧現式設計“等理念也被越來越多的研發團隊所推崇。研發範圍管理一方面要關注由於專案/產品團隊提出的一些不必要、不符合產品戰略的功能需求，也要在開發人員內部進行診視，看是否有過度設計等現象的存在。
3. 高效決策
決策是行動的源頭，源頭如果沒有把握好，後續所有環節都可能是一種浪費，這是我們面對決策的一個視角；另一個視角就是決策是正確的，但決策的過程是否高效。
關於決策一個關注點是決策支援過程，包括決策前資料準備、人員安排、產品調研等多個方面，這樣做的必要性在於確保決策的正確性，避免出現拍拍腦袋就拍桌子的現象，這個過程通常由公司高層主導，研發團隊進行配合。另一方面，在上文“如何識別浪費“中我們提到了一項實踐叫會議聚焦，通常這可以是我們消除決策浪費的一個切入點。個人對所有召開的會議都要求使用會議邀請郵件，這個會議邀請郵件在部門級別形成郵件模板，該郵件模板對會議的輸入、輸出、議程進行說明，以便與會人員會前可以準備、會後可以回顧，可參考：XXXX相關人員定於XXXX召開XXXX會議。
會議輸入：
1.XXXXX，請參考SVN地址
2.XXXXX
會議議程：
1.XXXXX，XXX主導
2.XXXXX，XXX主導
會議輸出：
1.XXXXX，落實人員和時間安排
2.XXXXX
請各位做好會議前的準備，有任何疑問請與我聯絡。
一個議題明確、輸入完備、責任人導向的會議能確保決策的高效性，避免出現浪費。
4. 跨職能團隊
跨職能團隊用於消除在資訊傳遞過程中為了確保資訊有效性而產生的浪費。跨職能研發團隊成員主要包括專案線、產品線、技術線、質量保證線等，大家圍繞某一個產品線/平臺開展所有工作，確保坐在一起並能夠實時、面對面溝通。網際網路開發環境下，跨職能研發團隊還可能包括運營、客服等角色，但銷售、市場等相關人員通常不在該團隊中。這實際上是一種強矩陣的團隊組織結構，所有人保持在同一認識水平和工作節奏中。針對從“資料傳遞有效性“、”流程執行力“中識別出來的浪費，很多都可以通過該項實踐進行消除。
5. 根本原因分析
缺陷本身就是一種最大的浪費。在開發過程中，bug不可避免，但這些bug的背後可能有其必然性，很多時候並不是開發人員或者技術本身的問題，根本原因分析的目的就是幫忙我們找到出錯的背後是否有其必然性，然後通過分析這些必然性並提供解決方法，從而避免類似bug的再次發生。常用的根本原因分析工具包括5個why、魚骨圖等。
6. 產品功能標準化
標準化有很多層含義，專案管理標準化、產品功能標準化、開發流程標準化等都屬於這一範疇，這裡重點講一下產品功能的標準化。當一個產品面向多個專案時，產品標準化就是消除浪費必須要做的一件事情。大家可以想象一下，如果每個專案都有不同的輸入，這些輸入雖然都長得差不多，但如果沒有產品的標準化平臺，來一個專案還得東抄一些程式碼、西拼一個功能，不但開發週期變長導致浪費，而且系統本身也會因為確保標準化而滋生bug，導致進一步的浪費。面對處於發展期的產品線功能，開發一套產品線功能，每次來專案時根據產品線生成框架再在其基礎上二次開發通常是較好的做法。如果產品線已經比較成熟，那麼產品的平臺話就可以提上日程，從而為專案線適配產品線提供途徑，最大限度減少因為專案線而導致的二次開發。
7. 技術評審
網上有一些技術評審無用論，但個人覺得技術評審在消除浪費方面還是很有用的。個人理解技術評審包括正式的技術評審和非正式的技術評審兩大類，兩者結合能有效的消除浪費。例如，產品經理在設計完產品需求之後、拋給研發之前，和UED進行產品UI風格和使用者互動方面的討論，這類就屬於非正式技術評審，有助於把問題扼殺在開發過程之前。而類似需求評審、程式碼評審等都是屬於正式技術評審的範疇，幫忙我們在研發過程中正確把握方向，避免因需求重複、程式碼維護等方面所引出的開發成本。
8. 過程資產建設
過程資產建設是一個組織級別的行為，體現在研發過程就是為了消除團隊成員“再次學習“的成本。關於研發過程資產建設可以參考我的文章《輕量級研發知識管理--如何幫助研發人員建設過程資產》，具體不再展開。通過文章中提到的輕量級的流程和實踐可以在很大程度上確保新人培訓、開發交接、系統維護等方面所暴露出來的問題，從而消除浪費。
9. 流程重構
上面講到我們要走一些流程，走流程很多時候也是一種浪費。因為走流程需要人、時間和配套的步驟，如果流程過於複雜，實行成本很高，這樣的流程通常會流於形式，沒有產出的流程就是一種很大的浪費；反過來說，如果一個流程中連責任人、執行的時機和具體的步驟都沒有明確，那執行過程中勢必會摻雜每個人自己的理解和意願，最終流程的執行變成相互扯皮的過程，執行力成為浪費的一種來源。流程同樣具有時效性，需要隨團隊成員和產品戰略的變動而做調整，無論是上述兩種情況中的哪一種，流程重構如同程式碼重構是需要定期/不定期做調整和優化的。四．如何壓縮必要的浪費？
上文闡述的是如何消除浪費的主要實踐，但有些浪費通常是必要的，也是不可避免的，對這些浪費而言，我們的思路是儘量進行壓縮，下面是個人梳理的7項壓縮浪費的實踐：
1. 程式碼質量
在消除浪費的實踐中我們提到的“根本原因分析”關注的是消除那些引起產品質量問題的必然性因素，通常涉及的是開發流程、環境部署流水線上的因素。除了這些必然性因素之外，產品質量的提高需要質量保證部門的努力，但在精益思想中，通過測試手段進行質量管理是低效和不被提倡的，精益思想提倡的是內建質量，個人理解至少在技術開發人員內部要確立質量意識，典型的由於開發人員輕視程式碼質量導致浪費現象發生的場景有：研發團隊沒有確立開發環境和測試環境分離原則，前後端開發人員各自完成程式碼開發之後，只是通過簡單的聯調就提交測試，沒有在專屬的開發環境中進行整合測試，導致提測的服務在測試環境中根本無法執行，需要開發人員、測試人員多次交涉和調整才能部署成功，這是一方面；另一方面，由於開發人員沒有進行充分的自測，導致很多本應該在除錯階段就應該發現和解決的問題最終通過內部測試流程由測試團隊暴露出來，這裡流程運轉所需要的額外成本實際上就是我們講的可以壓縮的浪費。
2. 視覺化
視覺化同樣與資料傳遞的有效性有關，雖然我們可以通過“過程資產建設”等實踐消除浪費，但溝通成本是一種實實在在的必要浪費，需要進行壓縮。個人認為視覺化是一項需要推廣的實踐，資訊的透明在敏捷等方法論中也備受推崇。視覺化通常需要使用一定的媒介並配合一定的協作流程和報告系統，可以參考系列文章《研發範圍和時間的“資訊透明化”》。視覺化的作用就是為團隊和相關干係人提供資訊輻射器，確保所有人對研發的範圍、進度等達成統一認識。
3. 過程自動化
從過程改進角度而言，過程的自動化是一個可以持續進行嘗試和探討的入手點，對提高開發效率、降低由人為因素所引起的錯誤和浪費起到促進作用。日常工作中，過程自動化在潛移默化中影響著研發團隊內部以及跨團隊協作流程，通常包括程式開發、功能測試、系統部署和服務釋出等領域，我們通過Ant、Python等指令碼或Jenkins等工具平臺進行過程自動化建設。
4. 並行工程
並行工程雖然聽上去比較難把握，但可能很多時候我們都在不知不覺中使用這一思想。例如需求評審之後，開發人員編寫程式碼和測試人員準備測試用例、前後臺開發確定互動協議和介面之後同時進行開發等都是簡單的並行化例子。並行就是分批思想，通過合理安排人員和順序，可以把原來需要序列的任務變成並行從而提高效率。個人認為並行工程的難度在於管理介面和系統整合，如果能夠保證介面的穩定性以及系統整合的成本控制，並行工程在某些場合可以很好的壓縮浪費。
5. 短迭代
短迭代是一種敏捷思想，也是一種精益思想，就是通過儘早暴露問題從而儘早解決問題。因為軟體開發是一項創造性工作，問題越在後期暴露則修復的成本就越高，造成的浪費也就越大。我們可以把短迭代形象的描繪成下面這張圖（來自章顯洲，《精益軟體開發藝術》譯者）：
通過上圖，我們可以很清晰的看到短迭代在壓縮浪費過程中的價值所在。
6. Feature粒度
關於Feature粒度的討論關注的是如何在研發管理活動上達成一種平衡。對Feature粒度的劃分可以採用以下方式：模組->功能線->功能點，即無論何種規模的系統，通過三級層次把範圍劃分到功能點級別，而研發團隊面臨的粒度即為一個個功能點。個人覺得一個系統的功能點在20~50之間可能是最優的，過少增加開發人員之間的資訊傳遞成本，過多則導致管理活動成本的增加，兩種情況都應儘量避免。
7. 單件流
單件流（single-piece flow）是精益思想中的一個關鍵詞，意思就是不要讓半成品工作在佇列中堆積起來。軟體開發中的半成品泛指部分編碼實現的需求，或者是還沒有進行測試、文件化和部署的程式碼，或者是還沒有修復的錯誤。單件流思想的背後個人覺得就是持續整合、持續交付的思想，要做到很不容易。但通過Feature級別的程式碼提交、每日部署、高效的測試流程閉環等方式可以在一定程度上提高單件流化的水平，從而壓縮在服務釋出、系統整合方面所造成的必要浪費。五．小結
本文對精益思想中的識別和消除浪費理念在研發管理過程中的表現形式，以及結合個人平時的體會對如何有效的識別、消除和壓縮浪費的模式和實踐進行了梳理。對精益思想中提到的推遲決策、整體優化等理念還需要進一步加深自己的理解並爭取能夠應用到日程研發管理過程中去。