世上無易事

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

　　有了上面這個(gè)問題墊底，你應(yīng)該可以猜到下面這個(gè)問題的意圖：現(xiàn)在開發(fā)軟件容易還是二十年前開發(fā)軟件容易？現(xiàn)在的軟件開發(fā)是可視化編程，就著框架搭積木，看起來容易多了。可惜，當(dāng)我們的問題變成：通過開發(fā)軟件來賺錢，比起二十年前是不是變得更容易了？答案也顛倒過來了。門檻的降低使得競(jìng)爭(zhēng)者大量涌入，拉低了軟件公司的利潤和程序員的入職薪水，更要命的是，客戶的胃口變得越來越大。二十年前，史玉柱在《計(jì)算機(jī)世界》登一個(gè)廣告“M6401，歷史性的突破”，然后就可以等到訂單，這樣的成功現(xiàn)在還能復(fù)制嗎？

　　當(dāng)我們從市場(chǎng)競(jìng)爭(zhēng)的視角去看問題的時(shí)候，容易的事情就變得不容易了。不過，很多開發(fā)人員還沒有學(xué)會(huì)市場(chǎng)思維，還是保持著學(xué)校里的學(xué)生思維。在此舉幾個(gè)場(chǎng)景為例，這些場(chǎng)景在我為不同團(tuán)隊(duì)提供服務(wù)時(shí)發(fā)生過很多次，令我印象深刻。

　　在給某單位做一個(gè)項(xiàng)目時(shí)，開發(fā)人員A自作主張加進(jìn)去一些用例。我認(rèn)為這些用例和客戶的愿景關(guān)系不大，可以去掉。A反問道：如果做一個(gè)通用的產(chǎn)品在市場(chǎng)上賣呢？

　　“如果”——開發(fā)人員很喜歡用這個(gè)學(xué)生味十足的詞。是否做通用產(chǎn)品，這可是一個(gè)重大的商業(yè)決策，開發(fā)人員卻認(rèn)為將這個(gè)系統(tǒng)變成通用產(chǎn)品拿到市場(chǎng)上賣（目標(biāo)客戶變了）是一件輕而易舉的事情。事實(shí)上，這涉及到整個(gè)愿景的轉(zhuǎn)變，甚至公司戰(zhàn)略的轉(zhuǎn)變，而且需求受影響的可能不只是當(dāng)前這個(gè)系統(tǒng)。市場(chǎng)是殘酷的，誰吃肉誰喝西北風(fēng)，可不能隨便“如果”。少說一些“如果”，多做一些調(diào)研吧！看看客戶的老大什么意思，自家老總什么意思，市場(chǎng)的戰(zhàn)局如何，盡量向最佳答案靠攏。

　　開發(fā)人員B在寫某信貸風(fēng)險(xiǎn)系統(tǒng)的愿景時(shí)寫道：本系統(tǒng)的目標(biāo)是，銀行風(fēng)險(xiǎn)部能夠?qū)J款做風(fēng)險(xiǎn)評(píng)估。我問道：難道銀行以前不能做風(fēng)險(xiǎn)評(píng)估嗎？B認(rèn)真地回答：不能啊，有我們的系統(tǒng)才行！

　　很多時(shí)候我們把自己開發(fā)的系統(tǒng)（噢，對(duì)，現(xiàn)在流行叫××平臺(tái)了）想得太牛了，以為沒有我們的系統(tǒng)，業(yè)務(wù)組織就玩不轉(zhuǎn)了。其實(shí)，我們開發(fā)的系統(tǒng)只是組織里面的小零件，和組織廁所里的馬桶沒有本質(zhì)區(qū)別。組織里面還有很多系統(tǒng)，其中最值錢的是千百年來一直在使用、現(xiàn)在依然是最復(fù)雜的系統(tǒng)——人肉系統(tǒng)，它由“父母公司”開發(fā)、“老師公司”不斷升級(jí)、公司以每月每人幾千上萬的租金租用。所以，有時(shí)為了抵消開發(fā)人員這種“致命的自負(fù)”，我會(huì)故意將“系統(tǒng)”稱為“馬桶”——你做這個(gè)馬桶是干什么的？

　　我和開發(fā)人員C聊天。我問：你最近做什么項(xiàng)目？C回答：我在做一個(gè)Java項(xiàng)目。

　　對(duì)嗎？對(duì)的！這個(gè)項(xiàng)目對(duì)于開發(fā)人員C來說確實(shí)就是一個(gè)“Java項(xiàng)目”，因?yàn)樗魂P(guān)心項(xiàng)目的核心領(lǐng)域是醫(yī)院、物流還是保險(xiǎn)，他只關(guān)心這個(gè)項(xiàng)目能不能提升他的Java技能、對(duì)以后的職業(yè)生涯有無幫助，所以他把這個(gè)項(xiàng)目叫做“Java項(xiàng)目”十分正確。可惜，這是從開發(fā)人員的角度看問題，而沒有從客戶的角度看問題。并不只是剛參加工作的Java程序員會(huì)這樣回答，有一次，我問一位有將近十年開發(fā)工作經(jīng)驗(yàn)的架構(gòu)師最近做什么項(xiàng)目，架構(gòu)師回答：在做一個(gè)數(shù)據(jù)倉庫項(xiàng)目。繼續(xù)聊下去，我才知道其實(shí)他做的是某通信公司的客戶關(guān)系管理系統(tǒng)，里面用到了數(shù)據(jù)倉庫，而數(shù)據(jù)倉庫的知識(shí)恰好是他比較缺乏而且感興趣學(xué)習(xí)的，所以他干脆把這個(gè)項(xiàng)目稱為“數(shù)據(jù)倉庫項(xiàng)目”了！

