你可以運用兩個基本戰術來加速軟體建造過程:
● 提高你的建造生產力
● 縮減你所建造之軟體的規模

短期來說,你可能增加一定數量的生產力,但是會受到各種形式的布魯克斯法則所限制。增加生產力(不僅增加數量,也提高技能)長期來說會有助於符合時程、達到高效能、低成本與幾乎所有的一切。然而,雖然很多經理人不知道如何做或無法言行一致地去做,但是縮減規模是經理人短期內能控制的事。

更小的意思是什麼?
系統規模構成了軟體工程中很多基本動態回饋迴路的一部分。例如,找出缺陷所在位置的一種基本動態學就是:找出特定缺陷的時間,會隨著系統大小而增加(圖20-1)。在更大的系統中:
● 有更多缺陷
● 需要從更多地方去找出缺陷
● 缺陷彼此互相影響的機率更高,使得要找出缺陷更加困難
 


圖20-1有些因素相互影響,導致找出特定缺陷的時間隨著系統大小而增加。

這種動態學暗示,我們在其中尋找缺陷的系統應該盡可能小。當然,短期來說,我們對於要交付之系統的實際大小的控制能力有限,但是我們並非沒有資源來縮減我們的系統的有效規模。

截至目前為止,我讓「更小」的意義變得有點含糊不清,但現在是更具體說明的時候。我所談論的大小是系統在人們內心中的大小,也就是要有效做事情所需的心理努力多寡。這個大小可能大致上與程式碼行數有關,但是具有同樣程式碼行數的L程式與B程式,在這個大小的意義上,可能有非常不同的性質。以下是一些例子(L代表「小」,而B代表「大」):
● L的文件可能優於B的文件。
● L的初期設計可能優於B的初期設計。
● L的設計在保留完整性方面可能比B的設計更好。
● L可能規畫比B更長的時程,所以L能以更少人與更少協調來完成,這使L變得相對更小。
● L可能比B有更少的交互影響的缺陷。
● L的需求可能沒有B的需求那樣廣泛。
● L的需求可能沒有B的需求複雜。
● L的需求可能沒有B的需求那麼明確,而容許更多設計方面的選擇。
● L的顧客可能沒有B的顧客那麼要求完美,而且更願意接受還不錯的東西。
● L的顧客可能比B的顧客更樂意合作。
此外,在內心中的大小也跟是誰的心理狀態有關。更聰明、受過更好訓練、並有更優良工具的人,會看到更小的系統。請記住,對一個膽小鬼來說,連井字遊戲都是很大的挑戰。例如說:
● L的開發人員可能比B的開發人員受過更好或更適當的訓練。
● L的開發人員可能比B的開發人員較少牽涉到隱藏性議程(例如建造新工具或新方法論)。
● 雖然承諾要有合理的品質,L的開發人員可能比B的開發人員較不著迷於完美。
● L的開發人員可能比B的開發人員更樂意與他們的顧客合作。

改變這些事情是後面各章將會提到的更長期方法的一部分。讓我們暫時先處理系統大小的問題。

縮減規格的範圍
當軟體開發人員討好顧客或他們的代理人(行銷人員)時,系統的功能會增加。在專案的早期,你可能很難勇敢面對推銷「更多功能之價值」的相關爭論。每個人都抱持樂觀心態,而且討好顧客比面對規模大小的品質動態學要容易得多。畢竟,預測不會那麼準確,而且沒有人能理性地堅持,只多增加一項功能實際上會影響到品質或交期。

然而,一旦你處於時程危機,爭論的平衡在面對現實時會變動。例如,在與一家軟體公司的行銷部門召開危機會議時,我向一開始抱持敵意又喜歡指責的聽眾解釋規模大小的品質動態學。到簡報結束時,事實與數字令他們折服,而且行銷經理請求說:「請問在預定的日期你能夠交付哪些功能?」當我告訴他不可能時,他乞求說:「你能否給我們一個日期,在那時候你可以交付任何的功能?」我再度告訴他不能。他最後溫順地說:「若你能給我們一份功能清單,並且告訴我們什麼時候你可以告訴我們一個交付日期,那我們會非常感激。」

當你停止推測,而且手中有資料時,你對於縮減系統的實際大小可以有比較貼近現實的期望。現在,堅持要獲得所有功能的顧客,顯然要冒著什麼都得不到的風險。因此,你應該考慮的第一件事是縮減規格的範圍。

