這篇文章筆者將通過一個日常工作中具體需求，重新梳理一遍從接到需求到功能上線的全過程，以及在實現(xiàn)這個需求的過程中遇到的一系列問題以及解決方案。

首先說下我們的團(tuán)隊配置：2個運(yùn)營、1個產(chǎn)品兼測試兼部分交互、1個前端1個后端、1個設(shè)計兼部分交互。這個配置在一個以運(yùn)營主導(dǎo)的公司里也算正常，而且需求方和技術(shù)方不在一起，溝通也不是很方便。但是，作為一個產(chǎn)品狗，搞好和技術(shù)部小伙伴之間的關(guān)系是必備技能，這可不能馬虎。

我們按照常規(guī)套路來從頭到尾講一下這個需求的實現(xiàn)過程，大體就分以下幾步：

公司不一樣流程也有小差別，比如豪氣正規(guī)的公司可能還會有灰度發(fā)布階段，當(dāng)然這也得看發(fā)布的需求值不值得這樣做，其中涉及的細(xì)節(jié)步驟暫未列出，只是寫了個大體框架，（你在原型出圖后到需求評審過程中，會有多次低保真模型流程測試，根據(jù)需求評審會其他小伙伴的意見進(jìn)行原型修改等過程）并且由于本次只是針對單個需求的制作過程，所以這個流程根據(jù)實際情況也會有些許不同。

收集需求

當(dāng)運(yùn)營的BOSS首先跟我提這個需求的時候，他是這樣說的：

“我需要咱們這個站做一個加價購功能，大概就是買產(chǎn)品達(dá)到一定條件后可以用少量價格換購另外的產(chǎn)品，類似與這個網(wǎng)站的功能（于是便掏出一個臺灣的網(wǎng)站給我看）?！?/p>

顯然當(dāng)他這樣跟我們說的需求我們是不可能回一聲“哦”然后屁顛屁顛跑去開始搞加價購，我們需要問清需求背景，需求目的，期望運(yùn)用到的需求場景，以及是否有后續(xù)計劃（考慮到功能拓展性）。

理解并分析需求

由于目標(biāo)客戶群體以及歐美文化因素等原因，面向這類用戶的跨境電商服裝垂直站點一直保持著簡約，低調(diào)的風(fēng)格，即使賣幾美金的貨，網(wǎng)站逼格也必須看起來跟國際大牌站點風(fēng)格沒什么兩樣，正是因為這個原因，大部分這類網(wǎng)站并沒有多少促銷活動，最多的兩種促銷手段是Coupon贈送和直減打折，剩下的打折手段實在是少之又少，相比于我們國內(nèi)琳瑯滿目的促銷手段，跨境垂直B2C站點這塊儼然荒蕪之地。

經(jīng)過我一番窮追猛打的追問后，并且由于以前自己做過一段時間運(yùn)營的背景，便了解到了以下情況：

• 現(xiàn)階段網(wǎng)站庫存積壓較多，常規(guī)清倉打折活動效果并不明顯，并且推廣入口單一（推廣人員只單純的推清倉集合頁，量也不大），清倉產(chǎn)品在很多流量入口沒有曝光，需要與關(guān)聯(lián)性熱賣品進(jìn)行搭配銷售，并且順便利用熱賣品的流量曝光清倉產(chǎn)品，加快清倉速度；
• 運(yùn)營這邊希望在有限的流量情況下提高客單價，由于加價購的門檻條件，當(dāng)活動功能覆蓋的流量范圍大并且功能運(yùn)用合理的情況下，是會對網(wǎng)站整體客單價產(chǎn)生一定影響；
• 當(dāng)前運(yùn)營活動手段單一，常規(guī)活動功能效果不明顯，運(yùn)營手段有限，需要新增活動功能；
• 未來運(yùn)營還希望能增加積分功能，滿贈功能等等其他活動功能（涉及后續(xù)功能擴(kuò)展，不屬于這次需求之內(nèi)，但是也要考慮）。

至此我們明白了運(yùn)營提加價購的背景，原因以及目的，這個需求的運(yùn)營真實需求是：以加價購為基礎(chǔ)，搭建一個活動功能體系，能夠有效的進(jìn)行商品清倉，并且可以用運(yùn)營手段影響客單價，增加運(yùn)營的活動運(yùn)營手段。

