隨着工作年限的增長，我們從一開始負責一個功能，再到負責一個模塊的數據字典及框架設計。再到負責整個系統的需求評審及架構設計。這一路見證着程序猿的成長。但當我們逐步成爲一名架構師，或是一名項目管理人員時，會發現一個項目的成功，會牽扯到各式各樣的問題及風險。無論是系統本身要兼容快速發展的業務形態，還是由於人員因素導致的項目延遲，又或是系統代碼的臃腫或是難以維護，亦是新人來後的一臉迷茫。那麼下面，分享下，項目流程管理之我見。
一、整體項目流程
1、 需求評審與確認
要求：PD會進行需求的整理並放入需求資源池。確定本期研發的功能需求，並開始需求評審，需求評審時，能夠使技術人員能夠完全理解本次需求的前因後果，作用，目標及整個流程。
產出：該階段主要爲pd產出相關prd及demo，對需求進行宣講，並記錄疑問及難點。
2、模塊流程文檔
要求：圍繞着本次迭代的核心問題，編寫整個模塊的閉環業務流程。如有複雜邏輯，需要畫出用例圖、協作圖等。
同時，要給出該模塊的非功能性需求，例如：調用量、日均增量、訪問次數等待。
產出：領域模型、開發模塊架構圖、技術架構圖、人員分工（每個人負責哪個模塊）
3、詳細設計及評審
（1）概念映射：抽取本次模塊迭代的一些屬於概念。
（2）框架設計：圍繞着本次迭代的核心，進行模塊的擴展構思，不僅僅以完成本次功能的模塊爲主旨，還需要考慮未來的體系中，該模塊的可用性、擴展性。
（3）數據庫設計：數據庫設計時要嚴格遵守數據庫範式、同時圍繞系統做到可擴展。
（4）功能細化與調研各個環節中需要調用哪些接口服務。
（5）前後端傳輸對象的映射及定義，進行前後端最後評審。
產出：技術架構圖、數據庫關聯關係圖等，一致評審通過後，形成完整文檔。
4、編碼
（1）圍繞着模塊的核心構建核心框架代碼（遇到問題可互相討論）
（2）編碼及功能實現。
（3）接口註釋、複雜邏輯註釋。
5、測試
要求：測試階段，根據代碼邏輯，編寫每一個case的相關測試用例及單元測試。變更覆蓋率不得低於百分之80。
產出：測試用例文檔及單元測試TestCase。
6、發佈前準備與發佈
要求：查看代碼檢測工具，質量分不得小於35分、行單測覆蓋率不得小於百分之60。從開發->集成->預發->發佈階段，每一階段都需要進行驗證及日誌查看。
注：預發前要充分做好迴歸測試（根據每次迭代的測試用例及單元測試進行測試），防止線上已有功能受到影響。
7、線上問題修復及運維
要求：（1）發佈上線後出現問題，需要緊急變更處理，做好線下及預發驗證，發佈線上。同時在lark上記錄該問題的前因後果。
（2）約定時間，每日查看自己負責的模塊及整體系統運行情況，發現問題及時拋出。
二、代碼質量及review
要求：每次迭代完的下個星期，抽出一下午時間進行代碼質量及review（pmd檢測大部分代碼質量問題），包括：
（1）代碼結構是否合理，能否有更好的實現。（結構角度、方法抽象、jvm堆棧內存佔用等）
（2）代碼中沒考慮到的情況
三、項目管理
項目管理要點分爲，時間把控、風險把控、補位意識、結果與目標導向四點：
時間把控：
（1）整個項目流程分爲需求、設計、開發、測試、實施階段。根據需求的複雜度、團隊整體能力水平、調研負責度進行迭代週期的預測。
（2）一旦時間確定下來，就嚴格按照每個階段的產出實行。
風險把控：
（1）意外情況或有進度風險的情況。需要及時暴露出來 風險原因及風險問題。並進行相關協調溝通，補位意識。
補位意識：
（1）項目風險確定，每個成員都有自身的長項，發現影響進度的問題，包含於自己能力的能力範疇內，幫助對方提速，追趕項目進度。
結果與目標導向：
（1）保質保量完成需求及模塊的迭代。
（2）優化review及補充，使每個人能夠知道對方模塊的邏輯及全系統邏輯。
（3）問題總結及技能總結。
（4）從整個系統的層面、業務大圖的層面去考慮整個系統或產品的發展及擴展。
當然，現實或許是殘酷的，時間或許是緊迫的。很多時候，我們會因爲各種各樣的原因而擱置其中的部分流程。但規範決定着長遠的風險可控，倘若有時間一定要將必要的補上，這是對別人負責，同時也是對自己負責。