本文是在2003年寫的一點心得。不過現(xiàn)在來看還是有啟發(fā)意義的，雖然筆法有些稚嫩實施分為這幾個階段： 

　　1字典準備，系統(tǒng)參數(shù)配置 

　　2客戶化 

　　3使用培訓 

　　4做報表做運行監(jiān)控 

　　5升級更新版本 

　　這幾部分都挺費時間。為什么? 

　　1 、字典準備，系統(tǒng)參數(shù)配置

　　沒有字典準備和系統(tǒng)參數(shù)配置說明。一個新人就被一個人扔到客戶處去獨立完成全過程。整個客戶這么大的投資這么多人這么重要的流程改制都把命運系在了這一個人的身上，不失敗才怪。配的字典和參數(shù)有問題，系統(tǒng)就是出錯誤，甚至有些功能都做不了，最后不得不把整個工程全都推翻，字典重做。 

　　解決方法：有詳細的字典準備和系統(tǒng)參數(shù)配置說明。 

　　FAQ數(shù)據(jù)庫 

　　深刻理解業(yè)務進行實施培訓支持人員考試。 

　　由于涉及到導客戶的老數(shù)據(jù)，由于格式，信息內容都不同，需要個性化做一些導表工具和數(shù)據(jù)初始化工具和數(shù)據(jù)校驗工具 

　　2、客戶化 

　　很多客戶化其實不是客戶有特殊需求，而是以下問題： 

　　A 軟件不實用，閉門造車，軟件商又不愿意大量修改，用戶當然不會用不愿意用互相僵持不給軟件款。 

　　解決方法：業(yè)務專家，模仿競爭對手，模仿本公司的上一代版本，上網(wǎng)找資料，做一家試用客戶 

　　B 由于沒有從咨詢高度教育引導客戶，使客戶隨意變動軟件，引起難以穩(wěn)定。而且沒有統(tǒng)一口徑管理用戶提交上來的BUG和需求列表，每個程序員都可以接了用戶電話，想也沒想通用性和影響性，為了應付現(xiàn)在這個客戶就改了，最后程序越來越不好改。開發(fā)員不負責任，編碼隨意也不測試，項目經(jīng)理管理不嚴，BUG百出，出了一個改一個，不出也不管。 

　　解決方法：需要咨詢專家洗腦，在實施的全過程，工程中的每個人都要給用戶灌輸并且表現(xiàn)這種思想，表現(xiàn)出我們是最正確的我們是最先進的我們是專家你們是落后的。 

　　需要建立BUG提交和支持BBS，與公司的SAWIN連接在一起。根據(jù)BUG和需求來安排人力，進度，計劃，考核程序員，監(jiān)控工作質量。 

　　需要有項目經(jīng)理，嚴格監(jiān)控程序員，不能讓他們對質量不負責任。為了好跟蹤BUG，需要有業(yè)務邏輯BUG的日志跟蹤，能跟蹤到每個界面的每個控件的操作和發(fā)向數(shù)據(jù)庫的SQL。為了好跟蹤BUG，需要有技術BUG的日志跟蹤。 
C 軟件商把各家用戶的需求功能都混合在了一起，一是使代碼BUG百出，二是使BUG不好找，三是使代碼客戶化不好修改，四是使功能復雜用戶不會用，五是使用戶覺得功能自己用不上要求裁減下去反而裁減不下去了。 

　　由于大家各寫一塊，通用的功能卻各寫各的，一個相同的BUG需要修改各自的程序，沒修改到的地方就有問題。 

　　解決方法：界面數(shù)據(jù)業(yè)務分離，一個修改，先有項目經(jīng)理總控是該單獨寫代碼還是交給公共基類來做。有人統(tǒng)籌開發(fā)通用基類。個性化的功能單獨做出來不要在原有代碼單元進行修改，把共用的放在共用單元，個性的各放各處。 

　　D 由于數(shù)據(jù)庫設計沒有分為摘要表，細目表，月匯總表，年匯總表，冷數(shù)據(jù)表，熱數(shù)據(jù)表，沒有用VIEW，SP，JOB，字段類型不考慮用簡單類型，引起性能問題。采用大量新技術，新技術有BUG，問題難以解決。 

　　解決方法：盡量不采用新技術新開發(fā)方法。數(shù)據(jù)庫設計應該重點之重點。盡量把在數(shù)據(jù)庫上做文章能寫VIEW，SP，JOB完成的就不寫代碼。這樣性能高，功能也好修改。直到數(shù)據(jù)庫的功能優(yōu)勢都發(fā)揮出來了再在中間層寫東西，把通用的功能，如安全，如存儲，如數(shù)據(jù)校驗，如流程走向，如復雜數(shù)據(jù)計算判斷都寫在中間層。把中間層的優(yōu)勢都發(fā)揮完了，再寫客戶端的界面控制，報表，字典維護界面。 

　　E 有些功能比較復雜，應該分成兩步或多步來做的，都做在了一起，引起功能異常復雜，不僅不會用，而且BUG多難穩(wěn)定更不會用。 

　　解決方法：盡量隱藏功能，使每個界面都不復雜。 

　　F 真正的客戶化的內容 

