[Soft & Share 會員服務] 文章選讀 055 超越專案管理的產品管理

軟體專案是資助和組織軟體開發的一種流行方式。它們將工作組織成臨時性的、只需建立的團隊，並根據商業案例中預測的具體效益進行資助。而產品模式則是使用持久的、從創意到建設再到執行的團隊來解決永續的業務問題。產品模式允許團隊快速調整方向，減少其端到端週期時間，並允許透過使用短週期迭代來驗證實際效益，同時保持軟體的架構完整性，以保持其長期有效性。

---

軟體專案是資助和組織軟體開發的一種流行方式。專案的資金是根據業務案例中預測的效益逐一提供的。它們以一個或多個臨時小組的形式組織起來，其成員在專案組織之外有持久的報告關係。它們的人員來自一個 “人才庫”，其成員被認為可以在專業領域內互換。通常，軟體專案組的工作是建立或加強一些系統或應用程式，然後繼續前進。

然而，專案並不是資助和組織軟體開發的唯一方式。例如，許多將軟體作為產品或服務銷售的公司並不以專案的形式資助或組織其核心產品/平台的開發。相反，只要產品在市場上銷售，他們就使用近乎永久的團隊來執行產品開發和支援。每年的預算可能會有所不同，但一般來說，預算足以資助一個持久的、核心的開發組織在產品的生命週期內持續進行。資助團隊在一段時間內針對一個特定的業務問題或產品開展工作；工作性質由要解決的業務問題而不是要交付的一系列功能來定義。我們把這種工作方式稱為 “產品模式”，並斷言，不一定要正在建構一個軟體產品，才能這樣資助和組織軟體開發。

什麼是產品模式？

“產品模式 “是一種工作方式。它是一種資助和組織軟體開發的方式，與專案的方式有很大不同。雖然這種工作方式普遍適用於數位時代的企業IT，但特別適合那些旨在透過數位平台推動業務發展的企業。下面總結了與專案的不同之處，並在文章的其他部分進行闡述。

專案

產品模式

什麼情況下會得到資助？

預先確定的解決方案或未完成的範圍得到資助

一個團隊得到資助。 一個產品模式的團隊是以滾動的方式（例如一次一年）獲得資助，並定期進行審查。團隊透過與產品/業務策略相一致的不斷發展的路線圖，處理一個又一個問題，大致在同一空間內工作。

資金是了為發展生命週期的哪一部分？

主要用於建構解決方案

用於建立、執行和迭代解決方案，甚至轉向不同的解決方案，直到基本問題得到驗證性解決

“構思”、”建設”、”執行 “的價值流階段如何組織？

作為分開的獨立部門

作為一個部門，有統一的報告層級

團隊可以持續多久？

直到專案資金持續，這理想地意味著直到最初構想的解決方案交付。通常情況下，需要幾個星期或幾個月的時間。

只要路線圖與業務相關。通常情況下，幾年時間。

人們會在同一個一般領域(area)長期停留和工作嗎？

不是依據設計。對於任何一個人來說，下一個專案可能是在一個完全不同的領域。

是的

如何確定優先順序？

專案與專案組合管理(PPM)小組一起按業務優先排序。閱讀更多.

路線圖專案由產品所有者和他們的業務對應方確定優先順序。跨領域的倡議由業務或技術領導層確定優先順序。初步沒有自己的團隊。它們被分配給已有的產品模式團隊。

如何進行效益驗證？

強調在專案批准前對預計效益進行正式評估。通常沒有在專案交付後驗證實際效益的機制；

產品負責人通過A/B測試、分析、使用者調查等資料或業務反饋來證明實際效益。這種能力取決於良好的工程能力，以小塊的方式頻繁地開發和釋出，以及良好的分析能力，以確定採用、轉換等方面的三角變化。 相對而言，人們不太重視前期的預期收益評估，尤其是在最好的這樣的團隊中，他們的執行週期很短，因此可以嘗試新的想法，而不會產生很高的失敗成本。產品所有者有權根據自己的需要批准路線圖專案的開發。透過小規模的、端到端的迭代開發，產品所有者能夠及早發現任何未能達到目標的努力，從而快速失敗（失敗-便宜）。

