專案實施過程

 

• 專案立項

1. 業務不成熟的情況下（包括業務部門對新的管理標準，業務流程不熟悉），採購專業的課程、培訓和諮詢。
2. 如果涉及的系統改造點較多，可能影響到未來的測試工作，需要在合同中註明需要增加測試人員。
3. 招標需求調研環節，需求室參與和後期專案需求調研的人員不一致問題。
4. 專案招標時，能夠駐場後按照CMMI3的標準實施的問題需要和公司方前期進行交流。
5. 專案調研後，形成的業務需求書的詳細程度問題（便於後期做工作量和進度估算）。

• 專案啟動

1. 專案啟動，專案經理做專案生命週期選擇，過程裁剪，報給EPG組稽核。
2. 專案經理組織開發人員做工作量估算，做專案總體工作量的估計，估計里程碑進度和人力、軟體、硬體、網路資源。其中人力資源需要根據估算的假設條件，對人員的素質和能力進行規定。
3. 專案經理根據風險庫識別早期的風險。
4. 啟動簽報。
5. 專案經理根據專案的實際情況，準備好《專案章程》（可以是PPT），召開專案啟動會議。

• 軟體需求開發

1. 框架性需求不夠仔細，需要在專案啟動前後重新做需求調研，專案經理在不能確定完整的專案進度計劃時，需要初擬一份《需求調研計劃》指導業務組人員進行需求調研（後期可以回溯需求調研是否有人員遺漏，需求到底是誰提出的，便於驗收）。
2. 調研沒有針對性和方法，所以需要整理調研問題清單和業務人員深入交流。
3. 業務不成熟的情況下，如何理清各個需求責任人的工作邊界。梳理業務需求的清單，標記需求的成熟度，然後採取不同的管理策略（該學習的學習，該討論的討論）。
4. 購買軟體產品做定製化開發的專案，需要理清購買軟體產品和本地化需求之間的差異，比如合同上的功能清單與使用者需求說明書的功能清單不一致時，要以使用者需求說明書為基準，因此不一致的地方需要說明，做還是不做。梳理系統功能需求清單，標記需求的狀態，然後採取不同的管理策略。
5. 瀑布式和增量式開發需求的評審和確認可以分多次組內評審，降低評審的難度，然後最後做一次正式評審（解決專家邀請困難的問題）。
6. 迭代開發時需求的評審和確認需要注意在迭代過程中的需求變更問題。第二次的需求評審應該涵蓋對第一次評審後提出的需求變更。

• 專案計劃

1. 在需求調研清楚以後，專案經理做WBS分解（每個工作包不要超過40人時），然後按照啟動簽報安排的資源進行每項活動的資源分配，調整活動間的依賴關係，編排進度，進度計劃的主要目的是可以指導每個人幹自己的活。
2. 進度計劃編制好後，專案經理可以著手編制《專案總體計劃》。專案總體計劃中的里程碑應該和進度計劃保持一致，可以與估算的里程碑截止日期有偏差，但是需要獲得專案發起人的同意。
3. 《專案總體計劃》要規定專案的組織結構，人員的技能要求。通過分析人員技能要求，從而推匯出專案的培訓需求和培訓計劃。總體計劃根據進度里程碑計劃和配置管理計劃中的基線，規定哪些文件或程式碼，什麼時間，哪些人員要參與評審，同時確定評審的規格（正式評審、組內評審、書面輪查、個人複查）。
4. 《專案總體計劃》中要規定專案日常的溝通行為，解決週會、里程碑會、每天的晨會哪些人蔘與，專案工作向誰彙報的問題。
5. 專案經理統一專案名稱，指派配置管理員，建立好配置庫。配置管理員編排配置管理計劃。
6. 專案經理選擇自己專案需要收集的資料，制定度量分析計劃。
7. 專案經理再識別一遍風險。

• 專案監督與控制

1. 專案監控的核心是在控制，監督只是觀察手段不對結果產生影響。控制要從兩個方面著手，一個是與計劃產生偏差的問題，一個是對專案過程進行調整。
2. 進度需要統計的資料可以分成日期進度（容易監控）和工作量完成進度（不容易監控）兩種。成本可以通過監控工作量間接達成。資料不真實的原因可能有：

