前言
對於你所談論的東西，你若是能加以量度，並以數字將之表達出來，那麼你對於那樣東西可說是有了某種程度的了解；反之，你若是無法加以量度，或是無法以數字將之表達出來，那麼你對於那樣東西的所知，則要歸於貧乏之列，或是嚴重不足之列……。
──克爾文勳爵（Lord Kelvin）
我從事軟體這個行業已有四十年，我學習到的經驗是，想要在軟體工程的管理工作上獲致高品質的成果，你將需要具備以下這三種基本能力：
1.具有了解複雜情況的能力，以便你能為專案做好事前的規畫，從而進行觀察並採取行動，使專案能依計畫進行，或適時修正原計畫。
2.具有觀察事態如何發展的能力，並且有能力從你所採取的因應行動是否有效來判斷你觀察的方向是否正確。
3.在複雜的人際關係中，即使你會感到迷惘、憤怒、或是非常害怕，甚至害怕到讓你想要一走了之並躲起來不見人，但你仍然有能力採取合宜的行動。
對於一個重視品質的軟體管理人員來說，這三項能力缺一不可，但是我不想將本書寫成一本皇皇巨著。因此，如同任何一位注重品質的軟體經理人一般，我把我的寫書計畫拆成三個小計畫，在每一個小計畫中討論這三項基本能力中的一項。第一卷《系統化思考》所探討的是第一項能力──了解複雜情況的能力。第三卷《關照全局的管理作為》所探討的是第三項能力──即使在情緒激動的情況下，仍然有能力採取合宜的行動。在此第二卷《第一級評量》中，我希望你把注意力都放在觀察事態如何發展的能力，以及完全掌握你所做的觀察是否有意義的能力。
將本卷的名稱最後定案為第一級評量之前，我花了許多的時間在思索要用怎樣的書名才比較貼切。重點是，每當有一本書在書名中冠上了「評量」這樣的字眼，該書的作者似乎就不得不搬出克爾文勳爵的這一段話。我亦不能免俗，此外，我還覺得有必要分析一下克爾文勳爵經常被人引用的這段話中，他真正的本意是什麼，而不是他本意的又是什麼。
首先，我必須要提出來的是，克爾文勳爵是一位物理學家。因此，當他說，「對於你所談論的東西，你若是能加以量度……你……可說是有了某種程度的了解，」他是以一位物理學家的觀點來說這段話，其本意是欲找出一個存在於大自然的萬有法則。物理學家在進行量度的工作時，其目的是為了尋求在學習某件事物時的樂趣，至於量度的對象為何就不是重點了。
與此相對照的，工程師對於萬有法則毫無興趣，他們亟於想知道的只是在建造某一特定事物時，必須要用到哪些與之相關的特定法則。他們念茲在茲的是能夠順利完成某一件事，而那些胡亂弄來的評量數字則不是他們所想要的。
雖然我從青少年時期即立志與電腦結下終身之盟，但是在學校裡我根本找不到一門與電腦教育有關的課可以上。因此，如同克爾文勳爵一樣，我所受的教育是教導我如何成為一位物理學家。如今，儘管我仍然摯愛物理，但我已自認是一位軟體工程師，而在區分這兩種知識時，我採取的原則是： 物理學的知識在於了解大自然的萬有法則。 工程學的知識在於明白要如何去完成一件事。 對於這兩種不同知識的探索工作，能夠提供支援的評量是大不相同的：我用「第三級評量」這一術語來代表「可支援物理學家尋求萬有法則」的那一類評量；比方說，對「熱力學第一定律」測試之後的結果所顯示的意義，其實是在說，若想打造出一台可永恆運轉的機器，這是絕無可能的事。
工程師們感興趣的是我所謂的「第一級」和「第二級」的評量，它們是用於一台機器的製造工作，以及在機器製造出來後可增強其性能的調整工作上。尤其是第一級評量，它僅可用於某件事物的製造工作上；第一級評量相當於我們日常所說的「信封背後的」（或英國人說的「香煙盒背後的」）計算。這類的評量適用的場合是粗略的做法（憑經驗但無精確數據為基礎的）或概略的草圖，以及「快速但不精確的」或「純直覺的」預估工作等。第一級評量是當我們要開始動手之前，先用來決定「某一台機器是否值得去製造」的那一類評量。
第二級評量就比較精細；適用於使系統功能得到充分發揮，並讓系統運作能夠更省錢或更快速，亦可用於使機器的性能得以調校至最有效率的狀態。第二級與第三級評量對於軟體工程界的開發工作，雖說是具有不可或缺的重要性，但兩者皆無法真正用於解決一般軟體工程經理人員在日常工作中經常會碰到的各種問題。下面的這則寓言，或許能清楚地說明為什麼我會做如此的論斷：
半斤八兩夫婦有一對十五歲的雙胞胎兄妹，哥哥半斤和妹妹八兩，兩人都正在學開車。家裡的那輛車八兩開過了十次，而她的安全紀錄堪稱完美。同一輛車半斤也開過十次，但他卻撞過三次車。半斤八兩太太要求半斤八兩先生得去找這個兒子好好談談，否則會有人命在旦夕。
半斤八兩先生先以檢討這三次車禍為開場白，然後他問半斤說：「你有什麼話要說，來替自己辯白的？」
「這個嘛，開了十次車才出三次車禍，這個數字還不算太難看。」
「我勉強同意你的說法，」半斤八兩先生說，「不過，你的妹妹八兩也開過十次車，她連一顆小石頭砸到擋風玻璃的情況都沒有發生過。」
「你說的沒錯，」半斤說，「可是我每公升汽油跑的里程數比她要高出許多。況且我的輪胎沒有沾到一點爛泥巴。」
「哦，」半斤八兩先生說。「這點我倒沒有想到。好吧，從今以後，你開車時還是要盡量小心，還有，你要保持省油和不弄髒車身的優良表現。我這就去找你妹妹談談，來檢討一下她的開車習慣。」
即使對我們這種有多次被家裡青春期子女欺騙經驗的人來說，半斤八兩先生這個做父親的聽起來也太過愚蠢。不過，在你對他嚴加批判之前，請記得這只是一個寓言故事罷了。而這個寓言的寓意又是什麼呢？或許你已經看出來，十分之三這個數字就有軟體工程業的影子。這個數字正是我許多客戶的公司裡大型軟體專案一直都無法完工的比率。軟體的品質專家Capers Jones、Tom DeMarco、Tom Gilb等人都曾向我證實，30%這個數字與他們的經驗完全吻合。
假設你是某所機構主管軟體開發工作的經理，該機構曾做過十個專案，其中的三個是以失敗收場。那些有專案失敗紀錄的軟體工程部門的經理人員，個個都可拿出一堆數值精確的評量數字，來向你證明，比起其他的七個專案，在這三個失敗的專案裡所花的每一塊錢皆可生產出更多行數的程式，而且每一行程式所產生的錯誤也比較少。你會因此就去找其他的專案經理來談談，檢討一下他們的管理習慣嗎？當然不會啦。
正如John von Neumann曾說的，「當你對所談論的主題是什麼都還沒搞清楚，就要求你對某一件事的數字必須精確，這是毫無意義的。」不過，某一機構所推動的評量方案若完全是以第二級評量為基準，那麼von Neumann所描述的，正是許多參與這類評量方案的經理人員所做所為的寫照。這些經理人員的鹵莽行為或許是受到許多此類書籍作者的鼓勵而來的。其他軟體工程方面的書籍在書名中凡有「評量值（measurements）」或「量測值（metrics）」者，所討論的皆為第二級評量，而有些書甚至討論到第三級評量。Bill Silver是軟體評量的大師級人物，他亦有同感：「這件事說來可悲，但卻是實情。軟體評量的方案大多是以失敗收場。」
Silver的觀察結果得到Capers Jones的證實，Jones的經驗是，有八成的軟體評量方案在兩年內就無疾而終。這樣的觀察也得到許多我的客戶的證實，可以完全吻合Silver對於失敗的第一大原因，也是最主要的原因，所做的描述： 「公司的品質文化能夠為評量工作提供一個良好環境的，這樣的公司實在少之又少。」 容我說得更不客氣些。若是在一家公司中，每十個重大的軟體專案就有三個會失事墜毀，這樣的公司還不夠格去談第二級評量。更糟糕的是，這樣的公司若意圖實施一個以第二級評量為主體的評量方案，所造成的傷害將遠大於所能帶來的好處，而最終的結果極有可能是製造出一堆價值百萬美元的「亂七八糟」評量。這絕不是「為評量的工作提供一個良好的環境」。
軟體品質文化的相關資料所顯示的是，目前機構的企業文化僅有極小比率可提供推動第二級評量方案所需的支援2。我所著的《溫伯格的軟體管理學》系列是專門設計來幫助任職於此類機構的經理人員，能讓他們在管理的工作上先求品質得到改善，然後才求日後他們可以回過頭來對所任職的機構進行改善。
本卷的目的在於幫助任職於這類機構的經理人員，將能力提升到懂得如何善加利用第二級評量，甚至第三級評量。如果你所任職的機構在大量製造軟體產品時能夠既準時又不超出預算，且這些產品又可增添你的顧客的生命價值，並讓顧客感到欣喜──而你至少有九成的機會可達到這樣的要求──那麼你就不需要閱讀《第一級評量》這本書了。老實說，你所任職的機構若已達到此種境界，則不論你買這本書花了多少錢，我都會滿心歡喜把本書的書款悉數還給您，以換取您在品質管理工作上的心得。
然而，你所任職的機構若尚未達到上述境界，那麼我希望能讓你明瞭如何可以「為評量工作營造一個良好的環境」，以避免多數的評量方案皆損失慘重的宿命，並且告訴你如何可以既簡單又有效率地替許多事物來進行量測，唯有這些事物才可能幫助你的機構持續不斷生產出你想要的高品質軟體。
第1章
為什麼觀察很重要？
能夠感動人的不是事物的本身，而是人對事物的看法。
──艾彼科蒂塔斯（Epictetus）
我們所開發的軟體若想要有穩定的品質，就必須對軟體的開發過程及服務過程加以控管。然而，我們若缺乏可靠的資訊，就無法對任何工作過程有一致的控管。
欲獲取這類資訊，我們必須先學習如何進行觀察。軟體工程在管理上的失敗，究其原因大多與觀察上的失敗有關。
評量工作是「進行可靠觀察」的一門藝術，也是一門科學。本章將會討論由不良的觀察所造成常見的失敗的例子，並提供一些模型來說明失敗何以發生。
1.1管理上的失敗：是危機還是幻覺？
不論何時，軟體工程在管理上的失敗，問題十有八九都出在品質上。不過，品質變壞並非一夕之間發生，而是經年累月的結果。可是，仍有許多經理人把這類的失敗稱作是一個危機，或是一個突發且不可預期的事件。是什麼原因使他們會有這樣的幻覺？
管理者會抱持這種危機的觀點，在某種程度上是源自人類在面對失敗時天生就有逃避責任的傾向。一個滿懷恐懼的經理人心底的想法是：「專案若是因一個危機而土崩瓦解，又怎能怪罪到我的頭上？」不過幸好，會自欺欺人又滿懷恐懼的管理者通常只占少數；多數的時候，多數的經理人都不會自欺欺人又滿懷恐懼。
面臨危機時人們的確容易心生恐懼。承受巨大壓力的經理人會真的相信他們是一個突發危機的受害者，那是因為他們意識到失敗已迫在眉睫，是突然間意識到的。換句話說，危機有多突然，這不是對危機的量測值，而是對經理人意識能力的量測值。他們若是能做好觀察的工作（這是優秀的經理人必須做到的），或許他們會感到失望，但絕不會感到吃驚。我很喜歡對經理人說的一句話是：
不要誤把一個幻覺的結束當作是一個危機的開始。
系統如果過於複雜，人們很容易成為幻覺的俘虜，這些幻覺完全沒有客觀真實的基礎。無人能免於幻覺的侵襲，軟體工程的經理人尤然。
1.2透視軟體文化
讓我們以「找出一個機構的軟體文化模式」這個問題，做為軟體工程上有嚴重幻覺的一個例子。在本系列叢書的第一卷、名為《系統化思考》1的那本書中，我們已檢視過軟體文化模式的細節，此處我僅簡單回顧與觀察相關的一些觀念。（想要知道某一個模式更詳細的資料，請參閱附錄C與附錄D。）
1.2.1文化是什麼？
人類學家會去研究文化，有時他們將文化定義為「你知道你並不知道你知道的那類東西」。文化是由有意義的符號所組成的一個無形且任意的系統，其中包括了語言與說話的方式、工具與使用的方式、以及影響他人與受人影響的方式。文化也會對改變抱持保守的態度，往往會利用因改變而啟動的控制機制來讓自己得以保存下來。文化會保存的一樣東西就是它的產品，因此透過對產品的研究，我們可以得知生產這些產品所用的工作過程是什麼，其方法與人類學家利用從廢墟中出土的遺物來研究古代的工藝水準大致類似。
1.2.2軟體次文化的六種模式
就我所知，克勞斯比（Philip Crosby）2 是把文化模式的概念用於研究工業生產過程的第一人。與人類學家一樣，他也發現組成一門技術的各種生產過程並不是一種隨機的組合，而是由一套有先後關係的模式所組成。克勞斯比稱這五種模式為：
1.半信半疑（Uncertainty）
2.覺醒（Awakening）
3.啟蒙（Enlightenment）
4.明智（Wisdom）
5.確信（Certainty）
此法大致上是根據在每一模式中所見到的「管理階層的態度」來分類。3
在Radice等人的〈程式設計過程之研究〉4一文中，將克勞斯比「依品質來分層」的方法應用到軟體開發工作上。軟體工程學會（SEI）鼎鼎大名的軟體品質專家韓福瑞（Watts Humphrey）繼續發揚光大，找出一個軟體機構成長之路上必經之「過程成熟度」（process maturity）的五個等級5。這五個模式分別是：
1.啟始（Initial）
2.可重複（Repeatable）
3.加以定義（Defined）
4.加以管理（Managed）5.最佳化（Optimizing）
SEI所用的這些名稱與每個模式中的「過程類型」（types of processes）6比較有關，而與管理階層的態度（克勞斯比的觀點）比較無關。依照我個人在組織方面的工作經驗，我比較偏好克勞斯比把重點放在管理階層及其態度之上。
以克勞斯比的研究成果為基礎，我再加上我工作夥伴丹妮的專業知識（她是一位人類學家）。我們的工作方法是採用人類學上的「參與式觀察」7模型。此模型講求觀察者要與關係人同甘共苦，才能掌握他們第一手的情況。利用此模型，我們往往能觀察到機構最底層的真實狀況，而不僅僅是管理階層做了什麼、說了什麼。我們會特別留意機構的各個不同部門中「所說與所做之間一致的程度」。若是按照「人們說他們是怎麼做的」來將機構分類，我們可以將之分類為如下的幾種模式系統：
0.渾然不知：「我們都不知道我們正循著一個過程在做事。」
1.變化無常：「我們全憑當時的感覺來做事。」
2.照章行事：「我們凡事皆依照工作慣例（除非我們陷入恐慌）。」
3.把穩方向：「我們會選擇結果較好的工作慣例來行事。」
4.防範未然：「我們會參照過往的經驗制定出一套工作慣例。」
5.全面關照：「人人時時刻刻都會參與所有事務的改善工作。」
這是我在本書中從頭到尾在描述各種不同的機構時會用到的一套分類法。要特別一提的是，我最關心的是前三種模式與後三種模式之間對評量工作所持態度的不同，因為那是一個重大轉變發生的地方──也就是朝向把穩方向型管理法的轉型。
而第一級評量就是朝向高品質軟體管理法轉型時的關鍵要素。
1.2.3找出組織文化模式的調查法
文化都具有保守的特性，不喜改變的發生，因此經理人想要改變一個機構時都必須從了解其文化模式開始下手。欲找出所屬模式為何，他們需要進行某些觀察。
SEI為找出軟體文化模式為何而開發出一套方法，那就是利用「自我評鑑的問卷」8來進行調查。在此列舉此調查法初期版本101個問題中的幾個典型問題：
對於有軟體開發人員參與的專案，是否每一專案都有人負責軟體型態管制（configuration control）的工作？
是否為軟體開發人員設計了一套軟體工程的訓練課程？且人人都經過此訓練？
是否有一套機制用以決定何時要在軟體開發過程中引進新技術？
在單元測試案例的準備工作上，是否有一套標準可供採用？
軟體設計上的錯誤是否有蒐集相關的統計資料？
是否有一套機制用以定期與顧客做技術的交流？
顯然，設計這套調查法的人對於何謂有效的「軟體工程開發過程」有相當深入的了解。此外，此調查法還強調「對問卷作答時應反映貴機構標準的實際做法」。既然先天條件如此嚴格，為什麼這樣的調查還會導致管理階層產生幻覺呢？有什麼地方出了問題嗎？
聽從我的同事布萊恩（Brian Nejmeh）的建議，我將這些調查問卷中的問題拿給我客戶的幾家機構試做。其中的一家機構，我拿問卷給資訊系統部門的副總、直接向他報告的四位處長、再下一級抽樣的11位經理、以及抽樣的11位軟體工程師（他們有各種頭銜，但都是實際上動手做產品和維護工作的人）。然後，我計算了一下對問卷中101個問題回答「是」的有幾個（答「是」意味著有好的實際做法），並依照不同的工作頭銜繪製成圖。這家機構的調查結果如圖1-1所示。
顯然，高階管理者對於軟體工程的開發程序，比起實際執行這些程序的工程師，看法要樂觀許多。單看這所機構，其經理人會認為（例如）發出「定期與顧客做技術的交流」的命令就代表這些交流將會實際發生。而工程師才會知道這些交流真正發生的機率有多少。
SEI會提供自我評鑑相關技術上的訓練以避免抽樣所造成的誤差，並且SEI較中意的做法是，自我評鑑要由外來的中立機構在進行其他調查時一併執行。很不幸，有許多機構在進行這類調查時並未遵照此要求。這樣的話，調查的對象完全不包括工程師，僅只做到經理人員，且通常是在副總的層級。機構的文化未來要如何發展，此類規畫的工作就是由這些副總所做的。你若是發現一所機構因為有這樣的「層級的幻覺」而很少願意對其生產力做改善，你會感到意外嗎？
2024專利防護中