集成化軟件研發(fā)流程IDP 70

1、文件標識：集成化軟件研發(fā)流程 idp 當(dāng)前版本：7.0 作 者：林銳 審 核： 文件狀態(tài)： 草稿 正式發(fā)布 正在修改 完成日期：2009 年 11 月 上海漫索計算機科技有限公司上海漫索計算機科技有限公司 http:/ 集成化軟件研發(fā)流程集成化軟件研發(fā)流程 idpidp 7.07.0 目 錄 a. 集成化軟件研發(fā)流程圖.5 b. 過程域和主要成果清單.6 c. 研發(fā)組織結(jié)構(gòu)模型.7 d. 角色職責(zé)表.8 第 1 章 營銷客服過程.10 1.1 產(chǎn)品管理.10 1.1.1 產(chǎn)品策劃.10 1.1.2 調(diào)研分析.11 1.1.3 產(chǎn)品立項與開發(fā).12 1.1.4 產(chǎn)品銷售與服務(wù).13 1.2 銷售

2、管理.13 1.2.1 營銷策劃.13 1.2.2 銷售跟蹤.14 1.2.3 合同管理.15 1.3 客戶服務(wù).16 1.3.1 受理.17 1.3.2 處理.17 1.3.3 審核關(guān)閉.17 1.3.4 客戶反饋.17 1.4 客戶信息管理.18 第 2 章 項目管理過程.19 2.1 立項管理.19 2.1.1 立項申請.19 2.1.2 pmo受理.20 2.1.3 立項評審.21 2.1.4 項目啟動.22 2.2 結(jié)項管理.23 2.2.1 結(jié)項申請.23 2.2.2 pmo受理.24 2.2.3 結(jié)項評審.25 2.2.4 遺留問題跟蹤.25 2.2.5 項目工作總結(jié).26 2.

3、3 項目規(guī)劃與監(jiān)控.26 2.3.1 項目人員角色.26 2.3.2 任務(wù)進度管理.27 2.3.3 項目成本管理.28 2.3.4 項目評審（決策評審和技術(shù)評審）.28 2.4 變更控制.29 2.5 溝通管理.31 2.6 問題跟蹤.33 第 3 章 項目研發(fā)過程.34 3.1 需求開發(fā)與管理.34 3.1.1 需求調(diào)研.34 3.1.2 需求分析.35 3.1.3 需求定義.35 3.1.4 需求評審.36 3.1.5 需求跟蹤.36 3.2 系統(tǒng)設(shè)計.36 3.2.1 軟件系統(tǒng)設(shè)計.36 3.2.2 設(shè)計評審.37 3.3 模塊開發(fā)與集成.37 3.4 測試與缺陷跟蹤.38 3.4.1

4、 提交測試.39 3.4.2 測試準備.39 3.4.3 執(zhí)行測試.40 3.4.4 缺陷跟蹤.40 3.4.5 消除缺陷.41 3.5 交付與驗收.42 3.5.1 撰寫文檔.42 3.5.2 軟件部署.42 3.5.3 用戶培訓(xùn).43 3.5.4 試用和驗收.43 3.6 軟件維護.44 3.6.1 接受維護請求.44 3.6.2 分析維護請求.45 3.6.3 執(zhí)行維護.45 第 4 章 支持過程.46 4.1 軟件配置管理.46 4.1.1 軟件配置管理的概念.46 4.1.2 軟件代碼管理的一般規(guī)則.46 4.2 文檔管理.47 4.2.1 文檔管理的特征.47 4.2.2 項目文檔

5、管理的一般規(guī)則.48 4.3 質(zhì)量保證.48 9.4 日志和周報.49 4.5 績效評估.49 4.5.1 定義績效體系.49 4.5.2 填寫績效表格.50 4.6 知識庫管理.51 a. 集成化軟件研發(fā)流程圖 b. 過程域和主要成果清單 過程域主要工作成果 產(chǎn)品管理（產(chǎn)品策劃，調(diào)研分析，立項）產(chǎn)品建議書，產(chǎn)品調(diào)研報告，立項申請書 銷售管理（營銷策劃，銷售跟蹤，合同管理）營銷方案，銷售跟蹤表，合同管理表 客戶服務(wù)（受理，處理，關(guān)閉，反饋）客服跟蹤表 營銷 客服 過程 客戶信息管理客戶信息表 立項管理（立項申請，pmo 受理，立項評審， 項目啟動） 立項申請書，立項評審報告，項目總體計劃 結(jié)項

6、管理（結(jié)項申請，pmo 受理，結(jié)項評審， 遺留問題跟蹤，項目工作總結(jié)） 結(jié)項申請書，結(jié)項評審報告，項目工作總結(jié) 項目規(guī)劃與監(jiān)控（人員角色，任務(wù)進度，項目 成本，項目評審） 人員角色表，任務(wù)進度表，成本表，評審報告 變更控制變更控制報告 溝通管理溝通記錄 項目 管理 過程 問題跟蹤問題跟蹤表 需求開發(fā)與管理需求規(guī)格說明書，需求跟蹤表 系統(tǒng)設(shè)計系統(tǒng)設(shè)計說明書 模塊開發(fā)與集成模塊文檔（需求和設(shè)計） ，軟件代碼 測試與缺陷跟蹤測試用例，測試報告，缺陷跟蹤表 交付與驗收安裝手冊，使用手冊，驗收報告 項目 研發(fā) 過程 維護維護記錄 軟件配置管理，文檔管理，知識管理軟件配置庫，文檔庫，知識庫 質(zhì)量保證質(zhì)量保

7、證檢查表，問題跟蹤表 日志和周報工作日志，周報 支持 過程 績效分析績效報表 c. 研發(fā)組織結(jié)構(gòu)模型 營銷和客服角色 項目成員角色 支持角色 管理角色 研發(fā)總監(jiān) 銷售人員 產(chǎn)品經(jīng)理 需求分析員 系統(tǒng)設(shè)計師 pmo 項目經(jīng)理 決策委員會 開發(fā)工程師 測試人員 質(zhì)量保證員 各部門經(jīng)理 配置管理員 客服人員 d. 角色職責(zé)表 角色該角色在研發(fā)流程中的主要職責(zé) 研發(fā)總監(jiān) （1）參與立項評審，為項目分配合適的人力資源。 （2）及時了解所有項目的人力資源、進度、質(zhì)量情況，協(xié)商處理問題。 （3）在項目結(jié)束時，對項目進行綜合評估。 決策委員會 決策委員會一般由部門經(jīng)理以上職位的人員組成，主要職責(zé)是參與決策評審

8、（如立項 評審） 。 部門經(jīng)理人力資源分配和協(xié)調(diào)，提升人員的能力，考核人員績效。 pmo受理立項申請，受理結(jié)項申請，項目過程檢查。 產(chǎn)品經(jīng)理 （1）通過調(diào)研分析，進行產(chǎn)品策劃，撰寫產(chǎn)品建議書，申請立項。 （2）跟蹤產(chǎn)品開發(fā)過程，及時試用產(chǎn)品，糾正偏差，給出優(yōu)化建議。 （3）幫助銷售人員宣傳、銷售該產(chǎn)品，及時獲取客戶的反饋，改進產(chǎn)品。 銷售員（1）負責(zé)本公司產(chǎn)品的銷售，鑒定合同，跟蹤合同執(zhí)行過程。 （2）撰寫合同項目的立項申請書。 客服人員集中受理客戶問題需求，指定合適的處理人，審核關(guān)閉問題，獲取客戶反饋。 項目經(jīng)理 項目經(jīng)理是立項之后的項目主要責(zé)任人，主要職責(zé)是帶領(lǐng)團隊在預(yù)定的時間和成本之 內(nèi)

