功能模塊、業(yè)務(wù)架構(gòu)、需求分析、用戶需求、系統(tǒng)分析、功能設(shè)計(jì)、詳細(xì)設(shè)計(jì)、文檔、業(yè)務(wù)、技術(shù)……很多被隨口使用的名詞，其實(shí)是含糊甚至錯(cuò)誤的。

到底含糊在哪里，錯(cuò)誤在哪里，不僅僅是新手軟件開(kāi)發(fā)人員糊涂，許多入行多年的老手也一樣。雖然很多老手功成名就，掛著CTO、總架構(gòu)師等研發(fā)線的最高頭銜，但是心里對(duì)這些概念也是一團(tuán)漿糊。

可能有的人會(huì)說(shuō)，不會(huì)吧，這些牛人帶團(tuán)隊(duì)做出了讓公司賺錢的系統(tǒng)，怎么會(huì)不清楚呢，只不過(guò)表達(dá)出來(lái)和你的表達(dá)不同而已吧？我只能很誠(chéng)懇地再說(shuō)一遍：很多“牛人”真的不清楚。當(dāng)然，搞不清楚不妨礙做出賺錢的系統(tǒng)，就像有的人不了解人體運(yùn)行機(jī)制憑感覺(jué)也活到了一百歲。您也可以說(shuō)“做出過(guò)賺錢的系統(tǒng)就行了唄，管他清楚不清楚呢！”，對(duì)對(duì)對(duì)，您說(shuō)的都對(duì)，但不清楚也還是不清楚。

我先說(shuō)一下我在《軟件方法》一書(shū)中對(duì)軟件建模工作流的劃分：

軟件開(kāi)發(fā)的一個(gè)迭代周期中需要思考四個(gè)問(wèn)題，即四個(gè)工作流：

A-業(yè)務(wù)建?！ㄎ恍枰倪M(jìn)的目標(biāo)組織（人群或機(jī)構(gòu)）以及該組織接下來(lái)最需要改進(jìn)的問(wèn)題。

B-需求——描述為了改進(jìn)組織的問(wèn)題，所引入的信息系統(tǒng)必須具有的表現(xiàn)。

C-分析——提煉為了滿足功能需求，所引入的信息系統(tǒng)需要封裝的核心域機(jī)制。

D-設(shè)計(jì)——考慮質(zhì)量需求和設(shè)計(jì)約束，將核心域機(jī)制映射到選定非核心域上實(shí)現(xiàn)。

如圖1。

圖1 四個(gè)工作流

以上四個(gè)工作流的名稱使用了傳統(tǒng)術(shù)語(yǔ)，也有一定的模糊性（特別是業(yè)務(wù)建模）。更貼切的名稱是組織建模、需求建模、核心域建模、實(shí)現(xiàn)。如果您覺(jué)得業(yè)務(wù)建模、需求、分析、設(shè)計(jì)不好，直呼ABCD或改成阿豬、阿狗、阿雞、阿鴨也無(wú)所謂。

針對(duì)這些工作流的思考，其實(shí)就是建模。任何一個(gè)軟件項(xiàng)目，這些思考都是逃不掉的，也就是說(shuō)，我們一直在建模，只不過(guò)很多人習(xí)慣于無(wú)意識(shí)地做，運(yùn)氣時(shí)好時(shí)壞，速度時(shí)快時(shí)慢，有的人能夠有意識(shí)地做，讓汗水不白流。

思考的結(jié)果，可以用口頭表達(dá)，也可以用文本、其他表示法或自造符號(hào)來(lái)表達(dá)。用UML來(lái)表達(dá)，目前是一種不壞的做法。如果用UML表達(dá)，推薦的用法如圖2?？梢钥吹?，工作流D可以不需要用UML表達(dá)。

圖2 各工作流思考內(nèi)容和推薦表達(dá)

再說(shuō)一下核心域和非核心域的概念。一個(gè)軟件系統(tǒng)封裝了若干領(lǐng)域的知識(shí)，其中一個(gè)領(lǐng)域的知識(shí)代表了系統(tǒng)的核心競(jìng)爭(zhēng)力，是系統(tǒng)和其他系統(tǒng)區(qū)分的關(guān)鍵所在。這個(gè)領(lǐng)域稱為"核心域"，其他領(lǐng)域稱為"非核心域"。更通俗的說(shuō)法是"業(yè)務(wù)"和"技術(shù)"，但使用"核心域"和"非核心域"更嚴(yán)謹(jǐn)。核心域不一定是物流、醫(yī)療、金融等非計(jì)算機(jī)領(lǐng)域，也可以是計(jì)算機(jī)和軟件領(lǐng)域。圖3展示了不同系統(tǒng)的核心域和非核心域概念：

圖3 不同系統(tǒng)的核心域、非核心域概念

好，根據(jù)以上的知識(shí)，我們來(lái)逐一剖析這些術(shù)語(yǔ)，可能有好幾十個(gè)。

術(shù)語(yǔ)01：功能模塊

評(píng)價(jià)：“功能”屬于模糊術(shù)語(yǔ)，“模塊”屬于模糊術(shù)語(yǔ)，“功能模塊”屬于錯(cuò)誤術(shù)語(yǔ)。

功能（Function）。當(dāng)我們說(shuō)起這個(gè)詞的時(shí)候，研究對(duì)象一般是系統(tǒng)。對(duì)于組織，一般說(shuō)“組織的服務(wù)”，對(duì)于類，一般說(shuō)“類的操作”。所以，“功能”屬于“B-需求”的范疇（功能需求），描述系統(tǒng)作為一個(gè)整體為其他系統(tǒng)提供的服務(wù)，把其他系統(tǒng)給它的輸入變成其他系統(tǒng)所需要的輸出。

