以電力系統為例：如何構建大中型系統

在我們使用的互聯網產品中，除了日常使用較多的電商、支付、娛樂等產品外，還有一部分產品給我們提供日常服務的產品，比較常見：電力、燃氣、社保、12360等相關政府提供服務的基礎系統。

這些系統日常中使用頻率很低，如果需要使用也是通過支付寶或者微信提供第三方入口可以直接進入，完成自己需要辦理業務和服務。雖然其使用率低，但是作為國民經濟發展一部分是不可或缺的。

本文將以電力系統為例，主要為電力指揮系統、電能質量配電系統等（具體可查看百度百科解釋），在對於這種大中型系統構建中所涉及的需求、項目、開發、人員配置等互相交流學，主要是面向內部系統，文章中不會有任何資料透露。

首先：從項目的組成人員角色來開始，每個名稱根據不同項目組會有不同、一些會叫做需求、業務、或者是產品，但是不管叫什麼名稱，工作的基本內容一樣，就是需求收集進行整理。同時產出相關的需求方案，開會溝通和相關人員不斷進行細節方面溝通，並且組織需求評審，跟蹤一下對應的項目進度。

當然，項目組如果有項目經理這部分就可以交給項目經理了，自己則能全部負責產品層面的工作，像是產品基礎的細節像是需求評審、收集需求、出需求方案等將不在這裏展開。

接着簡單説一下對於大中型項目的人員會根據不同的小組進行配置，一個項目可能四五十個小組進行負責，不同小組開發、測試、產品、項目經理、這是人員標準配置。

其次：公用人員角色就是UI設計，他們是單獨的部門人一般也不會很多，像是運營、風控、審計、安全等這些都會根據不同的項目組進行統一配置。

還有一部分人員第三方提供服務的人員，如果項目涉及硬件部分每一個廠會有一個對應的負責人，他們也是必不可少的，那麼簡單的人員就是這些，整體的人員配置情況需要根據不同項目組進行編制。

最後：很多人不怎麼喜歡的溝通、開會，日常不是開會就是在開會的路上。一天早上九十點開始到晚上七八點中，會議不斷，各種會議需要進行參與，不參與你可能後面就不知道進度。

也許有一天突然找你要東西而你不知道情況，為了更好的避坑，所以開會還是要參與，主要會集中在項目的開始，工作日一般是前三天，密集的會議會不間斷。

這裏就是考察產品經理對於項目的緊急程度、合理性等安排統籌，將自己手頭上面事情能夠在最短時間內進行整理並且安排到具體實施人員，主要的就是開發人員，提前安排會保證產品的人身安全，不然後面突擊給開發任務，他們會原地爆炸。

大中型系統的涉及人員多、涉及業務複雜，所以開始前將對應人員和負責業務進行熟悉就好，但是也需要準備好對應的人員臨時更換人員，換一個小白，同時加上自己也是個小白，對於工作就不好推進，要儘量避免這種情況。

萬一遇上這種情況，那麼只能自己快速熟悉業務，對於人員眾多的大中型項目需要很多項目組進行配合，需要注意不同項目組之間可能對於系統會有交集。這時候需要提前溝通好負責任務，最好是對應功能細化，不然後面就是和稀泥，搞得這個項目進度延遲，很糟糕。

接着對不熟悉大中型項目，需要快速的瞭解一些專業名詞，整個項目有一些通用的名詞，這些名詞第一次聽到就需要了解，不然就像聽到加密的電報一樣。有些可能是專業名詞縮寫，有些是整個系統中人員默認的簡稱，不管是哪種，只要是聽到你想不明白就問相關人員詞語解釋，這樣會保證你能聽懂項目組在説什麼。

同時專業性較強的大中型項目需要去了解相關業務的邏輯，這些業務邏輯和市場上的業務完全不一樣，之前積累的互聯網經驗換到這種傳統大中型系統中一點用處沒有，這就需要有一定學習能力。

以上就是構建大中型系統最基礎的、需要掌握的要素，簡單總結就是：

1. 專業名詞需要了解
2. 多和不同項目組人員溝通
3. 開會要積極參與
4. 和開發溝通要到位
5. 任務安排要細

這些都是產品或者需求基本具備能力和水平，介紹完了項目組和人員的情況接下就是大中型系統的介紹。

一、多個系統組合

一個大中型系統可能拆分N多系統同時由多個系統進行組合，可見政企在便民服務中投入是不低的。

