標準項目實施方法論(內(nèi)部參考)-V251

項目實施規(guī)范V2.0：總綱/22/2016目錄索引TOC\o"1-3"\h\z1. 概述 21.1. 總原則 21.2. 項目實施階段工作目標定義 22. 項目實施規(guī)范 32.1. 團隊確定（ProjectTeamSetup） 32.2. 項目會議（Meeting） 32.3. 項目進度報告（StatusReport） 42.4. 會議紀要（MeetingMinutes） 42.5. 變更控制（MeetingMinutes） 42.6. 報修控制（BugReport） 52.7. APMS使用（ControlYourProject） 52.8. 三人制設(shè)計模式（TrebleDesign） 5

概述成功的項目實施是一個復(fù)雜的工程問題，存在一定風險的；為了最大程度降低風險，唯智公司在長期的項目實踐中總結(jié)出（逐步完善）一套能避免或把風險降為最低的方法：項目實施方法論。同時按照規(guī)范進行項目管理，能夠保證不同能力的項目經(jīng)理能夠在面對客戶的時候，提供同樣的專業(yè)服務(wù)，能夠提高客戶滿意程度。各種類型的項目實施有其特點，都有自己的一套規(guī)范和文檔模版。本規(guī)范中規(guī)定的各項內(nèi)容和模版是所有項目都需要的共性問題。本規(guī)范是所有其他規(guī)范的基礎(chǔ)，必須得到切實執(zhí)行。實施方法論保證了分析人員能夠按照一種比較和的方法有條不紊的進行分析設(shè)計工作，同時留下足夠的文檔，幫助后期開發(fā)小組工作。但是必須注意，實施方法論無法取代分析設(shè)計人員對于客戶業(yè)務(wù)的直觀理解和創(chuàng)造性的思維。不動腦筋的進行文檔填寫工作是不能滿足公司要求的。也會對于項目造成嚴重損害。總原則項目盡可能采用迭代方式實施盡可能引入客戶參與項目的各個階段，讓客戶項目小組的人員成為幫助項目成功的戰(zhàn)友，而不是站在相反方向，防止甲方利益受損的敵人對于項目進行嚴格的過程控制項目文檔需要簡明扼要，多使用表格，清單的方式，避免大段的描述性文檔，各種會議紀要，進度報告等過程性文檔原則性不應(yīng)該超過2-3頁項目實施階段工作目標定義階段目標業(yè)務(wù)需求分析階段獲取詳細的用戶需求客戶充分參與，對于需要開發(fā)或者實施系統(tǒng)的功能有足夠的了解建立和客戶的良好關(guān)系保護公司利益，排除不合理需求設(shè)計階段設(shè)計實現(xiàn)需求的技術(shù)方案制定測試方案開發(fā)階段根據(jù)設(shè)計，進行迭代開發(fā)開發(fā)階段包含單元測試和功能測試測試驗收階段對系統(tǒng)進行全方位測試通過客戶驗收測試實施階段將系統(tǒng)交給客戶使用充分培訓(xùn)客戶，幫助客戶成功使用系統(tǒng)維護與擴展階段解決客戶發(fā)現(xiàn)的問題提供客戶提出的新的功能修改服務(wù)項目實施規(guī)范團隊確定（ProjectTeamSetup）項目啟動后，首要任務(wù)是成立一個由乙方，甲方信息部，甲方業(yè)務(wù)部門人員構(gòu)成的項目小組。把人員的聯(lián)系方式整理成一個清單是一個不錯的主意。[附屬文檔]項目小組成員表.doc項目整體計劃制定（MilestoneSchedule）項目啟動后在合同SOW中規(guī)定的項目進度就需要進行進一步細化成為項目計劃，該計劃是比SOW計劃略細的大計劃，側(cè)重點還是對于Milestone檢查點的計劃。采用MSProject編寫。編寫完成后和客戶確定計劃，并發(fā)給技術(shù)部經(jīng)理留檔。此文件將作為項目重要的控制文件，項目經(jīng)理必須確保每個里程碑都按時完成，如果無法及時完成，需要提前知會客戶和技術(shù)部經(jīng)理，調(diào)整計劃。需求定義（RequirementDefinition）項目啟動后，需要根據(jù)合同中的SOW進行細化，將客戶大塊的需求細化為可以開發(fā)的詳細功能定義。項目小組需要填寫此文檔，并通過公內(nèi)部審核，以及獲得客戶簽字確認，此文檔將取代合同的SOW作為項目驗收的標準。對于一些特殊項目，項目小組可以考慮引入一些流程圖等方式，增強需求定義文檔的表現(xiàn)力和說明力。[附屬文檔]需求定義文檔.doc項目會議（Meeting）成功會議要點：所有會議需要簡短，目的明確。會議不是進行重要問題的討論和爭論的場合，所有重要決定需要事先和客戶關(guān)鍵人物達成共識，在會上僅作為匯報和正式確認，逼迫部分問題客戶就范主動控制會議進程，不要被客戶牽著鼻子走。會議上，誰的準備充分，誰就會占主導(dǎo)地位，更加容易達成自己的目的KickOffMeeting:項目開始的時候，大家在一起開一個簡短的會議，會議上主要介紹項目的工作目標，各方的責任，以及下一階段的詳細工作安排。通過KickOff會議能夠讓大家意識到項目已經(jīng)開始，及早進入狀態(tài)。KickOff會議也是大家認識的一個很好的機會。如有可能盡可能要求該項目銷售，公司高層參與。會議要簡短，開完會最好安排一起吃飯。項目例會:項目開始后，和客戶確定每周一次的項目會議的時間。一般安排在周五下午或者周一上午。由客戶根據(jù)自己方便的時間選擇一個。項目例會的需要準備項目進度報告，提前發(fā)給客戶，在會上討論。會后需要整理會議紀要。如果會議上涉及重要決策，需要讓客戶簽字確認。里程碑驗收會議:當項目達到里程碑階段的時候，如有可能組織雙方高層參與會議。主要是總結(jié)前期工作成果，以及下一階段的安排。里程碑驗收會議對于收款和改進客戶高層（往往平時根本不知道項目情況）的滿意度有很重大的作用。里程碑驗收會議如有可能讓客戶項目經(jīng)理和主要參與的用戶負責匯報。我方項目經(jīng)理僅作為主持人，控制會議進程。需要事先準備PPT。項目進度報告（StatusReport）項目例會前，需要準備項目進度報告。項目進度報告反映了前期工作進展情況，下一階段工作計劃，會上需要討論的議題，以及風險分析。進度報告是幫助客戶了解項目進程，以及安排客戶協(xié)同工作的有效工具。[附屬文檔]項目進度報告模版.doc會議紀要（MeetingMinutes）項目會議，或者某些突發(fā)性的討論會議后，項目經(jīng)理必須準備會議紀要。會議紀要要求精簡，能夠反映問題。特別是對于項目有很大影響的決議必須在會議紀要上得到反映。會議紀要是逐步影響客戶，向有利于我方的方向發(fā)展的重要工具。會議紀要的措辭和寫法非常重要。會議紀要中不要出現(xiàn)誰發(fā)言，談了什么的流水帳，而要記錄會議中決定了什么（某些情況下可以有選擇的紀錄會議紀要）。用戶簽過字的會議紀要需要歸檔保存。[附屬文檔]會議紀要模版.doc變更控制（ChangeControl）項目中一定會發(fā)生客戶要求變更需求的情況。任何變更無論大小，項目經(jīng)理必須要求客戶填寫（或者幫助客戶填寫）變更控制表。變更控制文檔包含變更原因，變更內(nèi)容，實現(xiàn)方案，估算工作量和對于項目進度影響的內(nèi)容。[附屬文檔]變更確認書模版.doc對于需要向客戶收費的變更，需要在完成變更確認書后，交由技術(shù)部經(jīng)理填寫項目服務(wù)協(xié)議，并由銷售人員填寫服務(wù)收費后和客戶負責人進行簽署。[附屬文檔]服務(wù)協(xié)議.doc報修控制（BugReport）客戶發(fā)現(xiàn)軟件質(zhì)量問題，需要填寫（或者項目經(jīng)理幫助填寫）故障報修文檔。[附屬文檔]故障報修模版.doc上線通知（ReleaseNotice）當系統(tǒng)上線后，無論是bug修改還是迭代的功能更新之前都需要編寫上線通知文檔，讓客戶知道本次軟件更新的目的，需要提前準備的內(nèi)容以及對于業(yè)務(wù)操作的影響。[附屬文檔]系統(tǒng)上線通知模版.doc公司周末例會（InternalWeeklyMeeting）參加人員：當前承擔某項目的管理工作的項目經(jīng)理；主要內(nèi)容：review所有apms中需要本周完成的工作的情況，確定周末是否需要加班；提出下周工作的清單，便于公司統(tǒng)一安排人力資源（建議提前建入apms系統(tǒng)，可以不安排人員由公司統(tǒng)一安排，也可以指定人員，視情況而定）時間安排：周五下午5：00--6：00外地項目經(jīng)理通過電話提前進行會議，時間大概在4：00--5：00左右。如果會議時間和項目其他安排（例如已經(jīng)安排的客戶會議）沖突，請?zhí)崆巴ㄖ夹g(shù)部經(jīng)理，提前單獨review。APMS使用（Contr