有人說“一起在湖邊吹過晚風的人，會記得更久一些吧”，那一起住過院的人，是不是可以刻骨銘心了？之前就想寫篇文章總結一下自己前段時間當PM的經(jīng)歷呢，奈何發(fā)布了這個需求，還有另外一個需求要發(fā)布，周末稍微有點時間了，又想睡覺續(xù)命，我的懶癌就又犯了:(哇哇，我也只是個孩子呀，咳咳，阿姨言歸正傳，所以所以，一拖再拖，直到在醫(yī)院的這幾天。

每一個項目做完，或者跳出了一個舒適區(qū)，還是要自我總結復盤下的，不是么？一來以一個局外人的身份，系統(tǒng)地看待下自己所做的這個事情，二則為自己以后回顧這段時光提供一些素材，不然，說不定以后自己會忘記呢~

以下來源于Bella醬在阿里當PM的經(jīng)歷的總結，如有不當，歡迎批評指正~

1.項目立項

做一個項目之前，你要清楚為何要做這個項目，這個項目的價值和意義在哪里？如果是現(xiàn)有版本的大升級，那你還需要清晰的知道目前版本存在哪些問題，痛點是什么，擴展性如何，可維護性如何等等。同時還要確定升級后的版本的目標，只有目標確定了，后面技術方案選型的時候，你才會知道應該選取哪種技術方案，因為你選的技術方案，要能足夠?qū)崿F(xiàn)你的目標。

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

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

2.技術預研

這一階段的主要目的就是基于上一階段確定的目標，調(diào)研哪些技術可以支撐你實現(xiàn)這個目標，這些技術理論上的可行能否最準轉(zhuǎn)變?yōu)槁涞厣系目尚?，可以拿當前業(yè)務場景以及數(shù)據(jù)做一個推演，數(shù)據(jù)推演ok之后，可以再做一個小的可以運行的demo，以證明該技術真正可以用在此項目中。

此階段需要產(chǎn)出各個技術選型的數(shù)據(jù)推演圖，如果推演過程比較復雜的話，也可以考慮再產(chǎn)出一份比較詳細的Excel樣式的數(shù)據(jù)推演圖，每一個步驟數(shù)據(jù)如何變化都要體現(xiàn)出來。另外，還需要產(chǎn)出各個技術選型可運行的demo。最后，需要產(chǎn)出各種技術選型的對比，表格形式或思維導圖形式都可以，切忌純文字?；谏鲜鰧Ρ龋_定最終的技術選型，然后就可以開始技術方案的編寫啦~

3.技術方案編寫

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

3.1 業(yè)務背景

業(yè)務背景主要是交代下做這個項目的背景，即為什么要做這個項目，基于一個什么樣的業(yè)務背景，也可以把【1.項目立項】中畫的思維導圖直接放在這一pa。

3.2 場景分析

場景分析則主要是講這個系統(tǒng)有哪些應用場景，如果能夠列舉出業(yè)務方的真實訴求，那是最好不過了。然而大多數(shù)程序員的生活，并不會直接對接業(yè)務方同學，而是對接產(chǎn)品經(jīng)理。

3.3 系統(tǒng)架構

系統(tǒng)架構推薦以圖的方式來展示。開局一張圖，剩下全靠講，也不是不可以哈。Bella醬就有過這種經(jīng)歷，開局我放了一張圖，然后看著大佬們講了3個多小時。佩服佩服，那次經(jīng)歷也讓我懂得，表達方式是何等重要。一般情況下我會這么畫系統(tǒng)架構圖，主要側(cè)重于表達用了哪些中間件、什么數(shù)據(jù)源、什么應用、開放什么SPI、以及這其中各組件之間是如何交互的，最終可以支撐哪些業(yè)務。

3.4 應用架構

應用架構仍然推薦圖的方式來表達。我一般這么畫應用架構圖，主要側(cè)重于表達應用由哪些模塊組成，每個模塊包含哪些功能，各模塊之間的層次關系，哪些應用包含哪些模塊。另外，這張圖中也是可以把用了哪些中間件、什么數(shù)據(jù)源，支持哪些業(yè)務場景畫上的，這樣這張圖會更完整一些，即使不看系統(tǒng)架構圖，單單看這一張圖，也是可以明白整個項目的設計的。

3.5 系統(tǒng)流程圖

系統(tǒng)流程圖以流程圖為主，可以輔以文字說明，或者表格說明，由于這個和業(yè)務邏輯緊密相關，此處不再舉例。

3.6 領域模型設計

領域模型設計，這一階段是非常有必要的，先確定領域模型，后再根據(jù)領域模型確定存儲模型，并非所有的領域模型都要轉(zhuǎn)換為存儲模型，從而保存到數(shù)據(jù)庫中。領域模型設計過程中，要十分清楚系統(tǒng)整體流程圖，可以結合上個階段的系統(tǒng)流程圖，來推演一下，根據(jù)這些領域模型是否可以推演出系統(tǒng)的正常正確運行。圖為主，輔以必要的文字說明此領域模型設計如何讓系統(tǒng)運行即可。

