是否該導入 CMMI？

上回的觀點中，筆者簡單說明了自己對於CMMI的認知，同時也為剛剛入門的朋友簡介了一下CMMI (能力成熟度模型) 的四大流程領域與能力成熟度觀點。

這回我們將觸及朋友們經常提出的第一個問題，是否該導入 CMMI？導入 CMMI 真的也那麼大的好處？換句話說就是投資報酬率的問題？

如果回答這問題的是CMMI輔導顧問，那麼多數顧問將引用許多的數據告訴你CMMI是多麼地好，能降低公司經營成本、改善公司體質…等等。真的可以單純地相信顧問們提出的數據？如果是降，為什麼通過 CMMI 三級認證的公司，做出來的ＸＸ系統還是會不斷遭受客戶質疑！系統的壓力耐受度是如此地脆弱嗎？

除了從顧問們提供給的數據看到佐證外，我必須誠實地回答各位，CMMI 的精神是好的，不論從品質、成本、專案與風險管理的角度去看，他都有存在的價值與效益；但CMMI 是否能產生實質效益卻是事在「人為」，參與者用怎樣的心態去面對，絕對影響整件事情的發展，沽名釣譽者可以通過認證，苦幹實幹者也可以通過認證，但時間絕對會證明一切，剛剛說的ＸＸ售票系統不就是最佳的反例？

看到這現象，筆者體會到「哀矜勿喜」的真正意涵，台灣的軟體產業真的如此不堪一擊？我們必須停下腳步，不要一味地說是大環境不好或者CMMI制度不適用於台灣的環境，因此抹殺前人的功勞！取而代之的應該是徹底檢討，到底問題出在什麼地方？我們在這個過程中學習到什麼？
反省、檢討、改善並獲得所謂的Lessons Learned，不就是 CMMI 當中決策分析與解決方案(DAR: Decision Analysis and Resolution)反饋回流程管理領域 (Processes Management－組織流程焦點、組織流程定義、組織層級教育訓練…等)過程嗎？

懂得檢討才能累積經驗(Lessons Learned)並達到持續改善的真諦。

因此筆者認為各位應該關注的議題不是導入 CMMI 與否，或者一味地抗拒 CMMI，真正要提出的問題應該是：

1. 組織/公司目前碰到了怎樣的難題？
是控制不易、溝通不良、品質不佳、無法累積實力…什麼問題最嚴重？什麼問題做最急迫？輕重緩急？

2. 公司的現況、遠景？
有無實際可行的計畫與支持團隊？打算腳踏實地、突破創新還是繼續沽名釣譽？

以上問題雖然嚴肅，但卻是真正值得深思的，有些朋友會告訴我，這些是公司老闆們應該顧慮的問題，不是我這種層級該管的，我了解不在其位不謀其政的想法，但是，山不轉路轉…，或許你可以轉寄一些資料給上司、同事，不論你是否考慮導入 CMMI，我都希望這篇文章能讓大家凝聚共識；大家逐步達成共識，就是進步～

各位朋友們，無論將來職場如何發展，自己也可以累積一套Lessons Learned，反省、學習、累積與成長是進步的動力，如果能進而分享將可得到更多回饋。

CMMI 觀念 & 流程領域

看到很多人在討論 CMMI , 我認為是喜憂參半的狀況, 喜的是越來越多人重視公司內部的能力成熟度培養, 但也擔心良好的制度會被曲解成只有大型專案適用或者制度無效...的論述.

我要說明的是

1. CMMI 本身並不是一套標準作業流程, RUP 才是流程定義, 然而 CMMI 主要是定義流程應該達成的目標 (Goals), 因此, 公司內部可以定義自己的一套流程, 也可以採用類似 RUP 的規範, 但重點是 流程是適合貴公司的, 而且流程可以達到某些 Goals. 這就是為什麼我會建議引進 CMMI 的公司能夠先掌握公司的組織的目標, 並定義出一套能夠滿足組織目標並能夠落實的流程. 不要為了 CMMI 而 CMMI

