1、細節(jié)決定成敗，精神保證細節(jié)壽險事業(yè)部本部交銀康聯(lián)項目組摘要交銀康聯(lián)人壽保險大陸入股的第一家保險公司，從售前開始客戶就相當重視，參與項目的既有原中保康聯(lián)的同事，也有交通的，同時外方也安排了顧問與 BA參與。因此，項目實施過程必須既能提供用戶滿意的系統(tǒng)，又能滿通與外方同事對項目管理的要求。基于以上要求，項目團隊在組建初期就結合部門其他項目的實施經驗，以及CMMI5 的要求，制訂了一套既滿足項目管理需求，又不失靈活性的項目管理規(guī)范。規(guī)范是死的，如果不執(zhí)行還是一紙空文，只有執(zhí)行了的規(guī)范才具有其意義與作用。因此，項目組一直重視這方面的監(jiān)督與管理。項目是由人來做的，做好的工作，讓大家能夠安心工作是項目能夠

2、運轉的保障，而具有一個適合項目發(fā)展的內外部環(huán)境，是項目能夠順利進行的基礎。幸運的是，交銀康聯(lián)項目不僅具有一幫敢干、敢沖的同事，同時也具有一個項目良好發(fā)展的環(huán)境。經過一年時間的努力，目前個險系統(tǒng)已上線，并完成了新老系統(tǒng)的切換。目前，項目已經進入到了二期階段，用戶正在規(guī)劃著同更廣泛的合作。關鍵字：細節(jié)、項目管理計劃、數(shù)字與圖表、政委制目錄細節(jié)決定成敗，精神保證細節(jié)1壽險事業(yè)部本部交銀康聯(lián)項目組1摘要1目錄2引言3一、創(chuàng)建項目環(huán)境32.1.2.2.支持項目的客戶環(huán)境3和諧的合作環(huán)境4二、三、在細節(jié)5建立完善、細致的項目管理計劃64.1.4.2.4.3.4.4.4.5.4.6.4.7.需求管理計劃7進

3、度管理計劃7測試管理計劃9風險管理計劃9配置管理計劃10溝通管理計劃10培訓管理計劃124.7.14.7.2培訓12用戶培訓13四、堅決執(zhí)行14不斷宣導規(guī)范、流程14提高個人執(zhí)行力14監(jiān)督者15審計人15利用數(shù)字與圖表16需求16開發(fā)17測試20建立敢打、敢沖的團隊22個人與項目共贏22項目經理以身作則23培養(yǎng)志同道合者24建立政委制256.16.26.36.4五、6.16.26.3六、1.2.3.4.總結27參考文獻27作者簡介27引言交銀康聯(lián)人壽保險（以下簡稱交銀康聯(lián)）是交通控股的中外合資保險機構，其前身是中保康聯(lián)，成立于 2010 年 1 月 28 日，總部位于。公司資本金為 5 億元，

4、其通持股 62.5%，澳大利亞康聯(lián)持股 37.5%。交銀康聯(lián)作為批準的國內首家控股的保險公司，業(yè)務發(fā)展突飛猛進，市場穩(wěn)步，市場份額逐漸擴大。2010 年，公司在壽險公司中位列保費增速第二名，全年業(yè)績較上年增長了 7.5 倍。交銀康聯(lián)項目的嚴謹、細致從售前開始就體現(xiàn)出來，交銀康聯(lián)項目的售前從08 年下半年開始，持續(xù)了近一年的時間，包括系統(tǒng)方案講解、用戶到公司、系統(tǒng)介紹、快速定義用戶提供的 11 款產品、一個月客戶現(xiàn)場系統(tǒng)演示、客戶現(xiàn)場使用環(huán)節(jié)，內容設計個險、團險、管理、規(guī)則引擎、銷售支持等眾多產品線。在 2009 年 7 月份進入需求分析階段，在需求分析階段，共投入 11 個人/月，持續(xù)近 2

5、個月的時間。最后確定從 09 年 10 月底至 10 年 9 月底，需要實施完個險系統(tǒng)客戶化功能 830 人/天的工作量，產品定義 89 款，數(shù)據(jù)移植 10 人/月，在實施過完成新增需求及需求變更 13.5 人/月，并完成了 oracle 數(shù)據(jù)至 DB2 數(shù)據(jù)的轉換，多幣種業(yè)務功能的實施。在實施過，項目組平均35 人（包括交銀康聯(lián) IT、運營、合規(guī)、精算、財務等部門同事；CBA 顧問、監(jiān)理；軟項目組成員），時期參與項目組成員達到了 58 人的團隊規(guī)模。一、創(chuàng)建項目環(huán)境1.1.支持項目的客戶環(huán)境系統(tǒng)的實施是一個復雜的過程，需要涉及到客戶的銷售部門、運營部門、財務部門、精算部門、合規(guī)部門、IT 部

6、門。如果沒有用戶的支持，幫助，要想實施成功幾乎不可能。因此，作為項目經理必須首先爭取客戶的合作與支持。眾所周知，信息化工程一般是“工程，沒有的支持，信息工程很難有客觀的結果。甚至業(yè)內有一種公認的說法：項目成功與否取決于一把手重視程度。但在具體的實施國大部分企業(yè)“”都很難優(yōu)先在行動上重視信息化。這也就是為什么很多項目經理都將項目得不到重視、推行過程阻力太大作為項目失敗的首要原因。支持就是給政策給資源支持。但投入多少精力來支持信息化項目，在很大程度上取決于項目經理對的說服能力，有經驗的項目經理會投入相當多的精力爭取企業(yè)和供應商雙方高層的支持，以助項目獲得的資源保障。如果幸運，項目是“”工程，客戶都

