# 七、輕松寫就功能規格說明書 - 第3節：但是……如何？ 現在你已經讀過為什么要規格和規格里有什么，可以來談談什么人該寫規格. 誰在寫規格？ 請容我在此提一點微軟的歷史.1980年代當微軟開始快速成長時，那里每個人都 讀過The Mythical Man-Month這本軟件管理經典(如果你還沒讀過這本書，我可 是極度推薦）.這本書的主要重點是說，在進度落后的項目中增加更多程序員， 只會讓進度更加落后.這是因為當團體中有n個程序員時，溝通路徑的數量會變 成n(n-1)/2,也就是以0(n2)增加. 既然當時眾所周知增加程序人員只會讓事情更糟，所以微軟的程序人員都在思 考要如何撰寫更大的程序. 擔任微軟〃主設計師〃多年的Charles Simonyi提出了主程序員的概念.這個點子 基本上是讓一個主程序員負責撰寫所有程序，不過他或她底下有整組充當〃程序 奴隸”的菜鳥程序員.主程序員不必費心替每個函數除錯，而是定出各個函數的 原型，建立基本結構再丟給菜鳥程序員實作（理所當然的，Simonyi會是最大的 主程序員）.主程序員這字眼有點古老，所以微軟用的詞是〃程序經理(Program Manager)”. 理論上這應該能解決Mythical Man-Month的問題，因為大家不需要互相溝通(各 個菜鳥程序員都只和程序經理溝通），所以溝通路徑是以O(n)而非O(n2)成長. 哎呀，Simonyi可能精通匈牙利表示法，不過他不懂Peopleware.沒有人會想當 寫程序奴隸的.這種系統根本行不通.最后微軟發現，盡管有著所謂人月神話 (Mythical Man Month)的問題，還是能在團隊中增加聰明人而提升產出，不過邊 際價值也會減少.我待在Excel團隊時里面有50個程序員，生產力的確比25個人 團隊高(不過沒有多到兩倍）. 主奴式程序作業的點子行不通，不過微軟里面還是有一堆叫程序經理的人跑來 跑去.有個叫Jabe Blumenthal的聰明人重新創造了程序經理這個職位.從此之 后程序經理就負責產品的設計及規格. 自此至今，微軟的程序經理就是在搜集需求，定義程序應有作用并撰寫規格.每 個程序經理通常配5位程序員；程序經理以規格方式定義產品，而程序員則負責 以程序實作寫出產品.程序經理也必須負責協調營銷，文件撰寫，測試，地區 化，以及程序員不會花時間處理的其他煩瑣細節.最后當程序員只要全心貫注 讓程序正確無誤時，微軟的程序經理還得心系公司的〃遠景”. 程序經理是非常寶貴的.如果你曾經抱怨程序員太重視技術優雅而忽略市場性， 你需要程序經理.如果你曾抱怨大家寫得一手好程序卻寫不出好中文，你需要 程序經理.如果你曾抱怨產品方向不明確，你需要程序經理. 你要如何雇到一個程序經理呢？ 大部份公司甚至沒有程序經理的概念.我覺得這實在是太糟糕了.當我在微軟工 作時，公司內程序經理很強的團隊都有非常成功的產品（比如Excel，Windows 95, Access).不過其他團隊(如MSN 1.0和Windows NT 1.0)則的領導人通常忽視程序 經理角色(這些程序經理反正也不是很優秀，或許本來就該被忽視），而他們的 產品就沒那么成功了. 下面列出必須避免的三件事. 1.不要把程序員升為程序經理.良好程序經理所需的技能(撰寫清楚的中文，外 交手腕，對市場的察覺，對使用者的認同以及良好的使用接口設計)幾乎都不是 良好程序員所需的.當然有人兩者都行，不過少之又少.為了獎勵好程序員而把 他升到不同的職位(一個改去寫中文而非C++的位子），這是個Peter Principle 的典型例子：人們通常會被擢升到他們無法勝任的階層. 2.別讓營銷人員當程序經理.這沒有不敬的意思，不過我認為我的讀者應該會 同意，好的營銷人員很少能好好掌握產品設計的技術性問題. 程序管理基本上是完全不同的職業生涯.程序經理一定都是很技術性的，不過 卻不必是個好的程序人員.程序經理會研宄使用接口接觸客戶并且撰寫規格.他 們必須與各式各樣的人為伍，由”白癡”客戶到穿著星艦制服上班，孤癖又惹人 厭的程序員，還有身穿2000美元套裝大擺架子的銷售人員.就某方面而言，程序 經理相當于軟件團隊的黏著劑.所以領導魅力非常重要. 3.別讓程序人員對程序經理報告.這是很微妙的錯誤.我在微軟當程序經理時 設計了Excel的Visual Basic(VBA)策略，并且訂出涵蓋最微小細節的完整規格， 詳細敘述應該如何在Excel里實作VBA.我的規格大約有500頁.在Excel 5.0開發 的巔峰時期，我估計每天早上有250人來上班，主要任務就是要實作我寫的這份 龐大規格.我完全不知道這些人是誰，不過Visual Basic組就有十幾個人光是在 寫這玩意的文件(更不用提寫Excel的文件或是全職負責說明檔內超鏈接的人了）. 不過最夸張的是我位在這層層結構的”底層沒錯.沒有人要向我報告.如果想 讓大家去做某件事，我必須說服他們這件事該做.當主開發師Ben Waldman不想 做我規格定義的某個項目，他跳過不做就好了.當測試人員報怨規格中某個項 目不可能做完整的測試，我就得去把這個項目簡化.如果這些人得向我報告， 產品可能不會這么好.因為有些人可能會認為對上司放馬后炮不太好.另外我也 可能堅持己見，獨斷短視地命令他們照我的方式進行.這樣做的話就不可能有 機會建立共識.而凝聚共識的決策型式卻是做對事的最好方法.