如何定義成功？

按時和預算交付商定的範圍

改善與業務結果直接相關的指標，或者與業務結果不超過一兩個層次的指標。因此，每一個產品模式的團隊最好都是業務KPI驅動的團隊。例如，Scout24是這樣操作的，團隊負責流量、參與度等。

圍繞著團隊組織，有沒有什麼制約因素？

沒有	當團隊的組織同時與業務相關能力和企業架構邊界保持一致時，產品模式效果最佳。如果沒有前者，他們可能會失去與業務目標的一致性。如果沒有後者，他們就會失去自主性，即相對獨立於其他團隊發展其系統的能力。

產品模式不再侷限於銷售軟體的公司。它在所謂的科技企業中很常見，這些企業由科技平台促成，包括串流媒體內容、電子零售、分銷共同基金、找出租車、住宿、航班，你能想到的都有。在更多傳統的老牌企業的數位/產品/工程/IT部門，它也在流行。例如，澳大利亞保險集團(IAG)最近從專案轉移到一個更持久的平台組織，以產品模式運作。澳新銀行也在嘗試類似的做法。

在產品模式下運作的團隊有幾種，不那麼理想的變化。有的地方採用專案模式資金和產品模式組織的半路出家。即使是產品模式的組織也不一定是建構+營運。或者跨職能團隊(cross-functional team)由向不同職能負責人彙報的人組成。

一個理想的產品模式團隊是一個授權的、以結果為導向的、業務能力一致的、長壽的、跨職能的、構思-建設-營運的團隊，它能夠並被期望解決問題，提高業務成果，而不是按期交付工作範圍。這些團隊承擔的問題通常是長期的，例如：不斷提高從購物車到結賬的轉化率（降低購物車放棄率）。問題的定義也需要足夠狹窄，以便各個團隊能夠擁有它們。例如，雖然 “網路促進者分數”（NPS）是一個很好的整體性指標，但它通常過於廣泛，任何一個特定的團隊都無法負責。

在產品模式下，不僅僅是團隊是長壽的，其與問題領域的關聯也是長壽的。產品模式的團隊往往執行在基於拉動的開發模式下，注重實現流程，而不太注重利用故事層級估算和釋出計劃實現可預測性。

在產品模式下操作的好處

在今天（2017年）的商業環境中，以產品模式營運比以專案模式營運有幾個優勢。

快速調整方向的能力

過去，IT/工程部門只要在收到市場情報或反饋後一年內作出反應即可。隨著 “數位化 “成為主流，這樣的情況已經不復存在。讓我們以線上零售為例。廣義上講，一個基本的線上零售平台的功能可以分為目錄、訂單管理、支付和履行。

在專案模式下，可能在某個時間點，由於優先順序的原因，我們有影響訂單管理、支付和執行的活躍專案，但沒有目錄。現在，如果收到來自市場或商業利益相關者的意外的、與目錄相關的反饋，我們不會有一個團隊準備好對反饋採取行動。通常情況下，任何新的反饋都會被預設為要經過商業案例和專案審批流程，然後是人員配置的優先順序。即使我們可以暫停其中一個正在進行的專案，並將團隊重新部署到目錄中，該團隊也很可能是目錄功能的新手，因此無法立即投入使用。

相比之下，在產品模式下，我們會有一個長壽的團隊（或團隊）專門負責目錄、訂單管理等各個環節，並隨時準備對新的反饋資訊採取行動。這隻需要團隊的產品負責人和他們的業務相關負責人做出決定，挪用一些團隊的能力來對新資訊採取行動。這種快速調整準備好的團隊能力是提高回應能力的第一要素。

縮短端到端週期時間

週期時間是衡量回應能力的一個常用指標。在整體週期時間裡面包括了調整方向的時間和執行時間。現在我們就來研究一下後一個部分。

大多數企業的 DevOps 計劃根本不會變更 “改變 “和 “執行 “組織之間的分離。通常，這兩個組織都會採用一些新的工具，一些部署和基礎架構自動化，也許還會加入一些 “雲端 “的措施。他們甚至可能會實現更頻繁、自動化和可靠的部署等好處。

