Java代碼

1. TransactionDefinition   
2. public interface TransactionDefinition {   
3.     int getPropagationBehavior();   
4.     int getIsolationLevel();   
5.     int getTimeout();   
6.     boolean isReadOnly();   
7. }  

TransactionDefinition
public interface TransactionDefinition {
int getPropagationBehavior();
int getIsolationLevel();
int getTimeout();
boolean isReadOnly();
}

Java代碼

1. Connection con1 = getConnection();   
2. con.setAutoCommit(false);   
3. update employee set salary = 8000 where empId ="Mary";  

  Connection con1 = getConnection();
con.setAutoCommit(false);
update employee set salary = 8000 where empId ="Mary";

Java代碼

1. Connection con2 = getConnection();   
2. select  salary from employee where empId ="Mary";   
3. con2.commit();  

Connection con2 = getConnection();
select  salary from employee where empId ="Mary";
con2.commit();

Java代碼

1. //con1   
2.   con1.rollback();  

//con1
con1.rollback();

Java代碼

1. con1 = getConnection();   
2. select salary from employee empId ="Mary";  

con1 = getConnection();
select salary from employee empId ="Mary";

Java代碼

1. con2 = getConnection();   
2. update employee set salary = 2000;   
3. con2.commit();  

con2 = getConnection();
update employee set salary = 2000;
con2.commit();

Java代碼

1. //con1   
2. select salary from employee empId ="Mary";  

//con1
select salary from employee empId ="Mary";

Java代碼

1. con1 = getConnection();   
2. Select * from employee where salary =1000;  

con1 = getConnection();
Select * from employee where salary =1000;

Java代碼

1. con2 = getConnection();   
2. Insert into employee(empId,salary) values("Lili",1000);   
3. con2.commit();  

con2 = getConnection();
Insert into employee(empId,salary) values("Lili",1000);
con2.commit();

Java代碼

1. //con1   
2. select * from employee where salary =1000;  

//con1
select * from employee where salary =1000;

Java代碼

1. //事務屬性 PROPAGATION_REQUIRED   
2. methodA{   
3. ……   
4. methodB();   
5. ……   
6. }   
7.   
8. //事務屬性 PROPAGATION_REQUIRED   
9. methodB{   
10.    ……   
11. }  

//事務屬性 PROPAGATION_REQUIRED
methodA{
……
methodB();
……
}
//事務屬性 PROPAGATION_REQUIRED
methodB{
……
}

Java代碼

1. main{   
2.   metodB();   
3. }  

main{
metodB();
}

Java代碼

1. Main{   
2. Connection con=null;   
3.   
4.    rry{   
5.       con = getConnection();   
6.       con.setAutoCommit(false);   
7. //方法調用   
8. methodB();   
9. //提交事務   
10. con.commit();   
11. }   
12. Catch(RuntimeException ex){   
13.   //回滾事務   
14.   con.rollback();     
15. }   
16. finally{   
17.   //釋放資源   
18.   closeCon();   
19. }   
20. }  

Main{
Connection con=null;
rry{
con = getConnection();
con.setAutoCommit(false);
//方法調用
methodB();
//提交事務
con.commit();
}
Catch(RuntimeException ex){
//回滾事務
con.rollback();
}
finally{
//釋放資源
closeCon();
}
}

Java代碼

1. main{   
2.    Connection con = null;   
3.    try{   
4.       con = getConnection();   
5.       methodA();   
6.       con.commit();   
7. }   
8. cathc(RuntimeException ex){   
9.  con.rollback();   
10. }   
11. finally{   
12.   closeCon();   
13. }    
14. }  

main{
Connection con = null;
try{
con = getConnection();
methodA();
con.commit();
}
cathc(RuntimeException ex){
con.rollback();
}
finally{
closeCon();
}
}

Java代碼

1. //事務屬性 PROPAGATION_REQUIRED    
2. methodA(){   
3.   methodB();   
4. }   
5.   
6. //事務屬性 PROPAGATION_SUPPORTS    
7. methodB(){   
8.   ……   
9. }  

//事務屬性 PROPAGATION_REQUIRED
methodA(){
methodB();
}
//事務屬性 PROPAGATION_SUPPORTS
methodB(){
……
}

Java代碼

1. //事務屬性 PROPAGATION_REQUIRED    
2. methodA(){   
3.   methodB();   
4. }   
5.   
6. //事務屬性 PROPAGATION_MANDATORY    
7. methodB(){   
8.   ……   
9. }  

//事務屬性 PROPAGATION_REQUIRED
methodA(){
methodB();
}
//事務屬性 PROPAGATION_MANDATORY
methodB(){
……
}

Java代碼

1. //事務屬性 PROPAGATION_REQUIRED    
2. methodA(){   
3.   doSomeThingA();   
4. methodB();   
5. doSomeThingB();   
6. }   
7.   
8. //事務屬性 PROPAGATION_REQUIRES_NEW    
9. methodB(){   
10.   ……   
11. }  

//事務屬性 PROPAGATION_REQUIRED
methodA(){
doSomeThingA();
methodB();
doSomeThingB();
}
//事務屬性 PROPAGATION_REQUIRES_NEW
methodB(){
……
}

Java代碼

1. main(){   
2.   methodA();   
3. }  

main(){
methodA();
}

Java代碼

1. main(){   
2.  TransactionManager tm = null;   
3. try{   
4.   //獲得一個JTA事務管理器   
5.    tm = getTransactionManager();   
6.    tm.begin();//開啟一個新的事務   
7.    Transaction ts1 = tm.getTransaction();   
8.    doSomeThing();   
9.    tm.suspend();//掛起當前事務   
10.    try{   
11.      tm.begin();//重新開啟第二個事務   
12.      Transaction ts2 = tm.getTransaction();   
13.      methodB();   
14.      ts2.commit();//提交第二個事務   
15.         
16.    }   
17.   Catch(RunTimeException ex){   
18.      ts2.rollback();//回滾第二個事務   
19.   }   
20.   finally{   
21.     //釋放資源   
22.   }   
23.    //methodB執行完后，復恢第一個事務   
24.    tm.resume(ts1);   
25. doSomeThingB();   
26.    ts1.commit();//提交第一個事務   
27. }   
28. catch(RunTimeException ex){   
29.   ts1.rollback();//回滾第一個事務   
30. }   
31. finally{   
32.   //釋放資源   
33. }   
34. }  

main(){
TransactionManager tm = null;
try{
//獲得一個JTA事務管理器
tm = getTransactionManager();
tm.begin();//開啟一個新的事務
Transaction ts1 = tm.getTransaction();
doSomeThing();
tm.suspend();//掛起當前事務
try{
tm.begin();//重新開啟第二個事務
Transaction ts2 = tm.getTransaction();
methodB();
ts2.commit();//提交第二個事務
}
Catch(RunTimeException ex){
ts2.rollback();//回滾第二個事務
}
finally{
//釋放資源
}
//methodB執行完后，復恢第一個事務
tm.resume(ts1);
doSomeThingB();
ts1.commit();//提交第一個事務
}
catch(RunTimeException ex){
ts1.rollback();//回滾第一個事務
}
finally{
//釋放資源
}
}

Java代碼

1. //事務屬性 PROPAGATION_REQUIRED    
2. methodA(){   
3.   doSomeThingA();   
4. methodB();   
5. doSomeThingB();   
6. }   
7.   
8. //事務屬性 PROPAGATION_NOT_SUPPORTED    
9. methodB(){   
10.   ……   
11. }  

//事務屬性 PROPAGATION_REQUIRED
methodA(){
doSomeThingA();
methodB();
doSomeThingB();
}
//事務屬性 PROPAGATION_NOT_SUPPORTED
methodB(){
……
}

Java代碼

1. main(){   
2.  TransactionManager tm = null;   
3. try{   
4.   //獲得一個JTA事務管理器   
5.    tm = getTransactionManager();   
6.    tm.begin();//開啟一個新的事務   
7.    Transaction ts1 = tm.getTransaction();   
8.    doSomeThing();   
9.    tm.suspend();//掛起當前事務   
10.      methodB();   
11.    //methodB執行完后，復恢第一個事務   
12.    tm.resume(ts1);   
13. doSomeThingB();   
14.    ts1.commit();//提交第一個事務   
15. }   
16. catch(RunTimeException ex){   
17.   ts1.rollback();//回滾第一個事務   
18. }   
19. finally{   
20.   //釋放資源   
21. }   
22. }  

main(){
TransactionManager tm = null;
try{
//獲得一個JTA事務管理器
tm = getTransactionManager();
tm.begin();//開啟一個新的事務
Transaction ts1 = tm.getTransaction();
doSomeThing();
tm.suspend();//掛起當前事務
methodB();
//methodB執行完后，復恢第一個事務
tm.resume(ts1);
doSomeThingB();
ts1.commit();//提交第一個事務
}
catch(RunTimeException ex){
ts1.rollback();//回滾第一個事務
}
finally{
//釋放資源
}
}

Java代碼

1. //事務屬性 PROPAGATION_REQUIRED    
2. methodA(){   
3.   doSomeThingA();   
4. methodB();   
5. doSomeThingB();   
6. }   
7.   
8. //事務屬性 PROPAGATION_NEVER    
9. methodB(){   
10.   ……   
11. }  

//事務屬性 PROPAGATION_REQUIRED
methodA(){
doSomeThingA();
methodB();
doSomeThingB();
}
//事務屬性 PROPAGATION_NEVER
methodB(){
……
}

Java代碼

1. //事務屬性 PROPAGATION_REQUIRED    
2. methodA(){   
3.   doSomeThingA();   
4. methodB();   
5. doSomeThingB();   
6. }   
7.   
8. //事務屬性 PROPAGATION_NESTED   
9. methodB(){   
10.   ……   
11. }  

//事務屬性 PROPAGATION_REQUIRED
methodA(){
doSomeThingA();
methodB();
doSomeThingB();
}
//事務屬性 PROPAGATION_NESTED
methodB(){
……
}

Java代碼

1. main(){   
2. Connection con = null;   
3. Savepoint savepoint = null;   
4. try{   
5.   con = getConnection();   
6.   con.setAutoCommit(false);   
7.   doSomeThingA();   
8.   savepoint = con2.setSavepoint();   
9.   try  
10.       methodB();   
11.   }catch(RuntimeException ex){   
12.      con.rollback(savepoint);   
13.   }   
14.   finally{   
15.     //釋放資源   
16.   }   
17.   
18.   doSomeThingB();   
19.   con.commit();   
20. }   
21. catch(RuntimeException ex){   
22.   con.rollback();   
23. }   
24. finally{   
25.   //釋放資源   
26. }   
27. }  

main(){
Connection con = null;
Savepoint savepoint = null;
try{
con = getConnection();
con.setAutoCommit(false);
doSomeThingA();
savepoint = con2.setSavepoint();
try
methodB();
}catch(RuntimeException ex){
con.rollback(savepoint);
}
finally{
//釋放資源
}
doSomeThingB();
con.commit();
}
catch(RuntimeException ex){
con.rollback();
}
finally{
//釋放資源
}
}

當我對著遠程的大屏，給北京的IBM中國研究院幾位面試官匯報完30分鐘技術報告之后，心里忐忑不安，這已經是終面了一關關拼得不容易，但卻很精彩!

在之后的幾天，很高興接到了來自IBM兩位高級經理的電話，分別給我介紹了他們部門情況和項目情況，表示我的報告印象深刻，能力很突出真的是非常感謝他們能給我這個機會！

訣竅

我不是聰明過人的人，但是我相信自己的研究能力，這來源于一個訣竅我悟出一條定律，那就是：能力是一種態度！

簡單解釋如下：這世界上不缺乏聰明人，但是缺乏懂得運用自己聰明才智的人。

今天的帖子，我希望通過7個真實的故事，去詮釋這條定律能力是一種態度！

1. 我通過qq在課題組做了一次試驗，將同一個問題群發給了6個成員，有3個人回復我：這個我沒遇到過，不會做啊；有2個去Google了下，大概告訴了解了 應該怎么弄；有一個人，做程序試驗了不同方法的優劣，告訴我最好的方法是什么。多年以后，對很多問題都報以沒遇到過，不會啊的人，和能力在積累的人，雖然 一樣聰明，但是差距就很大了。

2. 行人仿真系統研發的初期，我突然發現A*算法和Social Force Model特別有意思，就鉆了進去，花了一些時間把它們研究透徹當我興致勃勃給老板介紹完各種模型算法之后，老板說：你去給領導介紹這些模型算法是沒用 的，他們要的是效果，模型是無止境的。當時我也很沮喪，但是后來事實證明，我的不務正業是對的！因為智能化的動態尋路能力成為了我們系統的核心創新點，也 是每次項目介紹中最得意的內容。

3. 給北京做的城市軌道交通運營輔助決策系統是要在08奧運前上線的，時間很緊，臨近系統調試的時候，北京測試人員突然打電話說發現某些車站之間候選路徑似乎 少了一條當時大家都認為可能就是邊界條件問題，稍微改改就好了。我研究了下這個K短路算法(其他人負責開發的)發現竟是理論上的缺陷

