組織裡大部分的工作都在團隊裡完成，而最好的團隊通常是**跨職能（cross-functional）**的——成員來自組織中不同的角色。身為 HoP，核心問題就是：

怎麼打造更有效率、更有效、更好玩的跨職能團隊？

答案是：coach 你的 PM 去學會怎麼帶團隊，忍住親自下場「動」團隊的衝動，並幫他們移除自己無法處理的阻礙，同時在整個公司推動 agile mindset。

團隊到底是什麼#

Jon Katzenbach 與 Douglas Smith 在《The Wisdom of Teams》給的定義，點出了「一群有共同任務的人」與「真正的團隊」的差別：

A team is a small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable.

一群技能互補、承諾共同目的/績效目標/工作方式、且彼此相互負責的少數人。

跨職能團隊把不同職能的人放在同一艘船上：開發、設計、QA、PM、分析師，有時還有行銷、BD 等部門的成員。光把一群有才能的人湊在一起叫它「team」，不保證成功。

HoP 能做的 3 件事#

  • 賦權團隊（Empower the team）：和其他職能主管（工程、設計 ⋯）一起確保團隊技能組合完整；團隊真的有 end-to-end 的決策權去創造對使用者與公司都有價值的產品；團隊目標與其他團隊、公司目標對齊
  • 縮小 maker-to-user gap：讓你的 PM（理想上是整個團隊）直接接觸使用者——給預算做 usability testing、鼓勵多做 user interview、把 user research 人派到團隊一段時間
  • 幫組織採用 agile mindset：讓你的 PM 有能力把 agile mindset 擴散到整個組織（不只是 product），這樣團隊才不必一直為自己的工作方式辯護

不要「動」團隊：Tuckman 四階段#

1965 年心理學家 Bruce Tuckman 提出每個團隊都要走過四個階段：

  • Forming：大家意識到「我們現在是一個團隊了」
  • Storming：問題浮現，團隊要自己找出解法；團隊規範與規則慢慢浮現
  • Norming：成員開始建立信任，找到自己在團隊裡的位置
  • Performing：真正彼此信任、做出產出

團隊化學反應是脆弱的。哪怕只是小小調整團隊組成，整個團隊就必須從頭再走一次四階段——這既沒效率，對成員也很辛苦。

把精力放在 coach PM 怎麼帶團隊，而不是動來動去「微調」團隊。讓他們自己走出路。

幫 PM 學習團隊合作#

PM 必須留意團隊產出與績效，卻沒有正式職權——他們是 lateral leader（橫向領導者）。你的工作是幫他們想清楚：沒有權柄的時候，能用什麼行動去影響產出。

PM 能做的第一件事：讓團隊理解挑戰與使命#

團隊需要共同目標，PM 必須發展這個目標、把大家聚攏起來。PM 需要為自己的產品建立願景，定期跟團隊分享：要給顧客什麼價值、公司要達成什麼才值得做這件事。

接著處理團隊的 ways of working#

組織裡如果有 Agile coach，這時候就請他出場。如果沒有，PM 可以帶團隊定義自己的 team values。

Team Values Workshop：

  1. 每人寫下 5 個你能想像最糟的同事特質
  2. 匯集所有特質，用 dot voting 投出「最讓人抓狂的」
  3. 挑前 10 名，請團隊反向想出對應的正面特質
  4. 討論其中哪些對團隊最重要
  5. 改寫成 value 句型：We value this [behavior] because [reason]
  6. 貼上牆並不是重點，重點是在日常討論與 retrospective 中真的使用

其他值得 PM 做的事#

  • Agile basics workshop：一起看 Agile Manifesto、原則與價值，討論對團隊的意義
  • Definition of Done / Definition of Ready：feature 何時算定義清楚可以開工？何時算完成？是測完？部署完？上線？還是使用者真的能用？這些討論讓成員彼此熟悉，流程更順
  • 找一位 Agile coach：他不做產品本身，但幫團隊處理流程、儀式、會議 facilitation，帶進不一樣的視角

The Five Dysfunctions of a Team（Lencioni）#

PM 一定會碰到團隊問題。Patrick Lencioni 指出團隊問題常源自五個失能：

  • Absence of trust（缺乏信任）：不願意展現脆弱；對彼此的錯誤與弱點不坦承 → 信任的地基立不起來
  • Fear of conflict（害怕衝突）：沒有信任就沒辦法真誠、熱烈地辯論點子，只剩包裝過的討論與閃躲式評論
  • Lack of commitment（缺乏承諾）：意見沒經過開放辯論，大家只是會議上假裝同意，事後不 buy-in
  • Avoidance of accountability（迴避問責）：沒有明確計畫，就算是最有動力的人也會猶豫要不要點出同儕的問題行為
  • Inattention to results（忽視結果）：成員把個人需求（ego、職涯、被認可）或部門需求放在團隊集體目標之上