　　大量做報表，這樣看，那樣看，條件也不同。所以需要一個好的報表設計器，好的報表條件設計器。南方的用戶要求盡量程序簡單，自動化運行，所以我們拼命在裁減功能。北方的用戶要求盡量程序處處控制，所以我們拼命在加功能，引起了矛盾。 

　　解決方法：報表設計器，報表條件設計器 

　　需要消息提醒服務使業(yè)務自動化。安全需要限制到一個界面上的一個字段。各家用戶對界面上能看見什么字段，每個字段有什么限制，某個下拉字段能下拉出什么記錄，如果錄入有問題提醒話都有不同需要定制。 

　　3、培訓 

　　有了上述的基礎。還需要有正規(guī)的使用培訓手冊，正規(guī)的培訓計劃，對用戶數(shù)，用戶素質，時間長短與時間安排，計算機室人員配合，次數(shù)，場地設備，PPT，DOC都有要求。 

　　4、做報表做運行監(jiān)控 

　　由于有了良好的報表設計器和監(jiān)控日志，工作輕松了許多。 

　　5、升級更新版本 

　　每次的界面修改，數(shù)據(jù)庫配置表結構VIEW，SP，JOB的修改，中間層的修改，INI的修改，都要記錄下來日志，并且做成數(shù)據(jù)庫SCRIPT腳本，按時間先后一并更新 

　　總結 

　　我們正確的做法是： 

　　1 業(yè)務功能設計方面 
a 業(yè)務專家，模仿競爭對手，模仿本公司的上一代版本，上網(wǎng)找資料，做一家試用客戶 

　　b 盡量隱藏功能，使每個界面都不復雜。 

　　2 架構方面 

　　a 盡量不采用新技術新開發(fā)方法。 

　　b 數(shù)據(jù)庫設計應該重點之重點。盡量把在數(shù)據(jù)庫上做文章能寫VIEW，SP，JOB完成的就不寫代碼。這樣性能高，功能也好修改。 

　　c 直到數(shù)據(jù)庫的功能優(yōu)勢都發(fā)揮出來了再在中間層寫東西，把通用的功能，如安全，如存儲，如數(shù)據(jù)校驗，如流程走向，如復雜數(shù)據(jù)計算判斷都寫在中間層。 

　　d 把中間層的優(yōu)勢都發(fā)揮完了，再寫客戶端的界面控制，報表，字典維護界面。 

　　e 報表設計器，報表條件設計器。 

　　f 需要消息提醒服務使業(yè)務自動化。 

　　g 安全需要限制到一個界面上的一個字段。各家用戶對界面上能看見什么字段，每個字段有什么限制，某個下拉字段能下拉出什么記錄，如果錄入有問題提醒話都有不同需要定制。 

　　3 代碼編寫方面 

　　a 界面數(shù)據(jù)業(yè)務分離。 

　　b 為了好跟蹤BUG，需要有業(yè)務邏輯BUG的日志跟蹤，能跟蹤到每個界面的每個控件的操作和發(fā)向數(shù)據(jù)庫的SQL。 

　　c 為了好跟蹤BUG，需要有技術BUG的日志跟蹤。 

　　4 客戶化方面 

　　a 需要建立BUG提交和支持BBS，與公司的SAWIN連接在一起。根據(jù)BUG和需求來安排人力，進度，計劃，考核程序員，監(jiān)控工作質量。 

　　b 需要有項目經(jīng)理，嚴格監(jiān)控程序員，不能讓他們對質量不負責任。 

　　c 一個修改，先有項目經(jīng)理總控是該單獨寫代碼還是交給公共基類來做。有人統(tǒng)籌開發(fā)通用基類。 

　　d 個性化的功能單獨做出來不要在原有代碼單元進行修改，把共用的放在共用單元，個性的各放各處。 

　　e 每次的界面修改，數(shù)據(jù)庫配置表結構VIEW，SP，JOB的修改，中間層的修改，INI的修改，都要記錄下來日志，并且做成數(shù)據(jù)庫SCRIPT腳本，按時間先后一并更新。 

　　5 實施培訓支持方面 

　　a 需要咨詢專家洗腦，工程中的每個人都要給用戶洗腦。 
　b 有詳細的字典準備和系統(tǒng)參數(shù)配置說明。 

　　c 深刻理解業(yè)務進行實施培訓支持人員考試。 

　　d FAQ數(shù)據(jù)庫。 

　　e 需要有正規(guī)的使用培訓手冊，正規(guī)的培訓計劃，對用戶數(shù)，用戶素質，時間長短與時間安排，計算機室人員配合，次數(shù)，場地設備，PPT，DOC都有要求。 

　　炒概念，雇傭槍手互相吐口水，上法庭，做平臺，打技術牌，搞高層論壇都沒有戲。大話，歲數(shù)大就冒充專家，不可操作性的大方向指導，媒體記者為了吃飯亂發(fā)表趨勢報告和什么真知灼見，都解決不了問題。 

　　關鍵在于有可操作性的東西，執(zhí)行下去，這才是管理的真髓，也是競爭的最厲害的一招。 

　　別相信什么管理大師和管理經(jīng)典書籍，對于管理你的企業(yè)一點用也沒有，也千萬別按照那些象牙塔中的東西到現(xiàn)實中演練，小心傷了別人，也小心傷了自己。