十月 2025 – 太陽拳的萬人敵之術

最近被拉進一個專案，團隊成員是一群賀爾蒙超標、噗噗跳的二十出頭年輕人。很有野心，也很熱血。這群人自己合作行之有年，而我們則是後來被空降進來的外部團隊。

爲首的工程師桀驁不馴，頭角崢嶸，對產品有想法，劍及履及，也確實擁有部分能實現產品遠景的技術。我們被拉進來的理由很單純──補上他們技能樹上那幾塊還沒解鎖的拼圖。

但也正因爲他桀驁、我們空降，兩邊的氣場一開始就不太一樣。
我們團隊很忙，也不是全職處理該專案，因此第一反應是：
「切得越乾淨越好，別互相干涉，更別談融合。」

而他們的想法卻完全相反——他們希望強制融合，所有流程、節奏、開發方式都得照他們的規則走。

問題就出在這裡：兩個團隊都想往前，只是想前進的方式完全不同。
再加上跨時區、文化與溝通習慣的落差，整個專案一開始可說是跌跌撞撞。

先把事情說開，把問題攤在桌上聊

畢竟兩個團隊想往前的方向不一樣，日常裡就開始出現一些小摩擦。
一兩次還好，可以裝作沒看到繼續往前；但越不處理，雙方就越想把對方拉到自己那一邊。想法和做法的張力越來越強，空氣裡的硝煙味也跟著濃了起來。

如果任由事態發展，我在某個東亞團隊裡就看過最壞的版本——最後至少會出現兩個山頭，團隊成員各自選邊站。
對話裡不再有「我們」，只剩下「他們」。
合作變成走過場，閉門造車，只要沒有互相扯後腿，就已經算萬幸。

若這樣的對峙持續太久，兩邊都會開始有人離職。
這種情況，只能迎面處理——不拖、不閃，開門見山地把問題攤在桌上講。

於是我們和那位帶頭的工程師開了幾次長會，討論合作方式與理想進程。
先讓他說明他想要的節奏與模式，再由我們指出其中的盲點，分享自身經驗，嘗試敲出一個折衷方案：
以他的想法為骨架，以我們的經驗作支撐。

年輕的 8+9 團隊很重視話語權，想掌控專案方向。
這點剛好和我們互補——我們並不執著於主導權，只想輔助執行、把產品做好。
這樣的立場，我們在多次討論中必須說得非常清楚。

處理完心理層面的對立後，接下來就是信任問題。

面對能力見長的團隊，信任要靠「實力」換來。
只要讓他們知道——在他們的盲點裡，你團隊很罩——就夠了。

這其實很直觀。好的技術人員，多多少少都有種《棋靈王》式『神乎其技』的執念：
對熟悉的領域意見極多，對陌生的領域則帶著好奇與敬畏。
而這份「英雄惜英雄」的情感，正是建立團隊互信的起點。

要建立信任，不是對所有技術決策都指指點點，而是要抓準時機補足他們的短板——
在他們不擅長的部分，補出一套能說、能做、能實現的技術論述；
在他們擅長的地方，就放手讓他們揮灑，整體節奏才會流暢。

信任就是在這樣的技術切磋與互補中慢慢累積。
有點像存錢——在產生利息前，要一塊一塊地累積本金。

但如果碰上他們擅長的領域，而我們又對他們的決定有強烈建議，該怎麼辦？
我們的經驗是：
只要點出盲點，然後跟他們一起討論解法即可。
聰明人看問題，不要一開始就想打 power play。

不要進入 power play。
「誰比誰大，所以要聽誰的」這種論述，是最容易傷害熱情與創意的做法。

就算暫時沒有共識，也應該讓團隊充分討論各種方案，再由負責人從商業角度提供意見、做出決定。
這樣的流程，聰明的技術人員多能接受，也能讓大家更清楚理解商業決策的考量。
一旦彼此能理解「為什麼這樣決定」，團隊默契自然會再往上一層。

畢竟在專案中，各自的角色不同，推進的速度與節奏也不同。
最後我們團隊與 8+9 團隊自然分開運作，但在兩邊之間，我們設計了多個溝通節點與會議機制，確保雙方的半成品與成品能夠順利整合。

每個 sprint 結束時，我們都能交出整合好的 deliverable 與 demo——
專案也就這樣穩穩往前走。

但這套溝通架構需要持續維護。

一旦運作出現卡頓，就要回頭 review，重新設計、再迭代。
上游合作品質不佳，後續一定會反映在下游的 deliverable 上。
如果只看成品 debug，往往要花好大一筆成本才能追出上游的問題，還不一定能夠立即解決。

回過頭來看，其實 8+9 型的團隊並不難合作。
難的，是我們一開始對專案、對團隊的前進方式，有非常大的想像差別。

他們的能量很真——那種想證明自己、想在最短時間內做出改變的衝勁。
要跟這樣的團隊合作，不能逃避矛盾與衝突，而要坦蕩地直面：
直面彼此對專案的野心，也直面各自對團隊的期待。

目前我學到的，是要能接得住他們對控制的執着、對產品的野心，
同時也撐得起他們的信任。
這兩件事都不容易，但一旦稍微做到一點，專案的能量就會明顯不同。
那不是「硬被管理出來的穩定」，而是「共振出來的節奏」。

或許這階段的筆記就先到這裡。
專案還在進行，故事也還沒寫完。
但至少目前，我們似乎開始找到一種能讓雙方都呼吸順暢的節奏。