3歲產品經理關於重構系統的心路歷程

編輯導語:本文將以3歲產品經理的視角,針對作者經歷過的某系統的重構過程,展開一次心路歷程的梳理和分享。從無到1。0版本的上線,從不知如何下手到那就衝吧……

3歲產品經理關於重構系統的心路歷程

一、專案概況介紹

本次重構的系統是“計費系統”,顧名思義是用來計算費用或者計算數量的系統,此係統的定位是根據客戶請求資料產品的介面情況來完成計算客戶賬單的流程。

這裡具體是哪個系統不重要,換個別的系統都一樣樣的,除此之外,要完成出賬單的任務,需要諸多指令碼在背後支撐,這部分屬於技術層面的工作,本文不做過多的闡述。

二、重構原因

1. 客戶計費需求光怪陸離

簡單來說,客戶想要的計費需求如今是千奇百怪,亦或是公司的商務為了能夠給客戶創造一些讓利空間,研究出了一些奇特的計費想法,然而當前的系統並不能夠非常靈活且快速地滿足這類需求,所以一部分特殊計費的要求都是人工透過臨時寫一些sql語句或者定製化的指令碼來實現的。

但是這種解決方案顯然不夠高效且風險性較高;另一方面,公司想把這部分的業務管理的更加規範化,進而提出讓我們必須透過系統化的功能來實現特殊計費業務的要求。

2. 祖傳程式碼表結構設計不夠合理

原計費系統當初了趕專案進度,在底層架構設計以及表結構設計上不夠合理,這就導致後期的改造成本和維護成本都比較高,經常是研發人員一邊吐槽一邊改,所以既然業務方有新的需求,剛好基於這次機會將程式碼進行重構,也便於經後的管理。

3. 合適的契機更換計費指令碼

說起這個原因,其實也是為了間接性地解決另外一個問題,那就是當前採用跑賬單資料的是shell指令碼,研發人員對於shell指令碼不是特別擅長,並且在我們使用過程中shell指令碼報錯頻率有些高,導致我們的賬單資料會存在計費不夠完全準確的情況。

其實很早之前就想過替換成spark指令碼,但是替換指令碼這件事事關重大,且日常的業務需求的開發任務也非常重,此問題一直沒能得到解決,說到這裡作為產品經理的我也有些慚愧,應該更早地為這個問題爭取時間和資源,好在這次終於有了這樣一個時機去解決,也算是抓住機會去改變吧。

在跟業務方多次溝通後,最終確認了透過開發新系統-結算平臺來解決當下的問題,在這之前我們確實是在“改造原計費系統”還是“開發新系統”中進行衡量和抉擇,考慮的因素無非是時間成本和開發成本。

二者的優劣也很明顯,如果是改造原系統,可以直接開始新需求的開發工作,必然是最快且成本最低的方式,但同時會錯失重構的機會,業務方也不會給比較長的時間來讓我們有時間做重構的工作;如果是打算從頭開始做新系統,當然需要的資源較多、耗時較長,但是這樣就能夠把整個系統的架構進行重新設計,從長遠來看自然是件好事。

三、專案整體規劃

既然確定了以新系統的方式來完成此次任務,

那在最開始產品經理需要規劃好專案整體的一個排期進度

。在確定排期前,首先要明確以下幾點:

1. 重構內容包含哪些?

當前系統主流程業務中哪些邏輯和功能需要調整

原有的哪些表結構設計需要調整

與其他的系統之間的互動是否需要調整

新舊系統在並行期間的資料該如何處理

新業務新功能的設計方案

在梳理這塊內容時,產品經理需要認真仔細的確認清楚當前系統中每個功能點,是否需要進行調整,

最好是將原有功能列出一個比較完整的清單

,這樣不易於遺漏一些小的功能點的改造,若是需要調整,則在清單內標註好方便後續的跟蹤。

而我本人在進行這項工作時,疏忽了這點,可能是覺得對於原系統過於瞭解,就想當然的以為這些點都在腦子裡,這就導致在開需求評審時,發現遺漏了細節,好在研發人員是比較熟悉系統的,能夠及時補充避免了一些問題。

2. 優先順序排序如何確定?

確定了原有功能需要改造的內容後,接下來需要考慮此次在新系統中的要實現的新增的功能與原功能在開發中的優先順序排序。