然而，由於從開發到集中式運維的持續交接，交付變化的端到端週期時間不會有太大變化。產品模式團隊在部署和執行他們建構的東西時，不會受到這種交接的影響。因此，他們可以實現採用DevOps的全部潛力。將應用級運維與開發同地辦公，還能促進開發人員和網站可靠性工程師之間更好的端到端迭代和更好的理解。

請注意，產品模式團隊通常會繼續依賴其他專業的運維團隊，這些團隊提供自助式建構和部署基礎架構，管理資料中心和/或負責非應用級安全。這些團隊也可能在產品模式下執行，即使他們的業務能力不一致。

真正的迭代能力

COO經常抱怨技術組織的成本。然而，他們卻錯過了一個最大的省錢機會，因為其根本原因是在技術之外。大票專案的構思和資金一次到位，卻沒有有效的機制來驗證實際效益。這些專案經常在實現效益方面失誤。如果組織有跟蹤效益實現比（實際效益/預計效益）的習慣，他們在大多數情況下會感到震驚。真正的迭代開發流程將能夠廉價失敗，節省資金。

雖然迭代開發的概念已經存在了一段時間，但實際上，在大多數情況下，迭代只到了衝刺展示的程度。大多數Scrum團隊被約束在基於範圍的衝刺承諾中，並被期望按計劃交付範圍，而不是解決問題。為了迭代地解決問題，團隊需要能夠回應解決方案早期版本的反饋（使用分析、使用者調查、利益相關者的證詞）。產品模式的團隊，由於穩定且壽命長，可以選擇真正的迭代方式來解決問題。

專案團隊不能輕易脫離範圍交付，原因有二。首先，他們通常只是為了 “建構 “解決方案，而不是執行它。因此，他們在一個或多個版本中建構一個解決方案的版本，將其交給 “執行 “組織中的一個團隊，然後繼續下一個專案。第二，專案資金的運作方式是，提供資金維持一個團隊的時間遠遠短於正在解決的基本問題的壽命。

例子。一個退休計算器

例如，在一家金融服務公司，一個開發退休計算器的專案獲得批准，該計算器將促使潛在客戶購買退休產品或提高現有計劃的繳款額。該專案團隊只獲得了建立計算器所需的時間，而不是解決根本問題，即提高退休產品的使用率。另一個團隊將在公司網站上嵌入計算器，第三個團隊將建立必要的數位活動，以提高計算器的流量。至少有三個不同的經理（主管）將密切跟蹤工作的完成情況，與業務利益相關者保持一定的距離，在指定了要建構的內容後，或者最好是參與了為期一天的啟動/熱身活動。如果所交付的解決方案在市場上沒有達到目標，就必須等待另一輪的資金和人員配置，以便找到改進的解決方案。

適應產品模式

一個產品模式的組織會如何迎合上述情況呢？首先，我們不會考慮成立一個新的團隊來開發計算器。相反，它會由一個已經存在的、穩定的、長期存在的、最接近問題領域的團隊（即產品模式團隊）來承擔。在這種情況下，我們可能會有哪些產品模式的團隊呢？鑑於這個業務線銷售了一堆養老產品，我們是否可以每個養老產品有一個產品模式團隊？遺憾的是，由於業務流程&邏輯的共性，以及現有系統的形態，即使從客戶的角度來看，每個退休產品有一個團隊是不現實的。另一方面，一個產品模式的團隊來負責所有的退休產品，會顯得過於龐大，難以管理。

相反，我們會有幾個業務能力一致的、產品模式的團隊。這裡有一個關於退休產品的長期客戶旅程的分割方式：入職公司、招收員工、退休儲蓄、提取等。請注意，每個分割都是以客戶為中心，是一個肉眼可見的切片，資料和業務邏輯分佈在多個系統中。整個客戶歷程太大，不可能由一個團隊來擁有。因此，每個分割（業務能力）都存在一個產品模式的團隊。這有點類似於前面的線上零售平台的例子，整個客戶旅程被分割為目錄、訂單管理、支付和履行。

