老系統重構中的隱祕角落

語言: CN / TW / HK

編輯導語:對於想要實現數字化轉型、提升業務處理效率、改變冗雜環節的傳統公司來說,系統重構也許是重要一環。不過老系統重構的過程中,總會遇到形形色色的問題。本篇文章裡,作者結合實際案例,對老系統重構過程中存在的隱祕問題做了梳理,一起來看一下。

老系統的重構對於一個傳統公司或者是已經經營了很多年的公司來說,是數字化、智慧化轉型的必經之路。

公司裡一般老系統走到了必須要重構的地步,說明該老系統在公司業務扭轉中是有很重要的作用的。但是往往老系統的重構是一件很讓產品研發團隊比較頭疼的事情,畢竟重構所涉及的反方面面太多,尤其是一些涉及到很多業務方工作扭轉的系統。

15年前的老系統介面截圖如下,供大家感受一下年代感:

一、重構背景

本人是從國內知名網際網路大廠跳槽去了一個國內較老的傳統IT公司,負責重構的老系統是公司在2005年研發出的一個類似erp系統,是.net開發的web系統,主要負責公司內部的一些檔案資產的上傳發布和存檔。

該老系統為什麼最終決定要重構?原因其實非常明瞭:

  1. 該老系統是公司在05年開發的系統,經過15年之久的“任職”已經在底層技術支援不能滿足研發人員對其正常的維護和迭代;
  2. 老系統的功能需求和互動體驗上不能滿足使用者的使用,甚至會導致使用者降低辦公效率;
  3. 就是很多高頻使用者對該老系統的“怨氣”極大,整理了60多頁的痛點PPT給到我們部門領導希望優化;

所以,經過和這些“怨氣”較深的使用者詳談後,我們發現很多系統背後的許可權劃分、資產、組織與使用者的關聯關係無邏輯可尋,及資產的資訊保安管控邏輯等很不清楚,就連高頻使用者也不清楚,因為他們並不知道這個15年的老系統的迭代更替的詳情,在公司內部也未找到相關歷史的需求資料。

二、重構覆盤

在新系統上線後其實暴露出很多問題,但是最終還是被認可的,只是整個專案組都是第一次重構這種老系統,會有些經驗不足。

關於整個專案確定到研發上線用時:9個月。

關於我們的研發團隊成員的基本情況:

  1. 產品:1.5個人力,我為owner,還有一個產品輔助;
  2. 設計:1個人力,因為設計資源緊缺,所以互動和UI各佔0.5個人力;
  3. 後端:3個人力,有2個人全部投入,另外來個人各投入0.5個人力,其中包含框架設計及所有後端開發人力;
  4. 前端:1個人力,全部投入;
  5. 測試:2個人力,全部投入;
  6. 翻譯:0.5個人力,由國際化翻譯部門支援。

關於重構目標達成情況:

  1. 技術項:優化技術支援,將底層技術微服務化及去x——完成;
  2. 產品項:挖掘現階段使用者的真實需求、刪減冗餘低頻功能、整合資訊及調整PAL庫資訊架構、根據公司安全部門規定重新定義資產密級和資產許可權劃分——基本完成;
  3. 設計項:優化使用者任務目標流程路徑,讓互動設計和介面資訊佈局與時俱進,提升PAL庫使用者體驗——基本完成。

三、系統重構的隱祕角落

本次我先不具體系統重構的過程,想先記錄下系統上線後的一些意外情況,因為,在系統重構的過程中除了人力上的緊張其他感覺沒有大的問題,但是在上線後,就發現在重構系統過程中有些是我們團隊沒有關注到的注意事項——靜靜的都在隱祕的角落裡!

首先,從技術角度來講:

1)資料同步這一塊,在新系統上線後經常會爆出歷史資料同步發生異常,比如資產的建立日期、資產的許可權範圍會出錯。