但是，“功能需求”仍然不夠精確。例如，以自助柜員機(jī)（ATM）為研究對(duì)象，“取現(xiàn)金”是“功能”，“登錄”也是功能，“計(jì)算手續(xù)費(fèi)”也是“功能”，到底“功能”有多大？用例的術(shù)語(yǔ)要嚴(yán)謹(jǐn)?shù)枚唷！叭‖F(xiàn)金”是一個(gè)用例，“登錄”是用例中的一個(gè)回合，“計(jì)算手續(xù)費(fèi)”是一個(gè)步驟。

模塊（Module）。當(dāng)我們說(shuō)起這個(gè)詞的時(shí)候，研究對(duì)象一般是系統(tǒng)。模塊表示系統(tǒng)的組成部分，屬于“C-分析”和“D-設(shè)計(jì)”的范疇。這個(gè)詞也是模糊的。這個(gè)模塊是一個(gè)控件？一個(gè)類？若干個(gè)類形成的組件？

如果說(shuō)“功能”和“模塊”是模糊的，那么“功能模塊”就是錯(cuò)誤的，這個(gè)詞混淆了系統(tǒng)外部和內(nèi)部的區(qū)別，需求和設(shè)計(jì)的區(qū)別。

“功能”是系統(tǒng)作為一個(gè)整體所需要完成的行為，“模塊”是系統(tǒng)的內(nèi)部結(jié)構(gòu)。連起來(lái)說(shuō)“功能模塊”，意味著在意識(shí)里認(rèn)為“功能”和“模塊”有直接的映射關(guān)系，甚至認(rèn)為“模塊”是屬于某個(gè)“功能”的模塊，是為了完成某個(gè)“功能”而存在的。

這樣的認(rèn)識(shí)是錯(cuò)誤的。如圖4所示，完成某個(gè)“功能”需要若干“模塊”的協(xié)作，而某個(gè)“模塊”也會(huì)參與完成若干“功能”，例如可以看出“模塊6”被反復(fù)使用了很多次。如果將“功能”和“模塊”直接映射，系統(tǒng)內(nèi)部將出現(xiàn)大量冗余。

圖4 “功能”和“模塊”的映射是多對(duì)多的

人體就是一個(gè)系統(tǒng)，基本功能有走路、跳躍、吃飯等，但是設(shè)計(jì)人體結(jié)構(gòu)時(shí)，不能從外部直接映射到內(nèi)部，得到人體由“走路模塊”、“跳躍模塊”、“吃飯模塊”組成。人體的“模塊”是五官四肢和內(nèi)臟，還有最關(guān)鍵的——“大腦”。不管是走路、跳躍還是吃飯或者將來(lái)發(fā)展出更多的“功能”，都由這些“模塊”協(xié)作完成。

那么，那些經(jīng)常被稱為“功能模塊”的東西，應(yīng)該怎么稱呼合適呢？圖5是百度“功能模塊”得到的排第一位的圖片：

圖5 百度“功能模塊”得到的排第一位的圖片，來(lái)自?http://www.think58.com/asp/9182.html?，非UML圖

從圖5得知，“商品銷售管理系統(tǒng)”有很多功能，其中一部分是給用戶使用的，另一部分是給管理員使用的，所以很多人會(huì)說(shuō)“本系統(tǒng)分為兩大功能模塊——用戶模塊和管理員模塊”，但是這樣的說(shuō)法在意識(shí)里不知不覺(jué)犯了從外直接映射內(nèi)部的錯(cuò)誤，如圖6。

圖6 不知不覺(jué)從外部映射到內(nèi)部

還是用人舉例。人有很多功能，有些是為老板提供的，有些是為老婆提供的，還有些是為老爸老媽提供的。按照?qǐng)D5的意思，人可以切割成“老板模塊”、“老婆模塊”……人體確實(shí)可以根據(jù)內(nèi)部的耦合和內(nèi)聚情況切割成不同層次的“模塊”（細(xì)胞→組織→器官→子系統(tǒng)），但是和外面的切割沒(méi)有直接的映射關(guān)系。為老板服務(wù)也好，為老婆服務(wù)也好，沒(méi)有強(qiáng)大的血液循環(huán)子系統(tǒng)（心臟、血管）和神經(jīng)系統(tǒng)（腦、脊髓、各種神經(jīng)）都是搞不定的。

設(shè)想食人族把一個(gè)人大卸八塊（對(duì)，模塊的塊），分贓時(shí)會(huì)怎么說(shuō)？“來(lái)，左腿歸你，下水歸我”，還是“走路功能歸你，吃飯功能歸我”？

如果要描述若干功能的集合，更貼切的術(shù)語(yǔ)應(yīng)該是“功能包”，如圖7所示。

圖7 用需求包來(lái)表達(dá)功能集合

當(dāng)然，如果您硬要說(shuō)，老子就喜歡叫“功能模塊”，那也可以，關(guān)鍵是要了解我上面說(shuō)的道理。

術(shù)語(yǔ)02：業(yè)務(wù)架構(gòu)

評(píng)價(jià)：“業(yè)務(wù)”屬于模糊術(shù)語(yǔ)，“架構(gòu)”屬于模糊術(shù)語(yǔ)，“業(yè)務(wù)架構(gòu)”屬于模糊術(shù)語(yǔ)。

