功能模塊、業(yè)務(wù)架構(gòu)实苞、需求分析、用戶需求乏奥、系統(tǒng)分析剂碴、功能設(shè)計(jì)荚坞、詳細(xì)設(shè)計(jì)、文檔僵蛛、業(yè)務(wù)鲜锚、技術(shù)……很多被隨口使用的名詞吏够，其實(shí)是含糊甚至錯誤的蚜厉。

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

可能有的人會說臊岸，不會吧橙数，這些牛人帶團(tuán)隊(duì)做出了讓公司賺錢的系統(tǒng)，怎么會不清楚呢帅戒，只不過表達(dá)出來和你的表達(dá)不同而已吧灯帮？我只能很誠懇地再說一遍：很多“牛人”真的不清楚。當(dāng)然逻住，搞不清楚不妨礙做出賺錢的系統(tǒng)钟哥，就像有的人不了解人體運(yùn)行機(jī)制憑感覺也活到了一百歲。您也可以說“做出過賺錢的系統(tǒng)就行了唄瞎访，管他清楚不清楚呢腻贰！”，對對對扒秸，您說的都對播演，但不清楚也還是不清楚。

我先說一下我在《軟件方法》一書中對軟件建模工作流的劃分：

軟件開發(fā)的一個迭代周期中需要思考四個問題伴奥，即四個工作流：

A-業(yè)務(wù)建男纯荆——定位需要改進(jìn)的目標(biāo)組織（人群或機(jī)構(gòu)）以及該組織接下來最需要改進(jìn)的問題。

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

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

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

如圖1崖瞭。

圖1 四個工作流

以上四個工作流的名稱使用了傳統(tǒng)術(shù)語古徒，也有一定的模糊性（特別是業(yè)務(wù)建模）。更貼切的名稱是組織建模读恃、需求建模隧膘、核心域建模代态、實(shí)現(xiàn)。如果您覺得業(yè)務(wù)建模疹吃、需求蹦疑、分析、設(shè)計(jì)不好萨驶，直呼ABCD或改成阿豬歉摧、阿狗、阿雞腔呜、阿鴨也無所謂叁温。

針對這些工作流的思考，其實(shí)就是建模核畴。任何一個軟件項(xiàng)目膝但，這些思考都是逃不掉的，也就是說谤草，我們一直在建模跟束，只不過很多人習(xí)慣于無意識地做，運(yùn)氣時(shí)好時(shí)壞丑孩，速度時(shí)快時(shí)慢冀宴，有的人能夠有意識地做，讓汗水不白流温学。

思考的結(jié)果略贮，可以用口頭表達(dá)，也可以用文本仗岖、其他表示法或自造符號來表達(dá)逃延。用UML來表達(dá)，目前是一種不壞的做法箩帚。如果用UML表達(dá)真友，推薦的用法如圖2〗襞粒可以看到盔然，工作流D可以不需要用UML表達(dá)。

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

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

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

好敏沉，根據(jù)以上的知識果正，我們來逐一剖析這些術(shù)語，可能有好幾十個盟迟。

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

評價(jià)：“功能”屬于模糊術(shù)語秋泳，“模塊”屬于模糊術(shù)語，“功能模塊”屬于錯誤術(shù)語攒菠。

功能（Function）迫皱。當(dāng)我們說起這個詞的時(shí)候，研究對象一般是系統(tǒng)要尔。對于組織舍杜，一般說“組織的服務(wù)”新娜，對于類赵辕，一般說“類的操作”。所以概龄，“功能”屬于“B-需求”的范疇（功能需求）还惠，描述系統(tǒng)作為一個整體為其他系統(tǒng)提供的服務(wù)，把其他系統(tǒng)給它的輸入變成其他系統(tǒng)所需要的輸出私杜。

但是蚕键，“功能需求”仍然不夠精確。例如衰粹，以自助柜員機(jī)（ATM）為研究對象锣光，“取現(xiàn)金”是“功能”，“登錄”也是功能铝耻，“計(jì)算手續(xù)費(fèi)”也是“功能”誊爹，到底“功能”有多大？用例的術(shù)語要嚴(yán)謹(jǐn)?shù)枚嗥白健频丘！叭‖F(xiàn)金”是一個用例，“登錄”是用例中的一個回合泡态，“計(jì)算手續(xù)費(fèi)”是一個步驟搂漠。

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

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

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

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

圖4 “功能”和“模塊”的映射是多對多的

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

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

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

