標(biāo)準(zhǔn)項(xiàng)目實(shí)施方法論(內(nèi)部參考)-V251

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

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