無痛功能規格 - 第三篇:不過...要怎麼做呢?

作者:周思博 (Joel Spolsky)
譯:Paul May 梅普華
編輯:Jeff Wang 王家麒
October 4, 2000

A part of Joel on Software, http://www.joelonsoftware.com


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

誰在寫規格?

請容我在此提一點微軟的歷史。1980年代當微軟開始快速成長時,那裡每個人都讀過The Mythical Man-Month這本軟體管理經典(如果你還沒讀過這本書,我可是極度推薦)。這本書的主要重點是說,在進度落後的專案中增加更多程式員,只會讓進度更加落後。這是因為當團體中有n個程式師時,溝通路徑的數量會變成n(n-1)/2,也就是以O(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不想做我規格定義的某個項目,他跳過不做就好了。當測試人員報怨規格中某個項目不可能做完整的測試,我就得去把這個項目簡化。如果這些人得向我報告,產品可能不會這麼好。因為有些人可能會認為對上司放馬後炮不太好。另外我也可能堅持己見,獨斷短視地命令他們照我的方式進行。這樣做的話就不可能有機會建立共識。而凝聚共識的決策型式卻是做對事的最好方法。

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

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