從圖5得知幽污，“商品銷售管理系統(tǒng)”有很多功能嚷辅，其中一部分是給用戶使用的，另一部分是給管理員使用的距误，所以很多人會說“本系統(tǒng)分為兩大功能模塊——用戶模塊和管理員模塊”簸搞，但是這樣的說法在意識里不知不覺犯了從外直接映射內(nèi)部的錯誤，如圖6准潭。

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

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

設(shè)想食人族把一個人大卸八塊（對，模塊的塊）焰檩，分贓時(shí)會怎么說憔涉？“來，左腿歸你析苫，下水歸我”兜叨，還是“走路功能歸你，吃飯功能歸我”衩侥？

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

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

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

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

評價(jià)：“業(yè)務(wù)”屬于模糊術(shù)語，“架構(gòu)”屬于模糊術(shù)語被环，“業(yè)務(wù)架構(gòu)”屬于模糊術(shù)語糙及。

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

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

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

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

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

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

我懂但不感興趣的知識→業(yè)務(wù)鸽扁；（下單蒜绽、收銀、配送我懂一些桶现，但不感興趣躲雅，這些是業(yè)務(wù)）

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

我不懂且不感興趣的東東→忽悠慰于。（我不懂UML建模钮科，也不感興趣，媽的婆赠，忽悠）

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

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

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

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

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è)樂于做這樣的事——找一些詞匯，并引申出大量微妙而又互相矛盾的含義逮刨。一個最大的受害者就是“架構(gòu)”呕缭。

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

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

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

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

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

圖10 域之間的架構(gòu)躬存，來自taimila.com张惹，非UML圖

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

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

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

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

含義一：組織的內(nèi)部機(jī)制轩褐。此時(shí)椎咧，“業(yè)務(wù)”作“組織”解。圖9就描述了這樣的機(jī)制把介。維基百科采用的就是這種含義勤讽，如圖12。此時(shí)業(yè)務(wù)架構(gòu)師應(yīng)該負(fù)責(zé)的是“A-業(yè)務(wù)建霓痔撸”的工作脚牍。

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

我們再來看一些公司招聘“業(yè)務(wù)架構(gòu)師”（Business Architect）的描述，有的崗位要求還比較貼近“A-業(yè)務(wù)建某彩”诸狭，如圖13券膀。

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

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

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

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

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

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

評價(jià)：“用戶”屬于模糊術(shù)語，“需求”屬于明確術(shù)語昵慌，“用戶需求”屬于錯誤術(shù)語假夺。

用戶（User）。首先斋攀，用戶默認(rèn)是人已卷，沒有稱某個軟件系統(tǒng)為用戶的——“本系統(tǒng)的另一個用戶是第三方支付系統(tǒng)”；其次用戶是和所研究系統(tǒng)有交互的人淳蔼。例如侧蘸，我正在用Word寫這篇文章凛忿，我是Word的用戶乐纸。以上是最常見的理解。

有時(shí)“用戶”也會用在根本沒有人機(jī)交互的地方茴她，如圖15存皂。一個定時(shí)收集信息的系統(tǒng)晌坤，根本不需要和人交互，但需求人員也會說“用戶是怎么要求的旦袋？多長時(shí)間收集一次骤菠？速度要多快？源格式和目標(biāo)格式是怎樣的猜憎？”此時(shí)娩怎，“用戶”不是指和所研究系統(tǒng)交互的人，而是系統(tǒng)所服務(wù)的目標(biāo)組織的某個負(fù)責(zé)和開發(fā)團(tuán)隊(duì)接口的人胰柑。例如截亦，假設(shè)這個系統(tǒng)為某市國稅局服務(wù)的，需求人員剛才說的“用戶”可能是國稅局信息中心的副主任柬讨。怎樣稱呼這位副主任才正確崩瓤，后文再說。

圖15 無人參與交互的收集過程

“用戶”一詞存在的問題：

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

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

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

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

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

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

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

圖18 演員（執(zhí)行者豪嚎，Actor）在臺上表演，觀眾（涉眾谈火，Stakeholder）在臺下看

用例使用“執(zhí)行者”（Actor）和“涉眾”（Stakeholder）代替了原來的“用戶”侈询，這是一個非常大的突破∨此＃“用戶”這個詞混淆了演員和觀眾的區(qū)別扔字。過去經(jīng)常說“找用戶調(diào)研需求”囊嘉，這是錯誤的。所謂“用戶”革为，就是上臺表演的人類演員扭粱。找用戶調(diào)研，相當(dāng)于找演員問劇本應(yīng)該是什么內(nèi)容震檩，豈不是很荒謬琢蛤？劇本應(yīng)該由編劇向觀眾調(diào)研編寫出來，然后由各路演員在臺上演繹抛虏。

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

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

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

