第十章：開發者計畫#

你已經建立了開發者使用 API 或平台所需的基本資源，但這就完成了嗎？很可能還沒有。正如第八章所討論的，引導開發者通過漏斗（funnel），幫助他們認知、熟練、投入並成功使用你的 API，是一個持續的過程。即使是被廣泛採用的 API（如 Amazon 和 Google 提供的常用 API），也需要開發者關係團隊的持續活動。

開發者計畫（Developer Programs）是 API 日常開發者關係與生態系建設的核心。

定義你的開發者計畫#

開發者計畫是幫助並驅動各種規模的開發者建構解決方案、整合你的 API 的活動。大多數公司透過開發者關係與行銷團隊提供多種開發者計畫。要定義需要執行的開發者計畫，你必須進行廣度與深度分析（Breadth and Depth Analysis）。

廣度與深度分析#

大多數開發者生態系由少數大型玩家和大量中小型玩家組成。以行動應用生態系為例：少數大型行動應用開發者（如 Uber、Lyft、Facebook、Supercell 等），以及眾多在較小公司裡開發行動應用的開發者。

開發者（以及開發者計畫）可以沿著兩個軸線來分類：

• 深度軸（Depth axis）：深度開發者受眾指的是使用你 API 的頂級合作夥伴或頂級客戶。你需要花更多時間與這些頂級夥伴合作，讓他們使用你的 API。沿著這個軸線的計畫針對少數開發者，每個開發者對你的生態系影響巨大，但對 API 的需求也很高。
• 廣度軸（Breadth axis）：廣泛開發者受眾由建構在你 API 之上的中小型公司組成，也可能包括基於非專業原因而使用你 API 的業餘愛好者和學生。沿著這個軸線的個別開發者對生態系影響較小，但整體而言對你的業務具有潛在巨大的影響力。

以下各節將更詳細地描述兩種受眾的開發者計畫。

深度開發者計畫#

深度開發者計畫試圖激勵一小群大型客戶或合作夥伴使用你的 API。這些夥伴有時需要大量的工作才能投入。許多 API 和平台提供者都有專門的開發者關係專家團隊，稱為合作夥伴工程師（Partner Engineers），負責與這些頂級夥伴合作，創建 API 的典範級大型應用案例。

頂級合作夥伴計畫#

頂級合作夥伴計畫（Top Partner Program）的目標是：

• 識別 API 的頂級使用者或潛在頂級使用者
• 與他們互動，推動其使用你的平台

這通常從使用案例分析（Use Case Analysis）開始：列出 API 的頂級使用案例，並為每個案例映射頂級合作夥伴。

例如，假設你正在建構一個用於調整大小、濾鏡和其他圖片操作的 API，它接收原始圖片與轉換參數，並回傳修改後的圖片。頂級使用案例可能包括：

• 縮圖與調整大小：網站開發者為商品提供縮圖，讓使用者點擊查看大圖
• 浮水印：開發者在圖片上疊加浮水印，防止濫用或強化品牌識別
• 行動裝置最佳化：行動開發者為行動應用壓縮圖片

針對每個使用案例，按市值（market cap）或其他業務重要標準列出頂級開發者：

若使用案例太多，也可以按產業（industry）進行類似分析：

映射完合作夥伴後，你需要：

• 與每個合作夥伴互動（與銷售或業務開發團隊合作）
• 建立關係並支持他們使用 API
• 提供白手套服務（white-glove activities）：為每個夥伴量身打造支援方式
  • 有些需要大量現場支援
  • 有些需要設計或架構協助
  • 有些只需偶爾提問

這是一對少數（one-to-few）的活動模式，更容易根據開發者需求調整。

Beta 計畫#

在開發 API 的過程中，你需要頂級開發者：

• 採用新功能
• 提供回饋
• 在新 API 功能向一般開發者發布時與你一起上線

與已在使用新功能的頂級開發者一起發布是一種常見的最佳實踐。這向整個開發者群體展示了這些頂級開發者信任並認為你的新 API 有價值。

在 Google I/O、Facebook F8 或其他大型技術活動的主題演講中，每次開發者新功能發布都會伴隨著展示已經使用該 API 實現創新的開發者。這就是早期存取與合作夥伴計畫的成果。

執行良好的 beta 計畫不僅保證了成功的合作夥伴在你發布時同步上線，也確保了上線時的 API 品質更好。Beta 合作夥伴是測試、驗證價值和獲取新 API 回饋的絕佳方式。

對部分加入的開發者而言，你的專案可能是低優先級。這可能導致延遲甚至取消參與。為確保 beta 計畫成功：