一時半會兒又沒辦法給領導解釋清楚，我就決定重寫這個部分，用數據來說明。由于時間太緊，在北京回上海的火車上看這些很多文獻，憑借著良好的A*算法基礎，很快設計出新的算法。通過測試發現，老算法共丟了500多條路徑！（總共十幾萬條左右），這時候大家總算舒了一口氣了

但我并沒有罷休，因為匆忙，算法速度不快。繼續花了幾天，將北京軌道網絡中2萬多OD之間清分計算時間優化到10多分鐘，最后優化到1分鐘（在我筆記本上）。上線調試當天，領導贊嘆道：這算法可真是又快又準啊！

4. 還是上面這個系統的故事：當時北京路網基礎數據是一個碩士負責錄入的，他畢業以后，上海路網數據沒人弄了，老板叫我去做。雖然只是半天時間的體力活，但是心里很不是滋味

雖然有人勸說：花個半天搞定算了哦！但是我決心不用笨辦法我花了一個星期，憑借曾經開發的二維矢量圖形庫，設計出一個智能化的基礎數據管理子系統， 只需要在圖上簡單點擊，然后拷入excel中的車站名稱和代碼，系統自動識別，然后再自動生成區間、換乘關系等等6張數據庫表需要的全部數據。后來課題組 利用這個工具構建了很多路網，因為非常簡單，這個子系統也成為了后來863中網絡客流仿真系統的基礎。

5. 上物流系統課老師提到一個著名的NP問題Vehicle Routing Problem，要求大家回去寫寫系統設計書。我當時就決定要開發這個系統，后來的幾個星期，我發現遺傳算法和自然界的規律真的是如此的吻合，達到了如癡 如醉的地步，被女朋友嘲笑為：整天關在屋里下崽后來結果是，我設計的遺傳算法，不但能夠求解最少需要多車，還能找到總里程很短的方案。

6. 在斯坦福訪學主要是參與一個疏散仿真系統的研究。但是，由于有遺傳算法的背景，另外一個教授介紹我參加他們的一個課題辦公大樓改造優化方案的輔助決策系統。

剛開始我認為這是一個確定性問題，因此采用A*算法得到了比較好的效果，已經可以滿足項目需求了。我想為了作對比，又設計了遺傳算法，居然發現在少 數情況下能變異到更好解。大量實驗后，我發現了兩種算法雖然原理差別很大，數據結構上卻存在內在聯系，能夠組合成一種具備通用性的框架，解決大量離散優化 問題。

完全出于對科學問題本身的癡迷，我并沒有罷手自行設計了一種數據結構替換哈希表，將兩個算法性能同時提升10倍之多（在遺傳算法中提出了花名冊的概 念），后來又發明一種交叉算法，再次將遺傳算法提升十幾倍。當時測試案例的人說已經完全跟不上了（已經讓他反復做了好多次了），因此最后我們paper里 面的數據不是我最快的算法得到的。

7. 利用上面的離散優化問題搜索框架，我發現還可以解決《編程之美》中的許多問題。在大家都忙于找工作面試的時候，我卻整整花了一個月關在寢室里研究《編程之 美》，有時候挑戰一個題目整整花去1天時間，當時我身邊的人都說我不務正業，我自己都有點懷疑了。可是事實證明，這份研究不但證明了興趣，還證明了我的算 法能力，對后來找工作很有幫助。

結論

通過上面的故事，我想已經可以證明我這個定律了能力是一種態度。如果要問態度是什么，那么我想是一種單純的，沒有任何功利的科學態度，對問題本身的執著。

1. 上下文 -- 和問題相關的場景，指一組已經是明確已知的，關于問題的條件的描述。

2. 目標 -- 指關于構成問題的結論的明確的描述。

3. 障礙 -- 指問題的正確解決方法不是顯而易見的，必須通過一定的思維活動，才能找到答案。

良好的定義問題是解決問題的關鍵步驟。

定義問題就是鑒別期望和現狀的差異。有如下幾個關鍵點：

1. 首要的是，收集整理關于現狀的可信的信息，而不要假設已經擁有完備的可信信息；

2. 不暗示傾向于某種原因或者解決方法；

3. 只陳述現狀和期望的狀態；

4. 在解決問題的過程中，問題的定義可能（有必要）會不斷的改進或者轉換形式。

源文檔 <http://zh.wikipedia.org/w/index.php?title=%E9%97%AE%E9%A2%98&variant=zh-cn>

心態

    靜心：在定位問題之前，最好先安靜下來，摒除雜念。放下自己的身份（項目經理、開發人員），以解決當前系統的問題為中心。靜心之后，將問題現象在腦中過一遍，弄清問題。

問題解決者不輕信，不盲從
    絕不因為一句“應該是對的”“大概沒有變化”而拋棄一個懷疑的點。
 

大局觀：不要盡早的陷入細節
    實際上，在整個問題定位和解決的過程中，都應該盡量在頭腦中對整個系統的映像以及當前位置保持清晰的認知。這樣有助于前后、上下聯系，在更高更廣闊的空間中發現問題。在解決問題的時候提醒自己：我現在處于一個什么位置？如果不啟動調試環境我能不能解決掉這個問題？

預判斷，然后驗證：盡量將日志、調試、HttpFox等都用作驗證問題的工具——首先對問題的原因做預判斷（猜測），然后確定該原因會導致什么現象，然后驗證該現象（日志等）。預判斷比驗證更應被關注。

當很難預判斷問題位置時，可以采用排除法：每次排除系統范圍的一半左右，逐步將包圍圈縮小到問題原因本身。應注意：排除的過程中，同樣要注意驗證排除的是否正確，即：排除、驗證、排除、驗證……

關注日志
     很多問題解決過程中其實打開日志文件就能馬上得到結論，但是開發人員寧可自己猜也不愿意動手打開日志。
另外也暴露了我們系統日志沒有為開發人員提供足夠的信息支持用以解決問題，后面的設計中要把異常設計作為一個重要部分。

充分利用工具，能得到事實就不猜測

比如：HttpFox等工具能將HTTP請求錄下來，我們不需要猜測；還有Windows事件日志，性能計數器，Windbg等等工具可用

通過差異找到問題的原因

很多問題的解決可以不依賴開發態的調試，比如通過比較當前版本和上一版本的區別，比較產品和產品之間的差別就能通過差異來定位問題。

解決掉一個問題不是終結
之前往往滿足于一個能夠解決眼前問題的答案；這是遠遠不夠的，一個問題的出現暴露出我們系統的缺陷，這是一個線索，需要避免同樣的問題的出現

一個問題的出現我們要追究到問題的本質，例如前段時間SSO登陸失敗和驗證碼本地使用失敗，本質上都是由于配置文件中指定了Cookie的域。

2、三五個人十來條槍 如何成為開發正規軍（二）

上一次，寫了一篇文章《三五個人十來條槍 如何走出軟件作坊成為開發正規軍》，反響異常激烈。

　　我的一個朋友也看到了我的博文，他是做某個行業企業管理軟件的。他說：你這個方法，在我從事的行業不適用。

　　我對他從事的那個信息化的行業還是有一定了解的。

　　他們的實施模式是：

　　一個實施項目，大約50萬的簽單額，做完驗收后給最后的20%-30%的尾款。

　　他們是一家小公司，為了多做項目多賺錢（企業都希望利潤保持的很高，如果毛利低，做軟件就不合適了，受的苦和壓力和不規律性比其他行業多的多），所以一個項目只派一個人去，而這個人需要培訓、輔助導入舊系統數據、清洗合并數據、規范化數據、報表制作、需求協調、推動切換上線、現場運行監控、個性化定制修改代碼。

　　如果不能推動客戶上線，就無法驗收結項。不結項，就無法去追尾款。

　　一個項目這個人，身兼項目經理、開發員、需求調研、軟件設計、功能測試、實施培訓、定制化開發，還有時候寫培訓文檔。因為公司里都是這樣的人，根本沒有分工出專門的文檔人員，所以產品根本沒有培訓手冊和幫助手冊。除非客戶必須要，這個項目的這個人才寫一份草稿應付。而公司又沒有人來做文檔管理工作，所以各個項目各個人寫，也沒有人合并，也沒有人來統一收集。每個文檔都在項目每個人的移動硬盤里。

　　由于項目就老哥一個人全活兒，所以自己答應了客戶修改什么需求就自己修改，根本沒有啥需求調研方法和版本管理方法，就看這個老哥和客戶之間的博弈了。每個項目一套源代碼，而且都在各個項目的各個人手里。返回公司后，往公司的服務器上一扔做個備份。以后誰的項目出了問題或需求，就誰負責繼續修改。但是，很有可能這個人已經在做其他項目了，還需要修改前幾個項目的需求或BUG，還需要接聽前幾個項目的支持電話。如果這個老哥是在頂不住壓力和焦慮而跑路了，只能把這些所有的活交給現存活的人的手里，啥也沒有。無法交接也得交接，反正人要跳槽。

　　由于每個人都是這樣一人擋一攤或數攤項目，而且項目周期長，每個項目都需要2-3個月的時間。老板也想把公司做大，但是每個項目能去實施的人，要求都非常的高，新人來了一年也上不了前線干不了活。所以，對招新人也是不愿意招，干花錢沒見起作用，小公司培養不起人。而對項目游刃有余的人，都是跑單幫跑慣了，帶著個新人，還干不了活，還浪費出差費用，真是氣死人了，還不如自己親自動手三下五除二搞定爽。

　　于是，公司五六年了也就那么大規模，老板員工都干的很辛苦，當然老板得到的錢要多一些，賺個500多萬沒啥問題，自己后半輩子算是有靠了。所以，老板也得過且過，反正現在賺錢速度已經比較滿足了，這樣也熟練習慣了，經驗路徑依賴，就這樣順坡下驢做吧。

　　我的朋友是個理想和現實總是不斷沖突的人。一方面，他確實想把項目做的很是順暢，另一方面，他卻覺得一切都像是被各種因素牽扯，根本無法轉變模式，于是只能認命繼續現在。

　　我說，你這種情況其實在中國很普遍。中國大部分軟件公司都是從事行業信息化，因為這塊技術難度最低，而且只要有人脈關系就可以做銷售開干。而很多軟件公司的成立，就是由于老板有一個關系，接到了某個項目，于是拉住了某個客戶，小活不斷，于是成立了公司。這是很多老板成立公司的原因。既然這類公司成立就沒有目標，其目的就是認識幾個人多拉一些項目多賺一些錢，所以如何復制模式，他們其實關注性也不大。原因很明白，就是自己不認識的客戶，要想打入這個單子，很難，每個客戶廟前都有N多關系戶。對于自己有關系的客戶，也就那么多個，有多大關系就能做多大的攤子，那就盡量從現有客戶中持續做項目。維護好客戶關系是最重要的。這類模式非常常見，并不是你這個行業特殊。

　　老板的生活已經趨向于小康穩定，而你呢？你還在掙工資。你也在一線客戶那里天天呆著，要么你把老板的客戶搶過來你做，要么為了你自己工作能輕快些，你必須自己給自己找方法。

　　我的朋友說，搶過來不可能。自己雖然天天在第一線和客戶天天在一起，關系也處的不錯。但現在人先認的是錢，后認的是感情。而老板給他們這幫人都持續吃喝玩樂送東西分回扣，自己只是一個干苦力的。自己只能找方法。但你說的方法是針對一個公司的變革，不是針對我個人而言的，所以不適用。我想有一個方法能幫助我自己的方法，你幫我想想。

　　我想了想我過去寫過的文章，確實是，自己一直從事職業經理人操盤產品研發管理，也統管咨詢、實施、培訓、支持，但都是在公司管理的層面上看問題分析問題解決問題，而沒有從一個個體上去思考。而中國，大量像我這樣的朋友，他們需要幫助，而我寫的卻是公司層面的，無法幫助他們，所以他們老說我的文章空洞、理想。

　　我說，咱們倆一起分析解決。也是給大量像我朋友這樣辛苦的人帶個福音。

　　咱們首先先說一下你想達到什么效果。

　　我朋友說：我現在在這里待的很煩，出差時間太長了，我就想早點回家。

　　那你什么地方費時間了，需要2-3個月在客戶現場？

　　我朋友說： 嗯，我看完你的那篇文章，我也做了一下反思和總結。我感覺有三個方面特別費時間：客戶需求，數據準備，報表制作。

　　一去客戶那里，你是見不到客戶老板的，也是看不到用戶的，你主要面對的是客戶信息科的人。他們一開始要求你先做演示，看看是否符合他們本企業使用。在這個演示過程中，就不斷提出需求讓你修改。而且，你不修改完，他們沒法接受你以下的演示，說想象不出后來的樣子，對著你畫的界面圖想象以后的功能變化，有點紙上談兵的感覺。而且，往往演示的時候必須信息科科長在，否則底下的科員都做不了主，演示了也是白演示。而信息科科長卻老不在。而他們上班時間也極為規律，該下班時立馬下班，根本不加班。所以邊演示變修改再邊演示。好容易修改完了，也演示完了，時間一倆個星期就過去了。

