前段時間總結出了個「y理論」，最近又整理出乙個「
z方法」，個人感覺便於實操，大家看著玩兒。
需求採集，或者說使用者研究的方法很多，比較經典的分類就是按「定性 vs 定量；說 vs做」二維。先回顧一下我在《人人都是產品經理》裡說的：
橫向，定性與定量。
定性研究可以找出原因，偏向於了解；而定量研究可以發現現象，偏向於證實。兩者都很重要，缺一不可，只定量會「以標代本」，看到問題但不知道原因，只定性會「以偏概全」，很可能被部分樣本的特殊情況帶入歧途。人們認知新事物的過程通常都是從定性到定量再定性再定量，並且螺旋上公升，而了解和證實也是在不斷迭代進化的。
縱向，使用者的說和做。
怎麼說表現了目標和觀點，怎麼做反映了行為，使用者怎麼說和怎麼做經常是不一致的。兩方面都很重要，我曾經認為「耳聽為虛，眼見為實」，所以看到使用者怎麼做會比聽他們說更真實有用，但後來體會到，只了解做是沒辦法知道背後原因的，而不知道問題的原因也就意味著沒法從根本上解決問題。所以我們既要看使用者怎麼做，也要聽使用者怎麼說，雖然他說的不一定是真話。
而四象限中，最常見的方法又如下——使用者訪談、調查問卷、可用性測試、資料分析。這塊內容，其實早就提過，只不過，最近把這些方法攢出了乙個「z」字，方便同學們記憶，可說是需求採集最簡單的組合拳。
說和做、定性與定量，合理的搭配組合使用，才能發揮最大的作用，而對於乙個產品來說，正好在不同的時期可以用不同的方法，下面舉乙個典型的例子，正好是用到了上述4種辦法，按照時間順序，「自上而下，從左到右」在圖里畫出乙個大寫的「z」：
第一輪，產品規劃階段。聽使用者定性地說，確定產品方向，做什麼？隨機抽樣了40個使用者做訪談，據此寫出需求列表。
第二輪，某個專案的早期。聽使用者定量地說，確定需求優先順序，先做什麼？投放了20萬份調查問卷，確定了需求優先順序的排序。
第三輪，專案實施過程中。看使用者定性地做，要先做的那幾個需求，應該怎麼做？一邊設計，一邊陸續的找了10個使用者來驗證，做可用性測試。
第四輪，上線後的優化階段。看使用者定量地做，根據產品的使用者使用情況做資料分析，不斷地改進產品。
具體怎麼做，去看其他材料把。當然，這是乙個比較重要的產品，所以在使用者研究上投入了較多的時間與人力，更多的時候，我們會視情況採取簡化的方案。
需求採集 使用者訪談的注意點
1 避免一組固定的問題 固定的問題會讓被訪者產生被審問的感覺，我們應該準備好問題清單，但清單只起乙個引導作用，並不用照著讀。2 首先關注目標，任務其次 比使用者行為更重要的是行為背後的原因，多問問使用者為什麼這麼做。3 避免讓使用者成為設計師 聽使用者說，但不要照著做，使用者的解決方案通常短淺，片面...
防採集的有效方法
解決方法 注意zzz 使用無效的html標籤，這樣瀏覽器就不顯示，但採集時因為無法設定開始 或結束 無法儲存規則。採集原理 很多採集程式都是逐步捉取而拿到想要的內容的，通常情況下是擷取頭部和尾部來獲取中間一部分，當你的文章列表或者內容沒有規則，採集程式找不到您的通用頭部和尾部的時候，自然就採集不了，...
資料採集的技術方法
1.系統日誌採集方法 很多網際網路企業都有自己的海量資料採集工具，多用於系統日誌採集，如hadoop的chukwa cloudera的flume facebook的scribe等。這些系統採用分布式架構，能滿足每秒數百mb的日誌資料採集和傳輸需求，例如，scribe是facebook開源的日誌收集系...