從專案到產品: 軟體時代需要價值流架構師 | IDCF

譯者：無敵哥

原文地址: 本文翻譯僅供學習交流之用。

原文作者 Mik Kersten 出版了《Project to Product》

本系列共四篇文章，分別是

• 01 從專案到產品：軟體需要從物理產品交付中學到什麼？|IDCF（點選檢視）

• 02 從專案到產品：生產線類比的終結 | IDCF（點選檢視）

• 03 從專案到產品：到底是什麼應該流經軟體價值流？|IDCF（點選檢視）

• 04 從專案到產品：軟體時代需要價值流架構師 | IDCF

---

“Every system is perfectly designed to get the results it gets.”

“每個系統都經過了完美的設計，以得到它所得到的結果。”

上面這句話，經常被認為是愛德華茲·戴明說的（但很多人也說過類似的），在今天的大規模軟體時代跟大規模生產時代非常相像。隨著公司努力與像亞馬遜這樣的顛覆者競爭，一個需要解決的問題是。誰將負責並構建加速商業價值流向客戶的軟體價值流？微軟和亞馬遜這樣的科技巨頭，對這個問題有一個明確的答案——那你的公司呢？

雖然傳統上，很多公司為把重點放在企業業務運轉的系統架構上，但在很大程度上忽略了用於軟體交付系統的IT整合架構。儘管這些 IT 系統對於公司如何透過軟體向市場提供價值是至關重要的。因此，在科技巨頭和初創企業之外，許多組織並沒有一個一致或整合的交付流水線，這個流水線被視為真正的產品，可以帶來切實的商業成果。

此外，在交付速度方面，也缺乏對這些系統架構的重視。最令人擔憂的是，僅有為數不多的企業 IT 組織設定了價值流架構師的角色，以實現這一至關重要的加速目標。因此，很多組織，投資僱傭開發人員和採用精益方法(如敏捷和 DevOps)，但在獲得相應的工具和培訓之後，卻沒有自動獲得更多的價值，也就不足為奇了。

即使組織採用了DevOps和其他實踐，許多組織仍在努力建立產品價值流的整體檢視，從產品組合/功能的基本概念到交付再到客戶反饋。之所以缺乏這種連續流和反饋迴圈的可見性，是由於反饋機制定義不清晰，以及組織無法建立並自動化一個能夠預測和影響這些流程的平臺。由於產品是透過DevOps流水線交付的，因此將資源集中到能夠持續簡化和提高整個組織交付速度的領域的能力，對於企業的適應性和成功至關重要。這就是價值流架構師的角色。

價值流架構師是影響者、顧問、最佳化者和架構師。他們與產品負責人（Product Owner）密切合作，產品負責人主要負責為產品團隊承擔的所有工作(特性、缺陷、風險和債務)提供資金並安排優先順序，以最佳化、支援整個產品生命週期的團隊的業務價值、質量、成本和快樂程度。例如，對於一家銀行公司來說，產品可以是一種金融工具，如年金。對於汽車製造商來說，這可能是資訊娛樂系統的創新。或者，它可能是一個面向資訊科技的資訊科技產品，如API，或者是由資訊科技人員使用的規劃、開發、測試、部署和支援工具組成的整合交付流水線。

價值流架構師角色需要包括如下幾個確保成功的因素:

1）視覺化

沒有對每條業務線/產品的視覺化，價值流架構師就像在真空中工作。重要的是，反饋機制的設計和實現要讓架構師對整個軟體開發和部署過程有一個360度的瞭解。這些反饋機制是任何價值流架構的核心組成部分。架構師利用這些系統，為軟體組合的每個部分提供業務級的價值流視覺化。

2）影響

價值流架構師需要組織的支援來推動價值流的每個組成部分的變化。

• 透過收集和分析反饋資料，從而驅動變更，應該採取價值流架構師向每個產品待辦列表（PBL）中新增工作項的形式。這些項是架構師透過與團隊合作，基於當前的Backlog和預期的業務結果指標，並在回顧中利用價值流指標和反饋而確定的持續改進想法。
• 價值流架構師影響並諮詢整合交付流水線的負責人，以推動關於平臺和工具的更高層次的決策。這些決策是作為跨所有價值流的組織核心能力來驅動的。

3）架構

業務價值交付的速度高度依賴於組織架構、軟體架構和價值流架構的一致性。價值流架構師專注於定義和實現一個架構，該架構包括：

• 建立支援反饋機制的框架以支援反饋和流程。
• 視覺化價值流中的每個關鍵流程。
• 瞭解當前的制約因素並找出瓶頸。
• 為每個產品的價值流建立目標架構。這項工作的副產品是每個價值流從其當前狀態到其目標狀態的差距，這些差距將是架構師理解每個價值流的能力和責任的關鍵。

4）指導和培訓

從價值流的整體角度來看，價值流架構師將不斷發現，價值流相關人員在培訓和技能方面的不足，並將與IT領導合作，以彌補與給定團隊之間的知識/技能差距。

隨著價值流架構師在各個組織的定義越來越明確，影響越來越大，企業將擁有一項關鍵資產，它將確保每個系統都經過完美和持續的設計，以獲得最重要的業務成果。在軟體時代創新，不定義這些角色，類似於試圖在沒有明確定義工廠運營領導角色的情況下成為汽車生產的領導者。要建立一個交付工廠，使您的團隊能夠構建優秀的軟體，首先要識別並授權您的價值流架構師。

注：這些文章最初發表在 IEEE 軟體雜誌的“ On DevOps”專欄中，目標讀者是對軟體體系結構進化感興趣的讀者。

這是一系列來自於Mik的部落格，這些核心內容可以認為是 《Project To Product》的起源。對Mik來說，從專案到產品，是一個20年的旅程，開始於作為一個開源開發者的十年學習，並將這些學習應用到他過去十年與 不同行業IT 領導者的合作中。這些帖子代表了他一路上最有趣的學習和合作歷程。