溫伯格的軟體管理學：第一級評量（第2卷）

致台灣讀者  溫伯格
導讀  曾昭屏
前言
序言：一個觀察模型

Part 1: 接收訊息
1. 為什麼觀察很重要？
2.  選擇你要觀察的事物
3. 讓產品看得見
4. 讓過程看得見
 
Part 2: 尋思原意
5. 詮釋的案例研究
6. 從觀察結果尋思原意有哪些陷阱
7. 對品質的直接觀察
8. 如何量測成本與價值
 
Part 3: 找出含意
9. 如何評量情緒上的含意
10. 如何在失敗發生前就加以評量
11. 準確的聆聽
12. 超評量
 
Part 4: 做出反應 
13. 化觀察為行動
14. 從移情作用的立場觀察
15. 處理大批功能失常

Part 5: 第零級評量
16. 由可量測工作構成的專案
17. 關於計畫與進度的溝通
18. 以審查做為評量的工具
19. 以需求做為評量的基礎
20. 開路先鋒

附錄A  效應圖
附錄B  薩提爾人際互動模型
附錄C  軟體工程文化模式
附錄D  控制模型
附錄E  觀察者的三種立場
註解
法則、定律、與原理一覽表
索引

千載難逢的軟體管理大師──傑拉爾德．溫伯格

　　在陸續出版了《人月神話》、《最後期限》、《與熊共舞》、《你想通了嗎？》等等軟體業必讀的經典之後，編輯感覺，這些書已透徹分析了時間不夠、需求膨脹、人員流失、管理不當，每每導致軟體專案的失敗。這些也都是軟體產業永遠的課題。
究竟，這些問題有沒有解答？如何做得更好？

　　專案管理的問題千絲萬縷，面對的偏偏又是最（自以為）聰明的程式設計師（知識工作者），以及難纏（實際上也不確定自己要什麼）的客戶，做為一個專案經理，究竟該怎麼做才好？

　　軟體能力，於今已是國力的指標；縱然印度、中國的軟體能力逐漸凌駕台灣……我們依然認為，這表示還有努力的空間，還有需要補強的地方。如果台灣以往的科技業太「硬」（著重硬體），那麼就讓它「軟一點」，正如同軟體業界的達文西——Martin Fowler所說的：Keeping Software Soft（把軟體做軟），也就是說，搞軟體，要「思維柔軟」。

　　因此，我們決定出版軟體工程界的天王巨星——溫伯格（Gerald M. Weinberg）集40年的軟體開發與顧問經驗所寫成的一套四冊《溫伯格的軟體管理學》（Quality Software Management），正由於軟體專案的牽涉廣泛，從技術面到管理面，得要面面俱到，而最重要的關鍵在於：你如何思考、如何觀察發生了什麼事、據以採取行動、也預期到未來的變化。

　　前微軟亞洲研究院院長、現任微軟中國研究開發集團總裁的張亞勤先生，為本書的簡體版作序時提到：「溫伯格認為：軟體的任務是為了解決某一個特定的問題，而軟體發展者的任務卻需要解決一連串的問題。……我們不能要求每個人都聰明異常，能夠解決所有難題；但是我們必須持續思考，因為只有如此，我們才能明白自己在做什麼。」

這四冊書的主題分別是：
1. 系統化思考（Systems Thinking）
2. 第一級評量（First-Order Measurement）
3. 關照全局的管理作為（Congruent Action）
4. 擁抱變革（Anticipating Change）

　　都將陸續由經濟新潮社出版。四冊書雖成一系列，亦可單獨閱讀。希望藉由這套書，能夠彌補從「技術」到「管理」之間的落差，協助您思考，並實際對您的工作、你所在的機構有幫助。

導讀

從技術到管理，失落的環節∕曾昭屏

　　「軟體專案經理」可說是所有軟體工程師夢寐以求的一個職務，能夠從「技術的梯子」換到「管理的梯子」，可滿足所有人「鯉魚躍龍門」的虛榮感。不過，就像有人諷刺結婚就像在攻城，「城外的人拼命想要往裡攻，城裡的人卻拼命想要往外逃」，這也是對做軟體專案經理這件事的最佳寫照。何以至此，我們來看看其中的一些問題。

