無痛功能規格 - 第三篇：不過...要怎麼做呢？ Painless Functional Specifications – Part 3: But… How?

現在你已經讀過為什麼要規格和規格裡有什麼，可以來談談什麼人該寫規格。

誰在寫規格？

請容我在此提一點微軟的歷史。1980年代當微軟開始快速成長時，那裡每個人都讀過 The Mythical Man-Month 這本軟體管理經典(如果你還沒讀過這本書，我可是極度推薦)。這本書的主要重點是說，在進度落後的專案中增加更多程式員，只會讓進度更加落後。這是因為當團體中有 n 個程式師時，溝通路徑的數量會變成n(n-1)/2，也就是以 O(n²) 增加。

既然當時眾所周知增加程式人員只會讓事情更糟，所以微軟的程式人員都在思考要如何撰寫更大的程式。

擔任微軟「主設計師」多年的 Charles Simonyi 提出了主程式師的概念。這個點子基本上是讓一個主程式師負責撰寫所有程式，不過他或她底下有整組充當「程式奴隸」的菜鳥程式員。主程式師不必費心替每個函數除錯，而是定出各個函數的原型，建立基本結構再丟給菜鳥程式員實作(理所當然的，Simonyi會是最大的主程式師)。主程式師這字眼有點古老，所以微軟用的詞是「程式經理(Program Manager)」。

理論上這應該能解決 Mythical Man-Month 的問題，因為大家不需要互相溝通(各個菜鳥程式員都只和程式經理溝通)，所以溝通路徑是以O(n)而非O(n²)成長。

哎呀，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 不想做我規格定義的某個項目，他跳過不做就好了。當測試人員報怨規格中某個項目不可能做完整的測試，我就得去把這個項目簡化。如果這些人得向我報告，產品可能不會這麼好。因為有些人可能會認為對上司放馬後炮不太好。另外我也可能堅持己見，獨斷短視地命令他們照我的方式進行。這樣做的話就不可能有機會建立共識。而凝聚共識的決策型式卻是做對事的最好方法。

規格系列的最後一篇要討論如何寫出大家想看的優質規格。

這些網頁的內容為表達個人意見。
All contents Copyright © 1999-2006 by Joel Spolsky. All Rights Reserved.