2025 年 1 月，組織開始導入 Team of Teams，比同年 7、8 月開始的 AI 導入，早了約半年。當時管理層有一個很明確的想法：打破部門的界線。這個方向，也跟 AI 時代帶來的變化有關。AI 讓很多工作開始有機會跨越原本的職能範圍，過去照著部門、職稱去分工的方式，也開始有重新思考的空間。
聽到這個方向時，我大概能有一些想像。每個人有自己擅長的專業，透過專案的方式，一起解決一個特定的問題，而不是只顧自己負責的那一段。後來回頭整理，我才發現，自己之所以比較容易理解，跟過去那幾年導入 Scrum 的經驗有關。這個系列從「我曾經讓敏捷落地」開始，寫到這裡，我開始把目光從自己，以及我和工程師、和 AI 的協作，往組織多看一點。但組織這一塊，我也還在摸索。這篇想寫的，是這次的參與和觀察，讓我重新想起了哪些過去的經驗。
以前做 Scrum 的時候，我需要跟業務 PM 溝通，也需要跟工程師溝通，兩邊的語言都得聽懂，還得想辦法翻譯給另一邊。久了之後，我比較能理解，上游為什麼提出這個需求，下游為什麼覺得這樣做有困難；也慢慢知道，同一件事情，站在不同的位置，判斷的標準可能完全不一樣。所以當組織開始談打破部門界線，我腦中已經有一些過去合作的畫面。但這是我帶著自己的經驗，才有的想像。
對其他工作背景的人來說，原本知道自己負責什麼、把自己的事情做好，現在卻要一起思考整個專案，這中間其實有很大的轉變。為什麼要這樣做？自己的責任到哪裡？其他人的事情，需要理解到什麼程度？這些都需要慢慢釐清。我後來提醒自己，不能因為我覺得熟悉，就以為這件事對大家都很自然。
我對這種協作方式的一個期待，是大家不再只用現在的職責，來決定自己能做什麼。當一個人只負責流程裡的一段，很容易把事情做好就交出去，至於前面為什麼這樣安排、後面會怎麼使用，未必有機會知道。但當大家圍繞同一個專案目標工作，就會開始看見：原來我的產出，會影響別人下一步能不能做；原來別人一直跟我要的資訊，是拿來做這個判斷。這些理解累積起來，才有機會從自己原本的專業，往另一個領域深入。我覺得，這對長成 π 型人很重要。不過，打破部門界線之後，人不會馬上就長出新的能力。以前我能聽懂工程師的考量，也不是因為被放進同一個團隊，就突然懂了，是一次次討論、問不清楚再回去確認，才慢慢學會的。
前面寫過，當年我們導入 Scrum，該有的會議一個都沒少，Sprint 也重啟了三四次，但很長一段時間，大家都沒有真正體會到哪裡不一樣。後來才慢慢明白，共同目標、默契、理解彼此的工作，這些都需要在實際合作裡累積。會議可以照表安排，但協作的方式，不會因為會議開了就自然改變。以前推動敏捷時，我一直記得一件事：敏捷不代表開發得更快，而是讓我更了解使用者，也有機會更早知道自己做錯了。 換到新的組織情境，我覺得這個提醒還是管用。新的工作方式需要嘗試，也需要回頭看看，大家現在理解到哪裡、卡在哪裡，再調整下一步。Team of Teams 是這樣，後來的 AI 導入也是這樣。
第一，是大家到底要一起解決什麼問題。
過去做產品時，只要目標不清楚，大家就很容易各自做出看起來合理、卻接不起來的東西。跨職能協作也是一樣，需要一個值得投入的目標，也需要理解，這件事情跟自己有什麼關係。這份理解，會影響大家願不願意多問一句、多往前走一步。
第二，是每個人對自己工作的掌握度。
以前跑 Scrum，我們也是透過一次又一次的 Sprint，才慢慢了解每個人擅長什麼、哪裡容易卡住、需要什麼支援。這不是看職稱就能知道的事。如果期待一個人很快就能支援其他職能，我會先想，他對自己原本的工作，掌握到什麼程度？哪些判斷已經很熟悉，哪些還需要有人一起確認？這會影響能力能往外延伸多遠，也會影響需要怎樣的支援。
第三，才是 AI 能在哪裡幫上忙。
當一個人比較清楚自己的工作需要什麼資訊、中間做什麼判斷、最後要交付什麼，就比較有機會把其中一部分交給 AI，也知道拿回來的結果該怎麼看。AI 還可以幫我們理解原本不熟悉的工作，讓能力有機會往上下游延伸。但能產出一份東西，跟真正掌握那份工作，中間還有一段距離。這一段，一樣需要做過、確認過，才會慢慢知道自己懂了多少。
Team of Teams 先發生，AI 導入在後。我剛好參與了兩邊，但這兩件事有各自的脈絡，不能因為時間接近，就直接當成前後相接的成果。對我來說，比較有意思的是，走到組織這一層之後，過去做 Scrum 時反覆遇到的問題，又出現了：大家有沒有理解共同的目標？知不知道彼此怎麼工作？遇到不確定的事情，有沒有機會一起弄清楚？我以前以為，那幾年是在學怎麼讓開發團隊運作。現在回頭看，那段經驗也讓我開始理解，人要怎麼一起工作，以及一種新的工作方式，需要花多少時間，才會慢慢變成大家真正掌握的能力。
iThome鐵人賽
看影片追技術