把五個失能翻成正面，就是高凝聚力團隊的行為：

  • 彼此信任
  • 能針對點子進行沒有過濾的衝突
  • 對決定與行動計畫做出承諾
  • 彼此問責執行進度
  • 聚焦在集體結果的達成

PM 知道這五個失能後，能更精準描述自己在團隊中觀察到的狀況——也會認真看待「信任」這類常被視為 soft factor 的因素。

幫 PM 移除阻礙#

作為 HoP，首先鼓勵團隊自己解決；碰到他們影響不了的事，才幫他們。以下是常見阻礙：

團隊變慢或交付不出來#

通常是對齊或自主性的問題。

對齊不足（Not enough alignment）：沒有共同目標、沒有清楚的 target、產品願景不見了或不再激勵人。和 PM 一起處理這些，同時訓練他們的 storytelling——例如請 PM 為下次大版本寫一份新聞稿然後分享給團隊。

Janet Fraser 在 2018 Mind the Product London 分享的 UBAD 模型衡量 buy-in，從下到上必須按順序建立：

  • Understanding：他們理解這個目標/願景嗎？
  • Belief：他們相信它嗎？
  • Advocacy：你看到他們準確、有效地為它發聲嗎？
  • Decision：他們做的決定在支持它嗎？

自主性不足（Not enough autonomy）：團隊是否真的夠跨職能？是否有對的技能？PM 是否鼓勵團隊自己做決定、依靠自己的專業？（PM 不在場就決定不了事，是警訊。）團隊是否缺一點預算來提升工作方式？——從買新硬體加速開發到買一份研究報告都算。找 Head of IT、Head of Design 聊人力議題；爭取讓團隊有真的決策空間、真的能自由運用的預算。

另一個可能原因：PM 沒有鼓勵團隊帶自己的工作任務上來。組織裡永遠都有商業想法、PM 永遠有 feature idea，但開發者也有一堆「遲早要處理」的技術事項被推遲。鼓勵 PM 認真聽團隊說「這件事現在不處理，之後會卡我們」。

團隊對優先順序不服#

檢查產品願景與 storytelling。自問：成員有夠參與 discovery、理解使用者需求嗎？PM 是怎麼把資訊分享給團隊的？

成員之間有衝突#

用 Lencioni 的五失能幫 PM 診斷；鼓勵 PM 更投入 retrospective（組織或 facilitate）。Retromat ↗ 是好靈感來源，或用下面的 Team Radar。衝突嚴重時，找 Agile coach 或 line manager。

Team Radar（Figure 19-1）#

團隊在 8 個面向上（如 customer centricity、courage、communication、trust⋯）討論自己做得如何，共同商出一個分數畫在蜘蛛網圖上，分享彼此對每一塊的看法，最後針對弱點定出 action items。

Figure 19-1: Team Radar example

        customer centricity
              / \
   trust ---/   \--- courage
          /       \
         |  Team   |
         |  Radar  |
          \       /
 comm.  ---\   /--- ...
            \ /
            ...

產品本身不成功#

這不是 HoP 能快速修掉的。可能是 discovery 不夠、做錯實驗、團隊沒有參與；或創意/創新不足、PM 不注意細節、聚焦 output 而非 outcome。逐項和 PM 核對。

PM 變成 bottleneck#

PM 陪團隊的時間不夠時就會成為瓶頸。和 PM 談，幫他看見問題，鼓勵他檢視時間分配——有些任務是不是該 delegate 給團隊？（就 team autonomy 的角度，通常本來就該。）

一些收尾原則#

  • 不要動團隊，要清路。鼓勵 PM 先自己處理團隊內問題；但有些阻礙必須你親自出手——認真對待
  • 持續推動整個組織的 agile mindset。公司理解 agile 的價值時，你的跨職能團隊的工作方式就不會一直被質疑
  • 觀察你的 PM 是不是好的 lateral leader。right people in the right seats——也許某些 PM 沒你想的那麼好（失去團隊信任？）；也許某些成員沒有大家想的那麼好。花時間和 IT、Design 等 tribe/部門的主管 check in，拿到他們的回饋
  • 快樂的團隊相信團隊本身很棒、使命值得投入。成員需要看到自己的努力累積成更大的東西——你的工作就是幫他們看到

延伸閱讀#

  • Janet Fraser 的 UBAD buy-in 衡量模型
  • Henrik Kniberg 論「maker-to-user gap」最小化
  • Team Radar、Retromat ↗
  • Agile values、Tuckman stages
  • Nima Torabi: Collaborating effectively in cross-functional product team settings
  • Marty Cagan: Empowered Product Teams
  • Patrick Lencioni: The Five Dysfunctions of a Team
Backward 產品人的時間管理 直接而開放的溝通 Forward