關鍵字：我來談談項目的收尾
2006年年初，公司面臨解散，但是還有部分項目沒有驗收完畢，公司高層決定采取內部員工承包的方式來解決這個問題，當時，我在公司負責物流項目，剛好有兩個項目沒有最后終驗，這兩個項目本來就是我一直負責做下來的，已經完成了初驗，所以我承包的時候是非常有信心完成最后的驗收的，我也跟公司簽定了合同，合同比較苛刻，兩個項目最后的終驗款合起來是7萬元，如果兩個項目我在規定時間內全部驗收，則公司就把這兩個項目的全部回款給我個人，否則拖延一天則賠償公司0.5%的項目款，直到達到兩個項目的回款總額7萬元，也就是說，如果我驗收不了，則要賠償公司7萬元。一般來說，IT項目的終驗基本是很難完成的，大部分公司的合同項目到了最后很多都是不了了之，要不是就拖了很長時間。我承包這兩個項目也真的是冒了很大的風險啊，現在想起來真是很害怕，這其中的辛酸只有自己知道啊,幸好我請了2個已經離職的同事來一起幫我完成這件事情（當然是我先墊付工資給他們）。 承包下來后，我首先認真的分析了這兩個項目的具體情況，如果讓客戶快速的驗收，我制定了兩個策略：(1)根據合同發催終驗及回款通知；（2）派人到現場解決客戶使用遇到的難題。我的思路是用催終驗的方式摸清楚客戶的最后需求，以現場解決的方式快速響應，扣住合同的驗收條文驗收。當時合同的終驗都是寫在初驗后3個月完成,這個對自己有利的地方啊。
我當時承包的兩個項目一個在深圳，一個在廣州，而且合同規定的終驗時間剛好是錯開了1個月，因此我首先給深圳的客戶發終驗的催請函，客戶很配合，很快回函說可以進行終驗，但是必須解決他們的問題，并且要我先提交終驗的報告和相關驗收文件，我當時就派了一個請來的同事去深圳現場解決問題，我自己則準備驗收報告和驗收的相關文件，當時碰到了兩個難題：一是去現場的同事技術不過硬，有部分問題要我親自操刀解決，二是有一些文檔不齊全，都是當時趕工忽視了文檔，而且在那么短的時間內最后補文檔，痛苦啊。我記得我當時是白天在現場解決系統問題，晚上趕文檔，經過2個星期的努力，各種準備工作都做好后，客戶說要讓系統穩定運行1個星期后才能驗收，我也同意了，最后那一星期，我吃住在客戶那里，還好系統基本上沒有出現什么問題，最終得到了客戶的認可，客戶最后也在驗收報告上簽字了。
深圳的項目還算是比較順利的，但是廣州這邊的項目就很頭疼了。
廣州這邊的項目開始的時候我也采取跟深圳這邊項目一樣的策略，但是客戶根本不吃這一套，客戶說要終驗，必須要求系統在他們那里完全使用起來才可以，我拿出合同的相關條款，客戶根本不理會，說系統沒有使用起來就不能驗收，我想到過打官司，但是這種官司最后打起來最后肯定是雙輸的。最后我決定變換策略，一切以客戶使用起來為目標。
這套物流系統本來設計理念和思路都是十分先進的，采用.net框架，瘦客戶端技術，界面十分友好，系統經過多次測試后比較穩定，特別是業務流程都是進行了優化，功能都已經實現了合同所規定的要求。但是問題就出在我們優化了客戶的業務流程，但是客戶并不認為這樣是對的，因為當時他們的崗位設置，機構設置并沒有根據優化的業務流程來設置，所以導致開發好的系統根本不能使用，我一邊跟客戶交涉什么時候客戶的業務流程會變過來，一變著手修改現有的系統使得系統能夠滿足現有的業務流程。當時系統有幾個關鍵的業務點只要修改過來就可以符合現在的應用模式，在覺得客戶更改業務流程無望的情況下，我只能更改系統了，于是我帶領了一個請來的同事沒日沒夜的開始了系統的修改工作，一切的目的就是讓客戶使用起來。終于客戶覺得系統真的能夠幫助他們提高工作效率了，客戶慢慢在使用系統。
接下來是1個月的慢長的：修改->使用 循環過程，吃住都是在現場，客戶也被我們的精神所打動，在全公司范圍大面積使用我們開發的系統，甚至動用了行政手段來規范流程，情況越來越好，終于客戶在驗收報告上簽字了。
這次的驗收，使得我明白了即使是有最先進的理念的系統(那怕是先進的ERP)，不符合實際，也是沒有用的，一切以客戶的實際需求為中心，充分滿足客戶的實際需要，能夠真正解決客戶的問題，提高客戶的工作效率的系統才是好系統。
最后兩個項目都驗收了，共經歷了2個多月，錢也拿到了，數目比較可觀（相對來說），于是找了一個投資人和老板，準備運作自己精心準備了1年多的一個綜合物流信息平臺。。。。。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/