PMBear本文是系列文章的第一篇，筆者從建立一個文檔管理系統的第一步講起：如何追根溯源，抓住用戶的原生需求。
從任務說起
近期從老闆處接到一項非產品工作，每天收集匯總公司多個運營小組編寫的針對病種的專業性文檔（涉及到公司核心業務，此處以文章指代）。
並至少滿足老闆如下需要：
- 為每個文檔分配唯一編碼；
- 統一出口，使用者只能在我這獲取文檔；
- 統計彙報每日完成的文檔數量；
- 製作文檔清單，並定期更新。
收集統計這麼簡單的事，擼起袖子就干吧，結果往往一頓操作猛如虎，回頭一看不靠譜。
職場老炮說：會不會工作取決於能不能猜中老闆心思。產品經理會翻譯成：產品好不好取決於能不能抓住用戶的原生需求。
原生需求
Want 和 Need 是老生常談，今天只想補充一個Original Need。道生一，一生二，二生三，三生萬物。大大小小的真實需求取之不盡，挖之不竭（其實能挖到真實需求已並非易事）。而一定存在一個原生需求來不斷產生這些真實需求，有果必有因，原生需求就像一條主幹，圍繞着它生長出來的才是各種真實需求。找到了主幹，想跑偏都很難。
要透過現象看本質，先抽象再具體，先歸納再演繹，才能萬變不離其宗。本質的、抽象的、歸納的宗就是原生需求。——馬大爺
抽象也好，歸納也罷。還是要基於大量的信息，信息從何而來是要解決的第一個問題。直接從老闆或相關第三方獲取信息是最直接的辦法。但即便如此，這些也只是信息源，少不了接下來自己的分析和加工。
今天，就拿上述老闆提過的具體要求為例，聊一聊：怎麼衍生出更多的信息？
先把書讀厚
先把書讀厚，再把書讀薄 ——華羅庚
分析出大量的信息就是把書讀厚，而歸納總結出原生需求就是把書讀薄。“十萬個為什麼”是最容易把書讀厚的方法之一。
我們先來簡單分析一下：
為什麼要為文章分配唯一編碼？
——就像每個人都有身份證，並且號碼肯定是唯一的。當然是為了便於管理了，而且這串神秘的數字隱藏着不少關鍵信息呢，這個不用解釋了吧！（尤其是110開頭的土著們）
為什麼要統一出口？
——統一出口的前提是集中管理，目的是為了讓使用者明確該找誰獲取，同時又能起到傳播控制的作用，防止傳播泛濫；
為什麼統計彙報每日完成的文檔數量？
——工作進度既體現了當前的狀態和瓶頸，也為未來規劃和發展提供了依據，因此需要時刻跟進。
文檔清單幹什麼用？
——文檔的價值不是存起來，而是用起來，建立清單就是為了更好的使用。書要有目錄才會結構清晰，便於索引。
再把書讀薄
通過上面的簡單分析，總結成一句話就是：文檔很重要，要集中管理、實時監控、便於使用。這就是粗略的原生需求了！
很多朋友會說，這麼簡單的事，有什麼好分析的，干就完了。而且分析完了也是一句正確的廢話，你可能不知道是：總結這句廢話的兩個極其重要的好處：
- 在分析具體要求時，會發現多個問題的答案存有潛在的矛盾衝突。不要慌，這是好事，這會增強你對具體問題的準確理解。比如：上面有兩個問題看起來是稍稍有一些衝突的，統一出口勢必會降低使用效率，而文件清單是為了提高使用效率。重新思考一下，統一出口本質上保護文檔內容信息盡量少外泄，目錄清單在沒有外泄內容的前提下輔助了傳播，兩者並無矛盾。
- 找到原生需求以後，就可以輕易的辨別之後的每一個需求是不是偽需求，優先級有多高，是否具有擴展性，就像各種立法的根基一定是不能違背憲法的準繩。
迭代原生需求
哈哈，終於定義出了原生需求，大功告成！
不要高興的太早，原生需求是需要迭代的，上面的問題只是個例子。你還可以通過繼續追問，獲取更多新的信息，來不斷的完善對原生需求的定義，比如：
- 為什麼要編寫文檔？
- 文檔包含什麼內容？
- 文檔有什麼用途？
- 文檔和業務怎麼結合？
- ……
原生需求的定義不是一成不變的，隨着業務的開展，隨時需要進行微調甚至顛覆。但至少在一個中短期的時間窗口，還是能穩定的指引方向的。
最後
無招勝有招，才是真正的高手。–《笑傲江湖》
不要盲目的扎入具體需求的實現，拿出一些時間總結出原生需求，當手握根基時你會發現：
- 接到需求后瞬間就能判斷是否合理，優先級高低；
- 不再被動接受需求，而去主動發現需求；
- 功能可用性增強，返工和廢棄的概率大大降低；
- 易於擴展，新功能與舊功能兼容性更高；
- ……
不知不覺寫了這麼多，只寫了個開頭。不過也好，即保證了閱讀體驗，又能體現文章重點。
。
