只知有淮，不知有濟：軟體作品，軟體項目，軟體產品—軟體產品是怎麼做出來的？

我在很年青的時候，喜歡上了寫代碼。

你知道嗎，軟體真的是個好東西，而寫軟體可以說是好上加好的事情。在軟體的世界裡，只要你願意，你就可以嘗試各種你腦子裡的想法。我們那時候的電腦最初是IBM 4381聯機分時系統，後來有了PC機，8088系列的，只是到後來才有了286、386等。編程語言嘛，最早學的是FORTRAN，然後是彙編，後來又重學BASIC，然後有了PASCAL，C，C十十等；當然還有當時的形式邏輯語言LISP。CORBA，ADA等也是那時候學的。我們給老師們幹活，除了可以掙點喝酒吃肉的錢以外，更主要的是可以免費有電腦用。我那時寫代碼完成過某型飛機的翼面翼型計算，也寫過小遊戲，小小的知識庫系統等。於是，很自然地，就想將來成為軟體編程高手。當然啦，那時的自己，也有些飄飄然，覺得自己也寫過若干軟體了，覺得自己離高手也應該不遙遠了。當然，那時候腦子裡還完全沒有軟體產品的概念。

到大學三年級的時候，要選專業方向。很自然地，我應該選計算機科學方向。但是，天捉弄人，我的某些科目的成績不夠好，不能夠去讀計算機科學。於是，只好退而求其次，選擇了CAD/CAM方向，就是傳說中的計算機輔助設計和製造。但說實話，那時的我對設計、尤其是製造其實並無多大興趣，真正看中這個方向的是，讓我覺得炫酷的計算機圖形學。

很快地，我覺得我歪打正著，選對了。在CAD/CAM這個方向，我接觸到了PDP，CDC，VAX，DEC，SGI等等機器。這些都是我的哥們兒在計算機科學系的實驗室里幾乎見不到的機器。那種感覺，就像是農村的孩子進了城，在鄉下鶴立雞群的感覺，很快被目不暇給的喜悅和興奮拋到了腦後。

於是，為了掙到儘可能多的接觸這些機器的機會，我更多地給老師幹活，並最終拿到了一個國防預研項目的技術領導的職責，可以天天霸著這些機器盡情地擼代碼。當然，同時還得驅動整個項目的技術進程。

這一干就是5年多。項目得了航空部的獎，國家的獎，似乎也是比較成功。真正更開心的是，我們寫出來的軟體，真正產生了我們看得到的影響和價值，是至今會想起來都會自豪淚目的團隊成績。我出了學校，進企業開始工作了；但心裡卻還是有些失落，因為這麼多年的時間，雖然我覺得自己讀了很多書，卻幾乎還沒能真正花上我認為的最少的時間，去做我最初喜歡的計算機圖形學，尤其是真實感圖形學的工作。

但很快，學校做項目的積累，讓我在工作中很快上手，並嶄露頭角。於是，飄飄然的感覺沖走了最初的失落。隨著時間的推移，覺得自己是高手的感覺慢慢又爬了出來，覺得自己帶團隊能做出真正的軟體了，應該是能做軟體產品的人了。

直到我來到了現在的公司。

下定決心一定要到現在的公司工作至少一段時間，是在面試準備的過程中決定的。在開始準備前，我自認為對java, j2ee等還是有不錯的水平。為了讓自己的面試顯得更有水平和分量，我從被通知面試的那一刻，就開始準備，就像當初在學校準備考試一樣。我去公司的程序員論欄下載他們的應用伺服器安裝包，準備在上面做個東西作為投名狀。

但是，就是這個安裝包的下載過程，我就被深深地震撼了。我折騰了差不多三天三夜，才把80G多的安裝包整下來。為這個，我還專門跑去電腦城買了塊大容量硬碟。整個過程就是N多草泥馬從心底飆過的感覺，腦子裡不知道念了多少遍「這是什麼鬼，要搞這麼大」。

終於，我把80G多的「鬼」整了下來，安裝好，準備從經典的「Hello, World!"開始。原打算用個半天、一天對世界說hello，結果又是差不多3天被折騰了進去；過程中深深的挫敗感無需多說。但同時，折騰的這三天，我開始有些感覺到這個「鬼」的強大。於是，對世界說完hello後，我用了一天多的時間，構造了一個小小的場景故事，然後又用了兩天左右，把原型做出來，可以跑給面試官看了。這個過程的感受，比我當初剛進CAD/CAM實驗室，看到PDP等那些機器還要洗腦：這個「鬼」體積龐大，複雜難懂；但當我開始懂它的時候，我甚至覺得j2ee伺服器也不過如此。於是，我說我一定要去這家公司工作，看看這個「鬼」是怎麼做出來的。

到今天，我在這家公司已經工作馬上就12年了。我依舊不敢說，我已經清楚了這個「鬼」是怎麼做出來的。但回頭看自己碼代碼、寫軟體的經歷，有幾個詞，或者說幾個概念值得弄清楚；釐清這些概念，對理解軟體產品怎麼做出來的應該會有啟發性的思考：

軟體作品

軟體項目

軟體產品

我那些一個人獨立寫成的東東，甚至和小夥伴們一起寫著玩兒的東東，只能被歸類為軟體作品，不管我自認為寫得多麼牛叉。這些東東既不能被稱為軟體項目，更不能被稱為軟體產品。

來這家公司之前，和大家一起協同，為了特定的stakeholder，為了一個特定的業務目標，寫成的東東，可以被稱為軟體項目。這已經不是軟體作品了，已經上了一個台階了。

那什麼才能被稱為軟體產品呢？我覺得至少得滿足以下幾個要求：

要有眾多用戶。這主要是確定在一定的domain邊界內的功能需求的多樣性。

只能是一套代碼來實現定義邊界內的功能，滿足這眾多客戶的不同需求。那種「if cusomer = A...『的代碼實現，最多能叫軟體項目，不能叫軟體產品。

一致的服務支持定義和質量。

細細想一下，如果單從技術層面來看，第二個要求，就足以讓很多很多市面上稱為軟體產品的東東被踢出軟體產品的範圍去。

另外一些有趣的問題是：

在軟體項目或者軟體產品開發中，有程序員把它當成了展示自己技術很牛叉的地方。所以，事實上，這些程序員們把一個軟體項目或軟體產品當成，或者綁架成了自己的軟體作品，哪怕是局部的。

混淆軟體項目和軟體產品的邊界：要求產品承擔項目的責任；希望項目有產品的能力。

只知有淮，而不知有濟。這或許是我們軟體產品研發能力提升緩慢的一個認知和執行層面的問題了？我自己相信，當我們靜心來思考，什麼是軟體產品的時候，關於「軟體產品是怎麼做出來的」這個問題，我們就已經拿到了打開答案的殿堂之門的鑰匙，不管是技術層面的，工程層面的，還是組織結構，流程層面的...

如果，我們碼出來的代碼，寫出來的軟體，不是用來解決問題的，而只是用來炫技的，那我們喜歡的究竟又是軟體的什麼？

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！