業(yè)務(wù)（Business）。“業(yè)務(wù)”這個(gè)詞在軟件開(kāi)發(fā)團(tuán)隊(duì)中使用得很頻繁，例如“我是一名業(yè)務(wù)架構(gòu)師”、“我們要了解業(yè)務(wù)”等等，但是往往說(shuō)話的人未必真的理解話中的“業(yè)務(wù)”具體指什么。

有時(shí)候“業(yè)務(wù)”指的是內(nèi)容上的劃分，含義是“核心域”。

例如，一個(gè)餐館系統(tǒng)，訂單和菜品的關(guān)系屬于“業(yè)務(wù)知識(shí)”，折扣的計(jì)算規(guī)則屬于“業(yè)務(wù)規(guī)則”，如圖8所示。

圖8 餐館系統(tǒng)需要封裝的“業(yè)務(wù)”——核心域類圖

此時(shí)，和“業(yè)務(wù)”相對(duì)應(yīng)的就是“技術(shù)”了。開(kāi)發(fā)人員假裝謙虛“我是做技術(shù)的，業(yè)務(wù)不太懂唉”，就是這個(gè)意思。甚至有的開(kāi)發(fā)人員在潛意識(shí)里是這樣劃分的：

我懂且我感興趣的知識(shí)→技術(shù)；（我是一名Java程序員，Java編碼是技術(shù)）

我懂但不感興趣的知識(shí)→業(yè)務(wù)；（下單、收銀、配送我懂一些，但不感興趣，這些是業(yè)務(wù)）

我不懂但感興趣的知識(shí)→高科技；（我不懂深度學(xué)習(xí)，但很感興趣，哇塞，高科技）

我不懂且不感興趣的東東→忽悠。（我不懂UML建模，也不感興趣，媽的，忽悠）

有時(shí)候“業(yè)務(wù)”指的是范圍上的劃分，含義是“組織級(jí)別”。例如，“業(yè)務(wù)建模”說(shuō)的是組織級(jí)別的建模、“業(yè)務(wù)用例”說(shuō)的是組織為其他組織提供的服務(wù)，“業(yè)務(wù)流程”說(shuō)的是組織內(nèi)各個(gè)系統(tǒng)之間協(xié)作的流程。如圖9，表達(dá)了餐館的“業(yè)務(wù)流程”。

圖9 餐館組織的“業(yè)務(wù)”流程

此時(shí)，和“業(yè)務(wù)”相對(duì)應(yīng)的就是“系統(tǒng)”了。

架構(gòu)（Architecture）。“架構(gòu)”這個(gè)詞被濫用得厲害，已經(jīng)達(dá)到一磚頭砸死十個(gè)架構(gòu)師的地步。Martin Fowler曾經(jīng)在他的書(shū)“Patterns of Enterprise Application Architecture”中寫(xiě)道：

The software industry delights in taking words and stretching them into a myriad of subtly contradictory meanings. One of the biggest sufferers is "architecture."

軟件業(yè)樂(lè)于做這樣的事——找一些詞匯，并引申出大量微妙而又互相矛盾的含義。一個(gè)最大的受害者就是“架構(gòu)”。

維基百科中這樣描述“架構(gòu)”：

軟件架構(gòu)是一個(gè)系統(tǒng)的草圖。軟件架構(gòu)描述的對(duì)象是直接構(gòu)成系統(tǒng)的抽象組件。各個(gè)組件之間的連接則明確和相對(duì)細(xì)致地描述組件之間的通訊。在實(shí)現(xiàn)階段，這些抽象組件被細(xì)化為實(shí)際的組件，比如具體某個(gè)類或者對(duì)象。

我的歸納：架構(gòu)是多個(gè)系統(tǒng)內(nèi)部共有的抽象機(jī)制。

要點(diǎn)一：內(nèi)部。系統(tǒng)提供的各種功能，不屬于“架構(gòu)”。要點(diǎn)二：共有。架構(gòu)是一種復(fù)用機(jī)制。它獨(dú)立于單個(gè)系統(tǒng)，圍繞它可以組裝成系統(tǒng)的家族。

圖10是現(xiàn)在常提到的一個(gè)架構(gòu)。可以斷定，我們會(huì)在很多軟件系統(tǒng)中發(fā)現(xiàn)這樣的機(jī)制。圖10表達(dá)的是不同領(lǐng)域（UI、Database、核心域……）之間交互的機(jī)制。不管系統(tǒng)的核心域是哪一個(gè)（保險(xiǎn)、物流、醫(yī)療），這樣的機(jī)制都可以存在。

圖10 域之間的架構(gòu)，來(lái)自taimila.com，非UML圖

圖11也是架構(gòu)，也可以在千萬(wàn)個(gè)軟件系統(tǒng)中發(fā)現(xiàn)這樣的機(jī)制。相對(duì)于圖10，圖11表達(dá)的是某個(gè)領(lǐng)域內(nèi)部各種領(lǐng)域概念的關(guān)系。不管將核心域概念映射到哪些非核心域上（Android還是iOS，Vue還是React）得到系統(tǒng)，這樣的機(jī)制都可以存在。

圖11 域內(nèi)部的架構(gòu)

