隨著工作年限的增長，我們從一開始負責乙個功能，再到負責乙個模組的資料字典及框架設計。再到負責整個系統的需求評審及架構設計。這一路見證著程式猿的成長。但當我們逐步成為一名架構師，或是一名專案管理人員時，會發現乙個專案的成功，會牽扯到各式各樣的問題及風險。無論是系統本身要相容快速發展的業務形態，還是由於人員因素導致的專案延遲，又或是系統**的臃腫或是難以維護，亦是新人來後的一臉迷茫。那麼下面，分享下，專案流程管理之我見。
一、整體專案流程
1、 需求評審與確認
2、模組流程文件
要求：圍繞著本次迭代的核心問題，編寫整個模組的閉環業務流程。如有複雜邏輯，需要畫出用例圖、協作圖等。
同時，要給出該模組的非功能性需求，例如：呼叫量、日均增量、訪問次數等待。
產出：領域模型、開發模組架構圖、技術架構圖、人員分工（每個人負責哪個模組）
3、詳細設計及評審
（1）概念對映：抽取本次模組迭代的一些屬於概念。
（2）框架設計：圍繞著本次迭代的核心，進行模組的擴充套件構思，不僅僅以完成本次功能的模組為主旨，還需要考慮未來的體系中，該模組的可用性、擴充套件性。
（3）資料庫設計：資料庫設計時要嚴格遵守資料庫正規化、同時圍繞系統做到可擴充套件。
（4）功能細化與調研各個環節中需要呼叫哪些介面服務。
（5）前後端傳輸物件的對映及定義，進行前後端最後評審。
產出：技術架構圖、資料庫關聯關係圖等，一致評審通過後，形成完整文件。
4、編碼
（1）圍繞著模組的核心構建核心框架**（遇到問題可互相討論）
（2）編碼及功能實現。
（3）介面注釋、複雜邏輯注釋。
5、測試
產出：測試用例文件及單元測試testcase。
6、發布前準備與發布
要求：檢視**檢測工具，質量分不得小於35分、行單測覆蓋率不得小於百分之60。從開發->整合->預發->發布階段，每一階段都需要進行驗證及日誌檢視。
注：預發前要充分做好回歸測試（根據每次迭代的測試用例及單元測試進行測試），防止線上已有功能受到影響。
7、線上問題修復及運維
要求：（1）發布上線後出現問題，需要緊急變更處理，做好線下及預發驗證，發布線上。同時在lark上記錄該問題的前因後果。
（2）約定時間，每日檢視自己負責的模組及整體系統運**況，發現問題及時丟擲。
二、**質量及review
要求：每次迭代完的下個星期，抽出一下午時間進行**質量及review（pmd檢測大部分**質量問題），包括：
（1）**結構是否合理，能否有更好的實現。（結構角度、方法抽象、jvm堆疊記憶體占用等）
（2）**中沒考慮到的情況
三、專案管理
專案管理要點分為，時間把控、風險把控、補位意識、結果與目標導向四點：
時間把控：
（1）整個專案流程分為需求、設計、開發、測試、實施階段。根據需求的複雜度、團隊整體能力水平、調研負責度進行迭代週期的**。
（2）一旦時間確定下來，就嚴格按照每個階段的產出實行。
風險把控：
（1）意外情況或有進度風險的情況。需要及時暴露出來 風險原因及風險問題。並進行相關協調溝通，補位意識。
補位意識：
（1）專案風險確定，每個成員都有自身的長項，發現影響進度的問題，包含於自己能力的能力範疇內，幫助對方提速，追趕專案進度。
結果與目標導向：
（1）保質保量完成需求及模組的迭代。
（2）優化review及補充，使每個人能夠知道對方模組的邏輯及全系統邏輯。
（3）問題總結及技能總結。
（4）從整個系統的層面、業務大圖的層面去考慮整個系統或產品的發展及擴充套件。
當然，現實或許是殘酷的，時間或許是緊迫的。很多時候，我們會因為各種各樣的原因而擱置其中的部分流程。但規範決定著長遠的風險可控，倘若有時間一定要將必要的補上，這是對別人負責，同時也是對自己負責。
專案管理之我見
有一年多沒出去做專案了，回想起來前幾年在外奔波的日子，有心酸 有快樂，做的每個專案都歷歷在目，整體上就是痛並快樂著。專案管理是一整體的系列活動 實施前 實施中 實施後，環環相扣，但每個專案的情況不一樣，可能實施過程也不盡相同，下面就個人的切身體會談談我個人對專案管理的看法。一 實施前 1 專案經理要...
專案管理之我見
伴隨著我國資訊化的發展，專案管理越來越成為專案成功的關鍵問題。許多專案配備了足夠優秀的人手，仍然以失敗告終，根本原因就是沒有良好的管理，大家都在努力工作，但是每個人卻衝著不同的方向，結果可想而知。那麼如何才能有效的管理呢？首先，控制需求。採集需求的書多如牛毛，每個人都提出了自己的觀點。作者認為控制需...
專案管理之我見
談到專案管理，有很多問題，不是你技術好，原則性強就能把專案帶好的。我總結了一下最起碼要從以下幾個方面做起 1 熟悉team member的各自水平，極其擅長的領域，做到合理分工，注 想熟悉乙個開發人員的水平一是通過簡歷，二是可以當面找他聊天讓他對自己做乙個技術能力介紹，乙個懂技術的專案經理如果能經常...