　　據不可靠的消息說，麥當勞為維持其一貫的品質，成立了一所麥當勞大學。當有人要從炸薯條的工作換到煎漢堡的工作，必須先送到該所大學接受完整的養成訓練後，才能去煎漢堡。軟體管理的工作比起煎漢堡來，絕對不會更簡單，但是有哪位軟體經理或明日的軟體經理，有幸在你就任之前，被送到這麼一所「軟體管理大學」去接受完整的「軟體經理養成教育」呢？

　　幾乎沒有例外，軟體經理都是從技術能力最強的工程師所升任。若說在軟體工程師階段所培養的技能有相當的比例可為軟體管理工作之所需就罷了，但事實是，兩種技能大相逕庭。

　　軟體工程師的工作對象是機器。他們的專長在程式設計、撰寫程式、除錯、將程式最佳化。他們大部分的時間花在跟電腦打交道，而電腦是最合乎邏輯的，不像人類偶爾會有些不理性的情緒反應。程式設計時最好的做法是將之模組化，也就是說所設計出來的模組要有黑箱的特性，至於模組的內部是如何運作，使用者可不予理會，只要能掌握標準界面即可。同樣的思維用到與人有關的事物上，反而會成為最壞的做法。

　　軟體經理的工作對象是「人」。在化學反應中的催化劑，其本身並不會產生變化，而只是促成其他的物質轉變成為最終產品。經理人員就猶如專案中的催化劑，他最大的責任在於營造出一個有利的環境，讓專案成員有高昂的士氣，能充分發揮所長，並獲得工作的成就感。這是軟體工程師的技能中付之闕如的一環，當他們成為經理之後，慣常以管理模組的方式來管理專案成員。以致，出現1997年Windows Tech Journal的調查結果1，其讀者對管理階層的觀感是：他們痛恨管理階層、對無能上司所形成的企業文化與辦公室政治深惡痛絕、管理階層不是助力而是阻力（獨斷、無能、又愚蠢）。

　　你還記得，或想像，你剛上任專案經理的第一天，自己是抱著怎樣的心情？狄馬克有一篇名為〈Standing Naked in the Snow〉的文章最讓我印象深刻2。他描述自己第一天上任的感覺猶如「裸身站在雪地中」，中文最貼近的形容詞是「沐猴而冠」，那種孤立無援、茫然不知所措的心境，也正是我上任第一天的寫照。想要彌補軟體工程師與軟體經理之間的這段差距，方法不外找到這類的課程或書籍。但軟體專案管理的課程在大學裡不開課，坊間的顧問公司也無人提供。至於書籍，在美國，軟體技術類書籍與軟體管理類書籍的比率是200比1，在台灣的情況則更糟，或許是我見識淺陋，我至今都未能找到一本談軟體專案管理的中文書。

　　幸好，溫伯格為我們補上了這個失落的環節。在這一套四冊的書中，他教導我們要如何來培養軟體經理所必備的四種能力：

　　1.專案進行中遇到問題時，有能力對問題的來龍去脈做通盤的思考，找出造成問題的癥結原因，以便能對症下藥，採取適切的行動，讓專案不但在執行前有妥善的規劃，在執行的過程中也能因應狀況適時修正專案計畫。避免以管窺豹，見樹不見林，而未能窺得問題的全貌，或是，頭痛醫頭，腳痛醫腳，找不到真正的病因，而使問題益形惡化。

　　2.有能力對專案的執行過程進行觀察，並且有能力對你的觀察結果所代表的意義加以解讀。猶如在駕駛一輛汽車時，若想要安全達到正確的目的地，儀表板是駕駛最重要的依據。此能力可讓專案經理在專案的儀表板上要安裝上必不可缺的各式碼表，並做出正確解讀，從而使專案順利完成，。