• 對 beta 開發者保持高度主動參與
• 設定明確的期望和一致的目標
• 安排多個合作夥伴，不要把所有雞蛋放在同一個籃子裡

設計衝刺#

設計衝刺（Design Sprint）是一個透過設計、原型製作和與開發者一起測試想法來回答關鍵產品問題的流程。在所有可以與開發者共同進行的活動中，設計衝刺可能是最受歡迎且最有效的活動之一，特別適合與頂級開發者一起釐清「在你的平台或 API 之上該建構什麼」。

設計衝刺可以花費幾小時甚至幾天。以下是高層次的步驟：

• 理解（Understand）：與開發者合作，解釋你的 API 能力，讓他們介紹自己的技術。邀請商業利害關係人討論共同的商業目標，邀請共同使用者了解他們的關鍵痛點與需求。將設計、產品和工程代表帶入會議室。
• 定義（Define）：清楚定義要解決的問題。開發者有什麼需求或痛點需要處理？只專注於定義問題，不要著眼於解決方案。
• 發散（Diverge）：每位設計衝刺成員提出六到八個設計方案。安靜地腦力激盪，將每個想法寫在便利貼上。
• 決定（Decide）：分析想法並決定要實施哪一個。可以透過團隊投票，或進行風險效益分析來比較每個方案的困難度與對終端客戶的價值。
• 原型（Prototype）：花時間製作解決方案的原型——可以只是模型圖（mockups），也可以是可運作的原型。關鍵是建構到足夠讓終端客戶能嘗試並給予回饋。
• 驗證（Validate）：邀請終端客戶試用原型並提供回饋；也邀請內部利害關係人做同樣的事。記錄回饋、學習並視需要迭代。

設計衝刺的關鍵好處是能夠快速地朝共同目標合作。雖然需要大量時間和資源，但成果通常很有用，因為它們源自實際問題或需求，並產出經過驗證的解決方案。

設計衝刺還有一個好處：它將許多合作夥伴會議濃縮為一次。

廣泛開發者計畫#

廣泛開發者計畫的核心是規模化（scale）。這些計畫試圖觸及盡可能多的開發者，並推動他們通過第八章討論的漏斗。與深度計畫不同，與開發者的互動不是高接觸的——沒有任何公司有能力親自支持每一位開發者。廣泛計畫使用可擴展的、低接觸的（一對多）工具，如影片、文件、活動和程式碼實驗室來達成目標。

Meetup 與社群活動#

這些可能是最廣為人知的開發者關係計畫。目標是建立一個自我維持的開發者社群，讓開發者彼此教學和支持。

Google 擁有最大的開發者社群之一，稱為 Google Developer Groups（GDG），全球有超過 250 個獨立開發者社群。每個 GDG 社群定期聚會（通常每月一次），舉辦講者分享 Google 技術的晚間活動。許多社群還舉辦黑客松、培訓日和大型活動。

良好社群的一個關鍵價值是：你不需要親自經營每一場 Meetup。你可能需要提供技術內容、食物或贈送獎品和周邊商品，但可以用僅一到三位全職社群經理來經營全球數百場 Meetup。社群經理的職責：

• 物色新的在地志工社群領袖
• 制定社群原則（社群規則）
• 建立社群資源（如網站和 Meetup 培訓材料）
• 與各在地社群溝通以監控其健康狀況
• 在需要時提供支援

不是每個 API 都需要建立自己的獨立社群。你可以向現有社群提供你的內容，特別是當其成員能從中受益時。例如，Unity 是一個遊戲開發平台，可以為 Android 開發者社群的遊戲黑客松提供教學或指南。

黑客松#

黑客松（Hackathon）是另一種非常受歡迎且知名的開發者計畫。黑客松是開發者圍繞特定主題（如醫療軟體）或技術（如 Amazon Alexa skills）進行腦力激盪並開發解決方案的聚會。

黑客松通常持續 24 到 48 小時，期間開發者分組、決定要建構什麼、製作原型，然後在活動結束時向彼此展示成果。

成功黑客松的要點：

• 明確定義結構、時間框架、主題和預期成果
• 提供小組串連工具（如想法試算表）
• 邀請對的人、追蹤報名、收集產品洞察

許多缺乏結構的黑客松會失敗，因為參與者來到活動時不知道該做什麼，或花太多時間在協調而非寫程式。黑客松在時間和資源上成本高昂，若未妥善規劃，管理層可能視之為浪費時間和金錢。

黑客松可以非常大型：Slack 曾贊助一場有 2,000 位開發者的黑客松，與 Lyft、Stripe、Google、Amazon 和 Microsoft 等公司合作。每家公司提供培訓材料、支援工程師和最佳專案獎品。

黑客松的貢獻：

