『系統開發有標準開發流程好不好？重不重要？』
你問這個問題，100個人有99個人會跟你說重要，不過通常他們後面會接著：『可是....』，接著就開始跟你說哪個部分的流程可以跳過，哪個部分可以少做一點，最重要的還是準時把東西交出來，有問題再說吧，我想很多人對 CMMI都有基本認識，CMMI最重要的就是訂定一個Process Model，依循這個Process Model，產出符合預期的內容，接著做量化管理，可預測產出，進行流程最佳化，這大概就是CMMI一層層上來的概要標的了。
『系統開發有標準開發流程好不好？重不重要？』
你問這個問題，100個人有99個人會跟你說重要，不過通常他們後面會接著：『可是....』，接著就開始跟你說哪個部分的流程可以跳過，哪個部分可以少做一點，最重要的還是準時把東西交出來，有問題再說吧，我想很多人對CMMI都有基本認識，CMMI最重要的就是訂定一個Process Model，依循這個Process Model，產出符合預期的內容，接著做量化管理，可預測產出，進行流程最佳化，這大概就是CMMI一層層上來的概要標的了。
推動CMMI最困難的地方或許不在於他的流程複雜、工作產品與文件要求多，常常在於我們對他有先入為主的觀念，我不需要走這些流程，因為我有：
1.厲害的開發人員
2.先進的技術
3.非常有經驗的PM
這些都是做好專案的基礎，有好的球員，還是要有教練做訓練與安排戰術才能贏的了冠軍，開發系統也一樣，有很強的團隊，如果缺乏了制度與方向，那一切都是白搭。
也有人認為流程代表著以下負面印象：
1.依循特定流程會干擾創造力
2.流程是一種官僚的作法
3.只能用在大案子
4.影響開發進度
5.花費較多的成本
你開發系統有用到哪些流程？我們在維護產品時，一定會做建構管理(Configuration Management, CM)，包含Source control、Version Control、Baseline等，也會做Issue Tracking，另外在系統發展實也知道要做需求收集、SA、SD，然後進入Coding跟Testing，好一點的可能還會搭配Daily building，版更有版更的標準流程、測試也有測試的流程，這些都是在整個開發週期中需要被重視與留意的，回過頭來，我們必須反思，為何當初這些流程會被發展與應用到我們日常工作中？
你說：『因為有缺失與需要改善。』
對，會有這些流程，一定是因為過去我們有些東西沒做好，所以後來我們將這定為一個SOP，要大家遵守這個SOP來行事，但這個SOP就像查檢表(Checklist)一樣，可以讓我們依循標準動作做好工作，但對既有的流程並不會有所改善，今天我們發現我們流程中有個缺失，導致更版的內容不完全，那我們一定要修改我們的SOP，讓這個缺失不再出現，但很多時候為了方便起見，就會出現人工/手動補起這個缺失的現象，導致這樣的流程問題在後續持續發生，這是什麼狀況？
你說：『趕時間嘛，而且這是因為負責更版的人不小心才會這樣，標準流程不會這樣啊。』
對，這個不小心就是我們要避免的，如果人工會出錯，那就要修改我們的流程，改成自動化，透過工具來處理，某種程度上，工具比人可靠，不是說人不聰明，但人會因為情緒(跟老闆吵架)、精神狀況(昨晚沒睡飽)、自作聰明(兩步併一步)等原因，導致流程執行的不完全，但工具不會有這種問題，需要知識投入的部分交給人，重複性、可自動化的工作交給工具，我們的開發流程才會順暢。
這篇文就是沒有依循SOP所產生的結果：[產品開發]能相信的只有測試過的程式
這也是我剛進公司時，還不太懂產品開發時所犯的錯誤，我們正式的版更區有一個版本，但流落在外的孤兒版卻有N個，當我想告知對方說換到哪個版本就可以解決問題時，我很難跟他說明他手上的版本跟版更區的版差別在哪邊，版更後可不可以解決他的問題，我只能跟他說：『換到最新版本試看看吧。』，這樣的try-error免不了會浪費大家很多時間與精力，只能說是怨聲四起啊，另外那些孤兒版本也造成一些問題，那就是它沒有經過標準測試流程就出去了，因此會有測試不確實的狀況，當時經驗又不足，常出現改A錯B的問題，系統不穩定的傳言就這樣爆開了，始作俑者的我們，也只好接受了。這個案例中，開發人員經驗不足固然是一個原因，但其實若有依循標準的流程，問題就會減少很多。
對開發人員來說
你有做使用案例(Use Case)嗎？如果沒有，那你怎麼測試你的系統呢？如果你有測試，那你如何確保這個結果符合客戶期望呢？
導入CMMI跟一般的流程開發最大的不同在於，會有一組人定期來稽核你的流程與工作產品，過去如果沒有使用案例，你可能可以說我用需求文件來替代，但導入CMMI後，如果使用案例是一項很重要的交付產出，那你沒有，就要請你補了，而這個程序相信就是有經驗的開發人員最反彈的，因為會有一堆負面想法，如：『煩死了，以前只要有需求文件就可以，現在還要畫使用案例。』、『這群人憑什麼來稽核我做對或做錯，我過去都這樣做的。』、『這文件寫出來給誰看啊？』。
改變工作流程，引來反彈是一定免不了的，但我們也該靜下心好好想想，如果流程真的沒有問題，卻被說要修改，那我們的建議是什麼？如果流程真有問題，而這個改變可以讓我們更好，何不修改？情緒都是一時的，但能夠改善工作流程是最重要的。
對老闆/業務來說
或許是以賺錢為第一考量的關係，因此這兩個職能是最常來破壞既有流程的人員(有錯請指正)，也可能是一項很大的誤解，總以為時程永遠是最重要的，因此什麼SOP，能刪減到最少就刪到最少，系統寫得出來，會動最重要，有Bug就再修吧。
在專案中，我們可能還看不出一味追求時程而忽略品質的可怕，這邊我想以產品的角度來說更能凸顯這個問題，你在專案中寫出的一個Bug，會影響這家客戶，也會影響你後續修復Bug所花的成本，而產品呢？對應的可能是500家客戶，你要幫這500個客戶處理這個問題，讓服務人員必須要執行500次相同的動作，而過程中還有可能被客戶客訴，不可不慎啊。
開發流程對系統開發絕對是重要的，而CMMI也不是毒蛇猛獸，套句我們CMMI推動小組常講的：『沒有缺失，何必怕別人稽核呢？』。
 |
游舒帆 (gipi) 探索原力Co-founder，曾任TutorABC協理與鼎新電腦總監，並曾獲選兩屆微軟最有價值專家 ( MVP )，離開職場後創辦探索原力，致力於協助青少年培養面對未來的能力。認為教育與組織育才其實息息相關，都是在為未來儲備能量，2018年起成立為期一年的專題課程《職涯躍升的關鍵24堂課》，為培養台灣未來的領袖而努力。 |