如果只是單純的瞭解一個系統是遠遠不夠，需要同時瞭解三個或者五個系統，這些系統也一樣都是大中型系統，可能A系統中a功能和B系統中d功能之間有着聯繫，也有可能數據是一樣或者數據庫表相互關聯，後期需求會面臨的是需要構建一個F系統，需要在已有的大中型系統進行拆分組合。

這樣就需要產品或者需求對於其他系統有一定了解，做好前期準備的工作，在項目開始時面對問題會有一定的瞭解，同時對於開發的提出問題能夠有很好的應對之策。

大中型系統的複雜程度其實在與多個系統功能相互關聯，多個功能穿插，其中最關鍵就是數據的問題，數據問題需要和不同的系統進行比對，不管是產品還是需求都會面臨自己寫sql校驗數據準確性，以及對應的數據表結構要自己去了解。

這些問題如果自己當初設計的就需要在接到不合理的需求時儘可能設計的合理，如果不是自己進行設計就需要首先進行業務的瞭解和熟悉，進而對於數據庫的表進行查看，保證開發有問題時能夠及時解決，因為開發會是臨時抽調過來，他們不瞭解具體業務和數據，這些需要產品和需求自己進行了解。

二、業務層級功能深

大中型系統在構建時候因涉及的人員較多、業務複雜會構建很深的層級，在每一個層級功能下面會掛着七八個相關子功能系統，同時這些子系統中數據來源會是其他幾個系統數據庫中提取數據。

對於這種層級很深的情況，就不要去看任何需求文檔和測試環境系統，最好是正式環境和測試一起看，同時需要相關開發人員多溝通，整理自己在使用中遇到的問題和不明白的地方，集中時間進行溝通。

很多細小的功能在大功能模塊下起到主要作用，同時這種功能會是很常用功能，有一些功能使用頻率不會很高，往往是這些不高的功能後期會展開二期、三期等。

對於大中型系統來説，實用性是較為關注的，相對UI界面設計這些則是關注點較低，這就是為什麼會在一個菜單下面掛着七八個子功能，同時擴展會在子功能中不定期修改、增加、刪除字段信息。

可能一個功能中的表單會在不同版本中出現好幾個，乍一看已經改變了，能夠加個字段解決問題就不會讓需求或者是產品在業務層面修改，這也是開發和產品共同默認的默契。

三、龐大的架構

大中型系統會由三個和五個系統構成，所以整體架構是一部分，單個系統架構是一部分，這兩部分架構構成一個整體系統。

不管是後期的維護還是開始新構建，都需要將這兩個架構整理明白，搞清楚業務的整體方向，這也是前期比較耗費精力的部分，需要不斷進行調整和溝通，需求方案調整次數會多。在整體架構中經過已經報備之後後期不會進行改動，在功能上面也需要根據相關資料貼合。

大中型系統會有兩種存在：一種是完全新開始構建；另一種是已經整體已經完成構建。

先來説新開始構建，需要在較短時間內將整體業務的系統部署到測試環境，同時進行演示，這裏會在演示環節進行修改和增加不少，很多大型項目就是從一個測試環境demo開始往裏增加功能需求，修改之前的需求進行構建，這裏不過多解釋相信很多有經驗產品自然會懂。

另一種已經存在就是從前面的描述開始進行後半部分，那就是不斷的修改和調整功能，增加大功能模塊和小功能模塊需要根據這個已經改過不知道合不合適的架構上面進行擴展，所以對於整體架構進行整體重構基本上不會出現。

四、維護更新

維護和更新的主要重點則是數據部分，對於功能在業務層面沒有大問題將基本上不會進行修改和更新。一個大中型項目在開始時就會分為簡單兩個步驟，第一步就是業務功能構建，第二部分就是數據。

在確定業務功能之後就會開始數據治理部分，後期對於每一個數據要達到一定的標準值，數據問題主要是新系統和老系統進行數據比對，在一定時間內數據沒有誤差，就可以完成項目的交付，但是還是要留一部分時間的過渡期。後期維護更新主要側重點是數據治理部分，對於業務層面的修改調整基本上不會有很多。

構建大中型系統需要的前期準備基本上就是以上內容，下一篇文章將介紹具體實施部分。

#專欄作家#

李杭，人人都是產品經理專欄作家。關注B端產品，擅長複雜的需求梳理，愛好將複雜難以理解的事物口語化。

本文原創發佈於人人都是產品經理。未經許可，禁止轉載

題圖來自 Unsplash，基於 CC0 協議