使您的技術和產品團隊與技術產品畫布保持一致

收聽本文的音頻版本

產品開發和技術團隊之間的溝通不暢可能是軟件開發中資源浪費的最大來源。 高增長的科技公司正面臨對產品交付的日益增長的需求，因此，有時會放棄適當的規劃。 有多種跡象表明產品和技術團隊缺乏一致性：

• 未按要求交付的產品。
• 交付產品功能所需的時間比計劃的要長。
• 團隊每週幾乎沒有互動和溝通。
• 由於新產品的需求，技術團隊不得不“重新做”他們的基礎設施。
• 與競爭對手相比，發展速度感覺緩慢。
• 技術團隊經常問：“你之前為什麼不告訴我們？ ”

成功的公司積極管理這兩個團隊之間的接口，並擁有每個人都理解的清晰的產品和技術路線圖。 然而，目前還沒有任何流行的方法以結構化的方式解決這個問題。

相反，大多數時候，這些目標是通過非結構化會議以臨時方式實現的。 與此最接近的比較是規模化敏捷框架，但即使是這些方法也並不總是適用於所有公司，尤其是較小的公司，因為這種方法需要採用整個框架。

輕鬆實現產品和技術團隊之間一致性的方法之一是使用結構化的技術產品畫布

什麼是技術產品畫布？

畫布概念已經存在很多年了。 該領域的主要遠見者和創新者包括創建商業模型畫布的 Alexander Osterwalder、Roman Pichler 和他的產品願景畫布，以及以用戶故事映射方法和他的機會畫布而聞名的 Jeff Patton。 我使用畫布方法來解決產品和技術對齊的問題，並創建了技術產品畫布。

畫布將作為促進團隊討論並讓每個人都在同一頁面上的快速方式 - 從字面上看。 這是創建此文檔的最重要的好處之一。 通過整個過程（可能只需要一個小時），您將開始管理產品和技術團隊之間的一致性。

技術產品畫布迫使您的團隊陳述和可視化產品路線圖目標、技術路線圖目標，並明確討論路線圖的每個產品技術階段。 此練習可確保團隊保持同步，並且每個人都可以帶著明確的期望和方向離開房間。

通過與科技公司的合作，我注意到業務目標和技術能力之間的交叉點是最大風險所在。 創建技術產品畫布是為了管理這種確切的風險。

何時使用技術產品畫布？

技術產品畫布討論最好由產品所有者在您完全定義產品願景、執行故事映射過程並製定初始產品發布路線圖時發起。 在這個階段，哪些產品功能對每個主要版本至關重要。 此時，團隊已準備好就如何構建產品進行詳細的技術討論。

技術產品畫布練習將帶來清晰性，有時會產生衝突，但最終會就開發產品需要採用哪些技術架構以及技術平台將如何發展以滿足產品需求達成一致。 它將允許技術團隊集思廣益，並確保獲得他們對創新的投入。

讓我們通過一個更詳細的示例來說明如何在假設的新軟件企業中使用技術產品畫布，以便我們可以看到它的實際應用並學習如何使用它。

如何使用技術產品畫布

技術產品畫布主要是用於創建焦點、溝通和團隊協調的工具。 畫布允許您與您的技術團隊進行對話，以確定支持產品開發所需的技術架構。 讓我們使用一個新軟件產品的假設示例。 一個新的基於位置的應用程序，可以將人們與周圍的人聯繫起來 - 一個社區應用程序，可以將您與您的鄰居聯繫起來。

您可以在此處下載技術產品畫布。 您也可以打印出畫布並在上面寫字。 或者，您也可以使用我在本文中使用的 Miro 等在線工具。

配置

假設您已經與您的初創團隊合作了幾個月，您有一些很棒的想法，現在您熱衷於計劃軟件開發。 您已經在精益畫布上工作，甚至創建了用戶在使用應用程序時將體驗到的流程步驟的故事圖。 現在您需要構建它。 因此，您讓每個人、您的產品團隊和您的技術團隊都進入會議室，並在會議室屏幕上投影一個空白版本的技術產品畫布。 從哪兒開始？

首先是對為什麼每個人都在這里以及您要實現的目標設定期望。 向您的團隊解釋他們來這裡是為了確保產品目標和技術任務之間的計劃。 此外，強調您並不是在尋求完美，並且隨著您了解更多和需求發生變化，您將每隔幾個月繼續審查一次。 但是，至少在今天，這是為了確保你們都在同一頁上。

第 1 步：定義成功指標

您將如何衡量您的整體計劃是否有效？ 業務目標是什麼？ 它們可能是每個發布階段的收入或應用下載次數。 如果您熟悉精益畫布，您可能已經確定了這樣的數字。 將該信息複製到此部分。 在這個例子中，我使用了以下兩個成功指標：“在我們的第一年聯繫 1,000 人”和“在洛杉磯創建我們的品牌”——一個可量化的指標和一個定性的指標。

但是為什麼我們首先關注這個呢？ 它確保整個團隊都明白我們為什麼在房間裡。 我們有一個比任何產品或技術問題更大的目標。 這是我們都在這裡的商業原因。

第 2 步：完成您的產品願景和產品發布部分

這使團隊能夠清楚地了解我們的產品願景是什麼以及我們目前如何定義我們的產品開發優先級。 寫下產品願景聲明以及主要目標群體是誰。 然後，確定您希望在每個版本中交付的一些關鍵產品項目。 我建議作為一個團隊填寫這些框，而不是事先預先填寫。 它確保技術和產品團隊成員都參與定義目標的過程。 從左到右工作：確定第一次產品迭代的目標——滿足客戶需求所需的主要功能。

