研發基本能力 <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.

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

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