這段時(shí)間我做了兩個(gè)大項(xiàng)目，其中一個(gè)項(xiàng)目算是商業(yè)模式上和使用規(guī)范上的調(diào)整，另一個(gè)項(xiàng)目是之前功能的重做，為什么重做我下面會(huì)說到。關(guān)于需求分析，我認(rèn)為把需求抽象成產(chǎn)品功能花費(fèi)的時(shí)間占到了軟件開發(fā)周期的40%，產(chǎn)品設(shè)計(jì)到評(píng)審?fù)甑臅r(shí)間大概是20%，也就是說實(shí)際開發(fā)之前產(chǎn)品團(tuán)隊(duì)介入的工作占據(jù)項(xiàng)目的60%，在需求分析階段我有一些個(gè)人觀點(diǎn)。

? ? ?1:抓核心點(diǎn)，不是所有用戶訴求都是需求

我們每做一個(gè)項(xiàng)目迭代或者新項(xiàng)目一定有目的，而需求分析階段，需求采集渠道中的需求往往是零散的、無重點(diǎn)的、邏輯性不強(qiáng)的，所以我們需要從這些離散的需求點(diǎn)中要抓住核心，梳理實(shí)際使用場(chǎng)景去分析問題，所有的核心點(diǎn)一定是以最終目的為導(dǎo)向的，不是所有用戶訴求都是需求。

以我的項(xiàng)目為例，由于歷史原因，自配送人員關(guān)系沒有進(jìn)入OA系統(tǒng)，所以配送員工資結(jié)算數(shù)據(jù)只能做進(jìn)配送系統(tǒng)，相當(dāng)于是一個(gè)簡(jiǎn)單考勤記錄，其實(shí)最早之前系統(tǒng)是有這個(gè)功能的，但是由于之前沒有仔細(xì)整理需求，導(dǎo)致這個(gè)功能白做了，所以這次我接手幾乎從做，我以為這個(gè)事情比較簡(jiǎn)單就讓一個(gè)產(chǎn)品助理先去整理需求，當(dāng)把原型圖出出來時(shí)發(fā)現(xiàn)并不能解決結(jié)算工資的功能，只是一個(gè)簡(jiǎn)單的排班。

所以，當(dāng)時(shí)我就跟那小兄弟說，你這東西只是完成了排班，然而排班的目的為了結(jié)算工資這還不能滿足需求。所以我跟他強(qiáng)調(diào)，我們做這個(gè)需求的目的是為了考勤，諸如請(qǐng)假、值班、加班工時(shí)、輪休日加班等數(shù)據(jù)要能提供出來，他的第一版原型其實(shí)沒有充分了解到我們?yōu)槭裁匆鲞@個(gè)排班功能，所以在了解需求過程中沒有抓住核心點(diǎn)，導(dǎo)致需求不明確。

? ? ? 2:制定規(guī)則、改善復(fù)雜流程

我的上一家企業(yè)做的是互聯(lián)網(wǎng)電商，其實(shí)在我看來電商和O2O有很大的區(qū)別點(diǎn)就是電商在當(dāng)下盛行的情況下已經(jīng)變的很有規(guī)則了，首頁、產(chǎn)品列表頁、詳情頁、下單頁等等，每個(gè)頁面展示的信息也大相徑庭，而O2O不一樣，一方面是O2O差不多13年才興起，到目前為止（15年）還沒有一個(gè)標(biāo)桿行業(yè)，另一方面是O2O與日常生活聯(lián)系的太緊密，落地下來就是很復(fù)雜的業(yè)務(wù)流，這些是to C產(chǎn)品的規(guī)則化和流程化，而流程化的東西在to B產(chǎn)品上體現(xiàn)的尤為明顯，to B產(chǎn)品最經(jīng)典的例子就是公司后臺(tái)系統(tǒng)。

不論是一個(gè)to C的產(chǎn)品還是to B的產(chǎn)品，我們都要考慮到用戶使用場(chǎng)景，PM需要把自己當(dāng)作用戶，充分考慮各種情況下的用戶思維才能設(shè)計(jì)一個(gè)滿足用戶需求的產(chǎn)品，這里并不是一味的去迎合用戶，做互聯(lián)網(wǎng)的都知道當(dāng)一個(gè)業(yè)務(wù)不是規(guī)則化時(shí)很難用產(chǎn)品去滿足用戶，所以我們有必要制定規(guī)則，或者優(yōu)化不完善、流程復(fù)雜的

