在現今的 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.
需求管理是人與人之間的溝通過程（軟性知識），需求清單與雙向追溯機制只是幫忙判斷與釐清需求是否被滿足的工具（硬性知識），因此，需求管理應側重於溝通的有效性，怎樣才是最有效果又能跟客戶達成共識的溝通方式反而是比較重要的，關於這點我推薦各位讀者可以學習卡內基的溝通訓練課程，相信一定會對各位有所助益。
但需求清單與雙向追溯機制等硬性知識又要怎樣做才洽當呢？ ...待續
沒有留言:
張貼留言