各位老闆們、同事們，產品技術中心產品部的產品專欄第一期終於推出了！
這個專欄將定期發佈產品部關於產品設計方面的思考。主要有以下四個方面：1）產品規劃 2）用戶需求探討 3）產品設計過程思考 4）競品分析。
開設這個專欄的目的很簡單，主要有兩個，一是讓公司各位同事能隨時瞭解並參與到我們產品設計的環節中，同時能通過這樣的平臺給我們多提意（tu）見（cao）。二是通過這樣的專欄也能倒逼我們更多地思考，提高自身的產品設計能力，從而設計出更好的產品服務大家。。
這是我們產品部的第一篇關於產品設計思路的文章，想了很久要怎麼寫，從什麼角度開始。最後我覺得任何產品的起源都來自需求，這期就主要聊聊我們是如何收集、分析和管理需求的辦法。如考慮不周的也請各位多多指正。
首先是我們如何進行需求收集的。主要有三個方面：
1.老闆需求
畢竟老闆對行業和業務比我們熟悉太多，前期需要吳校和各位大佬多給我們提意見和想法，幫助我們產品方向不會跑偏。
2.用戶反饋
目前我們的用戶反饋包括兩個環節，一是開發前我們將產品需求轉化爲原型DEMO，同時我們會選取對此產品最熟悉的用戶並把我們的原型一一和他們進行確認，如果還有問題則繼續調整原型，如無問題則可進入開發階段。如極運營在最初的產品設計時我們與財務同事確定需求不下10次，同時也到各校區找到相應負責人進行了多輪的溝通和確認工作，收集了大量寶貴的意見。（這裏要特別感謝申琴，在前期我們產品對極運營的需求一無所知時，是她在反覆耐心地給我們講解需求）
二是開發完成上線後我們通過面聊或通過《需求反饋表》給我們反饋的需求。我們目前使用的需求反饋表還用的是比較傳統的excel表格，後期會考慮做成簡單的系統，這樣採集反饋問題更及時，反饋人也能更方便了解自己反饋需求的狀態。
當然，在整個用戶反饋環節，我們也有需要反思的。比如需求調研覆蓋的面還不夠廣，覆蓋的層次還不夠多，包括各大區不同崗位層級的用戶還沒來得及全部溝通到位，後續我們也會在此投入更多精力。
3.競品分析
從進公司到現在，產品部已經完成兩版的競品分析報告，也分析了大量教育類產品，從中收穫非常多。無論是對整個行業軟件水平的瞭解，還是學習借鑑優秀產品，都幫助我們對行業內產品有了更深的瞭解，後期有機會我們會把這些分析報告整理後發出，希望引發大家更多的思考。不過關於競品分析，有一點需要我們注意的：競品畢竟是競品，它的業務場景可能和我們不一樣，不能直接copy，需要辯證的分析它存在場景的價值和意義。
就在前段時間有老師給我們提出，學而思和新東方都在課堂上使用答題器收集學員課堂學情數據。於是我們在網上也做了相應競品調研，看了很多課堂使用答題器的視頻，發現確實通過答題器收集學員學情數據很方便，既能調動課堂氛圍還能產生學情數據。但隨着調研深入，同時我們也到學而思和新東方線下課堂去體驗，發現他們線下面授課無一例外都沒用到答題器，只有雙師模式纔在運用。對這一現象，我們認爲，基於現有的線下小班授課的課堂答題器數據採集的迫切性不高，學員只要通過舉手或老師挨個查看學員作業就能很快收集到班級學情數據。而雙師模式需要一個老師覆蓋幾個班，上百人，同時還是遠程教學，實時掌握學員學情數據就必須通過答題器這種模式實現。從另一方面答題器的成本也相對較高，不僅是軟硬件投入成本，還包括課堂、課後管理成本都會帶來較大麻煩。我想這也是答題器雖然已經很成熟但仍在傳統課堂中使用不高的主要原因吧。
當然除以上幾種需求收集方式外，我們目前還缺少通過數據反饋中收集需求，比如通過在產品中對功能進行數據埋點，獲取各功能使用情況的數據，從中瞭解用戶的使用頻率及習慣來獲取需求。這個部分我們會在後續開發中逐步加入，畢竟人可能會說謊，但數據不會。
需求收集完，自然是需要對需求進行分析、過濾、篩選，從中去僞存真和優先級排序。首先我們需要區分收集上來的需求是真需求還是僞需求。有時真的很難區分，很多需求看起來都無比真實，但還原到實際場景卻是個僞需求。
舉個我自己提僞需求的例子，當時我剛到極客，希望快速提升產品逼格，於是聯繫到一家自動批改數學主觀題作業的公司。那家公司在做主觀題數學作業批改上確實很牛，在2016年通過它們的高考機器人蔘加北京數學卷考試得了105分。我當時希望能通過引進它們的自動批改作業功能，幫助咱們的老師減輕工作量。但後來我把這個產品推薦給老師時，存在兩種截然相反的態度，一種是認爲有這個功能太好了，能幫助老師減輕工作量，甚至可以完全可以不要助教了。另一種認爲其實老師批改作業的時間也佔用不到太多，必要性不強。後來我們產品也經過多次內部溝通、討論，到實際上課和作業批改場景裏實地調研，發現確實有問題。一來是我們很多老師本來就有助教，這些批改作業工作會交給助教完成。即使沒有助教，我們的班級都是小班教學，一個班也就十幾二十個學生，每次作業也就不到半小時能搞定，而且老師在實際批改作業時還能快速瞭解孩子學情狀況。這個自動批改作業的需求雖然從表面粗略一想完全合乎需求，但還原到真實場景裏卻就不是那麼回事。
從這件事裏也讓我總結出如何識別僞需求的兩個心法：1）任何需求必須還原到具體應用場景去思考和分析 2）不要看用戶怎麼說，關鍵看用戶怎麼做。
需求去僞存真後，還需對真實需求進行優先級排序，分清需求的輕重緩急和節奏對產品設計也非常重要。現在我們的做法是把收集上來的每一個需求都錄入到禪道（軟件項目管理平臺）的需求池裏，每次規劃下一個版本時我們會從需求池裏根據輕重緩急把需求重新梳理和設計，並把需求移到下一個版本中進行排期開發。
這裏需要重點講講我們關於需求優先級排序的方法。很多人講把需求優先級通過緊急、重要兩個維度生成四個象限，重要緊急〉重要不緊急〉緊急不重要〉不重要不緊急。當然，這個處理需求的原則沒有問題，但沒有定義什麼需求重要什麼需求緊急。其實緊急這個維度很好判斷，取決於交付時限、任務依賴。交付時限是指需求最終截止期限，如果過期上線將對業務有較大影響。任務依賴是指該需求是某個流程中的一環，如果缺失這一環將對整體流程造成影響。但重要這個維度就很難的定義，我認爲重要維度有兩個因素：影響範圍、商業價值。影響範圍很簡單，是指能滿足多少用戶的需求。商業價值是指該需求能對用戶帶來多大價值或給公司帶來多大的競爭優勢。
分清了重要和緊急的定義，我們就可以以量化的方式對優先級進行排序。量化的方法就是把重要和緊急兩個維度滿分設置爲5分，分別定義需求兩個維度的分值然後兩項相乘就得出該需求的總分，最後根據總分再進行排序。
當然，以上需求管理辦法主要適用已經上線的產品功能迭代，新項目開發需求還不適用。因爲新項目開發會利用大量研發資源，也存在一定風險，而現在來自各個部門越來越多的新項目需求，這樣的需求開發與否以及優先級排序就不能只在產品部內部進行決策，需要上升到公司級層面共同決策。因此後期我想可以通過在公司內部成立<產品評審委員會>的形式，召集公司產品智囊團在更大範圍內對產品方向、規劃進行探討和決策。
以上是本期產品部關於需求收集、分析及管理辦法的分享，過程中肯定有不完善的地方，也希望大家多多批評指正，幫助我們及我們設計的產品共同成長！
再次感謝大家利用寶貴時間看完此文，我們下期見！