　　信息科算是通過了，就需要錄入基礎數據了。問題又來了。現在大部門企業都已經上過一套軟件了，可能是Foxpro的，也可能是PB的。人家要求你把數據倒進新系統中，但是一看過去的數據，都亂七八糟的，過去上線都是沒經驗，后來也用的亂了，積腋成疾了。現在要導入，真是要把垃圾輸入，得出來的也是垃圾。你苦口婆心的說服讓他們重新錄入，但是他們一看都好幾千條，不想錄入，讓你能導多少導多少，然后在基礎上再維護。這一松口不要緊，你不僅忙活了一個多星期寫各種SQL導數據，而且往往舊系統也沒有文檔，數據結構需要你自己理解，理解有誤也是你的事。好容易導完了，再維護，發現數據是通過SQL導入的，在界面上卻不能維護，因為很多校驗都是寫死在程序里的，而不是約束在數據庫。磕磕碰碰，自己邊后臺修改數據，邊讓他們信息科維護。他們信息科首先先檢驗導進去的數據對不對，沒有填寫齊的字段填寫齊。然后把沒有導進去的數據錄入進去。然后再打印出來，統一對一遍，看看哪些數據錄入的有錯誤。這樣折騰，一個月，22天工作日就過去了，用戶還沒培訓呢。

　　第二個月開始用戶培訓了，但一培訓就發現了問題。用戶的需求和信息科所的需求，根本不是一碼事。原來一個企業，信息科也和業務科室是兩張皮，就和在軟件公司一樣，開發部和銷售部是兩張皮。于是，用戶和信息科開始吵架，各說各的道理，誰都在維護自己的利益。而且用戶部門有業務在身，也不可能天天大部分時間泡在IT討論上面，開會不來人，或者要來人也來了個小兵充數，根本起不了決定，還提自己的意見，過幾天開會，用戶部門的主任來開會，又把需求再推翻。業務部門主任是站在主任的層次上看IT管理， 而業務部門科員是站在自己輕松使用的角度上提需求，而信息科是為了自己以后維護著想。不斷的討論不斷的推翻不斷的扯皮。

　　討論扯皮推翻再討論再修改。終于消停了。開始培訓了。但問題來了，用戶上機一操作，發現基礎數據很多不是平常現實那樣的。計算機數據過去就和現實數據脫離了，現在想借新系統上線再回到計算機管理上。于是，一邊培訓一邊修改數據，有人報告數據錯誤就修改。而培訓沒有文檔，培訓也沒有課程，培訓也沒有專業訓練。培訓如何層層開展，培訓如何組織，都不知道。反正就老哥一個被訂在這里了，只能這么上手了。人沒有來齊，也得開始。等來了再重新講一次。一次不會，再講一次。有人年齡大打字不熟練，有人看不清屏幕，需要調整大字。一調整，界面發生錯位了。有人不會用鼠標雙擊和單擊，有人不會控制打印機。過去是UCDOS系統，還沒用過WINDOWS的，用不慣。從基礎培訓起吧。否則怎么辦呢？人家不上線用起來，人家不給驗收結項啊，尾款回不來啊。

　　用戶也培訓完了，該上線了，就需要初始化庫存了。先得現實盤點，然后再錄入計算機，還必須一邊得繼續營業。于是，真實庫存和計算機庫存肯定對不上去。由于品種太多，所以只能一批批盤點一批批錄入。

　　由于操作不熟練，特殊業務不知道如何處理，只能瞎處理。處理完后發現不對，想沖抵回去。沒有沖抵功能，只能修改數據庫中的數據。

　　由于前期修改，根本沒有測試，就是老哥自己一個人改。改完了有時候煩了連自己都不想測試。于是上線用著用著就不能運行了，需要當時就立即修改，中午晚上的連續作戰緊急解決，否則第二天一早還需要開門迎客。

　　好容易業務錄入了，但是報表不對。一檢查，原來是前段時間錄入的非法業務數據造成，功能沒想到沒攔住。怎么辦？偷偷自己修改數據，然后使報表平賬。過段時間，發現報表又不平了，發現還是非法數據進入造成。怎么進來的呢？想不明白。只好蹲點現場，直到客戶都運行正常了才能走人，算是上線成功。

　　這個累呀，兩三個月都是緊著過的。好不容易回來休息會，另一個項目就要啟動了，就這么幾頭能干活的蒜，老板笑著臉讓你去。于是，遭遇再次上演，日子就是這么過來了，一月又一月，一年又一年。頂不住的就跑路。

　　我聽完了我的朋友的訴苦。我說咱們一件件事情的排查。

　　第一件事，邊演示邊修改，還得信息科長在，還得他拍板。這段時間的浪費如入縮短。我過去也作過燈塔客戶的實施，我過去一去了客戶那里，并沒有一開始就這么做。我先是調研此次項目組的人員構成、能力、職責、上線時間、用戶計算機能力、用戶部門對上一套系統的最突出的抱怨，信息科對上一套系統的最突出的抱怨，現在還有哪些系統在持續運行，上一套系統用戶部門和信息科覺得哪里好，上一套系統的功能結構和操作流程。這樣，我就確定了我該如何開展項目實施。這就是項目調研階段。人往往很眷戀自己已經習慣的事情。而且人的想法，人的能力，各個部門的利益沖突，人和人的私人關系和恩怨，都有助于項目的推進。亞洲人做事，需要面上的和面下的都得下功夫。純粹都是正式的或者都是不正規的，都無法做好一個項目。我會在項目調研后，重新建議項目組人員構成、職責、流程、項目階段時間、各方面負責人、本項目的最突出要解決的前5個目標問題。

　　人常說，上下同欲者勝，廟算者勝。你一開始必須界定好項目的邊界和目標和執行標準和責任人，否則大家誰都想管或者誰都不管，大家沒有目標，或者大家各有各的目標，肯定無法項目很好的推進。

　　有了目標，責任人、標準、時間計劃，就要按照這個目標來分解做。基礎數據的校驗，需要用戶參與先來校驗原有系統的數據。不要認為用戶現有這套系統就沒有問題。如果沒有問題，企業也不會用你這套來代替他現有這套。所以校驗現有基礎數據很有必要。沒有的數據，先讓他們做準備，但你要書面把要準備的規范寫好交給要參與的各個用戶，而且要做好培訓工作，不能講講就認為他們理解了。有了的數據，需要校驗。地基打好，才能上面很快蓋房子。而且，信息科和用戶對老系統很熟悉，校驗數據比你快的多，而且準確的多。只有經過他們的確認，你可以導數據，也可以不負責導數據。其實，基礎數據，雖然多，但只要有5-10個人，2-3天就能錄入完畢。比你導更快更準確。

　　在用戶嚷嚷需求的時候，一定要以系統目標為約束。因為每個人看法不一樣，站的利益角度不一樣，每個人的計算機應用水平也不一樣，所以每個人都有看法。你讓百家爭鳴，而且什么需求都可以提，沒有目標沒有邊界，就讓你一個人修改，那么你結果不會好而且你會心身疲憊，你會很快就厭煩了項目。吃力不討好，就是方法不對。需求，一定要圍繞時間階段和目標為約束，大家要一個目標。

　　還有你剛才講到的沒有培訓方法、培訓文檔、培訓素質，說明必須要有專人來做培訓。這塊是項目實施非常重要而且工作量大的一塊。這才是真正的項目實施。項目實施不是讓你來修改需求來了。培訓做不好，上線會出一堆麻煩，軟件再約束不強，報表就是平不了。而培養一個培訓的人員還是容易的。如果想培養一個會協調推進來事的、會修改軟件的、懂得業務需求的、會SQL語句導數的、會培訓的，這樣的專業神人確實很難。而且這樣的神人一定不專業。所以，要帶人，先要讓他搞培訓，而且讓他編寫針對不同用戶的培訓手冊，有培訓時間課程、培訓規范、考試考核、模擬練習環境、模擬數據。這是這個培訓專員可以做到的。

　　軟件修改，尤其項目型軟件，不修改是不太可能的。我不贊成在客戶處修改軟件。因為不僅僅你只會以事論事的修改，容易陷入到這家客戶具體的需求中，而不會考慮其他客戶的需求兼容，所以你修改的軟件有很大局限性，最后形成只能一家維護一套代碼，最后客戶越多越累成本越高越不賺錢，被客戶多而拖累死。而且你在現場那么多事情，那么多人打擾，你根本無心踏實下來修改軟件，只想著趕快改完上線回家，你急躁，潦草，應付，軟件質量就沒法保證了。你想改變這種現狀，你必須把需求整理好，交給在家里專門編寫代碼的程序員。你在現場，你也很懂業務，你和你本公司的程序員溝通肯定比客戶溝通要順暢的多。

　　這樣，你在現場，你的任務就是當好一個項目經理，專門協調，控制，理順，制定流程、規范、目標、時間，保證執行到位。現場還有培訓專員分擔你的培訓工作，可以幫助你校驗數據，測試功能。公司里還有專門coding的程序員分擔你的開發測試工作，而且人家寫的代碼更加多家客戶兼容使用，而且質量穩定性比你高。

　　只有專業分工合作，才能轉成正規軍。否則，你只能把自己熬倒了，心力交瘁，最后心灰意冷，跳槽而走。

　　從民兵，到武工隊，到土八路，到正規軍。這條路有好幾個階段。不能想著一步到位。現實情況也不容許我們一步到位。我們只能是能改進什么就改進什么，天天進步一點，我們就會大變樣。

　　如果從心里就認為不可更改，直到心冷不想改進，那么我們永遠不會進步。

　　為了我們自己心身愉快，我們也要進步。

　　記住，你是項目經理。你是這個項目的領頭人。你決定這個項目的成敗。

如果你連這個定位都沒有，那么你什么都決定不了，你這個項目的成敗只能隨波逐流，那樣你真的很失敗了，你什么作用都沒有，要你干嗎。

3、三五個人十來條槍 如何成為開發正規軍（三）

自從寫了關于《三五個人十來條槍 如何走出軟件作坊成為開發正規軍》走出軟件作坊：三五個人十來條槍 如何成為開發正規軍（二），系列文章后，收到了很多網友的評論，也收到了很多網友的疑問請教。而大部分人都已經當上了項目經理，手下有個2-3個人或5-6個人。少部分人還在上學或者才畢業出來1-2年，詢問的還是學什么語言和什么才是核心技術的之類問題。

　　從接到的請教來看，許多中國國內軟件公司都是以項目為主，有單做單，沒單就干靠，靠的時間長了老板心毛了就裁人，來活了就招人，就這樣反反復復。所以，大量的公司沒有開發部（因為除了銷售，開發部從開發到實施到支持都全做），當然也沒有開發部經理，只有項目經理。更不用提技術總監和CTO。即使有個技術總監的頭銜，也是為了給客戶的名片，而手下也就5-6個人，項目一來，技術總監也需要編碼和實施，其實就是一個項目經理。

　　在國內，項目經理這個詞如此常見。均為實施項目經理和開發項目經理混為一身，統稱項目經理。雖然，開發和實施是軟件產品的不同階段，不同階段關注的重點也有不同。但既然都為項目經理，那么其關注點也有共性之處。

　　項目經理，主要職責是：

　　項目范圍定義項目計劃制定、分解、分配、協調、匯報項目質量控制項目需求變更控制國內項目經理一般沒有人事權和財務費用權。老板給分配什么人就帶什么人，自己只是一個最能干的工人加工頭而已，當然更沒有財務費用權，要想請客戶吃頓飯，當然需要和老板打報告（自己團隊想休息娛樂會，只能聯機打把游戲，想團隊吃頓飯，不可能給費用的）。

　　不過，從現狀來看，國內現在的項目經理，連項目范圍和項目需求都無法控制。老板說什么就是什么，客戶說什么就是什么，用戶說什么就是什么，只要自己和自己的團隊能做，并且不累死或者不跑路，能做的都照單全收。當然，做什么，什么時候做完，都不屬于自己管理和控制，當然，項目計劃的制定由項目經理制定，就是虛設了。唯一剩下的，就是項目質量控制：開發有代碼的質量，實施有實施的質量。

　　接到網友很多詢問，都問我工具的使用情況（對組織結構和流程問的極少，可能覺得都自己改變不了，根本沒有機會實現，道理能不能行的通也就不用去想了，因為想了也白想）。問我現在的團隊使用什么UML工具、什么壓力測試工具、什么數據庫設計工具、什么版本管理工具、什么需求管理工具、什么進度管理工具、什么BUG管理工具。

　　在他們眼里可能覺得，一個團隊，只要用上先進的工具就會成為一支裝備了機關槍的軍隊。就跟我們的客戶一個想法，只要上了這套ERP軟件，我們的管理就上了一個臺階，我們的盈利就會提升。這個想法，真是奇怪，就如同一個人拿了一把屠龍刀，人沒砍到，倒是把自己砍傷了。一把好廚子的刀，到了不會做菜的人的手里，仍然做不出好菜，就這么淺顯的道理，但大家還在幻想。

　　許多人想得到答案，覺得一個正規的開發團隊應該使用是Rose、Together、LoadRunner、PowerDesigner、VSS、CVS、SVN、ClearRequest等等。

　　但其實，我們也并沒有使用這些工具。

