產品重構之旅回顧——“一場取精華、棄糟粕的產品革命”
如果產品的架構不良,或者業務的方向發生了變化,這時就需要對產品進行重構。本文作者在一次產品重構之旅中,收獲了一些經驗,有了飛速成長,遂將本次產品重構經歷和經驗進行分享,希望能給你帶來幫助。
文章導讀:
- 通常意義上講,一個產品為什么要重構?
- 我們團隊的產品為何要重構?
- 重構的目標是什么?
- 最終結果如何?
- 我是如何做的?
- 過程中遇到了哪些問題?分別是如何解決的?
- 收獲與成長
- 最后談一下 0-1與產品重構哪個難?哪個易?
這次產品重構之旅,是我在漫漫產品路上,接觸到的第一次關于“重構”的實踐,收獲了頗多經驗,個人也因此在這4個多月中,有了飛速的成長,遂將本次產品重構經歷和經驗進行分享,以期幫助到有類似“重構”任務或有著“重構困惑”的產品er們。
01 通常意義上講,一個產品為什么要重構?
先引用《業務中臺產品搭建指南:電商業務平臺全流程設計與實戰》一書中,作者關于重構的原因及必要性的解讀:
每個系統的誕生都源于業務需要,為了能夠支撐飛速發展的業務,很多時候我們需對多個方案進行一些妥協來贏取時間。方案的妥協往往會造成架構不良,只能滿足中短期需求,對于長期的延伸都有致命的傷害。
還有一種情況是業務的方向發生了變化或者融合,導致原有設計的結構需要進行重新設計調整。
如果把一個系統看作是一個人,那么人身體里面的骨骼、血肉就可以看作是系統的邏輯和技術架構,它們支撐著身體的穩定運行。而產品架構的邏輯和規則,則代表著這個人的精氣神和性格,一個人身體再好,精氣神如果不順暢,身體早晚也會出問題。
所以每次重構既是對這身體的血肉和骨骼進行大刀闊斧的改造外,也需要對它的精氣神和性格做重新的審視和定位。
結合我本次重構的經歷來看,無不印證了上述書中作者的觀點和看法。
1)我新加入的產品團隊,組建時間不算短不算長,一年左右,為了滿足團隊初期的生存和發展,會承接一些商業化項目,基本上都是定制的,因此在架構設計上,也僅最大程度上考慮了多個項目的復用性,沒有考慮“產品化”。
舉個架構不良的例子(真實例子):
團隊前臺產品(姑且叫做產品吧,實際是為幾個商業化項目建的業務應用系統)運轉用到的后臺系統有:采集系統、數據治理與融合系統、信源管理系統(現在重構后的名字,之前的產品名字與產品功能極度不符)、工單管理系統、掃描系統等等。
其中“信源管理系統”的定位是用于運營和管理各類信源數據的,即增刪改查和打各類標簽用的。但是,在給各個前臺應用使用數據時,卻僅將采集到的數據經過【AI模型】打標后,直接給到業務去用,完全沒有 采納“信源管理系統”的“運營管理成果”,信源管理系統用的數據與客戶業務系統用的數據,是兩份孤立的數據島嶼。
很顯然,這是極度不合理的業務架構設計。
如果不及早解決,任由這樣的態勢發展下去,很難想象團隊會在多久的將來,會因為這些問題“over”,幾個月?一年?——但可以明確預見的是:如果不解決這些問題,團隊的資源將永遠都不夠、團隊也將無法拓展更多新的業務,因為忙著修修補補每一個孤島上“零零散散的部件”。
2)團隊此前有一個標品,但是是試水的v0.1產品,只有1個在線系統,沒有產品需求文檔、沒有產品使用手冊、沒有技術設計文檔,也沒有什么人維護了。
02 我們團隊的產品為何進行重構?
讀完上面我舉的例子,換作任何一個產品經理/技術都不能忍受吧,鑒于那么多問題,所以我們需要重構。再總結一下,我們團隊的產品為何進行重構:
- 技術架構上有諸多問題,如后臺各系統邊界不清晰、數據是孤島、無標準化前臺產品等;
- 團隊此前標品沒有人運營維護了,且文檔資料缺失。
- 團隊核心業務發展的需要。需要整合幾個核心業務系統(為項目做的)為一個“一體化平臺”,重新進行產品定位、打造標品并持續迭代,并努力成為行業內標桿產品。
03 重構的目標是什么?
——棄糟粕、取精華,對產品重新定位。包括產品目標行業與目標客戶、產品形態、產品商業模式、產品價值主張的重新明確,產品架構和技術架構的重新調整和設計,以重塑產品的骨骼和血肉,讓產品恢復精氣神兒,讓產品可以解決客戶問題的同時為團隊“掙錢”。
本次產品重構的目標,是基于當時團隊的業務背景需要,分成了幾個階段,每個階段有著不同的目標:
- 階段一:重新明確產品定位,設計產品業務架構,整合三個不同的業務應用(但業務流程及業務邏輯基本相同)至一個“一體化平臺”中,共用一套后臺系統,通過各類權限配置為不同類型的客戶及用戶提供產品服務。
- 階段二:優化線上系統邏輯漏洞、功能優化完善,提高用戶使用體驗。
- 階段三:重新設計后臺產品架構,厘清各系統職責和邊界,并分版本分別重構有問題的后臺系統。
- 階段四:隨業務發展,再將各個系統中的一些功能模塊剝離出去,形成單個子系統運轉。
比如后續可將采集系統中的采集優先級判斷、采集狀態的管理從“采集系統”中剝離出去,形成“采集調度模塊”,而采集系統僅做采集的執行,這樣整體的業務邏輯就會清晰很多。
再比如將積分規則設置、積分分配、積分管理等從用戶管理中剝離出去,形成單獨的“積分管理系統”,這樣也會減輕用戶管理的負擔。
為什么這樣劃分產品重構的階段?
——在當時,我不能特別領悟為何要這樣劃分。只是按照老板的大致意思那樣去做了。
甚至現在,團隊研發在做后臺系統重構時還在說:“XXX后臺系統本就該優先重構,然后再重構前臺業務系統!現在都是反的~”
但真的是研發說的這樣嗎?
現在回過頭來看,我想我理解了按上述節奏和周期去劃分工作的原因:
1)為了維持團隊業務的生存和發展,所以需響應市場需求、響應客戶需求。
有市場需求了,有客戶需求了,就需要趕快出客戶用戶“可見的”東西(產品v1.0),后臺亂成怎么樣,客戶和用戶看不到。
2)為了占據客戶及用戶心智,所以要不斷打磨產品,讓用戶看得見我們的變化。
后臺不急著重構,原因是:在產品初期,占據客戶及用戶心智是很重要的,因此“俘獲用戶芳心的新功能” 與 后臺優化的需求相比,仍是“俘獲用戶芳心”的功能更重要。
3)等業務運轉起來,且用戶沒有其它顯著的使用問題后,再花時間和精力好好優化后臺系統。千萬要注意,后臺的優化升級,不能影響到線上正常使用。
如遇其它重構任務,該如何合理地安排每個階段的產品迭代工作呢?
——可以按照如下金字塔來執行(從底到頂):
(圖引自《業務中臺產品搭建指南:電商業務平臺全流程設計與實戰》一書,如有侵權,聯系刪除)
通俗一點概況就是:讓業務RUN起來->讓業務閉環->讓業務流程完善->提高用戶體驗->再拓展其它新的東西。
上面的這個做事情的優先級順序,同樣也適用于生活、學習。比如學跳舞這件事:
目標是——老師教一支新的舞蹈,本節課你要學會這支舞蹈,長期目標是:你要學會自己跳舞。
可以怎么去做呢?
step1:你首先要將老師教的新舞蹈中的難的部分學會;
step2:然后將完整的片段記住,要能完整地跳下來;
step3:然后再是完扣每一塊的動作,做得盡量標準;
step4:然后再是提高你跳舞的可觀賞性(比如表情管理?。┛紤]下臺下觀眾;
step5:然后再是學習新的動作。
04 最終結果如何?
歷時1個月,完成了階段一的目標。最終成果是:完成了團隊標品v1.0(網絡情報偵察一體化SaaS平臺)的構建,并重新明確了產品對外服務的模式、以及產品所服務的目標行業及目標客戶群體。
又歷時1個月,完成了階段二的目標。最終成果是:1個月內完成了2個大版本的迭代,在春節復工后,正式開放給客戶使用。
當前處于階段三(第4個月),即在重構和優化后臺的幾個系統/模塊,同時打磨客戶高頻使用的模塊中。目前平臺已經有數十個試用客戶以及十多個正式簽約客戶了。
05 我是怎樣做的?
這里分成這樣兩個大階段:重構0.1階段和重構1.x階段,來分別介紹我具體是如何做的。
1. 關于產品重構0.1階段
這個階段主要是:明確重構的產品的業務目標是什么。
——即解決誰在什么場景下的什么問題?——你打算用什么路徑去解決?計劃什么時候可以解決?
帶著這些問題,我開始行動了。
首先是與老板、與其它產品同事,溝通要一些產品資料進行學習和線上系統的親自體驗,目的是了解團隊以前的業務都有哪些,以及與老板溝通當下及未來的業務重點或目標是什么。(攻哪個細分市場?當然是帶著自己對行業的見解與老板談)
接著,大致掌握了團隊的業務及產品現狀、團隊及公司資源情況(技術人員情況等)以及產品未來的發力點(姑且認為方向正確,先入行再懂行)后,我開始著手調研目標市場、目標客戶需求,目的是加深對行業、對客戶的了解。
確認了目標行業、目標客戶后,結合目標行業及客戶的特點,制定產品對外服務的模式。像我們的產品,主要是有幾種對外服務模式:一是SaaS系統,二是人工服務(如寫輿情報告、人員調查報告等),三是數據服務。SaaS是產品對外服務的主要模式。
2. 關于產品重構1.0、2.0、3.0
這個階段產品定位、產品形態已基本明確,主要任務是:具體產品的規劃設計,包括業務模塊的劃分,產品架構設計以及每個版本功能模塊的設計。
在這個階段里,我是按照先搞前臺,后優化后臺的思路來進行的。
1)搞前臺,是要將3個系統(一個輿情系統,一個公安核查工具,一個開源數據監測系統)進行整合,整合為一個前臺應用,并通過各類權限配置為不同類客戶提供服務。
主要是怎樣做的?
先按照數據流向,梳理業務架構,并按不同的業務場景,劃分功能模塊。
接著,上手整合現有幾個系統,功能合并去重、原有功能優化、缺少功能新增,最大程度復用原來的頁面和接口,重點設計rabc(基于角色的訪問控制)部分。
2)v1.x版本已經上線,解決了“邁進市場第一步”的問題,但仍有很多問題和漏洞需要修復。
在這個階段,主要是修復系統的諸多邏輯不一致、邏輯漏洞、業務未閉環、功能不完善等問題。
我是怎樣做的??
邏輯漏洞第一優先級,邏輯不一致其次,業務閉環其次,最后優化不完善的功能。
注:邏輯漏洞問題應該在v1.0版本前解決掉,但因本產品推出時間緊迫,且初期僅開放給少量用戶使用,所以放在了1.1版本解決。
本產品的邏輯漏洞例子:模塊A和模塊B用到了同樣的“付費數據”查詢功能,但模塊A考慮了“扣除積分”,另一個模塊B不扣除積分,用戶完全可以“鉆空子”——這是由于之前模塊B的系統是私有化部署交付給客戶的,所以模塊B并沒有積分扣除邏輯。
3)x版本已經上線,在“邁進了市場第一步”基礎上,也積累了一部分用戶了,這個階段可以系統優化后臺架構了,同時兼顧前臺的優化。
在這個階段,系統的穩定性、良好的架構設計、系統的數據準確性&及時性&全面性(做數據服務的廠商需要視業務重心酌情考慮),將能夠幫助支撐更多用戶的使用,讓產品活的更久遠。
4)搞后臺,梳理出幾個必要的核心的后臺系統,明確它們的各自定位以及職責邊界,以及它們之間的交互關系(還是可以參照數據的流向思路來梳理)。
06 過程中遇到了哪些問題?分別是如何解決的?
整個重構過程對我來說挑戰極大。
一是我從來沒做過后臺,也從未參與設計過rabc模塊,SaaS系統當然也沒有設計過了。
二是我10月25日入職,在11月上旬就要考慮重構事情,新環境、新同事、新業務、新行業,對我來說處處是挑戰。
我是如何克服并解決的??
1)首先充分認識自己,對自己的不足與優勢重新認識,對知識盲區瘋狂查漏補缺。
我過往的優勢是:有較豐富的AI類產品設計經驗,以及可以很熟練地掌握產品規劃的一些方案論,如華為的“五看三定”等,同時有著非常強的學習能力,以及調研能力。
對不足的地方,進行知識的查漏補缺。
比如rabc是什么,不清楚。
——我就去網上、去和前同事溝通交流、去看書,以此來構建這塊相對完善的知識體系,然后才能上手設計我要負責的SaaS產品。
再比如,對團隊的業務及產品目標不是很明確。
——我就逮住機會,和老板溝通交流(了解核心業務是什么、核心客戶是誰),充分利用上班及空閑時間,親自上手體驗他們以前做的系統,并與相關同事請教,去了解每一個功能模塊設計的初衷是什么、解決的是什么業務問題,并提出自己的思考
再比如,對后臺的幾個系統的重構和優化,從來沒做過,大多系統沒有界面,看不見摸不著,一頭霧水。
——我就從數據流向開始梳理每個系統的作用和價值,然后搞清楚這幾個系統當前是怎么互相配合(它們的交互關系)支撐業務前臺運轉的,然后再和每一個系統的研發溝通交流系統的主要功能以及核心邏輯,然后再基于自己的思考,發現當前邏輯的不足,并據此提出優化需求。
2)對我效率提升最大的就是:按照五看三定框架進行調研和設計。
整理文檔,按照“五看三定”方法論(看趨勢、看客戶、看競品、看自身、看機會;定目標、定控制點、定路徑),來整理文檔,每一塊都由淺入深地去了解。
對于不是自己做的系統,唯一可以加深體驗和了解的就是(尤其是在沒有文檔資料的情況下):自己親自上手體驗,有必要可以寫一下操作手冊,以方便后續回顧。
07 收獲與成長
- 關于重構的實踐與審視。
- 關于SaaS的實踐與審視。
- 關于采集系統、運營管理后臺系統的實踐,以及系統前后臺架構的整體設計。
- 關于知識圖譜的實踐(還不是很深入,主要是圖譜可視化工具,以及簡單的本體關系)。
- 關于抽象化思維的鍛煉。
比如我們要管理10多類信源,每個頁面如果都要開發的話,需要開發10遍,而將問題轉化成提煉共性,去開發一個動態配置頁面,將變得靈活許多也方便拓展,主要工作變為抽象提煉共性以及業務流程的設計。
08 最后談一下 0-1與產品重構哪個難?哪個易?
談不上幸運的是:0-1(前兩年)和產品重構,我均經歷過。
從個人親身經歷感受來說,我認為產品重構相對難一些,難在于你要“填坑”、你要“擦屁股”、你要“復用”,不像0-1,你有很多發揮空間。
而不論是0-1還是產品重構,都需要你對行業、客戶、市場調研了解,產品重構若只是后臺系統的重構,不涉及面向目標客戶的重構,則不需要了解市場這些,但也要清楚業務邏輯和業務流程。
寫在最后
希望本文的內容,能夠對你有所幫助。
產品經理,說難也難,說易也易。不知道自己會在產品這條路上堅持多久,至少現在還算熱愛,期望每天都能比昨天的自己優秀一點,加油!產品er們共勉~~ :)
本文由 @南方碟道 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
文章中rabc,筆誤。應是rbac(Role-based access control)
在做新系統前,首先要明確:是否真的要做,不做行不行?
其次,在對舊系統和業務調研時,除了要深入業務調研流程,角色,規則等,還要考慮一線用戶的使用習慣,不能因為新系統做完了,用戶的使用成本增加了(尤其是企業內部用的更是如此)。我在重構的時候就沒有充分考慮到這種情況,以至于有用戶反饋,為什么老系統有,我們都用了很久了,新系統卻下掉了?這樣的一系列的問題
你已經成長很快了。