當顧客與開發人員都不了解到底需要什麼時,他們開始編造各種需求。那就是為什麼縮減範圍未必是指提供給顧客更少的東西。若你有蒐集需求、分析需求並且將需求排序的防範未然型(模式4)流程,你就會知道顧客想要什麼,以及什麼對他們最重要。你所得到的需求,會比採用更原始的流程所得到的需求少很多,而且也更明確。

不幸的是,設置這種流程需要能夠防範未然,而且專案經理經常太過討好別人或太追求完美,等到太遲時他們才會去嚴肅考慮關照全局的需求流程。討好者發現要對任何請求說不,根本不可能辦到,而完美主義者也不可能說:「我們做不到我們原以為可以做到的那麼好,所以我們想縮減範圍。」那正是為什麼高階管理人員處於最佳地位,可以在專案後期或專案早期發起範圍縮減戰術。那也是為什麼缺乏有影響力高階主管贊助者的專案非常可能失敗的主要原因。如同Thomsett所觀察到:

贊助IT專案的資深經營主管實際上積極參與,並在下列領域中擔任執行專案經理(executive project manager),這樣的做法具有關鍵性:
● 利害關係人參與、承諾與解決衝突
● 規畫與實現效益
● 規畫品質需求
● 風險管理
● 專案變革控制

請注意,在決定需求的大小時,這些因素的影響力有多大。若我們有這類支持,當必須縮減需求時,就會有一些戰術可供我們運用。

消除最糟糕的部分
一個簡單的非線性模型會預測,刪去10%的功能可能減少20%找出缺陷所需的時間,但是實際上你還可以做得更好。一旦實際上從事系統開發,你會有哪些功能顯現出最多缺陷的相關資料。若你選擇去除掉最嚴重的缺陷,你可能會得到比你的規模大很多的結果。

容易出錯的模組
很多系統中有某些模組就是容易出錯,這一項發現已經過很多研究證實。雖然可能只占全部程式碼的2%,但這些程式碼包含了超過80%的缺陷。而且,在系統發表之前,容易出錯的模組經由系統測試中的缺陷模式很容易暴露出來。換句話說,容易出錯的模組天生就容易出錯,並且在整個系統存續期間還是容易出錯。

當你遭遇時程危機時,你會有找出最容易出錯模組所需的資料。這些模組是你應該最先建議從目前這次發表中刪除掉的模組。當然,這些功能有些可能對有意義的發表十分重要,但是就我的經驗來看,如果時程的壓力夠大,一個非討好者的經理人至少能協商去掉半數的容易出錯的模組。當然,對於本次發表,其餘的模組必須重新開發,但是正確開發模組總是比錯誤地開發模組速度更快。

因此你協商將10%的功能延期,這包括一些容易出錯的模組,以及在測試時程上有點落後,因此品質未知的一些模組。運用這項策略,你很可能消除掉50%剩下的錯誤。你只減少10%應該去搜尋的地方,但是你可能減少至少四倍的交互作用的影響。再結合將缺陷數量減半,最終結果可能輕易地將花在找出缺陷的時間縮減為十分之一。

找出缺陷所需時間減少的效應
功能的些微減少將造成找出缺陷時間減少達一個數量級,這與我的客戶的經驗十分一致。開發新產品時,有個軟體公用程式組織運用將缺陷製成表格,從可能容易出錯的73個模組當中挑選13個模組,延遲至較後面的發表。將這些模組從型態中抽離之前,花在往下追蹤缺陷的平均時間大約是7小時。在縮減過的系統中,找出缺陷的時間少於1.5小時。

當然,這些開發人員不知道的是,有許多缺陷他們永遠不必去看。他們可在一年後再做檢查,但是13個模組當中有6個已完全記錄下來,另有3個模組因為顧客不需要而永遠被丟棄,此乃這項戰術的一個不錯的額外效應。

要找出容易出錯的模組,你不需要花俏的評量工具。另有一位客戶是只在系統發表後,才開始搜尋容易出錯的模組。結果因為打電話給開發人員的顧客太多,那次發表造成整個公司出現危機。主管召開開發人員會議,並問說:「如果好心的仙女給你一個願望,你希望哪件東西不在這個系統中?」他們都毫不猶豫地指出同一個模組。結果,他們只是藉著通知顧客,這次發表中實際上沒有這個模組,就「收回」了這個模組。甚至在這次危機消失之前,士氣就提高了100%,可能對於減少找出缺陷的時間幫助頗大。

