論軟體開發中的三種重要角色(轉)

論軟體開發中的三種重要角色
...因為人的靈魂中，有著某種三頭政體，或者說，三個對手，三重政權，它之擾亂這一共和國的安寧，並不減於它之攪擾羅馬的國制。
----托馬斯·布朗 《醫生的宗教》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個人以上），這些雜務本身就能佔用一個全職工作者的幾乎全部時間。

2。也許我已經論證了上述三種角色分工的必要性。籠統地說，正如其他人類制度一樣，分工自身也同時具有益處和代價。如果允許一個空泛的概括，分工的優點至少有：

1）集中特定的知識、技能——想想自己左右手、左右腦的分工，我們也許就可以理解這對提高生產率的重要性；

2）職責明確，不同職責的人為自己做出的決定負責；

3）增進交流：各個角色之間為確保順暢的協作，必須要求高質量的交流，這也就能使很多原本不言而喻的事情書面化、明晰化。

但分工也有其自身的弊病。首先，不少人天性追求完滿，要讓他們接受分工，只完成整個工作的一個枝節部分，可能是非常痛苦的事。我記得自己剛剛參加工作後參與開發的一個系統，直到開發接近尾聲，專案經理才在一次每週例會上說：“大家開發了這麼久，對整個系統的用途可能還不很清楚，今天我們簡單談談”——這時我才知道自己參與的是整個店鋪系統的銷售子系統的訂貨部分的一個底層資料模組。

另外，分工往往導致等級制度和不同角色間的疏離。既然分工的要義是把高要求的工作集中在少數人手中，在少數和大多數之間，不同的工種之間，必然會導致等級差異和隔閡。《人月神話》中也談到，在區分了產品設計和技術實現之後，單純的實現者會感到僅僅聽命於人，常常缺乏獨自開發時的“成就感”。這也是素樸的、混沌未開的開發過程一旦引入分工，就必然產生的異化。

如果說，上面談到的這兩點還應該算是人類各種分工制度共有的“必要的惡”，軟體開發中的分工還有一種特有的弊端：細緻的分工與“重量級方法論”之間有很強的親和性，傾向於導致更高的開發成本和開發風險。

對於產品設計和系統構架設計來說，將決策權集中在產品經理和系統架構師手中，意味著一種集權式的專制體制。這也要假設，這些負責人對產品或系統構架具備了充分的、無遺漏的瞭解。整個系統從他們頭腦中的理念萌芽演化，再通過文件等介質，最終被實現為軟體產品。如果產品經理確實能夠從一開始就清晰、完整地把握客戶需求，選定的開發平臺、技術對系統架構師也不存在任何難點，那麼類似的集權制可能是合理而且高效的。但軟體開發往往充滿革新和變數，客戶需求一日千變，開發技術也日新月異，大量不確定因素的引入，使集權體制變得非常可疑。如果需求和設計無法自頂向下、一步到位的給出，而是需要多次反覆、迭代才能漸趨完善，那麼一個多級的、細分工的開發體制與扁平的、粗分工的體制相比，就需要更大的初期代價（initial investment），更多的文件和交流，並缺乏後者靈活、自適應的應變能力。

極限程式設計（XP）方法論，就在很大程度上抵制了上面提到的分工體制。

XP開發過程中用“素材（user stories）”取代了需求規格設計書（SRS）。一組由“客戶”粗略書寫的素材，直接由程式設計師加以評估和實現，並根據現場客戶（on-site customer）意見修改。因此上面所說的產品經理角色，就被客戶和程式設計師之間的合作完全取代了：無須產品經理給出細化、明晰的需求，只要程式設計師體會素材中的意思，做出實現，再通過客戶反饋逐次迭代，就能獲得不錯的系統。

而系統架構師在XP方法論中也沒有容身之處。系統構架不再是充分設計的產物，而是一個不斷演進、不斷完善過程的結果。具體的決策權留給了程式設計師自身，團隊中的頂尖程式設計師不再充當系統架構師，而是擔任“教練（coach）”的角色，啟發新手自己找到合適的構架，並在確實困難的時候扮演救火者。

事實上，傳統的“按照藍圖設計建築物”的隱喻在XP方法論中失去了價值。對比一下《人月神話》和《XP Explained》中“architect”一詞的出現頻率（在後者中我只發現了兩次，而且用的都是否定意義），我們就可以發現這種態度上的變化。取而代之的是某種自適應的、漸進式的開發過程。因此，很難說XP方法論中包含完整意義上的“產品設計”或“系統構架設計”工作。

