【正文】 風(fēng)險控制 制定了風(fēng)險防范計劃后，風(fēng)險并非不存在，在項目執(zhí)行過程中，需要時刻監(jiān)督風(fēng)險的發(fā)展與變化情況，并確定隨著某些風(fēng)險的消失而帶來的新的風(fēng)險。 制定風(fēng)險應(yīng)對策略在某種程度上決定了采用什么樣的項目實施方案。 E 級 —— 幾乎不可能發(fā)生，或者發(fā)生風(fēng)險對項目的影響及其輕微。 C 級 —— 有可能發(fā)生風(fēng)險，風(fēng)險發(fā)生后對項目產(chǎn)生影響，但不會造成項目停滯。 風(fēng)險等級： A 級 —— 有極大可能發(fā)生風(fēng)險，并且風(fēng)險一旦發(fā)生對項目將造成致命影響。對子任務(wù)從責(zé)任人、執(zhí)行過程、所需資源是否充足、任務(wù)能否按時完成和任務(wù)不能按時完成對項目有什么影響等方面進行風(fēng)險分析，從而得出項目整體風(fēng)險。 以下模型庫可供參考： 風(fēng)險類別 風(fēng)險內(nèi)容 市場風(fēng)險 ? 市場風(fēng)險 快速的市場風(fēng)險會導(dǎo)致方向上的突發(fā)變化； ? 選定行業(yè)程序 新標準等； ? 法律事務(wù) 爭端、訴訟或法院決議； ? 軟件公司市場戰(zhàn)略和優(yōu)先次序變化 財務(wù)風(fēng)險 ? 項目組成本超支； ? 估計不準或差錯導(dǎo)致的未預(yù)見的財務(wù)支出； ? 預(yù)算和進度超計劃； ? 公司縮減財務(wù)費用； 組織風(fēng)險 ? 組織結(jié)構(gòu)，項目組成員的選擇，是否建立了激勵考評 機制以及激勵機制的有效性； ? 項目經(jīng)理的職責(zé)、權(quán)力是否明晰，尤其是用戶項目經(jīng)理是否已 得到授權(quán)，在項目實施的相關(guān)部門擁有權(quán)威； 項目組織的文化氛圍差異導(dǎo)致的風(fēng)險 如項目小組成員之間 的矛盾導(dǎo)致團隊合作精神的削弱； 技術(shù)風(fēng)險 ? 項目實施的范圍界定不明確，用戶需求描述的不準確 由此引發(fā)的爭議極大的影響著項目成果，必要時應(yīng)該對合同重新審定； ? 硬件和網(wǎng)絡(luò) 硬件存在質(zhì)量問題或網(wǎng)絡(luò)設(shè)計存在缺陷； ? 操作平臺、數(shù)據(jù)庫選用不合適； ? 不成熟的軟件產(chǎn)品導(dǎo)致問題產(chǎn)生 軟件運行響應(yīng)慢，軟件缺陷、差錯； ? 實施所采用的產(chǎn)未經(jīng)過嚴格測試可能存在很多問題； ? 系統(tǒng)安全 用戶不注意口令保密、超級用戶授權(quán)多人等； ? 項目中采用新技術(shù) 采用新技術(shù)或技術(shù)創(chuàng)新無疑是提高項目績效的重要手段，但這樣也會帶來一些問題，許多新的技術(shù)未經(jīng)證實或并未被充分掌握，則會影響項目的成功； 其它風(fēng)險 ? 項目經(jīng)理 項目經(jīng)理是項目的靈魂人物，一名稱職的項目經(jīng) 理應(yīng)不斷提升自己的領(lǐng)導(dǎo)能力、業(yè)務(wù)素質(zhì)、技術(shù)能力、市場與客戶意識，還要特別關(guān)注團隊文化的建設(shè)； ? 項目組成員 小組成員的業(yè)務(wù)知識、技術(shù)水平、開發(fā)能力、 實施經(jīng)驗等； ? 團隊精 神 倡導(dǎo)有魅力的團隊文化，組員認可和尊重、自信 和信任、分工協(xié)作的良好平衡、愉快和上進的氣氛、遵守共同規(guī)范、多層次交流和溝通等； ? 人員變更 企業(yè)領(lǐng)導(dǎo)層的人事變動，項目組成員調(diào)整、辭職等； 融洽的客戶關(guān)系 雙方人員能否緊密合作，尤其是雙方項目 經(jīng)理的團結(jié)協(xié)作對項目的順利開展及其關(guān)鍵； （ 2） 流程圖法 制作項目的整體流程圖，分析各環(huán)節(jié)可能遇到的風(fēng)險，據(jù)此推斷出項目風(fēng)險。根據(jù)項目的性質(zhì)，從潛在的事件及其后果、潛在的后果及其產(chǎn)生的原因來檢查風(fēng)險，按照風(fēng)險的特征進行歸檔，評估風(fēng)險對項目在整體上產(chǎn)生的影響，包括：影響范圍、持續(xù)時間，對項目質(zhì)量可能造成的損害、解決風(fēng)險所需要的資源和成本等，然后收集、整理可能風(fēng)險形成項目風(fēng)險列表。 項目經(jīng)理要定期到客戶的各個部門全面了解產(chǎn)品的實施情況，認真收集關(guān)鍵用戶和最終用戶的意見，不要一味的依靠實施人員的口頭匯報和用戶項目聯(lián)絡(luò)人員的反映。 項目經(jīng)理要經(jīng)常提醒項目組成員，不要忽視最終用戶的感受，最終用戶是系統(tǒng)的具體操作者，他們的工作積極性、對系統(tǒng)的認同程度，對項目的順利實施會起重要作用。 （ 4）逐級上報制度 對于項目實施過程中發(fā)生的重要事件，要逐級匯報：項目成員 — 項目經(jīng)理 —項目領(lǐng)導(dǎo)小組 — 雙方?jīng)Q策層；比如： ? 本級沒有達成解決辦法的問題 ? 用戶沒有在規(guī)定時間內(nèi)整理好基礎(chǔ)數(shù)據(jù)，從而影響實施進度； ? 雙方因為某些觀點或想法存在嚴重分歧，最后經(jīng)過協(xié)商達成一致意見； 項目經(jīng)理應(yīng)該及時通過備忘錄形式詳細記錄該事件，將來雙方如果發(fā)生意見分歧或合同糾紛時，可以備查。 （ 2）項目周報 項目周報要以郵件發(fā)送給客戶方相關(guān)人員、監(jiān)理、部門領(lǐng)導(dǎo)并抄送項目組成員。 項目經(jīng)理特別要做好以下幾方面溝通： （ 1） 項目例會 項目經(jīng)理可以與用戶方項目組每周五下午舉行一次項目例會，按照項目周報匯報項目進度，并共同探討項目實施中遇到的問題，協(xié)調(diào)資源，安排下周計劃。 其中應(yīng)該確定哪些信息需要溝通（溝通，比如用戶需求的反饋、緊急問題的反饋、階段報告、計劃變更等），在什么時間（溝通時間）將信息提供給什么人（溝通對象），以及如何將信息提供給他們（溝通渠道，如電子郵件、傳真、個別交談及現(xiàn)場管理等），正式的交流都應(yīng)該留有文檔。 要確定四級溝通 每級溝通組的溝通頻率、溝通方式。 我們將采用四級溝通管理辦法將各方項目干系人劃分為四級，具體劃分方式如下： 四級溝通組 甲方參與人 我方參與人 監(jiān)理方參與人 項目指導(dǎo)委員會 甲方參與該項目的最高領(lǐng)導(dǎo) 公司總經(jīng)理 監(jiān)理方領(lǐng)導(dǎo) 項目管理辦公室 甲方直接負責(zé)該項目的領(lǐng)導(dǎo) 部門經(jīng)理 監(jiān)理方負責(zé)人 項目管理小組 具體負責(zé)本項目日常工作的負責(zé)人 項目經(jīng)理 監(jiān)理工程師 項目實施小組 協(xié)助項目日常工作的各業(yè)務(wù)部門 人員 項目組成員 確定項目各級溝通體系 首先要在項目立項階段確定項目各級成員和甲級溝通具體人員的名單和聯(lián)系方式 （電話、 等）。 項目組成員出差時項目經(jīng)理要下達任務(wù)單，完成的問題需要客戶簽字，出差回來后交給項目經(jīng)理，項目經(jīng)理再交給質(zhì)管保存。 如果不是問題也要耐心跟客戶解釋，讓客戶 理解 接受。 （ 4） 階段評審過程中發(fā)現(xiàn)的問題； 這些過程中 收集到 的 問題 將被記錄到問題跟蹤表 ，標明缺陷類別、來源、優(yōu)先級 ， 然后由項目經(jīng)理分配人員 指定時間解決。 （ 5） 問題跟蹤表 問題跟蹤表的問題的主要來源有： （ 1） 測試發(fā)現(xiàn)的 問題 。 除了源代碼外，項目文檔等成果也要納入配置管理。在發(fā)布后要測試一下每個功能的可用性，避免發(fā)布的新產(chǎn)品出錯影響使用。從內(nèi)容上來講 主要包括： ? 文檔 ? 軟件 新版本 發(fā)布 質(zhì)量檢查 —— 是由項目開發(fā)人員技術(shù)、質(zhì)量保證小組成員客戶方業(yè)務(wù)人員對交付物進行檢查，確定它已經(jīng)完成、符合對它的描述、符合質(zhì)量標準和用戶需求。 （ 3） 測試 測試是發(fā) 現(xiàn)缺陷的主要手段，在軟件項目中要做好以下測試： ? 單元測試； ? 代碼走查 ； ? 交叉測試； ? 測試人員測試。 《評審過程檢查表》、《需求管理檢查表》、《項目計劃過程檢查表》、《項目計劃跟蹤檢查表》、《配置管理檢查表》等 （ 2） 階段評審 每個階段都要組織內(nèi)部評審，質(zhì)量管理評審的主要內(nèi)容有： ? 提交的文檔或其它成果是否齊全、是否規(guī)范； ? 是否按照規(guī)范進行了單元測試或集成測試； ? 問題跟蹤表上所列的問題有沒有按計劃解決； ? 每周是否提交了項目周報； ? 系統(tǒng)原型演示或系統(tǒng)功能演示。 質(zhì)量控制 （ 1） 定期檢查 質(zhì)量保證人員每月要對 QA 活動進行統(tǒng)計，質(zhì)量管理組對所有 QA 活動進行統(tǒng)計匯總，并向各工程組組長報告。實際進度表可供以后的同類項目借鑒參考。影響項目交付期限的里程碑要組織客戶和監(jiān)理評審。 (三 ) 計劃調(diào)整 每周或每階段檢查進度時如果發(fā)現(xiàn)實際進度和計劃進度脫節(jié)的情況要及時對項目計劃進行調(diào)整變更，計劃和執(zhí)行脫節(jié)將導(dǎo)致項目延遲交付或爛尾。 每個階段都要組織評審，評審包括內(nèi)部評審和外部評審，盡量在內(nèi)部評審中發(fā)現(xiàn)問題并解決問題。 （ 2） 定制項目實際進度表，每周將實際進度和計劃作對比。項目周報要列出上周計劃的任務(wù)的完成進度，對于沒按計劃完成的任務(wù)要說明原因及解決辦法 ，盡可能在下一兩周將進度趕回來，否則將面臨計劃變更的問題。很多人在寫周報的時候才會驚叫：“天啊，我這周都干了什么？”。我們要通過以下幾方面做好項目進度的跟蹤控制。盡可能按功能模塊分配任務(wù)而不是按技術(shù)模塊分配任務(wù) (如：盡量避免某人只做前臺，某人只做后臺的情況 ) （ 12） 進度計劃是否充分考慮到客戶方推進項目可能存在的阻力對進度計劃的影響？ 是否有合理的應(yīng)對措施，是否提前化解？ 通過評審對項目計劃進行把關(guān) 項目計劃制定或變更后一定要組織公司領(lǐng)導(dǎo)、專家、部門領(lǐng)導(dǎo)、質(zhì)量管理員、項目組成員進行評審，評審的依據(jù)要參考前面 12 個要點。要盡量利用項目管理工具（ Project）分析每人每天的工作時間，直到安排合理。 （ 8） 編制進度計劃時任務(wù)要找出任務(wù)間的依賴關(guān)系，沒有依賴關(guān)系的任務(wù)可并行安排。 （ 4） 是否找出了關(guān)鍵任務(wù)，關(guān)鍵任務(wù)安排的資源和時間是否充足。這里只提供一些計劃制定和評審時的 12 個要點： （ 1） 工作任務(wù)盡量要分解到比較細的粒度，但又要避免過細缺乏彈性。 在軟件開發(fā)的各階段（設(shè)計、編碼及測試），相關(guān)的開發(fā)人員應(yīng)負責(zé)維護需求跟蹤矩陣。 需求跟蹤 對一個軟件項目來說，當(dāng)需求確定下來以后，應(yīng)該保證在軟件設(shè)計過程中每個需求都被實現(xiàn)，且項目的其它工作產(chǎn)品與需求保持一致。若估算的開發(fā)工作量大于 10 人月時，項目組項目管理委員會提出項目立項申請；若小于 10人月，且評估結(jié)果與申請部門達成共識，則開發(fā)項目組根據(jù)《變更管理規(guī)程》實施變更，若無法達成共識，則提交公司領(lǐng)導(dǎo)進行最終裁定。 需求變更申請 項目組外的需求變更，由變更申請人通過填寫《需求變更申請單》向項目組提出進行；項目組內(nèi)部的需求變更通過《軟件變更申請單》提出。 需求變更 對一個軟件項目來說，無論最初的需求分析有多么明確，開發(fā)過程中的需求變化也還是不可避免的。每個原子級需求必須滿足以下條件： 1）僅存在一條主要業(yè)務(wù)流程； 2）操作同一業(yè)務(wù)數(shù)據(jù)； 需求確認 1．需求評審 應(yīng)對所形成的需求文檔進行評審，以便作為下一階段工作的基礎(chǔ)。以表格形式給出 原子級需求必須，其它不適用 界面分析 實現(xiàn)該需求的界面風(fēng)格、表單樣式、報表格式及頁面布局。需求獲取技術(shù)包括但不限于： ? 客戶訪談 ? 客戶調(diào)查 ? 現(xiàn)場觀摩用戶的工作流程，觀察用戶的實際操作 ? 需求討論會 需求分析的內(nèi)容 名稱 內(nèi)容 適用性 功能分析 實現(xiàn)該需求軟件所須提供的功能及其含義、工作內(nèi)容 所有需求必須，非原子級需求需給出下一級的功能結(jié)構(gòu)圖 角色分析 分析該需求涉及的角色及在本需求內(nèi)容的行為 原子級需求必須，其它可選 業(yè)務(wù)流程分析 分析該需求涉及的業(yè)務(wù)流程，以流程圖或用例圖表示，并根據(jù)需要配合一原子級需求必須，其它可選 定的文字說明 數(shù)據(jù)分析 分析該需求涉及數(shù)據(jù)項的名稱、含義、格式、規(guī)則。需求信息的來源通常包括： ? 來自客戶的需求 ? 實施所滿足的需求 ? 競爭對手的產(chǎn)品優(yōu)勢與不足 （ 3） 獲取需求信息的方法。 （ 2） 明確需求信息的來源。 在招標文件及合同的基礎(chǔ)上，通過客戶溝通、需求調(diào)研進一步明確實施范圍，需求分析師應(yīng)在需求獲取前明確需要獲取的需求信息，以確保在實施需求獲取時有的放矢。發(fā)現(xiàn)和解決錯誤的時間越遲，糾正錯誤的成本就會越高。 項目組成員出差時項目經(jīng)理要下達任務(wù)單，完成的問題需要客戶簽字，出差回來后交給項目經(jīng)理，項目經(jīng)理再交給質(zhì)管保存。 站立會議制度 項目組每天都召開一個三五分鐘的站立分會，溝通前一天的情況和當(dāng)天的安排，無須會議記錄。 (五 ) 項目最后總分為各階段的評分之和。 (四 ) 項目階段考核的評分權(quán)重為質(zhì)管評分 30%，部門評分 30%，公司評分 40%。 (二 ) 評審內(nèi)容：項目實際進度與階段前計劃對比、下一階段項目計劃、項目質(zhì)量（文檔及系統(tǒng)）、客戶滿意度、風(fēng)險跟蹤。 項目經(jīng)理變更 項目經(jīng)理變更時可重新制訂項目實施計劃和成本提交審核，以免新的項目經(jīng)理受到舊項目進度滯后及成本超支帶來的考核連累。根據(jù)項目過程局部細節(jié)迭代管理的思想，在這一階段當(dāng)中，需求規(guī)格說明書、概要設(shè)計說明書、詳細設(shè)計說明書、數(shù)據(jù)庫設(shè)計說明書、測試方案、用戶手冊以及實施計劃將在過程當(dāng)中持續(xù)改進。 表 4安裝維護手冊、用戶手冊、觀看系統(tǒng)詳細演示，系統(tǒng)演示的數(shù)據(jù)和流程要模擬實際業(yè)務(wù) 部門檢查 上線運行 上線階段主要進行系統(tǒng)實施、項目試運行、客戶功能確認、需求及計劃變更管理以及項目初驗五項工作。 表 42 需求分析階段工作任務(wù) 工作任務(wù)大類 工作任務(wù)小類 具體任務(wù) 輸出