2)是因為老系統的資料庫和現在新系統的資料庫不同,沒辦法做實時同步,如果一定要做那就很費人力,所以這點影響到了使用者在新老系統切換時沒有過渡期,很多使用者在使用起來很不習慣(並且現公司是個傳統的IT公司,有很多老員對習慣的改變非常牴觸)。

其次,從產品角度來講:

1) 在產品重構的方案前期,應該要同步給到業務方及干係方的領導, 即便自己的領導沒有在高層內部同步本專案的事情,自己作為專案的owner也要提醒自己的領導。

這一點其實會很好地在高層建立一些理解和口碑;因為在系統重構後,其實或多或少地都會有使用者反饋一些負面資訊,同時,在新系統上線初期也是bug暴露最多的時期,如提前做好對干係方領導的資訊同步,他們就會更全面瞭解你們在研發中所遇到的一些問題,以及過程中的每一次重大產品決策,這其實能很好地幫助各方領導來理解你們重構的系統。

2)不能高估IT公司內部員工對新型網際網路的敏感度,在新系統上線前,一定要通過各種有效方式給大家做新系統的使用培訓,而且要盡最大努力做到培訓的全面性,避免使用者因使用習慣的改變而帶來的負面反饋。

3)有時間和精力一定要在前期做面對面的使用者訪談,比如我們在前期本來是要做使用者訪談的,訪談計劃、訪談使用者及出差城市都已經確定了,但是被領導叫停,原因則是覺得該系統的高頻使用人數不多,感覺也沒必要花時間和精力去做使用者訪談,於是這也成了很多使用者在使用不習慣的時候拿出來說事兒的“小辮子”了。

4)要實時跟進業務方答應的TODO事項是否落到實處,就拿我們的系統來說,公司的老系統其實是功能很龐大的,有不同的業務方在系統中上傳和釋出資產,有公司級的資產也有部門級的資產。

但是兩個不同權重的資產對許可權管控級別和管理人員的細分度都不同,事先,管理公司級的資產使用者是不希望部門級的資產使用者再使用本系統,建議他們使用公司內部的另一個可替代的老系統(但是誰會願意用老系統呢)。

但是這個事情主要是得這兩方的使用者或相關領導去協商好的問題,但是相關干係人並沒有重點關注這件事情,最終也導致了兩方業務方各種撕,同時作為產品研發團隊的我們夾在中間其實也是很難受的。

所以實時跟進事先安排給業務方的TODO任務,清楚他們對接的進展也是產品研發團隊所要關注的事情,不然就是兩狗打架粘你一身毛。

5)要將老系統所有的功能點,以及存在的問題都整理出來告知全公司的使用者,不然總有一些噴子會說老系統可以什麼什麼(其實沒有),或者說老系統許可權如何合理(其實是老系統的bug漏洞),還有甚者會說老系統的互動視覺好看的~

總之就是意想不到的的事情太多,想要堵住使用者的嘴是不可能的,但是可以提前準備好有力的回懟材料。

注:由於系統有水印,所以不便於給大家展示最新系統成果了,抱歉!

四、總結

B端產品的產品邏輯往往是比較複雜的,涉及的使用者角色也很多,但是這些往往在產品重構的過程中,只要使用正確的產品研發方法,都不會出大問題。

但是正因為是B端產品,所以很多領導在思想上就不太重視,因為做出來用不用公司內部員工往往是沒有選擇的,但是作為有追求的產品人,還是要避免“強權研發”產品。

同時一個系統的重構是一個很繁瑣的過程,不同的產品及公司級團隊所面臨的的問題是千差萬別的。

但是,除了關注產品本身的需求功能、技術、體驗問題外,還有一些看起來不太起眼的的各部門同步問題、涉及干係方的意見達成問題等和產品本身關係不大的細節也要注意。

最後的最後我想說,系統重構這種中事情遇到了的確令人下頭,但是這種機會也不是所有產品人都能遇到的經歷,所以,只要大家遇到了系統重構的機會,還是大膽上吧!

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

題圖來自Pexels,基於CC0協議