項目管理要素指南100問

1、精選優(yōu)質文檔-傾情為你奉上項目管理要素指南（完善中）策劃階段1何時開始項目策劃？在被任命為項目經(jīng)理之后，項目經(jīng)理應立即著手開始項目的整體策劃。避免等到合同簽訂再準備時時間不充分，而使得策劃內容質量不高或者指導意義不大。2策劃階段一般周期多長？項目策劃是一個重要活動，從指定項目經(jīng)理開始日起，項目經(jīng)理即開始收集項目資料，進行策劃；到合同簽訂后5天內，給出詳細的策劃方案。3策劃階段都做哪些工作？ 策劃工作包括：項目擬組建團隊及團隊分工、項目實施周期和方法、質量保證方法、項目風險分析及對策、項目雙方干系人及聯(lián)系方式、項目預算、項目過程文檔模版4誰負責策劃階段工作內容？策劃工作由項目經(jīng)理主責完成；當中涉

2、及到需要項目干系人明確部分內容，由項目經(jīng)理跟蹤落實（跟蹤方式包括會議，郵件，電話，審批簽字等），并得到確認。5策劃階段輸出標準文件有哪些？總體工作計劃、人力資源計劃、質量保證計劃、風險分析與對策、項目預算表、項目階段中所需要的標準文檔模版、項目啟動報告6各輸出文件如何處理？首先，所有輸出文件均需要得到相關人員批準確認，提交配置管理員歸檔；質量保證計劃提交SQA監(jiān)督執(zhí)行、項目預算表提交財務跟蹤執(zhí)行7如何編制項目預算表？項目預算表由五大部分組成：人工費用（包括咨詢服務費用）、采購費用（項目中用到的軟硬件）、全過程差旅費用、辦公費用、項目活動費用；預算編制以計劃為依據(jù)，分為預算總表和明細表；總表結果

3、以明細表匯總所得；項目經(jīng)理每月需要檢查預算執(zhí)行情況，如果出現(xiàn)變化，需及時提交項目管理委員會，經(jīng)審核同意后，方可允許預算變更；項目關閉時，項目經(jīng)理需提交預算執(zhí)行報告。8如何進行工期評估？ 項目工期評估是項目管理中很重要的一個環(huán)節(jié)；整個項目后續(xù)的計劃與人員安排都依賴于該工期的評估；項目經(jīng)理在做工期評估時按照以下步驟：1） 根據(jù)售前技術支持方案，與產(chǎn)品功能進行比較，分系統(tǒng)列出差異表2） 分系統(tǒng)，按照增、刪、改、查、打印、導入導出原則，對差異功能點進行統(tǒng)計，統(tǒng)計出待開發(fā)功能點，根據(jù)歷史開發(fā)經(jīng)驗，評估出差異功能點開發(fā)工作量；該工作量+標準產(chǎn)品部分開發(fā)工作量為該子系統(tǒng)合計開發(fā)工作量3） 按照實施過程時間分

4、配比率（需求：設計開發(fā)：測試：實施=0.6：1：0.7：0.6）,計算出各子系統(tǒng)總體工作量和周期4） 如果客戶有明確周期要求，則根據(jù)上述得到的總工作量合理安排資源；如果沒有周期要求，則項目經(jīng)理按照產(chǎn)品實施人員標準要求規(guī)劃出合理的周期5） 在最后得出的總體工作量和周期基礎上根據(jù)項目經(jīng)驗分別乘1.11.3的風險系數(shù)9如何做好項目風險管理？首先在項目啟動時，做好風險分析；風險分析步驟：1） 識別風險點、風險發(fā)生概率以及影響程度2） 確定重點關注風險點，并給出風險解決措施3） 給出風險措施的跟蹤監(jiān)控措施在管理風險問題點時，項目經(jīng)理要遵循閉環(huán)管理原則，對于重點關注風險，而且影響程度大的風險，一定要跟蹤落

5、實到底，直到該風險消失或解除；其次，在項目啟動的同時，項目經(jīng)理要編制質量保證書，保證書主要針對策劃書中項目各階段的輸出的保證，并將該質量保證書提交SQA審核，對于重大項目，交由專職SQA跟蹤與監(jiān)控。10項目經(jīng)理應知應會的計劃有哪些？項目策劃包括策劃整個項目的進度、資源（人力、軟硬件資源等）、財務、過程模式、風險分析等主要內容；項目策劃完成，項目經(jīng)理必須對項目的整體運作過程做到心中有數(shù)。變更計劃變更無處不在，項目經(jīng)理必須根據(jù)公司制度嚴格按照變更流程制定變更計劃（按優(yōu)先級及必要性對變更進行篩選）。開發(fā)計劃更細節(jié)的工作計劃，具體分配到開發(fā)小組或開發(fā)人員的計劃，必須明確到1-2天內的工作內容，這樣的開