7、很配合，項目實施就比較順利了，如果沒有這樣的環(huán)境，項目經理就需要想辦法創(chuàng)建這樣的環(huán)境，爭取得到客戶的支持。如果遇見不太利于項目的情況，可以從以下幾個方面入手：1.首先需要爭取得到 IT 部門支持，特別是 IT 部門長的支持。IT 部門負責整個企業(yè)的信息化建設，系統(tǒng)作業(yè)是保險公司最的部分，IT 部門長肯定會重視，需要做的是找到切入點，與其很好的配合；2.其次要得到 IT 部門成員的幫助，在實施的過，有很多問題需要他們來幫助協(xié)調；3.再次通過 IT 部門爭取其他部門長的支持，一個信息化系統(tǒng)的實施，每個部門都有自的需求或是利益點，找到這個需求或是利益點也就找到了得到他們支持的依據(jù)；4.最后是要得到各

8、個部門具體做事情的的支持，他們是需求的提出者，系統(tǒng)的最終使用人。如果你能心的幫助他們解決問題，他們也會真心的幫助你。交銀康聯(lián)項目很幸運，不僅是“工程，還是各個部門長都參與的項目，每個部門都非常配合項目的實施，IT 部門總每天都會關注項目的進展，有什么問題立刻會幫助解決。這是項目能夠做的比較好的最關鍵的。1.2.和諧的合作環(huán)境交銀康聯(lián)項目是一個大團隊組成的，是一個聯(lián)合，在現(xiàn)場實施的前后包括 BA 團隊、項目實施組、銀保通組、數(shù)據(jù)移植組、測試組以及期從其他項目組過來支援的同事。各個團隊都分屬不同的部門，各自有各自的線匯報經理。在交銀康聯(lián)項目組中，大家都配合的非常默契，每個人都把這里當做自己的項目，

9、認真工作，對客戶負責、對質量負責。同時項目也得到了其他項目組的大力支持，問題，大家都協(xié)力給目組支招，提解決方案。例如，團隊建設中的“培養(yǎng)志同道合者”就是金融服務部給的建議，建立“政委制”就是數(shù)據(jù)移植組提供的建議；另外姚仁義、這些同事為項目組提供了大量的幫助和支持；BA 組的表經理的一直為項目的需求實施提供及時、詳細的。項目組在建設過，就一直認為，項目組要像家一樣親切，不能讓任何一個人在這里受到了委屈。也正是于這樣的想法相處的非常，由于，的工作成效更加的顯著。二、在細節(jié)項目是一個歷時長，多，任務重的系統(tǒng)工程，很多細節(jié)保證了項目的順利進行，這些細節(jié)如果不被提前注意到，有可能會對項目造成致命的。“千

10、里之堤，毀于蟻穴”這句警句一致回蕩在耳邊，時刻不敢掉以輕心。項目初期，對細節(jié)也沒有足夠的重試，很多事情都得過且過了。是客戶的細心、嚴謹讓養(yǎng)成這樣的好的。特別是從 CBA 聘請的顧問、BA，可以說是事無巨細。其中的顧問 CF，在評審的計劃時，常常會問到每一個人每一天要處理的任務，如何處理？為什么需要花費這么多時間？需要修改哪些地方？評審設計方案的時候，會檢查的數(shù)據(jù)庫表設計，展示界面設計，以及例設計。在需求分析過，他經常問是：為什么要這樣做？其他公司怎么處理的？一位負責需求的 BA 同事，在開發(fā)前，將系統(tǒng)所有的報表樣式、通知書打印樣式與用戶一張了三遍，確認一張簽字一張，確認后的才進行后期的開發(fā)。還

11、有 IT 部門的趙總，對提供的方案，會反復的研究，提供建議和提出質疑，只有解決所有問題后才進入實施階段。正是由于客戶這樣的要求，在日常工作中才漸漸養(yǎng)成了這種良好的習慣。關于項目過的每一個細節(jié)。對于需求，會仔細分析每一個頁面的元素布局，業(yè)務流程，操作方式，通知書，報表的展現(xiàn)。并且會涉及案例、場景反復用戶進行，找到用戶的真正的需求。如果對于一些復雜的需求，還會與其他項目組的同事，吸取其他公司的經驗；對于開發(fā)計劃，對每一個任務拆分都會細化到 1 人/天，最多不會超過 3 人/天，并且對于計劃中的每一個任務，模塊，項目經理都需要能過回答為什么要這么長時間，需要修改哪些點；對于測試計劃，需要明細到每天每

12、個人測試哪些內容，哪些案例，如何測試？每個版本中都會對重點的需求進試案例評審，要求具體的測試同事講解測試思路，案例內容；對于方案設計，必須要有案例、業(yè)務場景的說明，底層數(shù)據(jù)庫的設計，負責方案實施的同事，需要在實施前進行方案的講解，如果有細節(jié)沒有講清楚，會在當天晚上或是第二天上午繼續(xù)講解，指導方案評審通過。在進行問題分析、判斷時，也注重的說明，任何問題、事情都不會在“基本上”、“大概”、“可能”這些帶有猜測的情況下進行，每次或是下決策時，總是將事情的根源找到，通過數(shù)據(jù)、圖表、事實來作為判斷的依據(jù)。項目組信任所有的同事，但是項目組從來不把大家的拍腦袋、拍胸脯作為判斷的依據(jù)。注重細節(jié)的確很辛苦，為此