在理解了運(yùn)營的需求后，我們需要對用戶需求進(jìn)行分析，如何平衡用戶需求以及商業(yè)需求？這個是需要我們考慮的，我們希望用戶接受并且順暢使用我們的功能，那么從用戶角度來說，我們需要注意什么？

我們站的定位是年齡段在20-35歲的年輕女性，目標(biāo)國家則是主要集中的歐美國家，商品價格偏低，物美價廉，以服裝類目為主摻雜其他附屬品類。

所以這要是想做面對面的用戶調(diào)研是十分困難的，但是根據(jù)以往的數(shù)據(jù)分析以及行業(yè)經(jīng)驗，我們可以知道這個客戶群是對打折促銷非常感興趣的群體，也就是對價格敏感，更直白的從人性來說就是愛占小便宜。那么用戶的使用場景又是如何呢？

我們需要從：

• 用戶設(shè)備；
• 用戶使用時段；
• 用戶著陸頁頁面場景；

這幾點進(jìn)行分析，最終得出契合用戶使用場景的解決方案。所以我們需要在功能制作中需要注意在合適的場景下凸顯價格差異，滿足用戶對價格敏感的特點，刺激下單。當(dāng)然了，你還可以根據(jù)其他的分析模型去更加具體的分析一下，常用的分析模型有馬斯諾，人性7宗罪，從用戶動機(jī)出發(fā)，模擬用戶對需求進(jìn)行驗證等。

需求篩選及優(yōu)先級排序

好不容易接到個需求咱就別給他在篩選和排序了。（PS：這樣做是不對的！這里我們要區(qū)別需求優(yōu)先級排序和需求功能點優(yōu)先級排序，兩者所處的階段不一樣）

制定迭代計劃

此需求暫不涉及大的版本迭代計劃，但是對于此需求的小版本迭代計劃，則需要在第一次評審后根據(jù)技術(shù)，運(yùn)營等小伙伴的建議，評估具體功能點的實現(xiàn)難度，實現(xiàn)周期以及模擬運(yùn)營方案后進(jìn)行排期迭代。

轉(zhuǎn)化需求

在轉(zhuǎn)化需求前我們首先要知道我們首先面臨的幾個問題：

• 類似加價購活動在國外站點基本沒有，至少在我調(diào)查的近40個無論大型綜合類電商還是小型垂直電商站基本沒有發(fā)現(xiàn)（暫時發(fā)現(xiàn)臺灣的兩個網(wǎng)站有，但是不是我們的目標(biāo)客戶群），所以，我們面臨著比較高的用戶教育成本，并且需要選用適當(dāng)?shù)奈陌缸層脩衾斫獠⑶覅⒓踊顒樱?/li>
• 此類活動即使在國內(nèi)也沒有哪家網(wǎng)站是讓服裝類商品參與的，基本只有小零食，快消品等通用性較強(qiáng)的商品。服裝類商品涉及到尺碼，顏色，款式等個性化較高的屬性，用戶不太會草率加購這類產(chǎn)品，并且服裝類商品如果尺碼，款式問題涉及的退換貨較多，如果主商品退貨，加購商品退不退就很尷尬，類似這種情況涉及的糾紛也相對較多；
• 由于公司業(yè)務(wù)原因，GA頁面事件埋點暫時不可用，也就是說具體的頁面點擊事件數(shù)據(jù)暫時不可用，我們只能根據(jù)粗糙的用戶行為數(shù)據(jù),業(yè)務(wù)指標(biāo)數(shù)據(jù)以及用戶反饋來盡量合理的評估活動功能效果；

了解面臨的問題后我們開始轉(zhuǎn)化需求。

明確需求的關(guān)鍵節(jié)點：

我們根據(jù)用戶使用場景來明確這個需求的前臺關(guān)鍵節(jié)點：

競品分析

