專案做不好，問題可能出在「管理」

為何關照全局對管理來說是必要的

要生產高品質的軟體，就需要高品質、高效能的軟體工程經理人。

到現在，這種經理人在軟體工程界還是相當罕見。在我長年擔任軟體開發者的事業生涯中，我從未擁有這種經理人，所以我認為他們根本不存在。當時我甚至認為這種經理人沒有必要存在──而且我的想法是對的，在那時候。如果只是生產平庸的軟體，根本不需要這種高品質經理人。不過在我擔任顧問這麼多年當中，我遇到過許多高品質經理人，讓我了解到，如果你想超越平庸就需要他們。

或許你的經驗跟我的經驗很像，或許你在軟體工程界沒有遇過許多高品質的經理人，或者你不認為要有高品質的經理人才能生產出高品質的軟體。不管怎樣，你必須相信我說的話──這種經理人是不可或缺的。

即使你相信高效能經理人的必要性，但你可能不認同我對具備高效能要付出的代價所做之說明。

舉例來說，你可能認為高效能經理人只要了解軟體工程的概念就好，不必落實這些概念。這個錯誤信念正是引起許多麻煩的原因，也是聰明人士極難克服的難題，至少對我而言是這樣。多年來，我享受著這種優越感：「我知道該做什麼，但我實際上有沒有這樣做，其實無關緊要。」這種想法讓我很容易成為光說不練的批判者。

在軟體業，我遇到過很多人跟我一樣抱持著這種想法，所以我必須先讓你相信這樣做是錯的。所以，我先開宗明義介紹關照全局（congruence）這個觀念，並解決「為什麼行動必須跟想法一致？」這個問題。

知與行的比較
這套書前二卷的討論重點是，為了要利用回饋控制1（圖1-1）來管理一個工程系統，扮演控制者角色的經理人必須執行以下這四項活動：
● 規畫應該發生的事

● 觀察目前發生什麼重要事情

● 把觀察事項跟規畫事項做比較

● 採取必要行動讓實際情況與規畫情況更為接近

圖1-1：一個軟體開發系統的回饋模型需要有關系統表現的回饋資訊，讓控制者可以拿這些資訊和需求進行比較。比較理想的把穩方向型（模式3）組織就是因為有這個模型，所以有別於比較不理想的渾然不知型（模式0）、變化無常型（模式1）和照章行事型（模式2）組織。

這套書的第1卷以規畫為主題，第2卷則以觀察和比較為主題。這本書（第3卷）則以接下來的行動為主題（參看圖1-2）。

對於那些認為一旦做完規畫，適當行動就會隨之出現的人來說，以行動為焦點似乎有些奇怪。我自己以前就這樣想。我跟許多效益不彰的經理人共事過，而且我把他們的無能歸咎於腦筋不好：他們根本不知道要做什麼。後來，我知道問題未必出在他們身上。我看過許多例子，經理人很清楚要做什麼，但是不知何故就是做不到，我舉一些例子做說明：
● 經理人知道根本不可能準時完成專案，卻不能向老闆坦承此事，所以無法開始討論替代計畫或做法。

● 另一位經理知道在進度落後的專案增加軟體開發人員，只會讓專案進度更加落後，但是他受不了別人以為「他什麼事也不做」。

● 經理人知道對同仁大吼大叫只會讓情況變得更糟，但是他卻無法控制自己不這樣做。

● 經理人知道某位員工有嚴重的體味問題，讓其他員工避而遠之不與其共事，但是經理人卻無法跟這位員工談論此事。

● 經理人知道某位人士適合某項職務，卻因為自己不喜歡這位最佳人選，而指派另一位人士接任那項職務。

● 經理人知道在大家還沒有清楚了解所要解決的問題以前，不應該讓專案開始進行，但是經理人卻無法抗拒軟體開發人員想立刻開始寫程式的渴望。

● 經理人知道自己不該做出無法實現的承諾，但是卻一再地做出這類承諾，以逃避麻煩的人際互動情勢。

這些經理人的共通點是：他們都缺少依據情勢所需而採取行動的自尊（self-esteem）。

圖1-2 ：在把穩方向型（模式3）組織，經理人的職責是控制生產預期產品或服務的過程。經理人規畫應該發生的事，然後觀察實際發生的事，並依據規畫事項與實際結果之差異來設計行動，而且這些行動後來反饋回這個受控制的過程。