　　3.專案的執行都是靠人來完成，包括專案經理和專案小組的成員。每個人都會有性格缺陷和情緒反應，這使得他們經常會做出不利於專案的決定。在這種不理性又不完美的情況下，即使你會感到迷惘、憤怒、或是非常害怕，甚至害怕到想要當場逃離並找個地方躲起來，你仍然有能力採取能關照全局的行動。

　　4.為因應這不斷改變的世界，你有能力引領組織的變革，改變企業文化，走向學習型的組織。

　　李斯特（Timothy Lister）在《Peopleware》中談組織學習3時說了個小故事：我有一位客戶，他們的公司在軟體開發工作上有超過三十年的悠久歷史。在這段期間，一直都養了上千名的軟體開發人員，總計有超過三萬個「人年」的軟體經驗。對此我深感嘆服，你能想像，若是能把所有這些學習到的經驗都用到每一個新的專案上，會是怎樣的結果。因此，趁一次機會，我就向該公司的一群經理人請教，如果他們要派一位新的經理去負責一個新的專案，他們會在他耳邊叮嚀的「智慧的話語」是什麼？他們不假思索，幾乎異口同聲地回答我說：「祝你好運！」

　　希望下次當你上任軟體經理時，不會再有沐猴而冠的感覺，也不會僅帶著他人「祝你好運」的空話，而是有溫伯格的這套書《高品質軟體管理》做你堅強的後盾。
（本文作者曾昭屏為資深軟體專案經理，美國德州休士頓大學計算機科學系碩士）

1.M. Weisz, “Dilbert University,” IEEE Software (September 1998), pp. 18-22.
2.Tom DeMarco, “Standing Naked in the Snow (Variation On A Theme By Yamaura), American Programmer, Vol. 7, No. 12 (December 1994), pp. 28-30.
3.T. DeMarco and T. Lister, Peopleware: Productive Projects and Teams (New York: Dorset House Publishing, 1999), p. 210.

前言

　　對於你所談論的東西，你若是能加以量度，並以數字將之表達出來，那麼你對於那樣東西可說是有了某種程度的了解；反之，你若是無法加以量度，或是無法以數字將之表達出來，那麼你對於那樣東西的所知，則要歸於貧乏之列，或是嚴重不足之列……。
──克爾文勳爵（Lord Kelvin）

　　我從事軟體這個行業已有四十年，我學習到的經驗是，想要在軟體工程的管理工作上獲致高品質的成果，你將需要具備以下這三種基本能力：

　　 1.具有了解複雜情況的能力，以便你能為專案做好事前的規畫，從而進行觀察並採取行動，使專案能依計畫進行，或適時修正原計畫。

　　2.具有觀察事態如何發展的能力，並且有能力從你所採取的因應行動是否有效來判斷你觀察的方向是否正確。

　　3.在複雜的人際關係中，即使你會感到迷惘、憤怒、或是非常害怕，甚至害怕到讓你想要一走了之並躲起來不見人，但你仍然有能力採取合宜的行動。

　　對於一個重視品質的軟體管理人員來說，這三項能力缺一不可，但是我不想將本書寫成一本皇皇巨著。因此，如同任何一位注重品質的軟體經理人一般，我把我的寫書計畫拆成三個小計畫，在每一個小計畫中討論這三項基本能力中的一項。第一卷《系統化思考》所探討的是第一項能力──了解複雜情況的能力。第三卷《關照全局的管理作為》所探討的是第三項能力──即使在情緒激動的情況下，仍然有能力採取合宜的行動。在此第二卷《第一級評量》中，我希望你把注意力都放在觀察事態如何發展的能力，以及完全掌握你所做的觀察是否有意義的能力。 　

　　將本卷的名稱最後定案為第一級評量之前，我花了許多的時間在思索要用怎樣的書名才比較貼切。重點是，每當有一本書在書名中冠上了「評量」這樣的字眼，該書的作者似乎就不得不搬出克爾文勳爵的這一段話。我亦不能免俗，此外，我還覺得有必要分析一下克爾文勳爵經常被人引用的這段話中，他真正的本意是什麼，而不是他本意的又是什麼。 　　