另外荒椭，現(xiàn)在的系統(tǒng)做出來谐鼎，越來越多的接口不是面向人類的，而是面向另一個軟件系統(tǒng)趣惠，也就是說沒有“用戶”狸棍。兩個電腦系統(tǒng)交互的需求身害，難道就不用做了，或者可以隨便做隔缀？非也题造。那只是相當(dāng)于上臺表演的不是人傍菇，是功夫熊貓猾瘸、變形金剛和喜羊羊灰太狼，但是臺下對表演說好說壞的觀眾依然是人丢习。建立“執(zhí)行者和系統(tǒng)在臺上表演牵触，涉眾在臺下看表演”的概念，在執(zhí)行者為非人系統(tǒng)時(shí)對捕獲需求很有幫助咐低。

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

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

一個老頭找到PS可樂公司卢未，告訴他們的主管，“我可是你們的忠誠客戶把吆骸辽社！我喝過的可樂罐排成線，可以從蘋果園排到通州（北京從西到東）∏萄迹現(xiàn)在我老了滴铅，我對你們的可樂下一個版本提出如下要求：第一，我有胃病就乓，下一個版本不要有這么多氣汉匙；第二，我有糖尿病档址，下一個版本里面不要有糖盹兢。”PS可樂公司的主管很感動守伸，哇绎秒，這么棒的顧客，把要求提得那么具體尼摹，省下好多我們調(diào)研需求的時(shí)間见芹，好剂娄，下個版本就這么辦！

可惜玄呛，現(xiàn)實(shí)生活中不會有這樣的場景阅懦。老頭老太太可以買可樂喝，甚至可以買給自己的寵物喝徘铝，PS可樂公司不會攔著耳胎。問題在于，老頭老太太提的要求惕它，或者為他們的寵物提的要求（注意用詞：是要求怕午，不是需求），PS可樂公司不會放在重要的位置來考慮淹魄，因?yàn)镻S可樂的目標(biāo)人群是青少年郁惜。可惜甲锡，很多時(shí)候我問需求人員：“可樂賣給誰兆蕉？”得到的回答大多是“賣給消費(fèi)者”，“賣給想喝可樂的人”等對做出好賣的可樂沒有幫助的缤沦、正確而無用的廢話虎韵。

我在《軟件方法》中，用“老大”取代了“用戶”疚俱∪笆酰“老大”是一個真實(shí)存在的具體的人。定位“老大”的具體方法參見《軟件方法》第2章呆奕，和Persona方法類似养晋。但是Persona是虛構(gòu)一個“用戶畫像”，說白了也是鼓勵需求人員逃避深入第一線調(diào)研的辛苦梁钾，安心閉門造車绳泉。例如，為女性做一個產(chǎn)品姆泻，建模人員深入第一線調(diào)研零酪，面對的調(diào)研對象是一個個具體的女性。如果建模人員把調(diào)研的精力花在羅玉鳳身上拇勃，留給林志玲的精力就不多了四苇，所以必須思考羅玉鳳更像老大還是林志玲更像老大的問題。相比起來方咆，關(guān)在辦公室隨意捏造一個符合自己要求的“女性”省事多了月腋。如果滿足于Persona，歸根結(jié)底還是在內(nèi)心里沒有認(rèn)識到深入第一線調(diào)研的重要性。

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

圖19 和對手在老大的大腦里廝殺

需求（Requirement）。明確術(shù)語耿焊，不再單獨(dú)闡述揪惦。

用戶需求。錯誤術(shù)語罗侯。需求指系統(tǒng)對外提供的功能性能器腋，如果要在“需求”前面加一個定語，這個定語是“系統(tǒng)”——“系統(tǒng)的需求”钩杰。

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

那么，“用戶”后面能跟什么呢酬荞？可以跟“要求”搓劫。更嚴(yán)謹(jǐn)?shù)男g(shù)語是“涉眾利益”。需求像電影劇本混巧，涉眾像電影觀眾枪向。劇本只有一份，觀眾卻是多種多樣咧党，不同觀眾的欣賞角度和口味不同秘蛔。魯迅說過：一部紅樓夢，經(jīng)學(xué)家看見《易》傍衡，道學(xué)家看見淫深员，才子看見纏綿，革命家看見排滿蛙埂，流言家看見宮闈秘事倦畅。

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

