林金地 / 效能定律管理顧問
0935-297174、0983-554042
我有一個正在輔導他們CMMI(Capability Maturity Model
- Integrated)的客戶，同時他們正在進行一個軍方的資訊系統開發案。眼看專案進度已經嚴重落後到進入罰款階段，迫在眉睫之際，整個系統都還沒有開發完成，某些專案人員卻在花很多時間撰寫CMMI所需要的階段性文件，並以寫文件來當作系統開發延遲的藉口。這讓我不得不嚴正的提醒老闆及專案成員，應該認知「緊急度與重要度」的交互關係，做到培養輕重緩急的應變能力，先趕快完成客戶急迫需要的系統不要被罰款比較重要，至於未來認證的內部要求文件可以待該緊急專案交付驗收之後再補！
順道一提，能力成熟度整合模型CMMI包括軟體能力成熟度 (SW-CMM) 、系統工程能力成熟度模式 (SE-CMM)、整合產品發展能力成熟度模式 (IPD-CMM)與人力資源管理能力成熟度模式 (P-CMM)等應用模式，由軟體工程學院 (SEI)於2000年12月公佈能力成熟度整合模型，提出對組織的軟體發展25項流程之改良/評量重點之指引，包括專案管理面、流程管理面、工程面、支援面等，CMMI的認證共分為五個等級，第一級L1為初始級、第二級L2為已管理級、第三級L3為已定義級、第四級L4為數量化管理級、第五級L5為最佳化級，其細節在此就不多加詳述。
很多企業因為ISO 的精神強調說、寫、做要一致，所以已經習慣撰寫一些符合ISO條文要求的文件，以為有寫有ISO認證之後就好了！其實有很多中小企業並沒有完全的落實自己所寫的程序書。就像這一個客戶未來想要有CMMI的認證，所以他們也需要不斷的寫又寫文件，花很多時間埋頭苦幹的一直寫，有時候卻減少了同事之間的溝通協調與互動的時間。我很擔心這一個客戶未來要如何有效的運行部門之間的互動，真正落實CMMI的L2與L3，更不要說未來要真正的實現L4與L5的認證要求。
又有一次幫企業員工上課時，有一位員工反應不知道某些應該配合的事項。當時，就有一位員工很理直氣壯的說：「我已經有寫E-mail給你了!」。結果，反應不知道何時應該配合做哪些事的那一位員工，他的辦公座位居然是在寫E-mail員工辦公座位的隔壁！沒有錯，就在隔壁而已，他居然吝於開口告知一下，而寫一個E-mail就算了事，這真是讓我無法理解！難道花幾秒鐘再提醒一下對方有那麼困難嗎？E-mail不是取代溝通協調的工具，更不是當作：「我已經有告知你的證據」！
如上述承接軍方專案的客戶，我介紹敏捷式軟體開發法（Agile software development）給他們，是一種應對快速變化的需求的一種軟體開發能力，強調程式設計師團隊與業務專家之間的緊密協作、面對面的溝通比書面的文件更有效、頻繁交付新的軟體版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重軟體開發中人的作用。敏捷式軟體開發法的方針有如下：
1.
個人與互動重於流程與工具。
2.
可用的軟體重於詳盡的文件。
3.
與客戶合作重於合約協商。
4.
回應變化重於遵循計劃。
以敏捷式軟體開發法的其中之一「Scrum」為例，目前應用的企業包括有Microsoft、
Yahoo、Google、Philips、Nokia、IBM、BBC等，寫出知名企業只是要強調Scrum的重要性，其實它更適合應用於中小企業。
為了改善我這一個客戶將來的新專案不要再重蹈覆轍，我應用Scrum的精神，幫客戶做了如下的變革：
l 將客戶的需求整理成為許多故事(story)，被放在專案產品的待辦目錄(product backlog)中。
l 每一次從待辦目錄中抽出一個小故事，並規劃一個2~4周的衝刺期(Sprint)，衝刺意旨不可以規劃每一個模組太長的開發期間。
l 每一個2~4周衝刺期所完成的小故事(系統)，要能夠清楚的表達每一個小故事的內容，且可以展現出讓客戶看得懂的畫面與欄位，不可以再講一些讓客戶聽不懂術語，更不可以展示出讓客戶看不懂的技術資料。
l 當然不可以告訴客戶：「我們已經完成模組的多少百分比」，這一類的語言對客來說是無法理解的，因為多少百分比未被定義清楚，會被客戶誤會或揣測。
l 每一個2~4周衝刺期都有客戶看得懂的產出，有明顯的專案「短期戰果」，客戶才不會擔心或「癡癡的等」，甚至以為應該沒有問題，沒想到在專案的尾聲才驚覺「原來你們專案人員在前面都是在忽衍與欺騙我…」，客戶會瘋掉。
l 為了每一個2~4周衝刺期都有客戶看得懂的產出，將傳統專案的分工模式如小組成員原來為2~3人，改變成5~10人的衝刺團隊(看專案的大小)。如此可避免原來2~3人的小組，只要有成員離職就無法銜接
l 衝刺團隊中一定要有資深人員，如此可以避免原來小組人員中缺乏資深人員而沒有能力提出關鍵問題或無法適時的提出需要人手的支援。許多資淺的成員悶不吭聲的後果就是注定專案會延遲或重工或做白工的命運。
l 專案經理需要每天早上「站著」開會10~15分鐘，只問3個問題如下：
1.
昨天做什麼？
2.
有沒有問題？
3.
今天做什麼？
專案經理(PM)問清楚並安排支援的人員後，即可散會，無須冗長的談細節。
PM也必須製作進度報表回報給總經理。最重要的是PM必須每一天回報專案面臨到的「真正難題」，讓總經理規劃必要的「外部支援」，專案成員若有無法解決的難題千萬不要悶著頭幹，一定要找「專家解決」，因為軟體公司的老闆一定會有「外部人脈」可以支援解決問題。如此的操作必須重複的練習許多遍，即能快速看到明顯的成效。