9、，開發(fā)并交付質(zhì)量合格的項目（產(chǎn)品） 。項目經(jīng)理對本項目的進度、質(zhì)量負主要責(zé) 任。 （1）負責(zé)本項目的日常管理（如任務(wù)進度管理，項目評審，變更控制，溝通管理， 問題跟蹤等） ，以及可能存在的跨項目、跨部門協(xié)調(diào)。 （2）如果本項目沒有專門的需求分析員，那么項目經(jīng)理承擔(dān)需求分析工作。如果本 項目缺乏足夠的開發(fā)工程師，那么項目經(jīng)理應(yīng)當(dāng)承擔(dān)某些模塊開發(fā)。 （3）在項目結(jié)束時，總結(jié)知識財富和經(jīng)驗教訓(xùn)，完善文檔。對項目成員的業(yè)績進行 評估。 需求分析員 （1）負責(zé)本項目需求調(diào)研、分析、定義，撰寫詳細的需求文檔。 （2）將需求準確地傳達給相關(guān)人員（如開發(fā)、測試、客戶等） ，隨著項目進展，及時 完善需求文檔。

10、系統(tǒng)設(shè)計師 （1）根據(jù)需求開展系統(tǒng)設(shè)計，包括構(gòu)架設(shè)計、數(shù)據(jù)庫設(shè)計、用戶界面設(shè)計等。 （2）撰寫設(shè)計文檔，并將設(shè)計成果準確地傳達給其他項目成員。 開發(fā)人員 （1）按照項目經(jīng)理分配的任務(wù)執(zhí)行開發(fā)工作，并清楚地交付給測試人員（準備測試） 。 如果測試人員報告缺陷，應(yīng)及時消除缺陷。對自己工作成果的質(zhì)量負最大責(zé)任。 （2）對自己的源代碼進行配置管理，撰寫自己承擔(dān)的模塊文檔。 測試人員 （1）了解項目需求，和項目經(jīng)理商議測試計劃，設(shè)計測試用例。 （2）根據(jù)計劃執(zhí)行測試，找出盡可能多的缺陷。使用缺陷跟蹤工具，及時將測試信 息反饋給相關(guān)責(zé)任人。 質(zhì)量保證員 （1）跟蹤每個項目的開發(fā)過程，重點檢查需求文檔、設(shè)計

11、文檔、變更記錄、用戶文 檔是否符合規(guī)范。 （2）參加需求評審和設(shè)計評審。 （3）如果發(fā)現(xiàn)項目問題，先和責(zé)任人溝通，如果難以解決，則由上級領(lǐng)導(dǎo)協(xié)調(diào)。 配置管理員 （1）為所有項目創(chuàng)建配置庫，為用戶分配合適的權(quán)限，負責(zé)信息安全和備份。 （2）指導(dǎo)開發(fā)人員使用配置管理軟件。 第 1 章 營銷客服過程 1.1 產(chǎn)品管理 產(chǎn)品管理流程如圖 6-1 所示，主要活動有：產(chǎn)品策劃，調(diào)研分析，產(chǎn)品立項與開發(fā)，產(chǎn) 品銷售與服務(wù)。該流程的主要工作成果和責(zé)任人見表 1-1。 圖 1-1 產(chǎn)品管理流程 主要活動主要工作成果主要責(zé)任人 產(chǎn)品策劃產(chǎn)品建議書產(chǎn)品經(jīng)理 調(diào)研分析產(chǎn)品調(diào)研分析報告產(chǎn)品經(jīng)理 產(chǎn)品立項與開發(fā)立項申請書

12、，最終產(chǎn)品產(chǎn)品經(jīng)理，項目經(jīng)理 產(chǎn)品銷售與服務(wù)產(chǎn)品宣傳材料，銷售合同，客服單產(chǎn)品經(jīng)理，銷售人員，客服人員 表 1-1 產(chǎn)品管理流程的成果清單和責(zé)任人 1.1.1 產(chǎn)品策劃 產(chǎn)品經(jīng)理負責(zé)產(chǎn)品策劃活動。產(chǎn)品經(jīng)理應(yīng)主動尋求研發(fā)部門的幫助，由產(chǎn)品經(jīng)理牽頭， 撰寫產(chǎn)品建議書 ，模板見表 1-2。 提示：本產(chǎn)品立項之后，項目團隊將進一步細化產(chǎn)品需求、設(shè)計方案和開發(fā)計劃等。 產(chǎn)品建議書 1. 產(chǎn)品概述產(chǎn)品概述 用簡練的語言說明本產(chǎn)品“是什么”， “什么用途”。 2. 產(chǎn)品開發(fā)背景產(chǎn)品開發(fā)背景 從內(nèi)因、外因兩方面闡述產(chǎn)品開發(fā)背景，重點說明“為什么”要開發(fā)本產(chǎn)品。 （1）內(nèi)因方面著重考慮：開發(fā)方的短期、長期發(fā)展戰(zhàn)

13、略；開發(fā)方的當(dāng)前實力。 （2）外因方面著重考慮：市場需求及發(fā)展趨勢；技術(shù)狀況及發(fā)展趨勢。 企業(yè) 戰(zhàn)略 調(diào)研分析 產(chǎn)品策劃 產(chǎn)品經(jīng)理 產(chǎn)品立項 與開發(fā)產(chǎn)品銷售與服務(wù) 項目經(jīng)理銷售和客服人員 3. 消費群體特征消費群體特征 （1）闡述本產(chǎn)品消費群體的特征； （2）說明消費者對產(chǎn)品的功能性需求和非功能性需求； （3）說明本產(chǎn)品如何滿足消費者的需求，以及給消費者帶來什么好處。 4. 產(chǎn)品主要功能和特色產(chǎn)品主要功能和特色 （1）產(chǎn)品的主要功能列表； （2）說明本產(chǎn)品的特色。 5. 產(chǎn)品設(shè)計方案和關(guān)鍵技術(shù)產(chǎn)品設(shè)計方案和關(guān)鍵技術(shù) （1）闡述設(shè)計方案及原理，如果有多種方案，需比較優(yōu)缺點。 （2）闡述本產(chǎn)品的一

14、些關(guān)鍵技術(shù)，評價技術(shù)實現(xiàn)的難易程度。 （3）確定哪些產(chǎn)品部件應(yīng)當(dāng)采購、外包開發(fā)或者自主研發(fā)，說明理由，分析相應(yīng)的風(fēng)險。 6. 產(chǎn)品開發(fā)和上市計劃產(chǎn)品開發(fā)和上市計劃 如果產(chǎn)品有多個版本，估算各版本的開發(fā)時間和上市時間，以及人員和資金。 表 1-2 產(chǎn)品建議書 1.1.2 調(diào)研分析 產(chǎn)品經(jīng)理在做產(chǎn)品策劃時，應(yīng)同步進行調(diào)研分析。產(chǎn)品經(jīng)理撰寫產(chǎn)品調(diào)研分析報告 ， 模板見表 1-3，目的是為公司決策提供充分的、有價值的信息。 提示：如果不做調(diào)研分析的話，那么產(chǎn)品建議和立項管理都建立在空想之上。 調(diào)研者應(yīng)當(dāng)客觀地對待被調(diào)查的事物，不可有意往“好處”或者“壞處”設(shè)想。所獲取的數(shù) 據(jù)、圖表等信息要真實并且有據(jù)

15、可查，不可憑空捏造。 調(diào)研分析的主要內(nèi)容有： 消費者（購買者，使用者，影響者）調(diào)研； 競爭對手和同類產(chǎn)品調(diào)研； 政策調(diào)研； 技術(shù)可行性分析； 知識產(chǎn)權(quán)分析； 成本收益分析； 產(chǎn)品調(diào)研分析報告 1. 消費者調(diào)研消費者調(diào)研 （1）購買者的特征和需求。 （2）使用者的特征和需求。 （3）影響者的特征和需求。 2. 競爭對手與同類產(chǎn)品調(diào)研競爭對手與同類產(chǎn)品調(diào)研 （1）各競爭對手在研發(fā)、銷售、資金、品牌等方面的實力。 （2）同類產(chǎn)品的功能、質(zhì)量、價格，以及主要優(yōu)點和主要缺點。 3. 政策調(diào)研政策調(diào)研 （1）有無政策“支持”或者“限制”。 （2）有無地方政府（或其它機構(gòu)）的“扶持”或者“干擾”。 （3）如