現在，任何關於退休計算器的工作，如果是為了改善註冊或儲蓄，將屬於註冊或儲蓄團隊的職權範圍。這個團隊，根據它一般解決的問題的性質，通常會有數位行銷技能，並在團隊內訪問行銷系統和資產。該團隊現在將負責提供和證明歸於核算機的轉化率的改進。作為一個長期的團隊，它將有足夠的時間來迭代開發和測試解決方案的有效性，同時在低谷期關注其他路線圖專案。

從成本和時間上看，產品模式的設定很可能比專案模式的設定要好。對於任何給定的組織來說，可靠地驗證這一點的唯一方法是嘗試在幾個問題上使用產品模式，並評估結果。

知識保留

軟體的真相是，再多的文件、交接、知識傳遞都無法彌補團隊100%的流失。然而這正是專案模式帶來的結果。技術能力並不駐留在成熟度模型、流程樣板、文件、程式碼或基礎設施中。它駐留和成長在一個團隊中。

知識在穩定的、長壽的團隊中成長並保持得更好，這些團隊在同一個通用領域工作了幾年。這與那些每隔幾個月就急速上升和下降的專案團隊形成鮮明對比。不可維護的程式碼至少有一部分來自於沒有維護的團隊。

儘管文件是有用的，也是必要的，但在那些喜歡 “可運作的軟體而不是全面的文件 “的組織中，它不能代替產品模式團隊中的知識保留。

產品模式團隊允許團隊成員專注於某一特定領域（與業務相關的能力），時間遠遠長於典型的專案持續時間。這有助於建立知識，提高對問題和權衡的理解，並豐富與中小企業和利益相關者的互動品質。

當團隊成員離開時，產品模式團隊會失去知識嗎？如果他們的工作是基於整體範圍的集體所有權，就不會。當團隊成員各自擁有不同的功能或子領域時，知識保留就會有風險。

架構完整性

專案模式中涉及的激勵措施給團隊帶來了壓力，使他們忽視了中期的架構完整性，而傾向於（通常認為）短期的功能交付。由於團隊不面對這種交易的後果，他們無法從長期所有權時出現的反饋迴圈中獲益。眾所周知，專案團隊在狹隘地追求專案及時交付的過程中，由於不瞭解企業架構準則或乾脆忽略了這些準則，從而（無意中）造成了架構債務。從中期來看，這種現象會影響系統的穩定性，降低交付速度。舉幾個例子。

• 他們可能最終會對一個註定要日落的系統進行低努力的整合，而不是對即將到來的後續系統進行高努力的整合。這就影響了日落路線圖，並增加了維護具有類似功能的多個系統的應用環境的成本。
• 他們可能最終會與下游系統進行直接的資料庫整合，而不是透過API暴露其功能後進行整合。反過來，這又會傷害到下游系統的任何需要對其資料庫模式進行突破性改變的進化。

另一方面，產品模式的團隊不會讓其他團隊與自己的系統進行不恰當的整合，因為他們更敏銳地意識到後果。這就是 “建構+執行 “團隊擁有系統的優勢，而不是專案模式下只執行團隊擁有系統。

程式碼和系統的所有權

團隊層面對程式碼和系統的所有權極大地幫助了團隊在構思-建構-執行模式下的運作能力。所有權使團隊能夠以更快的速度和更可控的方式進化系統。但集體所有制的理想呢？在團隊內部，以集體所有制( collective ownership)為目標是很好的，因為個人所有制的選擇是有問題的。但在團隊之間，明確的所有權劃分可以實現負責任的自治。

一些最先進的科技公司採用了內部開源模式。任何團隊中的任何人都可以透過向保管人（類似於開源專案中的核心提交人團隊）團隊傳送 pull request 來提出對幾乎任何程式碼區域的修改。

雖然這種模式可以與團隊級的所有權共存，但它往往會產生一種預設的期望，即依賴團隊會自我服務於他們所需要的變更。這在開源專案中是一個常見的期望（”發現了一個bug？ 很好，請提交一個修復。”），但在大多數主流企業的數位/工程/IT部門是不現實的。首先，很少有領域知識的水平來有效地對不同的系統進行修改。此外，它要求所有的程式碼在文件、建構（就像簡單的檢查和建構）和測試準備方面保持在一個可自助的水平–這對大多矩陣組織來說是一個很高的要求。這也是為什麼內部開放原始碼計劃在大多數嘗試過的主流企業中都未能成功的原因之一。對於這樣的組織來說，務實的做法是，不要把預設的期望看作是自我服務，而要把它看作是一種協商的依賴。任何變革都必須在預設的情況下，得到自己團隊的同意，並確定優先次序和交付。