這里再啰嗦幾句。在一些軟件開(kāi)發(fā)大會(huì)常可以看到這樣的場(chǎng)景：某電子商務(wù)網(wǎng)站的架構(gòu)師上臺(tái)講了一通，接著某視頻網(wǎng)站的架構(gòu)師上臺(tái)也講了一通，咦，兩個(gè)演講內(nèi)容如此相似？原來(lái)，他們講的都是自己系統(tǒng)中各域之間的機(jī)制（類似圖 10），而不是核心域內(nèi)部的機(jī)制（類似圖 11）。究其原因也許并非不為，而是不能——開(kāi)發(fā)人員對(duì)自己所開(kāi)發(fā)系統(tǒng)的核心域研究太淺。許多“網(wǎng)紅程序員 ”在網(wǎng)上談?wù)摰膬?nèi)容大多是某種語(yǔ)言或框架的新特性，少有探討他當(dāng)前所開(kāi)發(fā)系統(tǒng)的復(fù)雜領(lǐng)域邏輯，也是同樣的原因：并非不為，而是不能。

業(yè)務(wù)架構(gòu)。根據(jù)以上講述，這個(gè)詞有兩種含義。

含義一：組織的內(nèi)部機(jī)制。此時(shí)，“業(yè)務(wù)”作“組織”解。圖9就描述了這樣的機(jī)制。維基百科采用的就是這種含義，如圖12。此時(shí)業(yè)務(wù)架構(gòu)師應(yīng)該負(fù)責(zé)的是“A-業(yè)務(wù)建?！钡墓ぷ鳌?/p>

圖12 維基百科上關(guān)于業(yè)務(wù)架構(gòu)的描述

我們?cè)賮?lái)看一些公司招聘“業(yè)務(wù)架構(gòu)師”（Business Architect）的描述，有的崗位要求還比較貼近“A-業(yè)務(wù)建?！?，如圖13。

圖13 業(yè)務(wù)架構(gòu)師崗位描述1，來(lái)自拉勾網(wǎng)

也有不知所云的崗位要求，如圖14。

圖14 業(yè)務(wù)架構(gòu)師崗位描述2，來(lái)自拉勾網(wǎng)

含義二：系統(tǒng)內(nèi)部的核心域機(jī)制。此時(shí)，“業(yè)務(wù)”作“核心域”解。圖11就描述了這樣的機(jī)制。此時(shí)業(yè)務(wù)架構(gòu)師應(yīng)該負(fù)責(zé)的是“C-分析”的工作。

遺憾的是，在招聘網(wǎng)站上搜不到符合這個(gè)含義的“業(yè)務(wù)架構(gòu)師”崗位。搜“架構(gòu)師”可發(fā)現(xiàn)其崗位要求覆蓋了“C-分析”和“D-設(shè)計(jì)”。上文已經(jīng)說(shuō)過(guò)，絕大多數(shù)的“架構(gòu)師”熟悉的是“D-設(shè)計(jì)”的工作（圖10），不擅長(zhǎng)“C-分析”的工作（圖11）。

術(shù)語(yǔ)03：用戶需求

評(píng)價(jià)：“用戶”屬于模糊術(shù)語(yǔ)，“需求”屬于明確術(shù)語(yǔ)，“用戶需求”屬于錯(cuò)誤術(shù)語(yǔ)。

用戶（User）。首先，用戶默認(rèn)是人，沒(méi)有稱某個(gè)軟件系統(tǒng)為用戶的——“本系統(tǒng)的另一個(gè)用戶是第三方支付系統(tǒng)”；其次用戶是和所研究系統(tǒng)有交互的人。例如，我正在用Word寫(xiě)這篇文章，我是Word的用戶。以上是最常見(jiàn)的理解。

有時(shí)“用戶”也會(huì)用在根本沒(méi)有人機(jī)交互的地方，如圖15。一個(gè)定時(shí)收集信息的系統(tǒng)，根本不需要和人交互，但需求人員也會(huì)說(shuō)“用戶是怎么要求的？多長(zhǎng)時(shí)間收集一次？速度要多快？源格式和目標(biāo)格式是怎樣的？”此時(shí)，“用戶”不是指和所研究系統(tǒng)交互的人，而是系統(tǒng)所服務(wù)的目標(biāo)組織的某個(gè)負(fù)責(zé)和開(kāi)發(fā)團(tuán)隊(duì)接口的人。例如，假設(shè)這個(gè)系統(tǒng)為某市國(guó)稅局服務(wù)的，需求人員剛才說(shuō)的“用戶”可能是國(guó)稅局信息中心的副主任。怎樣稱呼這位副主任才正確，后文再說(shuō)。

圖15 無(wú)人參與交互的收集過(guò)程

“用戶”一詞存在的問(wèn)題：

（1）很多時(shí)候我們口中的“用戶”是隨意推測(cè)的。

我們來(lái)看圖9的餐館的例子。我們把它搬到圖16。假設(shè)圖16是餐館的現(xiàn)狀，餐館的老板希望在此現(xiàn)狀之上進(jìn)一步改進(jìn)。需求人員很容易先入為主，認(rèn)定上面的人就是新系統(tǒng)的“用戶”，然后逐個(gè)找這些“用戶”調(diào)研。

圖16 餐館的現(xiàn)狀

這樣的先入為主是不對(duì)的。也許餐館老板希望看到的改進(jìn)如圖17所示。從圖中可以看到，領(lǐng)位員這個(gè)崗位都不需要了，還找他調(diào)研個(gè)啥。如果連服務(wù)員都可以不要，老板可能覺(jué)得更爽。

圖17 對(duì)餐館的一種改進(jìn)

（2）“用戶”混淆了演員和觀眾。

我們先來(lái)看用例（Use Case）的一些概念。如圖18所示，用例把軟件系統(tǒng)看作一部電影，演員（Actor，執(zhí)行者）在臺(tái)上表演，觀眾（Stakeholder，涉眾）在臺(tái)下看，觀眾按照他們的地位排排坐。演員在臺(tái)上表演什么是由觀眾的口味決定的，先照顧前排的觀眾，如果有余力，再照顧后排的觀眾。