6、發(fā)計劃才有價值。測試計劃需協(xié)助測試部門根據(jù)項目策劃的進度安排，制定具體的測試計劃。實施計劃視項目組的工作要求來定，如果項目組是實施產(chǎn)品或者包括做簡單的二次開發(fā)，實施計劃基本上可與項目策劃同等作用（或用項目策劃來涵蓋），否則便是項目后期的試運行、驗收等工作的計劃編排。其余的還要明確：配置管理計劃、質量保證計劃、技術評審計劃、月度/周工作總結計劃等等。綜上，凡事預則立，項目經(jīng)理應排除“計劃不如變化快”的消極心理，要知“如果沒有計劃，變都不知如何變！”11制定計劃應注意哪幾個方面？a) 不能只關注時間，而要看人日工作量，往往一個項目的實施周期是合同定好的，這樣項目經(jīng)理編制計劃時已經(jīng)約束好了大的時間節(jié)

7、點，編制計劃多數(shù)是編制人日安排；同時注重人日工作量還有助于項目經(jīng)理更加關注成本和組織協(xié)同。b) 安排工作計劃應明確到1-2天的工作量和內容，天數(shù)粒度大會導致無法準確控制；c) 不要忽視周計劃的重要性和作用，周計劃是最為明確也最易有效控制的計劃；d) 不要忽視階段總結，計劃和總結往往是同時的，只有通過好的總結，識別出遺留問題，才能更好的編制下一階段計劃；12如何使項目組人員充分明確并重視計劃？首先要使項目組人員明確計劃，要明確計劃就需要項目組每個人都明確的知道自己應該做什么，可以通過計劃分解來實現(xiàn)。大計劃分解為小計劃、組內計劃分解為個人計劃，要充分調動團隊每個成員的主動性，自行分解匯總。其次，明

8、確了計劃還要使組內人員認識到計劃內容的重要性，讓每個人知道為什么做，同時對計劃引起足夠的重視，這需要項目組以透明的方式進行管理和溝通，如可通過例會方式將每個人的工作成果展示給大家等等。需求調研階段13如何開展需求調研？1） 實施人員在接到調研任務后，首先應從項目經(jīng)理、售前技術支持以及銷售三方獲取到客戶相關需求信息（包括技術方案、客戶原始需求）2） 告知客戶方我們調研工作方法：首先提供產(chǎn)品調研模版于客戶，針對該模版進行解釋，對客戶進行培訓，如何按照該模版描述自己的需求3） 給客戶布置任務，按照我們提供的模版把企業(yè)實際業(yè)務流程寫出4） 分析客戶提供的業(yè)務流程文檔，與客戶一起分析改善點5） 根據(jù)討論

9、確定的思路修改業(yè)務流程文檔，收集或設計相關表單報表；讓用戶管理層簽字確認業(yè)務流程文檔。6） 將業(yè)務流程文檔按照公司標準的需求規(guī)格說明書格式轉化14需求調研人員應避免在哪些方面陷入 “鉆牛角”？調研人員往往會在調研過程中陷入以下困境：1） 與客戶過分強調技術實現(xiàn)細節(jié)2） 調研過程忽視技術實現(xiàn)而承諾過多業(yè)務功能之外的軟件需求3） 過分追求完美，在業(yè)務實現(xiàn)上，客戶沒有提出的需求，主動提出和承諾15如何處理客戶不合理需求及軟件期望？1） 不要當場否定或承諾客戶提出的需求2） 尋求對方項目經(jīng)理幫助，分析客戶需求提出的不合理性或者過高期望可能帶來的風險3） 如果客戶最后堅持要實現(xiàn)，而需求又不在前期范圍中，

10、最后統(tǒng)一匯總，讓對方項目經(jīng)理，甚至更高層領導簽字，明確描述該部分需求對后期的可能影響16如何處理調研中客戶消極不配合的情況？對該類客戶，首先向對方表示感謝，希望得到工作上的支持；其次，多從對方角度考慮問題，分析客戶不配合原因，從中找出客戶的真正關注問題和希望解決的問題；如果是屬于對方因為自身工作任務重，尋求項目經(jīng)理幫助，找到客戶的領導，在此期間能夠分擔部分客戶的本職工作，并表示感謝；如果是其他原因，請對方項目經(jīng)理幫助，做好客戶思想工作；不管是什么情況，絕對不能出現(xiàn)向客戶方任何人抱怨客戶不配合；17如何同時展開多個業(yè)務模塊的需求調研？調研人員在調研時，一定避免所有的事情都由自己主導完成，要充分發(fā)