　　我一直在商業軟件公司工作，也深深的明白自己的責任就是幫助公司最大限度的利潤最大化。而利潤最大化的實現手段就是最小的成本、最少的人、最少的時間、最簡單的方法達到老板的目的，拿出合適質量和功能的產品，包裝好，賣上盡可能高的價格。只要能賺到老板想賺到的錢，達到老板的目的，只要不影響這個目標，不影響大目標，小磕磕碰碰自然難免，有問題解決問題，沒問題繼續前進。哪個企業沒個矛盾沒個利益集團，哪個企業沒個問題沒個埋怨，有人愛自然有人恨。就是這樣，這樣是常態，不是異常。所以，我使用工具，一般都是在各種手段我都使用的差不多的情況下自然使用的，而非為了正規而正規，而是為了解決問題，而且是很有效的解決問題，而且是最簡單的解決方法。我從來不為面子工程付出成本。

　　我們最先遇到的問題當然也是軟件質量的問題。軟件的質量問題，引起了實施培訓、實施推動上線的困難、客戶使用效果的困難、支持費用的增高、支持難度的加大。最后實施部不愿意實施、銷售部不愿意銷售、支持部直接把電話轉開發部。所有人對把自己工作的不順利和不順心歸罪到開發部。當然，這樣的開發部，不被老板開掉才怪。

　　于是我空降入主了。

　　我采取的第一個策略就是：專門劃出一個輔助開發人員（因為他對客戶需求也不了解，講了3遍也不懂，寫的代碼也考慮不周全，所以代碼漏洞百出。不過這個小伙耐心還不錯，就是有些懶。看來懶人一般都耐心不錯。不過還是有些得過且過，做一天和尚撞一天鐘。就這么個才。），讓他做技術支持兼測試。

　　過去是實施部有不少人，每個人都直接打開發員的電話。支持部也是。客戶也是。老板呢，不懂軟件也不深入操作研究軟件，卻從使用者角度老提意見，看到哪里想到哪里就直接給開發員打電話讓開發員修改，從最皮毛的字的字號到最深入的商業智能問題，都提，而且讓立即改掉，其他所有人包括客戶提的都靠后。這樣，一個開發被干擾的無法工作，最后離職。

　　我劃出開發部專人支持后，規定流程。所有的需求，不管是哪個部門或哪個客戶，都歸口到他這個人手上。即使還有人直接打給開發員，包括老板打給開發員的，開發員必須把需求或問題再并口到這個技術支持手里，我來統一安排調度開發。

　　開發人員是消停了，可以安心按我的安排的進度和優先級修改了。而支持小伙子呢，電話開始被打爆。幸好我給小伙子的指示是，都先接上記錄好，能不能解決，能不能快速解決，看自己能力，不著急，誰跟你急，你跟我說。于是，小伙子被吃了一顆定心丸。

　　小伙子一開始使用的是一個EXCEL。別人提的問題都自己記錄在里面。但是弄到最后，我的手里、小伙子手里、開發人員手里、支持人員手里，都出現了不同版本的EXCEL。互相都說這個已經修改了，那個說沒有修改。這個說有多少BUG，那個說不可能。

　　于是，我上了第一個工具，BUG管理系統。不管是BUG還是需求還是建議還是疑問，誰想提，都提到這里來，隨時記錄。不管你是出差還是在支持部坐班，都記錄到這里來。凡不記錄者，一律不解決。

　　于是，天下太平。經過技術支持和開發人員努力，一個大風浪過去。利益沖突處于一個平衡或者可能隨時崩塌引來下一次沖突。

　　我于是給支持小伙子分配了另一項重要工作。測試。為了不讓你以后繼續享受折磨，那么你必須卡好關。你自己卡不好，那么以后的技術支持仍然很痛苦。小伙子為了自己以后能過上幸福的上班生活，于是測試做的不錯。所有測試出來的BUG也記入到BUG管理系統。 現在，開發人員工作量和工作質量有了量化，支持人員的工作量和工作質量也有了量化，給我安排計劃和考核人員和申請資源做了大量的支持工作。

　　所以，一個BUG管理工具，能把計劃、進度、質量、需求、BUG都能管理起來，而且能追溯，能考核，能統計工作量和工作質量。真是必備。

　　但是，接下來發現了一個問題。就是在修改的時候，老誤會客戶的需求。程序員一天在家里面開發，不了解外面的客戶和在第一線戰斗的實施人員到底想表達什么。于是修改完，程序員覺得自己費了很大的勁，而實施人員和客戶卻非常惱火，一點不領情還發怒。最后，搞的開發人員和實施人員沖突不斷。

　　需求如何描述清楚，成了必須提上日程的事情。許多沒有經驗的項目經理尤其會在這一步犯暈。UML工具、數據庫設計工具，需求管理工具，能上的都上，最后也沒解決問題，把自己和自己的團隊累的半死。

　　我使用了PPT+WORD+腦圖+EXCEL的描述方法。

　　因為很多需求都是這個支那個叉出來的。程序員往往想的了這頭想不了那頭。這就是人的思考的周密性差異。

　　想讓人能從千萬絲絳中理出頭緒，于是腦圖軟件上場。把各個分支來龍去脈表現清楚。

　　到了描述某個節點的時候，PPT上手。一頁PPT相當于一個界面窗口。每頁PPT的圖形模仿了菜單、輸入框、按鈕。按鈕按下，還可以跳轉到其他的PPT頁上，和軟件操作流程非常相似。

　　讓程序員很直觀的看到未來軟件作出來是什么樣子。關于PPT的詳細描述，如字段，流程，特殊注意，特殊控制，都用WORD說明好。

　　遇到有報表功能的時候，用EXCEL把報表畫出來，讓程序員喜聞樂見。

　　這樣，從表及里，從概要到詳細，從分支到關聯，都表述OK。客戶也能明白，程序員也能明白，實施人員也能明白，老板也能明白（這點非常重要。雖然老板不懂軟件，但他要干涉軟件，他如果不明白，他就不知道這幫家伙到底在干嗎，是在真正干活還是在偷懶，到底工作量是大是小，軟件功能是復雜還是簡單。老板如果不明白，老板在給與資源和時間上就會很謹慎，處處提防。這是許多項目經理都忽略了大事。還拿UML做秀，誰也看不懂，誰也用不了，白花費時間畫那些好看的圖。這就是中國的現狀，我們站哪個山頭就唱哪個山頭的歌，有效解決問題提高銷售收入才是我們的根本任務，我們不抱怨不幻想踏實推進解決問題）。

　　于是，老板的天平開始向開發部傾斜了。資源，當然就容易申請了。

　　畫這些EXCEL+PPT+腦圖+WORD，當然很費時間（我直到引進了日本外包開發過程管理才發現，我們的解決方法和強調質量的日本人的做法非常相似）。于是，我申請一個人，把過去實施的一個項目經理（還居然會寫點SQL，從數據庫查數據，調整個報表。實在太強了）調入開發部，專門編寫這些文件。

　　開發部開始蒸蒸日上。項目經理、開發人員、測試兼技術支持已經到位。工具也已用的不亦樂乎，深入到了公司的每個部門。每個部門都按照標準描述方法和標準流程走。現在，連實施人員都會畫EXCEL報表格式、PPT界面。

　　軟件到位，就需要包裝，否則軟件就賣不上好價格。這是很自然的事情。干啥都要個品相。漂亮的姑娘誰都喜歡。

　　軟件包裝，第一步就需要幫助文件、視頻操作、解決方案、產品介紹、演示系統。當然，文案人員很快到位。美工美化也自然到位。能多賺錢干嗎不做，老板也不是傻子。誰喜歡賣一個土灰土臉的產品。

　　有了好的產品，出不去開發部也是個問題。只有自己內部人知道功能怎么用，怎么滿足客戶的需求，其他部門都不知道。許多人都不知道新功能和舊功能的改變。文檔中都寫了，更新說明也有，就是沒有人看。還是打電話找技術支持，技術支持只能不斷解釋。問題又來了。

　　文案出馬。每次版本發布，功能更新，文案反復舉辦集中培訓，辦班，一批次一批次的培訓，百其不厭。

　　四套馬車，于是真正的天下太平了。

　　從此，開發人員和實施人員過上了幸福的生活。

　　后續記：

　　接到很多網友的評論，都說老板不可能給資源的。說我寫的太理想。

　　嗯，如果你看完我的文章就直接找老板要資源，當然是會被趕回來的。因為，你什么都沒有做就開始要資源。

　　有人還說，公司就這幾條槍，能干活的更是那幾頭蒜。根本不可能給你派人。

　　嗯，如果你思考的目標不是為老板賺取更多的錢，那么老板不可能給你一丁點的，甚至還會把你干掉。如果你覺得，這樣的老板我還不伺候呢，那么中國大部分都是這樣的公司，除非你轉行不干這行了。要干，就別混日子。想得過且過讓老板公司倒閉，這個基本不可能。再說老板倒閉了對你一點好處都沒有。

　　邁出你的第一步吧。不邁出第一步，你都會覺得這是不可能完成的任務。

　　想過幸福的生活，從現在就開始腳踏實地的動手吧。

1、三五個人十來條槍 如何成為開發正規軍（一）

自從發了上一篇博文，這幾天收到很多朋友的來信。

　　大家從各個開發語言的優缺點和適用領域，一直討論到設計模式、框架、重構、單元測試，乃至敏捷編程，最后都討論到了軟件開發過程管理，甚至都談到了盈利模式和中國軟件的悲哀。

　　最后不了了之，都覺得改善中國內地現在的軟件生產狀況不可能。

　　為什么呢？

　　我重新把這幾天大家的討論留言翻了一遍，發現大家的軟件團隊都存在著這樣一種普遍現象大部分人所在的公司，開發人員僅3-5人，多的在10人。別看就這幾條槍，還從售前支持，軟件開發，測試、打包發布、文檔編寫、實施安裝、培訓、技術支持都做。

　　這還不算什么，而且幾乎是一個人負責一個產品或一個項目，一個人從頭跟到尾，而且負責多個客戶的維護工作。

　　這還不算什么，而且隨時老板會找來八竿子打不著的新活，要的還挺緊，突然要開發，打亂了所有的計劃，最后都懶的按計劃行事，每天撞鐘，老板有事就吩咐，沒事就上網，還不讓聽歌，當然更不讓打游戲。甚至還不讓看技術書籍，呵斥不干工作。只能上網裝作在工作。

　　老板和員工互相斗智斗勇，在年終獎、報銷、出差、平時福利上啊，都明爭暗斗。老板卡的緊，員工就在項目和產品上下藥，還不知道是誰占了誰便宜，誰給誰打了工。

　　員工一邊在刻苦鉆研各種開發工具，閱讀源代碼，學習做DEMO例子，閱讀UML、設計模式、單元測試、敏捷編程等等，一邊卻懶的修改現在公司的產品，有問題就打補丁，客戶不嚷嚷就懶的修改，代碼不優化，界面不友好，架構沒架構，代碼不封裝但是，在討論中，我時時都強烈感覺到，大家是想把產品開發好，把開發過程管理的井井有條，但是都心有余而力不足。閱讀了N多軟件工程的書籍，從重型方法到輕型方法都閱讀了，但都無法把現在的開發狀態一點點扭轉好。

　　許多人想鬧革命，把現在這些產品和團隊都砸塌，然后重新來過，但這只是夢想，說說而已。只能希冀下一次跳槽，能找到一個好的公司，把自己平生所學全部發揮出來，但這好像也只是夢想，因為交流了一下，大家彼此的境況基本相同。

　　一些極端主義者自己開了公司，才發現不持家不知道油鹽貴，現在自己和手下變成了老板和員工的關系，走了過去的老路。

　　更有一些極端主義者辭職，自己做軟件，最后由于生活拮據或做做發現這個軟件沒什么意義，就丟棄了自己的夢想，隨便找一家公司開始沉默撞鐘。

　　一些聰明的家伙，有的入了外企，有的進了大的網游公司，有的進了外包公司，有的進了大網站公司，都是講究大規模開發的公司，希望能找到一條中國式團隊開發產品保證之路作為小軟件公司，我們真的無能為力了么？我們真的成為炮灰了么？

　　但是，中國軟件行業大部分都是這樣的公司。從每年的CSDN的程序員調查都可以看到，中國軟件公司大部分都保持在這種開發團隊規模，開發人員大部分都在畢業1-3年。

　　我們是在等待時間讓人變得成熟么？我們是在等待時間讓人變得技術綜合實力增強么？

　　依筆者看，作為中國軟件群體最大的小軟件公司，需要的不是UML/RUP/CMM這些重型方法，不是前幾年大家關注的小組開發方法，也不是敏捷編程這樣的結對方法，我們都無法有這樣的資源實現這樣的方法。

　　但是，想想，星星之火可以燎原。紅軍能從爬雪山過草地起家，最后解放全中國。我們就沒有方法？

　　那我們就需要想，就我們目前能擁有的權力和資源，我們如何一點點改進。我們需要的是從游擊隊到兄弟連，從兄弟連到正規軍的方法。我們現在還處于游擊隊，一個隊長領了一幫游兵散勇，有的人甚至沒有槍還背著大刀，有的人還沒殺過鬼子。