確定關(guān)鍵節(jié)點后，我們有針對性的進(jìn)行競品分析，調(diào)研主流網(wǎng)站對于關(guān)鍵節(jié)點的處理的優(yōu)劣，由于國外沒有網(wǎng)站可以參考，在經(jīng)過多方篩選后，選取了國內(nèi)站點兩個綜合類并且流量較大，活動體系完備的網(wǎng)站，京東和1號店；（在此我只是闡述下競品分析的一些套路，具體分析內(nèi)容由于篇幅以及本文主題就不闡述了）

一般我們競品分析分為兩種，一種是完整的競品分析，我們需要進(jìn)入一個新市場，或者開一條新產(chǎn)品線，那么我們要完完整整的從戰(zhàn)略，產(chǎn)品架構(gòu)，產(chǎn)品功能點，產(chǎn)品界面設(shè)計等等層面去解構(gòu)，這也就是我們在各大網(wǎng)站上最常見的競品分析報告；然而從實際工作中來看，這種分析報告確實不怎么常用（但是這種分析一般用來鍛煉一下自己的產(chǎn)品思維是有幫助的）；我們常用的是針對功能點或者模塊的針對性競品分析，而這種分析又分為兩種：

• 帶著目的去拆解，優(yōu)化自己產(chǎn)品已有的功能；
• 功能總體分析評價，新增或者借(chao)鑒(xi)相應(yīng)的模塊或者功能。

而我們這次應(yīng)當(dāng)采用第二種方法，對競品的功能進(jìn)行總體分析評價，從而新增我們的活動體系。

競品分析過程中….（此處省略幾千字和N張圖）

根據(jù)我們對京東和1號店的活動體系進(jìn)行分析，得出以下關(guān)鍵結(jié)論：

一般的加購類活動類型包括以下幾個：

而這么多活動規(guī)則如何有序的在購物車進(jìn)行聚合展示呢？除了每個網(wǎng)站固有的分級策略外，一般的活動優(yōu)先級展示是這樣的：

至于為什么是這么個順序，有興趣可以自行去研究下，筆者在此就暫不闡述啦，除了以上關(guān)鍵路徑外，我們還對關(guān)鍵節(jié)點頁面的活動展示，交互方式，規(guī)則說明等做了詳細(xì)的研究和參考。在分析的過程中我們發(fā)現(xiàn)一個很嚴(yán)重的問題，這么復(fù)雜的活動，翻譯成英語的話，還真沒幾個人能懂。。。打個比方，”加價購”怎么翻譯？我專程問過好幾個國外同事，也沒人能簡潔的描述出來的，沒有一個詞來形容這個詞，他們甚至沒有聽過這種活動。

所以，如果直接按照國內(nèi)的加價購，完完整整的展示出來的話，那么我的1版本草稿業(yè)務(wù)邏輯方案是這樣事兒的：

這僅僅只是一個滿額減的完整的流程，里面還涉及到階梯滿減的概念，那么除了滿額減，還有滿額贈，滿量增，滿量減，滿額折，滿量折，每一個都這么來一遍？中國人都繞暈了吧，何況還得翻譯成英文，還得通俗易懂短小精悍，即使不考慮技術(shù)成本，如果這個作為第一個版本就這么個推出，基本就GG了。

所以，在功能框架一定的情況下，如果照搬國內(nèi)的設(shè)計并且直接推出全套版本顯然不能滿足我們的需求，我們要另辟蹊徑，站在國外友人的腦海里去考慮問題，去考慮他們的思考方式和語言特點，雖然我們要重新教育用戶，但是要盡可能的將用戶理解成本降至最低。

因此最終此功能的第一版大致方案框架是這樣事兒的：

暫時舍去階梯概念，舍去滿折方式，以一個Icon為節(jié)點，囊括滿額，滿量兩種活動方式，我們需要教育客戶一看到這個Icon就知道這是類似于加價購的活動，不再在標(biāo)識上區(qū)分滿額，滿量概念，在用戶的購物動線上，從Icon，文案一步步引導(dǎo)用戶，完成對活動的理解和參與，整個過程是個很自然的引導(dǎo)過程，不用再去讓用戶糾結(jié)規(guī)則，也不再去設(shè)置長篇大論的活動引導(dǎo)頁。

