PMP沒講的是...

PM Open Day 活動的啟發－『需求掌控』與『制度建立』
 

 
『PM Open Day』第一期活動即將圓滿結束，六堂豐富的課程，邀請各界資深前輩們來分享他們的實務經驗，包括：第一場次  CIM英國皇家特許行銷高階證照講師楊清貴的【品牌國際行銷與媒體公關-歐洲區品牌行銷專案】、第二場次 程曦資訊(股)客戶二部經理周慶源的【電腦電話整合系統專案實務分享】、第三場次 EMC Computer System Project Manager謝麗菁的【資訊架構規劃顧問案經驗分享】、第四場次 某證券公司電子商務部經理的【專案執行如前線作戰】、第五場次 某上市公司高階主管的【有截止期限嗎?OA系統認證CMMI ML3專案經驗分享】、以及第六場次 英特爾亞太區軟體開發暨策略聯盟部協理胡恆泰的【PM is the best job! & Career Suggestion】。在此由衷感謝每位主講人的不吝分享。

我對其中二位前輩的分享印象特別深刻，其一是第二場次的周慶源經理，其二是第五場次的鄭特助，他們二位都不約而同地提到了，做專案對『需求掌控』的重要，以及『制度建立』的觀念。

『收集需求』，從如何驗證開始

『需求』是應用軟體開發的起源，既然所開發的是一套應用軟體，那表示未來這要是一套能應用於使用者環境的軟體，而需求收集的好壞也就決定了這最終產品能否為顧客所接受的關鍵。

但『需求收集』這個動作能做得好的人其實不多。大部分收集顧客需求的人，對顧客所屬業務領域的知識極為貧乏，能否聽懂顧客需求就已經是個問題，又常自以為聽懂了顧客需求。在產品驗收的那天，被退貨也就是預料之中。

我們常教成員，去訪談顧客需求之前，自己要先用功，要去熟讀顧客所屬業務領域的知識，要知道顧客那行的行話。對於收集到的顧客需求，在一開始就要想到未來要如何驗證、如何測量；對於收集到的顧客需求，要能轉化為可客觀衡量的描述，那才表示你真的了解了顧客需求。

去收集好需求、真正的需求，能掌握好需求、真正的需求，才能開發出好的應用軟體！

『創造需求』，更能掌控需求

什麼是『好』需求、真正的需求？

做了十幾年應用軟體開發專案的心得是，要能把顧客既有需求實踐出來，並不困難，只要去對顧客所屬的行業別、功能領域、工作內容去用功了解，要產出一個符合現有需求的應用軟體，並非做不到的事。

但若能創造顧客的（未來）需求，那將更能掌控專案需求的發展！也就是說，需求是可以被創造的！就像世界在還沒有出現手機之前，人類並未對手機產生需要，但發明手機的人，日後卻主導了人類對接收資訊、傳遞資訊的需求發展。

所以，若你正在做一個為期二年的OA系統專案，那恐怕你要規劃的不是一個現行辦公室作業流程自動化的應用軟體而已，而是規劃一個二年後的創新辦公室作業流程。一旦你能創造顧客的（未來）需求，那就更能掌控顧客的需求發展、更能管理專案需求，而不只是被顧客牽著走。

『創造需求』，你便能驅動顧客、更能掌控專案需求的發展！

『建立制度』，能協助組織躍升

再講到『制度建立』這個議題。

你信仰『制度』嗎？對於組織來說，當其發展到一定程度時，人力資源也必須相對擴充，以因應業務拓展上的需要。而人變多了，績效不保證會變好，但保證的是，組織的溝通變得更複雜了。此時，組織必須藉由制度化的運作，來帶領組織突破現況，跳躍到另一個層次。周慶源經理提到，他們公司曾經擴充到一個規模，但因為無法順利建立一套制度，於是他們失敗了，公司又退回了原來的層級。當他們再次嚐試，終於他們建立了制度，也使公司順利地提升，跳躍到了另一個層次，進入下一個成長階段。