必要多樣性法則
控制論專家艾許比（W. Ross Ashby）指出，任何控制者為了發揮效力，本身必須具備足夠多樣性的因應機制，以對抗所控制的系統可能呈現的各種行動。艾許比的必要多樣性法則（Law of Requisite Variety）表示，控制者採取的行動必須全面關照整體情勢；換句話說，控制者針對系統可能呈現的各種行動，至少要採取一項行動來因應。知道自己該做什麼卻無法做到的經理人，就是欠缺這種必要多樣性，所以無法採取有效行動執行個人職務。

為了達到控制之目的，這些經理人為什麼無法展現行動的必要多樣性，其實無關緊要。原因可能是經理人（扮演控制者）缺少計畫，或缺少將計畫與實際發生事項做比較所需的觀察力。或者，原因可能出在經理人知道該做什麼，卻無法實際做到，尤其是在壓力狀態下更做不到。

當人們無法充分利用可能行動的多樣性，就會做出不一致（incongruently）的因應。根據必要多樣性法則，行為不一致的經理人可能無法控制自己想要控制的系統。

這本書要探討的重點就與提高行為之一致性有關，尤其是當你處於壓力狀態下時如何讓知行合一，並藉此改善你達成預期管理品質的能力。

關照全局的管理之重要性
關照全局的管理之重要性不僅止於個別專案，更擴及到提升整體組織全面文化水準的過程。如同軟體工程協會（Software Engineering Institute, SEI）流程方案前任主管寇蒂斯（Bill Curtis）的觀察：
如果組織設法建立一個全面管理的基礎架構，同時又設法改善本身的軟體流程，那麼組織就要花更長的時間才能達到下一個層級。

此外，軟體工程協會流程方案的第一任主管韓福瑞（Watts Humphrey）和第二任主管寇蒂斯都指出：
即使定義明確的工程流程也無法克服由欠缺健全管理實務所引發的不穩定性。

對我來說，這些觀察可能引發的做法不外乎以下兩者之一：
1.即使組織的經理人能力不足、行動力薄弱，但是組織為了克服不穩定性，就必須設法把定義明確的工程實務引進組織裏。

2.設法在組織裏找出並培養特別能幹又具說服力的經理人。

目前，軟體工程協會正在推行第一種做法，這種做法適合於那些跟組織做生意的機構。本書要推行第二種做法，因為這種做法適合我的讀者：也就是想成為「特別能幹又具說服力的經理人」的個人。

隨機過程的第一要素
很重要的是，軟體工程協會和其他機構推行第一種做法，即使那不是我選擇的做法。

首先，這種做法是我們在電腦業一直推行的做法，也是我們比較了解的做法：藉由從方程式中去除人員因素而達成品質。而且，這方法曾經很成功過。

最近，我得知英國數學家謝克斯（William Shanks）在十九世紀時，花了二十年的時間計算圓周率（pi），他算到圓周率的小數點後第707位，但是小數點後第528位開始就不正確。我也得知美國數學家李默（D. H. Lehmer）在一九三○年代時，在一年內每天花二小時的時間終於證明梅仙尼數（Mersenne number）是質數。

這二個例子可用以說明工具如何協助增加品質與生產力。現在，要計算圓周率到小數點後第707位，我可以求助於我電腦裏Mathematica這支程式，我只要輸入下列指令：
　　N[Pi,707]

十秒後，電腦就幫我算出答案，而且一次就計算正確。至於要計算2257-1是質數，我只要輸入下列指令：
　　PrimeQ[2^257-1]

十秒後，我的麥金塔電腦就顯示這個數字確實是質數。

利用軟體科技，我可以大幅提升績效、成本和品質。但是這二個問題都有一個重要特質：本質上，它們都跟管理無關！

如果跟管理有關，那麼可藉由工具大幅提升的利益就可能消失。在你的組織裏，如果顧客委託要求你們計算圓周率到小數點後第707位時，會發生什麼事？這是十秒鐘就能解決的工作嗎？

我讓一些學生私下請一位顧客提出這項要求，讓學生們在所屬組織進行這項「計算圓周率到小數點後第707位」的測試。其中的一些結果如下：
● 一週後，辦事員送回需求表（request form），上面還加註「填寫有誤」。

● 需求表沒有送回來，也從未加以執行，而且三個月後再也沒有聽說此事。（這是最常見的「反應」。）

● 顧客接獲祕書來電要安排與分析師開會，而且分析師要一個多月後才有空開會。

