重構 10 年曆史的 B 端產品,我的一些經驗體會

編輯導語:不管是剛剛入職的小夥伴還是已經入職工作很久的小夥伴,在重構系統的時候都應該會有一些問題,在本文中,作者總結了他的工作經驗,分析瞭如何在舊系統上進行升級的方法,一起來看看。

重構 10 年曆史的 B 端產品,我的一些經驗體會

我目前在一家傳統醫療企業,為實現資訊化轉型,領導期望將使用多年的舊系統進行升級。因系統擴充套件性不高,只能推翻重做。我司和德勤有戰略合作,所以請他們團隊來協助重構系統。

在重構的過程中,我在德勤的需求分析師身上學到了很多做事方法,受益匪淺。因此,把這個關於重構系統的例項分享出來,希望對大家有啟發。

一、重構老系統我們碰到的三大問題

1. 資訊架構混亂且重複,業務流程複雜且不合理

早期的系統沒有專門的產品經理規劃,一味圖快,有需求就加功能,留下了非常多問題。比如:

流程複雜

:舊系統存在非常多的不必要流程,導致使用者為了達成業務目標,經常要在系統裡操作多次,這嚴重影響實際工作效率。

展示覆雜

:現在的系統包含 900 多個頁面,頁面之間的重複度高。本可將資訊整合為一個頁面,實際卻用多個頁面展示。有的頁面有 50-60 個按鈕,且每個按鈕都會觸發不一樣的場景。

培訓難度大

:使用者很容易忘記功能的作用和操作順序,導致學習成本巨大。經調研,剛入職的同事要熟練使用系統,一般要 2-3 個月。

2. 缺少需求、設計文件

舊系統沒有完整的需求說明文件,概要設計,更不用說詳細設計了。文件更新不連貫,最新的文件還是幾年以前的,這幾年新增的業務功能則完全沒有記錄。且文件內容都非常簡單,無法呈現完整的業務流程和核心細節,很多地方都是簡單帶過。

3. 沒有人瞭解系統全部功能

文件不全,我們還寄希望於有“活文件”,但是這個希望也落空了。老系統的使用角色有近 20 個,因為功能複雜,每種角色只會操作跟自己業務相關的幾個頁面,但也只瞭解主流程,對於細節部分還是模稜兩可。

系統運行了 10 多年,一直有開發工程師在維護。但因為公司人員不斷有變動,文件、交接程式都不完善和規範,經過幾手傳遞,公司內沒有一個人瞭解系統全部功能。

二、面對挑戰必須要有整體且細緻的規劃

情況就是這麼個情況,挑戰非常巨大。

經驗尚淺的產品經理面對這種場景,可能會急於動手,在還沒有思考清楚工作流程的時候,就直接研究系統功能,看舊系統如何設計,然後在這基礎上做部分最佳化。但是這種工作方式並沒有大局觀,只知道要做但不知道要做哪些,且需求梳理完的截止時間也不確定,無疑不利於整個專案的落地。

有一陣子,工作進入了停滯期,一時找不到入手點,不知該如何處理工作。後來,在德勤的協助下,我們並沒有著急開始動手,而是先思考再做!

在動手前會認真討論和思考怎麼做更有效率,並且能達到一個最好的效果。畢竟我們不可能花幾年時間才把需求全部整理出來,到時候競爭公司早走在前面了。

以下是我們後來的規劃方案:

1. 確定工作的目標,範圍,截止時間

首先就是確定工作的目標,範圍,截止時間。

目標已經很明確,就是需要把需求全都整理一遍,然後重新進行產品設計。而工作的範圍即梳理全量需求:系統裡的功能都需要我們全部梳理。截止時間我們是倒推的,因為新系統計劃年底上線,所以需求梳理的時間要早於上線幾個月。開始動工前,梳理這三個事項非常重要。梳理完還要和領導做同步和確認,這樣才能明確工作方向和重心。

2. 量化需求梳理工作

確定第一步的內容後,第二步是對接下來的工作進行量化。

安排幾個同事把系統的所有選單都用 Excel 整理出來,包括一級選單,二級選單,三級選單等,最後統計下來有 900+ 頁面。