2. 小型專案也適用 CMMI, 但流程絕對不跟大型專案相同, 這就是 CMMI 裡頭談到的調適原則 (Tailoring Guide), 會說小型專案不適用的人, 大多數的情況是公司沒有一套所謂的調適原則, 我就見過三個人的專案也採用 CMMI 的規範, 文件不多, 但一樣可以滿足 CMMI 的 Goals , 舉例來說: 用 CVS 管控專案 -> 滿足 Configuration Management, 用 Use Case -> Analysis Model -> Design Model -> Code -> 滿足 Requirement Management, 用 MS-Project 追蹤與報告專案進度 -> 滿足 PP, PMC ... 其實制度是看人如何用它, 掌握制度的精隨不要以偏概全是比較重要的. ISO 也是好的規範, 只是被濫用了

對筆者來說，CMMI 就像是一本字典或者說是SI產業的百科全書，這書裡充滿了可活用的資訊，分別從工程流程、後勤支援、專案管理、流程管理等四大流程領域闡述其內涵，四大流程領域涵蓋的內容如下：

1. 工程流程領域 (Engineering Processes)，包括了需求管理、需求發展、技術解決方案、產品整合、驗證(Verification)、確認(Validation) 等；對筆者而言工程流程領域就是系統整合或軟體發展公司的價值鏈，如同一間工廠從接單、生產、品管、出貨、收款的過程，算得上是公司的命脈所繫，因此價值鏈必須受到重視，有了良好且穩定的生產作業後，產品品質才會穩定、信譽才能廣佈，之後才能厚實客戶群，從而發展精進，進而提升公司的競爭門檻（這才是能力成熟度的基本意義）。

2. 後勤支援流程 (Supporting Processes)，包括了度量分析、流程與產品品質保證、建構管理、決策分析與解決方案、跨界整合性組織環境、成因分析與解決方案等；後勤支援體系就像作戰一樣，是前線作戰的堅實後盾，這當中包括了情報收集、知識累積與經驗傳承，這些都是組織知識形成的過程。也是中高階領導人應該關注的重點之ㄧ。

3. 專案管理流程 (Project Management Processes)，包括了專案規劃、專案監控、供應商協議管理、風險管理、整合性專案管理、整合性供應商管理、整合性專案團隊、量化專案管理等；整體來看，專案管理流程領域是專案履約過程的整體規劃與管制作業，也是客戶、協力廠商、公司主管及專案團隊的協同合作基礎，履約過程中發生的各種狀況、意見與衝突，都需要妥善地溝通、協調與處置，除了充分履約與達成使命之外，更重要的是團隊成長與經驗分享，這才是專案管理應該滿足的重點。

4. 流程管理領域 (Processes Management)，包括了組織流程焦點、組織流程定義、組織層級教育訓練、組織流程效能、組織創新與落實等；一旦工程流程、後勤支援、專案管理…等落實後，公司便會累積出一些重要的資產，這些資產包括了作業方法、文件樣板、經驗分享與決策過程…，如果這些資產分散各地甚至因人而流失，對公司或者相關同仁而言都是一大損失，因此，我們需要管理這些組織資產，並在這些基礎上不斷改善與創新。

[JAVA] 常用的檢查機制

JAVA 常用的檢查機制
身分證字號,IP,Email,門號,關鍵字過濾等檢查功能

package com.info.website.util;

