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