在我們的應用示例中，我們的產品願景是“讓居住在我附近的人們之間能夠進行實時交流，以加強社區”。 之後，在產品發布中，我們可能會說版本 1 是“識別您當前的位置，顯示附近的人並與他們的電子郵件地址通信”。 V2 可能是“顯示附近的人並允許實時聊天”。 V3 可能是“實現隱私和貨幣化”。 產品的這些迭代將輸入到畫布中，如下所示。 使畫布盡可能簡單，以便人們可以看到全局。 畫布也旨在捕捉長期願景。 請記住，這可能是技術團隊第一次看到如此清晰的產品圖景，因此請花足夠的時間確保他們了解每個版本和隨附的要求。

第 3 步：將技術願景與產品願景相匹配

現在是時候從技術團隊那裡獲得意見並定義他們對技術架構將如何發展的願景了。 從技術願景開始，該聲明概述了開發的大局，並且可以在供應商工具更改後繼續存在。 在我們的應用示例中，技術願景可能會聲明：“使用提供位置信息的設備的地理位置功能，並使用無服務器微服務來啟用雲協作功能。” 在這一點上，我們沒有選擇特定的工具。 將技術願景視為技術將如何提供幫助以及我們正在尋求採用哪些創新以實現競爭優勢以及可以使我們實現願景的技術跑道的大創意。

第 4 步：將技術計劃與產品目標相匹配

這就是橡膠上路的地方。 在第 2 步中，對於每個產品發布迭代，都確定了關鍵特性。 現在您需要為每個版本定義技術計劃。 確定需要哪些技術架構和工具來支持這些功能。 確定確切的工具並獲得技術是可以的。 如果需要，您可以在未來的版本中進行調整。 該計劃是讓技術團隊明確傳達他們需要做什麼。

讓技術團隊領導這部分，並向他們保證答案不一定是完美的。 如果他們需要離開並進行更多研究，他們可以在會議結束後進行。 但是這裡的目標是完成畫布的第一次迭代，以後可以更新。 完美是成功的敵人。

在我們的應用程序示例中，我們查看產品版本 1 框中的產品需求。基於這些要求，我們可以說技術計劃 1 是“使用 Ionic 開發一個漸進式 Web 應用程序以啟用跨平台應用程序。 使用設備的地理位置功能。 與 Firebase 後端同步。 使用 SendGrid 電子郵件服務。” 此處描述的技術計劃和目標應該足以實現產品目標。 確保團隊沒有在不存在產品目標的情況下過度設計。

在這一步中，我們終於可以看到畫布的力量——這就是我們調整團隊的方式。 我們將產品目標與技術計劃保持一致。 中間那條線呢？ 這就是接口，產品經理需要在團隊之間積極管理。

同樣，技術計劃 2 將是“使用 Facebook/Google 授權實現用戶身份驗證，實現與 Firebase 數據庫和聊天界面的實時聊天”。 技術計劃 3 將是“為應用升級實施隱私/GPS 隱藏和應用內購買方法”。

該過程將要求您會議中的技術團隊參與討論。 您將有機會分享和討論所有想法和見解，並且您將獲得團隊一致和支持。 在這裡，團隊各方面的人員將了解需要討論的需求、優先事項和問題，並且您將在這裡制定初步計劃和協議。

至此，您擁有了與產品路線圖相匹配的第一稿技術路線圖。 關鍵技術任務以可視化流程佈局，這將幫助您的團隊了解應該關注什麼以及何時關注。

第 5 步：識別風險和資源

最後，一旦從技術架構的角度決定瞭如何構建產品，討論風險和資源是一個好主意。 在我們的示例中，我們可能會針對風險說：“漸進式 Web 應用程序可能不夠快。” 如果是這樣，我們可以轉向 React 或 Native 應用程序開發。 對於資源，我們需要具備“Ionic、PWA、地理定位和 Firebase”技能的人員。

將這些項目包含在此處可確保這一單頁摘要捕獲討論中出現的重要元素，並且在您稍後再次查看畫佈時會有所幫助。

全圖

這是基於我們上面假設的應用程序示例的技術產品畫布的完整示例：

不應該期望畫布必須在第一次完成時就完全完成。 作為一個團隊，您可能不同意與技術能力相比什麼是產品功能以及在畫布上放置什麼。 畫布的目的是發起和構建討論，以便在會議結束時，您和整個團隊對如何進行開發有更好的概念共識。

該文檔現在是您的開發計劃的核心。 這是高級開發路線圖，技術團隊現在可以根據業務目標制定更詳細的開發任務。

結論：迭代您的技術產品畫布

創建技術產品畫布的五個步驟是：

1. 定義成功指標
2. 完成您的產品願景和產品發布部分
3. 將技術願景與產品願景相匹配
4. 使技術計劃與產品目標相匹配
5. 識別風險和資源

畫布的一個非常重要的好處是它允許團隊確定需要在每個階段應用或開發的“最小”技術。 它可以幫助產品團隊了解所需的技術工作和未來的任何挑戰。 產品開發不會因為缺乏技術能力而放緩，因為技術計劃是同步的，並且可以看到足夠多的步驟。 在應用程序示例中，當我們接近發布版本 1 時，我們將對團隊進行培訓或尋找 SignalR 技術專家，以便為需要該技能的發布版本 2 做好準備。

您可以在此處下載技術產品畫布。 我建議團隊每季度進行一次審查，並且絕對是在每個版本完成時進行。 隨意修改畫布以更好地滿足您的需求。 我真的很想听聽您對如何改進技術產品畫布的反饋。