到了這里，我們就不再出現(xiàn)加價購這個名詞了，我們稱之為APA活動體系，去養(yǎng)成用戶對于APA活動的認(rèn)知和使用習(xí)慣。

原型出圖

前臺原型出圖

這個需求在原型制作環(huán)節(jié)整個頁面展示雖然簡單，但是涉及到多規(guī)則，后臺設(shè)計多流程。前端頁面動態(tài)數(shù)據(jù)較多，尤其注意規(guī)則說明以及異常說明詳細(xì)無遺漏，否則到時候做完了測試的時候就不可避免的開懟。并且與用戶的交互也比較多，所以我采取了低保真交互原型，并且把交互方式錄成GIF放在原型包里面，（必須要特意去提醒開發(fā)和設(shè)計某些按鈕是可以點的?。。。┚唧w的原型這里就不放了（不要打我，我一般做低保真交互模型的原則是做出特定的交互方式，對于界面元素只是標(biāo)注下信息層級關(guān)系，不會去加色彩以及按鈕樣式誘導(dǎo)設(shè)計師，每個人都有每個人的原型寫法，如果有感興趣的同學(xué)可以跟筆者交流下），在跟設(shè)計和開發(fā)反復(fù)溝通交流以及后兩次評審會之后，我們的第一版前端成品是這樣的：

商品列表頁Icon展示：

由于以前設(shè)計規(guī)范的缺失，在商品列表頁我們補(bǔ)充并且制定了活動功能的Icon規(guī)范，采用紅底白字的Icon方式展示活動，這為后續(xù)的其他活動功能留下擴(kuò)展空間，鼠標(biāo)移入會有簡短說明。

商品詳情頁活動規(guī)則以及選購商品展示：

商品詳情頁首先展示的是一段引導(dǎo)性文案，我們不會上來就告訴用戶活動詳細(xì)規(guī)則，因為第一英文解釋起來實在太麻煩，二來過于繁瑣的文案也會造成頁面混亂。我們把既定的規(guī)則放入展開模塊當(dāng)中。這個頁面涉及到的程序規(guī)則就是頁面展示的相應(yīng)文案，根據(jù)后臺配置的活動類型不同而變化，比如滿減活動，這里就會提示 “You have a chance to get this following fashion items in a low price:”

如果后臺配置的是滿贈活動，這里就會提示”You have a chance to get this items for free”,同時按鈕文案也會變成 “See the free?items”,里面的規(guī)則說明也會相應(yīng)變化。

這個鏈接會引導(dǎo)客戶去一個專門為APA活動定做的專題落地頁當(dāng)中，可供用戶選擇更多APA商品，當(dāng)然這個專題落地頁模板的制作也又是一個比較好玩的事情了，直接上部分設(shè)計稿吧（Low-price items里面的圖標(biāo)文案超出圖標(biāo)范圍是因為我在截圖的時候只是縮小了頁面，但是文案是用html寫的，不是圖片，所以字體縮小不了）

商品專題頁頁面截圖（部分）

購物車頁展示：

示例截圖1

示例截圖2

購物車?yán)锩嫖覀儏⒖剂瞬糠指偲返姆謾诜绞?，并且轉(zhuǎn)化成我們自己的分欄方式，這里尤其要提的是購物車?yán)锩娴倪壿嬢^為復(fù)雜，除了文案、提示語的變化，以及達(dá)到目標(biāo)值之后的商品狀態(tài)變化，按鈕樣式變化以外，比較無語的是在和技術(shù)溝通的過程中，發(fā)現(xiàn)了很多歷史遺留的邏輯問題，以及與其他系統(tǒng)對接留下來的未解決問題。

在這個需求中，我們的購物車無法同時存在兩條相同的商品數(shù)據(jù)，并且無法存在多個免費商品數(shù)據(jù)，這些購物車規(guī)則牽扯到的方面較多，優(yōu)化成本很高，這就導(dǎo)致了我們必須想出一些折中方案，盡量讓用戶體驗不那么糟糕或者造成相當(dāng)大的困惑，(事實證明在對國外同事做體驗測試的時候在極端情況下是存在一些困惑問題，不過這些問題出現(xiàn)頻次較少，可以交代客服人員在客戶詢問的時候進(jìn)行解釋。)

