2011/03/03
導讀：現在很多開發人員還沒有學會市場思維，仍像是象牙塔裡的學生那樣，保持着學生思維。事實上，軟體工程更接近于經濟學，而非計算機科學，需要開發人員具備市場思維。
世上無易事
要是我問你，跑百米容易還是跑馬拉松容易？這還用問！當然是跑百米容易了，是吧？其實我想問的是：亞洲運動員要拿奧運冠軍，是跑百米容易還是跑馬拉松容易？答案似乎就颠倒過來了。近鄰南韓和日本都已經出過奧運馬拉松冠軍，比起拿百米冠軍，機率要大多了。
當我們從市場競争的視角去看問題的時候，容易的事情就變得不容易了。不過，很多開發人員還沒有學會市場思維，還是保持着學校裡的學生思維。在此舉幾個場景為例，這些場景在我為不同團隊提供服務時發生過很多次，令我印象深刻。
在給某機關做一個項目時，開發人員A自作主張加進去一些用例。我認為這些用例和客戶的願景關系不大，可以去掉。A反問道：如果做一個通用的産品在市場上賣呢？
“如果”——開發人員很喜歡用這個學生味十足的詞。是否做通用産品，這可是一個重大的商業決策，開發人員卻認為将這個系統變成通用産品拿到市場上賣（目标客戶變了）是一件輕而易舉的事情。事實上，這涉及到整個願景的轉變，甚至公司戰略的轉變，而且需求受影響的可能不隻是目前這個系統。市場是殘酷的，誰吃肉誰喝西北風，可不能随便“如果”。少說一些“如果”，多做一些調研吧！看看客戶的老大什麼意思，自家老總什麼意思，市場的戰局如何，盡量向最佳答案靠攏。
開發人員B在寫某信貸風險系統的願景時寫道：本系統的目标是，銀行風險部能夠對貸款做風險評估。我問道：難道銀行以前不能做風險評估嗎？B認真地回答：不能啊，有我們的系統才行！
很多時候我們把自己開發的系統（噢，對，現在流行叫××平台了）想得太牛了，以為沒有我們的系統，業務組織就玩不轉了。其實，我們開發的系統隻是組織裡面的小零件，群組織廁所裡的馬桶沒有本質差別。組織裡面還有很多系統，其中最值錢的是千百年來一直在使用、現在依然是最複雜的系統——人肉系統，它由“父母公司”開發、“老師公司”不斷更新、公司以每月每人幾千上萬的租金租用。是以，有時為了抵消開發人員這種“緻命的自負”，我會故意将“系統”稱為“馬桶”——你做這個馬桶是幹什麼的？
我和開發人員C聊天。我問：你最近做什麼項目？C回答：我在做一個Java項目。
對嗎？對的！這個項目對于開發人員C來說确實就是一個“Java項目”，因為他不關心項目的核心領域是醫院、物流還是保險，他隻關心這個項目能不能提升他的Java技能、對以後的職業生涯有無幫助，是以他把這個項目叫做“Java項目”十分正确。可惜，這是從開發人員的角度看問題，而沒有從客戶的角度看問題。并不隻是剛參加工作的Java程式員會這樣回答，有一次，我問一位有将近十年開發工作經驗的架構師最近做什麼項目，架構師回答：在做一個資料倉庫項目。繼續聊下去，我才知道其實他做的是某通信公司的客戶關系管理系統，裡面用到了資料倉庫，而資料倉庫的知識恰好是他比較缺乏而且感興趣學習的，是以他幹脆把這個項目稱為“資料倉庫項目”了！
開發人員D喜歡鑽研“底層”，明明配置設定給他的工作是編寫一段計費的C#代碼，他偏偏要花時間深入研究到編譯器、作業系統甚至硬體，而且确實也搞清楚了一些門道。雖然工作是耽擱了，但D獲得了“勤奮好鑽研”的名聲。
其實軟體開發還有另一個更值得鑽研的“底層”：怎樣才能使這段代碼更容易維護和擴充？這段代碼達到的功能和性能對涉衆意味着什麼？……過分熱衷于鑽研“底層”，我認為這樣的行為更像是偷懶而不是勤奮，畢竟比起離開電腦去搞清楚質管部和生産部之間有什麼利益上的沖突，研究MSIL的文法要容易得多、愉快得多。我們不要忘記，能帶來利潤的是另一個更深不可測的“底層”——藏在涉衆心底裡的各種希望和擔心。
兩個底層
和“底層”一樣帶着光環的是“技術”一詞，有趣的是，不少開發人員說到“技術”的時候，含義就是“我懂得或感興趣的那點東西”，不懂且不感興趣的就稱為“業務”。例如，開發部的程式員認為“Java編碼是技術，産品部那幫需求人員做的是業務”；産品部的需求人員則認為“我做的是技術，客戶那幫報關員做的才是業務”；報關員也會說“Kao！我做的當然是技術，我薪水比你還高呢”。是以，我經常用“核心域”、“非核心域”來代替“業務”、“技術”。
計算機科學不是軟體工程
造成以上問題的根源，我認為部分原因來自開發人員對計算機科學和軟體工程的差別認識不清。軟體工程和計算機科學的關鍵差別在于人。軟體是為人開發的，是以我們要做需求；軟體是由人開發的，是以我們要做設計。考慮到人的因素，軟體工程更接近于經濟學，而非計算機科學。“程式員”這個職業，軟體工程的成分要比計算機科學的成分大。
現在的大學計算機教育，基本還是以教授計算機科學為主，所教的軟體工程僅是聊勝于無。這本來也沒什麼問題，畢竟象牙塔裡的教授要教出好的軟體工程也不容易，開發人員還是要在業界曆練學習。不過，因為軟體工程看起來沒有計算機科學那麼“深奧”，開發人員常會誤認為某人隻要對計算機科學的某個領域有一定研究，他對軟體工程所發表的見解也一定是有道理的！這時問題就大了。
事實上，以我的所見所聞，即使是拿到了名校計算機專業的碩士、博士學位，又在著名IT公司的研究院做研究多年，一張口仍然是“軟體工程盲”的人士，并不鮮見。上海的張恂先生2002年曾經和我一起寫作《駁UML三大“硬傷”論》，這些年，張先生一直高舉軟體工程大旗，多次批駁過類似的現象。
同樣作為一名軟體工程的研究者，我沒有輕視計算機科學研究的意思，隻是稍作提醒其中的差別，雙方的研究者應該互相尊重。
因篇幅所限，先談到這裡。後面我将從執行者和用例開始，談談裡面的市場思維——“小人圈圈不簡單”。
作者簡介：
潘加宇，UMLChina首席專家。1999年建立UMLChina，潛心研究需求和設計技能。2002年開始對外提供UML需求和設計的技術指導和訓練服務