規(guī)則。

下面說說制定規(guī)則，其實(shí)統(tǒng)一規(guī)則有利有弊，舉個(gè)例子，滴滴打車的訂單是搶的，uber打車的訂單是系統(tǒng)自動(dòng)分配的，滴滴那種做法能提高司機(jī)積極性、自主性，司機(jī)可以選擇高金額的訂單，但是這種做法也會(huì)影響用戶體驗(yàn)，比如說萬一以后不補(bǔ)貼了，我只是一個(gè)起步價(jià)，有些司機(jī)就不愿意接單，要等待很久；而uber打車制定了自動(dòng)分配的規(guī)則，先分配目前離乘客最近的空閑司機(jī)，如果他不接再分配給下一個(gè)，這種做法能不能滿足用戶我不說，我只說這種規(guī)則簡(jiǎn)化了下單流程，司機(jī)和乘客只有兩個(gè)選項(xiàng)，接還是不接，坐還是不坐，司機(jī)如果不接，但他并不知道下一單能等到什么時(shí)候，訂單金額有多大？雖然司機(jī)間的積極性和自主性減少，但是對(duì)用戶來說體驗(yàn)很好。

說完了制定規(guī)則，再說一下改善流程，我上面說了這種流程化精簡(jiǎn)在to B產(chǎn)品上尤為明顯，很多人有個(gè)看法就是后臺(tái)系統(tǒng)反正是自己人或者其他企業(yè)人員用的，完成功能就行，沒必要做的這么便捷和細(xì)致，其實(shí)不然，優(yōu)秀的PM在這方面總能善始善終，因?yàn)樵谒麄冄劾镆稽c(diǎn)點(diǎn)的產(chǎn)品優(yōu)化或者流程優(yōu)化能為企業(yè)帶來很多的效益，這個(gè)我有切身的體會(huì)。

之前做的多個(gè)項(xiàng)目，其中有兩個(gè)就是我在做需求的時(shí)候發(fā)現(xiàn)業(yè)務(wù)部門在實(shí)際運(yùn)營(yíng)中思維定勢(shì)或者每日重復(fù)做屬于他的工作，但是他們并沒有發(fā)現(xiàn)這樣做其實(shí)效率很低，在沒人觀察流程有問題的時(shí)候，業(yè)務(wù)部門已經(jīng)形成規(guī)范，但是這種規(guī)范并不是最優(yōu)的，當(dāng)PM做需求分析的時(shí)候需要細(xì)致觀察他們部門或者個(gè)人的工作內(nèi)容，想一想為什么這么樣做，有沒有其他方案能提高其工作效率。

在做數(shù)據(jù)統(tǒng)計(jì)需求的時(shí)候我發(fā)現(xiàn)業(yè)務(wù)部門某同事每天要先導(dǎo)出所有新用戶電話、訂單號(hào)、餐廳金額、訂單金額等數(shù)據(jù)用于考察配送員滿意度、用戶滿意度，然而她每天導(dǎo)出的數(shù)據(jù)其實(shí)有另外兩個(gè)同事也需要用，只是使用目的不一樣，但是他們都很死板，他們?nèi)齻€(gè)每天導(dǎo)出一份完整數(shù)據(jù)，然后篩選條件，組合成自己要的數(shù)據(jù)，這種工作其實(shí)很沒必要，我們可以每天為他們部門發(fā)一份當(dāng)日訂單報(bào)表，標(biāo)注新用戶即可。

還有個(gè)例子是，財(cái)務(wù)在結(jié)算物流人員工資的時(shí)候很多計(jì)算公式是相互關(guān)聯(lián)的，比如說A=B+C，D=A*E+B-C，然而他們就計(jì)算成D=(B+C)*E+B-C，暫且不說他們部門管理流程怎么樣，但是PM在遇到這樣業(yè)務(wù)流程的時(shí)候結(jié)合產(chǎn)品設(shè)計(jì)考慮是否可以精簡(jiǎn)流程，實(shí)現(xiàn)產(chǎn)品設(shè)計(jì)的初衷的同時(shí)也能簡(jiǎn)化流程。

