背景：2022年8月，在這家公司已經任職滿兩年。這兩年我最大的成就就是基於Scrum模式推行了敏捷專案管理，並取得了一定的成果。但是，在推行了兩年後新的問題也產生了。例如：
1，專案管理上，專案經理缺乏對專案團隊每個環節的過程管理，尤其在過程指標上缺乏工具監控。
2，產品管理上，在軟體成本管理與價值管理上雙線失守，眾多需求說不清楚價值是什麼？更不知道ROI的如何計算。
3，軟體開發上，程式設計師自測、問題修復以及軟體釋出，佔用軟體工程師非常多的時間。
4，質量測試上，軟體質量一直無法提升，尤其是在測試手段上一直處於低效的人肉測試模式，bug漏測時有發生。
5，需求管理上，識別不了哪些是對系統有推進意義的需求，哪些是偽需求。需求的價值評判標準是什麼？。
等等等待一系列問題。
我受到這些問題所困擾，而我下屬有10個專案經理，對應10個專案團隊， 以及10個以上軟體產品，近百人團隊也在這種Scrum模式下運作著。
這讓我的敏捷專案管理模式已經出現了瓶頸，我甚至認為這隻有敏捷的軀殼，壓根沒有敏捷的靈魂。
為此，我開始思考敏捷上的突破，這讓我有機會接觸了DevOps，從而知曉了《價值流動》這本書。儘管閱讀了這本書並沒有解決我眾多的問題，但是這讓我對管理 的認知有加深了一層理解。
正文：我們先來談談這本書講了什麼？
整本書在我看來就一個案例，即作者 參觀寶馬集團萊比錫工廠後，對生產流水線的高效運作從而對映軟體工程的思考。探討 專案制 與 產品制 思維方式上的差異，重點向讀者解釋了流框架的定義與運用。
再攤開來聊這些內容之前，我還得先闡述一下作者想表達的基本觀點：
首先，作者認為軟體成本佔比在企業運作中逐步提升，而且會持續下去。這一點我非常認同，我甚至認為將來所有企業不論傳統的農業、製造業，甚至服務業、金融業都將會成為科技公司，產生各式各樣軟體服務。
因此，作者得出數字化轉型的三個“顛覆”：
1，基礎設施顛覆——改變客戶獲得特定產品或服務的方式（產品營銷方式）。
2，運營模式顛覆——依賴於藉助軟體來改變消費者與企業的關係。
3，商業模式顛覆——軟體和技術對業務更根本的運用。
在這三個顛覆的歷史程式中，作者透過考察寶馬工廠之後對比軟體工程也有了三個頓悟：
1、由於軟體架構與價值流脫節，隨著軟體規模的不斷擴大，生產力反而會下降，浪費會增加。
2、脫節的軟體價值流成為軟體生產力規模化的瓶頸，軟體價值流的脫節是濫用專案管理模型的結果。
3、軟體價值流不是一個線性的生產流程，而是一個複雜的協作網路，必須要與產品對齊。
這三個頓悟，我深有體會。我可以毫不思考的回答我就處於這三個困惑中，這也是使得我迫不及待往後閱讀這本書，後續作者在面對這些複雜的場景中，也給予解決方案。答案正如書名一樣《價值流動-Project To Product》 從 專案 到 產品。
在說清楚這個問題之前，先要搞清楚專案制的生產模式 與 產品制的生產模式 有什麼區別。為此我特別做了一張表來說明：
|
|
專案導向 |
產品導向 |
|
編制預算 |
為里程碑提供資金，在專案確定範圍時已經預先設定。新的預算需要新立一個專案。 |
根據業務結果為產品價值流提供資金。按需進行新預算的分配。鼓勵交付增量結果 。 |
|
時間跨度 |
專案的時間期限定義了終止日期。在專案結束 之後不再關注維保。 |
產品生命週期，包括生命週期結束 前的持續性的健康，維護活動。 |
|
成功 |
成本中心方式。以按時和按預算來衡量成功。開發資本化的結果是專案太大。受此激勵的企業，會提前要求它們可能需要的一切。 |
利潤中心方式。以業務目標和結果達成（比如收入）來衡量成功。聚集在增量價值交付和定期檢驗。 |
|
風險 |
透過強制提前進行所有的學習、需求編寫和戰略決策，交付風險被最大化。 |
風險分攤到整個時間跨度和每個專案迭代中。這創造了期權價值，比如，當發現交付假設錯誤時終止專案，或者當出現戰略機遇時進行業務轉身。 |
|
團隊 |
給人安排工作提前為工作分配人員，人們通常會跨多個專案，專案人員頻繁流失或重新分配。 |
把工作給到人工作被分配給價值流上穩定的、增量調節的、跨職能的團隊。 |
|
優先順序 |
由專案組合管理和專案計劃驅動。聚焦需求交付。專案驅動的瀑布導向。 |
由路線圖和假設測試驅動。聚集於特性和業務價值交付。產品驅動的敏捷導向。 |
|
能見性 |
IT是個黑例子。PMO建立了複雜的對映關係，晦澀難懂。 |
直接對映到業務成果，做到透明化。 |
如何從專案制到產品制？作者設計了一套 流框架（如下圖）。在正式開始解讀流框架之前，我想還是有必要先闡述兩個問題：
1，什麼是價值流？即：透過產品或服務向客戶交付價值所開展的端到端活動集合。
2，什麼是軟體流動？即：沿著軟體價值流產生業務價值這一過程中涉及的活動。
簡單解讀一下，流框架是為了實現價值流管理，連線IT和業務，並將傳統企業轉變為高績效的技術公司提供了藍圖。整個框架分為四層：
最底層是：工具網路，將設計、建立、釋出和運維等連線起來，表示為整合模型，可以透過連線指數來衡量；
第二層是：工件網路，將各種活動等連線起來，構建活動模型，可以透過可跟蹤指數來衡量；
第三層是：價值流網路，連線價值，構建產品模型，可以透過對齊指數來衡量；
最上面一層是：價值流度量，有8個度量指標，從流動指標度量（流動速度、流動效率、流動時間、流動負載）到業務結果度量（價值、成本、質量、幸福），這些度量建立在流分佈到度量之上，流分佈會涉及特性、缺陷、風險和技術債務等分佈。
這裡需要將 流動項、流動指標、業務結果（價值） 進行闡述。
流動項 是由干係人所拉取的、透過產品價值流來傳遞的價值單元。在流框架中有四大流動項。
|
描述 |
交付物 |
拉動者 |
工件示例 |
|
|
特性 |
為推動業務結果而增加的新價值；對客戶可見 |
新的業務價值 |
客戶 |
史詩、使用者故事、需求 |
|
缺陷 |
為修復影響客戶體驗的質量問題 |
質量 |
客戶 |
BUG、問題、事件、變更 |
|
風險 |
致力於解決安全、隱私和合規風險 |
安全、治理、合規 |
安全及風險官 |
安全漏洞、監管要求 |
|
債務 |
軟體架構和運維架構的改進 |
消除未來交付的障礙 |
架構師 |
新增API、重構、基礎設施自動化 |
流動指標 是度量組織內每個價值流的指標，以便讓組織擁有一種講軟體生產指標與業務結果相關聯的方法。
|
描述 |
示例： |
|
|
流動分佈 |
相互獨立，完全窮盡，在一段時間內以特定的流動狀態分配各大流動項 |
在一個特定的衝刺中，每個處於活躍工作狀態的流動單元的比例 |
|
流動效率 |
在給定時間內完成的流動項的數量。 |
為特定釋出而解決的債務。 |
|
流動時間 |
流動項從工作被接受後進入價值流到完成所花費的時間，包括活躍時間和等待時間 |
從接受新特性到向客戶交付所花費時間。 |
|
流動負載 |
流狀態為活動中或等待狀態的流動項的數量 （即在製品，WIP) |
流動負載超過一定的閾值會對速率產生不利的影響 |
|
流動效率 |
流動項處於活躍工作狀態的時間佔總消耗時間的比例 |
當依賴關係導致團隊等待其他人時，流動效率會降低 |
業務結果指標
|
度量 |
舉例 |
|
|
價值 |
由價值流產生的業務貢獻 |
收入、月度經常性收入、年度合同價值、月度活躍使用者數 |
|
成本 |
業務的價值流成本 |
支援價值流的所有人員、運營和基礎設施成本。分配給價值流的全職員工。 |
|
質量 |
有顧客感知到的價值流所產生的產品質量 |
逃逸 缺陷、提交的工單、續約率、擴充套件率、淨推薦值 |
|
幸福度 |
價值流工作人員的敬業度 |
員工淨推薦值、員工敬業度 |
聊到這，有一個問題，我們已經有了如瀑布、Scrum、Less、SAFe、DevOps 那麼多框架了，隊為什麼需要用這個新框架？其實流框架的收益至少有以下四點：
1，實時看到業務價值的端到端流動。
2，立即發現瓶頸，並利用它們對投資進行優先順序排序。
3，基於每個價值流的實時資料對假設進行驗證
4，為了最大化價值流支而重新設計組織架構
在我看來無論 從瀑布到 Scrum，從Scrum到DevOps, 其實都是對技術人員的工作方式產生了重大影響。但它們過於以技術為中心，沒有被業務涉眾廣泛採用。而流框架跨越了業務語言和技術語言，並支援從專案到產品的轉換，流框架的作用是確保這些業務級框架和轉換計劃與技術框架相連線，需要將DevOps的三大原則“流程、反饋、持續學習”擴充套件到整個業務。
至此，對於這本書所寫的關鍵內容我就描述到這裡。
感悟：
對於《價值流動 Project To Product》一書我給出： 四顆星。
說說我的感悟：
1，談談我對專案制和產品制的看法。 一種管理模式的出現我從來不會認為有孰優孰略的看法，只是在不同場景下，不同模式的運用要去合理匹配。軟體行業過去幾十年的管理模式都是借鑑於建築業、製造業。正因為軟體本身變更成本低，且相比其他行業更容易產生變更。 這也導致了傳統的瀑布型（預測型）管理模式，在逐步失效。而敏捷專案管理模式本身是基於軟體產品而誕生的模式，所以更符合產品制的架構。
那是不是就完完全全的按照產品制來做呢？ 還是那句話要因地制宜，至少在我所任職的這家制造業來說，不能完全的按照產品制來說。在2022年全年中，我們面對每個月200個需求的吞吐量，幾乎每一位需求的提出者都認為 自己所提出的需求非常有價值。而我們的軟體確實一個從無到有的自研模式，這導致我們一直被使用者牽著鼻子走，最難受的我所任職的企業有多家子公司，同樣的採購部，同樣的採購系統，卻面臨著組織結構不一樣，作業流程也存在差異，需要提供的資料看板也五花八門。
這個時候，如何去衡量價值？又基於哪個據點去打造產品呢？ 我們在這一年中，幾乎完成了使用者提出的三千多個需求，為此我們明確的知道專案的範圍已經蔓延，而且遏止不了這種趨勢。我們可以自我安慰的說使用者越來越需要我們，但是隻有我們自己知道。我們交付了價值，卻失去了範圍。並且，使用者是喂不飽的。
有的專案甚至一年下來，都在完成業務部門以及終端使用者提出的需求，既定規劃的功能模組都沒有按時上線，既沒有完成價值交付，又失去了成本控制。一年下來，最後年終總結的時候居然寫不出這一年究竟做了哪些能拿出的出手的成果，一看全年的工作全是那種加欄位、做看板、流程最佳化。本身系統的推進，卻落在身後好遠，又只好把這些目標又放在了下一年。
我曾經諮詢過京東的老師，他給我分享了一下京東的案例。他們會採用了一種混合的模式，是使用專案只制模式下 套了一層產品制的方式。具體的方法大概就是，整個專案立項依然是採用PMP那套理念有整體目標，有里程碑計劃，有專案範圍、成本 以及質量要求。 然後基於里程碑計劃 分拆目標到每個核心迭代。並以迭代方式進行成果交付，這樣不是為迭代而迭代，每個核心迭代都是對齊專案範圍的。至於非核心迭代則一般是處理使用者需求 或 技術債務。 這樣也保證了在完成使用者需求的同時，業務需求，系統需求 也都能得到滿足。
雖然，不能完全解決我的問題，但是也讓我明白了從戰略分解，到里程碑計劃，到迭代目標。逐級對齊是如何去操作的，這已經讓我又進一步了。
2，說說業務與IT脫節。
業務與IT脫節是作者三個頓悟的二條。不得不說我深受其繞，由於我所在的公司是傳統的大型裝置製造公司，而且是最複雜的非標離散型企業。對我這種網際網路公司出身的人而言相當陌生，不僅僅是我即便是我們近百號的IT人員將近9成都不是製造業出身，業務知識的匱乏讓我們這兩年來一直期望有個業務專家來指導我們。就像人生希望有個導師來指引告訴我們什麼是正確的道路，可哪有這種人，這不就是希望有個大牛告訴你買哪支股票會漲一樣嗎？
起初我們的IT組織架構設計是隻有 專案部 、開發部 以及運維部。 是由專案經理設計產品，跟進計劃。後來從專案部中分離了產品部，前置一個產品經理崗專注產品設計。由於新成立的產品部並不精通業務，最近又希望再成立一個流程組，基於產品經理再前置一個 流程專家。不管是專案經理，還是產品經理，又或是沒有組建的流程專家，其實都不能解決問題。問題還是出在了體制上，我們嘗試深入一線去調研，往往只是挖掘出單點的需求，對於整體的數字化流程轉型，一直以來沒有高層次的架構來支撐。對於這一點，我特地去調研了我所在城市的兩家頭部企業。他們的做法我覺得也可以借鑑一下。
A企業的做法是，由業務部門提供產品設計，甚至系統的流程圖、原型圖都有業務部門透過評審並會議簽字。再交由IT部門執行。即：業務部門承擔系統業務設計工作。（這裡只需要培訓業務部門畫流程圖以及原型圖）
B企業的做法是，將IT部門下放到業務部門，每組2-3名開發人員直接在業務部門打卡上班，一起參與日常工作。崗位編制也是在業務部門，是專門為業務改善而存在的IT人員，即每個部門有自己的IT人員，確保以IT思維對業務部門實施數字化改革。
基於這兩家企業是從頂層設計上解決業務與IT脫節的問題，其實在我所任職的企業可行性都不高。結合這個問題我思考了另外一種方式，那就是在專案立項之時，從業務部門抽調 “全職”業務部人員加入專案團隊。 這不同於在專案組織架構中擔任某一角色，而是全職在專案團隊中參與專案實施。 也不同於從業務部門挖人到IT部門上班，專案結束時人員是釋放回業務部門的。
3，講講價值流動以及透明化。
談到價值流動以及透明化，這跟我最近讀的幾本書都或多或少跟這個有關係。 這使得我也意識到自己的另一外項能力的缺失，即“價值流圖分析”。我再之前幾本敏捷書籍中都有看到過價值流圖。大體意思是分析業務流程，擬定觀測指標，分析價值短板。 與之關聯的也有從觀測指標中提煉 關鍵指標，轉換為績效指標。
如果拋開價值流圖不談（畢竟我還沒掌握這項能力）。 一個部門或者一個流程的運作，應該是有過程指標的，拿IT來說。 需求達成率、設計變更率、任務準交率、Bug漏測率等等。 透過過程中產生的資料提煉關鍵指標。這不就是數字化轉型嗎？
我們現在給業務部門的採購系統，倉庫系統，都是透過各個指標來衡量降本增效。IT的降本增效呢？ 是否透明化出來。 如果像這本書的作者一樣，拿一家企業來對映IT部門。我們有哪些指標是不透明的，有哪些價值短板是需要改善的。其實作者已經指出了軟體團隊 流動的是 特性、缺陷、風險以及技術債務。那麼這些都已經透明化了嗎？ 顯然我還沒有做到。
在我看來沒有，單單特性 這一項就還差得遠，至少如下：
1，需求等待時長：一個需求從 登記到設計 的等待平均時間是多久？
2，需求設計時長：一個需求從開設計到評審透過平均時間是多久？
3，需求開發時長：一個需求從開發到交付測試的平均時間是多久？
4，需求交付時長：一個需求從測試到上線釋出的平均時間是多久？
圍繞這 需求（特性）的流動 我就看不清楚，說白了也就是不透明。這種不透明讓管理者非常沒有安全感，組織改善，績效評定，都失去了重要依據。這也使我理解了什麼叫：數字化轉型要為管理決策提供支撐。
不過很可惜，就像我上面圍繞特性這一個流動項 做出的價值流 我都沒有解決好，更別說 缺陷、風險、技術債務了。這裡工具、流程、方法論都有所缺失，以至於我到現在還沒想清楚怎麼來改善這一問題，哪怕只圍繞著特性 這一點來做價值流動 以及透明化。
至此，就寫到這裡。