導讀：現在很多開發人員還沒有學會市場思維，仍像是象牙塔裡的學生那樣，保持著學生思維。事實上，軟體工程更接近於經濟學，而非電腦科學，需要開發人員具備市場思維。
世上無易事
要是我問你，跑百米容易還是跑馬拉松容易？這還用問！當然是跑百米容易了，是吧？其實我想問的是：亞洲運動員要拿奧運冠軍，是跑百米容易還是跑馬拉松容易？答案似乎就顛倒過來了。近鄰韓國和日本都已經出過奧運馬拉松冠軍，比起拿百米冠軍，概率要大多了。
有了上面這個問題墊底，你應該可以猜到下面這個問題的意圖：現在開發軟體容易還是二十年前開發軟體容易？現在的軟體開發是視覺化程式設計，就著框架搭積木，看起來容易多了。可惜，當我們的問題變成：通過開發軟體來賺錢，比起二十年前是不是變得更容易了？答案也顛倒過來了。門檻的降低使得競爭者大量湧入，拉低了軟體公司的利潤和程式設計師的入職薪水，更要命的是，客戶的胃口變得越來越大。二十年前，史玉柱在《計算機世界》登一個廣告“M6401，歷史性的突破”，然後就可以等到訂單，這樣的成功現在還能複製嗎？
當我們從市場競爭的視角去看問題的時候，容易的事情就變得不容易了。不過，很多開發人員還沒有學會市場思維，還是保持著學校裡的學生思維。在此舉幾個場景為例，這些場景在我為不同團隊提供服務時發生過很多次，令我印象深刻。
在給某單位做一個專案時，開發人員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需求和設計的技術指導和訓練服務
Via：《程式設計師》