后臺原型出圖

后臺制作中首先要注意在活動功能管理板塊下預(yù)留其他活動的擴(kuò)展空間，并且注意前后端的數(shù)據(jù)交互標(biāo)注清晰，提前設(shè)計好表結(jié)構(gòu)和字段方便開發(fā)建表，理清楚業(yè)務(wù)操作邏輯后，便可出圖啦,這里我就貼操作邏輯以及最后的成品展示，后臺操作邏輯以及關(guān)鍵節(jié)點解釋如下：

表單部分截圖如下：(部分字段)

添加加購商品如下：(部分字段)

如何判斷我們的功能達(dá)到目的？

我們回過頭看看我們之前的需求分析，運(yùn)營希望加快清倉產(chǎn)品的清倉速度，提高清倉產(chǎn)品的曝光，那這只是業(yè)務(wù)場景，對于我們這個功能來說，清倉產(chǎn)品只是一種產(chǎn)品類型，那么如何判斷我們這個功能是否有效？我們根據(jù)實際條件下(我們無法拿到頁面點擊數(shù)據(jù))可以取到的數(shù)據(jù)制訂以下實驗：

我們采取獨立樣本T檢驗對功能效果進(jìn)行評測，總共10個清倉產(chǎn)品，產(chǎn)品轉(zhuǎn)化率近似，20個熱銷產(chǎn)品，轉(zhuǎn)化率同樣近似。

分三組制作三個專題：

• 第一個專題為普通專題，將10個清倉產(chǎn)品與20個熱銷產(chǎn)品混合放置即可；
• 第二個專題為加價購專屬專題，設(shè)定活動方式為滿減，將10個清倉產(chǎn)品作為20個熱銷產(chǎn)品的加購商品；
• 第三個專題也為加價購專屬專題，設(shè)定活動方式為滿贈，將10個清倉產(chǎn)品作為20個熱銷產(chǎn)品的贈品；

然后針對三個專題每一個專題抽取30個獨立用戶分組，用戶群的用戶基數(shù)近似相等，用戶群轉(zhuǎn)化率相似，采用相同的推廣渠道，由于無法精確確定用戶數(shù)量，我們只需告知推廣保證每日每個專題劃分的每一個群組的流量保證在一個特定數(shù)量XXXX左右，持續(xù)兩周，最終得出每個用戶分組的以下數(shù)據(jù)：從這個專題頁落地的用戶所下的訂單中，同時包含清倉產(chǎn)品與熱銷產(chǎn)品的訂單數(shù)/所有訂單數(shù)，我們給它起個名字叫近似加購率（因為即使在加價購專題里清倉產(chǎn)品和熱銷產(chǎn)品在一起也不一定就是參加加購活動加購的）。用圖表展現(xiàn)就是這樣：

得出數(shù)據(jù)后做兩兩獨立樣本T檢驗，最終判斷實驗結(jié)果，這個網(wǎng)站可以根據(jù)你的數(shù)據(jù)樣本輔助你完成此類實驗：http://www.evanmiller.org/ab-testing/t-test.html

（對于T檢驗的方法和適用范圍感興趣的讀者可以回顧下大學(xué)知識或者谷歌一下，這里筆者就暫不列出實驗具體步驟了，后期筆者會計劃專門寫一篇這類實驗的完整過程，這篇文章就只講一下筆者的實驗思路。）

需求評審

這一環(huán)節(jié)其實并不一定只在這一階段做一次，就像我上面說的，筆者出了第一版方案后拉幾個團(tuán)隊成員進(jìn)行初稿評審，理出許多問題，然后再進(jìn)行修改，針對一些短期無法實現(xiàn)或者成本較高的功能點進(jìn)行排期或者刪減，有時候也可能會出現(xiàn)二審，三審的可能性咯~如果到三審還有很多問題那就相當(dāng)?shù)木拘牧?，所以一般都是團(tuán)隊中過兩遍，然后拉上BOSS們再終審一遍基本就OK了。終審是最需要用心的時候，一定要注意自己的表達(dá)能力和情緒感染力，讓Boss能明白并且認(rèn)同你們的方案。在會議上面對別人的提問要及時給出有理有據(jù)的答復(fù)，這一點在終審上是要尤其注意的，良好的演說能力也能為你的需求過審少很多麻煩。

