作者：naven? 2005-5-10
“
軟件工程
”
的學(xué)科至少包括三個重要的組成部分：產(chǎn)品設(shè)計、系統(tǒng)構(gòu)架設(shè)計和項目控制，而相應(yīng)地，軟件開發(fā)隊伍中也有三個重要角色：產(chǎn)品經(jīng)理、系統(tǒng)架構(gòu)師和項目經(jīng)理。這三個角色直接關(guān)系著項目的成功或失敗。以下是對這三個角色的分工的具體介紹：（部分摘自《程序員》，作者：劉天北）
?
《人月神話》一書的讀者都能理解“概念完整性”對于軟件系統(tǒng)的重要性。概念完整性指的是，軟件系統(tǒng)作為一個整體，對于使用者體現(xiàn)出的概念上的一致性、清晰度和簡潔度。按照該書作者
Brooks
的看法，概念完整性是設(shè)計軟件時需要考慮的首要因素，而為了確保概念完整性，應(yīng)該要求：
1
）區(qū)分系統(tǒng)設(shè)計和系統(tǒng)實現(xiàn)工作；
2
）系統(tǒng)設(shè)計的工作由一個人或不多的幾個達成共識的人完成。這里談的“系統(tǒng)設(shè)計”，基本上對應(yīng)于我說的“產(chǎn)品設(shè)計”，即，確定軟件系統(tǒng)的功能、性能指標、交互模式等方面的需求。質(zhì)言之，產(chǎn)品設(shè)計者決定“做什么”的問題，而把“怎么做”的問題留給實現(xiàn)人員（
implementers
）來完成。
這樣就引入了第一組工作劃分。這里的重點是，產(chǎn)品設(shè)計應(yīng)該由專人負責，而不是交給“程序員”代庖。相反的實踐，即讓具體開發(fā)者確定產(chǎn)品設(shè)計細節(jié)的做法，在國內(nèi)軟件業(yè)似乎仍很常見，但正如《人月神話》所言，這是一種非常危險的嘗試。首先，如果產(chǎn)品的各個設(shè)計細節(jié)由多個開發(fā)者按各自的設(shè)想確定，那么概念完整性就幾乎一定會被破壞。其次，具體開發(fā)者往往更注重系統(tǒng)實現(xiàn)中的技術(shù)因素，而對最終使用者的需求、動機和感受都缺乏體認，因而單純出自程序員的產(chǎn)品設(shè)計，總是會偏離使用者對業(yè)務(wù)和易用性的實際需要，很難獲得用戶的欣賞——有一個略顯過分的比喻甚至說，讓程序員做產(chǎn)品設(shè)計，無異于讓精神病患者們自己運營瘋?cè)嗽骸?/span>
而談到產(chǎn)品設(shè)計或系統(tǒng)需求確定，另一種流行的誤解是，這應(yīng)該是客戶的任務(wù)：“需求調(diào)研人”至多需要記錄下客戶的所有需求，就能形成完美的需求規(guī)格設(shè)計書。天知道（至少，任何做過委托開發(fā)的人都知道）這種論調(diào)和國內(nèi)客戶的實際情況之間的差距。不止一次，我拿到的全部客戶需求就是：開發(fā)一套電子商務(wù)系統(tǒng)。句號。設(shè)計產(chǎn)品或確定系統(tǒng)需求不僅需要行業(yè)、領(lǐng)域經(jīng)驗（這是“客戶”的優(yōu)勢所在），更需要大量同類系統(tǒng)的使用經(jīng)驗（甚至開發(fā)經(jīng)驗）以及較強的抽象能力、表達能力等等。而目前很多客戶，由于接觸同類系統(tǒng)有限，自身業(yè)務(wù)流程也遠未標準化，若指望他們提出清晰、明確的需求，好比是讓一個只會喊“餓”的小孩兒進飯館點菜。開發(fā)團隊必須委派專人，通過耐心誘導(dǎo)和反復(fù)嘗試才能獲知他們的實際需要。
負責產(chǎn)品設(shè)計的“專人”通常稱為“產(chǎn)品經(jīng)理”。理想的產(chǎn)品經(jīng)理，應(yīng)同時具備較高的商業(yè)素質(zhì)和較強的技術(shù)背景。
具體地說，首先，一個優(yōu)秀的產(chǎn)品經(jīng)理要有深厚的領(lǐng)域經(jīng)驗，也就是說，對該軟件系統(tǒng)要應(yīng)用到的業(yè)務(wù)領(lǐng)域非常之熟悉。比如，開發(fā)房地產(chǎn)銷售軟件的產(chǎn)品經(jīng)理，應(yīng)該對房地產(chǎn)公司的標準銷售流程了如指掌，甚至比大多數(shù)銷售人員還要清楚。如果開發(fā)的是通用產(chǎn)品，他
/
她還具備對市場、潛在客戶需求的深刻洞察力。
其次，他
/
她應(yīng)該善于完成從使用者視角到開發(fā)者視角的轉(zhuǎn)化，善于將繁復(fù)的實際業(yè)務(wù)抽象為概念模型和人機交互操作。
再次，他
/
她在技術(shù)方面也應(yīng)該具備足夠的知識，能對特定需求的可行性做出初步的衡量，能夠做出方案選型的抉擇。功能需求往往符合
Pareto's Principle
（
20-80
原則），怎樣設(shè)計一個開發(fā)代價最小，而覆蓋需求最多的功能集，怎樣確定各個功能在實現(xiàn)時的優(yōu)先度，是產(chǎn)品經(jīng)理必須懂得的藝術(shù)。另外產(chǎn)品經(jīng)理應(yīng)該知道采用特定開發(fā)平臺、特定工具產(chǎn)品的優(yōu)勢和代價，并從商業(yè)角度出發(fā)做出選擇。
最后，他
/
她還應(yīng)該能夠確定系統(tǒng)在人機交互方面的主要特征。程序員設(shè)計的產(chǎn)品為世人譏評，很大程度上要歸咎于糟糕的交互（
UI
）設(shè)計。產(chǎn)品經(jīng)理應(yīng)該能夠從商業(yè)角度出發(fā)，了解特定客戶
/
潛在客戶群在人機交互方面的需求，并能衡量特定的人機交互模式的實現(xiàn)難度——在很多場合中，某個微小的操作模式的變化會導(dǎo)致整個系統(tǒng)實現(xiàn)構(gòu)架的變化，因此，盡早確定
UI
的主要特征，并要求它們在整個系統(tǒng)內(nèi)保持一致，對于概念完整性和系統(tǒng)技術(shù)構(gòu)架都是至關(guān)重要的。
對一次軟件開發(fā)來說，產(chǎn)品設(shè)計是源頭，是核心。因而產(chǎn)品經(jīng)理的工作質(zhì)量也直接關(guān)系到開發(fā)的成敗。記得一位業(yè)內(nèi)資深人士曾說，合格的產(chǎn)品經(jīng)理需要一份
MBA
學(xué)歷，再加上原先若干年的技術(shù)開發(fā)經(jīng)驗。
綜合考慮以上素質(zhì)，我相信他提出了相當中肯的要求。
?
系統(tǒng)構(gòu)架，是對已確定的需求的技術(shù)實現(xiàn)構(gòu)架。與產(chǎn)品設(shè)計相比，系統(tǒng)構(gòu)架設(shè)計的工作更明確，而目前該領(lǐng)域也已經(jīng)形成了較為成熟、完善的方法論和一整套易于掌握、傳授的知識。相應(yīng)地，系統(tǒng)架構(gòu)師是一個不折不扣的技術(shù)人員，主要著眼于系統(tǒng)的“技術(shù)實現(xiàn)”。他
/
她的責任是最終確認和評估系統(tǒng)需求，給出開發(fā)規(guī)范，搭建系統(tǒng)實現(xiàn)的核心構(gòu)架，并澄清技術(shù)細節(jié)、掃清主要難點。因此他
/
她應(yīng)該是特定的開發(fā)平臺、語言、工具的大師，對常見應(yīng)用場景能馬上給出最恰當?shù)慕鉀Q方案，同時要對所屬的開發(fā)團隊有足夠的了解，能夠評估自己的團隊實現(xiàn)特定的功能需求需要的代價。
這里，最容易導(dǎo)致誤解的部分是產(chǎn)品經(jīng)理和系統(tǒng)架構(gòu)師的區(qū)別。我感到現(xiàn)有的不少論述和實踐都傾向于將二者混為一談。但在我看來，如果把開發(fā)軟件比作攝制電影，產(chǎn)品經(jīng)理之于系統(tǒng)架構(gòu)師，就正像編劇之于導(dǎo)演。產(chǎn)品經(jīng)理雖然要有一定技術(shù)背景，但仍應(yīng)屬于“商業(yè)人士（
business people
）”，而系統(tǒng)架構(gòu)師則肯定是一個技術(shù)專家。
二者看待問題的立場、角度和出發(fā)點完全不同。當然，就像有時電影導(dǎo)演也出任編劇（甚至存在“作家電影”流派），對于特定的開發(fā)領(lǐng)域或項目，產(chǎn)品經(jīng)理和系統(tǒng)架構(gòu)師這兩種角色的重合也可能是無害、甚至有益的（我能想到的一個領(lǐng)域是編程語言的設(shè)計），但即使如此，不加區(qū)別地對待需求和實現(xiàn)、產(chǎn)品設(shè)計和系統(tǒng)構(gòu)架設(shè)計，肯定是危險的。如果你處在一人權(quán)充兩種角色的情況下，你應(yīng)該時刻意識到自己目前進行的是哪一種職責，并據(jù)此調(diào)節(jié)視角和思路。
我感到這兩種角色的含混還來自人們對“
architect
”這個表達方式的不同用法。
Architect
和
architecture
，這組顯然是借自建筑學(xué)的隱喻，經(jīng)常被不加區(qū)別地使用在產(chǎn)品設(shè)計和技術(shù)實現(xiàn)這兩個不同的方面。
Brooks
本人在《人月神話》做出的“
architect
”和“
implementer
”區(qū)分，基本上對應(yīng)于我在上面談到的“產(chǎn)品設(shè)計”和“技術(shù)實現(xiàn)”，但是由于“技術(shù)構(gòu)架”本身也可以稱作
architecture
，所以一般談到
system architecture
或
system architect
時，人們關(guān)注的卻主要是技術(shù)實現(xiàn)方面。正如
Martin Fowler
所說，人人都想被稱為
architect
而不只是
engineer
，所以這里用語的含混可能也體現(xiàn)了不同領(lǐng)域的人們對
architect
這個好詞的爭奪。
如果繼續(xù)上面的電影隱喻，那么攝制組中的“制片”職責也就對應(yīng)于我所說的“項目控制”。顯而易見，項目控制工作與上面談到的產(chǎn)品設(shè)計、構(gòu)架設(shè)計都不同，如果說產(chǎn)品設(shè)計偏重于“商業(yè)”、系統(tǒng)構(gòu)架設(shè)計偏重于“技術(shù)”，那么項目控制注重的就是“管理”。它主要關(guān)注的是項目本身的進度、質(zhì)量等方面。軟件開發(fā)項目需要專人負責這些內(nèi)容，我愿意稱此為“項目經(jīng)理”。
項目控制
/
管理已經(jīng)形成了一個專門的學(xué)科（
Project Management
），對于軟件項目經(jīng)理，其職責也未脫離該學(xué)科的描述，包括項目計劃、進度跟蹤
/
監(jiān)控、質(zhì)量保證、配置
/
發(fā)布
/
版本
/
變更管理、人員績效評估等方面。優(yōu)秀的項目經(jīng)理需要的素質(zhì)，并不僅在于會使用幾種軟件或是了解若干抽象的方法論原則，更重要的在于從大量項目實踐中獲得的寶貴經(jīng)驗，以及交流、協(xié)調(diào)、激勵的能力，甚至還應(yīng)具備某種個性魅力或領(lǐng)袖氣質(zhì)（
charisma
）。通俗地說，也許學(xué)校里的學(xué)生會主席要比“學(xué)習尖子”更適合這樣的職位。
由此可見，項目經(jīng)理和系統(tǒng)架構(gòu)師在職責上有很大差異。混同這兩個角色，往往也會導(dǎo)致低效、無序的開發(fā)
。特別是，從性格因素上講，單純的技術(shù)人員傾向于忽視“人”的因素，而這正是管理活動的一個主要方面。另外，就像戰(zhàn)爭中的空軍掩護（
air cover
）一樣，專職的項目經(jīng)理能夠應(yīng)付開發(fā)過程中大量的偶發(fā)事件和雜務(wù)，對于一個規(guī)模稍大的項目（《人月神話》似乎說的是
6
個人以上），這些雜務(wù)本身就能占用一個全職工作者的幾乎全部時間。
?
1、?
產(chǎn)品經(jīng)理（
Project Engineer
）：負責產(chǎn)品的設(shè)計，包括
UI
、功能和其他產(chǎn)品的方方面面，主要是從用戶角度和市場角度規(guī)劃產(chǎn)品的“模樣”。負責“是什么”。
2、?
系統(tǒng)架構(gòu)師（
System Architector
）：負責產(chǎn)品的實現(xiàn)，主要是產(chǎn)品的技術(shù)實現(xiàn)的架構(gòu)，使用什么技術(shù)、模塊的設(shè)計、接口的設(shè)計及模塊的協(xié)作等。負責“怎么做”。
3、?
項目經(jīng)理（
Project Manager
）：負責項目實施的總控，保證各個資源的合理分配，掌控項目的總體進度。
4、?
系統(tǒng)設(shè)計師（
System Designer
）：負責對系統(tǒng)架構(gòu)師分配的工作和模塊在架構(gòu)的師設(shè)計的范圍內(nèi)進行具體的設(shè)計和規(guī)劃，分離出小的功能，詳細到函數(shù)，即詳細設(shè)計。
5、?
開發(fā)人員（
Programmer
）：負責對系統(tǒng)設(shè)計師分配的工作的實現(xiàn)，即編碼開發(fā)。
6、?
測試人員（
Tester
）：這是另一獨立的角色，真正的測試人員的工作應(yīng)該從項目發(fā)布
BETA
版時開始各個方面全面的測試和評估。
BETA
版之前的測試工作應(yīng)該由上面的角色完成。
?
仍以電影的制作比喻：產(chǎn)品經(jīng)理相當于編劇，系統(tǒng)架構(gòu)師相當于導(dǎo)演，項目經(jīng)理相當于制片，系統(tǒng)設(shè)計師相當于燈光、場景等負責人，開發(fā)人員相當于具體的演員，而測試人員相當于電影局的審查人員。
?
一個較大項目的進行，必須要具備這些不同角色各自負責不同工作的人員組成，即使某個人綜合了不同角色的工作，工作也應(yīng)該如此合理分配。各人的職責也不應(yīng)該混繞交叉，比如：產(chǎn)品經(jīng)理不應(yīng)該關(guān)注實現(xiàn)的技術(shù)，架構(gòu)師也不應(yīng)該關(guān)注資源的配置（但他要充分理解產(chǎn)品經(jīng)理的意圖），項目經(jīng)理則不應(yīng)該干涉產(chǎn)品的設(shè)計及實現(xiàn)。另外一種情況，項目經(jīng)理主要是總控項目的進展，但不應(yīng)該自行評估整個項目工程的工時。評估項目的工時需要項目經(jīng)理和產(chǎn)品經(jīng)理、架構(gòu)師通盤考慮，綜合各方面因素得出，甚至需要系統(tǒng)設(shè)計師參與。架構(gòu)師負責整個項目實現(xiàn)的預(yù)計工時的估算，系統(tǒng)設(shè)計師估算自己的模塊內(nèi)部的預(yù)計工時，而項目經(jīng)理負責估算其他不定因素的工時（如開會、審批等），把這些綜合在一起才能評估出真實的項目工時。任何一個人都不應(yīng)當去獨立評估全部的項目工時，或者評估別人工作的工時。只有這樣分工明細且協(xié)調(diào)配合才能保障項目的成功實施。
?