11、揮客戶的參與性和積極性；首先在我們調研方法上，將需要調研的業(yè)務流程交給客戶，即給客戶布置作業(yè)；讓用戶在一段時間內按照我們的要求提交相應的資料或文檔；調研人員找出時間差，在時間差的范圍內分別與不同用戶討論業(yè)務流程。18需求調研中有咨詢服務時，如何做好與咨詢顧問的配合？1） 與咨詢顧問溝通確認我們的工作方法和工作模版，在任務上進行分工；盡量做到用文檔進行輸出交接。2） 時刻提醒咨詢顧問圍繞軟件界定需求范圍與客戶討論，不要超出需求范圍設計與開發(fā)階段19如何制定設計開發(fā)計劃?設計開發(fā)計劃的制定主要有以下幾個步驟：1、獲取需求文檔和項目相關約束信息2、根據(jù)輸入信息做出適合的WBS（一般是3級）3、進行階

12、段劃分，確定里程碑，進行工作量評估4、制定網(wǎng)絡圖，找出關鍵路徑5、根據(jù)網(wǎng)絡圖，制定甘特圖計劃6、確認所需的資源（包括人力、設備等）并進行責任分配，形成具體計劃7、在計劃執(zhí)行過程中，及時跟蹤，并適時進行調整，直至任務完成20設計開發(fā)計劃中各項任務應該細化到何種顆粒度？具體的設計開發(fā)計劃中的各項任務應盡可能細化到0.52個工作日。21開發(fā)模型的選擇？建議采用迭代化的開發(fā)方法一個項目的好壞，開發(fā)模型優(yōu)良是項目成功重要保障，有了好的開發(fā)模型我們可以很好的控制項目進度、降低風險。所以我們在項目開始前首先需要確定項目的開發(fā)模型。這里我們建議采用迭代式的開發(fā)模型。我們知道原有早期傳統(tǒng)的開發(fā)模型是一個文檔驅動

13、的流程，它將整個軟件開發(fā)過程劃分為順序相接的幾個階段，每個階段都必需完成全部規(guī)定的任務后才能夠進入下一個階段。項目開始首先完成系統(tǒng)需求規(guī)格說明書，之后才能夠進入概要設計階段，編碼則在系統(tǒng)設計完成之后進行。這就意味著只有當所有的系統(tǒng)模塊全部開發(fā)完成之后，我們才進行系統(tǒng)集成，對于一個由很多個模塊組的復雜系統(tǒng)來說，這是一個非常艱巨而漫長的工作，且存在著潛在的風險。   如：需求或者設計中的錯誤無法在項目早期發(fā)現(xiàn)，只有在系統(tǒng)交付客戶之后才能發(fā)現(xiàn)原先對于需求的理解是錯誤的，系統(tǒng)設計的錯誤也只有在測試階段才能被發(fā)現(xiàn)。 對于項目風險的控制能力較弱，往往項目風險只能隨著

14、項目結束才能逐步降低，同時也只有經(jīng)過系統(tǒng)測試之后，才能確定設計是否能夠真正滿足系統(tǒng)需求。 為了解決傳統(tǒng)軟件開發(fā)流程中的問題，我們建議采用迭代化的開發(fā)方法來取代瀑布模型。在瀑布模型中，我們要完成的是整個軟件系統(tǒng)開發(fā)這個大目標。在迭代化的方法中，我們將整個項目的開發(fā)目標劃分成為一些更易于完成和達到的階段性小目標，這些小目標都有一個明確的階段性評估標準。迭代就是為了完成一定的階段性目標而所從事的一系列開發(fā)活動，在每個迭代開始前都要根據(jù)項目當前的狀態(tài)和所要達到的階段性目標制定迭代計劃，整個迭代過程包含了需求調研、軟件設計、軟件實現(xiàn)、版本集成、軟件測試、軟件發(fā)布和產(chǎn)品交付等各種類型的開發(fā)活動，

15、迭代完成之后需要對迭代完成的結果進行評估，并以此為依據(jù)來制定下一次迭代的目標。   22何時開始進行程序集成？從開始有代碼的第1天起就要進行集成，而且是持續(xù)集成，直到通過測試，交付客戶正式使用。這個第1天通常情況下，還沒有開始進入編碼階段，而只是設計的初級階段或中間階段。23在編寫代碼時是先寫代碼還是先寫注釋？我們采用的是單元測試驅動的方式進行開發(fā)，先寫測試代碼，再寫程序代碼；但在代碼編寫之前最好先寫注釋，對于復雜邏輯要寫出詳細的偽代碼。24編寫注釋有哪些主要事項？(1)必須是有意義；(2)必須正確的描述了程序； (3)必須是最新的。 注釋必不可少，但也不應過多，

