產品優先於專案

快速重新調整的能力

IT/工程過去只要在收到市場情報或回饋後一年內做好回應的準備就夠了。隨著「數位」成為主流，情況不再如此。我們來看一個線上零售的例子。廣義來說，基本線上零售平台的能力可以分類為目錄、訂單管理、付款和履行。

在專案模式中，在某個時間點，由於優先順序，我們可能會進行影響訂單管理、付款和履行但不是目錄的積極專案。現在，如果要從市場或業務利害關係人收到意外的目錄相關回饋，我們將沒有團隊準備好對回饋採取行動。通常，任何新的回饋在預設情況下都必須經過商業案例和專案核准流程，然後才能優先考慮人員配置。即使我們可以暫停其中一個積極專案並將團隊重新部署到目錄，該團隊可能對目錄感到陌生，因此無法立即開始執行。

相反地，在產品模式中，我們將有一個長期團隊（或團隊）致力於每個目錄、訂單管理等，並隨時準備對新的回饋採取行動。這只需要團隊產品負責人及其業務對應方的決定，將一些團隊產能轉移到對新資訊採取行動。快速重新調整準備好團隊的能力是更好的回應能力的第一個組成部分。

縮短端到端週期時間

週期時間是回應能力的常見衡量標準。包含在整體週期時間內的是重新調整時間和執行時間。現在讓我們來探討後一個組成部分。

大多數企業 DevOps 計畫完全不會改變「變更」和「執行」組織之間的分離。通常，兩個組織都會採用一些新工具、一些部署和基礎架構自動化，或許還會適當地加入一些「雲端」。他們甚至可能會獲得好處，例如更頻繁、自動化和可靠的部署。

然而，由於開發人員交接給集中式營運的持續性，交付變更的端對端週期時間並未有太大改變。產品模式團隊在部署和執行他們建置的內容時，不會有這種交接問題。因此，他們可以發揮 DevOps 採用的全部潛力。應用程式層級營運與開發的並置，也能促進更好的端對端反覆運算，以及開發人員和網站可靠性工程師之間的更佳理解。

請注意，產品模式團隊通常會持續依賴其他專家營運團隊，這些團隊提供自助建置和部署基礎架構、管理資料中心和/或負責非應用程式層級安全性。這些團隊即使未與業務能力相符，也可能以產品模式執行。

真正迭代的能力

營運長經常抱怨科技組織的成本。然而，他們錯失了一個最大的省錢機會，因為其根本原因不在科技。大型專案一次成形並獲得資金，卻沒有有效的機制來驗證實際效益。這些專案在提供效益方面經常落後。如果組織養成追蹤其效益實現比率（實際效益/預期效益）的習慣，在多數情況下，他們會感到震驚。真正的反覆運算開發流程將能夠以低成本失敗並省錢。

儘管反覆運算開發的概念已經存在一段時間，但在實務上，反覆運算在多數情況下只進行到衝刺展示。大多數 Scrum 團隊都受限於基於範圍的衝刺承諾，而且預期他們要按計畫交付範圍，而不是解決問題。為了反覆運算解決問題，團隊需要能夠對早期版本的解決方案提供回饋（使用率分析、使用者調查、利害關係人證詞）。產品模式團隊穩定且長壽，因此可以選擇以真正反覆運算的方式解決問題。

專案團隊無法輕易擺脫範圍交付，原因有二。首先，他們通常只負責「建置」解決方案，而不是執行。因此，他們在一個或多個版本中建置解決方案的版本，將其移交給「執行」組織中的團隊，然後進行下一個專案。其次，專案資金運作的方式是，資金可供應團隊維持的時間遠短於所解決的基礎問題的壽命。

範例：退休金計算器

例如，在金融服務公司中，一個專案被核准開發退休金計算器，用以鼓勵潛在客戶購買退休金產品或改善現有計畫的繳款。專案團隊僅獲得資金用於建置計算器的時間，並未解決根本問題，也就是提升退休金產品的採用率。另一個團隊會將計算器嵌入公司網站，而第三個團隊會設定必要的數位活動，以引導流量至計算器。至少三位不同的經理（主管）會密切追蹤工作的完成狀況，而業務利害關係人則在指定要建置的內容後，或充其量參與一整天的構思/熱門話題後，保持距離運作。如果交付的解決方案未達到市場預期，就必須等待另一輪的資金和人員配置，才能找到改善解決方案的方法。