13、項目組的同事也經常熬夜、加班，付出了很多心血。記得在 10 年 7 月份時，一位測試同事關于分紅的的疑問，讓技術經理、保全幾乎通宵未眠，從各個角度來分析、論證如何處理?，F(xiàn)在來看，正是由于大家這樣的認得到了用戶的認可，也才使得項目可以順利的進行下去；正是由于大家對細節(jié)的關注，才沒有將那個“該死的放出來影響項目的進程。三、建立完善、細致的項目管理計劃交銀康聯(lián)項目的嚴格、規(guī)范是在用戶高標準的要求下產生的。參與項目的人員包括原中保康聯(lián)用戶、交通IT 的、CBA 同事。多，文化背景、企業(yè)背景都各不相同，為了能夠使大家在一個的規(guī)則下行動，采用的語義，項目組必須制定完善、細致的規(guī)則，否則大家都按照各自的、方

14、式來工作，不僅增加溝通的成本，更有可能由于理解的差異存在大量的返工的現(xiàn)象。為此在以下幾個方面進行了嚴格的控制。3.1.需求管理計劃需求管理在項目管理過處于最前沿最重要的位置。僅從字面出發(fā)，如果一個系統(tǒng)滿足了客戶需求，那它無疑就是成功的。需求管理的過程，從需求分析開始貫穿整個項目始終，力圖實現(xiàn)最終系統(tǒng)同需求的最佳結合。需求的變更通常會對項目的進度、人力資源產生比較大的影響，隨著項目生命周期的不斷推進，用戶對需求的了解越來越深入，會不斷提出一些新的想法。然而考慮到實際情況，在項目的執(zhí)行過增加需求和變更需求是不可避免的，對于需求的變更，本質上是對需求的范圍進行了變更，即對項目能夠順利實施的基礎進行了

15、變更，因此需要雙方在需求管理方面達成共識、共同參與、共同控制?；诖?，從需求管理的流程、工具、方式、評審的過程、各個組的角色及職責都與所有用戶達成了共識，并反復的項目組中進行強調與監(jiān)督，以保證最的部分不出現(xiàn)問題。3.2.進度管理計劃進度管理計劃包括項目階段劃分和詳細的項目實施計劃兩個部分，劃分大的項目階段是為了確定項目的整體方向與每個階段的重點內容；制定詳細的項目實施計劃是為了控制項目實施過的每一個細節(jié)?？傮w實施上，將系統(tǒng)的實施劃分為兩個階段，第一個階段完成新系統(tǒng)的功能，滿足業(yè)務需求；第二個階段完成數(shù)據(jù)移植的工作，進行新舊系統(tǒng)替換。在每個階段內開發(fā)、測試、UAT 測試交替進行，以迭代的方式推動

16、項目。詳細的項目實施路線如下圖所示：針對每一個階段內的詳細任務，項目組進行了認真分解，在項目初期時共制定了 835 項任務，對前期任務明細化，后階段任務概念化，計劃中規(guī)定了對于一個月內的計劃，任務必須拆分到 3 人/天內。在總體細化要求的基礎上強調適用，而非表面化，程序化，一切為了實際的實施服務。為了使計劃可控，并可追蹤，項目組借鑒敏捷，從中吸取對項目組有利的內容，制定了版本周期，及用戶故事，每一個版本都提供用戶一系列完整的用戶場景，逐步推進計劃的實現(xiàn)，降低計劃失控的風險。同時項目組舉行站立會議，問題當日核對的方式，提高工作效率。任何計劃的制定都不可能一點變化沒有，在制定計劃時就預留了相關的風

17、險期設置，例如項目組對每一個開發(fā)工程師在 3 天的開發(fā)任務后都會設置一天的風險期，該風險期只是作為該工程師沒有按時完成任務的預留量來統(tǒng)計，并其實際的工作量的安排，如果某一個工程師使用了其風險期，項目組會在當周的總結會議上與相關同事一起，找出問題所在，避免后期再次發(fā)生。計劃制定后也不是一成不變的，項目組每周都會對計劃進行細節(jié)上的調整。但是對了調整后的計劃是否生效，在進度管理計劃中制定了詳細的流程，需要提交每周的項目例會確定。至最后項目全部推上線，項目明細計劃一共包含 2117 項任務。3.3.測試管理計劃在制定項目組的測試管理計劃時，共分為兩個部分測試、用戶測試，用戶測試主要監(jiān)督執(zhí)行，這里主要以

18、測試為例來介紹測試管理計劃的內容。項目組定義系統(tǒng)質量或是用戶對系統(tǒng)的滿意度不是以生產環(huán)境的使用情況為標準，而是以用戶測試環(huán)境的使用情況為依據(jù)，因為這是用戶對系統(tǒng)的第一印象，決定著用戶對系統(tǒng)使用的直接評價。因此項目組非常重視測試的質量，將其作為系統(tǒng)質量、項目成功的最后屏障。為此，在制定測試管理計劃時，從測試組同事的架構、測試方法、測試過程、測試范圍、測試標準、用例管理、問題管理、測試、會議管理、溝通管理、UAT 測試交付管理方面進行了詳細的規(guī)劃，盡量考慮到測試中每一個細節(jié)或是有的部分，進行詳細說明。3.4.風險管理計劃在項目實施過，由于本身客戶化的內容較多，投入的資源也較大，這樣造成了某些“未知