16、以下是四種必要的注釋： a.標題、附加說明； b.函數(shù)說明：對幾乎每個函數(shù)都應有適當?shù)恼f明，通常加在函數(shù)實現(xiàn)之前，在沒有函數(shù)實現(xiàn)部分的情況下則加在函數(shù)原型前，其內容主要是函數(shù)的功能、目的、算法等說明，參數(shù)說明、返回 值說明等，必要時還要有一些如特別的軟硬件要求等說明； c.在代碼不明晰或不可移植處應有少量說明； d.及少量的其它注釋。 25在設計開發(fā)中遇到問題怎么辦？1）如果是各模塊公用接口等共性的問題需要及時召集相關人員，一起協(xié)商優(yōu)先解決；協(xié)商后，明確具體負責人，由該人負責，其他人協(xié)助解決；2）如果是個人初次遇到的問題，建議個人先獨立進行解決，根據(jù)影響程度，如果超過0.52個小時仍未解決，請

17、咨詢其他同事。3）作為小組組長或項目負責人，應經(jīng)常性的與組員進行溝通，及時發(fā)現(xiàn)影響進度的問題或瓶頸，并及時解決，做到日清周清；對于大家經(jīng)常性遇到的問題，及時進行總結，形成指導手冊并不斷補充完善。26在編碼中有哪些注意事項？遵循公司制定的統(tǒng)一的編碼規(guī)范。下面列舉其中的幾點共參考：u 清晰易讀的源程序文件結構： 每個程序文件應由標題、內容和附加說明三部分組成。 （1）標題：文件最前面的注釋說明，其內容主要包括：程序名，作者，版權信息，簡要說明 等，必要時應有更詳盡的說明（將以此部分以空行隔開單獨注釋）。 （2）內容控件注冊等函數(shù)應放在內容部分的最后，類的定義按private 、 protected

18、 、 pubilic的順序，各部分中按數(shù)據(jù)、函數(shù)、屬性、事件的順序。（3）附加說明：文件末尾的補充說明，如參考資料等，若內容不多也可放在標題部分的最后。u 一致的界面設計風格u 統(tǒng)一的編輯風格： （1）縮進：縮進以 Tab 為單位，一個 Tab 為四個空格大小。全局數(shù)據(jù)、函數(shù) 原型、標題、附加說明、函數(shù)說明、標號等均頂格書寫。 （2）空格：數(shù)據(jù)和函數(shù)在其類型，修飾名稱之間適當空格并據(jù)情況對 齊。關鍵字原則上空一格，不論是否有括號，對語句行后加的注釋應用適當空格與語句隔開并盡可能對齊。 （3）對齊：原則上關系密切的行應對齊，對齊包括類型、修飾、名稱、參數(shù)等各部分對齊。另每一行的長度不應超過屏幕太

19、多，必要時適當換行。 （4）空行：程序文件結構各部分之間空兩行，若不必要也可只空一行，各函數(shù)實現(xiàn)之間一般空兩行。 （5）按照6所述編寫注釋u 嚴格按照命名規(guī)范進行命名27開發(fā)人員為什么要進行自測？開發(fā)人員的測試是保證代碼能正常運行，在開發(fā)時候發(fā)現(xiàn)的錯誤往往比較容易修正。(另外一個好處就是沒有人來罵你。因為只有你自己知道)。但是一旦軟件到了測試小組那里出了問題，那么就多了很多時間來修正BUG，如果到了客戶哪里才發(fā)現(xiàn)的BUG，那么時間就更長了，開發(fā)人員本身受到的壓力也是到了最大化了。另外開發(fā)人員的測試除了保證代碼能正常運行以外，還有一個很重要的方面就是要保證上次能正常運行的代碼，這次還是能正常運行

20、。如果做不到這點，那么BUG就不斷的會出現(xiàn)，很多BUG也會反復出現(xiàn)。于是軟件看上去就有修補不完的BUG了。28如何進行組內成員配置 ？項目啟動之前除項目管理者著手計劃制定外，同時也需要對其項目組成員配置進行規(guī)劃，界定其職責。通常我們需要幾種角色：技術組長：負責技術難題攻關，組間溝通協(xié)調。需求人員：負責將用戶需求轉換成項目內的功能需求和非功能需求，編制項目需求規(guī)格說明書，針對每個迭代集成版本與用戶交流獲取需求的細化。 設計人員：負責對需求規(guī)格說明書，進行系統(tǒng)設計。開發(fā)人員：實現(xiàn)設計，完成用戶功能。集成人員：負責整套系統(tǒng)的編譯集成，督促小組系統(tǒng)功能提交，及時發(fā)現(xiàn)各模塊集成問題，

