從「同地辦公」到「分散式」#

作者長年是「同地辦公」（co-located）的擁護者。Jeff Bezos 對此有經典描述：

「在 Amazon，產品團隊有清楚的使命、具體的目標，並且必須跨職能、專責、同地。為什麼？創造力來自人與人之間的互動，靈感來自高強度的專注。就像新創團隊擠在車庫裡——實驗、迭代、討論、辯論、嘗試又嘗試。」

——Jeff Bezos

作者認為這並非巧合：Amazon 是科技業中持續創新最具一致性的公司。

但問題已經改變#

對許多公司而言，今天的問題不再是「要不要同地」，而是：「當團隊分散、部分或全部成員遠距時，要如何運用最佳實踐維持創新？」本章就是要處理這個問題。

本章不重複討論已被廣泛接受的工具與方法（雲端協作平台、視訊會議服務）。重點放在跨職能團隊的本質。

探索（Discovery）vs. 交付（Delivery）#

每個賦能型團隊都有兩大類活動：探索與交付。當人們談「同地辦公的魔力」時，主要指的是探索（如同 Bezos 引言）。

探索的方法本身在遠距與同地之間差異不大——仍然是「多個產品點子、做原型、用真實使用者驗證」。但真正的差別在 PM、設計師、技術主管之間如何協作出值得打造的解法的動態。

作者觀察到三個一貫存在、且任一個都會嚴重損害創新的問題。

1. 文件主義（Artifacts）#

一旦把 PM、設計師、技術主管分開，就會出現一個幾乎像重力的反模式——他們會開始為彼此產出文件，而不是一起討論「我們要怎麼解決這個問題？」

典型樣態：

• 設計師問 PM：「能不能先寫個 brief 或需求？」
• 技術主管問設計師：「線框稿什麼時候能給？工程師要開始規劃了。」
• PM 問工程師：「給我估時間。」

很快地，整個流程就退回類似瀑布的「文件接力」——創新會受損，討論的焦點也會從結果（outcome）退回到產出（output）。

解法：強迫自己回到「How do we solve this problem?」的視訊三方討論——表面上看起來「沒效率」，但這才是探索本身。探索期間的主要文件就是原型（prototype）。

當你決定要交付時，遠距工程師可能還沒看到最新原型，這時當然需要花時間描述細節給工程師與 QA——但只在你已經相信解法是有價值、可用、可行、可商業化之後。

2. 信任（Trust）#

探索與創新仰賴心理安全感（psychological safety）：團隊成員覺得被尊重、貢獻被歡迎且被珍視。

一個混蛋就能毀掉這份動態。幸運的是，多數人不是混蛋——但當人不是面對面交流時，正常的過濾與敏感度會減弱。

作者聽過不只一位部屬反映：「我看見了同事不一樣的一面——而且不總是好的。」

輔導的角色：

• 多數人不是有意冷酷或不敏感，他們只是少了非語言線索
• 好的主管能輔導部屬調整線上互動、識別可改進之處

看似 email 或 Slack 比較有效率——但一條表達不當的訊息若需要花幾小時做損害管控，就一點都不有效率了。

任何可能被解讀為敏感的話題，都改用視訊：表情、語氣、肢體語言對信任至關重要。

3. 時間（Time）#

• 有些人在家不被打擾，反而比過去更專注、有質量地處理難題
• 但很多人——尤其是有家庭照顧責任的人——渴望回辦公室「逃離家裡的負擔」

現實是：團隊成員不會擁有同等長度的高品質連續時間——找到「每天 1 小時大家都有空、不被打斷」可能極為困難。

主要建議：有彈性。例如設計師有幼兒，每天只能擠出一個早或晚的「整段一小時」，PM 與技術主管若能配合，就應該配合。

結語#

文件、信任、時間——這三個挑戰沒有一個容易處理。

但若你發現分散式團隊交付的成果不如以往，這就是你應該聚焦輔導的三個面向。

讓團隊清楚知道這些風險，並由主管提供避免或處理的輔導，分散式環境下你仍能做好產品探索。