用最簡單的文字工具記錄需求
需求是信息的具體表現，我們知道，一個信息進行一次傳遞，需要具備以下5個條件：
1、信息本身
2、信息發出者
3、信息承載介質
4、信息接收者
5、信息所處的環境
這5個條件的綜合作用決定了這個信息最終的質量。
具體到需求這種和產品經理每日息息相關的信息上，我們都必須面對一個非常現實的問題，就是：如何來保證我們獲得的信息的衰減性是最小，并且我們又如何能把這種信息盡量少衰減的傳遞給下一個接收者。
既然本章的標題是“用最簡單的文字工具記錄需求”，并且在本系列的第三章中，我提供了一個自己整理的《需求反饋文檔》模板，屬于記錄市場需求的第一個工具，因此，在本章里，就以這個模板工具為例，詳細來說明一下如何把需求記錄好。 
第一部分：
這個部分比較簡單，主要是說明原始需求提出者的信息，具體包括三項：
1、需求來源：我這里是以我所在公司的情況寫的，大家可以根據自己情況來定，其實這部分就是說明需求的市場細分，這個需求是個人終端客戶提出的，還是企業級客戶提出的。
2、來源方名稱：說明需求提出者的名稱，如果是個人，就是姓名，如果是企業，就是企業名稱。
3、來源時間：說明需求提出者的反饋時間。
這項比較關鍵，因為咱們通常會發現，客戶向公司的是市場人員反饋了一個 需求后，市場人員往往不能及時反饋給我們，要么是想起來的時候才說，要么就是等著開會的時候才說，要么就是右耳朵進，左耳朵出，根本沒放在心上。
因此，我在公司里一直強調有需求一定要及時通過這個文檔反饋給產品部，當然，要讓相關部門的每個人都真正重視起來，一是需要時間，二是需要規范。
第二部分：
這個部分就是針對內部第三方的了，主要是說明需求獲取方的信息，在前面的文章說過了，許多行業的產品經理很少有直接面對客戶的機會，因此，我們往往還是通過第三方來得到市場需求，具體包括5項：
1、需求提交人：這里用需求提交人，而不是需求來源，就是為了區別客戶和第三方。
2、提交時間：說明這個需求是第三方什么時候加入到需求池中的。
3、所在部門：說明第三方所在的部門。
4、工作職位：說明第三方在該部門內的工作崗位。
5、PST位置：PST是什么呢？就是產品戰略表（Product Strategy Table），關于PST的解釋這里不多說，對于第三方來說，只要說明這個需求是針對那個產品線或者產品的即可。
第三部分：
這個部分就是針對需求本身的了，大家可以看出來，一共就三部分，非常簡單，為什么呢？就是因為大家要知道，對于客戶來說，他們在提出需求的時候，根本不可能按照我們期望的那樣分門別類的告訴你。
有一次，我們的一個產品經理和一個客戶進行需求溝通，他首先問客戶“你對我們產品的功能有什么想法呢？”
對于客戶來說，產品功能還是比較熟悉的，也多少說了一些，但是接下來問題就出現了，他又問客戶“你對產品的UI有什么想法呢？”。
客戶一下子就糊涂了，想了半天，問他“UI是什么？”，他可能也意識到這個詞太專業了，于是又給客戶解釋說“UI就是界面，也就是產品的外觀”，客戶這次似乎是多少明白了一些，但是明顯感覺在說的時候有些不夠放開了，為什么呢？大家可以分析一下，你把UI就解釋為界面或者產品外觀，實際上在限制客戶的思維，客戶在每說一個需求的時候，就會想“我說的這個是和界面或者外觀有關系的嗎？”。
這或許還好一些，UI還比較容易解釋，如果是UE呢，誰敢說能讓客戶很清楚的知道UE是什么意思呢？用戶體驗？估計用戶會更沒體驗了，呵呵！
其實就是這樣，對于客戶來說，越是專業的詞匯，越是把需求分的很細，在省了我們事的時候，反而會讓客戶很費事，我們要知道，獲取需求的時候，一定是要讓客戶在思維上不受限制，讓客戶想到什么說什么就可以了。
在第三部分，也就是需求說明中，只有三個部分，即使是這三個部分，也不是由客戶直接填寫的，而是由公司第三方在獲得了客戶需求后，稍微進行整理后填寫的，相對于第三方來說，他們要比客戶更了解一些產品方面的知識，即使是這樣，對于第三方而言，我們也不能太專業了。
1、產品需求：針對產品介質本身的需求內容，通常包括功能、性能、UI和UE上的，不要細分，用戶怎么說的，就怎么寫。
2、業務需求：針對產品營銷層面上的需求內容，通常包括用戶對產品的渠道、價格、銷售、服務等方面的需求，撰寫要求同上。
3、個性需求：有時候客戶會提出一些我們看起來異想天開或者是我們沒有預料到的需求，千萬記住了，對于這些需求，不要一笑而過，一定要讓第三方記錄下來，有時候這些需求往往能夠讓我們的產品另辟蹊徑，獲得意想不到的成功。
第四部分：
這部分就比較簡單了，就是要讓第三方留下自己的聯系方式，因為如果我們對某個需求有不解或者想進一步溝通的時候，可以通過第三方找到提出這個需求的客戶，便于我們進行直接溝通。
從這個模板中可以看出，文章開頭說到的信息傳遞的5個要素中，這個模板包括了4個，分別是：
1、信息本身：模板中的第三部分。
2、信息發出者：客戶是需求的反饋者，第三方是需求的提交者。
3、信息承載介質：需求反饋文檔。
4、信息接收者：第三方是客戶需求的接收者，我們是第三方需求提交的接收者。
只有一個元素沒有涉及到，就是信息所處的環境，這個環境雖然決定不了信息的傳遞過程，但是會非常影響信息傳遞的效果，也就是會影響到信息的衰減程度。
這個環境包含的內容比較多，我也沒有很好的整理過，就不往下結論了，但是有一點是我體會非常深的，就是信息傳遞的環境包含一個非常重要的因素，就是“信息傳遞的環節”。
我們都知道一個傳話的游戲，一個本來很有效的信息，經過的傳話環節越多，那么到最后，可能已經和原始的信息大相徑庭了，如果每個環節之間還是相互封閉的，問題會更多。
這就是需求分析原則五中強調的第四點：保持溝通的通暢，是了解需求的保障。
這個通常首先是每個環節之間一定要開放，二是每個環節的傳遞介質一定是統一的，三是要傳遞的信息一定是標準的。
許多企業花大力氣建設CIS（企業信息系統），其實根本目的就是為了讓部門間的信息流轉能夠暢通和高效，最終讓企業的運轉成本降低下來。
在做一些企業級產品的時候，我們通常會不斷地和客戶進行需求的交流和確認，如果采用快速原型法的開發模式，那么，我們還會在原型開發完成后，和用戶進行需求的最終確認，這個時候，就會有一個問題出現了，就是“這個原型一定是要讓客戶無需太多思考就可以理解的”。
有時候我們會認為原型又不是成型的產品，差不多就行了，其實不然，對于客戶來說，他們看到原型的時候就會認為最終的產品也是如此，因此，在原型上，不但不能掉以輕心，而且要更加重視才可以。
記得有一次，我們為一個客戶做了一個產品原型，因為是原型，開發部門也沒怎么當回事，許多細節地方都帶著開發部門的專業印記。
例如，這個產品中其中有一項很簡單的功能，就是在選項里可以設置是否“自動讀取放入光驅中的光盤”。
但是在原型中，開發沒當回事或者認為寫中文太費事，于是直接就寫上了“AUTO READ CDROM”，開發當然明白這是啥意思了，可是給客戶看的時候，客戶就是搞不清楚這CDR
OM是什么，解釋了半天后，客戶還是很認真地問“這個CDROM就是VCD吧，那CD能不能放呢？”。
后來我和開發說這個事情的時候，開發還滿不在乎的說“不就是一個原型嗎，沒必要那么費事吧！”
我經常會遇到這樣的事情，開發和產品經理說“產品原型差不多就行了吧，簡單表示一下就可以了吧”，那個產品經理認真地說“嗯，意思一下就可以了，沒必要花太多精力”。
還是前面提到的那句話：我們省事就意味著客戶要費事。
因此，需求分析原則五中第三點強調的就是：不要希望客戶能花更多的時間來了解需求轉換后的模型。
要做到這點，就只能在我們獲得用戶需求的那一刻起，就要想著“我費些事，客戶就可以省點事”。
總結一下需求分析第五個原則的中心思想：
1、需求分析第五個原則：用最簡單的文字工具記錄需求。
客戶并不麻煩，需求也不復雜，麻煩的是我們把一切做的太復雜了。
2、原則第一點：所有人都能懂的東西，最不容易出錯。
沒有人喜歡復雜的東西，需求也不例外。
3、原則第二點：不需要再學習的東西，最不容易出錯。
產品是需求的表現，沒有人喜歡復雜的產品，要做到這一點，就從需求開始吧。
4、原則第三點：不要希望客戶能花更多的時間來了解需求轉換后的原型。
我費些事，客戶就可以省些事，客戶省事了，我們最終也就省事了。
5、原則第四點：保持溝通的通暢，是了解需求的保障
要實現需求的清清楚楚，就要做到溝通的反反復復。