為什麼只按頁面統計,不按功能統計呢?因為涉及頁面太多,有的頁面功能甚至高達 100+ 個,如果按功能整理就需要花費大量時間,但我們得嚴格控制需求梳理的進度。且我們對功能不瞭解,也不瞭解實際的業務含義,所以前期整理的顆粒度就僅僅按照頁面劃分。

重構 10 年曆史的 B 端產品,我的一些經驗體會

Excel-V0。1

有的夥伴可能會有疑問:為什麼需要列一個這樣的Excel表格去整理頁面選單呢?對於後臺產品,前期不應該直接進行業務調研嗎?

因為這是個重構系統的專案,上層領導只知道要重構,卻並不知道重構的難度有多少。前期制定的系統梳理至上線時間為 6 個月。但梳理完以後,我們對工作量和工作難度有了新的認知,6 個月是絕對完成不了的。

有了這樣的梳理和量化的結果,我們和領導彙報工作難度並且調整重構時間為 12 個月。

3. 確定頁面梳理優先順序

完成第2步的量化工作,我們是不是就開始著手梳理這 900+ 頁面了?

不,這還不夠,還得深挖!

梳理那些沒人用的頁面,根本就是浪費時間。我們要搞清楚使用者到底常用哪些頁面,壓根不用的頁面就不梳理。於是,我們繼續梳理頁面優先順序。將之前整理的頁面選單Excel的列後,再加上目前主要使用系統的各大使用者組。

使用者組是由業務負責人提供,大概有近20個使用者組,每個使用者組都有對應組長。所以,我們前期就和各大業務組組長進行溝通,逐個詢問當前所有頁面的使用情況,是否使用以及使用的頻率。

重構 10 年曆史的 B 端產品,我的一些經驗體會

Excel-V0。2

統計下來:高頻使用的頁面有200+,中頻使用有100+,低頻使用100+,幾乎不用頁面 500+。

不過,業務發生頻率和需求優先順序還有一定區分,經常使用的頁面肯定是需要優先梳理的,但業務不經常使用的頁面不一定優先順序低。因為低頻使用的頁面,可能也會涉及到一些核心流程的流轉。不過不要緊,深入調研的時候去了解詳情即可,初期階段就優先梳理把高頻使用的頁面的需求。

4. 進行需求梳理

需求梳理我們大概分為三步:需求調研,需求梳理,需求分析。

4.1 如何進行需求調研

前期業務負責人給我們提供了15個使用者組的組長資源,於是我們就以使用者組作為突破口,採取線下逐個調研使用者組的方式來了解需求。

因為不同使用者組在系統中都承擔著各自的職能,所以我們只要滿足各個使用者組的核心需求,那麼整個系統就相當於是調研成功了。

調研前:我們會在舊系統看該使用者組的主要使用頁面,根據頁面大概瞭解使用者組的特徵;與此同時也會準備自己不明白的問題。

調研時:整個系統的功能特別複雜,在調研時對調研人員也進行了一定的責任安排。

每場使用者調研下,都有一位同事負責瞭解主流程,一位負責瞭解異常流程,一位負責做筆記/錄音,一位負責技術評估等。

那調研為什麼要以主要流程和異常流程來進行劃分呢?主要流程是支撐使用者組的正常職能操作,調研必不可少;但異常流程也十分重要。我們做需求梳理的時候肯定也是要把這些異常場景考慮上,需要給使用者提供一些撤銷的功能來結束整個流程。

調研的方式為在使用者的工作區域進行現場訪談。因為涉及流程性的環節我們需要結合線下使用者的實際操作才會理解更深,避免出現大的偏差。

調研後:前期對調研人員有了具體安排,那調研後也就需要有對應輸出。

在此階段我們主要輸出的文件為:

主要流程圖,異常流程圖,使用者訪談記錄。

重構 10 年曆史的 B 端產品,我的一些經驗體會

流程圖例

4.2 如何進行需求梳理

因使用者組老師工作繁忙,不可能把每個需求以及舊系統對應的功能一一描述給產品經理。所以,我們採取的工作方式是,根據上述產出的某使用者組主要流程圖和異常流程圖,再把該使用者組使用頻率高的頁面和流程圖中的節點一一匹配。