● 需求表在二天內送回，表單上用鉛筆寫下圓周率值到小數點後第10位。

● 需求表在十天後送回並標註「你一定是在開玩笑！」。

● 在三週到四個月內，取得依據程式估計值做的一些回覆。

● 請其他顧客向二名顧客求助──其中一名顧客正使用Mathematica程式，另一名顧客正使用Maple程式（類似的數學應用軟體）。於是顧客們在幾分鐘內就輕鬆地解決問題。

● 顧客拿到算出圓周率小數點後第707位數值的列印文件，但是文件上印出的數值其實已經計算到小數點後第1000位。

● 顧客接到電話詢問是要列印文件還是電子檔案。顧客要求索取電子檔案，不到一小時內廠商就派人親自送交電子檔案給顧客。

對我來說，這項有點蠢的調查只是要確認我對數十家組織的直接觀察。這些組織在服務上產生的多樣性，並非出於技術上的差異，因為他們都利用同樣的技術；這種多樣性其實是源自管理上的差異。

目前在軟體界：
管理是隨機過程的第一要素。

你不必把我的話當真，因為你可以利用你自己的經驗做判斷。請你回想一下，你認識的最優秀軟體經理人和最差勁軟體經理人，他們的組織或專案在績效上有多少差異？在成本上有多少差異？在品質上有多少差異？

向任何一位品質專家詢問改善品質要從何做起，你聽到的答案有十之八九是這樣：
1.確認隨機過程的第一要素。

2.採取步驟以減少這項要素的不可測性。

隨機過程的第一要素會妨礙你去改善隨機過程的所有其他要素。

基於一些奇怪的理由，許多人試圖改變組織，但卻繼續犯下同樣的錯誤。他們以為，讓我們陷入混亂的那群人就是領導我們脫離混亂的最佳人選。事實上，如果經理人出現以下這類不一致的狀況，就算運用世上所有的管理工具也派不上用場：
● 如果他們太自我中心，對於正在發生的事視若無睹、不聞不問。

● 如果他們太慌張，無法了解應該發生什麼事。

● 如果他們太害怕，無法細心執行預期的行動。

當經理人言行不一致、無法控制情緒時，我們精心設計的控制論模型（cybernetic model）就會雜音四起，無法正常運作。請記住，無法控制自己的控制者比沒有控制者還糟糕：
如果你無法管理你自己，你就無權管理別人。

軟體工程管理的其他所有構成要素就是靠個人效能來加以整合。你如果用照章行事型（模式2）的經理人絕對無法讓組織變成把穩方向型（模式3）的組織；反之，你應該先取得高效能的經理人，然後由他們來領導其他人。

挑選管理階層
為什麼在軟體工程界裏這麼難找到關照全局的經理人？

或許這個難題跟組織選擇自家經理人和培養自家經理人的方式有關，或是跟經理人自己選擇擔任管理職務的方式有關。如果組織沒有選擇適當的人選擔任管理職務，後來經理人無法關照全局，那就沒有什麼好奇怪的。

我刻意把「挑選管理階層」這個主題模糊化，因為這個主題跟下面二件事有關：
● 組織如何挑選管理階層

● 個人如何選擇以管理職務來發展其事業生涯

如果你不了解這二項選擇之間的差異，那麼你可能從來沒碰過這種情況：組織選擇你（或沒有選擇你）擔任經理職務，而且最後的選擇掌握在你手上。如果你假裝自己沒有選擇可言，那正是你表現不一致的明確跡象，而且這樣做絕對不是開創個人管理事業生涯的最佳方式。

從哪方面著手最有利
我從軟體工程大師賓姆（Barry Boehm）的軟體工程經濟學經典著作中的一張圖，引伸出圖2-1。那張圖也出現在賓姆那本著作的封面上，這似乎表示該圖反映出整本書的主要觀察結果。賓姆在那本書中，把一些「成本動因」（cost drivers）孤立出來，其中以圖中所示的這四項成本動因最為重要。藉由研究這些動因──工具、人員、系統和管理──我們可以決定哪方面應該優先管理。

高階經理人可利用圖2-1做為高層次的指導，顯示本身組織的改善心力最好集中在什麼地方。假設此圖之要素並未加以標示，那麼你所看到的一切只是四項影響因素之比率──3、11、17和64。如果你正在管理一個軟體工程組織，你會把大多數時間花在尋求哪方面的改善？顯然，比率占64的因素應該是必須先加以改善之處，而這個部分就是「管理」。