團隊激勵和動力

團隊作為一個單位有效地合作需要時間。塔克曼的團隊發展理論認為，一個團隊在進入執行階段之前，會經歷一系列的次優階段(形成、暴風雨和規範化)。專案模式的人員配置有可能在團隊進入規範化或執行階段時就將其解散。產品模式的團隊，由於穩定和長壽，可以從漫長的執行階段中獲益。

研究發現，自主性、掌握性、目的性和歸屬感是關鍵的內在動力。與典型的、範圍交付的專案團隊相比，產品模式團隊往往具有更大的自主性和目的性。因此，採用產品模式的團隊通常受到群體的歡迎，即使管理層需要時間來適應新的正常情況。

流程和迭代的經濟性

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

— Donald G. Reinertsen

到目前為止，這些論點聽起來可能與傳統的 IT 智慧相悖。但商業環境已經發生了巨大的變化，大約是從智慧手機上市以來。雖然把IT/工程當作成本中心從來都不是明智之舉，但現在卻是站不住腳的。以成本效益為主要關注點來管理IT，從來沒有像現在這樣適得其反。在遲緩的後端IT之上建立一個高速的 “數位化 “前端組織是不夠的–雙模/雙速IT是建立在一個錯誤的前提之上的，它的肇事者已經開始承認這一點。

傳統的IT智慧在幾個方面已經過時了。其中一個方面是為了規模經濟而組織IT團隊，以最大限度地利用IT專家的規範。在某些方面，基於專案的營運模式反映了這種規範，一是使用臨時變更團隊，二是使用共享服務進行設計、測試、部署等。另一方面，流程經濟和迭代對於響應性的目標更為重要。

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

同樣，當實現商業利益所需的努力隨著微小變化的迭代能力的提高而減少時，迭代經濟就會出現。只建構的專案團隊遭受了太多的交接，無法有效迭代。此外，他們的生命力不夠長，無法持續進行一系列真正基於反饋的迭代。產品模式的團隊，從設計上來說，不存在這些缺點。

產品模式下的營運挑戰

工作人員使用情況

一個常見的擔憂是這樣的。”如果一個產品模式的團隊沒有工作怎麼辦？”。如果團隊負責一個足夠大的領域，如目錄或執行，這種情況就不會發生。此外，團隊的規模會定期（如一年一次）進行審查，以調整變化的、相對的優先順序。有些地方採用核心加彈性的模式，即核心團隊由員工組成，彈性的由承包商補足。不過，如果某個業務能力領域沒有足夠強大或重要的路線圖，它就會被（和核心團隊一起）摺疊到鄰近的能力中，直到下一次審查。

有時，根本的問題是：”如果我們（PMO或相當於PMO）不優先考慮某個團隊工作領域的任何事情怎麼辦？” 而答案是，產品模式的團隊是要成為一個授權的、半自主的單位，因此，並不完全依賴於外部的優先順序安排。只有交叉性的舉措才會被外部確定優先順序。對於路線圖工作，團隊層面的產品所有者( product owner )被授權與業務利益相關者共同確定優先順序。一個經驗法則是，路線圖工作佔三分之二，倡議工作不超過三分之一。因此，組合管理在產品模式上發生了根本性的變化。

跨職能團隊中不同角色的利用情況如何？如果沒有足夠的工作讓所有不同角色都忙起來，會發生什麼？好吧，人們會從事與自己技能相近的工作，例如，業務分析師可能會進行探索性測試，QA可能會幫助改進文件，等等。在開始的時候，他們可能需要跟隨他人來獲得初步的技能水平，但很快他們就會從一個專家變成一個通用的專家。

在談到利用的話題時，需要注意的是，為利用而最佳化不利於縮短端到端週期時間。你不能透過提高高速公路的利用率（即引入更多的車輛）來改善高速公路的交通流量。主要關注利用率是 “以IT為成本中心 “的思維方式的遺蹟。它與數位化業務格格不入。