19、量”。這給項目的實施帶來了一定程度的風險。當然，風險的存在是很正常的事情，關鍵是如何來控制。為了避免項目風險變成問題，項目組采取了主動積極的風險管理策略，著力預防和消滅根源的方法。在項目實施過程中，及時標示出潛在的風險，評估它們出現(xiàn)的概率及產生的影響，對風險按重要性進行排序，然后建立風險列表來進行管理（風險列表采用 QA 提供的風險列表樣式，如下表所示）。依次采用風險識別、風險評估、風險規(guī)劃、風險控制的步驟循環(huán)進行。項目的風險是很繁雜的，項目組不可能對所有的風險都能夠識別出來，事實上沒有必要識別出所有的項目風險。項目組結合實際的情況，每月采用一次寬德方法對項目風險進行識別，每周采用一次頭腦風暴

20、法、情景分析法對項目風險進行識別，同時通過定性、定量的風險編制風險列表（由于技術問題，主要還是采用定性的分析方法）。為了在時間上能夠滿足項目的實際情況，每次風險識別列表中僅包含 10 項風險，稱之為 TOP10 風險。然后每天追蹤風險清單中的內容，采取措施進行控制、改善。3.5.配置管理計劃配置管理是項目的，如何將版本的控制做得可以查詢？如何保證整個團隊的流程能夠順暢？如何能夠保證并行開發(fā)的進行？如何在迭代的過進行版本之間的管理，這些都在配置管理計劃中進行了解答。項目組制定的配置管理計劃從角色職責和、配置管理環(huán)境、配置標識、配置庫的說明、配置和變更控制、配置狀態(tài)統(tǒng)計、基線審計、培訓要求八個方面

21、進行了詳細的說明。角色、職責和是為了說明項目組各個組、成員之間的工作范圍、職責，讓大家都清楚自己的職責范圍，明細化各自的權利與義務；配置管理環(huán)境對項目組的開發(fā)和代碼集成環(huán)境、配置管理工具進行了詳細的介紹；配置標識（如下圖所示）是配置管理的根本，說明了配置管理將控制哪些內容，并對配置標識的定義標準進行了說明，同時也介紹了配置基線的建立；配置庫的說明主要是介紹對配置庫的管理方法，包括配置庫位置、配置庫結構、配置庫權限定義、配置庫備份與安全防范；在配置和變更控制小節(jié)，介紹了工作空間規(guī)則及變更控制的方法；從管理的角度來看，更希望了解誰在什么時候改變了些什么？為什么改？也希望了解到項目進展的如何、完成了

22、多少工作量？開發(fā)工程師的資源是否充分使用、工作是否平衡等信息，因此，在配置狀態(tài)統(tǒng)計小節(jié)，從SCCB 會議備忘錄、變更請求、基線狀態(tài)進行了說明；同時配置管理計劃對基線的審計以及新同事的培訓進行了詳細說明。項目組在配置管理崗位上的同事有了近 4 年的工作經驗，工作仔細、認真、負責。正是努力工作，才保證了平均 30 多人的團隊、涉及 7 個開發(fā)、測試、數(shù)據(jù)移植環(huán)境的日常工作能夠高效、有序的運轉。3.6.溝通管理計劃對于項目而言，要做到及時成功地完成并能達到或者超過預期的結果，是很不容易的。在完成下達的任務時，既要有規(guī)定的項目計劃，還要有一套適時的執(zhí)行方法，但同時又不能扼殺整個項目開發(fā)過的創(chuàng)造性和性，

23、這樣，就必須有一個靈活而且容易使用的溝通方法，從而使一些重要的項目信息及時更新，做到實時同步。在 IT 項目中，許多都認為：對于成功，最大的就是溝通。很多人認為 IT 項目成功的三個主要分別為：用戶的積極參與，明確的需求表達，管理層的大力支持。而這三個要素全部依賴于良好的溝通技巧，特別是對于非而言更是如此。溝通管理的目標是及時并適當?shù)貏?chuàng)建、收集、發(fā)送、和處理項目的信息。其在項目成功所必須的人、想法和信息之間提供了一個關鍵連接。涉及項目的任何人都應以“項目語言”發(fā)送和接受信息。為此，項目組的溝通管理計劃從項目干系人、溝通內容、溝通頻率、溝通方式、以及存在的風險進行了說明。例如，項目組的結構3.7

24、.培訓管理計劃3.7.1培訓團隊建設是實現(xiàn)項目目標的重要內容，而項目成員的培養(yǎng)是項目團隊建設的基礎，項目組織必須重視對員工的培訓工作。通過對項目成員的培訓，可以提高項目團隊的綜合素質、工作技能和技術水平。同時也可以通過提高項目成員的本領，提高項目成員的工作滿意度，降低項目的比例和人力資源管理成本。針對項目的和制約性（主要是時間的制約和成本的制約）特點，對于項目成員的培訓主要采取短期性的、片段式的、針對性強、見效快的培訓。培訓形式主要有兩種：1) 崗位前培訓，主要對項目成員進行一些性的崗位培訓和項目管理方式等培訓；2) 崗上培訓，主要根據(jù)開發(fā)的工作特點，針對操作中可能出現(xiàn)的實際問題，進行特別的培

