挨踢項目求生法則（7）——實施篇

摘要：

安裝部署系統、培訓客戶使用系統、推進系統上線等工做就是實施工做。實施工做的重要性有點象足球比賽的「臨門一腳」，前面全部工做都作好了，若是臨門一腳特別臭，前面的工做都會付諸一炬。實際上實施工做須要從項目一開始就要進行，而且對實施工程師的要求很高，除了技術要求，還有業務以及商務上的技能要求！

說明：

這是「挨踢項目求生法則」系列文章，以前已經爲你們分享了戰略篇、團隊建設篇、需求篇、設計篇、編碼篇、測試篇，這篇是實施篇。

什麼叫挨踢項目？

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）往產品經理的方向發展。

小結：

實施工做是高技術含量的工做，是須要和客戶相處的工做，是須要商務觸覺的工做。

做爲項目管理者的你，但願本文能對你改善項目工做帶來一些幫助；若是你是實施工程師，那麼本文特別是職業發展建議部分但願能對你有一點點小幫助。

我是CSDN博客之星2013候選人之一，若是你喜歡個人文章，歡迎投我一票！

投票連接：

http://vote.blog.csdn.net/blogstaritem/blogstar2013/u010825142

謝謝！

做者：張傳波

創新工場創業課堂（敏捷課程）講師

軟件研發管理資深顧問

CMMI首席專家

《火球——UML大戰需求分析》做者

www.umlonline.org創辦人