狹隘性

穩定、長壽的團隊是不是會讓人產生孤立的態度和普遍的停滯？這是一個風險，但通常情況下，技術團隊總是會有一些變動，這提供了一些新思想的注入。此外，許多組織贊助實踐社群–非正式的內部網路，與特定的能力相一致，如客戶體驗、A/B測試等–將各團隊的人員聚集在一起。

新的孤島

在專案模式下，我們會遇到產品管理、架構、設計、開發、測試、營運和支援等孤島。在產品模式下，我們會不會最終出現新的、與業務能力相一致的孤島，如目錄、訂單管理、支付和執行？也許會，但它們遠沒有活動導向的孤島那麼糟糕。產品模式的團隊，是以結果為導向的，最壞的結果可能是仍在為業務結果而努力的孤島。與業務能力相一致的孤島並不像與產品開發價值流的階段相一致的孤島那樣糟糕。

也就是說，我們可以透過沿著由服務體驗（如 “問題到解決”）或業務價值流程（如 “訂單到現金”）定義的業務對齊的能力邊界建立產品模式團隊，來一定程度上降低新孤島的風險。如果這對一個團隊來說太大了，那麼我們就會將其劃分為多個團隊（部落內的小隊，用Spotify流行的命名模式來說），但儘量讓他們同地辦公，並指定一名服務體驗提倡者或業務價值流程所有者與分部級產品所有者合作。

作為一種對策，對於跨越多個產品模式團隊的計劃，建議任命穿透孤島、優先順序談判、依賴性管理的解決方案提倡者，與產品所有者和業務利益相關者合作。另一個好的做法是，為人們提供一個選擇，讓他們在長時間的工作後，比如18到24個月後更換團隊。

最終，在產品模式下打破孤島是為了確保一致性和自主性。老派的方法是透過犧牲自主權來實現一致性。相反，我們使用對齊地圖等技術來獲得兩全其美的效果。

其他考慮因素

到目前為止，我們已經從利益和挑戰的角度來審視產品模式。最後一節討論其他一些常見的考慮因素。

分層團隊

前面提到的線上零售業的例子提出了產品模式的團隊，如目錄、訂單管理、結賬和執行。而退休產品的例子則提出了產品模式的團隊，如入職( onboard)、註冊、儲蓄和提取。這就提出了一個問題，這些團隊是否對企業應用堆疊，即從面向市場的前端系統一直到支援後台功能的後端系統（下圖中的第3層和第4層）有端到端的責任。答案是 “不一定”，原因如下。

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

即使端到端的責任有助於結果導向的事業，但考慮到系統的形態，這往往是不現實的。例如，線上零售平台通常至少有一個 web app 和行動app作為客戶店面，一個呼叫中心app作為支援前端，一個店鋪管理app作為店鋪經理的另一個前端。通常情況下，這些前端系統中的每一個都有自己對底層功能的依賴性足跡，如目錄、訂單管理、結賬和執行。通常，對於一個端到端目錄（或任何其他能力）團隊來說，沒有明確的、前端系統的邊界。例如，如果只依賴於目錄等單一的第三層能力，可能會避免建立第四層的商店管理應用團隊。所示的圖片假設商店管理不僅僅依賴於目錄。因此，我們採用如圖所示的第3層和第4層的獨立產品模式團隊。高層的層級是低層的消費者。

一個新的趨勢是將前端系統分解成與第3層能力一致的微前端。這樣就更容易擁有跨3層和4層的端到端團隊。但大多數已經/正在向微服務轉移的地方，還沒有計劃向微前端轉移的打算。

有時，由於存在支援多個tier-2B能力的遺留系統，可能會導致一個tier-3團隊也依賴於一個擁有相應技能的tier-2B團隊。理論上，可以將tier-2B人員嵌入到相應的tier-3團隊中。但在實際操作中，可能會受到tier-2B能力稀缺或共享配置管理、測試環境等實際挑戰的制約。