21、起到各小組之間的溝通的紐帶。 測試人員：對于集成人員集成的版本進行測試，盡可能的發(fā)現(xiàn)程序缺陷，以及未滿足需求的設計。文檔整理人員：負責對小組內產(chǎn)生文檔的整合，統(tǒng)一。 系統(tǒng)環(huán)境人員：負責系統(tǒng)編譯環(huán)境、運行環(huán)境規(guī)劃。編制系統(tǒng)環(huán)境說明書。 維護人員：系統(tǒng)驗收后，維護人員，建議維護人員早期進入項目參與項目測試以便順利承擔起項目維護職責。  在設計開發(fā)階段，對以上各個角色都需要，往往一個小組成員只有24人，我們可以根據(jù)實際需要1人承擔多個角色。29如何進行組內溝通 ？通常口頭溝通是最為常見的，這種溝通快捷、方便。一般的小問題或者是簡單問題的理解非常有效，

22、但問題復雜或是此次溝通需要后續(xù)使用，那么該種溝通則存在問題，則需要以書面方式加口頭相結合最為有效。即可在本次溝通中方便、快捷的領會，也可以為后續(xù)工作提供依據(jù)。項目組內部溝通不是越多越好，你會發(fā)現(xiàn)當內部的溝通時間沒有規(guī)律或是溝通時間過長，這樣其實也會嚴重影響項目成員的開發(fā)進度，但溝通又是必不可少，何種間隔最為適宜了？這是不好定的，通常以評審作為溝通的基礎，平日的溝通建議項目組成員在每天工作過程遇到問題，將其記錄下來，然后在以郵件方式發(fā)送給需要溝通或者詢問者。大家可以每天下班之前收取郵件，對于可以直接回答的問題則直接以郵件方式回復，對于無法直接答復而只需與提出問題者討論的問題，則可以在第二天上班前

23、進行商議確定。而需要眾人一起討論的問題，則放到每周會議上討論。非常緊急的話則可以馬上約齊人員討論，通常有良好的溝通方式話，這種非常緊急的問題是不常見的?，F(xiàn)場實施階段30項目實施階段的主要工作有哪些？在項目實施階段，主要有以下工作（按先后順序列舉）：（1） 基礎數(shù)據(jù)準備（2） 軟件安裝調試（3） 用戶培訓（一般分管理員培訓和業(yè)務操作培訓兩個部分）（4） 試運行（必要時需進行應用輔導）（5） 項目總結（6） 驗收在上述工作開展之前，要制定詳細的實施計劃，計劃需和客戶充分溝通并獲得認可。31基礎數(shù)據(jù)的準備重不重要？基礎數(shù)據(jù)的準備和錄入，是系統(tǒng)運行的基礎，故控制好這個環(huán)節(jié)也至關重要。大長江檢驗模塊，在

24、系統(tǒng)試運行前，配備了4名專職錄入員4個月才完成了基礎數(shù)據(jù)“檢驗卡片”的錄入工作（總共5000張檢驗卡片），可見，提前進行基礎數(shù)據(jù)的收集并做好相應的錄入準備是非常重要的。32軟件安裝調試時有哪些注意事項？（1） 在到客戶現(xiàn)場前，需提前與客戶確認硬件、軟件及網(wǎng)絡環(huán)境已配備到位；（2） 如需與第三方軟件系統(tǒng)做接口，需確認對方配合人員能按時到位；（3） 給客戶方安裝的任何商業(yè)軟件，如Windows操作系統(tǒng)、Oralce/SqlServer數(shù)據(jù)庫等，都應由客戶方提供（在合同中明確提出由我方提供的除外）。33問開展軟件培訓時會遇到什么困難？遇到困難后我們該怎么辦？ 培訓時可能會遇到各種的困難，如硬件不到位

25、，人員不到位等，這個時候需要我們和客戶方領導確認一個培訓負責人，所有培訓事項直接由他來負責，如培訓人員組織，培訓場地，培訓所需電腦及其他硬件，這樣，通過客戶方自上而下施加壓力的方式可以順利的完成客戶培訓，避免項目在等待中延期和超支。另外需要注意的是，在培訓階段，必須要求客戶有一個負責軟件維護的人員全程參與整個培訓。這個對客戶和我們都有好處，以后客戶對軟件后期一些維護接手快，我們后期工作也輕松。34項目總結匯報時有哪些注意事項？項目總結匯報一般是項目驗收的前奏，這個環(huán)節(jié)也至關重要，如果能把握好項目總結匯報，得到客戶的驗收簽字就容易多了。在做項目總結匯報時，有以下注意事項：（1） 匯報的內容需要提