可笑的是，如果只提供工具、人員、系統和管理這四個類別，大多數經理人對於成本動因的影響比率，會做出順序剛好相反的回答，他們認為工具是影響最大的成本動因，管理是影響最小的成本動因。或許特定動因比其他動因更重要的原因是，管理階層花太少時間注意它們。

圖2-1：賓姆提到管理因素對於軟體成本的影響最大，但他並未提出估計值。我從賓姆說會造成「軟體開發成本加倍」的六種管理行為，衍生出此圖之估計值。

根據軟體工程協會的研究，經理人在解決軟體成本方面這種「本末倒置」的做法確實存在。藉由計算及分類該協會過去五年贊助研究的發表摘要內容，我製作出圖2-2。

圖2-2 ：我依據軟體工程協會過去五年來對於「工具、人員、系統、經理人」這四個領域所贊助的研究，進行分析後所得的圖形。圖表顯示我根據賓姆的資料解析各領域之報酬百分比，並與軟體工程協會在一九八六年到一九九一年對相同領域所發表論文之百分比，兩者加以對照。

 

管理的單一面向挑選模型
以我在一些軟體工程組織的諮詢經驗來看，我發現這些組織的成效分配跟軟體工程協會的贊助研究極為類似。舉例來說，我把圖2-2拿給XYZ公司的經理人看時，他認為他們對於改善管理的努力，比軟體工程協會所顯示的4%還要顯著。

他這麼跟我說：「或許我們沒有像你們花那麼多錢在管理工具或訓練上，但是我們花很多時間在評量員工表現上，而且我們依據這些評量結果決定該升遷誰為管理階層。」

聽到這段話時，我馬上明白他們是怎麼做評量的。

XYZ公司可能花很多心力改善管理，但是那卻是以人類所設計的錯誤模型為基礎。同時，我領悟到我的客戶大都使用這個錯誤模型──我將這個模型稱為「單一面向的挑選模型」（One-Dimensional Selection Model）。這個模型是以三個錯誤假定為基礎，亦即：
● 經理人是天生的、不是後天養成的。

● 可以用單一面向的標準來為人們排名。

● 程式設計師的職級就跟管理人員的職級一樣。

現在我們就逐一審視為什麼這些假定都是不實際的想法。

1.經理人是天生的、不是後天養成的

如果你認為經理人是天生的、不是後天養成的，那麼你的主要興趣和努力會用於發現哪些人天生就是當經理人的料。在某些家族事業中，選擇接班人的過程完全以血緣為主要考量。在所有可能的經理人選中，家族事業所有人之長子顯然是最佳人選，如果沒有生兒子，那麼女兒就是最佳人選。

我或許不該取笑這個模型：世界上許多國家和企業都用這種模型挑選統治者，而且幾百年來都這樣做。據我所知，這樣做的國家和企業未必表現得比運用其他方法挑選統治者的國家和企業要來得糟。

長子繼承（primogeniture）法則具有一項明確優勢：本身不會含糊不清。你認為跟其他兒子相比，長子會是更優秀的經理人，即使他們是相差幾秒出生的雙胞胎。你當然也知道，不管女兒是不是比長子年紀更大，長子都優先繼承。這項法則雖然具有一些男性沙文主義的色彩，但是依據歐洲貴族社會常見的繼承法則，女兒比姪子和外甥還更優先繼承。

「經理人是天生的、不是後天養成的」這項假定會導致三項顯著的行為偏見：
● 其實成不成熟和經驗多寡一點也不重要。

● 真正唯一重要的是挑選對的人來管理。

● 管理技能訓練大多是浪費時間。

以軟體文化模式的觀點來看，變化無常型（模式1）的經理人對於程式設計師所做的假定就跟前述假定類似。以人類學的觀點來看，偏見相當於「威信」模型（mana model）：有些人有極大的威信，有些人卻沒有。

這種模型正確嗎？我不認為這個模型是正確的，美國管理協會（American Management Association）也不認為，哈佛商學院（Harvard Business School）也不這樣想。但是，我有很多客戶都認為這個模型是正確的。有些客戶表示，他們不認為這個模型是正確的，但是事實證明他們根本言行不一。

2.可以用單一面向的標準來為人們排名

如果你打從心裏支持共和政體，不相信長子繼承的功效，那麼你就需要另一項選擇法則來挑選你的經理人。不過，如果這項法則也有類似的明確性，那就再好不過。

許多組織使用評等系統為每一位員工產生一個單一數字。這個數字表示該位員工有多「好」，因此把所有數字擺在一起，就可以把所有員工的評等從最優秀到最差勁做出線性排列。舉例來說，如果有八萬名員工，那麼最優秀員工就是排名第一的員工，最差勁的員工就是排名最後的員工。

在其他組織則沒有個別員工評等，而是由個別工作單位內部進行評等，最後彙整為整個組織的評等。這種評等系統有效嗎？我個人從未刻意參與這類評等，因為這種做法違反我的某些基本原則。不過，這並不表示「我認為這類系統很荒謬」，只表示我不相信某些事。這個問題我就留給讀者自行判斷，我知道許多讀者參與過這類評等的實際運用。

3.程式設計師的職級就跟管理人員的職級一樣

即使前兩項假定是正確的，我們還必須面對這個問題：某類型工作的最佳人選是否就是其他類型工作的最佳人選。最優秀的英國國王也會是最優秀的電腦程式設計師嗎？或者，跟我們的主題有更密切關係的問題是，最優秀的程式設計師就能成為最優秀的經理人嗎？

在資訊系統業工作三十多年，每星期都有人問我這個問題。我相信「優秀程式設計師的條件」跟「優秀經理人的條件」，兩者之間其實沒有什麼關係。沒錯，要做好這兩項職務確實必須具備一些共同特質。然而，有些特質對其中一項職務比較重要，還有一些特質對其中一項職務有利，卻對另一項職務有害。我強烈質疑的是，這些特質最後都會抵銷掉，所以隨機挑選程式設計師擔任經理人，跟依據任何評等系統挑選程式設計師擔任經理人，兩種做法可能結果都差不多。況且，根據隨機方法挑選還更省錢呢。

應用這個模型的結果
這三項假定（我認為它們全都錯了）的結果是，最優秀的技術人員通常會被升遷為管理階層。通常，第一項升遷是將技術人員升遷為技術團隊領導人。要做好技術團隊領導人這項職務，確實跟做好程式設計師這項職務有關。但是，簡單講，技術團隊領導人並不是經理人，只不過頭銜上可能造成混淆罷了。

1.喪失管理工作的真正意涵

在變化無常型（模式1）的組織，可能有許多層級的管理階層，因為各個經理人的控制範圍很小。其中典型的「經理人」就是技術團隊領導人，其團隊由二至四名人員組成，其職務正好是擔任這個團隊最優秀的技術工作者。對於要因應程式設計師與工作間之差異的變化無常型組織來說，這種結構是最有效的做法。不過，單憑發展出一套具一致性的過程，並無法減少成果的變異（variability），通常必須靠技術團隊領導人接手團隊其他成員無法處理的技術工作，才能減少變異。

要讓這項做法奏效，就要把每個人管理好，尤其是管好基層人員。這樣一來，一旦有某項工作並未依照計畫進行，團隊領導人就能迅速知悉，並且親自出面接手做好這項工作。

當工作進展順利，這種做法意謂的是：最優秀的技術人員處理最棘手的技術工作，即使事先不知道哪些工作可能最棘手。如果團隊領導人在這一點上做得不錯的話，技術能力較差者就有機會觀摩如何處理棘手任務，組織的整體技術能力也得以提升。但是，如果處理得不好的話，這時候團隊領導人的工作將負荷過重，而且團隊成員根本無法學到什麼──只會覺得自己無法勝任工作。

2.喪失技術能力

組織依據技術能力將技術人員升遷為技術團隊領導者，看起來似乎相當合理，尤其當升遷是要借重其指導能力的時候。但是當這件事擴及到真正的管理階級──也就是技術團隊領導人以上的階級──這項理論根據就消失了。重要的效應就如圖2-3所示。即使最優秀的程式設計師可以成為最優秀的經理人，把最優秀的程式設計師調任管理職務，這顯然會讓組織的平均技術能力和最佳技術能力因此變差。

圖2-3：即使最優秀的程式設計師能成為最優秀的經理人，將他們升遷為管理階層卻會讓組織的平均技術能力因此變差，也讓組織的最佳技術能力隨之下降。
 

3.人力流失並造成不滿

不過，那只是第一級效應。如圖2-4所示，當組織的技術能力變差，技術人員可能變得更不滿意，而且組織可能更難留住最優秀的程式設計師。況且，人員發展通常需要有最優秀技術人員為榜樣。如果最優秀技術人員繼續調任他職，人員發展就會趨緩，也會對工作滿意度和人員留任造成不利的影響。