這樣就可以知道目前該使用者組為實現自己的主要目標的過程中,在系統上有哪些操作。

還需要明確一點,需求調研是一個反覆的過程,不可能每個使用者組只調研一次即可。我們調研的整體思路還是採用先整體後細節的邏輯。

先整體:第一次調研瞭解使用者組的主體流程和異常流程,再與舊系統頁面做對應;後細節:後幾次調研才開始瞭解頁面上的其他場景和細節。

4.3 如何進行需求分析

對於使用了舊系統近10年的使用者而言,他們對自己想要什麼、不想要什麼已經非常明確,而我們產品經理只需要能理解使用者的核心需求並作出最佳化設計就可以了。

但即使是這樣,我們還是會把使用者的需求用”使用者故事”的邏輯來理解。即,使用者故事=使用者+故事=人+事+故:誰要使用這個(角色),要完成什麼活動(活動),為什麼要這麼做,這樣做帶來的價值是什麼(價值)。

我們不是需求的搬運工,我們在刻意瞭解需求意義,進行需求分析之後,才開始進行產品設計。

5. 分配需求梳理工作

組裡的產品經理有 7 位,完全前幾步,接下來就是分配具體的任務了。

我們決定以使用者組的維度來進行分配任務,但這也並不是隨意去分配,在分配的時候還要考慮各方因素。

前期在對使用者組調研的時候,已經大概瞭解了對應的難易程度。於是再根據現有產品經理工作年限以及興趣的情況,進行分配任務。

比如一個產品經理,可以分配2個困難模組,3個較簡單模組;比如剛來且工作經驗不足的產品經理可以先分配些簡單的模組去熟悉,然後逐步開始進入深層次的協作;還有對於難度較大的模組,可以讓多人共同協作。

如此一來,整體團隊的工作任務就已經分配得當,大家就領好自己的任務專注執行即可。

6. 整體監控

當產品模組都分配下去後,還需要計劃需求梳理時間,即每個模組梳理的時間截點;

還要定期詢問各位產品經理的工作情況,是否按時進行,是否遇到問題,是否需要協助等。

經常跟進進度,監控整體進度,也讓整個團隊的目標都在按照計劃的日期如期開展。

我們只有先有條理的規劃,然後一步一步執行,這樣才能順利完成任務。

三、我的感悟

跨進網際網路做產品經理的那一刻,我便暗暗下定決心,要成為一名優秀的產品經理。

轉眼 3 年多了過去了,我在這期間看了不少產品經理的書籍,也系統地學了不少產品知識。

如果問我產品經理最重要的能力是什麼?我會毫不猶豫的說,

解決問題的能力。

1. 解決問題,需要系統思考

在我看來,任何一個職業都是在不斷髮現問題和解決問題,產品經理亦是如此。

但即使是同樣一個問題,換作不同的人處理,事情的完成效果也會不一樣。總有些人更快些,效率高些,處理的更恰當些。

那這種能力如何去培養呢?

其實最關鍵的一點就是需要平時積極思考,不斷的去總結和覆盤。

對於一些複雜的工作,經過總結下來,其實可以形成一套SOP流程(標準作業程式)。

比如:

先量化工作,再做任務拆分,排出任務的優先順序,然後任務分配到人,設定任務截止時間,最後整體監控。

2. 在錯誤中成長,多覆盤,多交流

在工作中會處理很多事情,但並不見得你每次處理事情的方式就是絕對完美的。而當我們覆盤時,就好像把整件事情的經過像電影一樣重新放映。

在重溫的過程中,不斷思考,這樣的事情是否還會有一種更好的方式去解決?如果有,那又是什麼。那當下次你再遇到這樣的事情時,你就會用一種更好的方式去處理。

如果想不明白也可以請教自己的領導,看看領導給的建議;或者繼續問產品社群的同僚們,看看他們是不是也遇到過類似問題,又是怎麼解決。

產品經理需要的能力其實還有很多。“人人都是產品經理”,但不代表著“人人都是好的產品經理”。一個好產品的背後總有一些優秀的產品經理在默默付出努力。

本文由 @炸草少女 原創釋出於人人都是產品經理,未經作者許可,禁止轉載。

題圖來自Unsplash,基於 CC0 協議

頂部