隨著工作年限的增長，我們從一開始負責一個功能，再到負責一個模塊的數據字典及框架設計。再到負責整個系統的需求評審及架構設計。這一路見證著程序猿的成長。但當我們逐步成為一名架構師，或是一名項目管理人員時，會發現一個項目的成功，會牽扯到各式各樣的問題及風險。無論是系統本身要兼容快速發展的業務形態，還是由于人員因素導致的項目延遲，又或是系統代碼的臃腫或是難以維護，亦是新人來后的一臉迷茫。那么下面，分享下，項目流程管理之我見。
一、整體項目流程 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）從整個系統的層面、業務大圖的層面去考慮整個系統或產品的發展及擴展。
當然，現實或許是殘酷的，時間或許是緊迫的。很多時候，我們會因為各種各樣的原因而擱置其中的部分流程。但規范決定著長遠的風險可控，倘若有時間一定要將必要的補上，這是對別人負責，同時也是對自己負責。

總結

以上是生活随笔為你收集整理的项目研发流程及管理之我见的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。