最近經歷了入職公司最長的一個項目，前後跨度3年，更換3任PM,SE等關鍵角色；本次項目週期長，有美國的助攻（中間暫停3個月左右），有需求範圍持續變更等客觀因素造成，也有項目管理中人爲原因造成；現將項目的過程幾個典型的片段進行回顧，最後做下項目管理的心得小結。
第一個TR5交付時整體需求大概有5000+，組織SE,開發等澄清保留3000+；設計是項目的源頭，建議定期和開發，測試澄清一次，尤其人員變更，項目範圍變更等時需要主動組織開展；
一到版本轉測試管理軟件的同事就通宵達旦合入代碼和驗證，轉測試後經常測試出低級問題（配套表不正確，不能升級，升級後啓動異常等）造成版本反覆被打回，如果一個事件反覆出現，背後一定有更深層次的原因（組織，流程，代碼架構等深層次原因）。
人一生少犯同樣的錯誤，能夠大大的提升個人的成功率，組織如果能夠積累，少犯相同的錯誤，尤其是低級錯誤，那麼這個組織就能不斷高效高質交付。
一直沒有的系統測試看護，項目組從立項開始就沒有系統測試人員，每次測試是都是測試經理多方求助纔有人力完成相關測試。初期還有一個獨立小組，負責產品的交付，還容易協調到人力；後期組織解散，人力不斷升級，一會軟件人員測試下，一會硬件測試測試下……總之系統測試能力一直沒有建設起來。
幾乎沒有按時達成的月度計劃：版本從轉測試初期，月度計劃基本沒有按時，往往因爲人力原因延期3~5周後轉測試，轉測試後低級問題多，又反覆需要出版本，版本就陷入的循環：延期，出問題，延期轉測試……最終版本火車也沒法保證，版本多次進行PR延期交付時間點。
心得
- 交付項目最好在6~8個月結項，長時間不結項的項目是很可能出問題的；增量版本單獨立項，單獨分配人力；
- 項目立項只談了立項的進度和費用情況，但時間人力投入太少；
- PM很關鍵，要持續跟蹤，交付計劃按月度達成，就是平時少量延期也不至於3年纔出來；
- 每個版本交付件要齊全，能夠驗證，減少反覆；
- 儘快進行生產裝備的試製，打通生產製造流程；
- 從開始就要全系統配合的測試，支持的單板，部件，場景覆蓋；
- 人員流動做好工作交接，形成組織資產；
- 配套產品一起轉測試，一起管理起來，作爲整體進行系統測試；
- 拉通下游一起開展聯調和測試，尤其是滿框業務的壓力測試；
- 需求進行定時澄清；