為什麼我們從來沒時間把事情做好，卻總有時間返工呢？
有資料顯示：產品中發現的缺陷有40%~50%是在需求階段埋下的“禍根”，需求階段的問題不但造成了大量的無效工作，也間接影響了團隊的士氣，降低了產品質量和業務價值。
為什麼會出現這種情況呢？
我們可以試著從需求的定義來找一找原因。
關於需求的定義，有兩個比較有代表性：
- 其一是《探索需求-設計前的質量》這本書中，作者把需求定義為「一個試圖發現人們對新產品的期望的過程。」
- 其二是《需求工程：良好實踐指南》這本書中，作者把需求定義為「需求是對我們應當執行的任務的規範說明。它描述系統的行為特性或屬性，可以是一種對系統開發進程的約束。」
無論是哪個定義，需求涵蓋了來自客戶視角的外部系統行為以及來自開發人員視角的一些內部特徵。正是因為接口和過程的多樣性，給需求管理帶來了不確定性和含混性，而產品開發是一門精確的學科，如果我們自己都不知道想要什麼。那麼開發過程越精確，其結果偏離越大。
本文結合自己踩過的坑，彙總一下探索需求的過程，以及如何儘量減少需求分析過程中含糊不清的地帶，達到「明白自己在做什麼」的目標。
有四個部分可以概括探索需求的內容，本文主要講人性因素、含混性來源和消除含混性的方法。
一、人性因素
在產品和系統開發方面有經驗的人可能有這種體驗，產品成功的關鍵越來越依賴於人的因素，所以他們會花更多的時間來與人打交道，而花較少的時間在技術任務上。
人與人不同
需求的產生，我們可以理解為：某些人會提出一些想法，並覺得某些特性應該設計到產品中並通過技術手段去實現。在這個過程中，如果是我們自己的一個想法或許不會產生什麼問題，但因為「人」來自不同的群體，針對同樣的事情看法可能截然不同，認識到這個差異性是我們探索需求的起點。
比如，有一名大學院長說：“我們需要吸引更多的學生”，如果僅僅理解字面意思，“更多學生”可能是指學生數量，也可能意味著招收更多的優等生等。實際上院長需求背後的動機是，提高申請者的拒絕比例來增加撥款。
我之前遇到過一種情況，領導和客戶代表溝通後說，希望通過一個智能分析算法實現道路車流量檢測，統計出一定時間段內道路通行車輛計數功能。
然後工程師就把分析算法當做核心工作開始了開發，等做得差不多了的時候去和客戶再次溝通，才發現：客戶並不關心算法，他關注的是統計出的數據能給他帶來什麼分析和推論，按照這個思路往下走，實際上數據處理、分析和深度挖掘，才是這項工作的真正需求。
人的知識不完善
在需求分析及探索過程中，負責需求的人員見識和技能的不同，結果也會存在較大的差異。在需求調研的開始階段，用戶訪談是比較常見的方式之一，但一個錯誤的假設或者錯誤的問題順序，會導致你給客戶的每個解決方案都是正確的，但解決的都是錯誤的問題。
而在產品開發過程中，人的知識不完善體現得更加明顯。沒有人是全能的，結構工程師很大概率不懂電氣，那在機電結合的環節，就存在一個隱藏的含混性。
之前的項目中，結構按照自己的設想設計了一款外觀得到所有人稱讚的方案，但實際安裝環節，發現結構和電氣設備之間的配合問題比較多。還有硬件和嵌入式，假如嵌入式想實現一個創新算法，其對硬件的運算速率、有效存儲往往有要求，但如果在項目開始前不把這些含混的地方討論清楚，最終的結果往往是更改設計方案或者被迫放棄新的功能。
群體無意識
個人一旦進入群體中，他的個性便淹沒了，群體的思想佔據統治地位；而群體的行為表現為無異議、情緒化和低智商。
——勒龐《烏合之眾》
我們在需求分析過程中，經常會遇到這樣的情況：拿著一份需求分析報告，在和同事、領導溝通的過程中，在尖銳的問題、不同的觀點交相碰撞中敗下陣來。
- 一方面可能是我們對需求的研究不夠深入，沒有發現需求的真正意圖；
- 另外一方面，人是群體性動物，當面臨同事的質疑、領導的強勢時，我們很容易就妥協了，從而進入「群體無意識」狀態。
比如：一款產品，按照設計路線圖，可能需要三個版本才能實現的一個功能，領導可能要求在第一版就實現。這中間就缺少了過渡和緩衝，就如嬰兒出生與成長一樣，很多事情需要時間和成長空間。
有一個故事是這麼說的：
“給我們用最低的成本解決。”
“在最短的時間內搞定。”
“我們必須儘可能以最好的方法完成。”
放在健康人身上，優化神經收到這些請求後，會給嘴發送一個脈衝，讓它回答：“那你願意犧牲什麼呢？”
可在群體中，這部分神經通路被切斷了，嘴裡就會吐出一些扭曲的話語，比如：“好的，老闆。我馬上去辦，老闆。”
探索需求的方法論和原則
和其他很多事情一樣，在探索需求的過程中，人幾乎是一切問題的根源。站在個人的角度來說，我是我大多數問題的根源。
探索需求需要遵循的原則離不開人性因素，如果一開始就想到了人與人之間存在差異，個人力量有限，我是引起大多數問題的原因，在群體中容易陷入對權威的無意識跟隨。那麼在需求探索的過程中，我們就可以有針對性地去避免這些問題。
有一個方法是將自己保持為“初學者狀態”，對初學者而言，所有的事物都是平等的、新奇的、不可能的。
二、含混性來源
在我們日常工作中，需求的獲取方式主要來自訪談、工作坊、焦點小組、觀察、問卷調查、系統接口分析、用戶界面分析、文檔分析等。
結合第一部分介紹，需求含混性的來源非常多，比較常見的有以下幾種：
- 觀察和回憶錯誤（需求調研前後，對用戶行為的觀察和回憶錯誤）；
- 解釋錯誤（看到一種現象，用自己的觀點而非客觀事實來解釋）；
- 錯誤來源的混合（比如：設計一款產品，不僅僅需要考慮直接用戶，還需要考慮投資人的期望，需要關注產品上下游維護和現場支持人員的功能及非功能需求。如果我們把需求方弄混淆了，或者把用戶的需求嫁接到投資人身上，其結果往往南轅北轍。）；
- 人們交互的作用（我們在分析問題時，鼓勵相互獨立，但在聽到一個不同的見解或新的問題解釋，我們改變了初衷。但這種初衷的改變並不是提高了觀察力，而僅僅是被他人影響。）；
- 問題陳述的含混性，有一類案例比較有代表性：瑪麗曾經有一隻小羊羔，這是今年我看過的最好的電影，我真的沒有騙你。試試把重音放在不同的詞語上，帶來的結果差異。
在參與需求工作時，我們可以採用直接使用回憶啟發的方法來驗證含混性。只要簡單地拿走書面的需求文檔，再請每個參與者根據記憶寫出其中所指的內容就可以了。那些有回憶差異的地方就是文檔中有含混性錯誤傾向的部分。
這一步非常重要，因為幾乎很少有人會在工作中實際參考那些需求文檔，他們更喜歡根據他們記憶中的文檔內容來辦事。因此，易於正確回憶起來的文檔很少會帶來設計錯誤。
三、消除需求含混性的方法
需求帶來的模糊地帶如此之多，有什麼好方法能夠儘量減少錯誤的發生呢？
我們可以從兩個方面來提升：
- 其一是需求的目標，需求記錄要做到：完整、正確、可行、必要、無二義、可驗證、定出優先級；需求規格說明書要做到：完整、一致、可修改、可跟蹤。
- 其二從需求的內容著手，將功能、屬性、約束、偏好、期望等循序漸進地明確下來，得到一個比較精確的定義“產品是做什麼用的”。正如馮·諾依曼說的：“我們只有知道自己在討論什麼，對其強求精確才是有意義的。”
下面選幾個不同階段的方法討論一下這個過程。
找到相關人員
在開發活動中最為常見的單個錯誤，可能就是在過程中遺漏了某個必需的人物。所以第一個需要問的就是“誰是客戶？”
客戶決定產品的外部屬性，比如：產品值多少錢。
其次是找到產品的使用者，使用者是真正使用產品的人，產品的成敗由他們決定，我們身邊有非常多的例子。有分析指出：很多公司購買了各種軟件工具，但70%被束之高閣，除非產品找到了真正的使用者，否則一切都是鏡花水月。
一種方法是我們先列出所有可能的使用者，利用我們的“共情能力”，對用戶立場和偏好進行深刻理解，理解他們的關注點，然後根據設計方案將使用者群體分為「對他們非常友好」、「忽略他們」、「對他們非常不友好」幾類。這些角色的定位除了對單一功能點的分析有價值外，也會決定需求的優先級。
需求評審
我一直認為需求評審就像少林弟子闖十八銅人陣，你只有過得了這一關，才有可能出師或者去研習更高深的武學。
需求評審串起了前期的需求收集和分析，不同利益相關方的博弈，以及後續項目落地實施的計劃管理等各個方面，評審會議本身只是露出水面的一角，想讓評審更有效，事前和事後都要做不少工作。
需求評審如果完成得好，則後續項目可能會比較順利，如果完成得不好則給後續環節帶來了更多的混亂。
一個比較好的做法是：產品經理全權負責，充分做好前期準備，把文檔、原型圖、解決方案、會議等組織好。
- 一方面我們通過需求評審會去驗證自己對於用戶深層需求的挖掘是不是正確；
- 另外一方面是向實現產品的團隊，包括開發、測試等講清楚需求的背景和來龍去脈，以及產品為什麼這樣做。同時向他們交代產品的解決方案，讓設計師、工程師弄清楚自己將要製造一個什麼東西，長成什麼樣子，怎樣運轉，有哪些特性等。
技術複審
有兩個基本途徑使得需求信息會發生錯誤：不充分或者不正確。
技術複審可以有效地解決需求信息不正確這個錯誤，技術複審可以分為非正式和正式複審，非正式複審可以將問題反饋提供給需求製作者以幫助改進產品，正式複審則將最終結論提供給管理者。
舉一個例子：一款產品想實現車輛在1米範圍內的精確測量，我們以普通的72km/h來計算，系統需要的分析時間為50毫秒。而如果想實現5釐米範圍內的精確測量，仍以72km/h來計算，系統的分析時間則需要做到500微妙。
這種量級的差異，會導致設計方案完全不一樣。這就是技術複審的意義所在。
需求驅動測試
在需求的定義階段，我們還可以使用測試中常見的概念：黑箱測試。
因為在需求階段，設計解決方案是一個真正的黑箱，我們在此階段，可以先不用過分關注如何實現，先將關注點放在輸入和輸出上，嘗試不同的輸入會導致什麼輸出。也就是“如果X發生了，產品應該做Y事。”
之所以提這個，是因為在實際工作過程中，我們經常會將「解決方案」定義為「問題」。這種錯誤也被稱作 X-Y Problem，也就是，我們希望解決 X 問題，然後想到了 Y 方案，隨後把所有的精力放在 Y這個解決方案上，而忽略了對要解決問題本身的理解。
這是我們討論的可能已經不是“需求”，而是偏離了需求的“解決方案”。
總結
需求要求我們在開發前期付出更多的時間和精力，但是一旦時間拉得過長，我們就容易陷入自以為是的境地，很多需求分析和過程就變成了走過場。
但我們也知道一點：造成混亂的原因就是丟掉謹慎。
需求過程開始於含混性，但總是要有結束的時候。有時候，需求過程就像是王爾德某次說的：
“我整個上午都在推敲我的一首詩，最後去掉了一個逗號。而在下午，我又把逗號放了回去。”
希望你在探索需求的過程中，也能體會到王爾德說這句話時的煎熬和美好。
題圖來自 Pexels，基於 CC0 協議
閱讀更多 人人都是產品經理 的文章
