項目重構——文本短信推廣重構
編輯導語:項目重構是一件特別耗費時間和人力的事情,項目重構比接手一個新項目更難;要在之前的系統基礎上進行修改,首先要對之前的系統足夠了解,對修改過程思路明確;本文作者分享了自己在接手一個項目重構時遇到的難題。
在近一個月我接手了我的第一個重構項目,雖然項目很小,但還是遇到了之前接手新項目時從未經歷的波折,總結一下這一個多月我所踩過的坑和這個項目。
一、項目背景
我司為一家大型家電企業,在兩年前直接由開發人員搭建了自己的短信發送平臺。
隨著業務的發展,原短信發送平臺在功能、流程上難以支持現階段的業務發展,為此需要對短信發放平臺進行重構。
二、業務調研
1. 原業務分析
原短信系統在搭建之時,我司尚未有專門的產品經理,完全由開發人員開發,且沒有搭建CRM系統,且各個系統的用戶數據并未打通。
在此情況下短信業務流程如下:
在經過和實際業務人員訪談后存在以下問題:
- 短信內容、投放人群無法復用(原系統不支持復制)。
- 客戶篩選顆粒度太大,缺少合適的標簽進行篩選。
- 難以支持大型活動中所需的短信的精準營銷,同一用戶可能在當天會受到多條類似的活動運營短信。
- 發送之后沒有任何數據,難以評估短信效果。
2. 問題原因
- 原短信推廣系統業務流程成單線業務流程,只存在短信發送一個實體,沒有投放人群、短信內容等實體使得不能自由匹配。
- 原系統開發時我司尚未有CRM和DMP系統等相關客戶數據分析處理系統,所以只能自行對客戶數據進行粗顆粒的劃分。
- 在原系統中未制定針對于客戶接收短信的規則導致客戶在一天之內接收過多短信。
- 原系統未將短信發送后的數據進行整合、分析,導致運營無法估量效果。
3. 問題解決思路
- 實現短信內容、投放人群復用。(高優)
- 實現CRM系統和短信推廣系統關聯。(高優)
- 制定客戶接收短信規則。(低優)
- 建立數據庫,制定數據界面反映短信回執效果。(中優)
三、改版目標
通過修改業務整體流程實現內容的多次復用,并通過調用CRM用戶數據服務來輔助短信精準發送,收集相關數據幫助業務人員分析發送效果。
四、業務流程優化
短信業務主要涉及人員只有運營、運營主管;其業務比較簡單,在項目重構時除了考慮短信平臺本身的業務流程,還需要考慮在CRM系統中調用短信服務的流程。
最終業務流程如下:
五、確認數據
對于短信系統來說主要數據為:
- 客戶數據;
- 號碼數據;
- 運營商返回數據。
客戶數據:客戶數據來源于重構后的CRM系統,人群篩選維度取決于之前客戶購買記錄和后續運營人員對于標簽的管理,并通過分組和人群直接分類客戶;在短信系統中直接調用CRM系統服務即可。
號碼數據:由于考慮到短信系統之后會開放給銷售公司,我司銷售公司和門店自己保留著一部分客戶數據(對總部保密);所以除了直接從CRM系統中直接獲得的客戶號碼外,還會有部分數據通過系統導入。
運營商返回數據:在短信發送整個業務中,我司能夠從運營商拿到的數據僅有短信發送成功條數、短信發送失敗條數,拿不到每個號碼發送情況。
整體來說能夠從運營商返回的數據有限,所以在之后的功能設計中需要增加更多數據收集方式。
六、功能框架設計
結合業務流程,以及與參與人員的訪談可以將整個系統劃分為4個模塊,分別為短信管理、統計分析、設置、賬戶管理。
除了考慮到之后功能擴展外還需要考慮到實際數據情況。
- 短信管理:為了之后的系統功能上的擴展性(我司有意做第三方平臺類產品),將短信分為短信簽名、短信模板、短信發送三部分,所有短信發送最終以發送任務的方式執行。
- 設置:主要考慮對發送的設置和名單的管理,其余功能需要在和運營商深入合作后再擴展。
- 統計分析:其實就是為了反映短信推送產生的效果,其分析大方向為從大顆?!w回執效果到小顆?!謾C號碼進行分析,但現階段我司還無法拿到每個號碼短信執行情況。
- 賬戶管理:主要考慮賬戶充值功能,現階段我司還不允許直接線上支付,需要走財務部線下充值方式和平臺轉充的方式。
七、信息架構設計
在信息架構上更多考慮到之后項目迭代時功能擴展,以及之后整合至大型DSP平臺,在結合功能框架后其信息架構如下:
八、數據建模
原短信系統中核心數據實體為短信、客戶,對應關系為多對多,而優化后的短信系統主要數據實體為發布任務、短信模板、短信簽名、人群和客戶。
它們之間的對應關系如下:
九、項目細節設計
1. 狀態設計
在整個過程中發布任務存在待審核、審核通過、審核未通過、發送成功、發送失敗、終止6種狀態。
在發布過程中送涉及到多個狀態的轉化,需要事先定義每種狀態以及狀態之間的切換條件。
2. 關鍵流程設計
在整個業務流程中最為關鍵的流程為發送任務發送、短信模板創建。
- 短信模板:短信內容的載體;
- 發送任務:短信發送的執行單位。
在短信模板流程中需要注意以下兩點:
- 由于運營商的限制,短信內容中不得包含敏感詞,在編輯過程中需要屏蔽敏感詞輸入。
- 在短信中常常會含有網址鏈接,而網址鏈接會占有比較多的短信字數,為了減少占用的短信字數需要轉換為短鏈。
而在發送任務發送流程中,主要需要考慮以下幾點:
- 短信運營商收費按短信條數收費,一調短信內容字數超過70字就會算作多條短信進行收費,在用戶編輯發送時就需要預先告知短信字數。
- 運營人員上傳或選中的號碼,需要進行篩選,屏蔽掉投訴過的用戶號碼。
- 在發送時需要考慮是否需要增加測試發送,以及測試發送是否需要審批,如果跳過審批可能導致短信內容不可控。
以上只是最為重要的兩個業務流程,除此之外還需要考慮充值流程、終止任務流程等,在此就不全部展示。
3. 頁面設計
系統涉及的頁面不多,主要只展示關鍵的創建發送任務頁面。
發送任務是整個短信發送業務流程的關鍵頁面,有運營進行操作;頁面涉及發送時間設置、發送號碼設置、以及效果預覽等。
在頁面中增加了很多功能快捷入口保證整體流程的流暢性,提供短信預覽幫助用戶掌控效果。
4. 權限設計
因為我司已有權限系統,在我司權限系統中允許創建角色并分配權限,所以只需列出所需權限即可。
我司權限系統分為功能權限和數據權限,短信權限設計如下:
功能權限
數據權限
十、總結
這個項目總共花費了1個多月的時間,總體來說比較簡單,但這是我接手的第一個重構項目,還是遇到了我沒有想到的一些問題。
1. 沒有文檔
正如我前面提到的,原系統開發時科室還沒有專門的產品經理,完全由3個開發人員開發,在重構時原本3位開發人員已經走了一位后端,且沒有任何文檔,所以首先需要梳理老系統中的邏輯。
在一些業務流程方面可以通過使用梳理流程,但很多隱藏功能卻不容易發現,甚至原本的開發都不一定記得。
比如:原本短信內容敏感詞提醒、發送短信數量顯示是在整個短信在提交頁面時才顯示;原系統中還能加入邀請碼,邀請碼能夠在手機小程序上核銷等等。
2. 用戶習慣
雖然之前的系統功能不足以支持我司的業務,但已運行了兩年,且操作很簡單;而重構后的產品新加了很多功能,但操作方面比原系統復雜了很多。
尤其是我司的銷售公司、代理商、門店人員操作電腦的水平不一,在新系統上線后需要解決的后續問題還有很多。
用戶會對重構后的系統抱有很大的期待,而且用戶不會希望工具類產品只發揮工具的作用,他們實際上想要的是一套方案。
3. 重構后做什么不做什么
原本原系統重構就是因為功能無法支持我司短信業務的擴展,所以新增需求是肯定的;在調研階段參考很多文本短信系統和與業務人員溝通后,手中就會有一堆功能點和需求,這個時候一定要區分哪些是系統所需要的。
而且必須要考慮公司與運營商合作的深度,不能照搬競品的功能。
比如說很多短信系統中有號碼黑名單的管理,但我司拿不到每個號碼發送情況的數據,所以雖然黑名單功能有必要但也只能之后考慮。
本文由 @遙遙愛嘮叨 原創發布于人人都是產品經理,未經作者許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
請問第一個圖是用什么工具畫的呢?
很完整的項目經歷,寫得很系統
剛規劃完一個重構,這輩子以后都不會重構的,寧愿從零開始做也不重構