如何減少需求的含混性（中）

07-09

如何減少需求的含混性（中）

來自專欄鋒言冷語

1 如何切入

當我們說起需求時，其來源是多樣的，但基本可以理解為這樣一個初始過程：某些人提出一個想法認為某些特性應該設計到產品中。比如，你是微信公眾平台的產品負責人，有一天你有了一個想法——文本支持Markdown格式，於是這個想法就轉成了最初始的需求。

然而，每個人都有其不同的思考方式，同一個觀點不同的人存在許多不同的解釋和表述方式，並由此產生許多不同的起點，如果參與者從一開始就沒有一致的想法，那麼可以肯定的是在項目還沒有成功的時候就註定要失敗了。仍以文本支持Markdown為例，有的同事支持類似於簡書、鎚子便簽那樣嵌入的，另外一位同事通過調研顯示通過第三方插件支持即可，這就產生了需求的差異。

2 通用做法

我們怎樣才能把大量不同的潛在切入點簡化並探索需求？一種可能的解決方法是先認為每個設計項目都可能解決一些問題，然後再簡化每個起點，直到問題陳述變得非常普通。

問題的最佳定義是：感受到的事情和期望的事情之間的差別——《你的燈亮著嗎？》

這個定義可以用來作為一個模板來衡量啟動開發項目的每一個想法。如果某個想法不符合這一定義，那麼就和想法的提出者一起來使問題通用化，直到符合為止。

3 具體化

通常，我們有很多不同的切入點。比如，來自解決方案的想法，來自技術的想法，來自一個比喻，來自某個標準，來自某個實體模型，甚至一個名稱。

最常見的切入點有可能是對某個解決方案的考慮，二爺鑒書（微信號：findbook）的作者邱岳曾在他的專欄中提到：

在開始把時間花在解決方案上容易陷入「X-Y Problem」的錯誤中，也就是，我們希望解決 X 問題，然後想到了 Y 方案，隨後把所有的精力放在 Y 這個解決方案上，而忽略了對要解決問題本身的理解。
正確的做法應該是：把類似的所謂需求當做一個線索，抓住這個線索不斷地向上追問背後的需求動機和需要被解決的問題。

回到第2點「通用做法」中的描述，解決方案往往陳述不清該方案具體要解決的是什麼問題，即什麼是感受到的（誰感受到的）以及什麼是期望的。

書中提到一個例子，某大學一名院長說：「我們需要吸引更多的學生。」有些人理解「更多學生」意味著招收更多的優等生，有的人理解「更多學生」意味著可以在某幾個部門資助更多的助教，更有甚者認為「更多學生」表達的是院長希望塞滿多餘的宿舍空間。

實際上，學校希望增大撥款，必須給州議會留下深刻印象，讓他們認為學校工作的質量在提高，因此需要提高申請者的拒絕比例。明白了這個目標，老師們找到了幾種不同的解決方法，但是沒有一種會增加入學學生的數量。

所以，正如書中所說，在需求切入階段，我們需要更多的前期思考。

未雨綢繆是避免陷入重大錯誤假設的最佳辦法，所以應該學著養成仔細分析切入點的習慣。
怎麼做？最基本的想法就是減緩切入階段的進展，去調查需求，仔細思考需求，就像禪宗所說的要儘可能地保持一個「初學者的念頭」。對於初學者而言，所有的事物都是平等的、新奇的、不可能的。

4 利益相關者

二爺鑒書（微信號：findbook）曾在他的另外一篇專欄中提到：

產品分析時的套路就是反覆思考：「用什麼方法，解決誰的什麼問題。」

其中，「誰的？」指的就是「利益相關者」，如何辨別、定位和找到所有相關人員中的參與者，這是了解需求背後主體的過程。

作者在書中給我們列出了一個步驟。

集體討論一個潛在使用者列表，列出所有可能的使用者，不僅僅是客戶，也包括上下游的「利益相關者」。
通過把他們分類成友好的、不友好的以及可忽略的三類來簡化列表，並針對定義的用戶群設計詳細而精確的使用者活動（我理解為使用者的場景）。
使用參與者的三維坐標，為每個你不想忽略的用戶群製作一個對策。誰：通過代言人還是使用者的實際抽樣，或者徹底參與？何時：其參與是連續的還是僅僅在一些離散的時間段；怎麼：其信息是基於經驗還是實驗？
執行你的參與計劃，用你的想像力和機智去獲得你所需要的全部的參與。

5 啟發

需求中的含混性無處不在，如果我們想要降低問題描述的含混性，就需要一些工具來使我們的腦子轉得慢一些，以防止我們玩命似的試圖太早來解決問題。

含混性投票：用性能、時間或成本作為度量，讓不同的人對這些度量進行評估，並比較和討論出結果。
記憶啟發：對於那些不能夠很好地回憶起來的地方很可能是含義不清楚的。（可以在團隊會議中，請不同的人陳述，然後看看是否存在理解不一樣的地方）
「瑪麗從前有一隻小羔羊」，把問題描述重複讀，每次將重音放在不同的地方，看是否存在不同的理解和解釋。
確定在問題描述中起重要作用的詞，然後列出其所有可能的解釋。

6 下一篇

《探索需求—設計前的質量》計劃寫三篇，還有一個下篇，會主要寫一寫如何明確功能點和期望等內容。