25、訓，多偏重與專門技術和特殊技能的培訓。當然，這里的崗位前培訓與崗上培訓不是脫離實際業(yè)務或工作來做獨立的培訓。對于每一個同事，都指定了一個師傅，但不一定受其或是分派任務，主要是對其進行基本的業(yè)務、行政的培訓與指導，使其在平時的工作中能夠有人可問，有榜樣可循。無論新老員工，是否是熟悉的業(yè)務，都不會安排時間讓他們專門學習業(yè)務系統(tǒng)，閱讀系統(tǒng)設計說明書或幫助文檔。這樣做的效率并不高，我們總是讓大家?guī)е蝿諏W習，帶著問題去找解決方案，如果存在有疑問或是需要的地方，會及時的召集有經驗的同事一起，對其出謀劃策。同時，每周還有一次業(yè)務或是技術培訓，項目組會讓講一次業(yè)務系統(tǒng)難點，或設計難點、難點技術、技術。這樣的

26、培訓從表面看浪費時間，實質上對團隊的凝聚力、學習能力、配合能力都有所提高。在這里根據(jù)項目組的實際運行過程，總結了三點：1)通過 2 到 3 天的時間對新入職的同事做一個緊湊的培訓，在短時間內灌輸大量的保險業(yè)務知識及系統(tǒng)的架構、組件、開發(fā)方法；2)根據(jù)個人能力及培訓的實際效果安排一個略高其水平的開發(fā)任務；3)每天仔細檢查其完成的情況如何？并提供相應的指導；4) 用老師的心態(tài)來帶新人。3.7.2 用戶培訓在項目的售前、實施過，培訓是始終的，起初的培訓是因為客戶的推動與要求，處于一個的狀態(tài)，因此也很難得到客戶的認同。后來，認識到通過培訓，能夠讓用戶熟練掌握系統(tǒng)的操作，讓用戶提出真正需要的需求，同時也

27、能增加用戶對項目的認同感，推動項目。在進行用戶培訓的安排時，主要從三個方面來進行規(guī)劃。1) 培訓計劃培訓不是一個隨心所欲的事情，培訓前要分析、本次培訓的目的，然后確定出培訓的用戶群，再根據(jù)具體的實施階段選定不同的培訓內容，然后根據(jù)大家的時間安排排定好具體的培訓時間表，并提前發(fā)給所有需要參與培訓的。2) 培訓實施培訓是一個講解系統(tǒng)的過程，同時也是一個向用戶展現(xiàn)專業(yè)能力、系統(tǒng)功能、工作態(tài)度的過程。3) 培訓考核培訓后不能聽之任之，項目組結合交銀康聯(lián)的實際業(yè)務，準備了適當難度的培訓考題，已檢驗大家是否對培訓內容已掌握，甚至是在上線前期的培訓后，我們組織大家進行正式的上機業(yè)務模擬，以減少上線后線上操作

28、問題，操作的不等問題。培訓的目的是讓大家掌握系統(tǒng)對業(yè)務的處理，所以提高大家的積極性是必須要考慮的，為了使得考核不給培訓帶來消極的影響，項目團隊采用“鼓勵優(yōu)秀、淡化”的策略促進培訓深入開展。4) 培訓反饋培訓完成后，會請參與培訓的填寫培訓效果反饋表，以對后面的培訓進行調整。四、堅決執(zhí)行任何一個稍大規(guī)模的項目都有這樣那樣的規(guī)范、流程，有些項目按照 CMMI5的規(guī)范來制定項目計劃、要求。但是為什么有的項目比較順利，有的項目卻重重呢？關鍵點就是執(zhí)行，沒有規(guī)范、流程肯定，有了這些規(guī)范、流程不去認真的執(zhí)行也是廢紙一堆，沒有任何實際的效果。那么項目組是如何解決執(zhí)行這個問題的呢？4.1.不斷宣導規(guī)范、流程人是

29、有惰性的，也會受以往的影響，而項目組這么多的規(guī)范、制度如何才能讓大家都能夠記住，并按照標準來進行實施？不能像培訓那樣，將大家集中進行培訓，然后再參與實施，這樣效果也不理想，在處理具體問題時還是不知道應該填寫什么表，通知什么人。結合實際情況，根據(jù)人們的遺忘特點，前期每一、二天就給大家講解一下各個領域的規(guī)范、計劃、流程，并逐漸拉大宣講的間隔、頻率。后期基本一個月才對所有的內容回顧一次。同時，對于執(zhí)行過不清晰的同事，采用“開小灶”的方式，單獨培訓，反復提醒，重點檢查直到該同事掌握該項內容。當然，這里的宣講也不是需要開一個大會，需要很正式的形式。項目組有時候是選擇近段時間錯誤率比較多的流程、規(guī)范進行宣