　　首先，要把我們自己變成兄弟連。

　　我常常觀看國際著名的CS戰隊的比賽錄像，他們配合的多好啊。如果他們都單兵作戰，那么早就死翹翹了。這和咱們的軟件開發多么相像。我們多么神往這種默契的配合，打的多么流暢。我們要的就是這個。他們也不幾個人么。

　　那讓我們來分析分析吧。

　　我們想好好專職的開發軟件，但我們的時間都被實施安裝、培訓、技術支持占去了。為什么我們要做這些？是因為我們軟件沒有操作說明，其他部門人都不會用。而且我們也沒有培訓機制，其他部門人更不會用。而且我們的軟件不穩定，其他部門人都拒絕實施。由于我們軟件不穩定，老出問題，出了問題其他部門人也幫不上忙，只能我們自己去做技術支持。

　　從以上來看，主要矛盾就是在：操作說明、培訓機制、穩定性。如何保證這三點。而且從以上來分析，穩定性是最重要的。不穩定，你即使有操作說明和培訓機制，其他部門人都躲著實施，誰想去客戶那里尷尬丟臉挨罵呀。所以，其他部門人會找各種理由向老板告開發部的狀，以躲避實施，說軟件太爛，根本無法拿出去。這也就是開發部往往和其他部門關系都不好，開發人員老抱怨自己就悶頭辛苦開發解決問題，沒有人說好，卻被奸人陷害。天長日久，積怨頗深。其實說起來，根源還在開發部自己這里。

　　如何保證穩定性？

　　大家第一想到的就是招測試人員。當然，一些公司的老板是拒絕養測試人員的。另外，如果你只想到招測試人員，其他方法不配合測試人員，即使有了測試人員，軟件穩定性仍然不會有提高。所以，有一些工作，是不管有沒有測試人員，都必須是我們開發人員要做的：

　　每個人的技術水平都參次不齊的，每個人對自己代碼的負責認真性也都是不一樣的，所以要想提高穩定性，必須專門從隊伍中找一個人，他作為公共代碼開發員。每個產品或項目的修改需求，必須首先經過他的思考，能做成公共代碼，能封裝成函數，就他來做。其他的程序員只管調用函數，實現客戶UI操作和輔助功能。這個公共代碼開發員必須具備以下能力：

　　參與過幾個主要項目的開發、實施、支持。這樣，他對客戶需求有綜合的把握。如果隊伍中沒有這樣的人，只有開發經理一個人有這樣的經理，那么接到客戶需求，分析客戶需求，分解析辨是公共代碼員來做還是其他開發人員來做。

　　公共代碼開發員具有負責認真的工作態度，代碼細心嚴謹考慮周詳異常保護做的到位內存創建釋放有頭有尾，代碼優美，代碼可閱讀，代碼重構，代碼性能和穩定都高公共代碼開發人員的技術能力高，知道封裝成什么樣的函數接口，在靈活性，以后的修改變化性上最好應該說，找一個技術能力好的，工作認真負責的人，應該是不難找到的。而且專門做這件事，不讓他參與各種雜事，他是應該能干好這件事的，而且會越做越好，這就是術有專攻。

　　剛才還講到一件事，那就是開發經理要熟悉客戶需求，而且是深刻理解客戶需求。

　　客戶需求，客戶需求。這個讓開發部最頭疼的字眼。每當想起客戶需求，就想起了以下這些話：

　　程序員說：這是你們家個性的需求，太邪門，我們不做。客戶說：不做我們找你們老板去，我們是花錢買了你們的產品的。

　　客戶說：我不會用鼠標，你給我做一個語音輸入吧。我們還想要一個類似QQ的東西供我們內部溝通，你們給我們做一個吧。程序員：我暈。

　　程序員說：等你們內部斗爭完，你們協調完了，我再調研需求。

　　似乎，我們在需求上無能為力，我們永遠在追趕客戶的需求，滿足他們的現狀，把N多家的客戶需求都加進軟件中，只要能實現的，我們盡量咬牙實現了。

　　最后，我們發現，我們的軟件無比復雜，誰也不會用了，連開發部門都不會用了，誰也不知道這個需求當時為什么是這樣的。因為無比復雜，所以實施、培訓、技術支持都成了問題，穩定性更成了問題。代碼互相交叉，根本無法理清有多少交叉影響點。維護的程序員都快崩潰了，天天在祈求，千萬別接到客戶電話，千萬別接到客戶電話。

　　這個問題終歸是問題，而且是軟件開發最大的問題。雖然我們也動用了這樣的技巧：

　　客戶業務部門不能隨便提需求。必須集中匯總到客戶IT部門，由客戶IT部門匯總過濾完，再集中報給軟件公司客戶IT部門的需求，必須客戶方負責IT項目的老板簽字才能生效，才能報給軟件公司不能隨時報，每3個月集中報一次不能口頭報（即使在現場實施支持也不行），不能電話報，只能MAIL或傳真來報必須按我們規定的格式報，要嚴格寫清楚需要實現的功能的界面，輸入數據或輸出數據，輸入輸出數據的格式要求，誰操作，多長時間操作一次。

　　軟件上線后只能免費修改3次。以后再有需求，就必須另簽合同另收費，否則不予修改。

　　經過這么幾招，客戶也疲了。需求是不提了，開發部歡呼雀躍。但我們真的做好了么？難道客戶真的滿意了么？客戶為什么要用我們的軟件？難道僅僅是為了把他們現在手工做的，然后轉到計算機去做。讓計算機的查詢統計計算速度代替人工？

　　客戶為什么要提這樣的需求？客戶要根本解決什么問題？這些問題誰來想，誰來想解決辦法？

　　，My God!我們無能為力，因為我們是技術人員，我們不懂業務。

　　那這個問題誰來解決？

　　程序員苦笑了：沒有人解決，也沒有人能解決。客戶就要，你不做他就要給老板打電話。

　　噢，那就讓程序員的噩夢繼續吧。誰也救不了你，能救你的只有你自己。

　　要救我們自己，必須我們自己走出我們自己。誰讓我們就處在這樣的處境呢？我們都想過的好，只能我們自己救我們自己。

　　那我們就鼓足勇氣，走出來，從我們的設計模式、OO、軟件工程、虛擬接口、反射、持久化、框架中走出來。開發經理來承擔起客戶行業研究來：

　　客戶行業這個群體有多大？大中小規模各有多少家，各分布在什么省？我們面對的最佳客戶是什么規模什么信息化程度的？我們的次佳客戶是什么規模什么信息化程度的？

　　我們的上層競爭對手、本層的競爭對手、下層競爭對手目前的產品怎么樣？他們各自的優點是什么？他們各自的缺點是什么？我們應該突出的優點是什么？我們的缺點是什么？

　　客戶行業的過去5年，現在2年，未來3年的發展歷史和趨勢是什么？他們面臨哪些挑戰和機遇？

　　我們現在所做的典型客戶，他們的組織結構，人員規模，每個崗位每日業務流程、每個崗位每日每周每月每季每年的異常處理業務流程，每個崗位每日每周每月季每年的輸入表格，每個崗位每日每周每月季每年的常用數據查詢，每個崗位每日每周每月季每年的統計報表針對以上的了解，客戶面對未來挑戰和機遇，未來應該如何變更他們的崗位和職責和流程，盡量流程少，效率高，運轉快？

　　其實，開發經理就相當于業務架構師（因為我們還是游擊隊，不可能有專職的業務架構師），公共代碼開發員就相當于技術架構師。

　　柳傳志說的非常好：搭班子，定戰略，帶隊伍。你班子不行，上什么需求管理軟件、版本管理軟件、項目進度管理軟件、自動測試、自動集成軟件，都是無法落地執行的。

　　有了夯實的業務+技術，功能實用、功能符合客戶操作、功能穩定。這是軟件最基本的要求，就都能滿足了。這時候再招測試人員，就能把質量再夯實了。

　　而且，測試人員由于熟知產品，他們還能做技術支持呢，這樣可以有更多的開發人員來專職開發，開發的專業性就能越來越提高了。

　　好的產品，還需要有好的文檔和培訓，否則其他部門還是不會接開發部的產品的。

　　那就招一個文案人員，寫幫助說明，制作操作視頻，制作學習版數據庫，參與輔助測試（這個很重要，否則文案人員不熟知產品，無法寫出有質量的文案）。有了這些文案的基礎，最熟悉產品的非開發人員就有了兩個崗位：測試兼技術支持，那么文案就兼起培訓工作（由于他自己寫文案自己用自己的文案做培訓，在培訓中會有各種提問，會更加增進他對文案和產品的理解，能寫出更好的文案。而且他不是開發人員，他能站在使用者的角度上來寫來講，而且他屬于開發部門，他會給產品開發帶來更多更好的產品易用性建議）。

　　好了，開發部的四套馬車終于起來了，這就是我要講的開發模式：從游擊隊轉變為兄弟連，從軟件作坊走向記住：業務架構、技術架構、測試兼技術支持、文案兼培訓，四套馬車。

　　我們一直用它，效果很好，搭建團隊容易，循序漸進不革命。

　　有了這么好的團隊，就能比過去產出更好的軟件，軟件的質量，軟件的進度，軟件的競爭力就都上來了，再上各種管理軟件：如項目管理軟件、版本管理軟件、BUG管理軟件、自動測試軟件，就水到渠成了。

　　其他部門也愿意接軟件了，軟件的實施和培訓和技術支持都被其他部門接過去了。開發部門也終于專職專業起來了，整個公司都很協調了，部門間也不互相陷害抱怨了。公司發展速度蹭蹭的。

　　老板看著形式這么好，也不摳門了。獎金福利隨之而來。老板看著公司產品銷售這么好，也不用再為公司生存發愁了，不用隨處找單子養活了，給開發部門更帶來了專業理順的計劃發展。老板也開始重視研發部門了，研發部門在公司的地位高多了，給與研發部門的資源和支持也更多了。

8、水清則無魚

我的朋友開了家屁小公司，純粹的三五個人十來條槍。每年還不死，但活的也很辛苦。平時做的也就是兩三萬的單子，運氣好能做8-10萬的單子。那天，突然給我打了電話，說要請我吃飯。

　　飯肯定是不能白吃的。朋友告訴我：唉，煩心啊。客戶不成熟，是麻煩事。客戶太成熟，也是個麻煩事。

　　我說，此話怎講？

　　我朋友說：你看，我過去跟單，客戶對軟件不懂，但他卻知道有個華軍軟件園，里面有可以免費下載的管理軟件。我報個兩萬的價格客戶直晃腦袋說：我以為你們的軟件600塊錢就能買到，怎么你們要殺人啊？

　　我朋友一臉苦難相：兩萬塊您都覺得貴啊。我們可是帶技術支持，還有培訓，還要給您做定制化開發呢。我給您這兩萬的報價，也已經是我插草標賣人的價兒了。

　　客戶還是直晃腦袋：誰不知道你們軟件開發，就一臺電腦一個人，啥費用也沒有，就賣我們兩萬。你看我們，進原料買地建廠房招人買流水線搞運輸招商做廣告打價格戰，我們可是水深火熱啊。我們全是成本，毛利極低，賺的都是血汗錢。你們呢，啥原材料也不進，流水線也不買，也不建廠房，居然賣兩萬，你說你們的利潤多高？

　　我朋友無語。

　　我朋友就盼著能有個了解軟件行業艱難的企業CIO能互表衷腸。

　　這回他總算遇見了。

　　大活兒。這次可是大活兒。我的朋友這樣評價這個項目。

　　原來是一家企業，計劃要給它的全國經銷商渠道開發一套管理軟件，以能管理全國進銷存的情況。但是這次就是由于是個大活兒，所以客戶方要求把價格報清楚了，不能開發費+實施費+...=總費用這么簡單。他需要我給他說出個道理。為什么這么多。而且這個企業CIO最難搞的就是，他明告訴我，別跟我說你們一個開發人員的每天費用是3000塊。你開發人員月工資9萬啊？

　　這回我是折了。我過去都是做小單子，和客戶反正也有關系（現在哪個上三萬元的單子是打陌生電話打出來的？），于是就囫圇吞棗就把單子簽了。水清則無魚，看似軟件利潤高，但軟件這個東西看不見摸不著不好銷售啊，報的價格高了誰都覺得你利潤高，不吃你吃誰。所以到處都是爺，哪個門都得把香燒到了，最后落手里其實我也剩不下多少個子兒。還得給員工發工資，還得請客送禮，還得交稅，還要交辦公室租金，每月這費那費都是要錢的。苦啊。

　　我故意逗他：那你干脆關了公司，回去繼續當程序員。

　　我的朋友詭秘一笑：呵呵，還是比給別人打工賺的多。別跟我打岔了，快給我想個方法，怎么報價讓他覺得合理。

　　我說：看到了吧。耍嘴皮的啞了口，混天黑的犯了愁。以后，拍腦門的時代就算一去不復返了。客戶也不是冤大頭，你說個10萬就給你10萬。你以后不給說清楚了，誰也不會跟你簽單。

　　我朋友說：那你快教教我啊。

