人都是做自己在意的事情
前陣子在公司碰到一個狀況。我們公司的 QC 部門一直比較薄弱。多數時間是在針對客訴做 troubleshooting 回應。前陣子 QC 部門進行改組，把原本分散各部門的 QC 人員整合成一個部門，也指派了一位新主管。但他們對於自己要擔任的職責範疇 (R&R) 仍在重新釐清。
前陣子我有兩個新產品開發專案準備收尾，正在進行最後規格定稿。基於禮貌下就拿給 QC 部門過目一下。開發過程中都有 QC 人員受邀開會，會議記錄也有 CC 他們，他們很少在會議中提出疑慮。所以我心想 QC 應該對產品開發內容皆核可沒問題。萬萬沒想到 QC 主管劈哩啪啦給了一堆質疑意見，有的意見甚至可能會動搖到規格而被迫延遲專案。我完全沒預期到 QC 主管如此突然的大反應。
對這問題一直百思不解，後來尋求了一些前輩的意見，才解了我的疑惑。原來雙方在意的區塊不同。我在意的是產品研發沒重大問題，讓新產品準時發表，專案如期結案。而 QC 主管他要確保的是產品萬無一失，最好零缺點，以避免往後客訴麻煩。我跟他聚焦的重點不同。在目標上的出入就會造成兩方似乎在互相扯後腿的現象。雖然從更高的角度看，兩邊都是在為公司好。
更深一層分析，癥結點在制度設計上， QC 不需共同承擔專案時程責任。專案過程中也被放在旁觀審核者角度，而不是產品或專案的擁有者(owner)之一。換句話說，在專案過程中 QC 無需持續檢視研發中的產品可能會有何品質疑慮及提醒研發團隊。他們被賦予的責任是只需在專案最後階段做審核人。若品質審核發現有任何問題，直接卡住產品要求團隊再回去釐清修改就沒自己的事了。但這一切其實是可以在研發過程中，早期發現早期處理的。
後來與主管跟 QC 部門討論後我做了一些調整
團隊與責任調整
直接將 QC 人員升格成核心專案成員，增加他們在專案裡的責任承擔。新增的責任有:
- QC 成員參與所有專案文件的制作工作
2. 參與專案定期會議。在開會過程中詢問 QC 人員有無任何品質方面的回饋，並及時將這些需求納入規格開發考量。
3. 參與產品試產並與生產部成員共同檢視試產成果。
交付物審核
QC 主管須負責交付物里程碑之前的審核。以往 QC 主管都是在產品正式發售後，產品出了問題才跑來詢問這產品到底是什麼，怎麼做出來的。為了避免這種狀況，現在 QC 主管也必須要納入利害關係人管理名單中，確保 QC 主管也有參與到產品開發過程並負起一部分責任。
當他做審核的時候，由於他的部屬同事已積極參與了，理論上資料審核都能很快完成。若發現有問題之處，那就是集眾人之智而發現的缺失，不容易發生任何人被指責當箭靶。QC 主管也必須代表QC部門參與交付物里程碑會議。
以上經驗供各位讀者參考。當碰到似乎別人來找碴，阻撓自己的工作進度時，可以先想一想，是否為制度設計不良導致的結果。或許修改一下，讓目標方向一致就可以減少這些不必要的衝突。
記得「Follow」我的 Medium，讓我提供更多優質文章給您。如果覺得這篇文章不錯，也請不吝掌聲拍手。你的拍手是我寫作的動力。
