1:抓核心點，不是所有使用者訴求都是需求
我們每做一個專案迭代或者新專案一定有目的，而需求分析階段，需求採集渠道中的需求往往是零散的、無重點的、邏輯性不強的，所以我們需要從這些離散的需求點中要抓住核心，梳理實際使用場景去分析問題，所有的核心點一定是以最終目的為導向的，不是所有使用者訴求都是需求。
以我的專案為例，由於歷史原因，自配送人員關係沒有進入OA系統，所以配送員工資結算資料只能做進配送系統，相當於是一個簡單考勤記錄，其實最早之前系統是有這個功能的，但是由於之前沒有仔細整理需求，導致這個功能白做了，所以這次我接手幾乎從做，我以為這個事情比較簡單就讓一個產品助理先去整理需求，當把原型圖出出來時發現並不能解決結算工資的功能，只是一個簡單的排班。
所以，當時我就跟那小兄弟說，你這東西只是完成了排班，然而排班的目的為了結算工資這還不能滿足需求。所以我跟他強調，我們做這個需求的目的是為了考勤，諸如請假、值班、加班工時、輪休日加班等資料要能提供出來，他的第一版原型其實沒有充分了解到我們為什麼要做這個排班功能，所以在瞭解需求過程中沒有抓住核心點，導致需求不明確。
2:制定規則、改善複雜流程
我的上一家企業做的是網際網路電商，其實在我看來電商和O2O有很大的區別點就是電商在當下盛行的情況下已經變的很有規則了，首頁、產品列表頁、詳情頁、下單頁等等，每個頁面展示的資訊也大相徑庭，而O2O不一樣，一方面是O2O差不多13年才興起，到目前為止（15年）還沒有一個標杆行業，另一方面是O2O與日常生活聯絡的太緊密，落地下來就是很複雜的業務流，這些是to C產品的規則化和流程化，而流程化的東西在to B產品上體現的尤為明顯，to B產品最經典的例子就是公司後臺系統。
不論是一個to C的產品還是to B的產品，我們都要考慮到使用者使用場景，PM需要把自己當作使用者，充分考慮各種情況下的使用者思維才能設計一個滿足使用者需求的產品，這裡並不是一味的去迎合使用者，做網際網路的都知道當一個業務不是規則化時很難用產品去滿足使用者，所以我們有必要制定規則，或者最佳化不完善、流程複雜的
規則。
下面說說制定規則，其實統一規則有利有弊，舉個例子，滴滴打車的訂單是搶的，uber打車的訂單是系統自動分配的，滴滴那種做法能提高司機積極性、自主性，司機可以選擇高金額的訂單，但是這種做法也會影響使用者體驗，比如說萬一以後不補貼了，我只是一個起步價，有些司機就不願意接單，要等待很久；而uber打車制定了自動分配的規則，先分配目前離乘客最近的空閒司機，如果他不接再分配給下一個，這種做法能不能滿足使用者我不說，我只說這種規則簡化了下單流程，司機和乘客只有兩個選項，接還是不接，坐還是不坐，司機如果不接，但他並不知道下一單能等到什麼時候，訂單金額有多大？雖然司機間的積極性和自主性減少，但是對使用者來說體驗很好。
說完了制定規則，再說一下改善流程，我上面說了這種流程化精簡在to B產品上尤為明顯，很多人有個看法就是後臺系統反正是自己人或者其他企業人員用的，完成功能就行，沒必要做的這麼便捷和細緻，其實不然，優秀的PM在這方面總能善始善終，因為在他們眼裡一點點的產品最佳化或者流程最佳化能為企業帶來很多的效益，這個我有切身的體會。
之前做的多個專案，其中有兩個就是我在做需求的時候發現業務部門在實際運營中思維定勢或者每日重複做屬於他的工作，但是他們並沒有發現這樣做其實效率很低，在沒人觀察流程有問題的時候，業務部門已經形成規範，但是這種規範並不是最優的，當PM做需求分析的時候需要細緻觀察他們部門或者個人的工作內容，想一想為什麼這麼樣做，有沒有其他方案能提高其工作效率。
在做資料統計需求的時候我發現業務部門某同事每天要先匯出所有新使用者電話、訂單號、餐廳金額、訂單金額等資料用於考察配送員滿意度、使用者滿意度，然而她每天匯出的資料其實有另外兩個同事也需要用，只是使用目的不一樣，但是他們都很死板，他們三個每天匯出一份完整資料，然後篩選條件，組合成自己要的資料，這種工作其實很沒必要，我們可以每天為他們部門發一份當日訂單報表，標註新使用者即可。
還有個例子是，財務在結算物流人員工資的時候很多計算公式是相互關聯的，比如說A=B+C，D=A*E+B-C，然而他們就計算成D=(B+C)*E+B-C，暫且不說他們部門管理流程怎麼樣，但是PM在遇到這樣業務流程的時候結合產品設計考慮是否可以精簡流程，實現產品設計的初衷的同時也能簡化流程。
3:離散需求整合
在和業務部門打交道的時候發現他們的思維邏輯性可能稍微差點，在PM瞭解需求的時候業務人員或者使用者表述的沒有前因後果，也就是沒有邏輯性，這時如果PM不追問下去自己很容易被帶到坑裡面，合格的PM應該在這種情況下峰迴路轉，把問題再闡述一遍，如遇到稍微強勢一點的PM，此時應該會指出剛才的表述有錯誤。
還有的業務部門人員在你去溝通的時候嘩啦啦的說了一大推產品改進意見或者新需求想法，此時PM應該細心聆聽，記錄下需求點，千萬不要給他們答覆這個功能什麼時候做、什麼時候上線，因為系統永遠是不完善的、需求卻永遠是數不盡的，而資源是有限的，你給的答覆實現不了別人會有不好的看法，優秀的PM需要大局觀，能夠和團隊一起評估需求優先順序，規劃產品生命週期，這才能推進產品迭代。
4:技術人員參與需求分析階段
現在很多網際網路公司基本上都是產品驅動，很難說技術驅動，因為產品團隊可以知道使用者想要什麼，我在參與需求分析過程中事業部技術負責人喜歡跟著我一起去了解需求，這在我之前的工作組中沒遇到過，現在做需求的時候他參與進來後我發現整個產品需求被亂了，阻礙了我需求分析進度，因為他總是以技術的角度考慮這樣實現的難度，由於他是技術負責人，邏輯思維能力很強，每當聽到這個資料沒有需要新增一個入口去維護時他就站出來說為什麼要這樣做，然後勸說業務部門說這個資料提供不了，能不能先不做。
但是從產品角度上考慮，既然選擇做這個專案那麼就該從產品角度去設計好，等一整套產品方案出來之後再去精簡功能是一個很好的方法，還有一些情況是當有一個比較好的idea產生時技術人員會首先考慮能不能實現、實現的複雜度，如果有一點困難或者技術可行方案不能當場給出時，這個功能就暫且擱置了，也許就會提出另一個不會錯但是並不是最好的方案，所以技術人員參與需求分析階段最容易把原本一個好的產品扼殺在搖籃之中。綜上考慮，我的理解是技術人員在需求分析階段暫且不要參與進來，等產品團隊內部討論之後技術團隊參與審評，這樣也許能達到事半功倍的作用。
1:抓核心點，不是所有使用者訴求都是需求
我們每做一個專案迭代或者新專案一定有目的，而需求分析階段，需求採集渠道中的需求往往是零散的、無重點的、邏輯性不強的，所以我們需要從這些離散的需求點中要抓住核心，梳理實際使用場景去分析問題，所有的核心點一定是以最終目的為導向的，不是所有使用者訴求都是需求。
以我的專案為例，由於歷史原因，自配送人員關係沒有進入OA系統，所以配送員工資結算資料只能做進配送系統，相當於是一個簡單考勤記錄，其實最早之前系統是有這個功能的，但是由於之前沒有仔細整理需求，導致這個功能白做了，所以這次我接手幾乎從做，我以為這個事情比較簡單就讓一個產品助理先去整理需求，當把原型圖出出來時發現並不能解決結算工資的功能，只是一個簡單的排班。
所以，當時我就跟那小兄弟說，你這東西只是完成了排班，然而排班的目的為了結算工資這還不能滿足需求。所以我跟他強調，我們做這個需求的目的是為了考勤，諸如請假、值班、加班工時、輪休日加班等資料要能提供出來，他的第一版原型其實沒有充分了解到我們為什麼要做這個排班功能，所以在瞭解需求過程中沒有抓住核心點，導致需求不明確。
2:制定規則、改善複雜流程
我的上一家企業做的是網際網路電商，其實在我看來電商和O2O有很大的區別點就是電商在當下盛行的情況下已經變的很有規則了，首頁、產品列表頁、詳情頁、下單頁等等，每個頁面展示的資訊也大相徑庭，而O2O不一樣，一方面是O2O差不多13年才興起，到目前為止（15年）還沒有一個標杆行業，另一方面是O2O與日常生活聯絡的太緊密，落地下來就是很複雜的業務流，這些是to C產品的規則化和流程化，而流程化的東西在to B產品上體現的尤為明顯，to B產品最經典的例子就是公司後臺系統。
不論是一個to C的產品還是to B的產品，我們都要考慮到使用者使用場景，PM需要把自己當作使用者，充分考慮各種情況下的使用者思維才能設計一個滿足使用者需求的產品，這裡並不是一味的去迎合使用者，做網際網路的都知道當一個業務不是規則化時很難用產品去滿足使用者，所以我們有必要制定規則，或者最佳化不完善、流程複雜的
規則。
下面說說制定規則，其實統一規則有利有弊，舉個例子，滴滴打車的訂單是搶的，uber打車的訂單是系統自動分配的，滴滴那種做法能提高司機積極性、自主性，司機可以選擇高金額的訂單，但是這種做法也會影響使用者體驗，比如說萬一以後不補貼了，我只是一個起步價，有些司機就不願意接單，要等待很久；而uber打車制定了自動分配的規則，先分配目前離乘客最近的空閒司機，如果他不接再分配給下一個，這種做法能不能滿足使用者我不說，我只說這種規則簡化了下單流程，司機和乘客只有兩個選項，接還是不接，坐還是不坐，司機如果不接，但他並不知道下一單能等到什麼時候，訂單金額有多大？雖然司機間的積極性和自主性減少，但是對使用者來說體驗很好。
說完了制定規則，再說一下改善流程，我上面說了這種流程化精簡在to B產品上尤為明顯，很多人有個看法就是後臺系統反正是自己人或者其他企業人員用的，完成功能就行，沒必要做的這麼便捷和細緻，其實不然，優秀的PM在這方面總能善始善終，因為在他們眼裡一點點的產品最佳化或者流程最佳化能為企業帶來很多的效益，這個我有切身的體會。
之前做的多個專案，其中有兩個就是我在做需求的時候發現業務部門在實際運營中思維定勢或者每日重複做屬於他的工作，但是他們並沒有發現這樣做其實效率很低，在沒人觀察流程有問題的時候，業務部門已經形成規範，但是這種規範並不是最優的，當PM做需求分析的時候需要細緻觀察他們部門或者個人的工作內容，想一想為什麼這麼樣做，有沒有其他方案能提高其工作效率。
在做資料統計需求的時候我發現業務部門某同事每天要先匯出所有新使用者電話、訂單號、餐廳金額、訂單金額等資料用於考察配送員滿意度、使用者滿意度，然而她每天匯出的資料其實有另外兩個同事也需要用，只是使用目的不一樣，但是他們都很死板，他們三個每天匯出一份完整資料，然後篩選條件，組合成自己要的資料，這種工作其實很沒必要，我們可以每天為他們部門發一份當日訂單報表，標註新使用者即可。
還有個例子是，財務在結算物流人員工資的時候很多計算公式是相互關聯的，比如說A=B+C，D=A*E+B-C，然而他們就計算成D=(B+C)*E+B-C，暫且不說他們部門管理流程怎麼樣，但是PM在遇到這樣業務流程的時候結合產品設計考慮是否可以精簡流程，實現產品設計的初衷的同時也能簡化流程。
3:離散需求整合
在和業務部門打交道的時候發現他們的思維邏輯性可能稍微差點，在PM瞭解需求的時候業務人員或者使用者表述的沒有前因後果，也就是沒有邏輯性，這時如果PM不追問下去自己很容易被帶到坑裡面，合格的PM應該在這種情況下峰迴路轉，把問題再闡述一遍，如遇到稍微強勢一點的PM，此時應該會指出剛才的表述有錯誤。
還有的業務部門人員在你去溝通的時候嘩啦啦的說了一大推產品改進意見或者新需求想法，此時PM應該細心聆聽，記錄下需求點，千萬不要給他們答覆這個功能什麼時候做、什麼時候上線，因為系統永遠是不完善的、需求卻永遠是數不盡的，而資源是有限的，你給的答覆實現不了別人會有不好的看法，優秀的PM需要大局觀，能夠和團隊一起評估需求優先順序，規劃產品生命週期，這才能推進產品迭代。
4:技術人員參與需求分析階段
現在很多網際網路公司基本上都是產品驅動，很難說技術驅動，因為產品團隊可以知道使用者想要什麼，我在參與需求分析過程中事業部技術負責人喜歡跟著我一起去了解需求，這在我之前的工作組中沒遇到過，現在做需求的時候他參與進來後我發現整個產品需求被亂了，阻礙了我需求分析進度，因為他總是以技術的角度考慮這樣實現的難度，由於他是技術負責人，邏輯思維能力很強，每當聽到這個資料沒有需要新增一個入口去維護時他就站出來說為什麼要這樣做，然後勸說業務部門說這個資料提供不了，能不能先不做。
但是從產品角度上考慮，既然選擇做這個專案那麼就該從產品角度去設計好，等一整套產品方案出來之後再去精簡功能是一個很好的方法，還有一些情況是當有一個比較好的idea產生時技術人員會首先考慮能不能實現、實現的複雜度，如果有一點困難或者技術可行方案不能當場給出時，這個功能就暫且擱置了，也許就會提出另一個不會錯但是並不是最好的方案，所以技術人員參與需求分析階段最容易把原本一個好的產品扼殺在搖籃之中。綜上考慮，我的理解是技術人員在需求分析階段暫且不要參與進來，等產品團隊內部討論之後技術團隊參與審評，這樣也許能達到事半功倍的作用。