Joel on Software

Joel on Software   周思博趣談軟體

 

其他Joel on Software文章( 繁體中文)

其他Joel on Software文章(英文)

與作者聯繫 (英文)

 

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


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

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

誰在寫規格?

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

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



文件來源: Painless Functional Specifications Part 3 (英文) 

約耳.斯珀儿斯奇是Fog Creek Software (設立在紐約的一家小型軟體公司) 的創立者. 約耳畢業於耶魯大學 (Yale University) ,並曾經在微軟, Viacom 和 Juno 擔任程式人員与管理工作.


這些網頁的內容為表達個人意見
Copyright ©1999-2005  Joel Spolsky. 所有權利皆予保留 使用規定

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky