摘要：
安裝部署系統、培訓客戶使用系統、推動系統上線等工作就是實施工作。實施工作的重要性有點象足球比賽的“臨門一腳”，前面所有工作都做好了，如果臨門一腳特別臭，前面的工作都會付諸一炬。實際上實施工作需要從專案一開始就要進行，並且對實施工程師的要求很高，除了技術要求，還有業務以及商務上的技能要求！
說明：
這是“挨踢專案求生法則”系列文章，之前已經為大家分享了戰略篇、團隊建設篇、需求篇、設計篇、編碼篇、測試篇，這篇是實施篇。
什麼叫挨踢專案？
IT專案，特別是軟體開發專案，都屬於“挨踢”專案的範疇。挨踢專案的幾大特點：
1.需求不確定。
2.技術不確定。
3.工期限死。
4.預算限死
兩大不確定和兩大限死，你想不“挨踢”都難！
什麼是實施工作？
實施工作內容主要有：
1）安裝系統，包括整治網路環境、安裝資料庫、安裝程式等一系列工作；
2）培訓客戶使用系統，解答使用者使用中的問題，推動系統上線；
3）推動驗收；
4）反饋客戶對系統的意見給專案組。
看上去實施工作似乎是專案後期的工作，但實施工作其實是需要從專案一開始就要準備的，以下工作需要前期就做好：
1）熟悉客戶業務，熟悉需求；
2）瞭解客戶的IT環境，根據系統的要求提出整治要求，並幫助客戶做好準備；
3）編寫使用者文件，通常至少包含兩種文件：一種是給一般使用者使用的，一種是給系統管理員使用的。
4）編寫實施計劃，準備實施環境進行演練；
5）熟悉客戶各層次的關鍵人物，和他們搞好關係，為後續工作做好準備。
實施工作需要具備的技能
要完成上述工作，實施工程師需要具備以下的技能：
1）熟悉網路、作業系統和資料庫；
2）熟悉客戶業務，熟悉需求；
3）能和客戶溝通和保持良好關係的技能；
4）需要有一定的商務觸覺。
不要“歧視”實施工作
我曾經“歧視”過實施工程師，甚至認為不需要專職的崗位，開發人員或者是專案經理親自去實施就可以了。
我“歧視”的原因有：
1）當時的實施工程師技能比較欠缺，經常還裝不上系統，需要開發去支援；
2）當時的實施工程師對業務不熟悉，需求不瞭解，客戶很多問題不會回答，不會“頂”回一些問題，只會做客戶的“傳聲筒”；
3）當時的實施工程師學習的動力不大，沒有意願去改善業務水平。
法則1：實施的首要工作是推動驗收
實施工作的首要目標是推動驗收，安裝程式、培訓客戶等等這些僅僅是手段，最終目的就是要驗收！
通常合同中規定的付款方式是這樣的：
1）合同簽訂後給一筆頭款，通常佔合同總金額的20-30%；
2）驗收後付款合同總金額的60-70%；
3）維護期後給合同總金額的10-20%。
付款大頭就是驗收後的那筆付款，所以推動驗收是實施工作的首要目標！你要這樣看待這個工作：如果不能驗收，你將沒有60-70%的工資！這樣你就會足夠重視實施工作了。當然推動驗收這個工作通常要和負責商務的同事一起來做的。
法則2：驗收除了搞定甲方老闆還需要搞定業務骨幹
案例：驗收失敗
某專案甲乙雙方老闆很熟，驗收之前乙方老闆已經做了很多工作，甲方老闆也表示驗收沒有問題。於是驗收大會上，甲方老闆一開始就定了基調：驗收是可以通過的，有問題可以記錄下來，驗收後繼續跟進。於是甲方老闆問大家的意見，結果“驚喜”來了。由於事先的實施工作不到位，出現了以下狀況：
1）裝置沒有采購都到位，大部分人還沒有用過這個系統；
2）某業務骨幹已經用了該系統，但他反饋的意見乙方沒有重視，該業務骨幹表示該系統無法驗收。
乙方老闆沒想到是這樣的一種情況，也覺得相當不好意思和丟面子，甲方老闆也很不滿，你不能這樣忽悠老子驗收啊！
所以結果你懂的，驗收自然沒有通過，乙方還需要再付出更多的工作才能搞定這個事情。
這個是真實個案，驗收是需要大小Boss通吃的，固然要搞定大Boss，也需要搞定小Boss！
大Boss是需要下面的人工作的，他手下哪些人能幹活、哪些人不能幹活，他自然很清楚，所以如果他手下的業務骨幹認為系統不可用、不能驗收，他自然也不會同意驗收。
法則3：一定要避免“一失足成千古恨”的錯誤
悲慘案例1：資料庫資料被刪除
某專案要安裝一個小版本，對客戶的原有版本進行了升級。本來以為是一個小事一樁，但升級後客戶說見不到資料了，我們檢視資料庫，發現資料庫中的一些表的記錄全部沒有了！檢查後發現，我們的開發人員去做資料庫升級的時候，犯下了超級低階的錯誤，居然直接用SQL Server自動生成的SQL去升級，而且居然還不去看一下這些SQL語句，哪怕是去看一眼。SQL Server自動生成的SQL是很坑爹的，它首先檢查有沒有這個表，有的話就Drop掉，然後重新建表，這樣當然就刪掉了很多記錄了。本來這個悲劇的事情是有挽救的機會的，我們規定所有的升級工作之前要備份資料庫，無奈我們一直無視這個規定，一直貪方便不備份資料庫。
悲慘案例2：格式化客戶伺服器的硬碟
某客戶伺服器出問題，找我們去解決問題，實施工程師檢查後決定用“絕招”——重灌系統！實施工程師問客戶：格掉C盤有沒有問題？C盤有沒有東西要備份？客戶說：沒有！實施工程師又再次確認：格調後資料都會丟失，不能恢復的，確認沒有東西要備份？客戶說：沒有！於是C盤被格掉，系統重灌了，問題解決了。但幾天後，另外一個客戶說：C盤的某些資料怎麼沒有了？後來客戶的大Boss自然就來追究我們責任了，而之前一直說可以格掉C盤的客戶就沒有吭過聲，而我們又不能“捅”他出來。
實施工作中會有升級資料庫、格式化硬碟等“危險性”動作，做這些工作之前一定要做足備份。哪怕我們之前的工作做得很好，客戶關係搞得很好，萬一不小心幹了無法挽救的錯事，例如：刪掉了客戶幾年來的資料又不能恢復、幹掉了客戶有重要資料的硬碟而沒有備份等，這些都會直接導致災難性的後果。
法則4：使用者文件要同步交付
通常系統好不容易按期釋出了，但使用者文件是不會同步釋出的，因為根本就沒有時間去做這個事情。
但我們的要求是使用者文件必須同步釋出！這樣的要求是因為：
1）使用者文件是推動驗收的有力工具；
2）使用者文件可以降低服務工作量（參見下一條法則）。
法則5：使用者文件是為了降低服務工作量
某電視機的說明書是這樣寫的：按什麼選單，彈出什麼視窗，按“確定”按鈕確定，按“取消”按鈕取消……
看了等於沒看，這樣的說明書寫了等於沒寫，不如不寫！
應該寫怎樣的使用者文件呢？
通常的寫法是按照功能點一個一個的講解，這些的寫法是沒有什麼實質性用途的。要從客戶的角度，業務的角度來寫，通常要針對客戶的不同使用者群，模擬不同的角色的日常工作環境，告訴他要完成你的某項工作，你要怎樣使用這個系統。不需要寫“按確定按鈕確定，按取消按鈕取消”之類的廢話，客戶不是傻滴。
另外一個重要的使用者文件就是管理員手冊，要針對客戶管理員的水平，寫他能看懂能操作的文件，管理員手冊通常寫得內容是如何安裝、除錯、備份系統，通常需要寫得比較傻瓜化，要有很多截圖，要一步一步來寫。
客戶不喜歡看使用者文件，就喜歡找我們，咋辦？
我們首先保證使用者文件的質量，然後就是要引導客戶多看文件，讓客戶遇到問題第一反應是看文件，仍然不懂才找我們。
寫使用者文件不是為了要和軟體配套，不是為門面好看，而是有“陰謀”的，就是降低我們的工作量！使用者文件的方式可以是Word文件、列印出來的手冊、線上幫助、視訊等。
法則6：培訓要有針對性
技術人員做培訓，最容易犯的毛病就是從技術人員的角度來講解，結果讓大家聽到一頭霧水。我以前就經常這樣幹，而且還以為自己很牛B，你們聽不懂是因為你們不懂技術！
給客戶培訓系統，目的就是讓客戶儘快上手，然後方便驗收。通常這樣的培訓要分幾次：
1）第一次培訓：這次培訓通常叫啟動大會之類的名字，客戶最高領導會參與，中層領導也會參與，然後是大量的基層員工。
我曾經也在類似的大會上做過這樣的培訓，效果不是很好；後面我總結出這樣的大會，你的主要目標就是讓客戶的高層領導滿意，你不需要面面俱到，你需要重點介紹：
a）系統的願景和目標；
b）高層領導需要用到系統什麼功能，能幫助他實現什麼業務價值；
c）使用者的其他關鍵角色需要用到系統什麼功能，能幫助他實現什麼業務價值。
2）後續的多次培訓：這些培訓通常是針對特定的受眾的，例如：分別為不同的部門講解如何使用這個系統，這個時候的培訓就需要講得比較細了。
培訓可能是推動客戶使用系統的最節省工作量的方法。要讓客戶幾百人都用上這個系統，一對一手把手教肯定不行，我們需要有策略的培訓，同時要注意培養客戶的內部講師，讓他們可以內部進行分享。
法則7：降低差旅標準並不能降低實施成本
某公司為了節省實施成本，降低了實施工程師的差旅標準，原來可以坐飛機的改成坐火車，原來可以住3星酒店的改為2星……
實施工作通常要出差，出差工作諸多不方便，其實是挺辛苦的，如果再來一些”不人道“的差旅標準，對士氣打擊其實相當大，其實一點都不能節省成本！
降低實施成本的最有效辦法是：
1）規劃好實施工作，保證每次實施都有效果。
2）不要隨傳隨到，每次實施之前都要和客戶做好溝通，讓客戶做好準備。
3）用盡量少的實施次數和時間來達到驗收這個目的。
對實施人員的差旅待遇要好一點，當然不是非要要求住5星級酒店，但至少要給多一些的人文關懷，讓實施工程師安心和放心了，每次的工作效果自然更好，這樣就會減少實施次數，節省更多成本。
法則8：“挨義氣”做的事情一定要講清楚
客戶電話過來說：你們昨天安裝系統，搞壞了我們的系統，快來看看！
我們嚇一大跳，跑去一看，原來不關我們事，昨天動過這個伺服器的還有其他人，但是我們還是幫助客戶修復了問題。
上述僅僅是一個小個案，我們常常會幫客戶做一些合同以外的事情，但客戶並不一定知道這些是合同以外的事情，如果我們不加說明，久而久之，客戶就會認為這是”理所當然“的事情。所以一定要說明，最好一開始就說明，並且每隔一段時間來一個彙總，說明我們幹了哪些”挨義氣“的事情。我們乾的這些”挨義氣“事情，要事先請示我們的老闆，並且要報告我們的完成情況。從我們的角度看來，我們幹這些”挨義氣“的事情就是為了不得罪客戶，維持客戶關係，但從我們老闆的角度看來，我們幹這些事情是他和客戶老闆談判的籌碼。
法則9：最好設定專職的實施崗位
我曾經反對設定專職的實施崗位，我認為這個事情讓開發人員“順便”幹了就行了。但後來體會到實施工作沒有這麼簡單，對實施工程師的要求也很高，設立專職是必要的，而且效果更好。看看上文列出來的實施工程師需要掌握的幾個技能，和客戶溝通的能力、商務觸覺這兩點，一般開發人員是很難具備的。另外實施工作其實工作量挺大的，如果有專職的實施工程師，可以讓開發人員更加專注開發工作。
但剛開始設立實施崗位的時候，很可能會出現“陣痛”，總體工作量更高。當時我們實施部剛剛成立不久，但部門專案組不喜歡找實施部來實施，他們說還不如開發人員直接實施了，這樣更加節省時間，因為實施部的人不具備相應的技能。而實施部的頭反駁說：1）實施部一直等待專案組的召喚，並且一開始就打招呼了；2）實施部的同事具備相應的技能。這樣公司出現了開發部門忙死，實施部很閒的情況，而兩個部門還在PK。
要儘快完成這個過渡，我們需要：
1）無論是開發部還是實施部，都需要理解實施工作的重要性和難度；
2）所有人都需要理解為什麼要設立實施部，這個部門會降低開發部的工作量，並且更加有利於推動專案驗收。
3）前期需要開發部的同事多幫助實施部提升水平，而實施部的同事需要嚴格要求自己，儘快進步。
法則10：實施工作需要貫穿專案整個過程
這個法則我放到最後再說，看了上述法則後，相信你對實施工作應該有新的認識了，所以實施不是最後才做的工作，一開始就需要準備，並且貫穿整個過程。
實施工程師的職業發展建議
我曾經招聘過實施工程師，我必須思考這個崗位的職業發展路線，幫每一位應聘者“畫一個餅”。
這個崗位有三個比較好的發展路線，供你參考：
1）往銷售和市場的方向發展。
實施工作幫助你沉澱了技術知識和業務知識，鍛鍊了你和客戶相處的能力，為你成為超級銷售打下了基礎。從打工的角度看，可能銷售這個職位是最賺錢的，當然這個職位是高風險高收入的，但你的實施工作積累會大大地降低你的風險。
2）往專案經理方向發展。
3）往產品經理的方向發展。
小結：
實施工作是高技術含量的工作，是需要和客戶相處的工作，是需要商務觸覺的工作。
作為專案管理者的你，希望本文能對你改善專案工作帶來一些幫助；如果你是實施工程師，那麼本文特別是職業發展建議部分希望能對你有一點點小幫助。
如果本文對你有幫助，麻煩點一下“推薦”啦，謝謝！
作者：張傳波
創新工場創業課堂（敏捷課程）講師
軟體研發管理資深顧問
CMMI首席專家
《火球——UML大戰需求分析》作者
軟體知識原創基地創辦人