圖2-4：當技術能力變差，技術人員的滿意度會下降，組織也更留不住優秀的程式設計師。而且，當最優秀的技術人員持續被調任他職，人員發展有減少之趨勢，同時也會影響到工作滿意度以及留任情況。
 

4.干預效應
另一組額外效應如圖2-5所示。升遷到管理階層的高效能團隊領導人很難放手不管技術工作，畢竟當初他們就是靠這種工作建立個人名聲。他們擔任經理人時，如果不像以往擔任技術人員那樣得心應手，就會有增加干預的傾向，他們有可能因為被他自己的主管施壓而這樣做。

圖2-5：以技術能力為選擇經理人之標準的整體動態學。

而且，如果組織的平均技術能力繼續下降，經理人當然做得更無法得心應手，因此面臨更多壓力去干預──於是引發另一個強有力的正向反饋（positive feedback）循環。

這種循環並未出現在此圖中，卻是十分具有破壞力的循環。愛管閒事的經理人會對技術人員造成妨礙，使其無法獲得發展專業所需之經驗。當經理人繼續承擔部屬的責任，就會讓部屬更為不滿，而且這種干預甚至可能造成員工離職，尋求其他更有利的職場。如果員工真的離職，這種情況可能進一步增加管理階層干預還在職員工的傾向。於是，這種情況一再地持續下去，沒有好轉的可能，而且有可能變得相當糟糕。選擇與一致性
在圖2-5中，整個動態學沒有哪個部分考慮到這項做法對於經理人本身的影響，畢竟他們可以一開始就拒絕接任管理職務。有什麼事比接下自己不想要且不適任的工作更不一致呢？不過，我針對這個問題進行訪談時，接受訪談的數百位軟體工程經理人大都坦承，他們不想離開原本的技術工作轉任管理職務。以下是這些經理人的典型說法：
● 我在所屬領域已經做到頂尖，為什麼要進入新領域？而且我可能是這個領域中最基層的新手。

● 我不想管理任何人。但是，如果我希望自己的事業生涯有所進展，就必須接任管理職務，否則我只好離職。

● 坦白說，我這麼做只是為了賺錢。我原先的薪水已經是技術職務的最高薪資，現在我的薪水幾乎是以前薪水的二倍。況且，大多數時間我還因為自己不能要求家人更省吃儉用而感到難過。

當然，並不是所有經理人都對自己的決定感到不悅。但是，如果我進行的這項非正式調查相當準確，那麼許多經理人對自己的決定其實都甚感不悅，至少一開始是這樣。

如果你的組織因為你是一名技術好手而提拔你擔任管理職務，雖然你不認為這是最好的職務，但你還是接任了。接下來，你開始追求關照全局的行動，卻讓自己面臨重大打擊。

如果你當初確實不想擔任經理人職務，那麼當你接任經理人職務時，你的所作所為就會不一致。

因此，要成為關照全局的高效能管理者，你必須想要成為經理人。不過，那並不是最重要的事。針對成功管理所做的許多研究顯示，效能最高的經理人不會以尋求個人事業生涯之升遷為主要考量，而是將個人願景提升到與組織成就劃上等號。許多軟體工程師因為本身技術職務的完成事項受挫，才轉任管理職務。這樣的起步不一定是壞事，但是，要成為高效能管理者不但要遭受挫折，還要付出其他代價。（摘錄整理自第一、二章）

---

溫伯格的軟體管理學：
關照全局的管理作為
（第3卷）

傑拉爾德‧溫伯格（Gerald M. Weinberg）／著；陳琇玲／譯
經濟新潮社出版
售價：650元

《作者簡介》
傑拉爾德‧溫伯格（Gerald M. Weinberg）

是美國軟體工程界大師級的人物。在40多年的軟體業生涯中，他曾任職於IBM、Ethnotech、水星計畫（美國第一個載人太空計畫），並曾任教於多所大學。他更是傑出的軟體專業作家和軟體管理思想家，因對技術問題與人性問題所提出的創新思考法而為世人所推崇。
溫伯格共寫了 30幾本書，包括《顧問成功的祕密》、《你想通了嗎？》、《領導的技術》、一共四冊的《溫伯格的軟體管理學》等等。溫伯格現為Weinberg and Weinberg顧問公司的負責人，他的網站是www.geraldmweinberg.com。