上一篇｜PM 小筆記｜混搭搭出新滋味─用Hybrid管控開發專案中，稍微簡單的介紹了一下Hybrid是什麼；接下來將以我們曾開發過的某傳產集團績效評核系統為例。
先簡單介紹一下系統需求的背景：
從使用者的面向來說，這個系統的使用者包含了：集團各子公司負責人以及各子公司內部員工、人資等。
在審核流程上，集團針對各子公司的負責人有一套績效審核流程，同時各子公司內部員工的目標績效評核也有一套審核流程。不過兩者間大流程還是一致的，都是：年初時在系統Key in年度目標→年中進度回饋→年末成果評核。
乍看之下好像不是太複雜的系統需求，但其實子公司負責人的考核規則跟各子公司內部員工的考核規則又各自有不同的小岔路(在同中求各式各樣的異XD)，再加上在開發這個系統之前，集團的考核是以「手動」Key in Excel的方式進行審核，「手動」這個行為，就可以有各種小後門進行調整(一些讓績效可以比較好看的小後門之類的XD)，為了要盡量讓系統能夠應對各種情境的變動的狀態，讓專案的細節內充斥著許多的不確定性。
因為該集團的潛規則(?)是訂定的系統上線時間不可以變動(不管上了什麼功能，系統一定要如期上線的概念XD)，所以在專案的最開始，拿到客戶的RFP(Request for Proposal)、對專案的大框架進行了初步的分析與了解後，依據專案的需求，先拉出大的時程規劃。
接著考量使用者很有可能在看到開發成果後覺得哪邊不夠或是哪邊不是他想要的，為了避免在開發完成後，再冒出一堆CR(Change Request→很多時候使用者都不會覺得CR是CR，而覺得那就是Bug…然後，就需要花很多時間跟客戶重新釐清與討論CR、Bug的項目…)，所以決定在專案時程的大框架內，將功能分批次產出，每批都會有：開發、內部測試、使用者測試、調整等的流程。
於是產生出類似下方這種大框架以Waterfall式的規劃、在開發上使用Agile進行的專案管理模式。
在使用者進行測試與確認後，通常使用者會提出想調整的項目；因為有些時候系統的商業邏輯盤根錯節，想調整的項目可能會與後面的開發項目有關(連動影響)，此時即可將使用者想調整的內容與後面尚未開發的功能一起做double check，確保後面開發的功能，能更符合使用者的想像與需求。
在這個績效評核系統開發的案子裡，就有過幾次使用者在看過產出的功能後，針對後面尚未開發的項目進行了需求調整；倘若是以Waterfall的方式全部開發完成後才交付使用者測試，在系統大局底定的情況下，能夠協助調整的幅度就已經不大了。
不過針對尚未開發的需求項目要進行變更與調整，也是需要進行評估、溝通，畢竟在考量預算時間等等的情況下，並不能讓使用的需求進行無限發想(畢竟我們也不是許願池XD)；要如何拿捏協助調整的幅度與內容，就又是另外一個故事了。