就轉換率每增加百分之一的成本和時間而言，產品模式設定很可能比專案模式設定更具優勢。對於任何特定組織來說，驗證這一點的唯一可靠方法是針對幾個問題嘗試產品模式並評估結果。

知識保留

軟體的真相是，任何程度的文件、交接和知識轉移都無法彌補團隊 100% 的流失。然而，這正是專案模式所帶來的。技術能力並不存在於成熟度模型、流程範本、文件、程式碼或基礎架構中。它存在並成長於團隊中。

知識會在穩定、長期的團隊中成長並保持得更好，這些團隊在同一個一般領域工作數年。這與每隔幾個月就會增加或減少的專案團隊形成對比。無法維護的程式碼結果（至少部分）來自於未維護的團隊。

儘管文件是有用且必要的，但在偏好「實作軟體勝於全面文件」的組織中，它無法取代產品模式團隊中發生的知識保留。

產品模式團隊允許團隊成員專注於特定領域（與業務相關的能力），時間遠遠超過典型的專案持續時間。這有助於建立知識、改善對問題和權衡的理解，並豐富與業務 SME 和利害關係人的互動品質。

當團隊成員離職時，產品模式團隊會失去知識嗎？如果他們根據整體範圍的共同所有權來工作，則不會。當團隊成員個別擁有不同的功能或子領域時，知識保留就有風險。

架構完整性

專案模式中涉及的誘因會對團隊施加壓力，讓他們忽視中期的架構完整性，而支持（通常認為的）短期功能交付。由於團隊不必面對這種權衡的後果，因此他們無法從長期所有權出現時出現的回饋迴路中受益。已知專案團隊會無意中透過不知道企業架構指南或僅在追求及時專案交付的狹隘目標中忽略它們，而造成架構負債。從中期來看，這種現象會損害系統的穩定性並降低交付速度。幾個範例

• 他們可能會與一個打算淘汰的系統執行低成本整合，而不是承擔與即將推出的後繼系統整合的高成本。這會損害淘汰路線圖，並增加維護具有類似功能的多個系統的應用程式環境的成本。
• 他們可能會直接與下游系統進行資料庫整合，而不是在透過 API 公開其功能後再進行整合。反過來，這會損害下游系統的任何演進，而下游系統需要對其資料庫架構進行重大變更。

另一方面，產品模式團隊不會讓其他團隊不適當地與他們擁有的系統整合，因為他們更清楚後果。與專案模式（由僅執行團隊擁有）相比，讓「建置 + 執行」團隊擁有系統的優點就在於此。

擁有程式碼和系統

團隊層級的程式碼和系統所有權極大地幫助團隊以構思-建置-執行模式營運。所有權讓團隊能更快且更受控地演進系統。但集體所有權的理想呢？由於個別所有權的替代方案有問題，因此在團隊內部追求集體所有權是很棒的。然而，在團隊之間，清楚的界定所有權可以讓自主權負責。

在一些最先進的科技公司中，使用了內部開源模式。任何團隊中的任何人，都可以透過將拉取請求傳送給保管人（類似於開源專案中的核心提交者團隊）團隊，來提議變更幾乎任何程式碼區域。

儘管此模式可以與團隊層級所有權共存，但它往往會產生一個預設期望，即依賴團隊將自行服務他們需要的變更。這是開源專案中常見的期望（「發現錯誤？很好。請提交修復程式。」），但在大多數主流企業的數位/工程/IT 部門中並不實際。原因之一是，很少有足夠的領域知識來有效地變更不同的系統。此外，它要求所有程式碼都必須維護在可自服務的程度，包括文件、建置（例如，只需簽出和建置）和測試準備，這對大多數組織來說都是很高的門檻。這是內部開源倡議無法在嘗試過的大多數主流企業中啟動的原因之一。對於此類組織而言，務實的做法是將預設期望保持為非自服務，而是協商依賴性。任何變更都必須預設由擁有團隊同意、優先處理和交付。

團隊動機和動力

團隊需要時間才能有效地作為一個單位共同合作。塔克曼的團隊發展理論斷言，團隊在進入執行階段找到其節奏之前，會經歷一系列次優階段（形成、衝突和規範）。專案模式的人員配置有解散團隊的風險，就在他們進入規範或執行階段時。產品模式團隊穩定且長壽，可以從漫長的執行階段中受益。

研究已將自主性、精通、目的和歸屬感確定為關鍵的內在動機因素。產品模式團隊往往比典型的範圍交付專案團隊擁有更大的自主性和目的。因此，即使管理層需要時間來適應新常態，產品模式團隊的導入通常受到軍隊的歡迎。