拿掉尚未完成的東西
當專案超過預定交付日期沒有完成時,你有另一種方法預測哪些是最糟糕的模組。事實上,你完全不必預測,因為從交付的觀點來看,最糟糕的模組正是那些尚未完成的模組。這些模組可能陷在測試中,或甚至尚未到達測試階段。無論哪種情形,只要從發表的內容當中拿掉那些模組,你就可以擬定你的時程。

當然,你未必能這樣做,但總是值得一試。你可以告訴顧客說:「你可以現在就擁有一個沒有X、Y與Z特色的系統;你也可以選擇在未來某個時候獲得一個可能有X或Y或Z特色的系統。你甚至可以三種特色全部都有,但是我無法保證你是否能獲得或何時能獲得,你喜歡哪種做法?」接著等對方的情緒平復下來,再開始協商。

防範未然型(模式4)組織會預見到這種可能性,並與顧客維持良好又開放的關係。在這種關係之下,你提供這樣的建議並不會讓對方太驚訝,也不會造成嚴重的衝突。在這種情形下,顧客更可能當場就接受功能縮減的系統,這樣一來你就正好能按照預定的時程完成第一次發表。現在你只要著手處理下次發表即可。

在某些個案中,你可能發現顧客不想要X或Y或Z。在那種情況下,你的2.0版本將是一個更小的系統,並且有更長的時程。在其他個案中,你還是必須開發X當作1.0版本的一部分,但是能夠將Y與Z延期;雖然無法如期完成,你還是有所收穫。在另一些個案中,你還是必須在1.0版本中生產這三項特色,但是至少比你沒有提問的情況要好些。

拿掉最沒價值的部分
如果你採用自上而下最先建造最重要的功能並加以整合,你也許就能避開這種「收回模組」的麻煩。因為你完成的那90%可能提供99.9%的價值。我看過很多從未完成(就實現完整原始規格的意義來說)的自上而下系統,但是顧客依舊快樂地接受了這些系統。當然,原型設計也可能有類似的效果:藉由最先放入最重要的部分,你可用更少的心力交付更多的價值。

縱使你未按照自上而下或原型設計開發來規畫你的專案,日後遇上麻煩時你還是可以想辦法拿掉最沒價值的部分。你只要將一份未完成功能的清單交給你的顧客,請他們按優先順序排序這些功能,並也標示出哪些功能需取決於其他功能的完成。之後,你就按照那個順序實作。當要整合每個新部分時,你就給顧客選擇,看是否現在就停下來不繼續開發並接受系統,然後等待顧客的回應。

有缺陷地交付
沒有軟體曾經毫無缺陷地交付,所以要拿掉最糟糕部分的一個方法是,以不會造成顧客太大困擾的方式交付產品。你可以提出一份已知剩餘缺陷清單給顧客,並請他們按優先順序排列。例如可以用以下的方式分類:
F. 有這項缺陷我將無法使用系統。
D. 如果補償我X,有這項缺陷我可以使用系統一段時間。
C. 如果補償我Y,有這項缺陷我可以無限期使用系統。
B. 即使有這項缺陷,我也可以無限期使用系統。
A. 有什麼缺陷?

你可立刻停止修正A類與B類缺陷,並將人力花在修正F類缺陷上。既然你已知道每一類缺陷的價值,你可以付錢給顧客,讓他們接受有C與D類缺陷的系統。你可以付現、以價格折扣或以交換方式處理。例如,若你從購買價扣除Y,顧客應該願意接受C類缺陷,而且絕對不會抱怨。若你扣除X,至少暫時他們應該不會抱怨。

這個戰術未必對你所有的顧客都行得通,因為不是每個人都計畫以同樣方式使用系統。雖然對某些人來說系統不及格,但是其他人可能完全沒有F類缺陷,或甚至D類缺陷。你可以將系統交付給想要的人,之後再應付其他人。

這種排優先順序的方法有幾個意想不到的優點:
● 你帶給專案一些成功的感覺,若果做得適當的話,這會提高士氣。
● 你可以降低「使用者人數」動態學的強度。

有特色地交付
與顧客一起審查缺陷清單,有時候會突顯出另一類缺陷:
A++.多麼棒的特色啊!

軟體可能未依照他們要求的方式運作,但是其運作方式至少在某些方面實際上更好。