16、何利用（應(yīng)對）政策。 4. 技術(shù)和時間可行性分析技術(shù)和時間可行性分析 （1）本產(chǎn)品“做得了嗎？”、 “做得好嗎？”。 （2）按照正常的運作方式，能及時開發(fā)完成本產(chǎn)品嗎？投入市場的時間合適嗎？ 5. 知識產(chǎn)權(quán)分析知識產(chǎn)權(quán)分析 （1）分析是否已經(jīng)存在某些專利將妨礙本產(chǎn)品的開發(fā)與推廣； （2）分析本產(chǎn)品能否得到知識產(chǎn)權(quán)保護，如何獲得？ 6. 成本成本效益分析效益分析 （1）估算總成本。 （2）估算總收益。 表 1-3 產(chǎn)品調(diào)研分析報告 1.1.3 產(chǎn)品立項與開發(fā) 產(chǎn)品經(jīng)理負責(zé)立項申請，撰寫立項申請書 ，提交給 pmo，進入立項管理流程。 如果本產(chǎn)品被批準立項，則： 項目經(jīng)理將管理本產(chǎn)品的開發(fā)過程，對

17、產(chǎn)品的質(zhì)量和進度負責(zé)。 產(chǎn)品經(jīng)理要跟蹤開發(fā)過程，及時了解產(chǎn)品的開發(fā)進度和工作成果質(zhì)量。如果產(chǎn)品經(jīng) 理發(fā)現(xiàn)開發(fā)工作偏離了產(chǎn)品需求和預(yù)定的計劃，應(yīng)當(dāng)及時和項目經(jīng)理溝通，糾正偏 差。 建議開發(fā)團隊采用增量模式來開發(fā)產(chǎn)品，每次發(fā)布新的版本，既要請測試人員進行測試， 又要請產(chǎn)品經(jīng)理來體驗（試用） 。 產(chǎn)品經(jīng)理應(yīng)當(dāng)站在客戶的角度來體驗（試用）當(dāng)前產(chǎn)品：產(chǎn)品經(jīng)理應(yīng)當(dāng)站在客戶的角度來體驗（試用）當(dāng)前產(chǎn)品： 如果發(fā)現(xiàn)產(chǎn)品中的缺陷，則向開發(fā)人員報告缺陷，開發(fā)人員及時消除缺陷。 若產(chǎn)品經(jīng)理向項目經(jīng)理提出改進建議，雙方應(yīng)先就需求和改進措施達成共識，然后 開發(fā)人員執(zhí)行相應(yīng)的改進措施。 1.1.4 產(chǎn)品銷售與服務(wù) 產(chǎn)品開

18、發(fā)完成之后，產(chǎn)品經(jīng)理負責(zé)： 撰寫產(chǎn)品介紹文件（如 ppt 文件） 。 制作本產(chǎn)品的宣傳網(wǎng)頁，設(shè)法在更多的網(wǎng)站發(fā)布產(chǎn)品信息。 可能需要設(shè)計和制作宣傳頁（印刷品） 。 產(chǎn)品經(jīng)理對本公司銷售人員進行產(chǎn)品培訓(xùn)，使銷售人員充分了解本產(chǎn)品的特性。 上述工作完成之后，進入銷售管理流程和客戶服務(wù)流程。產(chǎn)品經(jīng)理跟蹤銷售和客服過程，產(chǎn)品經(jīng)理跟蹤銷售和客服過程， 收集并分析客戶意見，及時改進產(chǎn)品策劃。收集并分析客戶意見，及時改進產(chǎn)品策劃。 1.2 銷售管理 銷售管理流程如圖 1-2 所示，主要活動有：營銷策劃，銷售跟蹤，合同管理。該流程的 主要工作成果和責(zé)任人見表 1-4。 圖 1-2 銷售管理流程 主要活動主要工

19、作成果主要責(zé)任人 營銷策劃營銷方案銷售經(jīng)理 銷售跟蹤銷售跟蹤表，銷售合同銷售人員 合同管理合同實施、收款、付款跟蹤表銷售人員 表 1-4 銷售管理流程的成果清單和責(zé)任人 1.2.1 營銷策劃 銷售部門商議營銷方案，銷售經(jīng)理分配任務(wù)給執(zhí)行人（可以多人） 。每個執(zhí)行人填寫執(zhí) 行情況，模板見表 1-5。 營銷方案 方案名稱制定人 產(chǎn)品或項目 營銷策劃 銷售人員 - 合同管理 - 實施計劃與跟蹤 收款計劃與跟蹤 付款計劃與跟蹤 銷售經(jīng)理 銷售人員 - 銷售跟蹤 - 接觸客戶 客戶分析 售前服務(wù)與跟蹤 簽訂合同 起止日期執(zhí)行人a, b 銷售計劃內(nèi)容 執(zhí)行人執(zhí)行情況狀態(tài)日期 a未開始，進行中，完成 b 表

20、 1-5 營銷方案 1.2.2 銷售跟蹤 銷售人員負責(zé)：（1）銷售本公司的產(chǎn)品；（2）從客戶那里承接項目。 第一步，接觸潛在客戶。第一步，接觸潛在客戶。銷售人員通過各種途徑接觸潛在客戶，了解客戶（公司）信息 和客戶的需求。 第二步，客戶分析。第二步，客戶分析。銷售人員應(yīng)當(dāng)撰寫客戶分析報告 ，為公司提供充分的客戶信息 （同時也記錄了自己的工作業(yè)績） ，格式參見表 1-6。 由于售前服務(wù)會消耗公司的資源（人力、金錢、時間） ，如果客戶最終不簽訂采購合同， 那么無效的售前服務(wù)將給公司增加成本。為了避免浪費公司的資源，節(jié)約成本，銷售部門需為了避免浪費公司的資源，節(jié)約成本，銷售部門需 商議是否為潛在客戶

21、提供進一步的售前服務(wù)，以及服務(wù)的程度。商議是否為潛在客戶提供進一步的售前服務(wù)，以及服務(wù)的程度。 客戶分析報告 客戶分析 1. 客戶介紹 2. 客戶需求 3. 采購可能性 4. 成本效益分析 5. 風(fēng)險分析 部門意見說明是否為潛在客戶提供進一步的售前服務(wù)，以及服務(wù)的程度。 表 1-6 客戶分析報告 第三步，售前服務(wù)與跟蹤。第三步，售前服務(wù)與跟蹤。銷售人員根據(jù)潛在客戶需求，提供產(chǎn)品演示、講解、答疑等 服務(wù)。如果承接客戶的招標項目，則按客戶規(guī)定的程序進行“投標、答辯、商務(wù)談判” 。如果 需要，銷售人員應(yīng)主動向研發(fā)部門申請技術(shù)支持。 銷售人員填寫銷售跟蹤表，模板見表 1-7。 銷售跟蹤表 客戶 銷售單

22、內(nèi)容 對客戶的承諾 跟蹤人銷售單狀態(tài)跟蹤說明跟蹤日期 表 1-7 銷售跟蹤表 第四步，簽訂合同。第四步，簽訂合同。如果客戶確定采購，可能有 2 種方式： （1）商務(wù)談判結(jié)束后，雙方責(zé)任人將簽訂正式的合同。雙方責(zé)任人仔細審查 合同中的每 個條款，確保合同沒有錯誤和隱患，然后簽字、蓋章，使合同生效。 （2）客戶承諾采購，但是目前不能簽訂合同。遇此情況，銷售部門需請示公司領(lǐng)導(dǎo)， 決定做還是不做。 提示：如果公司銷售產(chǎn)品，則需制定產(chǎn)品銷售合同模板。如果公司承接客戶項目， 則需制定項目銷售合同模板。 1.2.3 合同管理 銷售人員根據(jù)合同信息，制定實施計劃、付款計劃、收款計劃，并跟蹤這些計劃的執(zhí)行 情況