設(shè)計開發(fā)

設(shè)計開發(fā)中要隨時與團(tuán)隊成員保持聯(lián)系，尤其是與設(shè)計溝通更加頻繁，你們要商議具體的交互細(xì)節(jié)以及頁面細(xì)節(jié)，切記不可用特定的言語干擾設(shè)計思路。

比如說，有些產(chǎn)品會要求設(shè)計某個按鈕用什么什么顏色，某個元素大一點，小一點，這都是不可取的。你只需要確定好信息層級，告知設(shè)計師由于業(yè)務(wù)需求，哪些元素需要強(qiáng)調(diào)，哪些需要弱化即可，設(shè)計師會根據(jù)設(shè)計規(guī)范以及自己的設(shè)計思路進(jìn)行設(shè)計，否則就會和設(shè)計師懟的沒完沒了了；至于與開發(fā)的溝通，主要是在邏輯層面的交流會更多些，而且筆者認(rèn)為最好能懂些技術(shù)知識，即使一點不懂你也要分清楚哪個開發(fā)是做哪一塊的，遇到問題找誰，跟他應(yīng)該怎樣溝通，如果存在溝通障礙，那么程序員一般的反應(yīng)都是—>生悶氣，不理你，哈哈，你要知道，大部分程序員還是很可愛的。當(dāng)你的需求提上去后，什么時候測試，什么時候上線，這塊的進(jìn)度一般都由項目經(jīng)理掌控，當(dāng)然，自己的心里也要有譜，有自己的項目進(jìn)度表。

測試

測試確實是個心累的活兒，如果你們公司的測試人員較為專業(yè)，會為你省下不少麻煩和時間，你只需要負(fù)責(zé)上線前每一個階段的驗收即可。否則，你就得自己寫測試用例，測試反饋，直到上線，這里每個公司的流程不一樣，這里也就不過多闡述，免得產(chǎn)生誤導(dǎo)。

上線觀察，數(shù)據(jù)反饋

在此之前需要跟運(yùn)營人員以及推廣人員打好招呼按照事先設(shè)計的實驗方案進(jìn)行實驗，在上線之后每日監(jiān)控數(shù)據(jù)變動情況，每組數(shù)據(jù)的流量是否有異常，專題商品庫存情況，下架情況，等等，總之需要控制變量，確保實驗按照時間順利完成，最后拉取實驗數(shù)據(jù)進(jìn)行數(shù)據(jù)分析，根據(jù)分析結(jié)果確定此功能的可用性，得出分析報告反饋給團(tuán)隊成員和BOSS。

版本迭代

這一部我并沒有寫到最開始的那個流程圖當(dāng)中，對于一個完整的產(chǎn)品有大的版本迭代，對于一個功能同樣也會有相應(yīng)的版本迭代。在這個需求中，我們前面根據(jù)一二期需求評審之后以及后續(xù)根據(jù)運(yùn)營人員的實際情況進(jìn)行功能擴(kuò)展，針對此功能大致得出以下迭代計劃：

當(dāng)然，這個迭代計劃只是作為產(chǎn)品人員自己的計劃。具體每一階段是否上線還需要根據(jù)每一階段的數(shù)據(jù)反饋以及公司具體的運(yùn)營需求和運(yùn)營策略的變化（在一個運(yùn)營主導(dǎo)的公司就是這樣咯~）進(jìn)行調(diào)整，總之，用心對待自己做出來的東西，不僅僅是生孩子，養(yǎng)孩子的責(zé)任你同樣也逃不了。

至此，這個需求從初始到上線的一個流程就基本結(jié)束了。雖然僅僅只是通過一個需求來回顧了一下需求從開始到結(jié)束的整個框架，不知不覺也有了近7000字，對于里面的細(xì)節(jié)部分請原諒我沒有在本文中全部寫出來，文中還有許多的不足請各位讀者給予指正，私信評論都可，哈哈，歡迎拍磚。

本文由 @白子 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。