第1層和第2A層是持續交付、DevOps和精益產品開發的推動者。它們更適用於各個業務領域。例如，管道基礎設施團隊負責維護Jenkins/GoCD/TeamCity…基礎設施。他們不負責處理更高層團隊的破損建構。因此，較高層級可能會對較低層級有一個或多個依賴關係。無論哪個層級，每個團隊都是產品模式，因為他們是穩定的、長壽的、跨職能的、以結果為導向的、構思-建構-執行的團隊。低層團隊以解決問題（而非範圍交付）的方式將高層團隊視為其（內部）客戶。

小隊和部落

通常情況下，像目錄這樣的單一領域，可能一個團隊無法勝任，將其拆分成多個產品模式的團隊也是可以的。在這種情況下，目錄部落有多個小隊，每個小隊都有自己的成果、路線圖和所保管的系統。這種結構也允許區域性共享（部落內部）可能難以嵌入每個小隊的角色。需要注意的是，小隊的壽命要比一般的專案團隊長得多，儘管小隊成員可能會被刻意要求每隔18到24個月在部落內輪換一次，以獲得廣泛的知識，避免成為單一的失敗點。

但產品在哪裡呢？

重申開頭說過的一個觀點，不一定要在產品模式下打造產品來營運。也就是說，如果我們超越傳統的產品定義，將產品定義為在市場上銷售的東西，那麼就可以將目錄這樣的東西看成是產品。一旦像目錄這樣的能力被包含在一個團隊所擁有的一套系統中，並透過內部應用或記錄良好的API暴露出來，它就變成了一個可重用的、可自我服務的、類似產品的能力，以迎合內部客戶的需求。這同樣適用於低層產品模式的團隊。

結論

總而言之，要想獲得更高的回應速度和更高的效益實現比，”產品模式 “是一種比專案更有效的工作方式。

對於主流企業的Digital/Product/Engg./IT部門來說，可能會覺得這是一個激進的變革，在某種程度上也確實如此。然而，之所以感覺激進，只是因為我們沉浸在 “專案 “的工作方式中。亞馬遜首席技術官Werner Vogels，在2006年採用時描述了類似的方法。

在亞馬遜使用的細粒度服務方法中，服務不僅代表軟體結構，也代表組織結構。這些服務具有很強的所有權模式，再加上團隊規模小，目的是讓創新變得非常容易。在某種意義上，你可以把這些服務看作是大公司牆內的小型創業公司。這些服務都需要非常關注客戶是誰，不管他們是外部還是內部。

— 沃納-沃格爾斯

要想遷移到產品模式，最好採用一種迭代和廉價失敗的方法。從一兩個試點開始，學習和適應。雖然對於那些習慣於用詳細的路線圖來批准大的變革專案的人來說，可能會覺得不妥，但在驗證實際（而不是預計）效益之前，避免過度投資是精益-敏捷思維的精髓。

附註

不要把它當做一個城市來經營

專案模式類似於城市的執行方式。一個城市要保持燈火通明，可以說是各個部門，如供水、衛生、交通、治安等。在這些部門工作的人，就相當於我們的營運（執行）團隊。另一方面，當要新建自來水廠或汙水處理廠，或者要引進一條新的地鐵線路時，市政府會把它們作為專案進行資助，由承包商來執行。他們相當於建（改）隊。

與現代軟體團隊 “我們建構，我們執行 “的精神不同，城市的做法是 “你建造，我們執行”，這對一個城市來說是行之有效的，儘管它的市民可能更希望在各個領域得到更快的改善。另一方面，與軟體的情況不同，建設/改變一個城市的基礎設施和服務所需的技能與執行它們的技能有很大的不同。對一個城市來說，為總是在變化的團隊支付費用可能不划算。專案模式對城市來說是划算的，但當他們在業務投資上輸給其他城市時，他們確實要為低迷的業績付出代價。

傳統企業IT沿用了常設 “執行 “團隊和按需 “變革團隊 “即 “專案 “方式的雙管齊下的城市模式，並在業務響應速度上付出了代價。數位化時代的企業在應對業務利益相關者或市場的反饋時，不能怠慢。與業務能力相一致的團隊需要有一定的資金、人員配備和權力，以便在短時間內轉換重點或改變解決問題的方法。