23、，模板見表 1-8。 合同管理 客戶名稱客戶方負責(zé)人 合同名稱我方負責(zé)人 合同簽訂日期計劃完成日期 合同摘要 計劃實施日期計劃說明執(zhí)行人執(zhí)行狀態(tài)/情況說明 計劃收款日期金額及用途說明執(zhí)行人執(zhí)行狀態(tài)/情況說明 計劃付款日期金額及用途說明執(zhí)行人執(zhí)行狀態(tài)/情況說明 表 1-8 合同管理表（實施、收款、付款） 1.3 客戶服務(wù) 客戶服務(wù)流程如圖 1-3 所示，主要活動有：受理，處理，審核關(guān)閉，客戶反饋。該流程 的主要工作成果和責(zé)任人見表 1-9。 圖 1-1 客戶服務(wù)流程 主要活動主要工作成果主要責(zé)任人 受理客服人員 處理指定處理人 審核關(guān)閉客服人員 客戶反饋 客服跟蹤表 客戶 表 1-9 客戶服務(wù)流

24、程的成果清單和責(zé)任人 1.3.1 受理 客戶通過各種途徑報告問題（包括問題、需求、建議等） ?？头藛T記錄客戶問題，并 客戶報告 問題需求 審核關(guān)閉受理 客服人員 處理客戶反饋 指定處理人客服人員客戶 生成項目缺陷，項目任務(wù)，項目需求等 指定處理人，模板見表 1-10。 1.3.2 處理 如果處理人能夠直接解決客戶問題，則填寫處理說明，把狀態(tài)置為“解決待關(guān)閉” 。如果 問題比較復(fù)雜，可以生成“項目任務(wù)、項目缺陷、項目需求”等。若“任務(wù)、缺陷、需求” 都已經(jīng)完成，再把客戶問題的狀態(tài)置為“解決待關(guān)閉” 。 1.3.3 審核關(guān)閉 當(dāng)客戶問題的狀態(tài)為“解決待關(guān)閉”時，客服人員驗證這個問題，如果的確已經(jīng)

25、解決， 則把狀態(tài)置為“關(guān)閉” ，并填寫關(guān)閉說明。 1.3.4 客戶反饋 客服人員告知客戶其問題已經(jīng)解決，并獲取客戶的反饋意見。 客服跟蹤表 標題編號 客戶/聯(lián)系人客服類型 內(nèi)容 受理人受理時間 受理說明 處理人處理時間 處理說明 關(guān)閉人關(guān)閉時間 關(guān)閉說明 客戶反饋 表 1-10 客服跟蹤表 1.4 客戶信息管理 營銷人員和客服人員均可填寫客戶公司信息和客戶聯(lián)系人信息（模板見表 1-11） 。 客戶信息表 客戶公司簡稱客戶狀態(tài) 客戶公司全稱客戶類型 電話所屬區(qū)域 傳真所屬行業(yè) 郵政編碼所屬城市 地址 客戶公司簡介 客戶分析 聯(lián)系人姓名部門/職務(wù)聯(lián)系電話email /即時通信 表 1-11 客戶信

26、息 第 2 章 項目管理過程 2.1 立項管理 立項管理的流程如圖 7-1 所示，主要活動有：立項申請、pmo 受理、立項評審和項目啟 動。該流程的主要工作成果和責(zé)任人見表 2-1。 圖 2-1 立項管理流程 關(guān)鍵活動主要工作成果主要責(zé)任人 自主產(chǎn)品立項申請立項申請書，產(chǎn)品建議書，調(diào)研分析報告產(chǎn)品經(jīng)理 合同項目立項申請立項申請書，相關(guān)合同文件合同項目的銷售人員 pmo 受理立項評審?fù)ㄖ猵mo 立項評審立項評審結(jié)論立項評審委員會 項目啟動項目總體計劃項目經(jīng)理 表 2-1 立項管理流程的主要工作成果和責(zé)任人 2.1.1 立項申請 對于自主產(chǎn)品，產(chǎn)品經(jīng)理撰寫立項申請書 ，并將相關(guān)附件（主要是產(chǎn)品建議

27、書，產(chǎn)品 調(diào)研分析報告）一起提交給 pmo。 對于合同項目，銷售人員撰寫立項申請書 ，并將相關(guān)附件（主要是合同文件）一起提 交給 pmo。 立項申請書的格式見表 2-2。 立項申請書 合同項目立項申請 自主產(chǎn)品立項申請 項目啟動 產(chǎn)品經(jīng)理 項目團隊 銷售人員 pmo 受理 立項 評審 項目名稱項目類型合同項目 / 自主產(chǎn)品 申請人申請日期 1. 項目介紹 2. 本項目對公司的價值 3. 項目進度要求 4. 項目所需人力資源 5. 項目成本估算 6. 立項可行性分析 6.1 技術(shù)可行性分析 6.2 成本-效益分析 6.3 競爭分析 6.4 風(fēng)險分析 6.5 swot 分析 表 2-2 立項申請書

28、的格式 2.1.2 pmo 受理 pmo 受理人審閱立項申請書和相關(guān)附件，如果發(fā)現(xiàn)文件內(nèi)容不合流程要求或者質(zhì)量 不合格，則退還給申請人重新改進，直到文件合格為止。之后，pmo 受理人將文件轉(zhuǎn)交給研 發(fā)總監(jiān)。提示：這樣做的目的是提高立項評審的效率。 研發(fā)總監(jiān)根據(jù)項目的特征，選定“立項評審委員會” ，確定評審時間。 pmo 受理人發(fā)起立項評審?fù)ㄖ?，格式見?2-3。提示：如果項目涉及面很廣，難以一次 性在立項評審會議上決定，那么研發(fā)總監(jiān)可以先召開“預(yù)評審”會議，之后再進行正式的立 項評審。 立項評審?fù)ㄖ?項目名稱申請人 評審文件 評審時間地點 評審人員部門和職務(wù) 評審負責(zé)人 評委 其他參加人員 評

29、審內(nèi)容 表 2-3 立項評審?fù)ㄖ?2.1.3 立項評審 pmo 通知相關(guān)人員在既定的時間參加立項評審會議， 立項評審報告格式見 2-4。 評審負責(zé)人主持評審會議，把控會議進程。 立項申請人陳述立項申請書和相關(guān)文件的主要內(nèi)容。評審委員提出疑問，立項申請 人解答。雙方應(yīng)當(dāng)對有爭議的內(nèi)容提出處理意見、達成共識。 每個評委發(fā)表（填寫）自己的評審意見。 評審負責(zé)人匯總所有評審委員的評審意見，給出評審結(jié)論：“同意立項”或者“不同意 立項” 。提示：評審期間應(yīng)當(dāng)商議“項目人力資源計劃” ，避免立項之后人員不能到位的問題。 記錄員（pmo 受理人）填寫會議記錄。 評審結(jié)束后，公司級的項目由公司領(lǐng)導(dǎo)（研發(fā)總監(jiān)）

