越來越多的開發者服務公司投入重金，圍繞自己公司產品、服務、API等在組建自己公司的DevRel團隊。
但是，不同的公司對DevRel有著不同的理解：有的僱傭專職 「技術推廣的工程師（Developer Advocate）」；有的僱傭 「技術佈道師（Developer Evangelists）」; 有的認為DevRel就是「針對開發者的市場行為」；也有人把 DevRel 當作獲取產品的反饋、推廣產品成功的關鍵。如何來判斷什麼樣的崗位角色、活動形式對你的公司是最合適的呢？不同的崗位稱呼到底有什麼區別呢？
「開發者關係」對於公司來說到底意味著什麼呢？這取決於公司對目標是什麼。為了說明情況，讓我們來引用一下Google和Twilio的DevRel部門的使命，但是，注意一條簡短的語句未必能夠呈現DevRel團隊實際做的全部事情。
開發者關係的角色，是通過雙向溝通開發者和公司的平台產品、工程、設計，來創造一個充滿活力的第三方開發者生態系統。
Twilio
我們的工作是激發和幫助開發者建立下一代令人震驚的應用。這意味著要理解他們正在努力想要做什麼，給他們指明工具並進行培訓，以及幫助他們取得成功。
Google 使用「the interface between」詞眼。表明DevRel期望的是建立產品決策者和開發者（即產品使用者）間的一個雙向溝通橋樑。Twilio的態度表明DevRel更像是一個單向的「教育的角色」，幫助開發者使用Twilio產品。
Michael Mahemoff最近寫了一篇Developer Relations: A Five-Level Maturity Model. 在這篇文章中他闡述了一個公司DevRel部門發展的不同階段。從沒有DevRel部門到可以完全量化策略的價值。
針對在「如何制定本公司的DevRel策略」 的情境下，我需要對Michael的定義做些調整：
- 無（None），公司內部沒有支持開發者 或 收集開發者反饋的機制；
- 不正規（Informal），由公司其他部門 承擔 DevRel 的部分角色，PR 負責公司品牌的提升、BD 承擔部分支持開發者任務，而產品的專職開發者卻也要承擔部分社區演講；
- 合作夥伴（Partnerships），和珍貴的合作夥伴間的關係，通常比較隱蔽 （通常是大公司、擁有足夠資源來構建新的產品特性）；
- 佈道師（Evangelism），通過會議、合作夥伴、在線媒體來大規模提升、支持公司產品；
- 技術推廣工程師（Advocacy），一種雙向的關係，不僅為參與產品的開發，也鼓勵外部開發者使用本公司產品、收集bug反饋及新特性請求。同時，開發支持工具來提升開發者的使用體驗；
根據以上分析，總結：Twilio是以「技術佈道師」的方式來運營DevRel，而Google是「技術推廣工程師」的方式。
Michael指明：DevRel正確的運營方法取決於公司對於DevRel項目的目標。比如，如果一家公司僅僅是期望品牌知名度的提升、或者參加少量的活動來減少開銷，那麼該公司應該採取「技術佈道」的方式來運營DevRel。如果優先考慮從第三方開發者收集產品的使用反饋的話，採用「技術推廣」的方式也許效果最好。
總之，投資DevRel對於公司的各個業務都有促進作用。所以，你策略的目標是什麼，就顯得尤為重要了。Dave McClure的AARRR模型可以用來作為指導DevRel策略的基石。
然而，我建議我們稍做兩個修改：
因為DevRel可以增加開發者們對一個產品的認知度，根據傳統的營銷習慣，在AARRR縮寫前再增加一個’A’；
在DevRel團隊日常活動中可能會涉及到開發者們對產品的反饋，為了表明這一點在AARRR縮寫後面增加一個’P’；
這樣話就產生一個新的模型：AAARRRP模型。與其僅僅把這個當作DevRel指標，不如把它們當作你DevRel項目的潛在目標（雖然’如何來度量這些指標’也需要去考慮的，詳見：What’s the ROI of Developer Relations）:
- 認知度（Awareness）產品平台的認知度
- 獲取 （Acquisition）註冊量、下載量、安裝量
- 激活 （Activation）平台使用的活躍度
- 留存 （Retention）持續使用平台、使用新的特性
- 盈利 （Revenue）為平台的付費
- 自傳播（Referral）把平台告訴其他人
- 產品（Product）涉及到構建和收集產品的反饋
在DevRel日常運營中有各式各樣的活動形式。每種類型的活動都與之對應一個或多個 DevRel的指標，從而實現一個或多個AAARRRP目標，比如：
| 寫文檔（參考案例、入門指南等） | 獲取、激活、產品 | |||
| 庫開發 | 激活、產品 | |||
| 快速啟動應用 | 激活、產品 | |||
| 博客文章（教程、黑科技、思想領導力等） | 認知度、獲取、激活、留存 | |||
| 網絡研討會 | 認知度、獲取、激活、留存 | |||
| 活動贊助（Meetup贊助商、大會展位等） | 認知度、獲取 | |||
| 演講（Meetup、大會、社團等） | 認知度、獲取 | |||
| 產品支持（Zendesk、StackOverflow、其他論壇等） | 激活、留存、產品 | |||
| 售前技術討論（電話、郵件、支持等） | 獲取、激活 | |||
| 專用論壇（Google Groups、Discourse等） | 激活、留存 | |||
| Alpha/Beta程序 | 留存、產品 | |||
| 辦公時間 | 激活、留存 | |||
| 收集開發者反饋 | 留存、產品 | |||
| 幫助公司招聘 | 認知度 |
成功保證這些行為的結果將對開發者有著積極意義，公司的聲譽將得到提升。這樣的話有提高「自傳播」的可能性。但是，開發者和公司間這樣的關係，需要花時間來構建。
盈利：顯然從上述的行為中省略了。盈利取決於開發者使用產品的程度。因此，非常依賴產品價格結構。因此，盈利，不能簡單的添加到上述的列表中，但是，可以確定的是：暫時不考慮盈利的話，可以讓你更加專注於很有可能帶來大量的ROI的活動及目標開發者。
儘管我個人不認可通過職位Title來定義一個人，而是，職位Title反應了公司或者其他開發者對於他在DevRel團隊中的角色定位。
因此，基於常見的職位Title，來看看不同的角色參與什麼樣的活動？
技術推廣工程師（Developer Advocates）：承擔上述大部分職責作為DevRel工作的一部分，尤其是與產品或留存相關的職責；
技術佈道師（Developer Evangelists）：也許更加專注於用戶的獲取相關的活動，比如：寫文檔、發布博客、贊助活動、演講。查看更多和「認知度」和獲取相關的活動。
| 總結
如何來定義DevRel ? 以及那種方式是對你公司最適合？下面是我的建議：
- 根據 AAARRRP 模型 來制定出你對 DevRel 團隊期望的目標；
- 選擇與這些目標最匹配的活動形式；
- 根據這些活動形式，可以確定招募技術推廣工程師（Developer Advocates）還是技術佈道師（Developer Evangelists）；
作為另外一種幫助我自己的方式，或至少是建議。針對這種持續的關於職位Title的爭論，我創建了一個DevRelOMeter的項目——根據你期望DevRel團隊開展的活動類型，會建議你進行技術佈道還是技術推廣？
| DevRelOMeter
您是否在參與或者考慮參與到開發者佈道這個事業當中來呢？
https://leggetter.github.io/devrelometer/
作者：Phil Leggetter
原文：Defining Developer Relations
編譯：Jack Jin
轉載請註明：開發者關係 »