import java.util.regex.Pattern;
/**
*
* <p>Title: 常用的檢查機制</p>
* <p>Description:身分證字號,IP,Email,門號,關鍵字過濾等檢查功能 </p>
* <p>Copyright: Copyright (c) 2006</p>
* <p>Company:InfoTech Ltd. http://www.info.com.tw</p>
*
* @author Tommy Kao, PMP <tommy@info.com.tw>
* @version 1.0
* @since 2006/07/19
*/
public class Validator {
private static final Pattern ASCII_PATTERN = Pattern
.compile("[\x00-\x7F]*");
public static boolean isPureASCII(String msg) {
boolean result = false;
if (ASCII_PATTERN.matcher(msg).matches()) {
result = true;
}
return result;
}

/**
* IP Address 檢查程式
* @since 2006/07/19
**/
public static boolean isValidIPAddr(String msg) {
boolean result = true;
String []tmp = msg.split(".");
if (tmp.length<=4) {
for (int i = 0; i < tmp.length; i++) {
if (Integer.parseInt(tmp[i]) > 255) {
result = false;
}
}
}
return result;
}

/**
* 手機門號檢查程式
* @since 2006/07/19
**/
public static final Pattern MSISDN_PATTERN = Pattern
.compile("[+-]?\d{10,12}");
public static boolean isValidMSISDN(String msisdn) {
boolean result = false;
if (MSISDN_PATTERN.matcher(msisdn).matches()) {
result = true;
}
return result;
}

public static final Pattern EMAIL_PATTERN = Pattern
.compile("^\w+\.*\w+@(\w+\.){1,5}[a-zA-Z]{2,3}$");
/**
* Email 格式檢查程式
* @since 2006/07/19
**/
public static boolean isValidEmail(String email) {
boolean result = false;
if (EMAIL_PATTERN.matcher(email).matches()) {
result = true;
}
return result;
}

public static final Pattern TWPID_PATTERN = Pattern
.compile("[ABCDEFGHJKLMNPQRSTUVXYWZIO][12]\d{8}");
/**
* 身分證字號檢查程式，身分證字號規則：
* 字母(ABCDEFGHJKLMNPQRSTUVXYWZIO)對應一組數(10~35)，
* 令其十位數為X1，個位數為X2；( 如Ａ：X1=1 , X2=0 )；D表示2~9數字
* Y = X1 + 9*X2 + 8*D1 + 7*D2 + 6*D3 + 5*D4 + 4*D5 + 3*D6 + 2*D7+ 1*D8 + D9
* 如Y能被10整除，則表示該身分證號碼為正確，否則為錯誤。
* 臺北市(A)、臺中市(B)、基隆市(C)、臺南市(D)、高雄市(E)、臺北縣(F)、
* 宜蘭縣(G)、桃園縣(H)、嘉義市(I)、新竹縣(J)、苗栗縣(K)、臺中縣(L)、
* 南投縣(M)、彰化縣(N)、新竹市(O)、雲林縣(P)、嘉義縣(Q)、臺南縣(R)、
* 高雄縣(S)、屏東縣(T)、花蓮縣(U)、臺東縣(V)、金門縣(W)、澎湖縣(X)、
* 陽明山(Y)、連江縣(Z)
* @since 2006/07/19
*/
public static boolean isValidTWPID(String twpid) {
boolean result = false;
String pattern = "ABCDEFGHJKLMNPQRSTUVXYWZIO";
if (TWPID_PATTERN.matcher(twpid.toUpperCase()).matches()) {
int code = pattern.indexOf(twpid.toUpperCase().charAt(0)) + 10;
int sum = 0;
sum = (int) (code / 10) + 9 * (code % 10) + 8 * (twpid.charAt(1) - '0')
+ 7 * (twpid.charAt(2) - '0') + 6 * (twpid.charAt(3) - '0')
+ 5 * (twpid.charAt(4) - '0') + 4 * (twpid.charAt(5) - '0')
+ 3 * (twpid.charAt(6) - '0') + 2 * (twpid.charAt(7) - '0')
+ 1 * (twpid.charAt(8) - '0') + (twpid.charAt(9) - '0');
if ( (sum % 10) == 0) {
result = true;
}
}
return result;
}

public static final Pattern TWBID_PATTERN = Pattern
.compile("^[0-9]{8}$");
/**
* 營利事業統一編號檢查程式
* 可至 http://www.etax.nat.gov.tw/ 查詢營業登記資料
* @since 2006/07/19
*/
public static boolean isValidTWBID(String twbid) {
boolean result = false;
String weight = "12121241";
boolean type2 = false; //第七個數是否為七
if (TWBID_PATTERN.matcher(twbid).matches()) {
int tmp = 0, sum = 0;
for (int i = 0; i < 8; i++) {
tmp = (twbid.charAt(i) - '0') * (weight.charAt(i) - '0');
sum += (int) (tmp / 10) + (tmp % 10); //取出十位數和個位數相加
if (i == 6 && twbid.charAt(i) == '7') {
type2 = true;
}
}
if (type2) {
if ( (sum % 10) == 0 || ( (sum + 1) % 10) == 0) { //如果第七位數為7
result = true;
}
} else {
if ( (sum % 10) == 0) {
result = true;
}
}
}
return result;
}

public static boolean isValidQueryString(String sqlStr) {
if (sqlStr == null || sqlStr.length() <= 0 || sqlStr.indexOf("@") >= 0 ||
sqlStr.indexOf("'") >= 0 || sqlStr.indexOf("_") >= 0 ||
sqlStr.indexOf(""") >= 0 || sqlStr.indexOf("%") >= 0 ||
sqlStr.indexOf("=") >= 0) {
// "關鍵字不可包含 ( @ ' % _ = ) 等字元n";
return false;
}
return true;
}
}

建構管理概念

建構管理 (Configuration Management) 概念

研發基本能力 <4>

怎樣擬定建構管理計畫呢？建議的做法是：
1. 了解需求
2. 進行系統架構規劃並完成一份系統發展計畫
3. 依據系統發展計畫思考並規劃符合本研發專案的建構管理作業方式

假設我們需要研發一套系統，系統本身必須處理客戶訂單、管理庫存與進出貨物，當需求交到研發單位後，我們依照經驗將系統架構切割成進貨管理、庫存管理與銷貨管理三個子系統(進、銷、存)，有了系統架構後，我們便以此資料擬訂建構管理計畫，透過建構計畫說明本研發專案建構管理準則，計畫內容包含：建構管理的目的、工作環境(工具)、人員權責、變更管理流程、建構項目(Configuration Item)、版本基線(Baseline)、建構稽核(Audit)與稽核報告格式等；

建構項目(Configuration Item)指的就是我們打算要管理的項目，例如：需求清單、專案計畫、系統分析文件、系統設計文件、原始程式碼、測試計劃、測試報告、使用者操作手冊…等，在本案例中，我們可以將全系統當作是一個大的建構項目，也可以將進、銷、存分成三個建構項目，甚至再往下繼續分割，分割方式端看怎樣管理比較有效率而定。在此，筆者建議各位，配合系統架構規劃建構項目是比較好的方式，本案例中，筆者為了說明方便把進、銷、存當作三個不同的建構項目來管理研發過程中的所有變動。

產品研發的參考基準就是所謂的基線(Baseline)，基線的概念有點類似拍照留念，基線的用意主要在彰顯產品研發過程的特定工作成果或里程碑，當研發單位完成重大階段性任務如：分析、設計、開發、測試、整合、上線…等，可以利用建構管理的版本管理機制，將各個工作成果統合起來並拉出一條參考基線，所有研發工程師便可以站在基線(巨人)的肩膀上看世界。

本案例的建構管理過程可以參考下圖，研發專案剛開始的時候，主要的工作內容在於收集與確認各項需求，一但需求明確定義後，我們就可以建立需求的參考基線(需求凍結)然後著手進行分析設計工作；分析設計完成並透過審查與追溯機制確認滿足需求後，我們就可以建立另一條基線－Design Baseline，作為後續開發與測試的基礎；完成研發、整合測試後，我們一樣也可以建立 Development Baseline、Test Baseline …；當產品研發完成並確認各項功能與相關文件都備齊後，我們就可以建立Product Baseline，這時不要忘了要大聲歡呼並恭喜老闆喔 ^_^。

還記得前一篇文章當中的變更管理機制？專案受理變更後，專案成員就必須執行變更任務並確認變更成果，結合建構管理的具體實行步驟如下：

1. 確認變更任務的內容，找出要變更的建構項目是哪一個
2. 簽出(Checkout)該建構項目，
簽出的動作就像預約KTV 的包廂一樣，其目的主要是要提醒其他專案成員你正在這一區施工，避免同時施做造成資源浪費。
3. 依照任務內容執行變更並確認變更成果符合需求。(開始唱歌)
4. 變更完成後，將工作成果簽入(Check-in)到建構管理環境中，簽入跟簽出是相對的動作，目的就是告訴其他專案成員你已經離開，簽入後建構管理工具會同時保留新舊版本的工作成果。(包廂空出來了，可以開放給其他人預約)

提醒各位，簽入的動作必須嚴謹，簽入前必須透過審查、檢驗或測試的方法來確認變更任務已經完成，而簽入時必須加入時戳、修改內容註解並維護工作成果之間的追溯性

建構管理不但是研發單位的重大基礎能力，更是公司智慧資產評估的重要工具，因為「凡走過必留下痕跡」將成為研發單位的知識管理基礎，人員可以透過前輩的案例學習、成長；「站在巨人的肩膀上看世界」，配合系統架構擬定的建構項目有更多的機會用在其他專案上，除了重複使用、節省成本的效益外，部分建構項目還可以申請智慧財產權與各項專利，成為公司永續發展的一環喔。

相信各位讀者都聽過「計劃永遠趕不上變化」這句話吧，或許有些讀者看到這句話還會在內心深處發出心有戚戚焉之感！我想這句話突顯的正是變化的事實，為了迎接變化我們需要更有效率的管理機制－建構管理。

衍生思考：
「計劃永遠趕不上變化」這句話突顯的正是變化的事實，但難道因為變化的存在我們就不需要計畫了嗎？關於這點，筆者聽過一位好朋友說過「計畫就是為了要迎接變化」，我個人滿認同這樣的觀點，因為這是認同變化並積極面對的思維，也是身為工程研發單位除了基本能力之外應具備的思維，因此研發一定要有計畫，而且計畫本身應積極迎接變化－與時俱進。

研發基本能力 <3>

在上回的文章中，我們提到了需求管理是研發單位應具備的基本能力之一，這一回我們要聊聊研發單位的另一個重要能力－建構管理(Configuration Management)，建構管理有很多的別稱如：型態管理、組態管理、構型管理、中國大陸稱為「配置管理」…指的都是CM這個作業規範(Discipline)。

簡單來說，建構管理就是產品研發過程的變動管理，也就是系統架構、版本管控加上變更管理(關於變更管理部份請讀者參閱前一篇文章)，確實執行建構管理不但對有助於研發專案的快速進展，加速上市時間，更對公司整體營運有正面的加分效果－尤其是重視智慧資本的２１世紀。筆者認為建構管理對公司的影響是至為深遠的，不但是研發單位的命脈之一，更是公司從A邁入A+ 的重大里程碑，怎麼說呢？請各位看官聽小弟我娓娓道來

先說明一下建構管理跟系統架構之間的關連性吧，各位有沒有吃過歐式自助餐呢？各位有沒有發現，只要稍具規模的歐式自助餐聽都會將取餐區域畫分成：生食區、熟食區、糕點區、飲料區…等，這樣分區的結果不但方便顧客取餐(客戶滿意度)，更讓廚房能精準掌握各餐區的上菜時機與菜色內容(經營成本)，達到顧客與餐廳雙贏(Win-Win)的局面。聰慧的讀者應該已經發現，取餐區的配置其實就是系統規劃，有了系統規劃後，餐廳的經營管理也能提升效率，收到事半功倍的效果喔！在這裡，筆者要提醒各位讀者，取餐區的動線規劃也是系統規劃的重要環節之一，這點請各位下次到歐式自助餐用餐的時候自己留意一下囉。

從產品研發的案例來看，取餐區的劃分就等同於產品分成硬體機構、韌體跟軟體的區隔，其中硬體機構還會再分解成不同的單元，而韌體跟軟體也還會再分解成不同的子系統或是模組，這就是系統規劃的一部份，也是建構管理的重大參考資料，唯有如此我們才能有效的管理研發過程當中的變化。左圖是系統規劃的簡單範例，是不是一目了然且便於管理呢！

給研發主管&經營者的建議：系統規劃的優劣與否將是影響產品研發進程的領先指標，然而系統規劃人員(系統架構師)的養成卻是實務經驗跟時間累積而程的，建議各位可以放些資源在系統規劃人員的養成。

各位讀者應該都寫過履歷表吧！相信大多數讀者在騎驢找馬的時候都會重新檢視自己的履歷並加以更新，通常我們都會複製一份舊的履歷，然後才著手進行更新動作，因此我們會有新舊履歷兩份檔案，有些比較精明的讀者還會在履歷上加上日期甚至註解做為區隔，這樣做的讀者讓我忍不住要讚賞一翻(您真內行)，您知道這樣做，正是在實踐建構管理的精隨之一『版本管控』嗎？有沒有發現因為自己留存著不同版本的履歷，也多了些機會省思現在跟過往的輝煌戰績呢！

回到產品研發的案例去看，新舊版本的履歷就等同於不階段發行的產品，作業系統從 98 升級到 2000 又升級到 2003 是一個明顯的案例，然而改版代表的實質意義又是什麼呢？究竟是系統本身的整體規劃更動(大改版)，還是只有單一子系統的更動(小改版)？要回答這個問題真的很簡單，從個人履歷的例子中讀者就可以猜到十之八九了，只要在每次更動前後加上時間戳記與註解，就可以很快瞭解新舊版本之間的差異，建構管理作業規範也有類似的要求－「凡走過(異動)必留下痕跡(註解)」，能做到這點的人大多都是對自我期許頗高的人，相信各位讀者也是。

注重公司經營的研發單位主管都希望了解建構管理到底對公司會有哪些正面或負面影響？相對地又要投資多少資源？…尤其是有關投資報酬率(ROI)的問題；關於這點我必須清楚答覆各位，就像「信我者得永生」一樣，要發揮建構管理的優勢，首重執行力，能落實制度者，必然能夠得到滿意的報酬，有形的報酬將會反應在產品上市速度(獲利率)、專利與智慧財產權…等，無形的報酬將會反應在團隊的研發能力、知識傳承與產業提昇…等，相對投資則是九牛一毛，請各位主管自行盤算是否有投資的價值。

建構管理的投資 = 伺服器主機 + CM軟體工具 + 教育訓練
建構管理的報酬 = 產品上市速度 + 專利與智慧財產權 + 研發能力提昇
建構管理的 ROI = (執行力 X 建構管理的報酬) / 建構管理的投資

讀到這裡，相信各位對於系統架構(例：餐廳分區)跟版本管控(例：新舊履歷)都具備初步的概念了...待續

研發基本能力 <2>

需求清單、雙向追溯機制與變更請求(Change Request)等基本要素包括 ：

1. 需求清單

需求清單顧名思義就是羅列各項需求的清單，不過除了羅列各項需求外，有一些輔助性的資料包括：需求來源、時間、需求狀態、優先等級、負責人員與變更記錄等，這些輔助性資料在複雜的研發環境當中將更為重要，能讓所有專案成員據焦在清單的工作項目上因而達到事半功倍的效果。

2. 雙向追溯機制

雙向追溯機制最主要的目的就是鑑別專案計畫、工作成果是否能滿足顧客的需求，因此必須管理的項目自然就包括：需求清單、專案計畫(任務清單)、工作成果等各項資料，尤其是資料之間的相關連性－稱之為追溯，有了資料間的追溯性後，我們就能夠的清楚地知道自己執行的任務、工作成果跟哪些需求有關，也可以回答需求滿足度的相關議題，如果運用得當，我們還可以利用這些資料作為評估專案預算與工時…等佐證資訊。

3. 變更請求(Change Request)

需求變更簡稱CR 是專案執行過程中必然會碰到的狀況，變更請求基本上可以分為要求修正除錯錯誤的故障申告、衍生性需求、原始需求改變(需求變更)…等，顧客或專案成員提出變更請求須經過內部的變更管理機制去處理，並將各項變更反映到需求清單、專案計畫
(任務清單)等，這樣的運行模式才能正確反映事實，也為有著種運行模式才具有實質意義。

變更管制委員會(CCB：Change (or Configuration) Control Board) 主要的任務就是從各個面向去評估變更請求的適切性，評估的面向包括：

1)變更請求的內容是否在本專案的範疇內，

2)變更請求的內容是否跟現階段的專案任務有關，

3)評估各項資源、預算與時程的異動程度，

4)評估整體風險與影響範圍，

5)若受理變更請求，則需要調整並分配專案任務給相關的成員

以上說明需求管理的基本概念與作業流程，下次將介紹跟需求管理息息相關的建構管理作業，請
各位讀者給點時間，讓我好好整理腦裡的資料囉，如有疑問歡迎與本人連繫

研發基本能力 <1>

在現今的 IT 產業中，時間是最奢侈的消耗品，為了搶攻市場，系統必須快速完成研發上市，一
切跟品質有關的問題，只要不危及生命財產安全，都可以等到產品上市後再說！這樣的思維並非
錯誤，因為公司的經營本來就是以營利為目標，產品如果沒辦法獲利，公司都經營不下去了，哪
有多餘的資金投入大量人力、物力去維護品質！

公司的經營者當然也清楚，產品上市後，品質終將影響客戶對公司的整體印象，公司形象與客戶
滿意度也會進一步反應在公司的財務報表之上，因此，站在中長期的角度看來，品質與客戶滿意
肯定又是非常重要的，到底是要先顧好品質還是上市時間(Time to market)？這要怎樣評估呢？

除了基本的財務槓桿考量外，筆者建議各位還必須考慮到產品的特性，最重要的還是市場的現況
(Current Status)；如果市場已經有類似的產品，那麼品質與價格必定會站比較大的成份，產品本
身必須在價格與品質上都具有競爭力才可能獲得青睞；如果市場並不存在類似的產品，那麼就需
要從上市時間與技術門檻這兩個角度去思考合理的品質水準，理想的方式就是擬定產品的上市時
間表，然後在有限的時間內進行研發與反覆測試，以期達到能力範圍所及的最佳品質水準。

產品研發就是在有限的時間內達到能力範圍所及的最佳品質，然而，產品研發的過程當中要注意
的事情實在太多，如果沒有妥善的管理對策，品質似乎也變成了中樂透一般的隨機事件，碰到認
真負責的工程師品質自然好，碰到迷糊的工程師就只能祈求老天保佑了(希望自己能被閃電打
中)。

從工程師的角度思考，主管這些日子以來關愛的眼神不斷，一件任務還沒完成，主管又派了新的
工作，只能安慰自己說：『天將降大任於斯人也，必先苦其心志…說著說著又有新的任務來了，
疑，這不是以前做過的系統，怎麼又要搞一套…』，難道這就是工程師的宿命？或許建構管理
(Configuration Management)可以幫各位解決一點疑問。

建構管理是研發單位的重大基礎能力，它本身是一種作業規範，也是公司智慧資產評估的重要工
具，建構管理具備的優點包括：
1. 協同作業與任務追蹤
2. 知識累積與智慧資產
3. 品質管理與變更控制

品質的基本定義就是滿足顧客需求，但需求也有顧客群與輕重緩急的差異，因此品質的等級也會
有所不同，符合特定等級的產品，就是符合特定顧客群需要的產品，因此，產品開發過程當中，
最重要的任務就在於掌握與滿足特定客群的需求。

掌握需求是極具挑戰的任務，這任務通常由行銷或業務人員負責蒐集調查，當客戶需求進到工程研發單位後，如何妥善的管理各項需求，並在時限內研發出一套符合需求的產品，就成為研發工程師的基本工作了。

建構管理規範的作業方法，便是以需求管理作為起點，透過嚴謹的工作規範，有效掌握產品研發過程，到最後研製完成出一套符合需求的產品。

舉例來說，如果我們要辦一場生日宴會，我們會希望知道宴會的目的、邀請的對象、時間、地點、預算…，這就是所謂的需求，因此，我們的產品就這一場宴會，怎樣衡量我們費心籌辦的宴會是否成功呢？通常我們會把列出一張檢核清單，上頭列出所有大大小小需要注意的事項，然後在宴會的籌備過程中不斷的核對清單上頭的所有事項，看看是否有遺漏掉未完成的事情(任務)並加以補強，過程中，經常會有新的需求加到清單上頭，也有些不重要的需求會被忽略，加上經常性地核對清單上的項目，這樣做的目的就是為了要確保宴會成功。

從工程研發的角度思考，需求管理就跟籌辦生日宴會一樣，我們需要一個清單去紀錄各項需求，在研發過程中，也會不斷地檢視各項需求是否已經被滿足，過程中也經常有需求變更的情況發生，這些不都是現實生活中最正常不過的事件？唯有認清需求變動的事實，跟需求變動妥協，才能創造雙贏的局面。

讀者可以利用能力成熟度模型(CMMI)當中的需求管理要點來評估公司是否已具備妥善的需求管理作業規範，需求管理要點(Specific Practice)如下：

SP 1.1 瞭解與收集需求，並就需求的內涵取得共識
Develop an understanding with the requirements providers on the meaning of the requirements.

SP 1.2 取得所有專案成員盡力滿足需求的基本承諾
Obtain commitment to the requirements from the project participants.

SP 1.3 管理專案執行過程中的需求變更
Manage changes to the requirements as they evolve during the project.

SP 1.4 建立需求與工作成果之間的追溯機制（協助了解哪些需求已滿足）Maintain bi-directional tractability among the requirements and the project plans and work products.

SP 1.5 鑑別專案計畫、工作成果與需求之差異Identify inconsistencies between the project plans and work products and the requirements.

需求管理是人與人之間的溝通過程（軟性知識），需求清單與雙向追溯機制只是幫忙判斷與釐清需求是否被滿足的工具（硬性知識），因此，需求管理應側重於溝通的有效性，怎樣才是最有效果又能跟客戶達成共識的溝通方式反而是比較重要的，關於這點我推薦各位讀者可以學習卡內基的溝通訓練課程，相信一定會對各位有所助益。

但需求清單與雙向追溯機制等硬性知識又要怎樣做才洽當呢？ ...待續