相對而言，專案控制工作仍然在XP方法論中具有重要意義。只是這裡更強調，程式設計師的身上的責任是他/她主動接受而來的，而不是強加的（accepted responsibility, not given），因此對於任務的分配、專案進度的估算都由程式設計師首先決策，而不是由管理者直接指派。專案管理者被稱為“跟蹤員（tracker）”。他/她負責監督專案進度，並通過各種衡量尺度，及時地將情況反映給開發者自身（比如提示目前的開發進度是提前還是落後於時間表）。這樣的職責被形象地比喻為“鏡子（mirror）”。

3。從表面上看，XP方法論似乎抵制了傳統的分工體制。但是，仔細考察就能發現，這裡仍保留著對“商業”、“技術”和“管理”三種職責的劃分，而“客戶”、“教練/顧問”和“跟蹤員”身上也還存有一些我們熟悉的角色的痕跡。只不過，決策權被最大限度地交給了實際開發人員。這是一種“輕裝上陣（travel light）”式的開發體制。受益於扁平的權力結構，開發者能夠以最小的初期代價開始開發，並及時反饋客戶意見和變更需求。

在此我樂意給XP方法論和傳統分工體制的區別做一個淺顯的哲學解釋。柏拉圖以來的一派哲學認為理念/本質（eidos）先於、而且高於實際事物。以建築為例，抽象、初始的藍圖中蘊含了建築物的整個存在。本質主義傾向於認為本質是靜止而奧妙的，只能為少數人所領會，而把握了本質，也就窮盡了事物的一切方面和一切發展可能。由此，傳統的集權式分工體制就對應於這種本質主義態度。

另一方面，不少人也認為，很多事物無本質可言，事物並非在初始、根源中就蘊含了其後的所有變數，而是一直處於偶然、不可預知的演進之中。如果一個事物漸趨完善，那也不是因為它達到了自身的本質，而是在反覆嘗試-修改之中，在對於外界變化的不斷自適應調整之中逐步發展的結果。顯然，XP方法論更接近於這種非本質主義的漸進論態度。

不同哲學態度之間的爭論，似乎已經有兩千年以上的歷史，至今仍是教授們熱衷的論文題目。在實踐中，人們可能在某些場景下偏愛本質論，在其他地方則倒向漸進論。無論如何，二者都已成為我們重要的思想資源。而不同方法論之間的優劣看似比這更為顯而易見。通常的論調是，隨著新方法論的問世，舊方法論也失去了原來的價值。軟體行業在方法論上的逐新傾向，似乎與時尚女性對衣著的關注屬於同一個病理學範疇。

而以我個人所見，不同方法論的有效性，只能根據具體情形判斷。XP方法論對變化的擁抱和對輕裝上陣的強調固然可喜，但是，在不少場合，它的分工原則也是可疑、甚至成問題的。比如說，XP開發過程中“客戶”扮演著非常重要的角色。而一旦缺乏現場客戶的支援，或是客戶不具備完成“素材”的能力，自適應的需求獲取就很難奏效。再如，與集中決策相比，分散決策雖然能夠鼓舞士氣，但產品的概念完整性和技術構架的一致性都會受到威脅。一個專職的產品經理肯定會比客戶、程式設計師的合作更能有效地設計出簡潔、明確的人機互動模式。

也許，在需求不確定的場合，或是當團隊中沒有哪個開發者在產品設計/系統構架設計方面有足夠經驗時，採用XP模式開發是規避風險的最優選擇。在變數較大的情形下，如果沿用傳統的重量級方法論，勢必大量的前期文件、設計工作在多次迭代中被拋棄，從而導致高昂的投入。但是，當業務需求清晰，團隊較為成熟時，傳統的分工體制不失為穩健、高效的工作模式。另外，不同的開發領域也會對分工產生不同形式的要求。遊戲開發的團隊構成肯定與嵌入式開發不同，這二者又都與企業應用開發相差很遠。如果根據某個先驗的“軟體”定義，而推匯出所有這些領域都共通的方法論原則，那隻能是上面提到的“本質主義”幽靈對我們心智的一次最新侵襲。

就我個人熟悉的企業應用領域而言，一個優秀的領域專家/產品經理能保證較高的成功率。另外，快速原型法（而不是簡單的user stories）、迭代式的釋出計劃（而不是一步到位）、成熟的技術框架（而不是每次都從頭設計）和溫和的專案管理（而不是盲目施加壓力）能起到正面作用。如果允許比喻的話（就像我們在其他拙於描述的場合做的那樣），我感到與寫詩、談戀愛或練氣功相比，這個領域的軟體開發更接近於寫長篇小說、設計建築或拍電影的過程。

這是我的意見。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7942439/viewspace-21370/，如需轉載，請註明出處，否則將追究法律責任。