26、前預審，預審人員不僅是本公司相關人員，更重要的是需要客戶方項目組、特別是項目經(jīng)理及主要負責人參與，一來獲得他們的認同和支持，二來他們的總結對客戶高層來說更有分量和說服力?。?） 總結匯報一定要邀請對方相關主要領導參加，如果他們不能參加，總結匯報的價值就降低了不少?？偨Y匯報是一個承前啟后的過程，在匯報結束時，需要展示后續(xù)的驗收日程表，以推進驗收工作的展開。35異地實施時的計劃與客戶計劃如何銜接？首先明確一般客戶方負責項目的人員是兼職的（可能負責多個項目或其他本職工作，即使客戶方專門指派了項目的負責人），而我們作為實施方是專職的；其次明確所有項目計劃都是我方項目經(jīng)理應該專職編制和總結的，包括參考客

27、戶方有關項目的計劃和要求，明確總的推動一般是以我方為主，排除被動工作的心理；最后，我們的項目實施計劃均需要客戶相關人員配合完成，下一步計劃需要提前告知相關人員，有沖突時及時調整，以免執(zhí)行計劃工作時，客戶出現(xiàn)無法配合的情況；36異地實施時，如何有效組織項目小組的具體工作（計劃和會議相關）？項目組總結計劃必須和客戶方項目相關人員一同協(xié)商通過；避免單方面提出計劃安排；項目組異地工作的效果，往往取決于客戶的參與度和支持度，項目經(jīng)理要靠計劃及相關會議做好各個層面的充分溝通；試運行階段37在試運行階段如何與不同角色的客戶進行溝通？試運行階段應確定雙方的溝通接口人員，我方主要與客戶方的接口人員進行直接溝通。

28、該接口人員可以是業(yè)務部門的具體試運行負責人，也可以是信息部門的具體試運行負責人。對于業(yè)務問題，主要來自于對方的基層使用人員，而大面積基層用戶都習慣和自己人交流解決問題，所以我們應委托業(yè)務部門的具體試運行負責人來收集基層使用人員提出的各類問題，由其匯總后定期與我方溝通。業(yè)務部門的負責人員往往對基層業(yè)務非常了解，此類溝通方式可以清晰的處理各類業(yè)務問題，但對于技術類問題應考慮業(yè)務人員的實際情況，必要時可以借助于對方信息部門的相關人員協(xié)調解決。如果接口人員是信息部門的具體試運行負責人，此類溝通往往不能徹底有效的弄清業(yè)務問題，此時可以通過接口人員聯(lián)系基層的使用人員，進行直接溝通。溝通時切記要因材施教和對

29、癥下藥，不要與技術人員過于深究業(yè)務細節(jié)，也不要對業(yè)務人員使用不恰當?shù)募夹g術語。38系統(tǒng)試運行期間有哪些注意事項？（1） 客戶提出的任何問題或要求，需及時響應并記錄；如果是需要我方來處理的問題，則需給出處理措施和計劃完成日期；（2） 在試運行階段，項目組應積極推動用戶來使用系統(tǒng)，如果使用方不積極而我們又沒有推動的話，試運行就達不到應有的效果，最終很可能影響項目的按時驗收；（3） 在試運行階段，項目組的工作重心應該不單是保障系統(tǒng)的穩(wěn)定運行，還應觀察和總結試運行的效果并提取運行數(shù)據(jù)，這樣做的目的是：1) 對系統(tǒng)的作用進行評估；在緊接下來的驗收和項目總結階段有據(jù)可依、有話可說。39如何處理用戶試運行期

30、間發(fā)現(xiàn)的BUG？軟件存在問題是客觀的，即使是在規(guī)范的質量保證體系下經(jīng)過了嚴格的單元測試和系統(tǒng)測試，也沒有不存在BUG的軟件。而用戶往往有意識無意識假定軟件就應該是沒有問題的，這是我們可以預見的項目風險。因而對于試運行期間由用戶發(fā)現(xiàn)的BUG，我們應該虛心聽取，誠懇致歉，及時解決，并且自發(fā)的進行舉一反三的復查工作，爭取先于客戶發(fā)現(xiàn)潛在的BUG，保護來之不易的用戶滿意度。同時，應該形成詳細的BUG記錄定時提交給質量保證部門，以形成逐漸完善的知識經(jīng)驗庫，助以提高未來項目的測試針對性和覆蓋率。40如何處理用戶試運行期間提出的修改要求？任何項目都有明確的合同約束邊界，而基層用戶在試運行期間提出的問題往往是

