如何在產品模式組織中管理計畫

一開始就投資時間，讓計畫成功

計畫的開端提供了一個自然的暫停點，可在此時執行重點工作坊，讓團隊和計畫為成功做好準備。在計畫啟動結束時，業務利益關係人和團隊成員應了解此計畫及其重要性、他們在計畫中的角色、計畫將如何執行，以及第一個版本的概略範圍。在計畫啟動時預先投資時間，是針對延誤數個月的交付日期進行適當的風險緩解。我們建議撥出時間執行一系列工作坊，以提供以下成果

• 讓所有利益關係人了解需要完成的事項及其原因（包括對目前營運模式的任何變更）；
• 定義一致的工作方式、儀式和最佳實務；
• 向所有參與團隊說明業務、技術和客戶背景；
• 透過明確說明個人的角色、責任和動機，建立團隊之間的信任；
• 為建立團隊內部同理心和了解奠定基礎；
• 說明交付中存在的風險、依賴性、假設和複雜性。

一個旨在達成這些成果的啟動時間表範例如下

選擇適合計畫的領導風格

根據組織的不同，產品部門的現有文化可能無法接受計畫交付所需的急迫性和流程標準化程度。因此，計畫領導人（擔任解決方案倡導者）可能會發現他們需要調整自己的領導風格，以符合計畫的要求。

例如，情境領導模型提供了各種領導狀態下一些常見溝通風格的有用描述（請參閱側欄）。在理想狀態下，自組織產品團隊的領導人將會讓團隊參與並賦予團隊權力。然而，由於該計畫可能需要改變營運模式，挑戰所涉及產品團隊的自組織性質，因此領導人可能需要調整他們的風格，並花費比他們習慣更多的時間來釐清和定義。

除了改變他們的溝通風格之外，計畫領導人還需要讓團隊對支援新營運模式所需的那些變更負責。一個常用的工具是用於傳達責任和問責制的責任分配矩陣（請參閱 RACI 矩陣側欄）。可以使用類似這樣的東西來幫助團隊成員了解在維護流程標準和參加關鍵計畫會議方面對他們的期望。

勤奮管理依賴關係和風險

團隊之間的依賴性（稱為積壓耦合）在計畫交付中很常見，因為多個團隊將負責交付解決方案的不同離散部分。積極管理這些依賴性的良好做法是預先載入旨在解耦個別團隊積壓的計畫交付活動，以便讓團隊能夠更自主地交付。

例如，為了減少我們範例中產品團隊之間的積壓耦合，計畫團隊可能會決定花費其前幾個迭代來圍繞構建一個可運作的雛形（請參閱下方的圖 7）。假設有一個成熟的持續交付設定，可運作的雛形可以部署到生產環境，並在功能標誌的背後，讓未來的計畫進度更新專注於可運作的雛形的演進，因為產品團隊增加了更多的保真度和範圍深度。以下是一個發布計畫的範例，顯示可運作的雛形團隊如何融入產品藍圖。

在我們上述的範例中，骨架會包含整個 MVP 使用者歷程，但使用者介面的保真度投資不多。此外，所有 API 整合都會以任何模擬和硬編碼的資料截斷。骨架並非供客戶使用，而是讓產品團隊彼此合作的工作在團隊繼續交付自己的待辦事項之前大部分都已解決。此外，一旦骨架建置完成，它就能讓所有團隊持續整合他們的程式碼，減輕整合過晚的風險。

程式交付會有許多其他風險，因此積極管理風險作為正常反覆週期的部分對於成功至關重要。積極的風險管理並不總是標準產品交付週期的一部分（如上述範例所示），因此領導團隊可能需要一些紀律，才能在整個交付過程中保持動力。

制定強而有力的溝通策略

專案管理中協調工作的一大部分花在溝通上，目的是

• 確保所有相關利害關係人保持知情，並有機會提出問題和發問；
• 促進團隊間的溝通，以協助減輕交付中的瓶頸；
• 向專案領導團隊提出阻礙因素，以便他們能協助減輕這些因素。

由於專案中需要這種溝通開銷，專案領導應該著手建立一個強而有力的溝通策略，其中包含滿足每個利害關係人團體需求的接觸點。一個範例溝通策略可能類似這樣

投資於有助於資訊傳播的視覺化成果

視覺化工件，例如實體計畫牆（見下圖 9），可用作計畫的絕佳資訊散播器，不僅對主要利害關係人有利，對整個公司也有利。

計畫牆一開始可以視為獨立的計畫，但也可以透過保持最新狀態並迫使對話圍繞它發生，來建立新的組織習慣和紀律。實體牆一個有趣的附加好處是，它們可以促進團隊之間的協作和責任感。此外，計畫牆可以讓公司中的其他人快速吸收資訊，而無需安排與任何人見面的時間，從而幫助他們提出問題。

理想的專案牆面僅包含足夠的資訊，以便快速提供狀態更新。從上述範例中，我們可以得知蜂群團隊已完成其工作並解散，而傳遞團隊目前正在處理其可交付成果，其中一個團隊需要一些協助來移除未來的阻礙因素。

不要害怕為計畫管理定義角色

我們相信專案管理的紀律對於確保成功至關重要，特別是在任何計畫都涉及多個團隊的協調與協作以提供價值時。然而，實際的角色定義與責任將取決於組織背景與專案複雜度，因此我們偏好稱這個角色為「解決方案擁護者」，而非專案經理。然而，從根本上來說，需要有人負責計畫的整體健康狀況，並將其精力集中在下列策略要素上

• 持續確保團隊之間的一致性；
• 確保團隊與外部利害關係人之間的溝通順暢；
• 保持相關且重要的資訊最新；
• 管理專案依賴關係與風險。

務必在專案啟動時，讓所有參與者明確了解角色的責任。我們在產品模式組織中導入解決方案擁護者時，觀察到一個風險，即產品團隊成員與解決方案擁護者可能會產生重疊的責任，導致這兩個角色的效能降低。如前所述，解決方案擁護者應專注於專案的策略面向，而非所涉團隊的戰術性產品傳遞任務。下列 RACI 矩陣顯示角色之間的責任區分

請注意解決方案擁護者與產品傳遞領導和團隊之間的責任區分。