這一點蠻重要的,因為不一定要先把原功能全部開發完之後再進行新功能,當然對於本次重構的系統而言,新功能的使用是強依賴於一部分原功能的。

沒錯,只是強依賴於一部分原有功能,也就意味著我們並非需要在最後階段在開始新功能的開發。

我為什麼會提到這一點,因為這一點對於整體的排期優先順序的順序影響比較大。

大家可以想想,在我們實際工作中其實開發時間是非常緊張的,而我們的需求方也是急於看到一些成果的,原有功能的重構自然不是他們最關心的點,所以我們也要比較聰明地把重要的東西往前提。

也就是說當我們的把必須的原有的主流程開發完後,就直接上手開始新功能,這樣能夠把需求方最想看到的東西儘可能早點完成,那剩下的其餘功能我們就按照正常的系統迭代節奏進行即可,否則,很可能一直處於被需求方催進度的被動狀態。因此重構過程中的優先順序排序是需要好好考慮的事情。

3. 開發任務該如何拆解呢?

總體的優先順序確認後,我們需要將開發任務進行拆解

。在此過程中可以先按照階段拆解,明確每一階段的主要目標是什麼,進而就能知道在這一階段中需要完成哪些開發任務。

而一個階段內的開發任務也需要進一步拆解,此時可以根據功能模組劃分,比如一個選單欄內包含了列表展示、詳情展示、編輯、匯出以及一系列的子功能,我們也需要定義一個優先順序,決定先做哪些子功能。

最後就是將劃分好的各階段確定出開發完成時間,也就是提測時間,進而排期成多個版本進行分批上線,以上的過程是需要產品和研發共同敲定的,至於上線時間需要同測試人員一起進行評估。

3歲產品經理關於重構系統的心路歷程

圖為本人當時繪製的排期表,可適當參考

四、敲定新功能的設計方案

前面已經提到過了,本次系統的重構主要分為了兩部分,原有功能的重新搭建和開發新功能支援新的業務需求。

後半部分才是這次重構工作中最重要的內容,也是“業務方爸爸們”最在意的工作,但在實際工作中,我們是先敲定了新功能的業務需求和實現方案,再考慮新系統的整體規劃方案的,那這裡也由此可見我上面所提到的排期時考慮功能優先順序的重要性。

關於新功能的設計方案,這裡不會展開來講,原因也很簡單,此方案是根據公司的實際業務情況出發和落腳的,因此非常定製化。

那我想說的其實是另外一點,產品經理在設計新方案時,

不僅僅是需要站在支援業務實現系統化的層面,還要考慮高層領導想要達成的其他潛在目標

比如,管理制者之所以發起這樣的新專案,一方面是為了提高運整體的運營的效率,另一方面呢的其實是想降低研發人員替換時所產生的較高的替換成本,因為當前系統在支援業務工作時,有很多場景是需要研發人員臨時寫sql來獲取結果的,這樣的工作對人的依賴性很大,一旦出現人員變動,對業務的工作影響是比較大的。

如果一開始沒有想到這一點,那麼可能就會像我一樣,在設計功能時會忽略掉一些點,導致方案被一否再否,經過了多次的調整才得到了業務和領導層一致的透過。

五、專案進度跟蹤

當進入了實際的產品開發階段後,

產品經理需要時刻關注和跟蹤專案進度

,這樣可及時發現是否有延期風險。

根據排期規劃我們拆分出了4個階段的上線版本,大概歷時4個月,涉及3。5個後端人員和1個前端人員。同時我針對每一階段的版本拆分出了每個研發人員按周的計劃進度,每到週四下午我會與每個人確認本週的實際進度,是否可以按時完成,若是有其他原因導致延誤,則需要立馬定原因,解決延期問題,同時也要提防是否還會出現相同的狀況。

3歲產品經理關於重構系統的心路歷程

圖為本人當時繪製的進度跟蹤表,比較粗簡可適當參考

那實際中呢,我確實也犯了一些小錯誤,在最開始我們確定了一期的開發任務後,自認為大家都沒有反饋問題那就是沒有問題,因此在進入開發後的第一週我也就沒有過多的關心進度情況,等到第二週時發現原定的進度已經不能再透過趕工的方式來彌補了,結果就只能是延期提測了三天。