　　首先，我必須要提出來的是，克爾文勳爵是一位物理學家。因此，當他說，「對於你所談論的東西，你若是能加以量度……你……可說是有了某種程度的了解，」他是以一位物理學家的觀點來說這段話，其本意是欲找出一個存在於大自然的萬有法則。物理學家在進行量度的工作時，其目的是為了尋求在學習某件事物時的樂趣，至於量度的對象為何就不是重點了。 　　

　　與此相對照的，工程師對於萬有法則毫無興趣，他們亟於想知道的只是在建造某一特定事物時，必須要用到哪些與之相關的特定法則。他們念茲在茲的是能夠順利完成某一件事，而那些胡亂弄來的評量數字則不是他們所想要的。 　　

　　雖然我從青少年時期即立志與電腦結下終身之盟，但是在學校裡我根本找不到一門與電腦教育有關的課可以上。因此，如同克爾文勳爵一樣，我所受的教育是教導我如何成為一位物理學家。如今，儘管我仍然摯愛物理，但我已自認是一位軟體工程師，而在區分這兩種知識時，我採取的原則是： 物理學的知識在於了解大自然的萬有法則。 工程學的知識在於明白要如何去完成一件事。 對於這兩種不同知識的探索工作，能夠提供支援的評量是大不相同的：我用「第三級評量」這一術語來代表「可支援物理學家尋求萬有法則」的那一類評量；比方說，對「熱力學第一定律」測試之後的結果所顯示的意義，其實是在說，若想打造出一台可永恆運轉的機器，這是絕無可能的事。 　　

　　工程師們感興趣的是我所謂的「第一級」和「第二級」的評量，它們是用於一台機器的製造工作，以及在機器製造出來後可增強其性能的調整工作上。尤其是第一級評量，它僅可用於某件事物的製造工作上；第一級評量相當於我們日常所說的「信封背後的」（或英國人說的「香煙盒背後的」）計算。這類的評量適用的場合是粗略的做法（憑經驗但無精確數據為基礎的）或概略的草圖，以及「快速但不精確的」或「純直覺的」預估工作等。第一級評量是當我們要開始動手之前，先用來決定「某一台機器是否值得去製造」的那一類評量。 　　

　　第二級評量就比較精細；適用於使系統功能得到充分發揮，並讓系統運作能夠更省錢或更快速，亦可用於使機器的性能得以調校至最有效率的狀態。第二級與第三級評量對於軟體工程界的開發工作，雖說是具有不可或缺的重要性，但兩者皆無法真正用於解決一般軟體工程經理人員在日常工作中經常會碰到的各種問題。下面的這則寓言，或許能清楚地說明為什麼我會做如此的論斷： 　　

　　半斤八兩夫婦有一對十五歲的雙胞胎兄妹，哥哥半斤和妹妹八兩，兩人都正在學開車。家裡的那輛車八兩開過了十次，而她的安全紀錄堪稱完美。同一輛車半斤也開過十次，但他卻撞過三次車。半斤八兩太太要求半斤八兩先生得去找這個兒子好好談談，否則會有人命在旦夕。 半斤八兩先生先以檢討這三次車禍為開場白，然後他問半斤說：「你有什麼話要說，來替自己辯白的？」 「這個嘛，開了十次車才出三次車禍，這個數字還不算太難看。」 「我勉強同意你的說法，」半斤八兩先生說，「不過，你的妹妹八兩也開過十次車，她連一顆小石頭砸到擋風玻璃的情況都沒有發生過。」「你說的沒錯，」半斤說，「可是我每公升汽油跑的里程數比她要高出許多。況且我的輪胎沒有沾到一點爛泥巴。」「哦，」半斤八兩先生說。「這點我倒沒有想到。好吧，從今以後，你開車時還是要盡量小心，還有，你要保持省油和不弄髒車身的優良表現。我這就去找你妹妹談談，來檢討一下她的開車習慣。」