30、給出“終審結(jié)論和意見” ，部門級項 目由部門經(jīng)理給出“終審結(jié)論和意見” 。 xxx 立項評審報告 評委姓名評審意見 說明同意或者不同意的理由 評審負責(zé)人評審結(jié)論、匯總意見和人力資源計劃 評審結(jié)論： 同意立項 不同意 匯總意見和人力資源計劃： 記錄員會議記錄 領(lǐng)導(dǎo)終審結(jié)論和意見 評審結(jié)論： 同意立項 不同意 意見： 表 2-4 立項評審報告 2.1.4 項目啟動 第第 1 步步 確定項目團隊確定項目團隊 部門經(jīng)理根據(jù)項目特征和立項評審報告，任命合適的項目經(jīng)理，并確定該項目的主要成 員。 項目經(jīng)理對立項之后的項目進度和質(zhì)量負責(zé)。項目成員向項目經(jīng)理匯報工作。項目經(jīng)理 向部門經(jīng)理匯報工作。 第第 2

31、步步 確定項目總體計劃確定項目總體計劃 項目經(jīng)理和項目成員共同商議，制定初步的項目總體計劃 ，格式參見表 2-5。部門經(jīng) 理審批該項目總體計劃 ，如果有修改意見，請項目經(jīng)理及時修正。 提示：在項目開發(fā)過程中，項目經(jīng)理可以不斷細化項目計劃和修改項目計劃，詳見“項 目規(guī)劃與監(jiān)控”過程域。 項目總體計劃 項目名稱計劃開始日期 項目經(jīng)理計劃結(jié)束日期 1.項目介紹 說明項目目標、關(guān)鍵因素及優(yōu)先級 2.項目成員表 姓名角色說明（主要職責(zé)和工作時間） 3.任務(wù)進度表 名稱（ 階段 / 任務(wù) / 評審點） 執(zhí)行人計劃起止日期 4.部門經(jīng)理審批 審批意見 表 2-5 項目總體計劃 第第 3 步步 初始化管理平臺

32、初始化管理平臺 （1）pmo受理人或部門經(jīng)理在管理平臺中創(chuàng)建該項目。 （2）項目經(jīng)理登錄管理平臺，進入該項目，執(zhí)行初始化操作： 初始化項目成員表（含角色職責(zé)）。 把立項會議的相關(guān)文件上傳到本項目的文檔庫中。 根據(jù)項目總體計劃初始化任務(wù)進度表。 第第 4 步步 初始化軟件配置管理工具初始化軟件配置管理工具 （1）部門經(jīng)理（或指定配置管理員）創(chuàng)建該項目的配置庫，授予項目經(jīng)理控制本項目的 權(quán)限。 （2）項目經(jīng)理再分配權(quán)限給其他項目成員。 2.2 結(jié)項管理 結(jié)項管理的流程如圖 7-2 所示，主要活動有：結(jié)項申請、pmo 受理、結(jié)項評審、遺留問 題跟蹤和項目工作總結(jié)。該流程的主要工作成果和責(zé)任人見表 2

33、-6。 圖 2-2 結(jié)項管理流程 關(guān)鍵活動主要工作成果主要責(zé)任人 結(jié)項申請結(jié)項申請書項目經(jīng)理 pmo 受理 結(jié)項評審 結(jié)項評估報告pmo，結(jié)項評審委員會 遺留問題跟蹤問題跟蹤表項目經(jīng)理，pmo 項目工作總結(jié)個人工作總結(jié)，知識庫所有項目成員 表 2-6 結(jié)項管理流程的主要工作成果和責(zé)任人 2.2.1 結(jié)項申請 正常情況下，當(dāng)項目開發(fā)工作結(jié)束時，項目經(jīng)理撰寫結(jié)項申請書 ，遞交給 pmo。 結(jié) 項申請書的格式見表 2-6。 對于異常結(jié)束的項目，部門經(jīng)理應(yīng)當(dāng)明確指示項目經(jīng)理，確定何時結(jié)束項目。部門經(jīng)理 應(yīng)當(dāng)向員工們解釋為什么要異常終止項目。異常中止項目的結(jié)項流程與正常結(jié)項流程相同。 結(jié)項申請 項目經(jīng)理

34、 pmo 受理結(jié)項評審遺留問題跟蹤 項目工作總結(jié)：個人工作總結(jié) 分析提煉 知識入庫 所有項目成員 2.2.2 pmo 受理 pmo受理人審閱結(jié)項申請書和相關(guān)附件，如果發(fā)現(xiàn)文件內(nèi)容不合流程要求或者質(zhì)量 不合格，則退還給申請人重新改進，直到文件合格為止。之后，pmo受理人將文件轉(zhuǎn)交給研 發(fā)總監(jiān)。提示：這樣做的目的是提高立項評審的效率。 研發(fā)總監(jiān)根據(jù)項目的特征，選定“結(jié)項評審委員會” ，確定評審時間。pmo受理人發(fā)起結(jié) 項評審?fù)ㄖ?，格式和立項評審?fù)ㄖ嗤ㄒ姳?-3） 。 結(jié)項申請書 項目名稱項目經(jīng)理 1. 項目完成情況計劃情況實際情況 主要功能 項目起止日期 人員和工作量 項目成本 應(yīng)遞交的成果

35、2. 資產(chǎn)清單（資金和設(shè)備，軟件等）說明、處理建議 3. 專利和版權(quán) 4. 項目價值體現(xiàn)闡述：項目質(zhì)量，市場價值，成本效益，對機構(gòu)的貢獻 5. 人員業(yè)績工作業(yè)績描述評價人 人員 a 人員 b 項目經(jīng)理簽字 表 2-6 結(jié)項申請書 2.2.3 結(jié)項評審 pmo 通知相關(guān)人員在既定的時間參加結(jié)項評審會議。 評審負責(zé)人主持評審會議，把控會議進程。 立項申請人陳述結(jié)項申請書的主要內(nèi)容。評審委員提出疑問，立項申請人解答。雙 方應(yīng)當(dāng)對有爭議的內(nèi)容提出處理意見、達成共識。 每個評委發(fā)表（填寫）自己的評審意見。 評審負責(zé)人匯總所有評審委員的評審意見，給出評審結(jié)論：“同意結(jié)項”或者“不同意 結(jié)項” 。 記錄員（

36、pmo 受理人）填寫會議記錄。 結(jié)項評審報告的格式見表 2-7。 xxx 結(jié)項評審報告 評委姓名評審意見 評審負責(zé)人評審結(jié)論和匯總意見 評審結(jié)論： 同意結(jié)項 不同意 匯總意見： （1）項目任務(wù)完成情況。 （2）項目資產(chǎn)處理意見。 （3）發(fā)掘可以重復(fù)利用的知識財富，給出應(yīng)用建議。 （4）項目的價值：市場價值、成本效益、技術(shù)積累等 記錄員會議記錄 表 2-7 結(jié)項評審報告 提示：項目結(jié)項后，該項目的人力資源和設(shè)備資源將被釋放，應(yīng)用于新的項目。項目成 員有義務(wù)維護自己參與的項目。 2.2.4 遺留問題跟蹤 項目結(jié)項后，尚有一些遺留問題，項目經(jīng)理填寫“問題表” ，pmo 人員跟蹤該問題表， 確保所有問

37、題得到妥善處理。詳見“問題跟蹤”過程域。 2.2.5 項目工作總結(jié) 第 1 步。所有項目成員都要撰寫個人工作總結(jié) ，格式見表 2-8，在公司范圍內(nèi)共享經(jīng) 驗教訓(xùn)。 第 2 步。項目經(jīng)理召集所有項目成員，討論每個人的工作總結(jié)，提煉出知識財富。 第 3 步。把知識財富按照一定的格式保存在集成化管理平臺中。 項目名稱 個人工作總結(jié) 撰寫人日期 工作總結(jié) 1. 本人在項目中的主要任務(wù) 2. 遇到哪些問題，如何解決 3. 經(jīng)驗教訓(xùn)和建議 表 2-8 個人工作總結(jié) 2.3 項目規(guī)劃與監(jiān)控 項目規(guī)劃（project planning）是指對本項目的人力資源、任務(wù)進度、成本等做出合適的 安排，制定出一些計劃（