流程和迭代的經濟效益

在產品開發中，我們最大的浪費不是沒有生產力的工程師，而是閒置在處理佇列中的工作產品。

-- 唐納德·G·雷納森

到目前為止的論點可能聽起來與傳統的 IT 智慧相悖。但自智慧型手機問世以來，商業環境已發生巨大變化。儘管將 IT/工程視為成本中心從未明智，但現在卻是站不住腳的。以成本效益為主要重點來管理 IT 從未如此適得其反。即使在緩慢的後端 IT 之上建立一個高速的「數位」前端組織也不夠——雙模式/雙速 IT 基於一個錯誤的前提，其肇事者已開始承認這一點。

傳統的 IT 智慧在幾個方面已經過時。其中一個方面是組織 IT 團隊以規模經濟來最大化利用 IT 專家的常態。在某些方面，專案為基礎的營運模式反映了此常態，其一，使用臨時變更團隊，其二，使用設計、測試、部署等的共用服務。另一方面，流動和反覆運算的經濟對於回應性的目標來說更重要。

當處理的單位成本隨著處理規模的增加而降低時，就會產生規模經濟。另一方面，當處理的單位時間（批次大小為一的端到端週期時間——單件流）隨著處理流動的改善而減少時，就會產生流動經濟。由大量共用服務支援的僅建置專案團隊可能有助於實現規模經濟，而構思建置執行產品模式團隊則有助於實現流動經濟。

同樣地，當隨著反覆運算能力的提高，實現業務利益所需的工作量減少時，就會產生反覆運算經濟。僅建置專案團隊遭受太多交接，無法有效地反覆運算。此外，他們沒有足夠的壽命來執行一系列基於真實回饋的反覆運算。產品模式團隊在設計上不會有這些缺點。

員工利用率

常見的疑慮如下：「當產品模式團隊工作用盡時會發生什麼事？」如果團隊負責的領域夠大，例如目錄或履行，這種情況永遠不會發生。此外，團隊規模會定期檢討（例如每年一次），以調整變動的相對優先順序。有些地方會使用核心加彈性模式，由核心員工團隊和彈性承包商補充。儘管如此，如果特定業務能力領域沒有穩健或足夠重要的路線圖，就會在下次檢討前將其（連同核心團隊）併入鄰近能力。

有時，潛在問題是：「如果我們（PMO 或同等單位）沒有將任何事項優先排序在特定團隊的工作領域中，會怎樣？」答案是產品模式團隊應為一個有權限的半自治單位，因此不會完全依賴外部的優先排序。只有跨部門計畫會從外部優先排序。對於路線圖工作，團隊層級的產品負責人有權與業務利害關係人協調優先順序。經驗法則是要針對三分之二的路線圖工作，而計畫工作不超過三分之一。因此，在產品模式中，投資組合管理會經歷徹底的變革。

跨職能團隊中不同角色的利用率如何？當沒有足夠的工作讓所有不同角色都忙碌時會發生什麼事？嗯，人們會承擔與其技能相鄰的工作，例如業務分析師可能會執行探索性測試，QA 可能會協助改善文件等。一開始，他們可能必須觀察他人以獲得基礎技能水準，但不久後他們就會從專家變成通才專家。

在利用率的主題上，重要的是要注意，針對利用率進行最佳化會損害縮短端對端循環時間。您不會透過改善高速公路的利用率（即引入更多車輛）來改善交通流量。主要關注利用率是「IT 作為成本中心」心態的遺留物。這不適合數位業務。

孤立

穩定、長期的團隊難道不是造成孤島心態和普遍停滯的秘方嗎？這是一個風險，但通常科技團隊中總會有一些流動率，這會注入一些新思維。此外，許多組織贊助實務社群，這些社群是非正式的內部網路，與特定能力（例如客戶體驗、A/B 測試等）保持一致，讓跨團隊的人員聚集在一起。

新的部門

在專案模式中，我們會遇到產品管理、架構、設計、開發、測試、營運和支援等孤立作業區。在產品模式中，我們會不會最終得到新的、與業務能力一致的孤立作業區，例如目錄、訂單管理、付款和履行？或許會，但它們絕不像以活動為導向的孤立作業區那麼糟糕。產品模式團隊以成果為導向，最糟糕的情況可能是孤立作業區仍朝向業務成果努力。與業務能力一致的孤立作業區不如與產品開發價值串流階段一致的孤立作業區那麼糟糕。

