在阿里當PM都須要作什麼？Bella醬親身經歷告訴你！

有人說「一塊兒在湖邊吹過晚風的人，會記得更久一些吧」，那一塊兒住過院的人，是否是能夠刻骨銘心了？以前就想寫篇文章總結一下本身前段時間當PM的經歷呢，奈何發佈了這個需求，還有另一個需求要發佈，週末稍微有點時間了，又想睡覺續命，個人懶癌就又犯了:(哇哇，我也只是個孩子呀，咳咳，阿姨言歸正傳，因此因此，一拖再拖，直到在醫院的這幾天。

每個項目作完，或者跳出了一個溫馨區，仍是要自我總結覆盤下的，不是麼？一來以一個局外人的身份，系統地看待下本身所作的這個事情，二則爲本身之後回顧這段時光提供一些素材，否則，說不定之後本身會忘記呢~

如下來源於Bella醬在阿里當PM的經歷的總結，若有不當，歡迎批評指正~

1.項目立項

作一個項目以前，你要清楚爲什麼要作這個項目，這個項目的價值和意義在哪裏？若是是現有版本的大升級，那你還須要清晰的知道目前版本存在哪些問題，痛點是什麼，擴展性如何，可維護性如何等等。同時還要肯定升級後的版本的目標，只有目標肯定了，後面技術方案選型的時候，你纔會知道應該選取哪一種技術方案，由於你選的技術方案，要能足夠實現你的目標。

對於中臺項目而言，還要考慮2個問題，即兼容性和差別性。所謂的差別性，即指升級後的版本是否能夠無縫兼容新接入一個行業？接入成本有多高？是否能夠把一部分接入工做交由產品 or 運營同窗來作，解放一部分技術同窗勞動力？所謂差別性，即指升級後的版本是否能夠支持不一樣行業間存在的差別，是否能夠作到相互隔離，互不影響。

通常狀況下，我會選擇用思惟導圖來表達這些信息，圖每每會比文字更簡明直觀一些，TL們的接受度也更高一些。

2.技術預研

這一階段的主要目的就是基於上一階段肯定的目標，調研哪些技術能夠支撐你實現這個目標，這些技術理論上的可行可否最準轉變爲落地上的可行，能夠拿當前業務場景以及數據作一個推演，數據推演ok以後，能夠再作一個小的能夠運行的demo，以證實該技術真正能夠用在此項目中。

此階段須要產出各個技術選型的數據推演圖，若是推演過程比較複雜的話，也能夠考慮再產出一份比較詳細的Excel樣式的數據推演圖，每個步驟數據如何變化都要體現出來。另外，還須要產出各個技術選型可運行的demo。最後，須要產出各類技術選型的對比，表格形式或思惟導圖形式均可以，切忌純文字。基於上述對比，肯定最終的技術選型，而後就能夠開始技術方案的編寫啦~

3.技術方案編寫

私覺得技術方案應該包含如下幾部分，業務背景、場景分析、系統架構、應用架構、系統流程圖、領域模型設計、存儲模型設計、全局可用定義、功能模塊設計、接口定義、項目里程碑等等，若是是須要出海的項目，還須要考慮下本地化方式、時區偏移、部署方式等等。

3.1 業務背景

業務背景主要是交代下作這個項目的背景，即爲何要作這個項目，基於一個什麼樣的業務背景，也能夠把【1.項目立項】中畫的思惟導圖直接放在這一pa。

3.2 場景分析

場景分析則主要是講這個系統有哪些應用場景，若是可以列舉出業務方的真實訴求，那是最好不過了。然而大多數程序員的生活，並不會直接對接業務方同窗，而是對接產品經理。

3.3 系統架構

系統架構推薦以圖的方式來展現。開局一張圖，剩下全靠講，也不是不能夠哈。Bella醬就有過這種經歷，開局我放了一張圖，而後看着大佬們講了3個多小時。佩服佩服，那次經歷也讓我懂得，表達方式是何等重要。通常狀況下我會這麼畫系統架構圖，主要側重於表達用了哪些中間件、什麼數據源、什麼應用、開放什麼SPI、以及這其中各組件之間是如何交互的，最終能夠支撐哪些業務。

3.4 應用架構

應用架構仍然推薦圖的方式來表達。我通常這麼畫應用架構圖，主要側重於表達應用由哪些模塊組成，每一個模塊包含哪些功能，各模塊之間的層次關係，哪些應用包含哪些模塊。另外，這張圖中也是能夠把用了哪些中間件、什麼數據源，支持哪些業務場景畫上的，這樣這張圖會更完整一些，即便不看系統架構圖，單單看這一張圖，也是能夠明白整個項目的設計的。

3.5 系統流程圖

系統流程圖以流程圖爲主，能夠輔以文字說明，或者表格說明，因爲這個和業務邏輯緊密相關，此處再也不舉例。

3.6 領域模型設計

領域模型設計，這一階段是很是有必要的，先肯定領域模型，後再根據領域模型肯定存儲模型，並不是全部的領域模型都要轉換爲存儲模型，從而保存到數據庫中。領域模型設計過程當中，要十分清楚系統總體流程圖，能夠結合上個階段的系統流程圖，來推演一下，根據這些領域模型是否能夠推演出系統的正常正確運行。圖爲主，輔以必要的文字說明此領域模型設計如何讓系統運行便可。

3.7 存儲模型設計

存儲模型設計，須要詳細到表中每一個字段的設計，字段類型、是否爲主鍵、是否須要建索引、是否可爲空、是否爲分表字段等等。表結構設計表格展現便可。存儲模型設計，仍是建議圖片的形式表達，方便展現各表之間的關係。

3.8 全局可用定義

全局可用定義，主要定義一些通用的方法、枚舉類、共同的約定等，以免各個應用or各開發人員定義一套本身的方法、枚舉等，以確保同一個字段or同一個方法等在系統內惟一。

3.9 功能模塊設計

功能模塊設計，即各模塊的詳細設計，這裏應該儘量詳細，能夠舉一些例子，確保負責此模塊開發的同窗看文檔便可明白要作什麼，以及如何作。必要的話，能夠各模塊再出一個詳細的技術方案。

3.10 接口定義

接口定義，吶，很少作解釋，記得寫清楚入參、出參、接口名字，入參和出參記得用自定義類來接收，不要忘記實現序列化喲~

BaseResult、isSuccess、getData、getErrorMessage、buildErrorResponse、buildSuccessResp這些基礎的類和方法也不要忘記呀！

3.11 項目里程碑

項目里程碑，即項目的時間節奏，例如開發時間、聯調時間、提測時間、發佈時間等，此時也應該肯定各類資源了，確保相關同窗能夠在你計劃的時間範圍內投入項目中。

3.12 其餘

若是你的項目須要出海，那你還須要考慮系統的部署方式、本地化、時區偏移、系統所需中間件是否支持等等。

4.項目過程把控

只有好的方案，項目過程把控不到位，最終也是沒法交付一個使人滿意的產品的。那如何才能使項目按照既定計劃有序進行，同時又能保證交付的質量呢？

做爲一個項目的owner，你須要作：

1. 技術方案要切實可行
2. 明確整個項目的時間節奏，每一個階段應該交付什麼可衡量的結果，每一個階段之間的關聯性，不能按時交付的影響
3. 明確每一個人所作的事情，每一個事情須要作多久，交付結果是什麼
4. 是否可階段性提測，階段性驗證
5. 識別項目中存在的風險，風險是否可控
6. 大促封網，和上下游依賴這些因素也要考慮
7. 測試人員等相關人員須要提早鎖定

具體到action上面，則能夠考慮下下面這些：

1. 日會了解每一個人的進度、風險點、須要協助的點等
2. 各個階段的可運行單測是必須的
3. 按期review代碼(例如一週一次)，check真實進度，owner或owner&相應開發人員參加便可
4. 制定開發規範，保證代碼風格統一
5. 功能拆分儘量細，一個功能點最好不要超過5天，儘可能控制在3天以內
6. 開發總體自測ok以後，對項目進行總體code review，同時提測
7. code review以後修改的代碼，所有修改完畢以後，要進行總體的迴歸測試，迴歸測試期間除bug問題，不容許再修改代碼
8. 發佈避開大促封網，發佈以前肯定依賴方發佈時間點，看下發布順序有木有要求

其中，應重點關注項目中的風險，不管是何種緣由，本身可控or不可控因素形成的，現狀偏離計劃的事情，都屬於項目風險，應儘早拋出來，並且應儘量保證你但願看到這一風險的人看到。其次，風險不是拋出來就完事了，還要考慮下是否能夠cover掉這一風險，是否須要其餘人協助，須要的話，也應儘早提出來。最後，儘量多給測試留一些時間，你永遠不知道測試過程當中會發現什麼問題。

5.交付清單

交付清單的意義不只僅在於給到產品同窗，讓他check他所提的需求咱們已實現，還在於咱們自身對這個項目的一個回顧，另外，交付清單也能夠給到測試同窗一個最強王者輔助的做用，測試人員對比交付清單便可知道本次項目的全部功能，方便他們測試。因此，交付清單應儘量詳細，和TC 不衝突哦~

推薦思惟導圖+Excel+文字的形式展示。

6.發佈前準備

主要是一些資源準備，例如線上服務器、線上DB、線上mq等等各類中間件及資源的準備。

其次，將項目中用到的SNAPSHOT 版本二方包替換爲正式版二方包，替換完，記得再回歸測試一下。

另外，還須要肯定依賴的上下游的發佈時間，若是這次發佈依賴上下游的發佈時間，須要和他們協商好具體的發佈時間，肯定到幾點，以方便咱們到點check他們是否發佈，以決定咱們是否能夠發佈。

咳咳，發佈前也能夠寫一些工具，假如線上數據出現問題，能夠經過這些工具修復數據。一名合格的數據衛士不該該直接訂db，而應該經過工具來修復。項目上線，相應的工具也同步上線。

7.發佈

發佈過程當中，須要看各類監控，確保這次發佈沒有問題，才能繼續大範圍發佈。

發佈完成，還應該有線上測試環節，以check線上功能可用。

同時，須要跟進幾天線上監控、報警、日誌等，確保沒有問題後，纔算這次發佈順利完成。

8.覆盤

我的的覆盤是必須的，緣由我就很少說了。這裏的覆盤指的不是你對外分享/宣講等等的覆盤，而是對你心裏那個真實的本身來說的覆盤，在這個項目中本身究竟有沒有成長，成長了哪些，哪些地方作的好，哪些地方作的很差，很差的地方下次可不能夠避免or解決，這個項目有沒有偏離你的初衷等等。

以上來源於Bella醬在阿里當PM的經歷的總結，也許正在讀這篇文章的你，所經歷的項目歷程，並不徹底match上面這個過程，也許是團隊習慣問題，也許是項目時間節奏太快的問題等等，歡迎後臺留言給我或者加我微信，告訴我你如今所經歷的項目歷程是什麼樣子的。

大家的關注、點贊、轉發、收藏是我最大的動力。若是本文有任何錯誤和建議，歡迎批評指正~

我的微信公衆號『Bella的技術輪子』，掃描下方二維碼便可關注，期待你的關注～