38、包括宏觀的和細節(jié)的） ，使大家按照計劃行事，最終順利地達到預(yù)定 的目標。 項目監(jiān)控是將項目實際情況與項目計劃進行對比，如果發(fā)現(xiàn)某些因素（如人力資源、任 務(wù)進度、成本等）的偏差比較大，那么及時分析原因，給出糾正措施。項目監(jiān)控至少有兩個 好處：（1）避免原本合理的計劃在實施過程時落空；（2）避免“執(zhí)迷不悟”地按照原本不 合理的計劃行事。 項目規(guī)劃與監(jiān)控的重點是：“人員角色” 、 “任務(wù)進度” 、 “項目成本” 、 “項目評審” 。 2.3.1 項目人員角色 項目經(jīng)理向部門爭取“完成本項目充分必要的人員” ，項目人員到位后，項目經(jīng)理確定每 個人員在本項目的角色、工作內(nèi)容和時間，格式見表 2-9。 姓

39、名角色工作描述（簡要說明工作內(nèi)容和時間） 表 2-9 項目人員角色表 2.3.2 任務(wù)進度管理 項目經(jīng)理根據(jù)“本項目需求和人力資源”分解任務(wù)，和項目成員協(xié)商后，把任務(wù)交給最 合適的人員去執(zhí)行。簡而言之，就是要“知人善用” 。 “知人”是指領(lǐng)導(dǎo)者應(yīng)當(dāng)非常了解他的 團隊成員，包括知識技能和性格愛好等等。 “善用”是指讓團隊各成員揚長避短，使團隊戰(zhàn)斗 力達到最強。 項目經(jīng)理還要有意識地鍛煉、提升成員們?nèi)珠_發(fā)的能力，要保證至少有一人可以替換 別人的工作。否則萬一某人缺席（如離職、休假等） ，將導(dǎo)致工作被中斷。 任務(wù)進度管理的流程如圖 2-3 所示，主要活動和步驟如下： 圖 2-3 任務(wù)進度管理的流程

40、 第第 1 步步. 制定任務(wù)進度計劃制定任務(wù)進度計劃 項目經(jīng)理和項目成員們共同協(xié)商任務(wù)，大家達成共識后制定任務(wù)進度計劃，每個任務(wù)的 主要數(shù)據(jù)如下： 任務(wù)名稱，任務(wù)描述，預(yù)計工作成果 開始日期，計劃完成日期 任務(wù)執(zhí)行人（可以多個） ，計劃工作量 第第 2 步步. 填寫執(zhí)行信息填寫執(zhí)行信息 每個任務(wù)的執(zhí)行人（可以多個）填寫執(zhí)行信息，主要數(shù)據(jù)如下： 執(zhí)行人，填寫日期 任務(wù)狀態(tài)（進行中，已完成） 當(dāng)前進度（百分比） 實際工作量，執(zhí)行說明 第第 3 步步. 糾正偏差糾正偏差 如果任務(wù)的執(zhí)行情況和計劃之間的偏差比較大（例如工作量、完成日期的誤差超過 20） ，項目經(jīng)理應(yīng)當(dāng)和執(zhí)行人交流，分析原因并給出解決措

41、施：（1）若原計劃太樂觀了， 那么適當(dāng)修改原計劃；（2）若執(zhí)行人工作不得力，那么要求執(zhí)行人加班追趕進度。 2.3.3 項目成本管理 項目經(jīng)理應(yīng)當(dāng)懂得“非財務(wù)人員”的項目成本管理。項目成本管理的流程如圖 2-4 所示， 1. 制定任務(wù)計劃2. 填寫執(zhí)行信息 調(diào)整 3. 糾正偏差 1. 制定項目預(yù)算2. 記錄實際開支 調(diào)整 3.對比分析、控制成本 主要活動和步驟如下： 圖 2-4 項目成本管理的流程圖 第第 1 步步. 制定項目預(yù)算制定項目預(yù)算 項目經(jīng)理制定項目預(yù)算表，每條記錄的主要數(shù)據(jù)有： 金額； 預(yù)算類型（例如硬件、軟件、辦公消耗等） ； 用途說明。 第第 2 步步. 記錄實際開支記錄實際開支

42、 項目經(jīng)理和項目成員記錄實際開支，每條記錄的主要數(shù)據(jù)有： 經(jīng)辦人，開支時間； 金額； 預(yù)算類型（例如硬件、軟件、辦公消耗等） ； 用途說明。 第第 3 步步. 對比分析、控制成本對比分析、控制成本 項目經(jīng)理隨時對比分析“成本預(yù)算表”和“實際開支表”，盡量避免超支。項目經(jīng)理應(yīng)當(dāng)向 上級領(lǐng)導(dǎo)解釋為什么超支。 2.3.4 項目評審（決策評審和技術(shù)評審） 項目評審分兩類：決策評審和技術(shù)評審，兩者的流程相同，但是目的不同。 決策評審的目的是利用集體（所有評審人員）的智慧，做出正確的決策，決定項目工作 繼續(xù)進行還是終止。 技術(shù)評審的目的是及時發(fā)現(xiàn)工作成果中問題，提出改進建議，使工作成果變得更好。 第第1

43、1步步. . 發(fā)起評審?fù)ㄖl(fā)起評審?fù)ㄖ?發(fā)起人根據(jù)項目計劃（或者項目經(jīng)理的指示）發(fā)出評審?fù)ㄖ?，明確評審會議的內(nèi)容、參 加人員、時間、地點等信息，評審?fù)ㄖ母袷絽⒁姳?-3。一般地，默認的評審負責(zé)人是 項目經(jīng)理，如果項目經(jīng)理不能做出決定，可以重新指定其他人擔(dān)任評審負責(zé)人。 第第2 2步步. . 評審負責(zé)人召開評審會議評審負責(zé)人召開評審會議 （1）發(fā)起人講解待評審的成果。 （2）評審人員現(xiàn)場提問和討論，發(fā)起人解答疑問。 （3）所有評審人員給出評審意見。 （4）評審負責(zé)人匯總評審意見，給出評審結(jié)論。 （5）記錄員輸入會議記錄。 評審報告的格式參見表 2-4。 2.4 變更控制 項目開發(fā)過程中發(fā)生變更

44、是司空見慣的事情。這里“變更”是指改變已經(jīng)發(fā)布的工作成 果（如文檔、代碼或者計劃等） ，修改草稿不叫變更。變更控制的目的不是為了“預(yù)防變更” ， 而是為了“防止變更失去控制產(chǎn)生壞的后果” 。變更控制的最大困難在于變更控制的最大困難在于“如何拒絕客戶或上如何拒絕客戶或上 級領(lǐng)導(dǎo)提出的不合理變更要求級領(lǐng)導(dǎo)提出的不合理變更要求” 。 變更控制的流程如圖 2-5 所示，主要活動有：變更申請、評審和審批和執(zhí)行變更。 圖 2-5 變更控制流程 提示：一般情況下，先申請，審批通過后，再執(zhí)行變更。在實際工作中，由于時間緊迫， 對于低風(fēng)險的變更，允許先執(zhí)行變更，后補寫變更申請。 變更控制報告的參考格式如表 2-

45、10 所示。 第第 1 步步. 變更申請變更申請 項目開發(fā)過程中，所有人員（包括銷售人員、項目成員和上級領(lǐng)導(dǎo)）提出的變更申請， 必須說明“變更內(nèi)容和原因” 。由項目經(jīng)理受理，指定多個評審人和一位“審批負責(zé)人” ，一 般情況下，項目經(jīng)理擔(dān)任審批負責(zé)人。 如果對項目的技術(shù)方案、進度、質(zhì)量、成本產(chǎn)生重大影響的變更，項目經(jīng)理做不了決定， 那么可以指定上級領(lǐng)導(dǎo)擔(dān)任審批負責(zé)人。 第第 2 步步. 評審和審批評審和審批 每個評審人都可以發(fā)表意見（但是不做決定） 。由“審批負責(zé)人”做決定：“同意變更” 或者“拒絕變更” ，并給出指示。 變更申請 拒絕變更拒絕變更 同意變更 執(zhí)行變更 申請人評審人和審批人執(zhí)行人

