概述：
- 我們要找到符合自己項目開發和管理流程，而不是對一般流程照搬，並通過同類項目問題的根因分析來不斷優化流程
需求階段
- 需求工具：axure
- 需求來源（業務團隊原始需求、客服備案的用戶問題（迭代）、研發對實現方案的優化（迭代）、以及項目團隊成員對項目的看法（迭代））
- 需求分析與制定（需求人員）：需求文檔
- 需求確認（業務團隊）：需求原型確認
- 需求評審（需求，開發，運維，測試、客服）：要求在評審之前，至少有半天到一天時間，有自己的問題先進行記錄
- 需求流程：需求收集->需求分析->產品方案內部評審->產品方案用戶確認->產品方案外部評審
注意點：
- 需求人員需要分清需求來源的對象，一個需求可能來自不同的對象或同時來自多個對象，確定各個對象對需求的不同要求，從而得到最終需求。
- 對需求要有所取捨。我們對需求有從正反兩個方向考慮（正：這樣做能解決什麼用戶問題，反：實現這個需求是否會引發其他的問題，這個需求重要性如何等）。
- 對於持續改進的項目需要持續跟蹤各個項目需求方的現狀。項目經理必須對這個階段加以重視，跟產品經理配合來解決好這件事情。
- 對於需求變跟要麼不做，要麼延期做，要麼納入從而重新估時並及時通知其他相關的各方
- 大的優化和需求不要一起做，不然項目管控難以控制
- 對新平臺的引進不要引入新需求
研發階段：
設計
- 部署框架
- 軟件模塊圖
- 軟件層次圖
- 時序圖
- 流程圖
- 數據庫設計
- 緩存設計
- 接口設計
- 其它
設計評審
- 對設計階段的產物進行評審，分析其合理性和風險性。
功能分解
- 對功能劃分爲各個工作包，再根據工作包優先級及其限制（工作包之間限制，時間限制、硬件限制等）對工作包進行排序
- 再根據工作包的內聚性、複雜程度和人的水平、性格、業務瞭解層次等特點將工作包來劃分到個人。將任務分發下去後，先讓項目成員進行估時，項目經理在此基礎上得到最終的時間。
- 項目成員的工作包要按統一的格式輸出，如果是寫api，那麼寫明是什麼api，以這樣的維度容易計算工作量
- 如果人員不夠或截止時間過期則走人員管理進行招聘等。從而得到項目管理計劃。
- 估時既要考慮項目中的時間，也要考慮項目外的時間（會議、請假等）
- 工作包本身是不能再次進行分解的，這就要求工作包會非常細化。這樣也能保證估時更爲準確
- 對一個完全的新系統，研發人員對工作包的估時可能不太準確，可能需要相同崗位的同事進行輔助，尤其是新員工更是如此
- 如果多個項目並行，但需要同一個職能部門（如需求、研發、測試等），要把控兩個項目的關係
- 項目與項目的節奏要穩，不要一個項目週期很短，但項目間的週期卻很長，這對於產品方案評審及軟件質量都有直接關係
編碼
- 編碼規範
- 保證代碼至少一天上傳一次
- 每日工作立會：當前的項目進度、當天要完成的任務、遇到的問題、已知的風險
- 保證編碼工具和管理工具的統一
評審
- 代碼評審
- 規範評審
自測
- 開發人員單元測試
- 開發人員集成測試
聯調
- 開發人員間系統測試
- 多個系統聯調時，要求一個人有兩個系統的權限，讓着一個人同步跟蹤
測試
- 測試人員系統測試
- 測試的測試用例要提前於開發的自測時間，並在聯調的時候要走完測試用例
- 測試問題要求：
- 測試問題
- 測試賬號和密碼（不能用截圖）
- 測試標誌（如跟蹤id，不能用截圖）
- 測試url、測試參數、響應信息（不能用截圖）
覆盤
- bug覆盤：魚骨圖
- 技術覆盤：因爲設計問題或代碼問題導致異常耗損
- 管理覆盤：因爲工具或其它問題導致異常耗損
過程
- 要進行會議記錄，並能進行記錄發佈
- 需求修改，能進行需求記錄（如原型圖的體現和需求文檔的體現），並記錄需求的變動，並能進行發佈
- 接口修改，能進行記錄，並能進行發佈