? ? ? 3:離散需求整合

在和業(yè)務(wù)部門打交道的時(shí)候發(fā)現(xiàn)他們的思維邏輯性可能稍微差點(diǎn)，在PM了解需求的時(shí)候業(yè)務(wù)人員或者用戶表述的沒有前因后果，也就是沒有邏輯性，這時(shí)如果PM不追問下去自己很容易被帶到坑里面，合格的PM應(yīng)該在這種情況下峰回路轉(zhuǎn)，把問題再闡述一遍，如遇到稍微強(qiáng)勢(shì)一點(diǎn)的PM，此時(shí)應(yīng)該會(huì)指出剛才的表述有錯(cuò)誤。

還有的業(yè)務(wù)部門人員在你去溝通的時(shí)候嘩啦啦的說了一大推產(chǎn)品改進(jìn)意見或者新需求想法，此時(shí)PM應(yīng)該細(xì)心聆聽，記錄下需求點(diǎn)，千萬不要給他們答復(fù)這個(gè)功能什么時(shí)候做、什么時(shí)候上線，因?yàn)橄到y(tǒng)永遠(yuǎn)是不完善的、需求卻永遠(yuǎn)是數(shù)不盡的，而資源是有限的，你給的答復(fù)實(shí)現(xiàn)不了別人會(huì)有不好的看法，優(yōu)秀的PM需要大局觀，能夠和團(tuán)隊(duì)一起評(píng)估需求優(yōu)先級(jí)，規(guī)劃產(chǎn)品生命周期，這才能推進(jìn)產(chǎn)品迭代。

? ? ? ? 4:技術(shù)人員參與需求分析階段

現(xiàn)在很多互聯(lián)網(wǎng)公司基本上都是產(chǎn)品驅(qū)動(dòng)，很難說技術(shù)驅(qū)動(dòng)，因?yàn)楫a(chǎn)品團(tuán)隊(duì)可以知道用戶想要什么，我在參與需求分析過程中事業(yè)部技術(shù)負(fù)責(zé)人喜歡跟著我一起去了解需求，這在我之前的工作組中沒遇到過，現(xiàn)在做需求的時(shí)候他參與進(jìn)來后我發(fā)現(xiàn)整個(gè)產(chǎn)品需求被亂了，阻礙了我需求分析進(jìn)度，因?yàn)樗偸且约夹g(shù)的角度考慮這樣實(shí)現(xiàn)的難度，由于他是技術(shù)負(fù)責(zé)人，邏輯思維能力很強(qiáng)，每當(dāng)聽到這個(gè)數(shù)據(jù)沒有需要新增一個(gè)入口去維護(hù)時(shí)他就站出來說為什么要這樣做，然后勸說業(yè)務(wù)部門說這個(gè)數(shù)據(jù)提供不了，能不能先不做。

但是從產(chǎn)品角度上考慮，既然選擇做這個(gè)項(xiàng)目那么就該從產(chǎn)品角度去設(shè)計(jì)好，等一整套產(chǎn)品方案出來之后再去精簡(jiǎn)功能是一個(gè)很好的方法，還有一些情況是當(dāng)有一個(gè)比較好的idea產(chǎn)生時(shí)技術(shù)人員會(huì)首先考慮能不能實(shí)現(xiàn)、實(shí)現(xiàn)的復(fù)雜度，如果有一點(diǎn)困難或者技術(shù)可行方案不能當(dāng)場(chǎng)給出時(shí)，這個(gè)功能就暫且擱置了，也許就會(huì)提出另一個(gè)不會(huì)錯(cuò)但是并不是最好的方案，所以技術(shù)人員參與需求分析階段最容易把原本一個(gè)好的產(chǎn)品扼殺在搖籃之中。綜上考慮，我的理解是技術(shù)人員在需求分析階段暫且不要參與進(jìn)來，等產(chǎn)品團(tuán)隊(duì)內(nèi)部討論之后技術(shù)團(tuán)隊(duì)參與審評(píng)，這樣也許能達(dá)到事半功倍的作用。

本文為作者張輝投稿發(fā)布，轉(zhuǎn)載請(qǐng)注明來源于人人都是產(chǎn)品經(jīng)理并附帶本文鏈接