- 定價87.00元
-
8
折優惠：HK$69.6
|
|
|
|
溫伯格的軟體管理學：第一級評量（第2卷）
|
|
庫存=1
將於1個工作天內出貨
|
|
|
|
|
|
9789867889720 | |
|
|
|
曾昭屏、陳琇玲 | |
|
|
|
經濟新潮社 | |
|
|
|
2008年8月07日
| |
|
|
|
267.00 元
| |
|
|
|
HK$ 226.95
|
|
|
|
|
| |
|
|
|
|
| |
|
|
詳
細
資
料
|
* 叢書系列：經營管理
* 規格：平裝 / 528頁 / 23*16.8cm / 普級 / 單色印刷 / 初版
* 出版地：台灣
經營管理
|
|
分
類
|
商業理財 > 專業管理實務 > 專案管理 |
同
類
書
推
薦
|
|
|
內
容
簡
介
|
如果你的專案正在走向失敗，你看得出來嗎？
觀察，是一門科學。
學會觀察「發生了什麼事」，學好評量方法，是專案成功的關鍵！
★如果《人月神話》是一種反思與沉澱，那麼《溫伯格的軟體管理學》這套書就是軟體專案管理的最佳實務！
本書《第一級評量》簡介：
要有高品質的軟體，就要有高品質的管理，因此你需要具備三項基本的能力：
1. 具有了解複雜情況的能力，你因此能為專案做好事前的規畫，並據此進行觀察及採取行動，以保持專案能依計畫進行，或是去修正原計畫。
2. 具有觀察發生了什麼事的能力，並且能夠從行動要有成效而且符合當時情況所需的觀點，來解讀你的觀察所代表的意義。
3. 在複雜的人際關係中，即使你會感到迷惘、憤怒、或是非常害怕，甚至害怕到你想要當場逃離並找個地方躲起來，但你仍然具有做出適切反應的能力。
在第1卷《系統化思考》中所談的是第一項能力－－了解複雜情況的能力。
而在本書《第一級評量》要談的是觀察發生了什麼事的能力，以及去解讀你的觀察所代表的意義的能力。就像開車需要看儀表板一樣，管理專案要看哪些指標？這些指標怎麼用？所代表的意義是什麼？這就是本書所說的「評量」。
評量為什麼很重要？
因為，如果我們想做出高品質的軟體，就必須能對軟體開發過程進行控管。所以我們需要有可靠的資訊，而為了獲取這些資訊，我們必須知道如何進行觀察。許多軟體專案最後會失敗，大多數是因為「觀察上的失敗」所致。而評量就是「進行可靠觀察」的一門藝術，也是一門科學。
第一級評量，就相當於那種「信封背面的」（或英國人說的「香菸盒背後的」）計算。這種評量大多是粗略的（憑經驗但無精確數據為基礎的）草圖，適用於「直覺式的預估工作」。坊間一般談評量的書，多是談第二級或第三級的評量，但是軟體工程經理人日常會碰到的問題，則必須仰賴第一級評量。
本書以第1卷《系統化思考》所提過的「軟體機構的文化模式」為基礎，運用「薩提爾人際互動模型」將觀察的行為分解成四個簡單步驟，以確保你的觀察正確而適時。
書中討論的主題包括：軟體文化模式；觀察的模型；讓產品和過程具有可見性；對品質的直接觀察；量測成本與價值；在失敗發生前就進行評量；言行不一的症狀；觀察者的三種立場；讓溝通、審查、需求做為評量的基礎；第零級評量；公開的專案進度海報；還有一些非數字的評量。本書有珍貴的圖表、心得、練習、各種法則與附錄，幫助讀者應用這本書。
面對專案、產品、同事、客戶等等複雜狀況，你想學著關照全局，進而將你所在機構的文化向上提升，你需要「系統化思考」，也需要有「觀察發生了什麼事的能力」，有了正確的觀察才可能有正確有效的行動。
《溫伯格的軟體管理學》一套四冊，主題分別是：
一、 系統化思考（Systems Thinking）、
二、 第一級評量（First-Order Measurement）、
三、 關照全局的管理作為（Congruent Action）、
四、 擁抱變革（Anticipating Change）。
作者簡介
傑拉爾德．溫伯格（Gerald M. Weinberg）
是美國軟體工程界大師級的人物。在40多年的軟體業生涯中，他曾任職於IBM、Ethnotech、水星計畫（美國第一個載人太空計畫），並曾任教於多所大學。他更是傑出的軟體專業作家和軟體管理思想家，因對技術問題與人性問題所提出的創新思考法而為世人所推崇。1997年，溫伯格因其在軟體領域的傑出貢獻，入選為美國計算機博物館的「計算機名人堂」成員。他也榮獲J.-D. Warnier獎項中的「資訊科學類卓越獎」，此獎每年一度頒發給在資訊科學領域對理論與實際應用有傑出貢獻的人士。
溫伯格共寫了 30幾本書，包括《顧問成功的祕密》、《你想通了嗎？》、《領導的技術》、《從需求到設計》（以上由經濟新潮社出版）、《程式設計的心理學》、一共四冊的《溫伯格的軟體管理學》等等，這些著作主要涵蓋兩個主題：人與技術的結合；人的思維模式、思維習慣與解決問題的方法。在西方國家，溫伯格擁有大量的忠實讀者。溫伯格現為Weinberg and Weinberg顧問公司的負責人，他的網站是www.geraldmweinberg.com
譯者簡介
曾昭屏
(負責第一、二、三部)
交大計算機科學系畢，美國休士頓大學計算機科學系碩士。譯作有《顧問成功的祕密》、《溫伯格的軟體管理學：系統化思考（第1卷)》。專長領域：軟體工程、軟體專案管理、軟體顧問。最喜歡的作者：Tom DeMarco, Gerald Weinberg, Steve McConnell.
Email: marktsen@hotmail.com
陳琇玲（Joyce Chen）
(負責第四、五部與附錄)
美國密蘇里大學工管碩士，曾任嶺東科技大學講師、行政院國科會助理研究員、Alcatel Telecom系統程序專員、ISO 9000主任稽核師暨TickIT軟體品質稽核師，現專事翻譯、譯作甚豐。相關譯作包括《第五項修鍊III—變革之舞》、《杜拉克精選：個人篇》、《ERP進階實務》、《供應鏈策略管理五大修練》、《市場的真相》、《搜尋未來》、《川普清崎讓你賺大錢》、《投資大趨勢》。
|
|
目
錄
|
致台灣讀者 溫伯格
導讀 曾昭屏
前言
序言：一個觀察模型
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。我所著的《溫伯格的軟體管理學》系列是專門設計來幫助任職於此類機構的經理人員，能讓他們在管理的工作上先求品質得到改善，然後才求日後他們可以回過頭來對所任職的機構進行改善。
本卷的目的在於幫助任職於這類機構的經理人員，將能力提升到懂得如何善加利用第二級評量，甚至第三級評量。如果你所任職的機構在大量製造軟體產品時能夠既準時又不超出預算，且這些產品又可增添你的顧客的生命價值，並讓顧客感到欣喜──而你至少有九成的機會可達到這樣的要求──那麼你就不需要閱讀《第一級評量》這本書了。老實說，你所任職的機構若已達到此種境界，則不論你買這本書花了多少錢，我都會滿心歡喜把本書的書款悉數還給您，以換取您在品質管理工作上的心得。
然而，你所任職的機構若尚未達到上述境界，那麼我希望能讓你明瞭如何可以「為評量工作營造一個良好的環境」，以避免多數的評量方案皆損失慘重的宿命，並且告訴你如何可以既簡單又有效率地替許多事物來進行量測，唯有這些事物才可能幫助你的機構持續不斷生產出你想要的高品質軟體。
|
|
|
書
評
|
|
|
|
|
