這段時間筆者做了兩個大項目，其中一個項目算是商業模式上和使用規范上的調整，另一個項目是之前功能的重做，為什么重做筆者下面會說到。關于需求分析，筆者認為認為把需求抽象成產品功能花費的時間占到了軟件開發周期的40%，產品設計到評審完的時間大概是20%，也就是說實際開發之前產品團隊介入的工作占據項目的60%，在需求分析階段筆者一些個人觀點。
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產生時技術人員會首先考慮能不能實現、實現的復雜度，如果有一點困難或者技術可行方案不能當場給出時，這個功能就暫且擱置了，也許就會提出另一個不會錯但是并不是最好的方案，所以技術人員參與需求分析階段最容易把原本一個好的產品扼殺在搖籃之中。綜上考慮，我的理解是技術人員在需求分析階段暫且不要參與進來，等產品團隊內部討論之后技術團隊參與審評，這樣也許能達到事半功倍的作用。
作者：張輝，來源：人人都是產品經理
