作者／鄭喬挺　管理Muscle Ryan

不知道你有沒有聽過一個經常被使用的Gate或Phase的分階段開發流程，這是一種設計上相對簡單，但效果非常不錯的開發控管方式。讓我們用兩個不同的情境，來比較有Gate Review 跟沒有Gate Review的差異。

情境：替客戶開發到一半的產品只打過兩次樣品，客戶忽然就下單要求盡快交貨。

公司A的應對情況
各部門動起來準備生產的相關事宜，RD把BOM建好、模具課確認治具何時可以開發好配合上線、採購根據建好的BOM開始買料、PE則著手準備相關站別的SOP、生管根據生產流程開始排線並確認交期。

看起來一切都井然有序對不對？但上線後問題到處開花，一下線上缺生產用的包裝袋，一下生產出問題，一查才知道是SOP還沒發行到現場，一下測試用的自動手臂取放物料卡住，無法用自動線生產。這些情境在你的公司中是不是也經常發生呢？

公司B的應對情況
PM招開了Gate Review的準備會議，在會議中與各部門確認BOM的架構是否完整、有沒有缺料，針對生產使用的SOP，也經過生產單位與PE單位共同確認清晰可操作，所有治具也經現場與維護單位驗證。不僅如此，會議中還檢視了生產效率是否達成報價所設定之目標，討論了有沒有尚待解決的議題。

前置作業大略完成後，PM邀請生產、研發、採購、品質部門最高主管共同參與生產前的Gate Review，會議中把治具、SOP、BOM、以及生產效率的統計水準個別做了說明，由生產部門主管仲裁是否可進入生產階段。

Gate Review到底有什麼好處？
比較一下這兩間公司的情境，你應該也能清楚地知道，Gate Review的卡控有什麼優點與好處，是不是可以對專案進程的推展，產生更有效的助益？

主管Review產生一股助推壓力
身為專案管理者的你，是不是常常覺得這些跨部門同事有時候很難搞，開會愛來不來，交的東西又亂七八糟，你很在意的專案，又那麼剛好跟他被迫切關懷的那個不一樣。那你怎麼能不好好利用這個機制，快速推進你的專案呢！

由於Review中各部門主管一定會問很多問題，大家對事前的準備也會比較上心，避免到時候在會議上不小心被釘滿頭包。

跨部門互相檢視，降低作業不良
事前準備另外一項重要因素是，跨部門的合作者都在同一個討論中，如果在會議中A部門睜眼說瞎話，B部門就會跳出來糾正，大家都會各自確認其他部門該提供的服務或產出是否完整且不影響生產作業，最常聽到的就像是：
A：「模具這邊還有點問題沒處理好，會掉屑！」
B：「軟體功能我們驗證起來還有三個Bug要修。」
C：「產線相關的文件還沒到位，文件不來我們生產會有問題唷！」
大家會在一種「我要趕快確認其他部門有沒有欠我東西，免得我這邊被影響」的氛圍中「非常融洽」地討論，最後以互相督促的狀態把該交出來的功課都完成。

系統化管理
有了Gate Review這樣的管理活動，更能夠確保下一階段的運作能夠順暢，為什麼呢？最主要的原因是制度跟流程恰到好處地結合。從流程面說起，下一階段開始前，先審查前階段的產出是否符合標準來決定是否往下邁進，最大的好處就是在開發中，可以透過階段審查來決定是否繼續投入經費、繼續開發，如果遇到產品難產或其他狀況就可以停止開發，將資源投入到其他專案。也因此，在制度面上透過Gate Review的設計，可產生以下幾種效果：

Gate Review應該怎麼運作？
說明了Gate Review的好處後，來談談實務上怎麼運作吧！其實概念非常簡單，只要注意三大重點，就可以確保大家不會浪費時間，卻沒得到該有的效益。

階段成果要審查些什麼？
既然要以某種形式確認是否往下投入專案，想必要先約定到底以什麼標準來通過，簡單來說，做做表面的話就是審查ISO文件等相關表單，落實一點的指標則有很多形式，例如：
●功能
●客戶採用
●產品是否獲得特定群族的好評
●階段品質標準，如：滿意度、良率
●成本標準，如：報價成本、開案設定工時等

審查的標準是什麼？
確定審查的目標與方向，接下來當然是設定通過與否的標準，用上面的審查內容繼續說明。
●功能
無論是哪種類型的產品開發，都能設定為「階段需要完成某些功能」來當成審查的標準，例如：汽車必須可以飛起來，掃地機器人不用換集塵盒……等等，各種特殊的功能需求都可以列入審查標準中。
●客戶採用
這是一個廣泛的標準，真要衡量的話，可以設定多少客戶為門檻通過階段審查，或是採用金額達到多少後通過，例如：獲得5個客戶採用且金額超過500萬台幣，即可通過此階段。
●產品是否獲得特定群族的好評
這個衡量標準不難設定，可以這樣定，比如：公司是3D設計軟體的供應商，特定族群可以是市場上前100大的使用者，好評與否則可以利用問卷調查來設定，如果滿意度超過85分則視為通過。
●階段品質標準
針對軟體業，如：App開發，審查階段品質標準，如：滿意度、良率，最快、最簡單的方法當然是App獲得多少顆星的評價了，然而，非App軟體也可以利用其他的滿意度評價方式來衡量。製造業常用的衡量指標就是良率，產品在樣品階段的小量生產中，一般會統計組裝後的良率，來衡量是否適合大量生產交貨，如果設計出一個成本與功能都會令消費者開心，但良率相當低的產品，通常也很容易在開發階段就被喊停。
●成本標準
報價成本、開案設定工時等，硬體與軟體相關業者在成本的計算是不同的，所以硬體開發多半是計算BOM、Cost與相關生產成本，這在單一階段就很容易設定目標，比如：開模後的第一次組裝不可以超過某個比例的值、量產前成本需達到報價成本以內。軟體業則一般都是計算人員工時，所以可以衡量在這個階段或Sprint，到底花了工時、是否超過標準來設定通過與否。

階段的產出
所謂階段的產出概念其實簡單到不可思議，列起來可能就寥寥幾項而已，一點也不複雜。
●通過
階段經審查後符合標準，予以通過往下一階段，繼續投注資源。
●不通過
階段經審後不符合標準，繼續停留在此階段，直到完成此階段的目標。
●有條件通過
經審查後發現某些要素並未完全符合，但還是判定值得往下投入，只是需要監督某些特定的條件是否在特定時間點完成。
●暫停
討論過後認為現今的狀況不適合繼續投入資源，但專案仍具有一定價值，所以只是暫時停止投入，將所有動作在此階段收尾後，關閉所有待辦事項、儲存專案資料。
●放棄
研究後認為往下繼續開發不具備經濟或其他效益，因而決定將專案永久關閉，同樣進行收尾，並將所有的資料整理後，封存在可檢視的位置。

Gate Review的主要目的與功能，都是在透過設定清楚Gate來Review專案階段，判斷是否要調整方向或繼續投入，將來能夠產出更大的效益，或是當機立斷地暫停或結束專案，來避免耗用更多的資源，轉而將有限的資源投入到其他更有效益的專案運用。

學會了嗎？利用Gate Review來檢視投入資源與產出效益的比例，階段審查可以幫助專案較多的公司進行合理的分配資源，也可以幫助專案較少的公司更精準地確認專案的重點指標，如果現階段公司有此制度的話，那非常恭喜，如果沒有的話，何不去推動這項制度的建立，來幫助解決過往所忽略的問題呢？