• 因為資料填寫的頻率過高，填寫人員積極性不高；
• 填寫的手段不夠便利，資料收集比較困難；
• 因為和績效或者收入掛鉤，所以填的資料看上去很美；
• 執行人員沒有養成資料填寫的習慣。

1. 專案經理每週寫週報，到了專案里程碑結束，撰寫《里程碑報告》（主要是通過度量資料進行總結）
2. 干係人的監控（C3體系中沒有介紹），主要是干係人對專案態度的監控，然後採取不同的策略。

   干係人特徵	態度	管理措施
   權利大、利益小、影響小	支援	儘量滿足要求，並當面澄清需求的目的
   	中立	儘量滿足要求，告知不能實現需求的理由
   	反對	週報或口頭報告問題到專案發起人、專案的分管領導
   權利大、利益大、影響大	支援	分析需求實現的利弊，決策做不做的理由，上報領導
   	中立	告知能實現和不能實現的需求項，告知不能實現的理由
   	反對	和發起人對專案情況進行說明

• 
  專案的變更控制

1. 專案的變更要走CCB的審批。需要關注專案變更中哪些人對變更擁護，哪些人不支援變更，中間會有利益點的衝突，需要專案經理進行協調。
2. 專案變更每週都要做監控，但是如果專案週期超過了4個月，可以等到一個月再處理一次。如果一個月內累計工作量不超過3人天的變更，專案經理自行處置。如果一個月內，累計發生的變更工作量超過了10人天，專案經理需要走變更流程，通知CCB決策。專案週期較短，可以每週/半個月處理一次。
3. 執行變更後，開發人員報告執行變更遇到了未預見到的問題，應該第一時間報告給專案經理，需要協調專案外部資源的情況下，專案經理將問題升級到領導處。

• 專案驗收和結項

1. 驗收的流程和方法按照C3的驗收流程開展工作，原則上不具備驗收條件的專案，未經過領導批准不能自行驗收走商務付款。專案相關的驗收標準要嚴格遵照專案合同中的驗收規定。如果合同中沒有規定如何驗收，專案經理需要和業務部門、資料中心擬定驗收的要求。
2. 先有專案驗收，後有專案結項。專案結項主要是為了撤出專案資源和移交組織過程資產，因此需要得到領導的批准才能進行結項。是否召開結項評審會，主要是看專案涉及的各方是否對專案資源撤出有不同的看法，或者專案需要做一次全面性的總結工作。

• 軟體設計

1. 軟體設計主要弄清軟體：

靜態：內部關係和結構，使用的技術框架，每個模組的功能和效能，編碼時使用的設計模式（優化程式碼，減少維護工作量），類的命名和類之間的關係。資料關係設計和結構設計，資料庫設計，介面設計等。

動態：不同模組間的互動方式（一對一、一對多、多對多），通訊協議，互動順序，時序要求（同步或非同步）。

1. 設計如果發現需求沒有提清楚，應該第一時間把發現的問題記錄下來，然後提交給專案經理處理。處理的方式可以是召開需求研討會議，業務人員澄清需求。
2. 假如專案組的設計人員提出了多套解決方案，或者有不同的聲音，應該使用決策分析流程選擇最佳方案。
3. 設計的評審工作應該邀請真正的設計專家參與，可以請原廠商的人員參與設計評審，對照設計檢查單一起進行檢查。

• 軟體編碼

1. 開發的軟硬體環境、工具、元件的版本一定要統一。
2. 程式碼必須寫註釋，註釋要進行人工檢查。
3. 單元測試要做好檢查，利用檢查單。
4. 編碼規範的檢查可以藉助專業的程式碼掃描工具，也可以人工進行檢查，每週專案組花一小時檢查程式碼。

• 上線試執行

因為推廣計劃沒有做好，使用者培訓做的不到位，或者使用者反映的問題得不到及時的解決，會認為系統質量差，所以需要周密的計劃系統的培訓和推廣方式，這個可以在系統《試執行計劃》中策劃該工作，如果方案特別複雜，需要整理單獨的推廣計劃。