話雖如此，我們可以透過設定產品模式團隊，並沿著服務體驗（例如「問題到解決方案」）或業務價值串流（例如「訂單到現金」）定義的業務對齊能力界線，來減輕新孤島的風險。如果這對單一團隊來說過於龐大，那麼我們可以將其區隔成多個團隊（根據 Spotify 普及的命名模式，也就是部落中的小隊），但盡量讓他們共處一地，並指派服務體驗擁護者或業務價值串流所有者與區段層級產品所有者合作。

作為對策，對於橫跨多個產品模式團隊的計畫，建議指派能穿透孤島、協商優先順序、管理相依性的解決方案擁護者，與產品所有者和業務利害關係人合作。另一個良好的做法是，在一段較長的時間（例如 18 到 24 個月）後，提供人員變更團隊的選項。

最終，產品模式中的孤島打破在於確保對齊與自主性。舊式方法透過犧牲自主性來達成對齊。相反地，我們使用 對齊地圖 等技術，取得兩全其美的結果。

階層式團隊

先前描述的線上零售範例建議使用產品模式團隊，例如目錄、訂單管理、結帳和履行。退休產品範例建議使用產品模式團隊，例如登機、註冊、儲蓄和提領。這引發了一個問題，這些團隊是否對企業應用程式堆疊負有端到端的責任，亦即從面向市場的前端系統一直到支援後台功能的後端系統（下圖中的第 3 層和第 4 層）。答案是「不總是」，原因如下。

圖 1：線上零售中分層產品模式團隊的簡化範例。

儘管端對端責任有助於成果導向，但考量到系統的形狀，這通常是不切實際的。例如，線上零售平台通常至少具備一個網頁應用程式和一個行動應用程式作為客戶商店，一個呼叫中心應用程式作為支援前端，以及一個商店管理應用程式作為商店經理的另一個前端。通常，這些前端系統中的每個系統都對目錄、訂單管理、結帳和履行等基礎能力有其自己的依賴性。通常，端對端目錄（或任何其他能力）團隊沒有明確的前端系統界線。例如，如果商店管理應用程式團隊僅依賴於單一第 3 層能力（例如目錄），則可以避免使用它。所示圖片假設商店管理依賴於不只是目錄。因此，我們訴諸於第 3 層和第 4 層中分開的產品模式團隊，如所示。較高層級的層級是較低層級的消費者。

一個新趨勢是將前端系統分解成與第 3 層能力一致的微前端。這使得擁有跨越第 3 層和第 4 層的端對端團隊變得更加容易。但大多數已轉移/正在轉移到微服務的地方尚未計畫轉移到微前端。

有時，支援多個第 2B 層能力的舊系統的存在可能會導致第 3 層團隊也依賴於具有相應技能的第 2B 層團隊的情況。理論上，可以將第 2B 層人員嵌入到對應的第 3 層團隊中。然而，在實務上，這可能會受到第 2B 層容量稀少或共享組態管理、測試環境等的實際挑戰的限制。

第 1 層和第 2A 層是持續交付、DevOps 和精實產品開發的促成者。它們更適用於各個業務領域。例如，管線基礎架構團隊負責維護 Jenkins/GoCD/TeamCity... 基礎架構。他們不負責處理較高層級團隊中斷的建置。因此，較高層級可能會依賴於較低層級。不論層級為何，每個團隊在於它們是穩定的、長期的、跨職能的、以成果為導向的、構思建置執行團隊的意義上都是產品模式。較低層級的團隊將較高層級的團隊視為其（內部）客戶，以解決問題（而非範圍交付）的方式。

小隊和部落

通常，目錄等單一領域可能對單一團隊而言過於龐大，將其拆分為多個產品模式團隊是沒問題的。在這種情況下，目錄部落有多個小隊，每個小隊都有自己的成果、路線圖和系統。此結構還允許在每個小隊中可能難以嵌入的角色在當地共享（部落內部）。請注意，小隊的壽命應遠長於典型的專案團隊，儘管可能故意要求小隊成員在部落中輪調，例如每 18 至 24 個月輪調一次，以擴展知識廣度並避免成為單一故障點。

但產品在哪裡？

重申一開始提出的觀點，建立產品並非以產品模式運作的必要條件。話雖如此，如果我們超越產品的傳統定義（即在市場上銷售的產品），那麼就有可能將目錄等事物視為產品。一旦目錄等功能包含在由團隊擁有的系統集合中，並透過內部應用程式或文件完善的 API 公開，它就會成為可重複使用且可自給自足的產品類似功能，服務於內部客戶。這也適用於較低層級的產品模式團隊。