世上無易事

　　要是我問你，跑百米容易還是跑馬拉松容易？這還用問！當然是跑百米容易了，是吧？其實我想問的是：亞洲運動員要拿奧運冠軍，是跑百米容易還是跑馬拉松容易？答案似乎就顛倒過來了。近鄰韓國和日本都已經出過奧運馬拉松冠軍，比起拿百米冠軍，概率要大多了。

　　有了上面這個問題墊底，你應該可以猜到下面這個問題的意圖：現在開發軟件容易還是二十年前開發軟件容易？現在的軟件開發是可視化編程，就著框架搭積木，看起來容易多了。可惜，當我們的問題變成：通過開發軟件來賺錢，比起二十年前是不是變得更容易了？答案也顛倒過來了。門檻的降低使得競爭者大量涌入，拉低了軟件公司的利潤和程序員的入職薪水，更要命的是，客戶的胃口變得越來越大。二十年前，史玉柱在《計算機世界》登一個廣告“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需求和設計的技術指導和訓練服務

it知識庫：做有市場思維的開發人員，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。