圖18 演員（執(zhí)行者，Actor）在臺(tái)上表演，觀眾（涉眾，Stakeholder）在臺(tái)下看

用例使用“執(zhí)行者”（Actor）和“涉眾”（Stakeholder）代替了原來(lái)的“用戶”，這是一個(gè)非常大的突破?！坝脩簟边@個(gè)詞混淆了演員和觀眾的區(qū)別。過(guò)去經(jīng)常說(shuō)“找用戶調(diào)研需求”，這是錯(cuò)誤的。所謂“用戶”，就是上臺(tái)表演的人類演員。找用戶調(diào)研，相當(dāng)于找演員問(wèn)劇本應(yīng)該是什么內(nèi)容，豈不是很荒謬？劇本應(yīng)該由編劇向觀眾調(diào)研編寫(xiě)出來(lái)，然后由各路演員在臺(tái)上演繹。

演員如果是人類，那么在觀眾席上也會(huì)有一個(gè)位置，不過(guò)在第幾排就不知道了。范冰冰這樣的大咖，可能有能力影響劇本的內(nèi)容，跑龍?zhí)椎木退懔税伞?/p>

在臺(tái)上當(dāng)“用戶”當(dāng)?shù)迷綒g的涉眾，往往在涉眾排行榜上排位越靠后。您想想，整天操作電腦搞得手僵脖子硬的“用戶”，有幾個(gè)是職位高的呢？真正位高權(quán)重的涉眾，雖然偶爾也會(huì)上臺(tái)表演，但更多時(shí)候是坐在臺(tái)下看戲。建模人員如果過(guò)多地關(guān)注“用戶”，花在重要的前排涉眾身上的時(shí)間可能就不夠了。

像“用戶故事”這樣的方法在開(kāi)發(fā)一些面向大眾的互聯(lián)網(wǎng)系統(tǒng)時(shí)還能應(yīng)付，因?yàn)檫@類系統(tǒng)的執(zhí)行者往往屬于前排涉眾，以上問(wèn)題就被掩蓋了。如果開(kāi)發(fā)涉眾較多、利益沖突微妙的系統(tǒng)，應(yīng)該采用用例這樣更嚴(yán)謹(jǐn)?shù)男枨蠹寄?。例如做一個(gè)手機(jī)游戲，重點(diǎn)調(diào)研玩家這個(gè)“用戶”是可以的，做一個(gè)某單位的柜臺(tái)系統(tǒng)，也重點(diǎn)調(diào)研窗口工作人員（希望干活越少越好），那背后的領(lǐng)導(dǎo)和其他同事就遭殃了。

另外，現(xiàn)在的系統(tǒng)做出來(lái)，越來(lái)越多的接口不是面向人類的，而是面向另一個(gè)軟件系統(tǒng)，也就是說(shuō)沒(méi)有“用戶”。兩個(gè)電腦系統(tǒng)交互的需求，難道就不用做了，或者可以隨便做？非也。那只是相當(dāng)于上臺(tái)表演的不是人，是功夫熊貓、變形金剛和喜羊羊灰太狼，但是臺(tái)下對(duì)表演說(shuō)好說(shuō)壞的觀眾依然是人。建立“執(zhí)行者和系統(tǒng)在臺(tái)上表演，涉眾在臺(tái)下看表演”的概念，在執(zhí)行者為非人系統(tǒng)時(shí)對(duì)捕獲需求很有幫助。

（3）“用戶”是拒絕深入思考的遮羞布。

即使是演員和前排觀眾重疊的系統(tǒng)，“用戶”也是一個(gè)阻攔需求人員深入思考的詞匯。許多產(chǎn)品經(jīng)理把“用戶”掛在嘴邊，“要從用戶的角度思考”，“用戶滿意的才是好產(chǎn)品”等等，甚至還有“喬布斯不在意用戶的意見(jiàn)”等奇談怪論。問(wèn)題來(lái)了，誰(shuí)是用戶？

一個(gè)老頭找到PS可樂(lè)公司，告訴他們的主管，“我可是你們的忠誠(chéng)客戶??！我喝過(guò)的可樂(lè)罐排成線，可以從蘋(píng)果園排到通州（北京從西到東）?，F(xiàn)在我老了，我對(duì)你們的可樂(lè)下一個(gè)版本提出如下要求：第一，我有胃病，下一個(gè)版本不要有這么多氣；第二，我有糖尿病，下一個(gè)版本里面不要有糖。”P(pán)S可樂(lè)公司的主管很感動(dòng)，哇，這么棒的顧客，把要求提得那么具體，省下好多我們調(diào)研需求的時(shí)間，好，下個(gè)版本就這么辦！

可惜，現(xiàn)實(shí)生活中不會(huì)有這樣的場(chǎng)景。老頭老太太可以買可樂(lè)喝，甚至可以買給自己的寵物喝，PS可樂(lè)公司不會(huì)攔著。問(wèn)題在于，老頭老太太提的要求，或者為他們的寵物提的要求（注意用詞：是要求，不是需求），PS可樂(lè)公司不會(huì)放在重要的位置來(lái)考慮，因?yàn)镻S可樂(lè)的目標(biāo)人群是青少年。可惜，很多時(shí)候我問(wèn)需求人員：“可樂(lè)賣給誰(shuí)？”得到的回答大多是“賣給消費(fèi)者”，“賣給想喝可樂(lè)的人”等對(duì)做出好賣的可樂(lè)沒(méi)有幫助的、正確而無(wú)用的廢話。

