說到過程能力基線，了解cmm/cmmi的人都不會陌生。一般是指組織的過程能力基線，通過數字反映了組織的能力。比如乙個組織的生產率是每人月生產**行2000行。當然現在一般用功能點來計生產率，比如每人月平均生產8.5個功能點，西格瑪是多少。
但是如果在專案一級上提出專案的過程能力，就讓我犯難了。當前的思路是從專案的大目標來分解。
專案的大目標一般有一按期發布，二缺陷要少。
從 工期上而言，有不少組織採用掙值管理的，完成可以採用掙值中的cpi和spi來管理，這樣不僅管理了工期，成本也得到了管理。但是我所在組織沒有採用掙值 管理。只有工期偏差。每階段都有實際的工期偏差，每週的工期偏差是當時的預計值。雖然沒有掙值更為準確，但足以為專案提供支援。這樣利用每週和每階段的工 期偏差可以生成專案工期偏差的過程能力。
從缺陷上而言，我當前還沒有想到合適的辦法。由於每階段的工作產品不一樣，每個工作產品的規模度量也不一樣，比如開發計畫書是按頁數的。需求分析是按功能點數量的。這樣想來，每個階段都有的度量只有工作量是合適的。同行評審缺限數量與工作量的比值是每個階段都可比的嗎？
這好象很有疑問。誰能告訴我，如何在專案中就缺陷控制生成控制圖？
---------
在cmmi5過程改進中，baseline和baseline model是兩道很難逾越的「坎」。
缺陷控制圖是baseline和baseline control的方法之一。其中的難點還在於組織級是否已建立缺陷的baseline（包括質量區間）。我想我們遇到的難點是，如何識別工作產品，並建立缺陷分類，以建立基線。
一般來講，我們可以從cmmi v1.2 專案5個階段著手，從開發中、交付前和交付後，對「評審發現的缺陷」、「測試發現的缺陷」和「系統執行中的缺陷」進行分類管理，其中「評審發現的缺陷」主要是「業務解決方案」、「技術解決方案」、「**」等中間產品。
同時，缺陷密度一般是缺陷數量和專案規模的比值較為合理。按照第二代fpa（function point anaylis）方法，我們可以忽略「缺陷的顆粒度」干擾因素（據說經過資料統計，顆粒度綜合印象係數分布在1附近），用fpa方法統計專案規模，從而得 到無主觀因素干擾的「缺陷密度」。
上面 carl 回答了一些，我這裡補充一些。
process performance baseline 和 process performance model 是兩個很重要的過程改進的標誌。
process performance baseline 可以理解為 過程在某個方面的 benchmark，是以後專案用來參考和對照的，它是乙個範圍值，在低成熟度級別的（如ml2 和 ml3）專案管理中，我們經常用的 threshold （閾值）跟這個意思類似，但是threshold 更多的依賴於專案經理和成員的經驗，是比較 主觀的；但是process performance baseline 是個比較客觀的值，它是需要一定量的 相同性質的（homogeneous）資料通過統計方法得到的。這個值的得到需要時間（也就間接告訴我們 達到 4級 是需要時間的），也就是需要不少類似專案資料支援，從而提高了過程的客觀性和透明度（資料管理），也提高了專案管理能力，所以這個概念是在 四級（不論是 ml還是 cl）中提出，這也才真正體現「過程控制」的概念，如果把 ml2和 3 認為只是工程概念。
對於 缺陷來講，我建議首先 分專案型別，目的是取樣資料時能夠滿足資料的要求之一（homogeneous），然後 建立 phase containment，對各種缺陷資料進行再分類，同時主要 缺陷引入（injection）和消除（removal）概念，這些資料在識別過程問題和提高過程能力方面很重要，（car和四級都要求剔除 過程中的問題，不同的在於common cause 和 special cause，）；然後根據各個專案不同工作產品的規模（如 頁數、fps、模組數、測試用例數等）進行 normalize，就可以得到該項目的不同產品缺陷律，這樣與同類可以比較，資料多了，也可以考慮建立 baseline。一般的方法是資料少時就用平均法，多了就要用一些專業的control chart 來描述，對軟體來講，這個 baseline 永遠是相對客觀的，因為你總在不停的改正你的過程，原因是你的專案不會等你的過程穩定了才去調整你的過程，別忘了過程改進的目的是為了專案管理，是為了達 到乙個 的核心目的 － control，這個就是所有管理的終極目標。
乙個公司對 同乙個過程的 baseline 可以有多個，別忘了 裁剪在這裡仍然是適合的，因為這個的情況的根本（common cause）是背後不同的專案型別決定了這個資料。
只是薄見而已。
process performance baseline（ppb） 和 process performance model（ppm） 是兩個很重要的過程改進的標誌。
process performance baseline 可以理解為 過程在某個方面的 benchmark，是以後專案用來參考和對照的，它是乙個範圍值，在低成熟度級別的（如ml2 和 ml3）專案管理中，我們經常用的 threshold （閾值）跟這個意思類似，但是threshold 更多的依賴於專案經理和成員的經驗，是比較 主觀的；但是process performance baseline 是個比較客觀的值，它是需要一定量的 相同性質的（homogeneous）資料通過統計方法得到的。這個值的得到需要時間（也就間接告訴我們 達到 4級 是需要時間的），也就是需要不少類似專案資料支援，從而提高了過程的客觀性和透明度（資料管理），也提高了專案管理能力，所以這個概念是在 四級（不論是 ml還是 cl）中提出，這也才真正體現「過程控制」的概念，如果把 ml2和 3 認為只是工程概念。
對於各種ppb，它的建立過程類似，都是要進行資料收集、分類（這個非常關鍵，按專案型別是主要的乙個分類）和處理，這個可以參考ma 中的sps。
對於 缺陷來講，我建議首先 分專案型別，目的是取樣資料時能夠滿足資料的要求之一（homogeneous），然後 建立 phase containment，對各種缺陷資料進行再分類，同時主要 缺陷引入（injection）和消除（removal）概念，這些資料在識別過程問題和提高過程能力方面很重要，（car和四級都要求剔除 過程中的問題，不同的在於common cause 和 special cause，）；然後根據各個專案不同工作產品的規模（如 頁數、fps、模組數、測試用例數等）進行 normalize，就可以得到該項目的不同產品缺陷律，這樣與同類可以比較，資料多了，也可以考慮建立 baseline。一般的方法是資料少時就用平均法，多了就要用一些專業的control chart 來描述，對軟體來講，這個 baseline 永遠是相對客觀的，因為你總在不停的改正你的過程，原因是你的專案不會等你的過程穩定了才去調整你的過程，別忘了過程改進的目的是為了專案管理，是為了達 到乙個 的核心目的 － control，這個就是所有管理的終極目標。
乙個公司對 同乙個過程的 baseline 可以有多個，別忘了 裁剪在這裡仍然是適合的，因為這個的情況的根本（common cause）是背後不同的專案型別決定了這個資料。
專案管理的幾個過程
一.商務談判 1.作人的姿態 作人似乎跟商務談判不太有關係，很多技術人員相信pm需要的是本事，是如何做好乙個專案，而不是會搞好關係弄的四平八穩的人。隨著pm在中國的悄悄興起，越來越多的pm開始在老總的授意下參與商務談判，和銷售們一起打單子，這就比較實在的需要pm們去揣摩客戶的心理。揣摩客戶心理需要有...
IT專案管理 幾個基本概念的討論
本篇主要討論projects 專案 programs 專案集 portfolio 專案組合 三者間的關係和其對企業的貢獻，以及operations 運營 與opm 組織級專案管理 的關係。一 專案 專案集 專案組合三者間的關係和其對企業的貢獻 從定義上，projects 專案 指為創造獨特的產品 服...
關於專案進度風險控制的討論
原問題摘錄 北京心靈方舟科技發展 專案經理 王奎 2小時前 有個關於專案進度控制的問題請教大家 在專案實施過程中有部分功能實現需要有人去研究學習才能解決，如果不研究學習可能解決方案就比較差，但是這個學習的時間可能不太確定，或者在學習的過程中發現比預想的要複雜的多，這個如何做進度控制？如何控制這個不確...