• 提升開發者認知度與熟練度
• 連結 API 產品團隊與廣大開發者
• 收集產品回饋並建立對開發者問題的同理心

活動演講與活動贊助#

許多公司聘用全職的倡導者（advocates）在世界各地的活動中演講。Oracle、Facebook 和 Google 等大公司會舉辦多天的開發者活動，包含數百場議程和培訓研討會。這些活動通常是大規模觸及開發者的有效方式，因為許多議程被錄製下來，在活動結束後被觀看數千次。

如果你是小型新創公司或獨立開發者，創建開發者活動可能非常昂貴且耗時。但在第三方活動中找到演講機會並不困難。

許多演講機會附帶活動贊助協議，可能非常昂貴。請確保你是在接觸正確類型（開發者而非商務人士）和正確規模的受眾，以確保投資回報。記住，有很多社群活動會很樂意讓你免費演講。

培訓者培訓與大使計畫#

此類計畫在各公司有不同名稱：

• Microsoft：Microsoft Most Valuable Professional（Microsoft MVP）計畫
• Google：Google Developers Experts 計畫

無論名稱如何，本質相同：API 提供者聯繫一群非常精通的開發者社群成員，與他們建立特殊關係，使這些開發者成為更大開發者社群中的大使（ambassadors）。

線上影片與直播#

建立圍繞線上內容的計畫，關鍵在於為開發者提供持續節奏的內容。Google 有一個名為 The Developer Show（TL;DR） 的節目，類似於每週面向想要跟上 Google 技術的開發者的電視節目。

建立高端影片計畫可能很昂貴，但你可以考慮使用 YouTube 或 Twitch 等平台進行每月的輕鬆直播節目。在節目中，你只需直播自己在 API 上開發的過程，並回答觀眾的即時問題。例如，Stripe 的開發者關係團隊在 Twitch 上進行其支付 API 的直播，並透過即時聊天與開發者互動。

支援、論壇與 Stack Overflow#

一個有時被忽視但非常重要的計畫是穩固的支援計畫，它回答這個問題：「開發者在使用你的 API 時卡住了，該如何獲得支援？」

不同公司的做法：

• Slack：公司運營的開發者支援——開發者可以透過 email 提問，這會開啟一張 Zendesk 工單，路由到開發者支援團隊
• Twitch：活躍的支援論壇，讓 Twitch 員工和社群成員回答論壇中提出的問題
• Stack Overflow：一個任何人都可以提問和回答程式相關問題的線上平台。社群管理問題並為答案投票，創建高品質、高度可搜尋的問答資料庫。Android 開發者支援計畫就是在 Stack Overflow 上運作，使用其 API 檢索相關的新問題並逐一回答

信用額度計畫#

如果你的 API 需要付費使用，可以考慮為特定開發者提供免費信用額度（credits）。Microsoft、Amazon 和 Google 都有 API 信用額度計畫。

信用額度計畫的要點：

• 通常容易維護和追蹤
• 若 API 免費則無用
• 選擇給予信用額度的正確開發者並不容易
• 信用額度可能被錯誤的開發者濫用
• 目標是給予會隨時間轉為付費客戶的開發者
• 分配方式：有些公司根據公司規模，有些透過新創孵化器分發

信用額度就像金錢：仔細考慮該給誰，以及你能得到什麼回報價值。

衡量開發者計畫#

確定哪些計畫推動了哪些指標、以及它們如何影響你的生態系，可能是你能做的最重要的活動之一。計畫可能有影響力，也可能毫無用處，沒有衡量就無法分辨。對於每個計畫，你需要了解：

• 這個計畫做什麼？
• 預期的投入是什麼？
• 預期的產出表現如何？

以下是部分計畫的衡量範例：

每個計畫有其各自的投入與預期產出，很容易將它們混淆。有些人抱怨黑客松沒有帶來付費客戶，但增加付費客戶根本不是黑客松的預期產出。了解你想對開發者生態系產生什麼影響，然後選擇正確的計畫來推動。

結語#

還有許多其他類型的計畫和子計畫，各有不同的衡量標準和產出。你也可以嘗試無數的實驗性計畫。在 Slack 和 Twitch，團隊曾在歐洲和亞洲進行一系列的開發者巡迴（developer tours），整個團隊一起去見開發者和合作夥伴，並在當地活動中演講。

在建構開發者計畫時，重要的是：

• 映射開發者生態系的現狀和期望狀態
• 啟動幾個實驗性計畫，看看什麼對開發者和你的業務都有效

開發者社群是一個脆弱的生態系，需要關注和支持。傾聽你的開發者，持續改進你的 API、資源和開發者計畫，以符合他們的需求。