度量面面观
度量面面觀<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
?
在中國，要在項目里建立一個度量體系非常難。我觀察到的情況是大部分項目都沒有度量的概念。但是我們大部分的項目，尤其是關鍵的項目，總能完成。從此，我們可以說項目的完成不需要度量。另一方面，我們常常都會有一些定性的、有關項目績效的概念。我們會認為這個項目做得好，哪個沒有那么好。有一次，我跟一位所長談話，他們的研究所，是過程做得非常表面的那種，他說，他們有些項目是世界一流的。我就問他，“你是如何判斷項目是世界一流的？”他的回答都是一些泛泛之詞。我就希望他可以說出一些明確的指標。但是他就是不能。?
其實是否世界一流可以從多個方面衡量：比如生產力、目標的滿足頻率、技術含量等等。這些都可以用數據表達的。不用數據，沒有量化的準則，很多時候，我們心中的印象嚴重偏離了現實都不知道。?
所以說，度量的重要性和意義，不一定在于非度量不能完成任務，而是沒有度量，我們就不可能正確地了解實際情況。就不能有效地提高與改進我們的項目效能。所以度量的使用在成熟的團隊里是非常常見與普遍的。否則他們是很難發展成為成熟高效的團隊的。?
那么，為什么建立度量體系這么難呢？這里零散地羅列一些原因，希望有利于大家克服這些困難。?
統計意識?
建立度量體系需要有統計意識。因為不習慣度量所要求的統計概念，往往就會不合理地使用個別的數據。其實過程是在很多很多的因素和條件地下開展的，所以同等的技能，在不同的實施也會有不同的績效。所以一個過程，實施了多次之后，他們的數據的整體，包括中間趨勢，偏差幅度，才能有效地代表這個過程的效能。這個就是“過程的聲音”，它代表了我們組織里的過程效能。?
就是因為這個原因，我們不能使用個別的績效來正確衡量個別的過程的績效，更加不能拿過程數據來衡量個人，因為使用過程數據來衡量個人的話，就一定很難建立可靠的度量體系。因為沒有人會提供對自己不利的數據和信息的。因為要得到有利的數據，要么數據就不真實，要么過程是被歪曲（做一些對滿足目標無關的事情）的。?
不知道要度量那些因素。?
一般項目在開始使用度量時就要定義很多很多的度量要求，希望可以避免遺漏。這是費時失事的，因為數據的收集和管理，成本是不簡單的。我們需要明確度量那些因素，不一定需要一大堆，但是需要度量能解決問題的因素。這個需要由領導開始。比如，領導希望知道自己的團隊的響應性、生產力（效率）、以及工作質量么？這是理所當然的。可能它們之間有一定的比重和優先級，但一定不能離開這些。那么，領導就應該關注制定這三個因素的度量定義，并要求經常定期的收集與匯報，進行分析以利了解團隊的效能。?
平衡監控?
很多時候，我們只關注了部分的度量。其實每一個過程或是組織單元，都有一組意義上相對獨立，但實際上相互影響的因素。比如項目的效能，就有“周期、效率、產品質量”三個因素。這三個因素其實是最小的一組“直交”（orthogonal）因素。如果我們只關注這個基本的因素集里面的個別因素的話，比如只關注周期，項目的效率和產品質量都會受影響。所以合理的度量使用，應該同時監控所有的基本因素（不要擔心，也不會有太多），否則我們就沒有平衡這些因素的能力。當然，項目的目標，可以對這些因素有不同的重視程度和優先級。?
準確與一致的比較?
一個經常聽到的、讓度量體系建立不了的原因，就是“不能收集到準確的數據”，或是“如果不是每一個數據都準確，就沒有用”。如果我們要求每個數據都是準確的，這樣一定很難，甚至不可能。但其實度量的定義明確，收集方法得到遵守，執行沒有例外情況就可以了，不一定要每一個數據都驗證清楚，這一定太費功夫了。?
在數量達到大概50個以上的一致數據，數據之間的偏差就會被中和掉。就是數據不是很一致，我們還是可以從收集到的數據說明一部分問題的。所以不需要要求每個數據都是準確的。?
員工的態度?
很多員工都覺得自己沒有度量的責任。其實每一位員工都應該有理想，對自己有要求，這樣才能進步。要對自己有要求，就得知道自己的效能。換句話說，就是自己要有度量自己效能的數據。如果團隊有度量的需要，那么團隊的成員就有責任收集所需的數據，提供過程的可視性，讓改進提高創造條件。?
另外一個借口就是“度量很難”。對于不習慣用數據說話的人，度量看起來有點難，因為還不清楚如何去思考度量的意義和用途。對這些同志，我可以提議歸類法。歸類法（taxonomy）是一個簡單有用的方法?？偨Y以上的原因，度量難的原因，不出“目標不明確、度量技能、態度”這三個方面。大家就自己分析一下吧。?
說到難，其實要得到度量的好處也不很難。但是要有幾個基本的原則。?
第一，一定要明確度量的目標和意義。 度量的意義在于提供一個反映實際的精確指標。所以我們的度量目標，就是提供我們過程效能的量化指標。比如項目的指標，開始時用三個就夠了：周期、效率、質量；但是要一起監控。作為一位領導，要幫助團隊提高，就需要監控所有的項目，看大家在一段時間之內的發展趨勢，是否對頭。也需要觀察項目是否能夠在關鍵因素之間找到最佳的平衡。這就提供了一個管理的依據，是持續改進的基礎。?
從項目組的角度，既然能夠通過度量關鍵的因素，看到因素之間的關系，那就更能夠有效處理這些因素。比如，以前單單關注進度。我們就會通過度量周期、效率、和質量，看到在什么條件底下縮短周期，對效率和質量有什么影響。不同時監控這三個因素，就不能了解他們之間的關系，就不能有效平衡項目的這幾個關鍵因素。?
這就好像是一個迪士尼的米老鼠氣球一樣，他有一個頭，上面有兩個大耳朵，一共是三個小球連在一起。如果你抓他的其中一個小球，其他兩個就會膨脹，米老鼠就變形了。單單抓一個因素的管理理念造成的效果，就像米老鼠的氣球一樣變形，我稱它做“氣球效應”。擺脫了氣球效應，我們才可以了解因素之間的關系，從而提高項目平衡這些因素的能力，達到最佳的效果。所以只有這樣，才能有效地持續改進、提高。?
領導明確了要求項目平衡這些因素之后，項目了解了因素之間的關系，就自然會要求有針對性的改善項目的個別活動或是過程單元。那么，項目立刻就面臨一些問題，比如哪些活動對項目的目標影響最大？這個問題重要，因為我們要優先改進最關鍵的活動。另外一個問題就是，如何制訂這些活動有效性的指標？我們需要用度量來回答這些問題。很多同志都說不明白如何制訂度量目標。為這些問題找答案，就是我們的度量目標。?
決定哪些活動影響最大的量化方法比較復雜，基本上是敏感性分析。開始的時候，大家不妨用定性的主觀推測。6 sigma黑帶和SCAMPI評估師一定會批評我。但是相信我，這樣做不需要太多的經驗，比較有效。只要大家答應在習慣度量的使用之后，一定要用量化的敏感分析就可以了。?
在一般的軟件項目里，要滿足項目的進度目標，最關鍵的活動，可能就是通過各個里程碑的成功率，如客戶接受方案之前的確認次數，版本構建的成功率，通過系統測試的版本數等等。次數越少，對進度越有利。項目就要度量這些次數。這樣項目就制定了一些度量定義了。比如要滿足項目的效率目標，影響最大的，可能就是每一個活動的效率，比如項目里所有的會議，需求收集、編碼、測試等效率?？赡苡绊懶实囊舶ǜ黝惢顒拥墓ぷ髁亢椭芷诘姆峙?。分派合理，就提高效率，如需求、編碼、測試的比例，或是管理與開發的比例等等。這些活動的度量定義，有些是容易的，有些不那么容易。要知道，這些因素都是相關聯的，一時未必可以理順，所以還是主觀地找一些關鍵的和可以度量的開始，就可以了。?
讓我舉兩個案例吧。第一個，要支持項目的效率目標，我們知道項目有些活動是直接關聯到最終產品的，有些不是。那么，主觀上，有關聯的活動的比例越大越好。那么，我們可以制定哪些是關聯強的，如需求、編碼等等；哪些是關聯弱的，如培訓、會議、測試等等。我們就統計這兩種活動的工作量。更簡單一點，我們可以單單統計其中一種也可以。?
第二個案例，就是找其中一個活動來度量，比如會議。有關會議的測量，同樣可以是進度、效率和質量。會議的進度比較簡單，就是開會的時間。但卻不是最關鍵的。效率呢，就需要有一個會議的成就的度量。我提議用議程項或是決策項就可以了，反正會議是要來做決策解決問題的。會議的質量呢，就沒有那么明確了。想一想，什么會議我們覺得是高質量的?？赡苁菦Q策之前，考慮比較多的因素，可能是所有開會的人都發言，也可能是會議的決策沒有被推翻。要有一個正確的會議質量度量比較復雜。我們就要判斷是否值得。不值得可以壓根兒不度量。一個變通的辦法就是簡化其中的因素，比如強調考慮過的因素是否充分，就不考慮決策的接受率或是實施率等等。這樣當然有不準確的風險。我們不能因為不準確就不去度量，只要小心決定這個風險是可以承擔就可以了。這樣我們就可以制訂會議的度量，如：參加人數、會議時間、議程或決策點、討論的因素、與會人員的發言比例（有興趣可以想一下如何定義這個度量）等等。?
請留意，這些判斷取舍，是按最能表達項目能否滿足目標，衡量實際情況，考慮風險之后而作的，不是隨意的，為個人、形勢等其他與項目目標沒有關系的原因而作的。這個非常重要。?
第二，度量定義，最好能夠是和過程相輔相成的。?
數據的產生，最好可以理所當然地由過程產生。但不要過分依賴工具?；疽蛩仉x不開周期、規模、工作量、與質量。在這里，就談一下這幾個度量的一些簡單定義。?
周期?
周期的定義，在乎始點和終點。如果我們希望使用度量來讓自己的業績好看一點，我們就會千方百計地把“始點”的定義延后，把“終點”的定義推前。這只是自己騙自己而已。反之，我們應該盡量地把試點定義為全部的開發活動。這就是項目已經具備資源以開展開發活動的時候開始。這些資源，未必是全部的資源，只要可以啟動開發活動就可以了。項目的開發活動，包括開發產品需求，系統方案，實施，確認與驗證，以及獲取客戶的接收。項目具備資源開展任何以上的部分活動，這個一般是制訂產品需求，就是項目的“始點”?！敖K點”不應該時系統測試通過，因為這個定義有利益沖突。了解這點，“終點”就理所當然地是獲得客戶的接收了。?
這樣的定義，項目經理很有意見，因為現在的管理理念，項目經理未必有這個權力來處理好一頭一尾的時間段。這就是誤解了度量的用處。我們有一個用度量來評價人或是項目的心態。這是奧林匹克比賽的度量觀。每一個獨立的數據點都是全部的意義。這是不對的。同一個活動，不同的實施，就受到不同的氛圍、條件限制。同一個活動的兩個實施，不一定是可比的。這不符合過程的度量觀。?
過程的度量觀是反映團隊的效能。一個組織的效能，就是所有項目的效能的總和。就是說，所有項目的效能（其中包括項目經理和成員的技能）數據作為一個集，才能代表組織的文化氛圍與過程能力。如果組織不能合理有效地處理資源的下達，獲取客戶的接收，那么度量的確應該反映團隊不具備很好的效能這個現實。正確的管理理念，就是領導需要看見這個現實，從過程的角度，考慮如何提高改進，而不是追究責任！領導的責任，就是分析這個項目的效能數據集，從而找到改進的道路，幫助組織提高效能。?
規模?
軟件項目，規模通常就是代碼行。這是無可厚非的。也有使用功能點的。代碼行是產品的規模。功能點才是項目的規模，因為這是項目需要實施的功能。功能點有兩個問題：第一，它適合以人本交易（tansaction）為主的系統，如財務等企業信息或是網上的C-B和B-B 的系統。對其他通訊、自動化、遙控等系統不很適用。第二，這類方法有很多微調的要求，需要對方法以及應用領域有經驗。對于一般團隊需要一段比較長的學習時間。但是項目的規模，的確是應該依據需求，而不是依據產品來制定的。對于硬件項目，規模就更加復雜了。我們希望有一個簡單的，可以用于大部分項目的規模定義，這就容易管理了。?
我建議用產品需求來制定規模。本來每一條（或是一項）需求的粒度差異很大，使用需求項數量來度量規模很不一致。但我們可以利用一個簡單的原理：如果粒度越小，需求項數量越多，差異就越小，就越可以代表項目規模。問題是，如何細化需求，如何決定細化的標準。我的建議是：每一個需求項，就是一個需要驗證的獨立因素。舉一個例，一個這樣的需求：?
買一張星期三上午9:30前，從上海到南京的頭等×××頭火車票?
就可以有五到八個需求項：- 星期三上午9:30前（是兩、三個因素？）
- 上海到蘇州（是兩個因素？）
- 頭等
- ×××頭
- 火車票
?
雖然需求項的粒度，還不能是絕對一致的，但是差異已經縮小到從統計的角度來說，可以是一致的程度了。這代表著開發產品需求的系統工程師，需要清楚每一個需要測試的因素。系統工程師的角色，本來就要求這個能力。這樣的規模定義，是一個驅動提高需求質量水平的非常有用的理念。?
不同領域或是產品，基于需求項的規模定義，可能是不可比較的。但是同一類產品的項目，是可以比較的。這樣的規模定義，是簡單的。從項目的任務角度看，是理所當然的，是容易判斷與收集的。同時，還會讓系統工程師提高水平，讓測試人員的策劃工作，非常方便。?
工作量?
工作量可以用于幾個不同的目的。一個是反映某些任務的大小，另外一個目的是幫助策劃將來的項目。工作量可以應用在不同的任務，比如會議的工作量，或是編碼、測試等的工作量。會議的工作量比較明確，有多少人，會議進行了多久，就可以算出來會議的工作量。以后也可以用這個數據來策劃將來的會議。但是我們不會想到會議里有些是有意義的發言，有些是風花雪月的閑談（尤其是開始的時候），我們不會把這些時間段分的非常清楚吧。分的這么清楚有意義么？一定不容易，而且意義不大。但是我們編碼的時候，就往往要求只記錄真正編碼的工作量。比如，一天之中，開了一個會，回了一些郵件的時間，要從編碼的時間減除掉。這樣的工作量，聽起來是比較準確，但沒有用。因為將來估算類似的任務的時候，我們還要知道一天的平均會議，回郵件等等的時間。這樣非常麻煩，而且會引進不準確的因素。要解決這個問題，我們需要按照項目管理的原則，制定一個在組織氛圍低下完成任務的工作量。我叫這個定義為“成本工作量”。?
要定義有意義的工作量，項目首先需要按項目管理的原則制定“任務”。任務有很多層次，比如：開發一個模塊是一個任務，主持一個會議也是一個任務。這兩個任務是在不同的層次上面的。開發模塊，是產品的組成部分。會議，可能是完成這個模塊所需的，所以層次比較低。一個項目，最高層次的任務，應該是按產品的構建而制定的，就是說，是跟系統方案是一致的。這樣的任務，才可以代表整個項目的范圍。這個層次的任務，我把它稱為“項目層任務”。會議、評審等等，就不是項目層任務。還是需要策劃，但度量的方法不一樣。有了這個概念，才能定義出有意義的工作量。?
成本工作量，就是一個項目成員完成他的項目任務所需的“在勤時間”。在勤時間，就是他上班的時間。那么，一個項目成員在他開始一個項目任務的時間，到這個任務完成的時間，他的上班時間，就是這個任務的工作量。其中包括會議的，評審自己與他人工作的，回郵件的，甚至上廁所的，自己胡思亂想的時間。如果同時處理多個任務，就要制定原則，把時間分配到各個任務上去。這個定義，工作量的收集不用員工操心，考勤的信息就可以了，是非常簡單的，也是與項目的操作相配合的，收集數據的額外干擾就減到最少了。這個定義不是唯一的。我們可以定義成本工作量為“在職時間”。這就包括了請病假、接收培訓、出差之類的時間。各有好處。大家自己研究一下，自己決定。?
項目的總工作量，就是所有項目層任務的工作量，加上管理與支持的工作量。要監控項目里的各種調控，就需要有比較精確的度量，我們是不能從考勤信息拿到，是需要特別度量的。我稱它為“度量工作量”。比如項目的會議所占的比例，就是所有會議的工作量之和，對比整個項目的成本工作量。那么，我們就需要有精確的會議工作量。這個我們從會議紀要里可以算出來。評審占的比例也是如此。另外一個案例就是返工量。這個不是項目層任務。所以我們要精確地算出來。一個方法就是用變更控制系統。如果變更控制系統是規范的，每一次每一位員工處理變更請求單里的要求所用的實際工作量填上去，那么，返工量就是這些變更控制系統里的工作量之和。?
質量?
真正的質量指標，應該是獨立于項目的，是由項目之外傳遞過來的，例如：現場故障數、故障間隔（MTBF）、客戶滿意度等等。在成熟的團隊，度量真正被利用來管理項目，那么項目過程之中的缺陷數，跟實際的產品質量還是有一定的關系的。?
定義缺陷的時候，需要考慮失效與缺陷的分別。我們通過測試或是現場發現失效。缺陷是產品里面造成失效或是不能滿足需求的原因。我們需要分別他們，是因為每一個失效里，可能有一個或是多個缺陷。所以數量就不同了。在項目里，缺陷的定義可以是基于失效的，也可以是基于缺陷的。最終還是需要能夠建立項目里的質量特征（無論是建立在失效或是缺陷之上），與產品的現場表現關聯起來的。?
與產品質量關聯的項目質量特征，包括兩方面：項目里的缺陷密度與發現缺陷的階段分布。所以質量的指標，在統計缺陷數的同時，也要統計在不同階段的缺陷發現分布。?
所有這些數據，都應該可以在變更控制系統里拿到，它們的收集，還是比較理所當然，不會讓項目受到太大的干擾的。?
第三，知道如何分析，才開始收集。?
要看圖，不能只看表格?
在收集數據之前，需要清楚如何分析收集到的數據，并且如何使用分析的結果。從上面的討論，我們知道要掌握過程效能，就要看一整堆的數據，看它們的中間趨勢，與標準偏差。也要看時間上的趨勢和分布。所有這些，都要通過圖來表達。表格是不能充分表達這些特征的。分析的方法之一，就是要看圖，不能單看表。度量的實際應用，每一個人都照著自己的目標來制定度量的需要，在實踐中積累度量的經驗，提高度量的能力。?
不用過程數據評價個人?
有一件事，再要強調一下。過程數據不要用來評價個人。除了會破壞度量體系，歪曲過程之外，也會造成不同領域之間的壁壘，妨礙團隊的共同目標。從另一個方面看，我們提到，項目有一個最小的因素集，并且要監控集里的所有因素，否則我們得不到最佳的平衡。對項目來說，集里有三個因素。在個人方面，這個集里的因素就多的要命。技能、態度、性格、喜愛、溝通、人緣、等等，每一個都對員工在項目的價值又非常重要的影響。這個也是為什么不應把過程數據用于評價個人的原因之一，因為我們永遠都不清楚這樣做的效應是否正確，是否有利。轉載于:https://blog.51cto.com/mk6yeung/103433
總結
- 上一篇： MySQL基础篇(01)：经典实用查询案
- 下一篇： 关于解决service 'sapdp00