軟件的需求規(guī)約相當(dāng)于電影劇本奏路。電影劇本不是由觀眾直接提供，而是由編劇根據(jù)不同觀眾的口味編出來的臊诊。同樣鸽粉，軟件需求不是由涉眾直接提供的，而是由需求人員綜合不同涉眾的利益來決定的抓艳。涉眾沒有資格提供需求触机。

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

拿患者和醫(yī)生類比也可以幫助理解舞竿【┚埃患者到醫(yī)院對醫(yī)生說“我腿疼，可能得了腿癌骗奖，我要做放療”确徙，醫(yī)生就給他做放療？顯然不是這樣重归，醫(yī)生只能把患者所說的一切當(dāng)成素材米愿，按照成熟的套路，該做什么檢查就做什么檢查鼻吮，該如何治療就如何治療。

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

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

術(shù)語04：文檔

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

先列出使用“文檔”的一些話語：

你們怎么一上手就寫代碼悼吱，連個文檔都沒有慎框！

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

代碼就是文檔笨枯。

從以上話語可以看出以下問題：

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

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

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

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

這樣的誤解就會導(dǎo)致推論：只要“代碼”寫得自己“會說話”跟压，那么“代碼就是文檔”胰蝠，“文檔”就不需要了。本來“文檔”就是“代碼以外的其他東西”震蒋，這么一推茸塞，就變成了“代碼就是一切”。

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

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

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

是否系統(tǒng)的用例應(yīng)該以“好賣”來判斷丐枉。權(quán)衡涉眾利益之后覺得應(yīng)該有，系統(tǒng)就有掘托，不該有就沒有瘦锹，而不是我寫好了代碼，所以就應(yīng)該有闪盔。

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

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

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

（4）“文檔”還意味著它和“代碼”使用的可能是不同的工具寫出來的塔拳。在Visual Studio鼠证、Eclipse里面寫出來的叫“代碼”，在Word靠抑、wiki量九、Visio、EA等等里面寫或者畫出來的叫“文檔”颂碧。

正確的理解是：

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

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

如果清楚了解“區(qū)別在于內(nèi)容”這一點(diǎn)，就知道“我在寫文檔”這樣的話只是表達(dá)“我正在用文檔編輯工具在工作”戚宦，沒有其他意義个曙。你在寫什么文檔？“業(yè)務(wù)建氖苈ィ”垦搬？“需求”？“分析”艳汽？“設(shè)計(jì)”猴贰？我不寫，我畫圖難道不可以嗎河狐？我不寫不畫米绕，我用語音清楚地表達(dá)出組織的流程瑟捣，不可以嗎？更有意義的說法應(yīng)該是“我在做業(yè)務(wù)建恼じ桑”迈套。如果說“文檔”二字可以給您帶來不可替代的快感，可以說“我在寫業(yè)務(wù)建模文檔”碱鳞。

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

如圖21所示磷蜀，最初的源代碼是機(jī)器語言。程序員在紙帶或卡片上打孔來表達(dá)0和1百炬。后來發(fā)現(xiàn)這樣太累了褐隆，于是發(fā)明了一些助記符，這就是匯編語言剖踊。 今天會有開發(fā)人員故意裝×庶弃，“這些我不太懂唉，我是做底層的德澈，用C編碼”歇攻，可是C語言卻被歸類為“高級語言”，因?yàn)轭愃艭這樣的語言出現(xiàn)的時(shí)候梆造， 大多數(shù)程序員編輯的是匯編語言缴守，C相對于匯編來說，當(dāng)然很高級镇辉。今天的一名企業(yè)應(yīng)用程序員屡穗，最終需要編輯的可能有 HTML、CSS忽肛、JavaScript村砂、Java、配置腳本屹逛、SQL等础废，這些就是現(xiàn)在的“源代碼”的形式汛骂。

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

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

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

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

我們在使用UML建模的時(shí)候，各種建模元素和建模內(nèi)容也是靈活匹配的池颈。例如尾序，狀態(tài)機(jī)圖，可能一看到就想起分析設(shè)計(jì)躯砰，其實(shí)也可以用來表達(dá)需求每币。圖23把“電視”作為整體來畫狀態(tài)機(jī)，表達(dá)的就是“電視”的需求琢歇。

圖23 用狀態(tài)機(jī)圖表達(dá)電視的需求（讀者可以自行思考圖中脯爪？處應(yīng)該寫什么】笪ⅲ看起來一目了然，其實(shí)寫對不容易尚揣。）

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