46、 評審和審批 第第 3 步步. 執(zhí)行變更執(zhí)行變更 審批負責(zé)人同意變更后，由項目經(jīng)理安排人員執(zhí)行具體的變更工作，調(diào)整相應(yīng)的任務(wù)進度 計劃，通知給受變更影響的相關(guān)人員。 1. 變更申請 項目名稱 變更原因和內(nèi)容 說明變更原因和變更內(nèi)容，估計此變更對項目造成的影響。 變更申請人 評審人可以多人 審批負責(zé)人可以逐級審批 2. 變更審批 評審人評審意見 同意變更 拒絕變更 審批負責(zé)人 指示： 3. 執(zhí)行變更 執(zhí)行人說明 表 2-10 變更控制報告 2.5 溝通管理 溝通管理包括項目內(nèi)部溝通、跨部門溝通、與上級領(lǐng)導(dǎo)溝通、與客戶溝通等，要及時記 錄重要的溝通信息，避免遺忘，模板見表 2-11。 溝通記錄 標

47、題溝通日期 溝通對象客戶或公司內(nèi)部人員填寫人 溝通方式面談 / 電話 / email / 網(wǎng)絡(luò)交流 溝通結(jié)果達成共識 / 存在異議 / 擱置 詳細信息 表 2-11 溝通記錄 項目開發(fā)過程中存在各種各樣的風(fēng)險，需要項目經(jīng)理（和銷售人員）及時地和客戶溝通。 “客戶溝通”主要目的是“消除摩擦、增進關(guān)系” 、 “處理不合理的變更”和“發(fā)掘新的商機” 。 一、消除摩擦、增進關(guān)系一、消除摩擦、增進關(guān)系 項目經(jīng)理（和銷售人員）應(yīng)經(jīng)常和客戶溝通，盡可能地消除客戶對需求、進度、質(zhì)量的 不滿。如果雙方工作人員之間發(fā)生摩擦，項目經(jīng)理（和銷售人員）應(yīng)及時消除摩擦。 為了不斷改善開發(fā)方和客戶方的人際關(guān)系，項目經(jīng)理（和

48、銷售人員）在時間、經(jīng)費允許 的前提下，主動邀請客戶方人員參加友誼活動，例如運動、聚餐、娛樂等等。 二、二、 處理不合理的變更處理不合理的變更 項目經(jīng)理（和銷售人員）要設(shè)法“拒絕客戶提出的不合理變更” 。 所謂“不合理的變更”是指：客戶提出的變更不是由于開發(fā)方的過錯引起的，此變更造 成開發(fā)方承擔(dān)了額外的成本，但是客戶不愿意支付相應(yīng)的費用。 客戶會想當(dāng)然地以為變更是他的權(quán)利，通常情況下開發(fā)方是不敢得罪客戶的，但是無原 則地退讓將使開發(fā)團隊陷入困境。這里建議了三種應(yīng)對方法： 方法方法 1：依據(jù)合同處理變更：依據(jù)合同處理變更 如果客戶是很有信譽、嚴格按照合同辦事的企業(yè)，那么雙方應(yīng)當(dāng)依據(jù)合同中的條款處理

49、 變更糾紛。這就要求雙方在簽訂合同的時候，要在合同中寫明“變更處理協(xié)議” 。例如： 當(dāng)需求規(guī)格說明書被雙方確認之后，如果再發(fā)生需求變更的話，那么按照“變 更申請審批執(zhí)行”的變更管理流程執(zhí)行。 如果客戶（或者開發(fā)方）提出的變更對項目進度、成本的影響超過 10%，那么雙方 要重新協(xié)商成本、資源和進度，否則開發(fā)方（或者客戶）可以拒絕變更請求。 方法方法 2：設(shè)法拖延到下個版本：設(shè)法拖延到下個版本 如果雙方簽訂的合同中沒有“變更協(xié)議” ，或者有變更協(xié)議但是客戶找出很多理由來搪塞， 只要雙方還沒有完全鬧僵的話，項目經(jīng)理（和銷售人員）需要一些社交技巧來減緩矛盾： 首先承認客戶提出的需求變更請求是合理的（讓

50、客戶面子上過得去） ；再闡述己方的 難處和變更對客戶造成的不利影響，例如質(zhì)量問題等等，讓客戶明白隨意變更對他自己 也沒有好處；最后建議在開發(fā)新版本的時候?qū)崿F(xiàn)客戶提出的變更。 這種方式比直接拒絕有效得多，既不得罪客戶，又為自己爭取了余地。拖延到下個 版本實現(xiàn)客戶的變更，有可能讓客戶支付升級費用。即使升級是免費的，也不會延誤當(dāng) 前項目的進度和客戶驗收，讓開發(fā)方及時拿到合同經(jīng)費。 方法方法 3：讓客戶欠下人情：讓客戶欠下人情 如果客戶提出重大的變更請求，既不愿意支付變更的費用，也不愿意延緩到下個版本中 實現(xiàn)，而且客戶也知道自己理虧，但是現(xiàn)實環(huán)境迫使客戶必須那樣做。開發(fā)方?jīng)]有辦法拒絕， 因為倘若拒絕的

51、話，就得不到合同余款，怎么辦？ 在這種情況下，開發(fā)方只能接受讓自己吃虧的變更，但是還有辦法減少損失，這個辦法 就是“讓客戶欠下人情” 。 銷售人員（和項目經(jīng)理）應(yīng)當(dāng)真誠地和客戶溝通，讓客戶明白“開發(fā)方為了客戶的 利益付出了額外的代價” 。只要客戶是個講道理的正常人，那么客戶會感激開發(fā)方的幫助， 覺得自己欠下了“人情” ，可以約定在后面恰當(dāng)?shù)臋C會回報開發(fā)方。例如，在客戶驗收的 時候，適當(dāng)?shù)胤潘梢?，及時地向開發(fā)方支付合同費用等，這些回報對開發(fā)方而言都是 隱形的收益。 三、發(fā)掘新的商機三、發(fā)掘新的商機 項目經(jīng)理（和銷售人員）和客戶交往的過程中，不僅要關(guān)注已經(jīng)簽訂合同的項目進展情 況，還要不斷發(fā)掘新

52、的商機，例如： 發(fā)掘客戶更深層次的需求，吸引客戶繼續(xù)采購（例如不斷升級） 。 將合同項目的成果轉(zhuǎn)化成為通用的產(chǎn)品或構(gòu)件，賣給其它客戶。 請老客戶推薦其新客戶。 2.6 問題跟蹤 問題跟蹤的范圍包括：開發(fā)過程中的各種問題、風(fēng)險和建議，以及結(jié)項后遺留的問題。開發(fā)過程中的各種問題、風(fēng)險和建議，以及結(jié)項后遺留的問題。 問題跟蹤的一般步驟如圖 2-6 所示，問題跟蹤表見表 2-12。 第 1 步。報告者創(chuàng)建問題，指定接收者，此時狀態(tài)為“新的” 。 第 2 步。接受者處理問題，狀態(tài)為“正在處理” 。 第 3 步。如果已經(jīng)解決了問題，則把狀態(tài)置為“解決待關(guān)閉” 。 第 4 步。報告者審核這個問題，如果確定該