好在及時跟測試人員進行了溝通,壓縮了測試時間,這才能夠在既定日期完成一期上線。當然這裡也不提倡透過壓縮測試時間來達到目標,只是一期上線功能較少,原評估的測試時間較長,確實是有可壓縮的空間,才解決了延期問題。

六、第一階段1。0。0版本上線

與大多數網際網路公司一樣,上線日是週二和週四,第一期的版本我們定的是週四,原本像這樣的新系統,通常是可以不用等晚上再推包上線的,可是我們還是拖到了晚上7點多才開始準備上線。

也正如預想的一樣,新系統上線問題百出,大概的原因主要是測試環境和生產環境配置不相同,以及又遇到了sre資源佔用等問題,最後的結果就是直到晚上23:30左右才在生產環境部署成功。

那針對這一次的上線問題,我們下來也進行了

覆盤

,從產品角度來看的話,當時確實是在上線驗收前,我發現了一些問題,並且花了較多的時間進行了再次測試驗證,結果是問題確實存在,但這也就直接導致直到晚上7點左右才開始推包。

其實針對這樣的狀況,在我看來產品經理可以果斷一點,那就是帶著問題先上線,因為第一期的上線,也並不會對外開放使用,主要是為了先跑通正式環境,如果是這樣的話那天就不用熬到快12點了,這也是我這次學到的一次教訓。

那另外一點經驗教訓是

,像這樣的新系統上線,其實可以先預上線一次,就是在原定的上線日的時間,提前一個上線日先“預熱”一次,主要是解決環境部署或者預發和生產配置不一致等問題,等到正式上線就能避免這些問題。

3歲產品經理關於重構系統的心路歷程

圖為與研發和測試覆盤會議的總部,可適當參考

七、寫到最後的小想法

如果對本次的重構工作進行個自我打分的話,我確實是不太滿意的,只能給自己打6分,也就是剛及格的狀態,這裡主要有幾點原因:

第一呢,我覺得自己還是過於保守不夠勇敢。

主要體現在不太敢於打破原來的一些邏輯和設計,在原有功能方面還是儘可能在“復刻”,一方面是出於使用者習慣的考慮,另一方面是害怕如果進行改變帶來的不確定的影響範圍。

這可能與我本人的一些工作習慣和方式相關,更傾向於謹慎地完成工作,當然這一點也並非是完全有問題的,因為我確實需要考慮上面提到兩個因素,但是也不應該就真的被嚇住了。

假設下如果真的敢於突破,出了一些問題,又會怎樣呢?影響範圍和程度又會有多大呢?完全不可控了嗎?其實實際上可能就真的還好,大不了被多罵幾遍再改回去嘛,只要能掌控住風險大小,那就衝一把嘛~

第二呢,重構前的產品準備工作做的不夠充分。

也是體現在兩方面,自身角度沒能更加深入的去思考這次重構怎樣能讓系統和業務結合的更加順暢和緊密,更像是火急火燎、慌慌張張的去完成一項緊急且重要的工作任務,“交好這個差”。

再就是前期的調研應該多花時間做做,而實際中這塊確實被忽略了,如果說調研做的比較充分,前面沒能深入思考的問題可能就迎刃而解了。

第三呢,產品經理爭取資源和時間的能力真的也是需要好好培養和鍛鍊的。

客觀來講,當時在接到重構系統任務時,我同時在負責另外一個龐大複雜的賬務系統,日常的需求任務非常重,也是我們部門最核心的系統之一,單就負責這一個系統的時候我都蠻心力交瘁的。

所以這個時候公司讓你同時負責多個系統時,要是沒有很好的爭取資源和時間的能力,估計就會像我一樣,吭哧吭哧自己加班幹活,兩邊都不敢耽誤。雖然最後也能完成得讓業務方和領導層基本滿意,但是學到的東西就比較粗淺也很累人。

最後呢,希望以上的分享能給各位產品經理多多少少帶來一起啟發或者思考,能吸取我的一些經驗教訓,在產品路上大步前行不要慫!

本文由 @Joysaver???? 原創釋出於人人都是產品經理,未經許可,禁止轉載

題圖來自 Unsplash,基於 CC0 協議

頂部