我在《軟件方法》中，用“老大”取代了“用戶”?！袄洗蟆笔且粋€(gè)真實(shí)存在的具體的人。定位“老大”的具體方法參見(jiàn)《軟件方法》第2章，和Persona方法類似。但是Persona是虛構(gòu)一個(gè)“用戶畫(huà)像”，說(shuō)白了也是鼓勵(lì)需求人員逃避深入第一線調(diào)研的辛苦，安心閉門造車。例如，為女性做一個(gè)產(chǎn)品，建模人員深入第一線調(diào)研，面對(duì)的調(diào)研對(duì)象是一個(gè)個(gè)具體的女性。如果建模人員把調(diào)研的精力花在羅玉鳳身上，留給林志玲的精力就不多了，所以必須思考羅玉鳳更像老大還是林志玲更像老大的問(wèn)題。相比起來(lái)，關(guān)在辦公室隨意捏造一個(gè)符合自己要求的“女性”省事多了。如果滿足于Persona，歸根結(jié)底還是在內(nèi)心里沒(méi)有認(rèn)識(shí)到深入第一線調(diào)研的重要性。

“老大”的頭腦是一塊塊的戰(zhàn)場(chǎng)，所研發(fā)的系統(tǒng)是一支軍隊(duì)。研發(fā)團(tuán)隊(duì)的領(lǐng)導(dǎo)是軍隊(duì)指揮官，他負(fù)責(zé)找到自己的軍隊(duì)最值得投入的戰(zhàn)場(chǎng)，指揮軍隊(duì)和敵人廝殺，占領(lǐng)戰(zhàn)場(chǎng)，或者防守住敵人的進(jìn)攻。戰(zhàn)局是殘酷的。您手上的三萬(wàn)紅軍下一步應(yīng)該殺向哪里，可選項(xiàng)其實(shí)少之又少，您必須竭盡全力把這個(gè)戰(zhàn)場(chǎng)找出來(lái)?？上?，許多人低估了現(xiàn)實(shí)的殘酷，意淫自己手里有百萬(wàn)大軍，愛(ài)殺往哪里就殺往哪里。

圖19 和對(duì)手在老大的大腦里廝殺

需求（Requirement）。明確術(shù)語(yǔ)，不再單獨(dú)闡述。

用戶需求。錯(cuò)誤術(shù)語(yǔ)。需求指系統(tǒng)對(duì)外提供的功能性能，如果要在“需求”前面加一個(gè)定語(yǔ)，這個(gè)定語(yǔ)是“系統(tǒng)”——“系統(tǒng)的需求”。

系統(tǒng)的需求就像電影的劇本，規(guī)定了電影拍出來(lái)必須滿足的內(nèi)容，它是平衡了各種觀眾的口味（先照顧第一排觀眾，再照顧第二排……）得到的結(jié)果。對(duì)所有觀眾、演員來(lái)說(shuō)，劇本就在那里，不會(huì)因?yàn)槟硞€(gè)觀眾不喜歡其中某個(gè)情節(jié)而變化，也不會(huì)因?yàn)闀簳r(shí)還沒(méi)有找到演員來(lái)拍成電影而變化。所以，不存在什么“用戶需求”、“設(shè)計(jì)需求”、“架構(gòu)需求”、“開(kāi)發(fā)需求”、“編碼需求”等東西。需求不是你的、我的、他的，是系統(tǒng)的，是你我他最終達(dá)成的關(guān)于系統(tǒng)的一份契約。

那么，“用戶”后面能跟什么呢？可以跟“要求”。更嚴(yán)謹(jǐn)?shù)男g(shù)語(yǔ)是“涉眾利益”。需求像電影劇本，涉眾像電影觀眾。劇本只有一份，觀眾卻是多種多樣，不同觀眾的欣賞角度和口味不同。魯迅說(shuō)過(guò)：一部紅樓夢(mèng)，經(jīng)學(xué)家看見(jiàn)《易》，道學(xué)家看見(jiàn)淫，才子看見(jiàn)纏綿，革命家看見(jiàn)排滿，流言家看見(jiàn)宮闈秘事。

軟件系統(tǒng)也是如此。例如一個(gè)生產(chǎn)執(zhí)行管理系統(tǒng)，老大制造部王部長(zhǎng)關(guān)注的是“縮短從接到市場(chǎng)部訂單到交付產(chǎn)品的時(shí)間周期”，車間工人更關(guān)心“我這個(gè)崗位的工作量會(huì)不會(huì)增加”，庫(kù)管員可能擔(dān)心“以后不好搞手腳”。系統(tǒng)的需求首先要照顧王部長(zhǎng)的利益，在不損害王部長(zhǎng)利益的前提下，還有余力的話再照顧車間工人和庫(kù)管員。對(duì)于實(shí)在照顧不到的后排涉眾，很多時(shí)候只好抱歉了，這個(gè)系統(tǒng)可能會(huì)損害你的利益。

軟件的需求規(guī)約相當(dāng)于電影劇本。電影劇本不是由觀眾直接提供，而是由編劇根據(jù)不同觀眾的口味編出來(lái)的。同樣，軟件需求不是由涉眾直接提供的，而是由需求人員綜合不同涉眾的利益來(lái)決定的。涉眾沒(méi)有資格提供需求。