　　開發(fā)人員D喜歡鉆研“底層”，明明分配給他的工作是編寫一段計(jì)費(fèi)的C#代碼，他偏偏要花時(shí)間深入研究到編譯器、操作系統(tǒng)甚至硬件，而且確實(shí)也搞清楚了一些門道。雖然工作是耽擱了，但D獲得了“勤奮好鉆研”的名聲。

　　其實(shí)軟件開發(fā)還有另一個(gè)更值得鉆研的“底層”：怎樣才能使這段代碼更容易維護(hù)和擴(kuò)展？這段代碼達(dá)到的功能和性能對(duì)涉眾意味著什么？……過分熱衷于鉆研“底層”，我認(rèn)為這樣的行為更像是偷懶而不是勤奮，畢竟比起離開電腦去搞清楚質(zhì)管部和生產(chǎn)部之間有什么利益上的沖突，研究MSIL的語法要容易得多、愉快得多。我們不要忘記，能帶來利潤的是另一個(gè)更深不可測(cè)的“底層”——藏在涉眾心底里的各種希望和擔(dān)心。

兩個(gè)底層

　　和“底層”一樣帶著光環(huán)的是“技術(shù)”一詞，有趣的是，不少開發(fā)人員說到“技術(shù)”的時(shí)候，含義就是“我懂得或感興趣的那點(diǎn)東西”，不懂且不感興趣的就稱為“業(yè)務(wù)”。例如，開發(fā)部的程序員認(rèn)為“Java編碼是技術(shù)，產(chǎn)品部那幫需求人員做的是業(yè)務(wù)”；產(chǎn)品部的需求人員則認(rèn)為“我做的是技術(shù)，客戶那幫報(bào)關(guān)員做的才是業(yè)務(wù)”；報(bào)關(guān)員也會(huì)說“Kao！我做的當(dāng)然是技術(shù)，我薪水比你還高呢”。所以，我經(jīng)常用“核心域”、“非核心域”來代替“業(yè)務(wù)”、“技術(shù)”。

　　計(jì)算機(jī)科學(xué)不是軟件工程

　　造成以上問題的根源，我認(rèn)為部分原因來自開發(fā)人員對(duì)計(jì)算機(jī)科學(xué)和軟件工程的區(qū)別認(rèn)識(shí)不清。軟件工程和計(jì)算機(jī)科學(xué)的關(guān)鍵區(qū)別在于人。軟件是為人開發(fā)的，所以我們要做需求；軟件是由人開發(fā)的，所以我們要做設(shè)計(jì)。考慮到人的因素，軟件工程更接近于經(jīng)濟(jì)學(xué)，而非計(jì)算機(jī)科學(xué)。“程序員”這個(gè)職業(yè)，軟件工程的成分要比計(jì)算機(jī)科學(xué)的成分大。

　　現(xiàn)在的大學(xué)計(jì)算機(jī)教育，基本還是以教授計(jì)算機(jī)科學(xué)為主，所教的軟件工程僅是聊勝于無。這本來也沒什么問題，畢竟象牙塔里的教授要教出好的軟件工程也不容易，開發(fā)人員還是要在業(yè)界歷練學(xué)習(xí)。不過，因?yàn)檐浖こ炭雌饋頉]有計(jì)算機(jī)科學(xué)那么“深?yuàn)W”，開發(fā)人員常會(huì)誤認(rèn)為某人只要對(duì)計(jì)算機(jī)科學(xué)的某個(gè)領(lǐng)域有一定研究，他對(duì)軟件工程所發(fā)表的見解也一定是有道理的！這時(shí)問題就大了。

　　事實(shí)上，以我的所見所聞，即使是拿到了名校計(jì)算機(jī)專業(yè)的碩士、博士學(xué)位，又在著名IT公司的研究院做研究多年，一張口仍然是“軟件工程盲”的人士，并不鮮見。上海的張恂先生2002年曾經(jīng)和我一起寫作《駁UML三大“硬傷”論》，這些年，張先生一直高舉軟件工程大旗，多次批駁過類似的現(xiàn)象。

　　同樣作為一名軟件工程的研究者，我沒有輕視計(jì)算機(jī)科學(xué)研究的意思，只是稍作提醒其中的區(qū)別，雙方的研究者應(yīng)該互相尊重。

　　因篇幅所限，先談到這里。后面我將從執(zhí)行者和用例開始，談?wù)劺锩娴氖袌?chǎng)思維——“小人圈圈不簡單”。

　　作者簡介：

　　潘加宇，UMLChina首席專家。1999年創(chuàng)建UMLChina，潛心研究需求和設(shè)計(jì)技能。2002年開始對(duì)外提供UML需求和設(shè)計(jì)的技術(shù)指導(dǎo)和訓(xùn)練服務(wù)

it知識(shí)庫：做有市場(chǎng)思維的開發(fā)人員，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。