CMMI是軟體開發能力成熟模式之認證，任何對自己有更高期許的軟體開發公司或軟體開發單位，均自我要求導入CMMI，並取得認證，這是一個組織成熟度的表現。藉由導入CMMI，建立組織的軟體開發流程，讓軟體開發作業流程產出有一定的品質。就以『收集需求』流程來說，許多軟體人員對於需求收集作業的自我要求太低，常自以為已了解了顧客需要，而結局是開發出的軟體無法適用，導致專案驗收失敗。導入制度後，藉由一定的程序，使得需求收集作業有了更縝密的檢視，而透過這樣的檢視，能讓需求提出人與需求收集者都更為正視需求，達到收集需求作業的好品質。

我信仰制度。藉由一定的流程步驟，至少，得以確保通過這樣流程步驟所產出的軟體為可用的；至少，得以有效降低因人員素質差異，而造成產出品質的極度不穩定。當組織大到一定程度時，『制度化』能讓組織溝通運作較為協調、能讓作業品質有一致水準、能降低人為失誤對組織造成的衝擊傷害，建立組織制度係有其必要性。

　
　　
『創新制度』，更能展現制度的價值

導入CMMI，讓軟體開發不再只是個手工藝，不再只能依賴師父功力的好壞；導入CMMI，讓初入門的小徒弟，也能開發出一個有基本品質水準的軟體。既然有這麼多的好處，那又為什麼組織在實行CMMI一陣子後，卻對是否要繼續挑戰下一個更高等級的CMMI猶豫了？組織中優秀頂尖的人才又為什麼在此時，卻選擇了離開這個有制度的環境？

問題不在CMMI。不論是ISO或CMMI，它們規範的都只是What? 而不是How? 組織要建立一個什麼樣的軟體開發流程，CMMI並未干涉。若所建立的制度，只是一個既有作業的流程化與文件化，那成員們會失去繼續挑戰更高等級CMMI的熱情（還要繼續做更多的文件？）；頂尖優秀的人才也因為那文件化的流程，限制了他們的作事方式，當他們已經有了更好的工法、工序，但制度卻不予許他們這樣做，於是頂尖優秀人才失去了想繼續留在這個組織的熱情。

一個為期三年的CMMI導入專案，若在規劃的當下不是做開創的動作、不是去發想一個三年後的創新軟件開發流程，而只是把現有作業流程化與文件化，那只是舊瓶新裝。三年後，專案完成的那天、取得CMMI認證的那天，所建立的也只是一個舊制度，且往後數年還得繼續運作這套制度。

建立制度的『真實』需求是 － 展現制度的價值

現行（或過去）的軟件開發流程也不是不好，但產業的進步不就是在工法、工序上的進步嗎？品管界的進步，在於不斷地省思品管問題、不斷提出新的品管方法。製造業的進步，也是不斷在製程上的創新突破，讓生產效能得以大幅提升。而數十年前的『軟體開發生命週期法（SDLC）』還適用於現在的世界嗎？一個數十年前的方法論，至今仍為該產業所採用，是因為該方法論太經典、無可取代；還是該產業不思進步、原地踏步？

導入CMMI或建立任何制度的『好』需求、真正的需求是什麼？是把既有作業流程化、文件化，以取得CMMI認證；還是去研究、開創一個創新的應用軟件開發流程，以展現制度的價值。頂尖優秀的人才們，能否將自己腦袋中的好東西記錄下來，讓一般人也能應用你們的好方法；制度建立者，能否邀集組織中頂尖優秀的人才們一同共事，聽聽他們的聲音，他們可能比你花大錢請來的外部顧問更了解你們的組織適合的是一個什麼樣的流程，他們有能力創造出一個更好、更有競爭力的應用軟體開發流程，使組織導入CMMI的價值終獲展現。