例如,有位客戶做了一個有缺陷的電子郵件系統,若你提供比一個螢幕畫面還長的訊息,系統就會發生故障。審查缺陷清單時,顧客說:「這會是保持備忘錄不要太長的一個很棒方法,但是我真的負擔不起讓系統整天發生故障。那樣所付出的代價,高於較短備忘錄所帶來的節省。」專案經理隨後決定,當一頁填滿時就停止訊息輸入,來修正這個缺陷,使系統不會發生故障。顧客購買這套系統,並自誇說該項設計特色做到了過去他們的組織中從未有人做到的事:削減備忘錄長度。

盡早拿掉
削減系統規模是一種強力介入,而且你能越早這麼做,這項介入的影響力就越大。首先,越早縮減規模,你浪費在不必要的工作上的資源就越少。你也有更多時間與更少壓力去讓人們受訓接手新工作,而且專案經理也能在不合理的期望具體化之前,先設定合理的期望。理想的情形是,在規畫前你就能將規模縮減至最小,但是如果缺乏先見之明,你就只能密切注意縮減規模大小的早期機會。

讓人們準備好縮減
對於你的組織中的人,早期縮減是比較好的選擇。負擔過重就像癌症,會自己吞噬自己(圖20-2)。早期減輕負擔可以提升士氣並降低疲憊感,使人們更有生產力。然而,你必須注意進行縮減的方式。在開發專案中,模組被刪除或延遲的程式設計師可能會變得沮喪。

只要不指責,並準備好讓這些人做其他工作,你就可以將這種沮喪減至最低。若你先刪除模組,才開始找事情讓人們去做,你等於在暗示說要擺脫掉糟糕的工作,這就是一種指責。你也讓人們必須被動地等待你的決定,這不僅浪費資源,也是你所能造成的最令人沮喪的情況,或最無力感的事。

若有幾項替代性工作(能立即開始從事的工作)供程式設計師挑選,你就是在強調加入,而非扣除。實際上,你發送出新工作有價值而非舊工作做不好的訊息。提供選擇可以減少造成沮喪的無力感。藉由提供選擇,你讓程式設計師有機會得到賦權(empowerment)的感覺。

但是他們不需要被告知,他們所做的工作相當糟糕嗎?還有什麼其他方法能讓他們下次做得更好?當然,他們需要工作遭刪減或延遲之理由的精確回饋。你若剝奪了要給他們的那項回饋,你等於排除讓他們和組織在專業上有所成長的機會。但是你不需要告訴他們,因為他們已經很清楚。如果你就是忍不住要告訴他們,請至少等一會兒,等到他們跳出「混亂」階段,並在新任務中重新建立了一些自信再說。換句話說,你縮減系統規模的方式,常常與實際的規模縮減同樣重要。否則一不小心,你所縮減的有效勞動力,將會超過你所縮減的系統規模。


圖20-2長期負擔過重會自我強化,所以早期減輕負擔可以有正面的雪球效應。

延長時程
有些系統規模的動態學之效應乃相對於時程。換句話說,我們所理解的要在兩週內完成的一個大系統,若容許時程長達兩個月,就可能被視為是小系統。強迫給大系統一個短時程,總是會讓整個專案耗時更久,所以,若你想要縮減規模,也可以藉由延長時程來達成。

然而,協商延長時程之前,你應該研究你的系統的動態學。例如,若時程在可能的最後一分鐘延後(系統到期的那一天),你將看到:
● 失敗感造成的沮喪
● 壓力釋放造成的興高采烈
● 失去重新規畫的時間
● 失去讓個人彌補已損失時間的機會
● 由於「混亂」所造成的普遍的效率降低

因此,當你在晚期做出時程延後,你可以預期至少有兩星期的損失。這意指將時程延長兩星期,絕對讓你一無所穫。若那是你的最佳選擇,請不要接受它。我們需要時程與資源餘裕來減少問題,而不是擴大問題。若你早一點延後時程,這些影響就會變小。事實上,若在預定日期幾個月前就開始,人們可能不會注意到些微的時程延後。

務實並大膽行動
最終來說,幫助你最多的是勇氣與務實的態度。知道你在日後可以將需求縮減是個有用的戰術,但是對於懦弱的人來說也可能是陷阱。不要容許先增加需求,並希望後來你能拿掉它。不要早期先討好,並希望後來你可以勇敢奮戰,以消除掉證明不可行的那些部分。即使你有所有的資料,較晚而非較早消除掉功能,在情緒上總是會更加費力。