3.7 存儲模型設計

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

3.8 全局可用定義

全局可用定義，主要定義一些通用的方法、枚舉類、共同的約定等，以避免各個應用or各開發(fā)人員定義一套自己的方法、枚舉等，以確保同一個字段or同一個方法等在系統(tǒng)內(nèi)唯一。

3.9 功能模塊設計

功能模塊設計，即各模塊的詳細設計，這里應該盡可能詳細，可以舉一些例子，確保負責此模塊開發(fā)的同學看文檔即可明白要做什么，以及如何做。必要的話，可以各模塊再出一個詳細的技術方案。

3.10 接口定義

接口定義，吶，不多做解釋，記得寫清楚入?yún)?、出參、接口名字，入?yún)⒑统鰠⒂浀糜米远x類來接收，不要忘記實現(xiàn)序列化喲~

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

3.11 項目里程碑

項目里程碑，即項目的時間節(jié)奏，例如開發(fā)時間、聯(lián)調(diào)時間、提測時間、發(fā)布時間等，此時也應該確定各種資源了，確保相關同學可以在你計劃的時間范圍內(nèi)投入項目中。

3.12 其他

如果你的項目需要出海，那你還需要考慮系統(tǒng)的部署方式、本地化、時區(qū)偏移、系統(tǒng)所需中間件是否支持等等。

4.項目過程把控

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

作為一個項目的owner，你需要做：

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

具體到action上面，則可以考慮下下面這些：

1. 日會了解每個人的進度、風險點、需要協(xié)助的點等
2. 各個階段的可運行單測是必須的
3. 定期review代碼(例如一周一次)，check真實進度，owner或owner&相應開發(fā)人員參加即可
4. 制定開發(fā)規(guī)范，保證代碼風格統(tǒng)一
5. 功能拆分盡可能細，一個功能點最好不要超過5天，盡量控制在3天之內(nèi)
6. 開發(fā)整體自測ok之后，對項目進行整體code review，同時提測
7. code review之后修改的代碼，全部修改完畢之后，要進行整體的回歸測試，回歸測試期間除bug問題，不允許再修改代碼
8. 發(fā)布避開大促封網(wǎng)，發(fā)布之前確定依賴方發(fā)布時間點，看下發(fā)布順序有木有要求

其中，應重點關注項目中的風險，無論是何種原因，自己可控or不可控因素造成的，現(xiàn)狀偏離計劃的事情，都屬于項目風險，應盡早拋出來，而且應盡可能保證你希望看到這一風險的人看到。其次，風險不是拋出來就完事了，還要考慮下是否可以cover掉這一風險，是否需要其他人協(xié)助，需要的話，也應盡早提出來。最后，盡可能多給測試留一些時間，你永遠不知道測試過程中會發(fā)現(xiàn)什么問題。

5.交付清單

交付清單的意義不僅僅在于給到產(chǎn)品同學，讓他check他所提的需求我們已實現(xiàn)，還在于我們自身對這個項目的一個回顧，另外，交付清單也可以給到測試同學一個最強王者輔助的作用，測試人員對比交付清單即可知道本次項目的所有功能，方便他們測試。所以，交付清單應盡可能詳細，和TC 不沖突哦~

推薦思維導圖+Excel+文字的形式展現(xiàn)。

6.發(fā)布前準備

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

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

另外，還需要確定依賴的上下游的發(fā)布時間，如果此次發(fā)布依賴上下游的發(fā)布時間，需要和他們協(xié)商好具體的發(fā)布時間，確定到幾點，以方便我們到點check他們是否發(fā)布，以決定我們是否可以發(fā)布。

咳咳，發(fā)布前也可以寫一些工具，假如線上數(shù)據(jù)出現(xiàn)問題，可以通過這些工具修復數(shù)據(jù)。一名合格的數(shù)據(jù)衛(wèi)士不應該直接訂db，而應該通過工具來修復。項目上線，相應的工具也同步上線。

7.發(fā)布

發(fā)布過程中，需要看各種監(jiān)控，確保此次發(fā)布沒有問題，才能繼續(xù)大范圍發(fā)布。

發(fā)布完成，還應該有線上測試環(huán)節(jié)，以check線上功能可用。

同時，需要跟進幾天線上監(jiān)控、報警、日志等，確保沒有問題后，才算此次發(fā)布順利完成。

8.復盤

個人的復盤是必須的，原因我就不多說了。這里的復盤指的不是你對外分享/宣講等等的復盤，而是對你內(nèi)心那個真實的自己來講的復盤，在這個項目中自己究竟有沒有成長，成長了哪些，哪些地方做的好，哪些地方做的不好，不好的地方下次可不可以避免or解決，這個項目有沒有偏離你的初衷等等。

特別推薦一個分享架構+算法的優(yōu)質(zhì)內(nèi)容，還沒關注的小伙伴，可以長按關注一下：

長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