總結不在於回顧與記錄，而在於在覆盤中可以得到經驗教訓，得到更快速的成長。總結雖然很費腦力，但作為一項工作中最具收穫的環節，怎麼可以放棄呢，所以我拖到今天，還是把總結奉上了。
一、項目介紹
我們的產品是微信活動營銷工具，商家可以在管理後臺創建諸如大轉盤、投票的互動活動。此次部門準備拓展商業促銷類活動類型，也就是電商常見的砍價、秒殺活動，便於有賣貨需求的商家做促銷活動。我負責拼團的項目。拼團的玩法由來已久，但在拼多多的影響下，在微信又颳起了一股浪潮，藉助微信的強大社交屬性，開展拼團活動的確是做促銷的不二選擇。
項目成員包括4人，一個喜歡用PS開車的設計師，一個愛提需求的後端，一個頂著全部門最快稱號的前端，一個雞蛋裡挑骨頭的測試，以及一個對改需求樂此不疲的產品經理。拼團從今年6月份立項，花了3周半的時間才完成需求文檔第一版，文檔經過多次修改，7月底進入開發階段，10月中正式上線。
二、需求分析
（一）前期調研
一開始只是確定了要做帶支付的拼團，但拼團的玩法很多，需要先確定拼團的底層玩法是什麼。因此我對比了相關競品的拼團玩法，包括嵌入在商城的拼團，拼團app，還有提供拼團活動的工具型產品。在這一步，只是查看這些競品的底層玩法，而在後期進行業務流程設計時我又再度查看。
（二）定位
經過對主流拼團玩法的調研，結合自身產品的情況，確定了拼團的底層玩法採用當前主流的“達到參團人數後全員都能以拼團價購買的形式”，主打的特色在於能快速創建一款可變現的拼團活動。並將該活動取名為“天天拼團”，那時是想著像騰訊的天天遊戲系列那樣，如果做出多個該類型的活動，那一致性的前綴，其實是有助於增強產品關聯和用戶認知的（雖然很土）。銷售對外也能說“做電商促銷就用我們的天天系列”，想想覺得還挺爽。
三、業務流程
（一）業務板塊
確定好對拼團的定位後，我開始考慮一個帶支付的拼團，都需要哪些底部板塊，才能維持活動的自運轉。可以分為營銷設置，支付設置，商品管理，發貨設置，退款退貨，以及拼團最重要的分享邏輯。
營銷設置，第一版只挑選最為核心的功能，後面的功能再迭代。
支付設置有兩種，成團前付費有利於商家快速變現，但不利於推廣，尤其是缺乏背書的中小商家，利用第三方的拼團工具，其實較難取得粉絲信任。因此我們推出另一種支付模式“成團後付費”，即滿團後再進行支付，但由於不限制每個人都付費，所以可能會造成客戶流失和收入損失。前者更適合變現，後者更適合推廣。雙管齊下，由商家來選擇。雖然增加了開發難度，但我們認為是值得的。
底部模塊
（二）用戶流程
在確定底層板塊後，梳理用戶流程就很輕鬆了。從用戶進入首頁到完成支付，過程基本與一般電商的購物路徑無異，但由於我們定位為快速創建，所以縮減了許多設置與路徑。
用戶流程圖節選
四、頁面交互設計
節選首頁，訂單頁和商品詳情。
交互稿節選
五、推廣策略
在10月中旬已經上線，但並沒有大力推廣，等到宣傳雙十一新活動時再一起推廣，因為拼團+雙十一帶來的效果是翻倍的。包括在官網和商家後臺增加banner位，在活動類型新增類別“商業促銷類”，提前兩週發佈拼團的宣傳推文。
六、經驗總結
根據以上的覆盤，我發現有以下的不足和改進方案。
1．調研耗時太長
競品分析當時做的比較亂，因為我不瞭解項目，也並不清楚需要調研哪些方面，所以花了很多時間去調研，效率不高，效果也不好。現在回頭看調研的資料，發現可分為梳理拼團的玩法，不同玩法的優劣勢，營銷設置，用戶流程等。現在回顧，其實面對一個陌生的領域，不應該馬上進入細節，而要先思考框架，如果無法找到框架，也可以列出所有信息，用自下而上提煉的方法找到框架，然後再開始細節。這樣做，一方面可以提高調研的效率，一方面也可以使調研資料更有條理，便於後期回看。
2．做產品定位主觀因素強
做產品定位時雖然有思考，但主觀因素較強，對實際的環境缺乏瞭解。現在看來，其實拼團產品更大的意義是在於豐富了我們的商業促銷類活動，帶動高級版本的銷售。而對用戶而言，由於我們產品的定位本身就是輕量級，所以也無法提供一個帶有完整設置（物流、商品管理等）的拼團產品。因為這個限制是無法改變的，所以更應該思考，在這種限制下去做此項目，用戶是否買單。
這給我的一個啟發是，做產品定位需要做環境分析（比如SWOT分析法，適用於宏觀環境分析），作為一個子產品，它相對母產品的戰略定位是什麼。戰略定位其實就限制了很多東西了。以下是我後來利用swot做的分析。
SWOT分析
3．技術無法實現導致屢次修改方案
支付環節是調整次數最多的。由於是調用微信支付接口，微信的支付邏輯是到了開發階段才發現某些地方走不通，而且不是一次性發現，是開發過程中才不斷曝光，因此屢次調整文檔。耗費了較多時間。但這個也是隻有在開發過程中才能發現，無法完全避免。
4．商家場景多樣化甚至互為矛盾，無法全部滿足
舉例子說明。當商家的剩餘庫存小於開團要求人數時，是否允許粉絲開團？如果不允許，會造成庫存浪費。如果允許，則要求商家必須及時補充庫存。後來我們採用後者，因為考慮到商家的訴求應該是儘量清空庫存，所以我們的邏輯做成只要有庫存，就能開團，但是當最後一個粉絲提交訂單時，需要判斷庫存是否夠全組人扣，如果不夠，則提交訂單失敗，並提醒其通知商家添加庫存。
後來有一個商家因為這個邏輯找過來，說我的庫存的確就這麼點了，你們還讓人能開團，這不合理。
當時設計時的確沒考慮到這種情況，我當時認為大多數商家應該都是供過於求的，並且是可以快速補貨的。現在我已經想到了兩全其美的辦法，但仍不能掩蓋我沒有真實瞭解電商行業的事實。我在第一次考慮時，自認為那應該是大多數人的場景，然而那只是我的一廂情願，沒有現實依據。準確的判斷來源於充分的依據，在於你對用戶的瞭解程度。
這個給我的啟發是，在遇到多樣化的場景時，應該考慮主要場景並去滿足，而次要的場景，應該衡量交互成本、開發成本後再看是否要滿足，但如果是與主要場景矛盾，那就應該重新斟酌是否要兼容了。當然，對於場景的考量，必須建立在準確判斷上，否則做出的都是錯誤決策。
THE END