53、問題已經(jīng)解決，則把狀態(tài)設(shè)置為“關(guān)閉” 。如 果發(fā)現(xiàn)問題沒有解決，則可以“重新打開”問題，回到第 2 步。 報告問題 報告者接受者報告者 處理問題解決待關(guān)閉審核關(guān)閉 接受者 重新打開 圖 2-6 問題跟蹤示意圖 問題跟蹤表 問題編號問題類型 重要性緊急程度 問題描述 報告者報告時間 接受者期望完成日期 問題處理方案 當(dāng)前狀態(tài)實際完全日期 審核關(guān)閉意見 表 2-12 問題跟蹤表 第 3 章 項目研發(fā)過程 3.1 需求開發(fā)與管理 需求開發(fā)與管理是指通過“調(diào)研、分析、定義、評審、跟蹤”等活動，使開發(fā)方和委托 方（客戶或本公司領(lǐng)導(dǎo)）對需求有共同、清晰的理解，并依據(jù)雙方確認的需求開展后續(xù)開發(fā) 工作（如設(shè)計

54、、編程、測試等） 。 項目經(jīng)理根據(jù)本項目的人力資源來確定需求分析員（可以多人） 。需求分析員負責(zé)開展調(diào) 研、分析、定義、評審、跟蹤等活動。 3.1.1 需求調(diào)研 需求分析員起草需求問題表，將調(diào)查重點鎖定在該問題表內(nèi)，否則調(diào)研工作將變得漫無 邊際。 需求分析員確定需求調(diào)研的方式，例如： 與用戶交談，向用戶提問題。 參觀用戶的工作流程，觀察用戶的操作。 向用戶群體發(fā)調(diào)查問卷。 與同行、專家交談，聽取他們的意見。 分析已經(jīng)存在的同類軟件產(chǎn)品，提取需求。 從行業(yè)標準、規(guī)則中提取需求。 從 internet 上搜查相關(guān)資料。 需求分析員在調(diào)研過程中隨時填寫“客戶需求記錄” ，參考格式如表 3-1 所示。

55、 項目名稱需求分析員 調(diào)研方式被調(diào)研者 時間、地點 需求標題客戶需求記錄 表 3-1 客戶需求記錄 需求分析員整理所有客戶需求記錄，歸納與總結(jié)共性的需求，為撰寫詳細的需求規(guī)格 說明書作準備。調(diào)研過程中獲取的需求信息可以作為需求規(guī)格說明書的附件。 3.1.2 需求分析 需求分析是對各種來源的需求信息進行分析，消除錯誤，刻畫細節(jié)等。常見的需求分析 方法有“問答分析法”和“建模分析法”兩類。 問答分析最重要的問題是：“是什么”和“為什么” 。每個需求都應(yīng)當(dāng)用陳述句說明“是 什么” ，如果“是什么”的內(nèi)涵不夠清晰，則應(yīng)補充說明“不是什么” 。如果“是什么”和 “不是什么”并不是“理所當(dāng)然”的，那么應(yīng)當(dāng)

56、解釋“為什么” ，以便加深讀者的理解。追究 “是什么”和“為什么”的目的是獲得正確、清楚的需求。 對于某些類型的信息，用圖形表示要比文本表示更加有效。所以將圖形與文本結(jié)合起來 描述需求是很自然的方法。需求建模就是指用圖形符號來表示、刻畫需求。 現(xiàn)代建模工具如 rose 有非常豐富的圖形符號和文字標注，能很好地表達模型的細節(jié)。要 注意的是：在建模時使用花樣過多的圖形符號或文字意味著模型表示的復(fù)雜化，將使開發(fā)人 員更難掌握，而且使圖形文檔更加雜亂。 世上不存在一個包羅萬象的圖用以完整地描述需求。需求建模不可能取代文字描述。在在 需求文檔中，文字描述是第一重要的，建模主要是起分析、解釋作用。需求文檔

57、中，文字描述是第一重要的，建模主要是起分析、解釋作用。建議將模型存放在需 求文檔的附錄中，便于正文引用。 3.1.3 需求定義 需求分析員根據(jù)需求調(diào)查和需求分析的結(jié)果，進一步定義準確無誤的需求，撰寫需求 規(guī)格說明書 ，模板見表 3-2。提示：若有其它類型的需求規(guī)格說明書，請另定義模板。 軟件需求規(guī)格說明書 1. 背景介紹 2. 軟件系統(tǒng)的用戶介紹 2.1 用戶類型和角色職責(zé) 2.2 用戶組織結(jié)構(gòu)圖（可選） 2.3 用戶的信息化情況 3. 用戶業(yè)務(wù)流程介紹 4. 軟件系統(tǒng)的約束 5. 軟件系統(tǒng)當(dāng)前版本的范圍 6. 軟件系統(tǒng)的功能清單 7. 模塊需求說明（可以寫在單獨的模塊文檔中） 8. 其它需求

58、 9. 簽字確認 表 3-2 軟件需求規(guī)格說明書 3.1.4 需求評審 需求分析員邀請項目成員（包括項目經(jīng)理）和客戶代表共同評審需求規(guī)格說明書 ，大 家盡最大努力使需求規(guī)格說明書能夠正確無誤地反映用戶的真實意愿。 需求評審的流程見“項目評審流程” 。一般地，需求分析員為申請人，項目經(jīng)理為評審負 責(zé)人，項目成員和客戶代表可以擔(dān)任評審員。所有評審人員認真檢查需求文檔，力求使需求 文檔達到正確、清楚、無二義性、一致、必要、完備、可實現(xiàn)、可驗證。 3.1.5 需求跟蹤 第第 1 1 步。步。需求分析員創(chuàng)建需求的目錄結(jié)構(gòu)，便于人們閱讀。 第第 2 2 步。步。需求分析員輸入每條需求的詳細內(nèi)容，可以多次細

59、化修改，每次修改后應(yīng)通知 相關(guān)項目成員。 第第 3 3 步。步。需求分析員跟蹤每條需求的進展狀況，填寫需求跟蹤記錄（當(dāng)前狀態(tài)和情況說 明），需求跟蹤表的格式見表 3-3。 需求跟蹤表 需求目錄/名稱優(yōu)先級狀態(tài)責(zé)任人關(guān)聯(lián)信息（文檔，任務(wù)，缺陷等） 表 3-3 需求跟蹤表 3.2 系統(tǒng)設(shè)計 3.2.1 軟件系統(tǒng)設(shè)計 軟件系統(tǒng)設(shè)計的主要內(nèi)容有體系結(jié)構(gòu)設(shè)計、用戶界面設(shè)計、數(shù)據(jù)庫設(shè)計等，在需求與代 碼之間建立橋梁，指導(dǎo)工作人員開發(fā)能夠滿足用戶需求的軟件系統(tǒng)。 項目經(jīng)理根據(jù)本項目的人力資源來確定軟件設(shè)計師（可以多人） 。 軟件設(shè)計師撰寫軟件設(shè)計師撰寫軟件系統(tǒng)設(shè)計說明書軟件系統(tǒng)設(shè)計說明書 ，并構(gòu)造可運行的軟

60、件系統(tǒng)框架，所有的模塊都，并構(gòu)造可運行的軟件系統(tǒng)框架，所有的模塊都 是在該系統(tǒng)框架上開發(fā)和運行。是在該系統(tǒng)框架上開發(fā)和運行。 軟件系統(tǒng)設(shè)計說明書的模板參見表 3-4。 軟件系統(tǒng)設(shè)計說明書 1. 軟件系統(tǒng)概述 2. 設(shè)計約束 3. 開發(fā)、測試與運行環(huán)境 4. 軟件體系結(jié)構(gòu)圖 5. 功能模塊設(shè)計概述 5.1 模塊匯總 5.2 模塊之間的關(guān)系 6. 數(shù)據(jù)庫設(shè)計概述 6.1 數(shù)據(jù)庫環(huán)境說明 6.2 數(shù)據(jù)庫命名規(guī)則 6.3 安全性設(shè)計說明 6.4 表匯總和表設(shè)計 7. 用戶界面設(shè)計概述 8. 綜合考慮（可選） 8.1 穩(wěn)定性和可擴展性 8.2 性能分析 8.3 復(fù)用和移植 8.4 防錯與出錯處理 8.5