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