　　我說：唉。我遇到的問題和你不一樣，但我的解決方法也能解決你的問題。

　　我過去遇到的問題是：我一直在琢磨如何提高銷售收入。否則，這么老路子做軟件，費死勁也掙不了幾個錢。所以，我在研發過程管理上引入了一些方法，引入專職的項目經理、公共代碼開發、測試員，來收集需求、控制需求、安排進度、把控質量。在產品制造上我引入了美工來美化界面，引入了文案編寫了精美的幫助文檔、產品白皮書、演示版和視頻教學。讓銷售拿出去給客戶打單，一看PPT一看產品演示就感覺這是個專業的產品。另外，我在實施和咨詢和技術支持也下了大功夫，讓這種專業性一直連貫的保持下來，否則就會讓客戶感覺簽單前很專業，一簽了單子就糊弄人，這樣生意就沒得做了。

　　有時候你會遇到這樣的場景：客戶說你的東西太貴了，而你的回答往往是一點不貴啊，我才給您報3萬塊，您的企業一年的流水就一個億呀，您坐的寶馬車一次保養就3000多塊。您看，軟件能全體員工用，而且能提高您企業的運營效率，才3萬塊，多值啊。

　　但客戶還是覺得貴。為什么呢？不是他掏不起這三萬塊錢，他可能請他的客戶吃飯，一頓飯就能吃3萬塊。他為什么覺得他吃飯3萬塊不貴，而3萬塊買你的軟件就貴呢？原因就在于他覺得你產品不值3萬塊。但到底值多少錢，他也不了解軟件成本構成，所以他按心理估計，給你的報價上打個5-7折應該沒錯。

　　而軟件這個東西，尤其是管理軟件這個東西，就非常類似古董字畫一樣。在識貨的人看來，他非常值。在不識貨的人看來，一文不值。而管理軟件的銷售人員，尤其是銷售這個行當，正規的管理方法很少，大部分都是術和案例，喜歡出新招出奇招，而對按部就班的流程運作頗為不感冒，所以對固化流程的管理軟件也是覺得沒什么大作用，比EXCEL貴還比EXCEL難用，所以也講不出來這個管理軟件該值多少錢。客戶也不知道值多少錢，銷售也不知道值多少錢。這樣，雙方的價格磋商，就成了互相猜心。客戶覺得打他個5折，他估計就實在了。而銷售呢，估計客戶能承受xx萬的價格，所以我就報個xx萬。價格和軟件成本沒了關系。到底這個項目做到最后是賺是賠，都不清楚。反正單子我是簽了，我的銷售任務完成了。

　　我就是為了應對這種銷售和客戶亂猜拳互博弈談價格，才出此方法。

　　我先給你說說軟件開發費怎么報。下次再請我吃飯，我再跟你說如何給實施報價。

　　產品開發由以下階段構成：

　　客戶調研、客戶調研報告編寫功能設計、功能設計說明書編寫開發測試幫助文檔、培訓課程、培訓演示版本編寫其實，產品開發完畢后，還必須由開發部的文檔組對實施部門的培訓專員和項目經理進行內訓，否則產品知識無法通過培訓專員和項目經理傳遞給客戶。這個內部培訓也都是有成本的，而客戶和你，往往都會遺漏的。

　　由于功能說明書為內部產品開發使用，所以功能說明書不會銷售給客戶。如果客戶非要連功能說明書都認為是他的產品的一部份，那么他也需要花錢買走。這也是文案人員和項目經理辛苦勞動的成果，又不是自動產生的。有付出就必然要求回報。

　　產品開發團隊由如下人員構成客戶調研團隊產品開發團隊產品測試團隊產品文檔教育團隊客戶調研團隊，由項目經理和培訓專員構成，親自到客戶現場去調研。每個調研團一般由2名人員構成，1名項目經理，1名培訓專員。由于不同經驗的人當然工資待遇不同，而工作的質量也就不同。所以我們的調研項目經理，也有高級調研項目經理，中級調研項目經理，調研項目經理三個等級。你如果作為客戶，你敢把企業的需求和流程梳理交給一個剛畢業出來的毛頭小子么？他對企業的感覺連企業的一個看門人都不如。當然，不同等級的調研項目經理，調研一天的工作費用當然也是不同的。與之匹配的調研助理（培訓專員）也是有不同的經驗等級的。

　　調研費用，按調研團隊人數和工作天數和他們的工作費用和調研家數計算。出差過程所花費的交通、住宿、餐費不包含在他們的工作費用中。調研是調研費，這是調研的工作，但出差產生的費用是出差的費用。如果你把這些都整到一塊，你的調研費用肯定看起來很高，客戶又質問你怎么一天3000塊了，還不如報的時候就清楚的報。哪里都需要錢呀。

　　一般，調研周期為兩周。先是調研收集客戶現有狀況細節，然后進行現有狀況梳理。梳理理解后，總結疑問，并與調研方開會，雙方就疑問和目標和需求進行討論。最后是根據多次討論進行調整，得出最后的調研報告。

　　我為啥說需要兩周呢。因為一個企業有許多部門許多崗位。你要把客戶的整個組織結構和崗位職責和流程，和他們的現狀問題，和他們的需求目標，都需要調查清楚，而且還要和他們協商統一認可好如何改進，否則你怎么設計適合他們的系統。沒有兩周的調研和討論和反復修改磨合，你出來的軟件更是痛苦，調研3天，開發1月，實施和不斷修改2月，維護修改和穩定和技術支持3月。最后客戶還抱怨你的軟件太不穩定，N多需求都沒有做，當然不能付尾款了。你不答應他們的需求，你就拿不到尾款。于是，需求修改更新，發現又引出了其他的BUG和需求，噩夢循環啊。

　　咱們說說調研。

　　例如，調研10家客戶。客戶分布在東北、華北、華東、華南、華中、西南、西北。調研需要2周的時間。如果遇到星期六日還需要出差進行工作，那么休息日加班費就按國家規定累計。

　　這樣來算一下費用。高級調研項目團隊，中級調研項目團隊，標準調研項目團隊，（每個相應等級的調研項目經理每天的調研工作費用+他的每天對應的餐費交通費通訊費住宿費+每個相應等級的調研助理每天的調研工作費用+他的每天對應的餐費交通費通訊費住宿費）x10天工作日x10個城市，你看看多少調研費用吧。你用一個EXCEL做個自動計算就OK了。你把這個公式內置到EXCEL中，客戶只需要選擇自己想要等級的調研人員，填寫要調研一家的天數，再填寫要調研的總家數，調研費用自然就出來了。如果客戶覺得不能接受，就讓客戶自己玩這個計算公式，直到他自己都覺得確實沒什么水分了作罷（他也不是變態狂，以榨干軟件公司逼死軟件公司為樂。所以，他認可的是一個合理的報價，而不是離譜的報價。他認可的合理的利潤還是手下留情的）。

　　想想吧。沒有跟客戶要一點渾水摸魚的費用。都是大家都能認可和理解的費用。假設，一個在本行業信息化工作了5年的調研經理，他的月薪水達到6000塊應該沒有人質疑吧。那么他這個人每天最低的成本就是200元。再說了，這個員工消耗的其他辦公費用與福利與稅金也是有均攤成本的（企業總不能無原因生錢吧。錢肯定還是要從客戶這個源頭來）。

　　另外，我還沒有計算調研團隊在這2周的調研時間內，還有4天的休息日，如果工作的話，這個加班費用還沒算呢。你可以算一下。

　　調研完了，就要開發了。你以為雇傭幾個編碼人員就能搞定了。那樣的搞定也是活稀泥的，最后不斷修改的成本能讓你把賺的錢都吐出來。所以為了以后不秋后算賬，我們就得從一開始好好做（如果你想賺更多的錢，可以把我給你講的配置都縮減了。當然，質量和效果也就縮減了。一文價錢一文貨，誰也不白給。國內軟件如此現狀，就是為了多賺錢，最后把客戶給的合適的費用都縮減了，但是給客戶報的卻是達到100%效果的人員數量和人員素質和人員天數。這個中間差就是個小九九了）。

　　產品開發團隊，一般由以下角色構成開發總監1名架構師1名，公共代碼開發人員2名業務開發組長1名，主要代碼開發1名，輔助開發1名。每個子系統由3名人員構成。假設有4個子系統，就需要有12名開發人員產品測試團隊，一般由以下角色構成測試員1名。假設有4個子系統，就需要有（4+1）=5名開發人員，其中+1是公共代碼測試。

　　產品文檔團隊，一般由以下角色構成每個子系統一個文檔編寫與內部培訓人員。假設有4個子系統，就需要有4x1=4名文檔人員。

　　所以，一個產品開發過程，以4個子系統為例，共需要參與開發人員客戶調研團隊 2名產品開發團隊 16名產品測試團隊 5名產品文檔團隊 4名共計27名參與者（估計許多人會說我三五桿槍能有這么多人么？樓主真是搞笑癡心妄想白日做夢。我報這個人數，是為了計算一個能達到客戶效果的一個合理人員配置上。國內軟件公司往往無法滿足，所以效果就不斷衰減。不過，我一般都建議三五條槍的企業最好能從實施部門抽調過來調研、文檔、測試人員，這樣人數可以縮減，但要做的事情不能縮減，這樣效果衰減的就不會很厲害。很多三五條槍的企業現狀都是做一單騙一單砸一單，就是什么人也沒有，兩個開發人員從調研到設計到開發到測試到實施到支持都這兩位老哥。甚至干脆一個人全挑。這樣的現狀如果不去想辦法改觀，軟件質量和軟件競爭力仍然無從提高。）。

　　客戶調研周期14天。產品開發周期60天，產品測試周期10天，產品文檔周期10天，產品內部培訓周期10天。由于產品測試周期和開發同步測試，自己獨立出來的10天是綜合測試。產品文檔周期10天也是如此。而產品內部培訓周期10天，是必須在產品文檔發布后才能培訓。

　　所以總的項目周期會是14+60+10+10=94天，27名參與者。才能保證一個產品（4個子系統+1個系統管理系統）開發的質量。

　　平均每人6000元月工資算（因為有低工資的培訓專員和輔助編程，也有中等工資的各職責經理組長，也有高工資的總監，所以拉平6000元，應該也算比較合理。）。一個產品的開發大約是6000x3月（94天）x27人=486,000費用（這可都是成本，諸位客官都看到了，里面沒有加任何企業的利潤點）。再加上30%的毛利，共486,000+145800=631,800。大約63萬開發費用和3個月的時間才能保證4個業務管理系統的軟件質量和進度。

　　這些人的成本，你都可以做一個計算公式，明明白白得算。在客戶要求的質量、時間限制內，使用多少人，使用多高工資的人，一算，成本就出來了。成本出來了，再加上你希望的合理毛利，就得出了你應該報出來的價格了。否則，你拍腦門報價，做到項目結束，你還真有可能虧損了。那些被項目拖死的公司還少嗎？

　　的毛利，剔除銷售費用和稅金和管理費用，純利在15%以下。也就是說，年銷售1000萬，純利才150萬，其他都產生了費用支出。根本無法支撐下一年的生產再發展。

　　這樣來看，軟件公司確實活的挺慘。

　　這樣來深入計算軟件公司一個軟件的成本和利潤，我想那個說600元軟件的客戶該理解了吧（當然，那些總覺得老板是黃世仁的程序員，心里或許也能舒坦舒坦）。

4、人，是人，真的是人

　　有網友評論我之前的幾篇博文：分析的不錯，方案似乎也很能解決問題！不過必須滿足一個潛條件：一定要找到非常合適人。現實中，就連最基本的程序員，找個合格的也不容易（聰明伶俐的養不住、經驗豐富的養不起、遲鈍呆傻的沒法要、碰上心術不正的還夠你喝一水壺的）還有網友評論：樓主所說的很多方法，都是假設了客戶還不錯、對項目的重視程度、習慣于正規化的程度都還過得去，而樓上有些朋友的質疑則是指出這些資源不一定滿足的情況；但是跟貼最多的評論就是：現實問題描述的很精確，但解決方案不現實，太理想化，老板根本不可能給你人。如果真的發慈悲心，也是給你一個新人讓你哭死。你想主導項目，省省吧，死了你的心吧，一切都是老板說了算。而且，你敢和客戶說個不字，看來你是不想要你的飯碗了。還是乖乖敲好你的代碼，多干活，多跟客戶搞好關系。高手做啥都是高手，低能再培養再有方法管理他也是低能。你這樣研究，只能吃飽飯瞎想瞎扯蛋，有你這工夫，早就把項目做好了。

　　種種評論來看，一切的根源都是人，是人。大家都覺得我的方法要想實施，必須老板支持，員工也是高素質的，客戶也是高素質的。而三者要想湊到一起具備，根本不可能。所以我的方法算是理想的癡人說夢。

　　能支持的老板從哪里來？高素質的員工從哪里來？高素質的客戶從哪里來？好像一切都是運氣而來。好像我們就有高薪能聘得起高素質的員工。好像我們的產品面對的就是高素質的客戶。

