Cross-functional alignment and action closure in product development
專案真正難的，通常不是技術，而是協作。
一個新產品要從概念走到量產，往往不是某一個部門單獨就能完成。業務看的是客戶需求、時程與業績壓力，RD看的是技術可行性、規格完整性與開發風險，工廠在意的則是產能、良率、製程穩定度，品保關心的是交付後的品質與後續風險。每個部門的出發點都合理，但也正因為出發點不同，專案很容易在中間開始卡住。
最常見的情況，就是大家都在講同一件事，卻像是用不同語言在對話。
業務會說，客戶已經催了，這個案子不能再拖。RD會回，規格還沒定，現在硬做風險太高。工廠則會反映，這個條件下良率不穩，試產也不一定能過。每一方都有自己的理由，也都有自己的壓力。問題不在於誰對誰錯，而在於這些資訊如果沒有被整理過，就只會變成來回拉扯，最後誰也沒有真正往前推一步。
我後來慢慢體會到，跨部門協作最重要的，不是把每個人都說服，而是先把資訊整理成大家聽得懂、也接得住的樣子。這件事看起來簡單，其實很考驗人的判斷力。
對專案來說，資訊不能太散
要看的，不是每一個技術細節，而是現在的問題是什麼、影響有多大、接下來有什麼選項。也就是說，資訊要先降噪，留下真正需要決策的部分。很多人簡報時容易把所有東西都塞進去，怕漏掉任何細節，但對管理層來說，過多資訊不但沒幫助，反而會讓重點被淹沒。
反過來，當我跟 RD 或工廠對接時，就不能只講大方向。這時候必須把需求拆得更細，講清楚條件、範圍、時間點和限制。因為執行端最怕的，不是任務多，而是任務模糊。只要邊界不清楚，後面就會開始出現解讀差異，最後不是重工，就是互相推責。
所以我一直覺得，專案最重要事，就是能夠切換語境。面對不同對象，用不同粒度講同一件事。不是話說得越多越好，而是要讓每個角色都知道自己現在要做什麼、不能做什麼、以及為什麼要做。
但光是把話講清楚還不夠，真正讓專案往前走的，是任務閉環。
很多會議看起來有討論、有結論，甚至當下氣氛還算順，但一週後回頭看，事情卻沒有人真的去做。原因通常不是大家故意拖，而是會議沒有留下可以執行的東西。討論完如果沒有明確責任人、沒有期限、沒有驗收標準，那這場會議多半只是把話講完，還不算真正完成。
會議紀錄是需要的，不是為了寫流水帳，而是為了讓每一件事情都能被追蹤、被確認、被收尾。該由誰負責，什麼時候完成，完成的標準是什麼，這些都要先講清楚。很多跨部門問題，表面上看起來像溝通不良，實際上是責任沒有落點。事情沒有落點，進度就不會有閉環。
尤其當任務涉及跨部門交接時，驗收標準更重要。RD交給工廠的，不只是文件或圖面，而是後續能不能順利導入製程；業務帶回來的，不只是客戶需求，而是這個需求是否真的可行、是否值得投入資源。每一次交接，都是一次風險轉移，如果沒有先對齊標準，後面就很容易反覆修改，甚至變成雙方各自有理。
所以專案剛開始的時候，花多一點時間把目標、邊界、風險和責任講清楚，後面其實會省下很多溝通成本。看起來像是前面慢了，但其實是替後面加速。很多專案失敗，不是因為做不出來，而是因為一開始沒有把規則定好，但除了規則團隊的默契建立也很重要。
說到底，跨部門協作不是比誰聲音大，也不是比誰比較懂，而是誰能把事情整理得更清楚，讓每個部門都能在自己的位置上往前走。
如果一個專案裡，RD、業務與工廠始終在不同語言裡打轉，那專案就很難真正落地。真正有價值的，不是讓大家講同樣的話，而是讓大家在不同角色裡，最後走向同一個目標。
我想….資訊要先被整理，理解要先對齊，責任要有人承接，流程也要能真正閉環，事情才會開始動起來。
YinOnMars 
發表留言