技術團隊不是孤島，與產品、設計、運營的協作決定了產品成敗。

跨部門協作的挑戰#

跨部門協作的難點不在於溝通技巧，而在於目標不對齊、語言不通、利益不一致。解決這些根本問題，溝通自然會順暢。

常見的協作問題#

問題表現根本原因
目標衝突產品要快、技術要穩沒有共同的優先級框架
語言不通產品說用戶，技術說架構缺乏共同語言和背景知識
互相不理解「技術不懂業務」「產品不懂技術」缺乏換位思考
推諉責任「這不是我們的問題」職責邊界不清

協作失敗的後果#

flowchart LR
    subgraph MILD [⚠️ 輕微]
        M1[進度延遲]
        M2[返工重做]
        M3[氣氛緊張]
    end

    subgraph SEVERE [🚨 嚴重]
        S1[產品方向錯誤]
        S2[技術債務積累]
        S3[人才流失]
        S4[業務失敗]
    end

    MILD -->|持續惡化| SEVERE

    style MILD fill:#fff3e0
    style SEVERE fill:#ffebee

與產品經理的協作#

理解產品經理的視角#

邱岳在《產品手記》中解釋了產品經理的工作：

  • 核心責任：定義「做什麼」和「為什麼做」
  • 壓力來源：用戶需求、業務指標、資源限制
  • 常見困境：需求太多、資源有限、各方期望不一致

技術與產品的常見衝突#

產品視角技術視角如何平衡
「用戶需要這個功能」「這個架構要大改」評估真實的用戶價值和技術成本
「競爭對手已經有了」「抄不是長久之計」分析是否真的需要，還是有更好的解法
「老闆說要做」「技術上不可行」一起向上溝通，提出替代方案
「能不能快一點」「快了就容易出問題」明確 trade-off，讓產品做決定

與產品高效協作的方法#

寶玉的建議：

  1. 早期參與：技術在需求定義階段就參與，而不是等 PRD 出來再看
  2. 理解為什麼：不只問「做什麼」，還要問「為什麼做」
  3. 提供選項：不只說「做不到」，還要說「可以這樣做」
  4. 共享數據：用數據說話，而不是感覺

邀請產品經理參加技術評審，讓他了解技術複雜度。邀請技術參加用戶訪談，讓他了解真實需求。相互了解是協作的基礎。

與設計師的協作#

理解設計師的視角#

設計師關注：

  • 用戶體驗：用戶操作是否順暢
  • 視覺美感：界面是否美觀一致
  • 設計系統：是否符合整體設計語言
  • 設計價值：不只是「畫圖」，是解決問題

常見的技術-設計衝突#

設計要求技術挑戰協商方式
複雜的動效性能問題、開發成本評估對用戶體驗的真實影響
完美的像素對齊不同設備的適配定義優先級，核心頁面優先
新的交互模式沒有現成組件評估通用性，是否值得做成組件
頻繁的設計修改返工成本建立設計評審流程

設計協作最佳實踐#

mindmap
  root((設計協作))
    🎨 建立設計系統
      統一的組件庫
      一致的設計規範
      技術和設計共同維護
      減少重複討論
    💬 前置溝通
      技術可行性早期反饋
      設計意圖早期說明
      減少後期返工
      共同探索方案
    📏 明確邊界
      哪些細節必須嚴格還原
      哪些可以有彈性
      不同設備的優先級
      性能和效果的平衡

與運營的協作#

運營的需求特點#

運營團隊通常有以下特點：

  • 響應快：市場機會稍縱即逝
  • 需求變化快：根據數據和反饋不斷調整
  • 時效性強：錯過時機就沒意義了
  • 個性化多：不同活動有不同需求

技術如何支援運營#

喬新亮的經驗：

  1. 建設運營平台：讓運營自己配置，減少開發介入
  2. 標準化組件：常用的活動頁面、推送、彈窗做成模板
  3. 快速通道：緊急需求有快速上線機制
  4. 數據支撐：提供運營需要的數據看板

技術不應該被動響應每一個運營需求，而是要思考如何用平台化、組件化的方式提高效率。

需求管理與優先級#

需求爆炸的困境#

喬新亮在《CTO 成長復盤》中討論了「需求做不完」的問題：

作為初中級管理者，面對堆積如山的需求，解決方案是加人或者拼命干。 但高級管理者需要學會說「不」。

優先級決策框架#

邱岳推薦的優先級框架：

mindmap
  root((評估維度))
    👤 用戶價值
      對用戶的幫助有多大？
    📈 業務價值
      對業務指標的影響？
    💰 開發成本
      需要多少資源？
    ⚠️ 風險程度
      失敗的概率和後果？
    ⏰ 時效性
      是否有時間窗口？

優先級矩陣：

quadrantChart
    title 優先級矩陣
    x-axis 低價值 --> 高價值
    y-axis 高成本 --> 低成本
    quadrant-1 P0 立即做
    quadrant-2 P2 可以做
    quadrant-3 P3 不做
    quadrant-4 P1 規劃做

說「不」的藝術#

說「不」不是拒絕，而是引導更好的選擇。

如何優雅地說不：

  1. 先理解需求：確保你真的理解對方要什麼
  2. 說明原因：為什麼現在不能做
  3. 提供替代：有沒有更簡單的方案？能不能分期做？
  4. 給予希望：什麼條件下可以做

建立共同語言#

為什麼需要共同語言？#

不同職能使用不同的術語：

  • 產品說「用戶故事」，技術說「功能點」
  • 設計說「體驗」，技術說「性能」
  • 運營說「活動」，技術說「配置」

建立共同語言的方法#

  1. 統一術語表：對關鍵概念達成一致的定義
  2. 共同參與：讓不同職能都參與產品的全過程
  3. 知識分享：定期的跨職能分享會
  4. 文檔規範：需求文檔使用統一的格式和術語

建立一個「產品詞典」，定義產品中的關鍵概念。新人入職時作為必讀材料。

處理衝突#

衝突不一定是壞事#

健康的衝突：

  • 對事不對人
  • 目的是找到更好的方案
  • 各方都願意傾聽
  • 有最終的決策機制

不健康的衝突：

  • 針對個人
  • 目的是證明自己對
  • 互不傾聽
  • 無法達成結論

衝突處理步驟#

flowchart TD
    A[1️⃣ 確認事實] --> B[2️⃣ 理解立場]
    B --> C[3️⃣ 尋找共識]
    C --> D[4️⃣ 做出決策]

    A -.- A1["各方對事實的理解一致嗎？<br/>有沒有資訊不對稱？"]
    B -.- B1["各方的核心訴求是什麼？<br/>為什麼他們會這麼想？"]
    C -.- C1["有沒有共同的目標？<br/>有沒有都能接受的方案？"]
    D -.- D1["無法達成共識時，誰來決定？<br/>決定後各方都要支援"]

    style A fill:#e3f2fd
    style B fill:#e8eaf6
    style C fill:#fff3e0
    style D fill:#e8f5e9

本章要點#

  1. 協作難在根本：目標不對齊、語言不通、利益不一致
  2. 與產品協作：早期參與、理解為什麼、提供選項
  3. 與設計協作：建立設計系統、前置溝通、明確邊界
  4. 與運營協作：平台化、組件化，而不是被動響應
  5. 優先級決策：用框架評估，學會說「不」
  6. 衝突是正常的：健康的衝突有助於找到更好的方案
Backward 向上與向下溝通 反饋與輔導技巧 Forward