　　但我回顧了自己10多年的從業經驗和管理經驗，我并沒有發現這個規律。我并非供職國際巨頭公司，也不是國內知名企業，只是信息化行業內略有名氣而已。手下很少出現名牌大學的員工，也很少能達到所謂的高薪（我自認自己還沒有在馬云、史玉柱、牛根生、柳傳志這樣大胸懷大眼光的企業家手下任過職，我們所從事的行業信息化也不是暴利的行業，大家也都知道管理軟件沒啥暴利，定制化修改、實施、咨詢、培訓、支持占去了很多成本。），我們的客戶也是各種各樣的人都有，從挖煤暴發戶的私營老板到死氣沉沉勾心斗角的國企，我們的客戶千奇百怪。

　　在這樣的環境下，我能把方法用起來，我和許多網友也交流過，最重要的是我認可了以下觀點，這就是一個職業經理人和老板的關系：

　　老板都是疑人也用用人也疑。用人不疑，疑人不用，我不奢望。

　　再勞苦功高，我也只是職業經理人，我不擁有這個企業的哪怕1%所有權，所以我做好職業經理人本分，老板的歸老板，職業經理人的歸職業經理人。職業經理人的職責范圍的，老板權力范圍的，不要超越，也不要動歪腦筋。即使公司大部分的收入都是你研發的產品帶來的。

　　計劃不計劃一件事情，執行不執行一件事情。一定要以老板利益為目的。老板不賺錢，一切好事一切好想法都會被老板推翻，老板就是老板。老板賺錢賺的眉開眼笑，其他的事情就好辦的多。這是很多職業經理人居然都認識不到的，他們總抱怨老板限制太死，什么資源也不給，干活還賊累。根源就出在這里了。想實現你的想法，必須在實現了老板想法和目的的前提下才能做。所以我的方法能實現，多靠此。

　　而且我的方法不是為了我自己有什么好處，我的每一個方法也都不是為了正規化裝修門面圖好看。我的方法都是為了解決實際問題，為了老板賺錢更快更省成本更容易，員工更省力，客戶更滿意，而且每個方法都是在本企業能力和成本范圍內能執行落地的解決方案。這樣的解決方案，哪個老板會不支持呢。但很奇怪的是，很多研發部主管都忽略這個重點，老板在想利益，他在想技術。兩人說不到一個目的去，互相不理解互相不支持互相埋怨，久而久之互相猜疑互相提防互相留一手。其實技術就是個手段，賺錢是目的，雙方一起綁定去賺錢，怎么合法的賺更多錢怎么來。如果研發主管能腳踏實地的從本企業的能力和困境和現狀去思考改進方法執行落地，而不是抱怨這樣的環境沒法實現想法消極怠工或心想跳槽，我想很多心結就都打開了。

　　只有和老板具備了這樣的距離和關系，我的方法才好實施下去。所以，很多人覺得太理想化，就是和老板沒有找到自己的位置。

　　但是，即使有這樣的基礎，要實現我所述的方法，也需要其他的環境支持。

　　我個人是這么看的：

　　好的氛圍，才會引入、留住好的人（亂世強盜多就是這個理）。

　　好的人，才會有好的制度，并且保持好這個制度（制度是人定的）。

　　好的人和好的制度，才會遇到好的客戶（有句老話，夜路走多了總會遇見鬼。有些人老想著邪門事，最后也被邪人玩。近朱者赤近墨者黑，什么人總遇到什么人，就這個道理）。好客戶就會產生好的結果。

　　所以，好的人才，好的客戶都不是運氣來的，而是來自你自己。你就是控制源頭的人。

　　如何制造好的氛圍，我講講我的職業經理人管理人的一些心得：

　　師傅制。這里沒有總監，沒有經理，只有師傅，老師。總監，經理，會讓員工產生隔閡，距離，權力爭斗。每一個人總有一個師傅。每一個新人進來，都要指定一位合適的師傅。尤其是新人，更要短期內注意看時候合適，不合適就要更換合適的師傅。什么問題都可以問師傅，從技術到公司制度到公司新聞公司歷史到職業發展規劃到個人生活問題。團隊的凝聚力，配合性，歸屬感，責任感，很多問題都被人的感情消化了。

　　朝九晚五，禁止加班。其實大部分程序員也是不喜歡加班的（不過有些程序員是光棍，也是漂在北京，反正也是一個人，于是就喜歡呆在公司上網玩游戲看小說看電影吹空調，美其名曰加班。還有一類老板喜歡看表面功夫，誰加班就喜歡誰，于是大家都裝做很忙都要加班）。因為加班不給錢。不給錢，還加班，天長日久就覺得自己很虧，心里不平衡，各種心思就都有了。其實也沒有多大的事。我的老板一開始對我的不加班也是心存戒心，但是每次交給他的結果比加班的部門做的都好都快，他也就默許了。

　　良好的辦公環境和良好的個人形象。我們看到美女就興奮的口吐蓮花，我們看到陽光溪水草地我們就心情舒暢。當然，我們看自己，別人看我們，都是一個道理。心情好，工作才能好。一個滿桌狼藉充滿煙味飯味腳丫子味有人在冥思苦想解決問題有人在打游戲有人在放朋克音樂有人在罵有人在打鬧嬉笑有人把腳放到桌子上的辦公環境，我看誰都會逃離。

　　以更快更省成本更容易完成任務為目標，以賺更多錢為目標，以提高產品質量產品價值產品售價為目標，鼓勵員工進行自我崗位上的改進創新，我經常給與交流和指導，一旦有效，進行精神或物質的獎勵或職位提拔或工資晉級。

　　好的氛圍有了，就需要有好的人才。以下是我引入好的人才的幾個心得：

　　人的年齡和工作經驗拉開距離。年年招，時時招。不斷看人，試人，濾人，培養人，形成層次感有階梯有接力的員工組織，綿綿不斷前赴后繼，不會出現人才地震、集體疲勞、小團伙爭斗。避免不同高低職位上全是80-84年的人。下屬還在窩里斗互相不服（很多員工不看對方能力，就看對方的工資和年齡。憑啥你就是我師傅？），那么客戶逼你，老板壓你，其他部門利益沖突你，下屬還鬧你，你這個孤獨人算是失道者寡助也。

　　人的技術能力高低先放一邊。首先要過EQ關。有些中小型企業沒有HR經理，一般考察EQ，都是老板把關。如果你現在招人沒有老板把關，那么必須先考察人的EQ，再考察他的技術能力。我最怕有些羨慕科學管理的管理者照搬什么EQ測試問卷或什么團隊游戲來評測。我的評測方法仍然是不講道理，要講經歷。沒有工作經歷，至少有學習經歷和生活經歷吧。一個人的情感、壓力、正義感、真誠感、領悟力、心細觀察力、思路整理總結能力、關注全面平衡能力、執著力，都能看的出來。

　　招聘程序員也得看這些。我曾遇到一個程序員，思維混亂所以代碼也混亂，思考也不全面，程序到處都是漏洞，思路也不自我整理總結，無法舉一反三，給他講了多遍的需求他都無法自己重述，一有了問題很急躁說搞不定了，一看還是很簡單的問題，把錯誤提示原模原樣輸入到百度中查百度就能搜到好多，你說這樣的程序員算技術合格嗎？

　　其實，試用期的三個月就是主要看他的EQ和他的技術能力、理解學習成長能力，而不是片面只看他的現狀技術能力。一個不愿意學習鉆研，沒有方法鉆研快速學習理解，推一下動一下，或者怎么說都理解不了的，都需要統統辭掉。另外，對于心術不正有仇必報不服管教之類，早就掃出門外。一個講究吃穿用享受或者滿口臟話習慣毛病一堆或者不孝順父母或者滿口介詞的人堅決不能要。

　　專業發展，流程協作。如果不專業化，老板有什么活就分配什么活，時間短了還認為自己是在學習更多知識在鍛煉。時間長了就會覺得自己就像個混子，干什么都干過，但什么都拿不起來。出去應聘啥職位，是應聘開發呢，項目經理呢，實施呢，支持呢，銷售呢。啥都做過，但啥都沒做專，都了解個皮毛，真要讓上手還真給人家拿不下來。心就慌了，覺得自己是個被老板困在手心的小鳥，無法飛出本企業的樊籠，一旦飛出就要餓死沒有能力存活。好可怕。難道只能在這家公司耗死了？趕快能逃逃吧，逃到一個正規的專業的公司去。

　　下一階段目標交流制定。交流，我想每個CTO或技術總監或研發經理都會做。交流可以了解員工的困難和心中的疑惑、個人期望、個人專業興趣的變化、人生觀世界觀技術觀管理觀生活觀（以調整自己以后和該員工如何交流、如何講解工作、如何鼓勵、如何布置任務、如何考察等等）。交流也可以讓員工多了解自己是怎么想的。雙方在日常很多事情的分歧和誤解就會消除，心會往一處想，勁會往一處使。但是，交流也不僅僅實現這些目標。更重要的是，交流，主要為了能給該員工制定一個切實可行的、某段時間段內可達到的、他也喜歡也愿意努力的、也會他未來職業發展很有好處的職業目標。沒有目標的工作，雖然他很努力，但是他容易迷失方向。如果他又是一個不能很有悟性很有規劃的人，他的工作就會形成做一天和尚撞一天鐘。撞鐘撞的不錯，但沒什么更高層次的提高。天長日久，就會木然，倦怠，不思進取，思想守舊，遇到新問題無法突破。所以，我會根據雙方的交流，和員工一些協商一個下一階段的職業發展目標，并且時常指導調整他的做事方法和思考方法，給他講解一些我過去的工作經驗和我的感受，鼓勵指導他們有計劃有目標的走的更高更專業。這是很多研發部門主管沒有做的一點。

　　最后有幾句話和大家分享一下：

　　毛主席說：社會主義就是打土豪分田地（不是資本論這樣的天人天書），要天天講，時時講，到處講，要團部建設到連隊。所以，借用毛主席的方針，咱們的團隊精神建設也得這樣。天長日久，就形成了文化精神，就形成了習慣。

5、習慣決定性格，性格決定命運，細節決定成敗--實施經理的工具箱

前段時間， 項目經理的工具箱---走出軟件作坊：三五個人十來條槍 如何成為開發正規軍（三） 寫完后，發現寫的有些偏，偏向了開發經理，而沒有顧及項目實施經理。在項目實施的時候，有些獨特的地方，需要有獨特的工具來幫助。

　　前天晚上，和一位做了多年實施項目帶領的朋友吃飯。

　　我笑著跟他說：實施，能不能不實施？！不去人，也不搞實施，把軟件賣了就OK，你們做好IT咨詢就可以，把什么數據準備、培訓、協調業務部門和信息科需求、推動上線、報表制作都讓客戶做。咱也不賺他的實施費用。因為你們是個合伙成立的小公司，你們如果也是從開發到定制化到實施到支持，你們根本沒有那么多人，項目周期又這么長，銷售價格競爭又如此激烈，你們賺不了幾個錢。實施尤其是最耗成本的，你們好不容易拿到的單，實施完剩不了多少，所以你們這么多年公司也沒有大發展，不斷在年年求生存。

　　他說：你純粹是白日作夢。我一直在想怎么能縮短點或干活輕快點，你還在做夢不實施。不實施，人家買你的啊。企業那幫人，連數據準備都不想錄入，你讓他們自己實施？

　　我說，我雖然沒有你實施的客戶多，但我也做過燈塔標桿客戶。再說，我多年統管開發、實施、服務三大部門，沒個方法能搞定么？我給你介紹一下我的一些心得。可能不會真的讓你不去實施，那樣確實可能帶來客戶連單都不簽的危險。咱們一起交流一下怎么能讓實施盡可能的短。能短一點也是一點。我這個人就有個習慣，能改進我就不在原地踏步。這個改進方法不行，我就繼續想其他改進方法，不斷嘗試不斷推進，哪怕一點改進我都要去實現它。量多了就會引起質變。許多人就等著大機會大改變，對小改進懶的動，我不贊同。

　　我說說我在項目實施和項目管理上的一些好的方法和心得。

　　做實施，最怕的不是人家使用中出現各種麻煩。而是業務部門抵制用，不想用，出各種各樣理由，項目進展很慢（真不知道過去是怎么簽單了）。究其原因就是：你們用軟件能做到的，我用EXCEL也能做到。我現在就用的挺好，你們的軟件還挺難用，還不根據我的需求我的習慣修改。修改了我就用。

　　完了。原來我們辛辛苦苦研發出來的管理軟件，跟一個電子表格沒啥區別。人家EXCEL還可以盜版免費用，網上隨便下載。我們這個還花錢，還有時候有BUG，還要服務器，還要專職系統維護。

　　實施人員沒招了。都是些剛出身社會一兩年，學生氣和學生思維習慣都還沒有擺脫，就讓來實施管理軟件，并且給人家管理人員講軟件中的管理理念。這有點勉為其難。

　　其實有些管理軟件不僅僅是減輕工作量，用電腦代替人工這么簡單。它還蘊藏著豐富的管理經驗。但說到管理經驗，就很玄妙了。管理這個東西，是個公說公有理婆說婆有理的東西。很多人經常一說，他們管理落后。啥叫管理落后？你具體說說。說不出來了，指東打西的說的不到點子上。

