關鍵字：軟件開發中 角色
因為人的靈魂中，有著某種三頭政體，或者說，三個對手，三重政權，它之擾亂這一共和國的安寧，并不減于它之攪擾羅馬的國制。 托馬斯·布朗 《醫生的宗教》I.19
1
“三”據說是玄學家們偏愛的數字。對于這種怪癖或狂熱，我只能自認免疫力不足：在“三段論、三權分立、三位一體...”這個似乎無休止的列表上，我甚至想再加上一點兒自己的貢獻——在我看來，通常稱為“軟件工程”的學科至少包括三個重要的組成部分：產品設計、系統構架設計和項目控制，而相應地，軟件開發隊伍中也有三個重要角色：產品經理、系統架構師和項目經理。
《人月神話》一書的讀者都能理解“概念完整性”對于軟件系統的重要性。概念完整性指的是，軟件系統作為一個整體，對于使用者體現出的概念上的一致性、清晰度和簡潔度。按照該書作者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個人以上），這些雜務本身就能占用一個全職工作者的幾乎全部時間。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