系統(tǒng)的需求是平衡各種涉眾利益得到的，不由單一涉眾決定。以ATM機(jī)為例，如果需求人員詢問(wèn)ATM機(jī)的執(zhí)行者儲(chǔ)戶“取款機(jī)應(yīng)該怎么做你覺(jué)得最好”，儲(chǔ)戶回答大實(shí)話“最好像我家抽屜一樣拉開(kāi)就拿，喏，把我家里的抽屜拿去做原型”，需求人員顯然不能把這個(gè)“抽屜”當(dāng)真，只需要把“抽屜”背后的涉眾利益提煉出來(lái)——儲(chǔ)戶希望操作次數(shù)盡可能少一些。最終系統(tǒng)的需求有多少尊重了這個(gè)利益，就要看儲(chǔ)戶在涉眾排行榜上的排位了。

拿患者和醫(yī)生類比也可以幫助理解?；颊叩结t(yī)院對(duì)醫(yī)生說(shuō)“我腿疼，可能得了腿癌，我要做放療”，醫(yī)生就給他做放療？顯然不是這樣，醫(yī)生只能把患者所說(shuō)的一切當(dāng)成素材，按照成熟的套路，該做什么檢查就做什么檢查，該如何治療就如何治療。

很多時(shí)候我們想涉眾調(diào)研時(shí)，涉眾直接給出解決方案——“我要一個(gè)像某某軟件那樣的！”如果你真的按照他說(shuō)的做了，他用的時(shí)候又不滿意了，而且他的其他同事更不滿意。然后我們還委屈呢，都是按照當(dāng)時(shí)開(kāi)會(huì)時(shí)你說(shuō)的做的，還有錄音為證！

了解到“涉眾無(wú)資格提供需求，和涉眾交流的內(nèi)容應(yīng)該聚焦于涉眾利益”，可以幫助我們少犯錯(cuò)誤。

術(shù)語(yǔ)04：文檔

評(píng)價(jià)：“文檔”屬于模糊術(shù)語(yǔ)。

先列出使用“文檔”的一些話語(yǔ)：

你們?cè)趺匆簧鲜志蛯?xiě)代碼，連個(gè)文檔都沒(méi)有！

你現(xiàn)在在做什么？我在寫(xiě)文檔。

代碼就是文檔。

從以上話語(yǔ)可以看出以下問(wèn)題：

（1）在許多軟件開(kāi)發(fā)人員的大腦里，“文檔”的意思就是“代碼之外的其他工件”。由于缺乏軟件工程方面的基本知識(shí)，對(duì)之前提到的“A-業(yè)務(wù)建模”、“B-需求”、“C-分析”、“D-設(shè)計(jì)”等工作流沒(méi)有概念，只好把軟件開(kāi)發(fā)工作分為“寫(xiě)代碼”和“寫(xiě)文檔”兩部分。（其實(shí)，就連什么叫“代碼”，很多人也是糊涂的，這一點(diǎn)后面再說(shuō)。）

（2）軟件開(kāi)發(fā)人員一旦把工件簡(jiǎn)單分割為“代碼”和“文檔”，還會(huì)導(dǎo)致這樣的誤解：認(rèn)為“文檔”只不過(guò)是“代碼”的一種比較概要或比較形象的表現(xiàn)形式，不同的“文檔”代表著“代碼”的不同視圖，可以讓開(kāi)發(fā)人員從不同的視角觀察代碼，這樣就便于人腦把握代碼的復(fù)雜性。如圖20所示。

圖20 誤解：文檔只是代碼的視圖

這種誤解不只“普通”的開(kāi)發(fā)人員會(huì)有。Martin Fowler所著的UML暢銷書(shū)《UML精粹》，認(rèn)為UML有三種用法：草稿、藍(lán)圖和編程語(yǔ)言，也是僅從編碼的角度來(lái)說(shuō)的。從Fowler寫(xiě)作的其他書(shū)籍《重構(gòu)》、《企業(yè)應(yīng)用架構(gòu)模式》、《分析模式》等可以知道，他的研究工作集中在分析設(shè)計(jì)工作流，在業(yè)務(wù)建模和需求方面研究不多。

這樣的誤解就會(huì)導(dǎo)致推論：只要“代碼”寫(xiě)得自己“會(huì)說(shuō)話”，那么“代碼就是文檔”，“文檔”就不需要了。本來(lái)“文檔”就是“代碼以外的其他東西”，這么一推，就變成了“代碼就是一切”。

（3）把“文檔”當(dāng)作“代碼”的視圖還會(huì)帶來(lái)下面這種思維顛倒：先拍腦袋實(shí)現(xiàn)，然后再?gòu)膶?shí)現(xiàn)反推其他工作流的內(nèi)容。例如下面的對(duì)話：

張三：這個(gè)不應(yīng)該是系統(tǒng)的用例（如果您不理解什么叫“用例”，就先把它理解為“功能”好了）。

李四：是的！我都寫(xiě)好了，運(yùn)行一下給你看，這個(gè)系統(tǒng)確實(shí)提供了這個(gè)用例。

是否系統(tǒng)的用例應(yīng)該以“好賣”來(lái)判斷。權(quán)衡涉眾利益之后覺(jué)得應(yīng)該有，系統(tǒng)就有，不該有就沒(méi)有，而不是我寫(xiě)好了代碼，所以就應(yīng)該有。

張三：這兩個(gè)類關(guān)系不應(yīng)該是泛化，而是關(guān)聯(lián)。

李四：是泛化，不信我打開(kāi)代碼給你看，或者逆向工程轉(zhuǎn)出類圖給你看。

是否泛化關(guān)系應(yīng)該以“符合領(lǐng)域內(nèi)涵”來(lái)判斷，而不是先寫(xiě)好代碼“人是豬的一種”（肯定編譯通過(guò)），再用寫(xiě)好的代碼來(lái)證明“人是豬的一種”。