30、講，或是挑選比較重要的內容進行介紹，每次介紹的時間大概也就在 1520 分鐘的時間，如果大家沒有問題，就結束該項內容。4.2.提高個人執(zhí)行力制度是有項目團隊成員來執(zhí)行，每個人對制度的執(zhí)行力才是關鍵。而個人執(zhí)行力的強弱取決于兩個要素個人能力和工作態(tài)度，能力是基礎，態(tài)度是關鍵。所以，個人執(zhí)行力，一方面是要通過加強學習和實踐鍛煉來增強自身素質，而更重要的則是工作態(tài)度。項目組提出“要去做，并要做好”的工作態(tài)度，通過各種事例、案例來講解如何提高的執(zhí)行力，通過一些拓展活動來鍛煉大家的執(zhí)行力。從各種角度來培養(yǎng)大家踏實工作，靈活處理的工作作風。“天下大事必作于細，古今事業(yè)必成”，只有大家明白了這個道理，我們才

31、有走下去，并走好的本錢。4.3.監(jiān)督者既然是人在執(zhí)行，出錯也就是不可避免的，因此引入監(jiān)督者也成了必然。但是設定的監(jiān)督者并不是單獨的設置一個崗位來監(jiān)督流程的執(zhí)行希望有這樣的崗位，但是成本是不允許這樣來做的。為此，把監(jiān)督的任務放到了各個環(huán)節(jié)的下游人身上，這位同事不僅掌握著第一手資料，并且他也愿意來組織這個事情，因為流程出現(xiàn)了問題，第一個受影響的就是下游的同事。例如，需求負責人沒有按照流程進行需求確認，就將需求提交到開發(fā)組，開發(fā)組接觸到這樣的需求安排開發(fā)有可能因此變更，不安排開發(fā)，客戶又知道需求已經流轉到開發(fā)崗了，會不斷的來具體的開發(fā)時間。所以開發(fā)組長實際就成為了需求管理計劃中需求到開發(fā)這個環(huán)節(jié)的監(jiān)

32、督者。開發(fā)會每周統(tǒng)計沒有按照流程處理的事項，在項目例會上進行，并確定大家注意執(zhí)行。另外重要一點就是，監(jiān)督者提交的信息，項目經理必須仔細對待，認真處理，并將后續(xù)的處理步驟與監(jiān)督者進行仔細溝通，并定期的匯報改進情況。最好是能夠使問題可以及時的得到解決，讓監(jiān)督者看到實際的效果。這樣大家才有動力繼續(xù)對大家的執(zhí)行效果進行監(jiān)督。4.4.審計人對項目團隊流程的執(zhí)行情況，還引入了審計制度，包括公司 QA詢問，CBA 建立團隊的監(jiān)理，以及項目組的流程審計。項目組的審計是為了盡早的發(fā)現(xiàn)問題，及時的改正，以將問題造成的損失降到最低。引入外部的審計其實是給項目組壓力，這樣來自外部的壓力更能幫助團隊找出存在的問題，避免

33、影響到項目質量。流程、規(guī)范是有人來執(zhí)行和遵守的，也就是說是一個問題，所以制度能否很好的執(zhí)行，關鍵是要不斷的堅持，仔細的檢查。此時的痛苦，是為了能過順利完成項目的。五、利用數(shù)字與圖表一個項目能過順利完成，前提是每一個階段的任務能夠順利完成；而每一個階段的任務沒有問題，在于對每一個小的里程牌的奮斗；要保證每一個里程碑都完成的較好，需要對項目的每一天的狀態(tài)都有一個清晰的反應，能夠通過詳細、細致的數(shù)字、圖形反饋項目組目前，便于的判斷與行動。在理論上項目越大，時間越長，監(jiān)督的間隔可以適當放長，但是，每一個大的階段都是由經過的每一天組成了，所以項目組堅持認為將項目組的間隔設置為 1 天，是合理的且可的。為

34、了反應項目組的實際狀態(tài)，定制了工具，能夠從需求、開發(fā)、測試三個方面來進行統(tǒng)計。5.1.需求在需求方面，通過差異化列表用戶的差異化需求，差異化的中的每一項任務都包括提交環(huán)境的選項，初估的工作量，是否關閉的選項。每一個版本完成后，需求會根據(jù)版本的提交情況，更新該差異化，因此從該能夠統(tǒng)計需求的條數(shù)，概要的工作量。如下圖所示5.2.開發(fā)在開發(fā)方面，項目組制定的版本迭代周期為一個月。為了追蹤的方便，主要對一個版本內的任務進行追蹤。對每一個任務，通過紅、黃、綠燈進行狀態(tài)的區(qū)分，綠燈表示正常業(yè)務，黃燈表示存在風險，紅燈表示存在問題。如下圖所示：同時，對每一個模塊也進行了統(tǒng)計，從模塊的角度來看哪個模塊出現(xiàn)嚴重

35、，從而進行資源的協(xié)調，如下圖所示：項目的任務是由項目團隊成員來完成的，為了能夠反映每一個成員的任務完成情況，針對每一位同事也做了工作完成的情況統(tǒng)計：對于出現(xiàn)異常狀態(tài)（紅色、黃色）的同事，會針對其負責的任務進行分析與，幫助他找到問題的癥結所在，盡量的采取措施將工期趕上來。為了統(tǒng)計在這個版本中大家的努力，也對每一個成員的月累計完成情況進行了統(tǒng)計，統(tǒng)計的依據(jù)是的完成狀況，如下圖所示：為了估算項目風險，項目組還編寫了一個簡易的風險評估工具，可以根據(jù)版本任務的總工作量，及當前工作量的完成情況，估算出到某一個預計值是否存在風險，并可以估算需要增加多少資源才能彌補這個資源缺口。5.3.測試測試是系統(tǒng)質量控制

