《溫伯格的軟體管理學：第一級評量（第2卷）》（Quality Software Management, Volume 2: First-Order Measurement）

｜前言｜

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

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

1. 具有瞭解複雜情況的能力，以便你能為專案做好事前的規劃，從而進行觀察並採取行動，使專案能依計劃進行，或適時修正原計劃。
2. 具有觀察事態如何發展的能力，並且有能力從你所採取的因應行動是否有效來判斷你觀察的方向是否正確。
3. 在複雜的人際關係中，即使你會感到迷惘、憤怒、或是非常害怕，甚至害怕到讓你想要一走了之並躲起來不見人，但你仍然有能力採取合宜的行動。

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

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

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

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

雖然我從青少年時期即立志與電腦結下終身之盟，但是在學校裡我根本找不到一門與電腦教育有關的課可以上。因此，如同克爾文勳爵一樣，我所受的教育是教導我如何成為一位物理學家。如今，儘管我仍然摯愛物理，但我已自認是一個軟體工程師，而在區分這兩種知識時我採取的原則是：

● 物理學的知識在於瞭解大自然的萬有法則。
● 工程學的知識在於明白要如何去完成一件事。

對於這兩種不同知識的探索工作，能夠提供支援的評量是大不相同的：我用「第三級評量」這一術語來代表「可支援物理學家尋求萬有法則」的那一類評量；比方說，對「熱力學第一定律」測試之後的結果所顯示的意義，其實是在說，若想打造出一台可永恆運轉的機器，這是絕無可能的事。

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

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

半斤八兩夫婦有一對十五歲的雙胞胎兄妹，哥哥半斤和妹妹八兩，兩人都正在學開車。家裡的那輛車八兩開過了十次，而她的安全紀錄堪稱完美。同一輛車半斤也開過十次，但他卻撞過三次車。半斤八兩太太要求半斤八兩先生得去找這個兒子好好談談，否則會有人命在旦夕。

半斤八兩先生先以檢討這三次車禍為開場白，然後他問半斤說：「你有什麼話要說，來替自己辯白的？」

「這個嘛，開了十次車才出三次車禍，這個數字還不會太難看。」

「我勉強同意你的說法，」半斤八兩先生說，「不過，你的妹妹八兩也開過十次車，她連一顆小石頭砸到擋風玻璃的情況都沒有發生過。」

「你說的沒錯，」半斤說，「可是我每公升汽油跑的里程數比她要高出許多。況且我的輪胎沒有沾到一點爛泥巴。」

「哦，」半斤八兩先生說。「這點我倒沒有想到。好吧，從今以後，你開車時還是要盡量小心，還有，你要保持省油和不弄髒車身的優良表現。我這就去找你妹妹談談，來檢討一下她的開車習慣。」

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

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

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

Silver的觀察結果得到Capers Jones的證實，Jones的經驗是，有八成的軟體評量方案在兩年內就無疾而終。這樣的觀察也得到許多我的客戶的證實，可完全吻合Silver對於失敗的第一大原因，也是最主要的原因，所做的描述：

「公司的品質文化能夠為評量工作提供一個良好環境的，實在少之又少。」

容我說得更不客氣些。若是在一家公司中，每十個重大的軟體專案就有三個會失事墜毀，這樣的公司還不夠格去談第二級評量。更糟糕的是，這樣的公司若意圖實施一個以第二級評量為主體的評量方案，所造成的傷害將遠大於所能帶來的好處，而最終的結果極有可能是製造出一堆價值百萬美元的「亂七八糟」評量。這絕不是「為評量的工作提供一個良好的環境」。

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

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

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