您是否在開發對組織來說有價值的產品？如何判斷產品是否有價值？
如果沒有經常提出這兩個問題，那麼您可能忽略了產品價值方面的問題。
產品是目前工作所要達成的目的，是組建團隊的原因。產品也是你選擇Scrum的原因，所以，你必須要集中精力理解並提高產品價值。
優化產品價值的4個步驟
第1步：培養產品思維而非專案思維
產品思維聚焦於創造有價值的輸出。
如果開發的產品沒有人想要或使用，那麼產出就毫無價值。
作為一名以傳統專案管理作為職業起點的PMP，我對專案思維模式非常熟悉。衡量專案是否成功的標準通常基於一個鐵三角：在規定的時間和預算內交付所有預期功能。
Scrum不是以更快、更便宜的方式交付更多產品。
Scrum旨在頻繁交付更高的價值。
通過交付更高的價值，可以為組織降低風險，並挖掘更多的可能。雖然仍然需要做專案預算和時間表，但更需要重視的是要確保開發的產品是適合的。以下幾步將詳細介紹如何做到這點。但是，培養產品思維是一個持續的過程，因為人們很容易重拾舊思維，尤其是在壓力下。
當出現“專案狀態”的對話時，請注意傾聽發起對話的人的思維模式。如果對話只涉及專案完成百分比、專案預警、問題跟蹤等問題時，你需要問一些強有力的問題把大家的焦點帶入產品思維模式中。這裡有幾個例子可供參考：
- 我們如何驗證有關使用者需求/市場需求的假設？
- 我們對價值瞭解多少？如何通過價值指導產品決策？
- 從我們開始這個專案以來，使用者/競爭環境發生了哪些變化？
Scrum團隊裡的PO（Product Owner）在培養產品思維模式方面扮演很重要的角色。
第2步：描繪巨集偉藍圖
由於你是以迭代遞增的方式開發產品，因此必須清楚地瞭解工作的方向和原因。這樣可以幫你確定是否與公司目標保持一致並在需要的時候做出相應調整。
有許多方法可以幫助企業明確產品目標（產品願景）及其背後的商業模式。產品願景描述的是對產品的期望，向目標使用者傳達的是其主要價值定位。
巨集偉藍圖還包括價值定位。期望中的產品會有許多的特點和功能。所以為了衡量價值大小，必須要定義產品中最重要的價值點以及如何判定你達到了預期目標。
雖然對價值的定義高度依賴於背景，但以下幾種價值型別也可以考慮：
- 商業目標（如，客戶轉化率）
- 利潤/收入（如，每位客戶帶來的收益、回頭客）
- 節約成本（如，獲客成本）
- 客戶/使用者增長率（如，新客戶、市場份額、使用最新版本的客戶）
- 功使用率（如，使用某項功能的客戶、使用某項功能的時間）
現在，具體要做的就是明確價值定義及如何衡量價值。
第3步：價值實現
複雜問題的解決辦法總會在你認真工作（不僅僅是分析和談論）的時候出現，你可能會判定那些假設是錯誤的，也可以看出市場甚至是商業模式已經發生改變。
因此，必須在開發產品的時候讓價值湧現。產品Backlog代表計劃開發的產品及開發順序。而通過產品Backlog的細化過程來使價值湧現時，需要注意3點：
- 將任務分解到足夠小
- 理解價值一致性
- 拉遠/推進
將任務分解到足夠小——以便更靈活快速地交付價值。一旦確定了願景，就會有一些實用的方法來構建更高層次的細節。首先，可以確定實現願景的關鍵業務結果或目標。然後，再確定交付預期結果所需的關鍵特徵、功能或效能。
任務分解越細，靈活性越強，交付價值和驗證假設的速度就越快。還有很多補充的方法和理念會對細節上的工作有所幫助（如需求地圖和假設地圖）。達到“中等水平”後，可以考慮嘗試進一步分解PBIs（Product Backlog Items）的模式。
記住不需要提前分解每件事。隨著時間推移，產品Backlog會出現，這個時候你可以根據你在迭代遞增式開發中所學的知識對其進行調整。
理解價值一致性——以交付更大的價值。在產品Backlog中聚焦價值的另一種方法是確定預期結果。很多時候PBIs（Product Backlog Items）會說明產品預期特徵和功能。那麼，我們是不是可以轉而更多地關注產品特徵或功能的預期結果？有許多方法可以讓PBIs聚焦在價值上，包括求使用者故事（如果運用得當的話），假設驅動開發和A / B測試等。還可以在產品Backlog中為每一個PBI捕獲價值作為後設資料。這個後設資料也許是以美元為單位的投資回報率（ROI），也許是步驟2中定義的價值定位的對映。
不斷拉遠推近……以確保可交付價值沒有偏離。在檢驗和調整時，需要“拉遠”以檢視不同之處，然後再“推近”檢視現在有什麼不同以及需要如何調整。這就是如何驗證學習的有效性，然後學以致用的方法。拉遠推近的頻率取決於產品開發的情況、市場中驗證假設的頻率以及業務變化大小。注意：PO（Product Owner）不會單獨確定什麼是有價值的，不會知道價值細分的最佳方式，也不會以書面形式完美地描述分解過程讓大家理解。這就是為什麼PO必須想方設法讓他人共同參與合作，一起改進產品Backlog。
第4步：驗證實際價值
現在一切準備就緒，可以開始評估實際價值。沒有得到市場驗證之前，價值只是一個假設。
產品釋出之後才能精準獲知產品的實際交付價值。通過獲取經驗資料，來確保知情決策所需的透明度。
實際價值與預期價值的比率是多少？如何有效地收集這些經驗資料？開發團隊通常可以提供一些將資料收集功能構建到產品中的方法。隨著產品規模和複雜性的增加，還需要增加流程和工具來收集這些經驗資料。
一旦有了資料，就可以分析走勢。記住，某一時間點的資料並不能說明多少，整體走勢更為重要。而且需要收集多種型別的資料，單一型別的資料並不能說明全域性的情況，因為影響產品使用的因素通常會有很多（有些因素超出控制範圍）。
在分析價值走勢的時候，請思考這些問題：已經發布了哪些產品更改，這些更改何時以及如何影響價值，哪些因素超出了可控範圍（例如，即使已經實現了預期會增加銷售額的新功能，但股市下跌也會影響使用者決策）
將實際價值的測量方式透明化。聽取利益相關者的看法以及他們如何看待走勢對產品改進方面的影響，而Sprint評審會議是聽取意見的良好時機。
總結
經驗主義引導你積極處理這些棘手的產品價值問題。對價值而言，它必須具有透明性，並且必須經常檢驗它的實際值，以便根據需要進行調整。就像開發出一款可執行的產品一樣，想清楚要做什麼同樣複雜且具有不可預測性。所以要學會邊做邊學，根據所學知識做出決策。
總之，Scrum的核心不是我們開發了多少東西，而是通過頻繁交付可執行產品為組織創造了多少價值。因此，Scrum也強調不斷學習和適應，以便從產品中獲取更多價值。
文章來源：Worktile敏捷部落格
歡迎訪問交流更多關於技術及協作的問題。
文章轉載請註明出處。