　　即使對我們這種有多次被家裡青春期子女欺騙經驗的人來說，半斤八兩先生這個做父親的聽起來也太過愚蠢。不過，在你對他嚴加批判之前，請記得這只是一個寓言故事罷了。而這個寓言的寓意又是什麼呢？或許你已經看出來，十分之三這個數字就有軟體工程業的影子。這個數字正是我許多客戶的公司裡大型軟體專案一直都無法完工的比率。軟體的品質專家Capers Jones、Tom DeMarco、Tom Gilb等人都曾向我證實，30%這個數字與他們的經驗完全吻合。 　　

　　假設你是某所機構主管軟體開發工作的經理，該機構曾做過十個專案，其中的三個是以失敗收場。那些有專案失敗紀錄的軟體工程部門的經理人員，個個都可拿出一堆數值精確的評量數字，來向你證明，比起其他的七個專案，在這三個失敗的專案裡所花的每一塊錢皆可生產出更多行數的程式，而且每一行程式所產生的錯誤也比較少。你會因此就去找其他的專案經理來談談，檢討一下他們的管理習慣嗎？當然不會啦。 　　

　　正如John von Neumann曾說的，「當你對所談論的主題是什麼都還沒搞清楚，就要求你對某一件事的數字必須精確，這是毫無意義的。」不過，某一機構所推動的評量方案若完全是以第二級評量為基準，那麼von Neumann所描述的，正是許多參與這類評量方案的經理人員所做所為的寫照。這些經理人員的鹵莽行為或許是受到許多此類書籍作者的鼓勵而來的。其他軟體工程方面的書籍在書名中凡有「評量值（measurements）」或「量測值（metrics）」者，所討論的皆為第二級評量，而有些書甚至討論到第三級評量。Bill Silver是軟體評量的大師級人物，他亦有同感：「這件事說來可悲，但卻是實情。軟體評量的方案大多是以失敗收場。」1 　　

　　Silver的觀察結果得到Capers Jones的證實，Jones的經驗是，有八成的軟體評量方案在兩年內就無疾而終。這樣的觀察也得到許多我的客戶的證實，可以完全吻合Silver對於失敗的第一大原因，也是最主要的原因，所做的描述： 「公司的品質文化能夠為評量工作提供一個良好環境的，這樣的公司實在少之又少。」 容我說得更不客氣些。若是在一家公司中，每十個重大的軟體專案就有三個會失事墜毀，這樣的公司還不夠格去談第二級評量。更糟糕的是，這樣的公司若意圖實施一個以第二級評量為主體的評量方案，所造成的傷害將遠大於所能帶來的好處，而最終的結果極有可能是製造出一堆價值百萬美元的「亂七八糟」評量。這絕不是「為評量的工作提供一個良好的環境」。 　　

　　軟體品質文化的相關資料所顯示的是，目前機構的企業文化僅有極小比率可提供推動第二級評量方案所需的支援2。我所著的《溫伯格的軟體管理學》系列是專門設計來幫助任職於此類機構的經理人員，能讓他們在管理的工作上先求品質得到改善，然後才求日後他們可以回過頭來對所任職的機構進行改善。 　　

　　本卷的目的在於幫助任職於這類機構的經理人員，將能力提升到懂得如何善加利用第二級評量，甚至第三級評量。如果你所任職的機構在大量製造軟體產品時能夠既準時又不超出預算，且這些產品又可增添你的顧客的生命價值，並讓顧客感到欣喜──而你至少有九成的機會可達到這樣的要求──那麼你就不需要閱讀《第一級評量》這本書了。老實說，你所任職的機構若已達到此種境界，則不論你買這本書花了多少錢，我都會滿心歡喜把本書的書款悉數還給您，以換取您在品質管理工作上的心得。 　　

　　然而，你所任職的機構若尚未達到上述境界，那麼我希望能讓你明瞭如何可以「為評量工作營造一個良好的環境」，以避免多數的評量方案皆損失慘重的宿命，並且告訴你如何可以既簡單又有效率地替許多事物來進行量測，唯有這些事物才可能幫助你的機構持續不斷生產出你想要的高品質軟體。