36、的最后環(huán)節(jié)，也是最好的保證，測試情況最能夠直觀反映當前項目的實際狀態(tài)。在第四章的第三小節(jié)過，通過對缺陷的，狀態(tài)的追蹤來管理缺陷的情況。然后通過對這些數(shù)據(jù)的統(tǒng)計、分析來反映項目的質量情況。在統(tǒng)計維度上可以分為送測需求統(tǒng)計、缺陷收斂統(tǒng)計兩類。1. 送測需求統(tǒng)計送測需求統(tǒng)計是對提交測試的功能需求的統(tǒng)計，包括需求送測情況、需求測試執(zhí)行情況、案例執(zhí)行情況三個方面進行統(tǒng)計。其中需求送測情況包括應送測、已送測、未送測三個部分的數(shù)據(jù)；需求測試執(zhí)行情況包括可執(zhí)行、已執(zhí)行、未執(zhí)行、已通過、在進行、不通過、執(zhí)行率、通過率、總體執(zhí)行率、總體通過率 10個部分的統(tǒng)計數(shù)據(jù)；案例執(zhí)行情況包括案例總數(shù)、通過數(shù)、未通過數(shù)、通過

37、率四項統(tǒng)計計信息。為了能夠直觀的反應需求總體通過率的情況，還制定了總體通過率趨勢圖，如下圖所示：2. 缺陷收斂統(tǒng)計缺陷收斂統(tǒng)計是從 BUG 的角度來系統(tǒng)狀況，從 BUG 的總體缺陷情況、嚴重程度、原因、當日缺陷情況進行數(shù)據(jù)統(tǒng)計。其中總體缺陷情況包括新建、打開、固定、開發(fā)、問題重提、需求處理、已修復、已發(fā)布、測試接收、已取消、已關閉項，是從缺陷的狀態(tài)來進行分析；嚴重程度包括緊急、嚴重、普通、輕微；BUG 產生原因包括程序錯誤、產品定義錯誤、需求問題、版本發(fā)布問題、操作問題、遷移數(shù)據(jù)錯誤、其他；當日缺陷情況包括提交、修復、關閉。通過未關閉缺陷趨勢圖可以反映缺陷的收斂情況,如下圖所示：通過當日缺陷情

38、況可以統(tǒng)計確定平均處理情況及根據(jù)以前狀況統(tǒng)計的關閉全部缺陷所需的日數(shù)：六、建立敢打、敢沖的團隊6.1.個人與項目共贏項目團隊的士氣是項目成功的一個重要，而團隊士氣是需要項目經理不斷的激勵來調動的。激勵團隊士氣有很多種方法，也有很多理論上的指導，我認為關鍵是要找到大家的，將團隊成員的需求與項目的需求結合起來，保持一致，讓大家在實現(xiàn)個人需求的同時也能實現(xiàn)項目需求。根據(jù)的需求層次理論，人類的需要是以層次形式出現(xiàn)的，共有 5 個層次，生理、安全、社會歸屬、自尊和自我實現(xiàn)。自我實現(xiàn)是最高的層次，低層次的需求必須在次需求滿足之前得到滿足。后期佛近一步發(fā)展了的需要層次理論，認為：有的需要（如自我實現(xiàn)）是后天

39、通過學習而產生的，人的需要不一定嚴格地從低到高的順序發(fā)展，并提出了有名的“挫折”假設，管理者應努力把握和控制好工作結果，通過工作結果來滿足人們的各種需要，從而激發(fā)人們的工作。正是給予這樣的理論指導，根據(jù)項目組的特點，發(fā)現(xiàn)項目組部分同事是剛參加工作的畢業(yè)生，部分同事有 1 到 2 年工作經驗，只有及少數(shù)存在 3 年以上的工作經驗。也就是說在這個團隊中，針對每一個個人來說，能夠通過工作大家的能力，使得自身的價值在不斷提高是當前最為關注的問題。因此，項目組根據(jù)大家的、分配不同的任務，并且提供一切可以提供的機會讓參與感的任務，通過任務的完成來提供自能力，同時也提高了自信心，在后面的工作中也有接受更有性

40、的工作。但是對于老員工，特別是在公司三年以上的老員工，大家都在考慮到成家、購房、養(yǎng)家，如何在實現(xiàn)項目的過程滿足大家這個方面的需求，目前還沒有一個好的想法，這也為老員工的流逝留下了隱患。項目團隊一致認為，追求進步、追求卓越的同事其實是在實現(xiàn)個人目標的過，順便把項目的目標也實現(xiàn)了。6.2.項目經理以身作則一個團隊的或是氣質是和團隊的人有關的，這個人的氣質、做法將影響到項目團隊中的每一個人，久而久之將成為項目的一種文化沉淀下來，影響進入團隊的每一個人。因此，一個項目的成功可能和項目經理的關系不大，但是一個項目肯定與項目經理的一些不恰當?shù)淖龇ㄓ嘘P。所以，在交銀康聯(lián)項目組中，要求項目經理必須是沖在第一線