管理遲來的需求
即使你運用最大的努力削減系統大小,專案中遲來的需求會讓你覺得好像在逆流而上。新需求可能來自顧客或程式設計師,所以你必須留意每一處地方。任何組織中有些遲來的需求變更是必要的,但是你絕對不能忘記,這些需求會增加系統的規模。圖20-3概略描繪了其中一些效應,如同本節所解釋的。


圖20-3在專案的後期增加需求,會使得進展速度減慢的效應遠遠超過程式碼增加的百分比。

以時間交換需求
不要受騙而輕易接受以一些額外的時間,換取加入遲來的需求。系統規模的動態學是非線性的,所以在估計遲來的需求所造成的影響時,你需要非常不吝嗇地做估計。若你在協商時能對真實的成本有概念,那你就更有機會獲得你所需要的東西。這樣一來,如果你真的必須接受遲來的需求,至少你能得到滿足這些需求的合理時間。

例如,有一項研究顯示,為了回應系統規模增加11%,找出所有缺陷所需的時間會增加28%。若專案的測試部分原本排定54天來找出所有的系統故障事件(STI, system trouble incident),那麼如果要在原本90K行程式碼中再加入10K行程式碼,則必須另外再加15天的測試時間。此外,這項程式碼的增加尚未考慮到其他因素,例如以下的因素:
● 修正缺陷的時間也會非線性地增加。

● 新加入的程式碼可能等比例地導致更多故障產生,因為這段程式碼是在有時間壓力的情況下開發的。好的設計可減輕這種影響,但是絕對不保證在所有個案中,這種情況都不會發生。

● 新加入的程式碼可能等比例地導致更多故障產生,因為那不是原始設計的一部分,所以無法非常順利地相互搭配。

● 新加入的程式碼可能等比例地導致更多故障產生,因為本質上更大的困難度,通常會在後期加入的需求中發生。若你研究一下為什麼這些需求到後期才加入,你會發現這些需求常常是更加複雜(使需求流程放慢下來)或更難以捉摸(所以起先並未看出來)。

● 每當你接受一項新需求,為了重新規畫,你必須從其他任務當中挪出資源。

● 即使你花時間與資源適當地重新規畫,計畫可能沒有最佳化,因此會比全部一次完成規畫還更沒有成效。

● 你可能會強化你的顧客的行為,鼓勵他們在更後期做出更多變更。一旦你接受了一項變更(尤其若顧客不必支付這項破壞的真實成本時),進一步變更的機會可能大幅增加。單單考慮這些變更的成本,就可能對你的專案造成很大的延誤效應。

● 隨著工作量增加,對於工作人員可能會有打擊士氣的影響。請檢查你的進度落後圖,因為工作人員都會在他們的腦海中計算。若他們的宇宙似乎擴大得比光速還快,他們可能會提早跳離太空船。此外,每次他們經歷這種擴大時,他們會對管理階層的信用更失去信心。

● 當專案結束時,工作人員可能會有其他計畫要做,所以當專案超出原本的估計時,你會更快速失去人員,導致你必須加更多人,這會使時間進一步拖長。當我回想起一位絕望的主管,為了大致上符合新預定的專案截止時間,而要求一位開發人員將她的婚期延後「一個月左右」時,我不禁微笑起來。我認為他真的相信她可能會答應。

綜合所有這些因素我們可以輕易地猜測,最初規畫需要200個工作天完成的計畫,因為要求的規模大小增加10%,可能會輕易延長到250個工作天或更久。若第100天之後新需求才到來,因為上述那些具破壞性的影響,時間的增加甚至會更多。你可以合理估計要延長一百天,而且顧客會尖叫說:「為了10%的增加你竟然把你的交付時間加倍!」當然,不是交付時間加倍,而是剩餘的時間加倍。若你無法解釋非線性的動態學,你將很難說服別人。從事這類協商之前,請研究圖20-3,然後拿那張圖給你的顧客看。

建立你的行事方針
當然,我沒有說你絕對不應該在專案後期接受新需求。基於商業理由,若你不接受這些需求,專案可能就會變得毫無意義。但是你也必須建立你這邊的行事方針。以下是你能做的事:

一定要將用於估計的時間與成本,納入需求變更的考慮中。一定要學著說:「如果要考慮那項變更,因為必須要有人員參與研究這項估計,我們必須加入X週和Y美元到交付日期中。」這立刻會去除掉像空中樓閣般的一些比較不重要事項。

