本文僅從技術的角度討論這個問題，不涉及其他諸如人員素質、經濟、法律等各個方面。
計算機工業發展的過程中，出現了許多思想、方法和技術——結構化程序設計、可移植性、跨平台、面向對象分析和設計、UML、COM、CORBA、可重用性、LINUX、軟件工程、TCP/IP、三網合一、互連、電子商務、DCE。那麼，這些思想、方法、技術是如何產生的？
作者對此進行了自己的分析和總結。簡單地說，就是我們在利用計算機解決問題的過程中，遇到了許多新問題，隨之也就產生了這些思想、方法和技術。我們所遇到的問題分布在四個領域——問題域、解題域、計算機域、項目管理域，它們之間互相促進，相互制約。
我們中國人為什麼在其中的貢獻微不足道？我們該怎麼辦呢？
作者認為，只要將上述四個領域的問題分析清楚，也就從技術上找到了答案。
1． 問題域
這個方面需要專門的知識，計算機人員非常不熟悉，必須需要相關人員的幫助。
通用問題當然有通用解，但是問題都有特殊的一面，不能一概而論，所謂隔行如隔山。如何解決呢？就是將問題分類，所謂的領域工程、面向對象中的設計模式就是這個思路。我們常用的模板也是這個思路。總之，積累是必要的。
每個公司都有自己的定位問題，如何選擇合適的問題領域至關重要。
我們承認，我們現在落後，但是只要我們努力，通過充分的積累，我們會趕上的。
2． 解題域
這個領域最需要人的創造性勞動，需要領域專業人員和計算機人員共同努力。
關鍵是數學模型問題。這個不是所謂的OO、UML可以解決的，它們充其量提供了一個輔助表達的方法。
所以我們現在的高等教育強調數學的基礎地位是非常重要和必須的。
不過，通過專門的訓練可以提高我們建立數學模型的能力。
作者有這樣一個問題：是否可以建立一套可行的規則，幫助相關人員建立數學模型，就想解微積分似的？
3． 計算機域
計算機域的問題是計算機工作者的重點，它的實質就是在問題和解決問題的產品之間搭起橋梁，從問題——UML——COMPILER——OS——IC——到產品就是這個思路的體現；當我們的生產積累達到一定程度、所解決的問題越來越復雜時，必然要求搭積木似的生產方式，所謂的CORBA、DCOM、軟件總線、構件等等，就是這個思路的體現；我們可以設想，下一步的發展就是模塊（構件、零件）智能化，就象現在所謂的柔性制造一樣。
如果想讓各個公司的產品能夠搭集成新的產品，這些產品必須遵循標准。誰掌握了標准，誰就成功了。CORBA與DCOM之爭、JAVA論戰、LINUX與WINDOWS之爭，起因就在這裡。不過，我想說一句心裡話，這些公司的產品真能互相交互嗎？這大概是一個夢想。ORACLE的CEO就說，我們這裡什麼都有，全用我們的吧，他們的集成性能更好。
那麼，我們該怎麼辦呢？突破點在那裡？
4． 項目管理域
要想好快省地作出一個產品，滿足客戶的需求，沒有必要的管理是無法想象的。
項目管理包括人員組織搭配、設備材料管理、資金管理、進度計劃制定和控制四個方面。
從人員的角度講，有人說項目經理可以不懂技術。作者不感贊同，起碼這會給溝通造成困難。
從設備材料管理講，必須注意降低成本，有效地管理和使用是關鍵。NOKIA成功的關鍵一點就是成本控制。
資金的流入和流出必須有計劃並受到相關制度的控制。
進度控制是最難的。原因包括項目需求的頻繁變動，創造性勞動的不可預期性等。
計算機產品的生產管理有它內在的規律，肯定不同於傳統行業的生產管理，需要我們進一步在實踐中總結經驗。企圖全盤照搬其他行業的做法，是肯定行不通的。必須充分考慮到創造性勞動的特殊性，包括對人員組織的影響、對資源使用的影響、對進度計劃控制的影響。
5． 人類的夢想
人類失去夢想，這個世界就會死氣沉沉。
我們設想這樣一個智能助手。
我們的銀行信息系統需要升級。作為系統管理員，我告訴智能助手，我們需要在本周將這個任務完成，具體任務內容在某某文件中，具體工作由它負責，遇到問題要向我匯報。
這下子，智能助手忙壞了。它首先聯系系統中所有的實體，問問它們目前所使用的信息系統，什麼時候有空升級等等情況。然後制訂了一個升級計劃，包括兩個應急措施。
當工作開始後，智能助手發現。。。。。。
這是我所設想的分布式計算的高級目標。
6． 我們究竟需要什麼
有人說，我們目前的水平需要提高，畢竟老外已經先我們走了幾十年。
有人說，看看印度、愛爾蘭，我們需要的是管理。
有人說，我們太浮躁了，沒有能夠腳踏實地。
我想補充一點——科學的精神。就是當我們碰到問題的時候，要用科學的眼光看待它，要用科學的方法解決它。
從五四運動到現在，有很多年了。但是五四精神，依然離我們很遠。就從現在做起吧！就從你我做起吧！
注：
1. 你可以隨意處理這份文檔，包括修改、復制、分發。
2. 作者水平有限，歡迎大家批評指正。即使惡毒攻擊，我也歡迎。
3. 我的聯系方式
E_MAIL：[email protected]