31、不會考慮這一約束邊界的。對于用戶提出的任何問題，都不應即時承諾，一旦輕易承諾，將導致項目的邊界無休止的變更，嚴重模糊項目目標，項目的修改將不斷擴散，而距驗收目標愈行愈遠。我們要做的是如實的做好記錄，進而進行邊界分析，分清哪些是合同范圍內的修改要求，哪些是超出合同范圍的修改要求，對于這些要求分類進行處理。41如何處理超出合同范圍的修改要求？ 用戶在需求調研階段所提出的需求是存在局限性的，在實際應用后難免產(chǎn)生一些新的業(yè)務思想，希望也通過系統(tǒng)加以解決，這些業(yè)務需求可能包含很有價值的需求，也可能是未經(jīng)過深思熟慮就提出的，還可能是希望我們的系統(tǒng)兼?zhèn)淦渌到y(tǒng)的功能。對于有價值的需求，應充分肯定用戶的修改意

32、見，在進行必要的分析后，與公司內部相關部門溝通，采取相應的產(chǎn)品升級或其它相應措施，并通過銷售人員盡力做好后期的鋪墊，引導用戶以長期合作的視點考慮這類需求，在后期的系統(tǒng)中滿足其要求。對于未經(jīng)過深思熟慮的修改要求，應引導客戶理智分析這類需求是不是必要的、非改不可的，力爭以現(xiàn)有功能滿足其要求。而對于用戶希望兼?zhèn)淦渌到y(tǒng)功能的需求，應站在系統(tǒng)規(guī)劃的高度上引導客戶，建議其采購我方對應的專業(yè)解決方案，或尋求其它廠商的對口解決方案。42如何處理合同范圍內的修改要求？在試運行期間客戶反饋的問題，確認是合同范圍內的，需登記到項目試運行問題記錄，如果屬于產(chǎn)品部分的問題，則需同時登記到產(chǎn)品實施問題記錄并反饋給產(chǎn)品實

33、施總監(jiān)，產(chǎn)品實施總監(jiān)對問題進行分析，如果屬于產(chǎn)品自身原因導致的問題，則提交產(chǎn)品部修改，產(chǎn)品部修改完成后，提交給產(chǎn)品實施總監(jiān)，實施總監(jiān)再提交給實施部進行更新；如果是其它原因，則將相應情況反饋給實施部。43對于試運行階段由實施部進行修改的內容，處理流程是怎樣的？按照實施部項目管理制度，項目試運行階段流程如下44如何處理試運行時發(fā)現(xiàn)的系統(tǒng)性能與效率類問題？企業(yè)用戶的數(shù)據(jù)量巨大，這在我們的系統(tǒng)測試過程中是很難完全模擬的，對于此類問題我們應該做好充分的思想準備。對于此類問題，一般可通過改進程序算法、改進數(shù)據(jù)庫存取邏輯、統(tǒng)計結果預處理等手段加以解決。由于在需求調研階段一般已經(jīng)向用戶明確定義好系統(tǒng)運行的硬件

34、要求，因而在處理性能與效率類問題時，不到萬不得已，絕不可建議用戶升級硬件配置。45如何交付修改內容？試運行期間修改的內容一般需制作成補丁包，補丁包內含有修改或新增的程序文件、自動應用補丁的dos批處理或unix/linux腳本文件以及補丁的使用說明。補丁應經(jīng)過系統(tǒng)測試后方能交付。視補丁包的體積大小，可采用郵件交付或刻錄光盤交付的方式。46公司制度中關于試運行階段的程序和文件有哪些？試運行階段需參照的制度包括：項目實施與維護規(guī)程、產(chǎn)品實施配合規(guī)范試運行階段應記錄的文件包括：項目試運行問題記錄、產(chǎn)品實施問題記錄、項目需求變更記錄47試運行階段在為人處事上要注意哪些方面？公司資源有限，負責試運行階段

35、的項目成員往往還肩負著其它任務，想每個項目都應該全力以赴是很困難的。這樣難免讓用戶覺得我們響應不及時，有問題不解決，特別有些問題不是我們一個個體能夠解決的，長期下來用戶可能會積累很多的怨氣。因此試運行階段的負責人員平時要牢記以下幾點：做不到的事情千萬別隨意承諾；承諾的事情一定要努力做到；每次做到的事情都進步一點點。有這三條用戶會慢慢接受稍微長一點的響應周期，也會用更多積極性眼光看現(xiàn)在的問題，也相信問題一定有人響應，也一定可以得到解決。48如何組織高層匯報？a） 明確匯報對象；匯報對象不同匯報資料的組織方式不同，業(yè)務部門主管、技術主管更加關注工作內容和解決方案的描述是否充分，廠級領導更加關注項目

