起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識如何決定需求分析與產品開發？
需求分析與產品開發之間的根本區別是什么？一定的不確定性。不確定性程度決定了是否需要進行需求分析。
為什么預先知道不確定程度很重要？
假設三種情況（大部分產品開發過程中都會經歷這三種情況）。在每種情況下，我們產品團隊都需要進行數據跟蹤，以便更好地了解用戶的注冊情況并最終提高注冊轉化率。讓我們看看當我們改變不確定性的程度以及改變處理不確定性的方法時會發生什么。
方案1：確定環境中的執行
比如：創業公司新開發一款APP，通常會將注冊量作為指標，而作為產品負責人，我們就需要分析分析每一個用戶行為以提高注冊轉化率。一般有經驗的產品經理，都會對提高注冊轉化率有很豐富的經驗。能分析跟蹤數據并從中提出有價值的見解的看法。
根據以前的經驗，我們對所涉及的步驟具有相對的把握，并且對任務將花費多長時間有了很好的了解。如果CEO表示，他希望在兩周內完成注冊數據跟蹤。我們會制定了一個相當詳細的計劃，并非常準確地估計需要三個星期。我們可以證明為什么需要花費額外的一周，并且可以對CEO承諾在一定期限內完成任務。
由于整個項目的不確定性較低，因此我們產品團隊可以立即開始工作。去實施注冊數據跟蹤，并在截止日期之前完成注冊轉化的渠道分析。
我們實現了目標并為公司創造了價值。我們與管理團隊建立了信任，這不僅僅是因為我們達到了目標而已，還是因為我們在達到目標的過程中，展現了對時間的把握。我們創建了一個計劃，該計劃可以用作管理團隊的可靠錨點，以跟蹤團隊朝著正確方向的進度。
總的來說，預測未來是困難的-但上述情況并非如此。
為什么？
因為不確定性較低，我們知道所有不確定因素以及如何確定成功，我們可以對實現目標需要交付什么以及何時可以實現做出正確的預測。結果，我們團隊無需花費大量時間去探討該如何進行工作。
當面對不確定性的程度很低時，我們很容易朝著自己的目標邁進。
方案2：不確定環境中的執行
當我們很少或根本沒有完成任務的經驗，會發生什么？在這種情況下，我們無法確定地說出涉及哪些步驟以及將花費多長時間。
當CEO要求您在兩周內完成注冊數據跟蹤時，我們會感到有壓力，因為要遵守這一期限，我們首先要寫連自己都不確定的需求，然后將其交給開發工程師，工程師很有可能也難以理解這個需求。
然后隨著截止日期的臨近，我們意識到自己不會成功，然后就拼命的去熬夜試圖挽救這個項目，我們會對現在不可能完成的任務感到沮喪和憤怒，士氣低落。
最后，不僅注冊數據跟蹤分析的不完整，而且CEO也會不高興，我們也失去了團隊的信任。
我們可能面臨高度不確定性，這可能是由于缺乏經驗或技術知識所致。但是致命的缺陷不是我們缺乏經驗，而是缺乏需求分析，沒有評估需求的時間周期。相反，我們應該提前進行需求分析，至少要檢查技術可行性，而不是直接從執行開始。
如果產品目標更加復雜（例如要我們改進百度的搜索結果，使用戶獲得更相關和個性化的結果）會怎樣？
在這種情況下，也許沒有人真正了解用戶想搜索什么?；蛘邲]有人知道如何構建一個可以為數百萬用戶進行個性化的搜索引擎（技術可行性的高度不確定性）。這項工作可能要花費數月甚至數年，而且如果執行不當，沒有產生實際效益，很容易打擊人的信心。
方案3：在不確定環境中先進行需求分析
讓我們探討在執行階段之前，面對不確定性進行需求分析時可能發生的情況。
我們回到團隊，并對我們期望的數據進行用戶分析的討論。團隊中的每個人都有機會發表他們確定的事情（從過往經驗中）和不確定的事情（沒接觸過）。
然后，我們開始寫下認為對實現目標至關重要的所有假設。根據重要性和不確定性程度評估假設。
我們會很快發現產品可行性是最大的未知因素，對成功至關重要。但是我們對如何為移動平臺實施注冊數據事件跟蹤了解得很少。因此，我們決定進行產品調整，這大約需要一周的時間。
四天后，我們團隊已經對產品可行性有了很好的了解，因此我們估計可以在三到四個星期內達到目標。
我們將其傳達給CEO，團隊便能夠按照承諾實施注冊數據跟蹤。
這一共花了四到五個星期，但是每個人（無論是領導層還是團隊）都對我們的處理方式感到非常滿意。
這對我們的日常生活意味著什么？
注冊數據跟蹤是一個簡單的示例，但是我們可以將相同的思維模型應用于所有目標。如果我們面臨太多不確定性，則不應該直接開始去構建產品解決方案。
相反，應退后一步來了解不確定性的根源，并做出相應行動來證明是為了實現我們的目標。
在產品管理中，我們將這些行動總結為需求分析。在最佳情況下，我們可以將不確定性降低到可以開始構建解決方案的水平，來使我們更接近實現目標?；蛘?，我們找不到任何理由來證明可以實現我們的目標的時候，可以在沒有大量投資的情況下盡早停止。
這兩種情況都是成功的，可以節省團隊寶貴的時間并減少挫敗感。
總而言之，不確定性程度決定了我們是否可以直接進行產品開發，還是需要先退后一步進行需求分析來證明我們可以進行產品開發。能夠識別處于低不確定性或高不確定性的環境，對于實現目標的成功和效率有很大的不同。
評估不確定性并采取正確的措施
評估不確定性程度的一些實用策略和減輕風險的策略。
不確定性規則
不確定性規則的目的：幫助我們評估最大不確定性的地方。
馬蒂·卡根（Marty Cagan）在他的《啟示錄：打造用戶喜愛的產品》一書中談到了四種不同類型的風險：
- 價值風險–人們會購買/使用它嗎？
- 可用性風險–人們可以弄清楚如何使用它嗎？
- 可行性風險–在我們現有的技術條件下，能否成功開發出產品？
- 商業可行性風險–解決方案能否創造商業價值？
在確定要開發產品之前，問問自己這四個問題，是否已經足夠清晰。
如果我不知道所提出的解決方案對用戶是否有價值，那么我需要進行需求分析以更好地了解用戶所面臨的問題以及他們真正的需求所在。
如果從用戶的角度來看我不知道所提議的解決方案是否可用，那么這也會造成不確定性，在開始構建解決方案之前，應該通過可用性測試來解決這些不確定性。
實際上，對這四種風險的思考會引發了很多更為詳細的問題，這些問題有助于量化我們在開發新的產品時面臨的不確定性程度。這些詳細的問題構成下面的問題。
請記住，這些問題會根據我們當前的目標去調整程度，而不是一成不變。
嘗試回答每個問題，并以1到10的等級對我們的確定性進行評分，其中1表示“我對這個問題有100％的把握”，10表示“我只是在猜測”?？赡苡肋h不會百分百確定任何事情，所以我們將收集大量的定性或定量數據來支持我們的主張。我建議我們不僅要給問題打分，還要寫下詳細的描述-描述用戶或用戶群，即我們要解決的確切問題。
如何處理計分的分數？
如果我們和我們的團隊將每個答案標記為3或以下，則表明我們對自己的方向具有高度的確定性，可以開始進行產品開發。開發過程中我們能仍然會發現新的問題，但是我們需要一邊調整一邊去適應它-這就是我們使用諸如Scrum的敏捷方法的原因。
標記為4或以上的答案表示我們應該進行需求分析以減少不確定性的地方。在此階段，最好找出正確的做法，而不是致力于結果。
一旦確定了需要進一步理解的地方，就需要引入另一個變量條件：影響程度。
我們可以把評分為4或更高的每個問題都可以視為假設（因為不確定）。
如果我們僅有一個假設，則可以跳過引入這個變量，直接進行實驗。但是，如果我們確定自己面臨的不只是一個假設，則必須優先考慮最關鍵的目標假設。通常，產品創建過程中假設的優先級為：用戶->解決方案->資金->規模。
假設我們已經確定了在做正確的事情方面不確定性高的兩個方面–最重要的用戶利益和所建議解決方案的可用性。
談到對當前目標的影響時，我們覺得至少在產品初期過程的這個階段，確保用戶利益比可用性更重要。因此我們覺得用戶利益的影響很重要，而可用性相比而言就沒那么重要。所以讓我們填一下影響程度的分數：
接下來，將我們的假設繪制在下面XY軸上，其中x軸描述對目標的影響，y軸描述我們面臨的不確定性量。我們的示例如下所示：
在著重于可用性假設之前，我們應該著重于證明有關用戶利益的假設。通常，我們應該從不確定性和影響都很大的地方開始。
有了一個優先級的假設列表，可以將其用作設計和進行實驗的起點。
設計和進行實驗
下一步是將我們的假設按照優先級轉換為實驗。根據假設的性質和業務環境，實驗可能會大不相同。我們要經歷很多最佳實踐，從用戶研究，到灰度測試，到可用性測試等等，都需要一步步的來。
回到我們的案例，那么現在的目標是設計一個經濟高效的實驗來降低實驗風險。該實驗應通過收集數據點來增加我們的信心，并使我們清楚地制定出最重要的用戶利益。然后，可以關注可用性問題以及如何創建一個新的具有成本效益的實驗，以降低圍繞該假設的實驗風險。
同時要為自己設定個具體的時間周期，例如：兩周后，希望收集足夠的證據以繼續進行此工作。這在可以進行大量生成實驗的早期階段特別有用。設定自己的時間周期，去評估為一個特定的想法需要投入多少時間和精力。
我們可以并且應該在必要時重復執行所有三個步驟，尤其是當我們擁有新問題時。但是，一旦我們對所有重要因素都建立了足夠的清晰度，就應該開始提供產品解決方案。
結論
創新意味著不確定性，但是適當地管理它會帶來很大的不同。能夠識別我們要處理問題的不確定性程度，可以使我們更加成功和高效地實現目標。如果現在將整個案例簡化為一種產品原理，那么就是這樣：如果我們面臨的不確定性太大，請從需求分析而不是產品開發開始。
我希望這種結構化的方法對我們有所幫助，并在需要決定是開始構建產品，還是退后一步以找出適合我們的用戶和企業的建議時為我們提供一些幫助。
#專欄作家#
lennon，微信公眾號：張論（ID：woshipm123），人人都是產品經理專欄作家。關注新零售電商、供應鏈金融的產品經理，擅長產品設計與需求分析。
本文原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自 Unsplash ，基于 CC0 協議。
- 目前還沒評論，等你發揮！