41、的，必須是最刻苦的，必須是最受累的一個人，己所不欲勿施于人。對于項目經理的本質工作需要保質保量的快速完成，同時也需要了解各個小組的工作情況，對項目的狀況有一個清晰的認識；如果大家的工作出現(xiàn)了，項目經理還需要想辦法去幫助大家解決；需要能夠控制需求的風向、流程的執(zhí)行與進度的把握。總之，需要八面玲瓏，無所不關注。但是，項目經理也是人，怎么掌握所有的細節(jié)？如何分配時間？要求項目經理以身作則，不是說項目經理需要所有事情都親力親為，也不是說要項目經理精通每一個細節(jié)。這里所說的以身作則，包括幾個方面的含義：第一：對于需求分析、計劃安排、計劃追蹤、異常處理這些項目經理份內的事情，項目經理必須想盡辦法完成好，如

42、果連自己的本質工作都完成的不好，如何控制其他同事的進度？第二：對于與客戶的合作，項目經理需要具有為客戶服務、客戶至上的服務心態(tài)，與控制項目發(fā)展的“大項目經理”形態(tài)（這里所說的大項目經理只是為了強調對客戶的推動）；第三：在業(yè)務上，項目經理需要對整個業(yè)務的開展、系統(tǒng)的操作、功能達到熟悉、精通的程度，在某一方面可能沒有其他同事精通，但是對于整體的把握一定要具有獨到的見解；第四：在技術上，項目經理不一定是一個技術強人，但絕對不能讓工程師覺得同項目經理溝通時是對牛彈琴；工作時間上，項目經理可以不是工作時間最長的，但是不能讓一位同事認為他的工作時間比你的還長。第五：在協(xié)助上，項目經理需要經常組織大家參與培

43、訓，必要時能夠親自結合項目解釋，每做一件事情，需要讓大家明白為什么做，怎么做以及這樣做的價值，不做可能帶來的。方法論要細到操作層面，提供豐富又典型的工具和模板，讓項目成員可以獨立進行各個環(huán)節(jié)的工作；第六：在成長上，項目經理應該是一個熱愛學習的人，無論多么累、多么忙，項目經理都應該保持這樣的，都應該有自己學習規(guī)劃，例如計劃看些書、學習業(yè)務等等?？傊?，要想團隊進步，只有大家通過學習來進入，如何才能推動大家學習的積極性呢？首先就是項目經理做出表率。以身作則？就是大家你的精神、態(tài)度，覺得有力量,覺得你是可信任的人。6.3.培養(yǎng)志同道合者現(xiàn)在的項目越來越復雜，團隊規(guī)模也越來越大，一個團隊不可能僅僅靠一兩

44、個人來支撐，必須靠整個團隊協(xié)力才能完成。因此有一群能支撐你的成員是項目能夠可以完成的基礎。但是一個項目能夠得到的支持、員工高素質、客戶高素質幾乎是不可能的，即使希望在團隊中每個模塊都有一個熟練工都是比較奢望的事情。這樣的困境不是僅僅只有交銀康聯(lián)這個項目存在，其實大部分的項目都存在這樣。解決之道就在于：項目組的同事能夠和項目經理對項目的期望目標是一致的，大家都一股力，一起往前沖。這樣老員工可以發(fā)揮其優(yōu)勢，將自己負責的模塊做到優(yōu)秀，經驗較少的員工可以在大家的幫助，通過時間來彌補業(yè)務、技術上的缺陷，在每次與用戶交流時可以提供一個滿意的方案，每次提交功能時，都能較好的實現(xiàn)用戶的需求。如何才能有這幫可愛

45、的人來幫助你?對于老員工，應該抓大放小，搭臺唱戲。許多管理者喜歡對下屬揉捏有余，風行，顯得自己很有手腕。項目組更喜歡，對于有能力的同事，項目組更喜歡給大家提供舞臺，引導目標，提供經驗指導，讓大家互相搭配表演一場好戲。我是比較謹慎的人，但是對于有能力的，經過實踐證明做事認真負責的同事負責的事情，我喜歡抓大放小。根據(jù)二八原則，一件事情的關鍵點也就是那么兩三個。你抓住了關鍵點，項目的發(fā)展就不可能偏得太遠。有了問題，我會先看看大家怎么解決，也不，但如果發(fā)現(xiàn)開始就沒有一個好的方案、規(guī)劃，我也會處理，以防事情失去控制。當然，由于過于謹慎、當心的心態(tài)，也導致很多事情都處處事必躬親，雖然沒有像一樣嘔血而死，死

46、后還蜀中無大將，廖化做先鋒。但是也給項目組的發(fā)展，后期留下了隱患。從這個方面來講，我也是一個不合格的項目經理。對于在崗位上經驗比較少的同事，項目組采用教一段、扶一把、送一程的方式，在準備階段，協(xié)助大家將方案做細、做通；在階段，陪同一起，讓大家有底氣、有信心；在實施階段，經常一起回顧，一起修訂方案，檢查成果，讓大家覺得不是一個人在戰(zhàn)斗；完成后，在一起總結，找到做的好地方，存在問題的地方。通過這樣的方式，幾輪下來，新員工也就逐漸成了老員工了。目前很多剛剛不到一年的同事就可以獨自負責一個模塊了。無論工作、生活，都不拋棄、不放棄任何一位同事，只要自己愿意，項目組總是會提供機會來讓大家成長。但是，如果一經證明不適合這個崗位，