36、的整體運作層面的內容，如：如何有效組織、取得的成果、發(fā)揮的價值等；b） 事先向相關人員發(fā)出通知（客戶人員尤其是領導層并不是隨定隨到的），明確匯報時間、內容、人員，最遲提前3天發(fā)出通知；c） 高層匯報的內容，需要在項目組（包括客戶方項目組相關人員）提前預審的；d） 根據(jù)匯報對象和內容，項目經(jīng)理明確判斷出，我方應由哪個層面的哪個領導出面參加或者不參加；49高層匯報應注意哪些匯報內容？項目經(jīng)理應充分認識到，高層匯報是獲取客戶方及我方領導高度關注和支持的絕好時機，不要錯失充分展示項目成果和請求支持的機會；往往在匯報中要注意以下幾點：a） 具有圖文并茂的展示效果，避免純文字性的描述，符合高層負責人的思維

37、習慣；b） 重點講述項目在歷程中取得的成果，并通篇貫穿客戶方項目組及相關負責人付出的努力；c） 不能簡單的只提出支持建議，而是要將為何這樣建議的緣由講清楚即基于建議的內容，如果能夠獲得支持，項目的成果會如何更好；即講建議時，要提前做好伏筆；d） 如果匯報時，需要暴露問題，也要將問題歸于實際客觀的情況，避免人為或主觀上的不足因素（如第三方系統(tǒng)的接口暫未實現(xiàn)導致而不要去說“第三方項目組人員不夠導致接口未實現(xiàn)，從而導致”）；e） 拋露問題的同時，項目組要給出建議，而不能只談問題，不談如何解決；50高層匯報的資料準備的幾點建議a) 高層的時間是有限的，而且可能在匯報時就發(fā)生變化（原定1小時，卻臨時改為

38、30分鐘），這要求項目經(jīng)理在匯報前，組織資料要充分，認真將資料篇章組織好，并備好不同時間段的講解方式；b) 組織的第一階段資料要全而大，而后進行提煉總結，再提煉再總結；須知“臺上10分鐘，臺下10年工”的含意；c) 對組織的資料能夠“見一說十”，可視化的資料部分是經(jīng)過抽斂的，要想講清楚，需要背后的資料做支撐；一旦領導針對某個細節(jié)展開來問，要有理有據(jù)，以數(shù)據(jù)和資料說話；51如何增強匯報自信心？做好知己知彼的工作：知己要對自己的工作內容有充分的認識，這來源于自身日常的工作積累，對自己的日常工作能夠細心觀察、認真總結；知彼要知道本次匯報的領導關注點是什么；獲取客戶方項目組負責人的支持，從項目角度講，

39、我方項目組和客戶方項目組負責人是站在同一立場的戰(zhàn)友！匯報的內容應獲取他們的認可和支持，要達到項目組內的口徑一致，這樣在匯報時，才不至于被客戶孤立；52其他匯報工作的注意事項項目經(jīng)理做工作匯報不單單代表項目組，還是代表公司，項目經(jīng)理的形象即代表了公司的形象，交流時應注意言語和著裝；維護階段53維護人員面對完全陌生的項目如何快速入手進行維護？在項目維護過程中往往會出現(xiàn)維護人員完全沒有參與項目前期的需求調研、框架設計、開發(fā)、實施等，維護人員應首先閱讀項目的需求報告、設計報告、實施方案及用戶手冊等文檔了解項目的需求和設計架構，從宏觀上入手逐步熟悉整個項目，熟悉項目后再和用戶進行溝通交流，進而才能針對用戶提出的問題進行分析并給予維護。在不熟悉項目的情況就對用戶提出的問題進行修改往往會出現(xiàn)修改后的結果不是用戶想要的，結果事倍功半。54在對數(shù)據(jù)維護過程中怎樣避免造成重大損失？維護人員參與的是項目已經(jīng)開始上線運行后的維護階段，此時系統(tǒng)中已經(jīng)存在一些用戶工作中的數(shù)據(jù)。遇到和數(shù)據(jù)庫中數(shù)據(jù)相關的維護時一定要先備份數(shù)據(jù)庫，一定要在用戶不使用系統(tǒng)的情況下進行數(shù)據(jù)庫更新，避免因為一時圖方便不小心給用戶造成重大損失，數(shù)據(jù)庫在沒有備份的情況下一旦維護過程中出現(xiàn)問題往往是比較難恢復的。55維護過程中如何避免根據(jù)用戶提出的問題修改后的結果不是用戶所要的結果？在自己機器上搭建用戶系統(tǒng)運行環(huán)境一樣