（4）“文檔”還意味著它和“代碼”使用的可能是不同的工具寫(xiě)出來(lái)的。在Visual Studio、Eclipse里面寫(xiě)出來(lái)的叫“代碼”，在Word、wiki、Visio、EA等等里面寫(xiě)或者畫(huà)出來(lái)的叫“文檔”。

正確的理解是：

不同工作流產(chǎn)出的工件之間的區(qū)別不在于形式，而在于思考和表達(dá)的內(nèi)容，如圖21所示。

圖21 建模工作流思考內(nèi)容

如果清楚了解“區(qū)別在于內(nèi)容”這一點(diǎn)，就知道“我在寫(xiě)文檔”這樣的話只是表達(dá)“我正在用文檔編輯工具在工作”，沒(méi)有其他意義。你在寫(xiě)什么文檔？“業(yè)務(wù)建?！?？“需求”？“分析”？“設(shè)計(jì)”？我不寫(xiě)，我畫(huà)圖難道不可以嗎？我不寫(xiě)不畫(huà)，我用語(yǔ)音清楚地表達(dá)出組織的流程，不可以嗎？更有意義的說(shuō)法應(yīng)該是“我在做業(yè)務(wù)建?！薄Ｈ绻f(shuō)“文檔”二字可以給您帶來(lái)不可替代的快感，可以說(shuō)“我在寫(xiě)業(yè)務(wù)建模文檔”。

內(nèi)容和形式的組合是靈活的。很流行的“代碼就是設(shè)計(jì)”這句話的意思就是，設(shè)計(jì)工作流目前推薦的做法是不需要畫(huà)UML圖或者寫(xiě)“設(shè)計(jì)文檔”，直接用源代碼來(lái)表達(dá)設(shè)計(jì)模型。編碼本身就是一種建模工作。計(jì)算機(jī)運(yùn)行的是二進(jìn)制指令，源代碼實(shí)際上也是“模型”。之所以被稱為“源代碼”，是因?yàn)樗侨四X需要編輯的最低形式模型（編輯完這個(gè)就好，后面的事情就可以交給計(jì)算機(jī)了?。?。這個(gè)最低形式模型隨著時(shí)代的發(fā)展不斷變化。

如圖21所示，最初的源代碼是機(jī)器語(yǔ)言。程序員在紙帶或卡片上打孔來(lái)表達(dá)0和1。后來(lái)發(fā)現(xiàn)這樣太累了，于是發(fā)明了一些助記符，這就是匯編語(yǔ)言。 今天會(huì)有開(kāi)發(fā)人員故意裝×，“這些我不太懂唉，我是做底層的，用C編碼”，可是C語(yǔ)言卻被歸類為“高級(jí)語(yǔ)言”，因?yàn)轭愃艭這樣的語(yǔ)言出現(xiàn)的時(shí)候， 大多數(shù)程序員編輯的是匯編語(yǔ)言，C相對(duì)于匯編來(lái)說(shuō)，當(dāng)然很高級(jí)。今天的一名企業(yè)應(yīng)用程序員，最終需要編輯的可能有 HTML、CSS、JavaScript、Java、配置腳本、SQL等，這些就是現(xiàn)在的“源代碼”的形式。

圖22 “源代碼”的發(fā)展歷程

從圖22中的“歷史進(jìn)程”來(lái)看，大趨勢(shì)是人腦要編輯的“源代碼”離計(jì)算機(jī)原來(lái)越遠(yuǎn)，離領(lǐng)域越來(lái)越近。至于最終什么樣的具體形式能成為下一形式的代表，只好看各種語(yǔ)言的“個(gè)人奮斗”了。

同理，如果人腦只需要編輯UML模型就可以實(shí)現(xiàn)系統(tǒng)，那么“模型就是源代碼”。例如用帶有設(shè)計(jì)級(jí)調(diào)試和強(qiáng)大代碼生成能力的工具IBM Rational Rhapsody開(kāi)發(fā)實(shí)時(shí)嵌入系統(tǒng)，在配置好和IDE的集成之后，人腦只需要編輯和調(diào)試UML模型（主要是類圖和狀態(tài)機(jī)圖），就可以實(shí)現(xiàn)系統(tǒng)，不需要在IDE里敲字符。感興趣的讀者可以自己去看Rhapsody附帶的例子。

“代碼就是設(shè)計(jì)”可以，那么“代碼就是需求”可以嗎？當(dāng)然也可以。例如，把整個(gè)系統(tǒng)看作一個(gè)類，那么這個(gè)類的操作就是系統(tǒng)的需求，因?yàn)樗磉_(dá)的是系統(tǒng)作為整體提供的服務(wù)。

我們?cè)谑褂肬ML建模的時(shí)候，各種建模元素和建模內(nèi)容也是靈活匹配的。例如，狀態(tài)機(jī)圖，可能一看到就想起分析設(shè)計(jì)，其實(shí)也可以用來(lái)表達(dá)需求。圖23把“電視”作為整體來(lái)畫(huà)狀態(tài)機(jī)，表達(dá)的就是“電視”的需求。

圖23 用狀態(tài)機(jī)圖表達(dá)電視的需求（讀者可以自行思考圖中？處應(yīng)該寫(xiě)什么?？雌饋?lái)一目了然，其實(shí)寫(xiě)對(duì)不容易。）

當(dāng)然，不同的內(nèi)容有推薦的形式。各建模工作流可以選用的建模圖形以及推薦用法如前文圖2所示。