如果沒有經過你的需求流程的需求檢定,請不要做任何估計。(這是必須花費你很多資源之處,並也部分解釋延遲的原因。)一定要告訴顧客:「從你交給我們完整的書面需求構想,以進行審查的時候算起,我們需要一週的時間[比方說]。我們可能也需要時間讓必要的人員騰出時間來。那段時間結束時,我們將會知道為了做估計,新需求構想是否夠清楚,或者需要將新需求做一些修正。」甚至更多如空中樓閣般的東西會遠離。

一定要基於你的專案的動態學模型檢查每一項提出的變更,以發現任何可能的非線性影響。一定要相信你的模型所說的。提出你的估計值時,一定要對顧客解釋清楚。

一定要訂定優先順序。替你自己訂定優先順序,並讓顧客訂定優先順序。一定要將每項新需求當作一項缺陷,因為目前這項需求並不在系統中。協商之前一定要讓顧客使用A~F的排序系統。

一定要以清楚又講究實際的術語,描述每項需求變更的後果。「若你想要這個與那個,則在時間、金錢與不確定性方面,將會付出這樣與那樣的代價。」一定要確定,若你的顧客接受協議,你要能夠履行這項協議。

不要成為討好者!若你已完成前述這些事項,而且你的顧客開始對你施壓,你一定要說:「我也可能算錯。若你想要我重新計算,則這是專案必須延遲多久的資料。」若他們接受這項提議,你就要重新計算。若你並沒有算錯,請不要打退堂鼓。若他們威脅找另一個更好的人取代你,那只是專案管理實務上的風險之一。若他們能找到比你更好的人,換掉你是他們的權利,而且可能你會學到東西。

一定要事先告訴顧客,如果要請求變更,我們將用一個特定的流程來評估該請求,而且將會花X的時間。這是在開始前的一些教育過程與達成協議過程。相反地,後期的驚訝會導致顧客生氣、降低顧客信任度、而且可能使整個關係變得不利,而不是變得樂意合作。一定要一開始就賦予你的顧客權利,讓他們知道如何最適當地記載下想要的變更,以及什麼評估流程是必要的。這是管理顧客期望的一部分。由於你對於如何因應需求變更已做好充分準備,你的顧客將會事先更完整地考慮他們的請求,有些可能會提交較少的請求,而且大多數顧客會更加體恤地接受流程。

一定要記住「對事情有幫助的模型」:不論表面上看起來如何,其實每個人都想成為對事情有幫助的人。一般來說,你的顧客只是不了解軟體品質的動態學,這是你的專業,而不是他們的專業。那是為什麼他們堅持在專案晚期迫切需要新需求的原因,而不是因為他們是壞人,試圖讓你看起來更糟糕。

心得與建議
1.帶領探月小艇計畫的工程師James G. Gavin, Jr.說:「若一個重要專案真的夠創新的話,你不可能一開始就知道精確的成本與精確的時程。而且如果事實上你真的知道精確的成本與時程,可能它的技術已經過時了。」換句話說,如果你最想做的是一個野心勃勃的時程,那麼請遠離「尖端」技術。

2.你若想找出容易出錯的模組,你就有十足的動機在單元測試之前,就將程式碼擺在型態管理之下。若你有來自單元測試的變更紀錄,你就可以盡早找出容易出錯的模組。(摘錄整理自第20章)


溫伯格的軟體管理學──
第4卷 擁抱變革

傑拉爾德.溫伯格(Gerald M. Weinberg)/著;何霖/譯
經濟新潮社出版
售價:980元

《作者簡介》
傑拉爾德.溫伯格(Gerald M. Weinberg)

是美國軟體工程界大師級的人物。在40多年的軟體業生涯中,他曾任職於IBM、Ethnotech、水星計畫(美國第一個載人太空計畫),並曾任教於多所大學。他更是傑出的軟體專業作家和軟體管理思想家,因對技術問題與人性問題所提出的創新思考法而為世人所推崇。1997年,溫伯格因其在軟體領域的傑出貢獻,入選為美國計算機博物館的「計算機名人堂」成員。

溫伯格共寫了30幾本書,包括《顧問成功的祕密》、《真正的問題是什麼?你想通了嗎?》、《領導者,該想什麼?》、《從需求到設計》(以上由經濟新潮社出版)、《程式設計的心理學》、一共四冊的《溫伯格的軟體管理學》等等,這些著作主要涵蓋兩個主題:人與技術的結合;人的思維模式、思維習慣與解決問題的方法。他的網站是www.geraldmweinberg.com

熱門新聞

Advertisement