背景介紹：當(dāng)前正在負(fù)責(zé)的是一個O2O公司中營銷的臨時需求的產(chǎn)品。需求主要來自公司運營，和市場部門（線下地推人員）。當(dāng)前在做的是滿足業(yè)務(wù)隨時間變動的臨時性需求，產(chǎn)品通常都是一次性的，復(fù)用率較低。且公司尚無形成對業(yè)務(wù)的系統(tǒng)性支持。該產(chǎn)品的方向是，在滿足業(yè)務(wù)臨時需求的同時，總結(jié)一些常規(guī)化的需求模型，進(jìn)行常規(guī)化的研發(fā)，更好的響應(yīng)業(yè)務(wù)的需求，同事也避免重復(fù)性開發(fā)的資源成本。
近來臨時需求的增多搞得自己昏頭轉(zhuǎn)向，時間浪費了很多，卻沒有很好的解決問題。逢著當(dāng)前的閑暇，寫一下自己的體會，教訓(xùn)。
臨時需求對時間的要求會比較嚴(yán)格。所以一旦確定了要做某個東西，整個項目會進(jìn)入倒排期的流程。從收到來自需求方的需求郵件開始，盡快的整理出需求，梳理出邏輯能為整個項目爭取時間。但是就是在這種目的的營銷下，容易產(chǎn)生幾個問題，具體如下：
?需求了解不清楚。沒有形成詳細(xì)的業(yè)務(wù)流程圖，因為需求方在上海，而我們在北京。所以需求的主要溝通方式是電話或微信，跨城市的溝通很容易產(chǎn)生分歧。簡單的說就是你做完了東西，需求方不買賬，吃力不討好。所以，這要求我整理需求的時候務(wù)必流程化、圖形化，進(jìn)行郵件確認(rèn)。把所有的需求都以郵件的方式告知，雙方能夠很好的避免出現(xiàn)后期扯皮的事情。需要郵件確認(rèn)的內(nèi)容包括流程圖、功能點、文案、設(shè)計圖，其中流程圖和設(shè)計圖務(wù)必要確認(rèn)（最受運營重視）。
?需求的分析整理不透徹。這對于沒有技術(shù)背景的的產(chǎn)品是一個需要歷練的過程。一個需求往往不是自己能搞定的——比如我們當(dāng)前在做的歐洲杯的項目，需要跟4個團(tuán)隊進(jìn)行溝通協(xié)調(diào)。這就要求對具體怎么實現(xiàn)，能不能實現(xiàn)有一個清楚的認(rèn)知。而這些細(xì)節(jié)在業(yè)務(wù)流程圖中難以體現(xiàn)，最終確定的方案必然是在指定時間內(nèi)可實現(xiàn)的滿足了業(yè)務(wù)核心需求的雙方妥協(xié)的產(chǎn)物。這個核心在對對接方有清楚的了解，清楚對方能做到什么，做不到什么，哪些應(yīng)該他們做，哪些自己應(yīng)該做。對接過程中最應(yīng)該明確的是API文檔。所以最起碼的API文檔必然要自己確認(rèn)可行，才帶研發(fā)團(tuán)隊進(jìn)入。不然必然遭吐槽。方案改動的風(fēng)險也極高。
做臨時性需求時，有兩點是需要自己時刻考慮的問題。
?臨時需求如何體系化。無休止的滿足業(yè)務(wù)需求，而不懂得理解需求的內(nèi)核，只能是讓自己變得很疲憊，沒有成就感。所以針對公司業(yè)務(wù)，抽象大家常規(guī)的需求很重要。這要求做的時候考慮是否還會有類似的需求，哪些流程是可以常規(guī)化的，哪些是不行的。對業(yè)務(wù)的理解是一個初步的養(yǎng)成過程，不能一蹴而就。
?臨時需求常規(guī)化。簡單說就是盡可能早的預(yù)見到必須要做的臨時需求。這主要需要培養(yǎng)需求方，讓他們學(xué)會提早計劃，提早提需求。保證提出需求后有充足的時間考慮，實現(xiàn)。考慮到一般運營的具體運營方案都是以月為單位，所以在具體執(zhí)行時，在每月的月末發(fā)給需求方本月已經(jīng)做了的事情，索要下個月的業(yè)務(wù)規(guī)劃。這樣可以很好的保證產(chǎn)品迭代的條理性，不會隨便的加入CR。