　　如果先進的管理理念說不出來，有些軟件就跟做手工一樣了。

　　這是很多實施管理軟件人的難題。先進的管理理念說不出來。因為自己就是個實施人員，又沒有管理過企業，又沒有多少管理經驗，也就管過1-2個人，怎么能說服人家天天待在企業處理業務的管理人員呢。無法說服人家，人家就覺得這個管理軟件就跟EXCEL一樣，還不如EXCEL好使，人家肯定不用，沒法上人家用起來呀。怎么辦呢？

　　針對這個現象，我專門從軟件附著的管理理念中抽取出了管理模型KPI、管理模型計算公式、管理模型流程。把管理模型KPI一亮，都是管理人員很喜歡的和利潤費用成本相關的東西。他們就來勁了。然后就給他們展示這些KPI是怎么得到的。計算公式上場。計算公式中的值是怎么得到的呢。管理模型流程上場，是這么走流程就可以得到。那這么流程怎么能保證讓各個部門一致的順利的走下來呢。好啦。管理軟件，水到渠成，客戶老板立馬拍板，誰拖延了上線就問誰的責任。

　　好的開端有了，就需要做實施的第一步，數據初始化。

　　做實施，在實施的前期，最大的時間消耗就在數據準備。這是一座信息化大樓的基礎啊。基礎出了問題，就會引起輸入的問題，更會引起輸出的問題。越發現的晚，以后調整的難度越大。我曾經遇見一個實施人員的案例，就是數據準備這塊沒做好，上線十來天才發現。最后他發現是他的問題，就自己偷偷改后臺數據，沒想到還改亂了，系統更是問題百出，客戶急了，他也慌了。最后緊急救場。但仍然有一部分數據已經錯誤很難對齊了，給企業帶來了當月財務處理核算很大的問題，我們不僅開除了員工，還給客戶賠了錢，真是損失慘重。

　　痛定思痛。

　　首先做的第一項決定就是嚴厲測試數據字典準備功能。每一個基礎數據錄入窗口界面，都各種邊界測試，非法字符測試，亂點亂按測試，刪除默認值測試，機器反應速度慢測試，突然斷網測試，突然斷電測試，嚴把數據口。有些基礎數據是互相關聯的，就要嚴格測試數據關聯性，保證前置數據沒有準備好，后續數據字典不準進入維護窗口。

　　第二步就是封鎖數據庫。把數據庫訪問權限嚴格控制。所有視圖、存儲過程加密。所有更新刪除插入語句留下日志審計，修改前修改后的字段信息日志。每條記錄的最后更新時間和更改人留下日志。停用標志的停用時間和停用人的日志。這樣增加了數據的安全性。

　　第三步，錯誤日志。一旦發現了沒有程序預先想到的處理的錯誤，就立即終止軟件，把軟件的錯誤界面快閃自動保存成GIF文件，真正內部錯誤，都保存下來，可以點擊按鈕通過網絡發送到公司報告。

　　我還專門組織編寫了數據準備手冊。詳細的數據準備操作流程，輸入輸入規范約束默認值不可為空不可重復等等都說明的很清楚。而且還給了一份清單，每通過一步，就打一個勾。如果這個清單上的列表，每項勾都打好了，說明數據準備階段就完成了。很清晰，很了解自己目前的工作進展。

　　其實，實施，做數據準備是非常耗費時間的。他們過去的數據用了那么多年，有很多重復，廢舊，編碼或命名不規范的數據。而且沒有人愿意做數據準備。因為基礎數據往往挺多，錄入就是個人工活，還要校對規格和價格，否則以后業務處理就有問題。

　　所以，實施人員一般去了才去整理過去的數據。說整理吧，人家過去的系統還不了解，又不是自己公司開發的。而且居然大多沒有文檔。數據結構根本不明白。就是根據數據瞎猜。

　　到了數據錄入階段吧，人都溜的賊快。反正你在現場，反正你著急回家，反正你的老板正焦急的催你上線節省費用早日上線早日催尾款。于是，只要自己一個人錄入一個人校對，其他人都在偷著樂。這種實施，真不是人干的活。怎么他們上線用軟件，他們自己不忙，實施人員倒是成了長工。唉，誰讓人家是出錢的呢。有錢就是娘啊。

　　現在，我力求實施人員能不去現場做數據準備就不去，給他們按照數據準備手冊按照流程給他們信息科培訓幾次，模擬操作幾遍，就回到公司，不會在那里繼續干耗。他們拖時間是他們自己拖。他們自己不想上線，他們的老板會找他們算帳。而且現在已經做的這么簡單安全穩定了，客戶的信息科他們都會自己根據安裝手冊做了。如果他們還懶還說不會，就說不過去了。

　　我的朋友開始限于思考狀態中。

　　做實施，在實施中期，最耗費時間的就是培訓。需要把人聚集起來，需要培訓教室，還需要定點，還需要組織人，還需要模擬練習的機器。這就很難辦了，業務部門是用戶使用者，但他們都在工作中，讓他們扔開工作來培訓，誰來接替他們的工作，大家都很忙。另外，培訓教室也是個事，那么多人需要培訓，即使按撥來，也好幾撥，哪有那么空閑的地方搞培訓教室。人還有時到不齊，還需要重復培訓。培訓一次，不會，還需要再次培訓。累啊。

　　針對這個問題，我們也想了招。這都是被迫了，老板要講究成本和時間和人力。你搞不定，你就下課。

　　我首先，讓培訓專員制作了培訓課程、培訓教材、培訓考試卷、模擬練習學習版軟件、視頻教學軟件。在沒有實施的時候就發下去光盤，讓他們自己看視頻看幫助看教材做練習。懶的看懶的學？可以，我還有培訓。

　　到了真正的培訓期，網絡教室管理軟件又派上了用場。他們每個機器都配個隨身聽那種耳機，隨便一個耳機就可以，街上批發有許多，花不了多少錢。我在信息科電腦跟前坐，他們在他們的電腦跟前坐，根本不用培訓教室，也不用他們離崗。他們的電腦一律顯示的是我的電腦的演示。我邊操作邊講。他們邊聽邊看。

　　在講的過程中，我也啟動了我機器上的錄像軟件。講完后，誰忘了聽或者有事或者沒聽懂，都可以重復看。

　　誰想浪費我的培訓苦心，隨便聽聽，把培訓當玩。我這里還有考試卷，考試打分。然后報給他們領導。而且還從中選出優秀者做業務標兵。這就很尷尬了。誰也不想當科室里的落后者。愛怎樣就怎樣的科員我還比較少見，因為現在的企業都不養閑人。

　　我的朋友眼睛開始閃光，興奮中。

　　做實施，后期最大的時間就花在了上線后的監控運行上。那個客戶端出現了問題，或者功能不會操作了，就需要立即趕去處理。由于上線后第一個星期，你正跑到18樓解決問題，4樓的用戶就給你打電話了，讓你去解決。剛解決好4樓，15樓的用戶又給你打電話了。你的手機不斷，揮汗如雨的奔忙在樓層之間，電梯人還多，每層都停，讓你累的半死一個上午也解決不了幾個問題。

　　現在網上很多免費的或收費很少的軟件，如網絡教室管理軟件，如網吧管理軟件，如遠程監控軟件很多。你給每個客戶端在裝PC的時候就都標配裝上。這樣，你以后就可以在信息科就可以掌控所有的計算機。那個計算機出了問題，你連接過去就看到了解決了，電話一交流，甚至內部IM系統一交流就全搞定了。

　　我的朋友不斷點頭稱好。

　　在項目的維護期，就涉及到版本更新的問題。尤其是有些行業客戶，需要你在實施過程中就修改需求定制化軟件，否則不修改完不讓上線，非要按照他們的習慣做才肯用，自然更新版本不斷。

　　而客戶端非常多，更新一次非常累。而且哪個更新了哪個忘了更新，更新的版本一致不一致，都會引起數據異常的問題，以后報表不平，查問題就很困難了。所以，為了更新，網上有很多局域網內文件同步軟件，可以設置定時監測更新，如中午吃飯的時候正好自動更新，也可以設置每次啟動計算機自動監測更新。你也可以用用。

　　我的朋友臉有點窘說：嗯，確實是個點子。我現在更新仍然需要一臺臺的安裝更新覆蓋。更新一次確實挺累。

　　我說：我現在已經改進的更好了了。直接在軟件中集成同步功能了。客戶端軟件一啟動的時候，先自動監測服務器上的版本一致不一致？如果不一致，就自動更新同步服務器上的軟件文件。但是客戶的局域網由于這權限那權限，網絡安全設置極為怪異，所以有時服務器數據庫能訪問，但就是無法訪問文件夾。這樣的情形我們的同步功能也考慮了，一旦檢測無法同步，會自動提示版本不一致，需要手工版本同步。就不允許他繼續登陸軟件繼續使用，否則他機器上的軟件還是舊的，BUG仍然沒有修復，他輸入進去的數據還可能是錯誤的，給后續的技術服務會帶來很多的困難。

　　我過去經常遇到這樣的情形：網絡管理員打來電話說版本更新了仍然軟件功能不好使。最后雙方爭論的很厲害，客戶支持部呢說他沒更新，網管說更新了。客戶支持部說再更新一次，可能更新時候有異常，網管說已經再次更新了。客戶支持部說：那我遠程支持連接看看。他說無法上網。只好出現場。如果這個客戶在海南島就慘了，成本居貴。去了一看，是有的更新了有的沒有更新。更新一次，OK，全搞定了。慘，3分鐘搞定的問題，卻花了飛機出差，也花費了大量客服支持人員找問題的時間，客戶滿意度還不行。

　　自從軟件有了同步和版本監測功能，客服支持電話少多了。而且由于一次機緣，客戶的服務器必須定時在線數據上傳，我們又利用這次機會，做了在線更新探測。我們一旦發現問題更新了軟件，就放到了我們的支持服務器上。客戶的服務器有駐留軟件定時探測，一旦發現有新更新，自動下載更新，可以更新數據庫，也可以更新文件。服務器更新完了，客戶端就會自動按照服務器的版本變化自動更新了。從此，客戶滿意度提高了不少。因為有的客戶還沒有發現那個BUG的時候，就已經被我們更新了。客服的工作更輕松了。

　　上線還有一個小竅門，這個也能幫助你縮短時間。這也是我的一個心得。

　　我記得我做燈塔客戶的時候，兩家客戶在不同的兩座城市，但是兩座城市比較近，2個多小時的路程。我實施完了A客戶，去了B客戶那里繼續實施。但是A客戶打了電話，說需要有些工作需要支持支持。我就去了。因為我已經實施他這家了，所以他也不好意思繼續用我。我來支持他們，也是一是人情二是近。于是我一去了他就問我這次能在他這里待多少時間。我說大概1天。于是，他會立即召集他的下屬，把平時積累的問題都拿了出來，非常配合也工作節奏非常快工作效率也非常高的完成了。如果我說大概能待3天，估計他的人影在第三天才能出現。這就是人的惰性，時間不催趕著他，他總覺得還有明天。

　　所以，如果你去上線實施，如果一開始不明確告訴所有人，你必須1月后離開，而且必須實施完畢，那么他們半年都上不了線，即使上了線也是用的松松垮垮。如果限定項目時間，努力奔著這個時間，而且限定好項目此階段著重解決的三個問題，他們就會工作節奏快的多。注意，不限定項目邊界，項目時間目標都是假的，很容易就超過項目時間，再想遵守項目時間就很難了。

　　我過去還實施過一家客戶，沒有實施前就是個松松垮垮的企業。小城市，人們中午11點下班后還回家買菜做飯，不像北京大城市中午回不去必須吃工作餐。他們還有午休時間。所以，小城市的生活是安逸的。但是我想快速實施。我早就準備好了很多項目過程管理表格和項目進度匯報流程。一去了，各種表格方法一拿出來，他們一看，來的人非常專業，混是不好混的，于是心情揣揣不安看我會如何。我每天郵件報告給我的老板、他的老板、項目涉及到的每個人，通報今天的工作內容和明天的工作計劃。本來大家都覺得很難啃的一個客戶，被我按計劃時間完成。大家都一開始笑稱我需要在那里買套房安家才能實施完，沒想到我這么快。

　　這個案例就說明，你自己得過且過不正規，別人更就不把你當回事。你舉止文雅談吐內涵，別人也不好意思在你面前大放厥詞。

　　我的朋友很尷尬的說：我服了你了。我實施多年，也沒有想出你這么多招。總覺得什么都動不了。這些方法我們現在一個都沒有用。如果用了，我相信能縮短現在一半實施周期。縮短了周期，就能減少成本。成本低了，利潤就高了。

　　我說：我也是沒有辦法，老板逼的，老板向我要效益啊。人在壓力中，自然就能想出辦法。你如果覺得無法突破，那么你真的就無法突破了。我就是由于不相信這個老規矩就破除不了，所以就大膽思考大膽嘗試，最后還真管用。這些方法不僅僅能降低成本。你實施周期短了，你可以實施更多的客戶，這是一個開源節流的好方法。企業利潤，不外乎多賺錢，少花錢。我全辦到了。