从零设计开发者关系项目战略：用一页 DevRel…

当有人问是否该做 DevRel、新项目先做什么、为什么忙却没效果、如何向高管论证、下一个该投哪个支柱或招谁时，用访谈+章程的方式产出一份能通过预算评审的战略文档。

适用场景

解决思路

1. 先做访谈，一次只问一个问题，尽量给多选项；一旦能说出资金来源、公司阶段、真实产能和问题 12–14 的答案就停止，其余边做边确认。
2. 访谈必问 14 项：1) 产品是什么、开发者实际怎么用（调 API、装库、跑基础设施、扩展平台、学方法）；2) 购买中开发者是用户、决策者、两者还是都不是，谁签字；3) 公司为什么出钱（开发者采用、销售赋能、开发者赋能、产品输入、生态与伙伴、贡献者社区、雇主品牌），出资方会先说哪个；4) 项目阶段（无人做、一人兼职、小团队、多个专业团队）；5) 今天谁在做 DevRel 类工作（创始人、工程师、支持、市场），每周真实投入多少小时；6) 已有什么（文档、quickstart、社区场所、博客、OSS 项目、活动、champion）；7) 出资高管在两到四个季度内用自己的话期望看到什么；8) 试过什么没效果、团队认为原因是什么；9) 禁区（不出差、不投付费广告、受监管的声明、竞争对手社区、创始人拒绝的渠道）；10) 未来两个季度的变化（发布、定价、融资、开源、品牌重塑），计划要对齐什么；11) 谁拥有预算，该数字是否含团队薪资还是仅项目支出；12) 第一个结果最晚何时对谁可见（董事会、发布、续约、预算评审）；13) 出资方要本周期内的一次性胜利，还是主要从明年开始回报的复利资产；14) 投入上限——已有其他工作的人每周能投入的小时数、实际能加的人头、承诺必须多可逆。
3. 绝不跳过问题 12–14：一个季度内的截止日期会提升 enablement-first 并删除 agency 管线（其公开的搭建延迟约六个月）；“复利资产”会提升 community-first 和 contributor-first；由已有其他工作的人挤出时间的产能上限会删除所有需要常设岗位的形态。
4. 必问问题 11：预算归属是目标选择的名义输入；《State of Developer Relations 2024》（DevRel.Agency，310 名受访者）显示 60% 的项目预算不含薪资，33.5% 的从业者根本说不出预算。
5. 记录答案；若运行环境有持久记忆就存入：资金来源、阶段、受众优先级、拒绝清单、截止日期、一次性 vs 复利授权、产能上限。
6. 区分两类数字：可自由引用并注明出处与样本量的调查数字，和本技能自设的基线；把自设基线伪装成行业标准是最快失去高管信任的方式。
7. 可引用（注明出处与样本量，来自《State of Developer Relations 2024》，310 名受访者，2024 年 9 月发布；若有更新版优先用新版）：团队规模 2–5 人最常见占 35.2%，单人从业者 18.2%，69% 的团队少于十人；33.5% 说不出预算、17.8% 没有设定预算；43.6% 报告有多个团队做 DevRel 工作；预算方向 29% 增加、24% 持平、24% 减少。
8. 仅作历史引用、绝不作目标：同一调查的支出拆分（活动 41.1%、薪资 30.9%、内容 19.5%、市场 13.0%）——只有 47 人看到该问题、占比合计 104.5%、类别遗漏社区/工具/教育。
9. 明确标注为本技能自设基线：产能上限、支柱数、目标数、下注数、叙事长度；说“起始基线”，情况有理由时就移动它。
10. 第 1 步：先做 CORE 情境分析（Matthew Revell，developerrelations.com，2016），每个象限写一段——Community（谁在用/贡献、在哪聚集、参与度、阻碍）、Organization（与产品/市场/工程的内部对齐、资源、谁决策、以前试过什么及结局）、Relationships（合作者、竞争者、依赖方、各自被如何看待、目标是否一致）、Ecosystem（技术格局、竞争集合、开发者在其中把你放在哪）。
11. 命名答案所暗示的生命周期阶段：starting、growing 或 established；在这四段存在之前拒绝提出支柱、招聘或渠道。
12. 第 2 步：说出受资助的驱动因素（Revell 的七项之一：开发者采用、销售赋能、开发者赋能、产品输入、生态与伙伴、贡献者社区、雇主品牌），用出资方的语言说明哪个是主要、哪个是次要；若答案是“全部”，说明这是赞助人问题而非战略问题。
13. 用 AAARRRP（Phil Leggetter，2016）把驱动翻译成目标：awareness、acquisition、activation、retention、referral、revenue、product；只选两个主要目标加一个次要，并把每个目标定位到开发者旅程的具体步骤（初始认知、深度认知、评估、承诺、标准化、倡导）上当前流失的位置。
14. 没有可观察流失的目标只是偏好；声称全部七个目标的项目没有战略，因为所有候选活动得分相同。
15. 第 3 步：宣布进入头脑风暴模式，先不写计划；把选定目标铺到四个支柱（developer advocacy、developer marketing、developer enablement、developer community）上，构建两到三个整项目候选，绝不只做一个；从 references/program-archetypes.md 取阶段与驱动原型、投入及其放弃的东西。
16. 排序前先过滤：只保留受资助驱动契合的原型，然后删除被答案排除的——路线图已锁定一年则删 product-feedback；拒绝自建场所则删 community-first；代码库无法吸收外部改动则删 contributor-first；要从候选集中删除而非排到最后。
17. 按效率排序：enablement-first > product-feedback > evaluation-support > reach-first > community-first > contributor-first；按价值排序：enablement-first > evaluation-support > community-first > reach-first > contributor-first > product-feedback；按投入排序：product-feedback > enablement-first == evaluation-support > reach-first == community-first > contributor-first。
18. 解释两个并列：enablement-first 与 evaluation-support 投入相当（约一个人四分之一的写作时间）且都留下比项目更长寿的产物，同样可逆；reach-first 与 community-first 都是常设岗位，节奏一停当月就没有产出。
19. 对每个幸存候选呈现同样六件事：过度投入的支柱、资助的前三个下注、刻意饿死的部分、所需产能、起效的最快信号、使其成为错误选择的条件；推荐排名最高的幸存者并说明理由，然后让项目负责人选择后再细化。
20. 当驱动是贡献者社区或既有用户群的留存，或问题 13 答“复利资产”且周期超过本周期时，仍可提升 community-first 或 contributor-first 为主要并饿死高效形态；以常设岗位四分之一投入的社区是唯一比不开始更糟的投资。
21. 按执行者重新排序：已有内容引擎的团队已付过 reach-first 的常设成本，reach-first 升到首位；本季度就要数字的出资方把 community-first 和 contributor-first 移出列表；单人团队只保留前两名。
22. 第 4 步：设定受众优先级，选出本周期首要服务的细分并说明暂不服务谁；区分两条采用路径——个人开发者采用（开发者独自发现、试用、决定；投可发现性、首次成功时间、同行证明；成功表现为先于收入的用量）与公司采用（开发者评估但经理、架构师、安全评审或采购批准者决定；投批准者可读的评估材料：参考架构、安全与许可清晰度、迁移与支持路径、具名生产案例；成功表现为通过评审的评估）。
23. 两条路径不设效率排序：路径由谁签字（问题 2）决定而非服务成本；多数项目两者都面对，本周期只选一条而非平均分配，并说明哪些产物同时服务两条路径以便只建一次；深度细分交给 samber/developer-relations-skills@developer-segmentation。
24. 第 5 步：对每个受资助下注决定自建、外包个人、代理机构还是社区来源；partner/sponsored 不在菜单上（它买的是位置和接触而非产出或信任），在 samber/developer-relations-skills@developer-event-sponsorship 决定；用 references/build-vs-buy.md 查各能力表、红线与隐性成本。
25. 按效率排序：contractor > in-house > agency > community-sourced；按价值排序：in-house > community-sourced > agency > contractor；按投入排序：contractor > agency > in-house == community-sourced；按合规成本排序：in-house == contractor > agency > community-sourced。
26. 对照表：contractor 首次产出前约一小时简报、约一周交付，买一次性细分深度，随合作结束而终止；in-house 是常设岗位，买可信度与留在团队的知识，一次离职就全停；agency 约需负责人六个月自建管线、之后每篇八到九周，买超过搭建期的量，系列可干净停止、无衰减；community-sourced 是招募、评审与认可的常设岗位且需已有密度，买内部无法产出的同行证明，已合并的贡献无法取消许可。
27. 解释两个并列：in-house 与 community-sourced 投入并列，因为都是常设岗位（一个付薪资、一个付招募与认可），人一停当月就停产；in-house 与 contractor 合规并列，因为都是 work-for-hire，权利问题由雇佣或合作合同回答，无需单独评审。
28. agency 需一次合同评审处理权利转让与署名披露，续约时重开；community-sourced 需在首次贡献前就位的贡献者许可或 DCO 决定，是本页最不可逆的承诺。
29. 两条覆盖排序的规则：把判断与声音留在内部——技术取舍、倡导者署名、事故沟通、审核决定、任何关于产品局限的声明，这些正是开发者受众检查真实性的表面，没有菜单，其他三个选项直接删除而非排最后；租量不租可信度——按 Matt Jarvis（Snyk 开发者关系总监，developerrelations.com）的唯一公开案例，倡导者写大纲并审结果，代理机构产出正文。
30. 当 community-first 或 contributor-first 已是受资助的主要方向时提升 community-sourced：密度已付费，此时它是唯一产出增长而无需每单位新增常设岗位的选项。
31. 按执行者重新排序：本季度就要首个结果则直接删除 agency（六个月管线搭建装不进窗口）；无预算线的单人团队只有 in-house 和 community-sourced；已有编辑团队在薪资单上的公司实际上已预付 in-house 那一行。
32. 第 6 步：从第 2 步发现的摩擦推导人员序列，绝不用标准团队模板；阶段词汇用 Leggetter（2021）——Seed：一个通才，常是先兼职后转人头，资助一个高影响项目并在加第二个前完成；Grow：只有当通才的队列成为瓶颈时才专业化，按仍漏水的旅程步骤拆向 developer educator、community manager 或 advocate，并警告 Leggetter 指出的代价：除非能继续在专长外贡献，否则可能失去喜欢当通才的人；Scale：按此顺序加杠杆而非人头——champion and ambassador programs > community-run events > paid write-for-us pipelines > contributor programs，并守住 Leggetter 的检验：只有进一步投资使产出增长多于投入增长才算在扩展。
33. 说明杠杆顺序的理由：champion 项目认可已在倡导的人，放大你拥有的资产；contributor 项目最后落地，因为它消耗无人能补位的维护者时间；每一个仍消耗内部评审，而这通常正是杠杆本想缓解的瓶颈。
34. 只说明下一个招聘及其触发条件，不要十二个月组织架构图；汇报线、角色比例与团队拓扑交给 samber/developer-relations-skills@devrel-team-structure。
35. 第 7 步：按模板写章程并逐节验证——# DevRel charter: <company>, <horizon>，含 Position（CORE 摘要、生命周期阶段、自上次以来的变化）、Driver（受资助原因，用出资方的话，及其负责人）、Goals（2 主要 + 1 次要，各钉在旅程步骤上）、Audience（主要路径与细分；暂不服务谁）、Pillar mix（投入去向，刻意饿死哪个支柱）、Bets（3–5 个下注：服务目标、负责人、信号、评审日期）、Build vs buy（每个下注，含延迟与搭建成本）、Staffing（下一个能力、触发条件、当前阶段）、Refused（本周期不做什么及原因）、Open questions（会改变计划的未知项、谁解决、何时解决）、Exec narrative（出资方无需你就能复述的五句话）、Review（重新决策节奏及什么会迫使提前重审）。
36. 一次呈现一节并在写下一节前取得同意：在第二个标题发现错误驱动只花一段，在第十个才发现要花整份文档。
37. 诚实填写“Open questions”而非掩盖缺口（未测量的流失、未具名的赞助人、没人能说出的预算）；隐藏未知项的章程会在它本要挺过的评审上被伏击。
38. 按质量门迭代直到通过，并在结尾明确报告检查结果，说明哪些是结构性、哪些是你移动过的基线。
39. 结构性检查（任一不过即不完整、无可商量）：驱动是一个具名原因、一个具名负责人、用出资方的话表述；每个目标命名一个旅程步骤和一个观察到的流失而非偏好；每个下注恰好追溯到一个主要目标并带负责人、一个信号和评审日期；拒绝清单非空且至少含一件团队想做的事；未知项被写下而非靠假设解决；可信度表面上没有任何外包；高管叙事不用 DevRel 行话。
40. 数值检查（本技能自设、无公开研究支持、可有意移动并说明理由）：承诺不超过申报产能的 70%，其余吸收支持负载、发布与计划外事项；seed 或 grow 阶段最多两个支柱获得超过象征性投入；最多三个目标（两主一次）；每个周期三到五个下注；高管叙事五句话。
41. 失败于产能线的章程不是纪律问题，而是多了一个下注；哪个数字证明项目有效是另一个决定（见 samber/developer-relations-skills@devrel-metrics），这里只承诺每个下注一个信号以保持战略可证伪。
42. 避免常见失败模式：照搬大公司项目（其支柱组合预设了你还没有的杠杆项目和品牌，应从 CORE 推导）；把活动清单当战略（没有驱动支撑的演讲、文章、活动日历只能挺过一次预算评审）；服务所有目标（七个目标让所有活动得分相同，投入跟着谁喊得响走）；外包声音（代理机构代写、倡导者署名的内容很快被识破，损失的可信度超过内容所得）；重组而非重划范围（未达标的项目通常是资助了太多支柱而非组织架构错）；衡量点击而非人（没有开发者行为支撑的触达数字过不了高管第一问）；把小样本均值当基准引用（流传的“DevRel 41% 花在活动”来自 47 名受访者、合计 104.5%、类别遗漏社区/工具/教育；只作历史引用，绝不作目标）；忽视实践走向（DevRelCon New York 2025 议程把 agent-readable documentation、测量素养、少花钱多办事放在中心，活动与周边在衰退）；没有拒绝清单（每个想法每季度被重新争论，投入重新摊开）；驱动因素的负责人离职（赞助人变更时在预算评审前而非后重跑章程）。
43. 若可浏览网页，先查 Developer Relations Foundation（dev-rel.org，由 Linux Foundation 托管）的 Metrics Index 和 Maturity Model 作为领域唯一厂商中立参考；读实际发布的内容而非假设有分级模型——Maturity Model 可能只定义目的而无级别，除非级别确实存在否则不要当作分级呈现。
44. 与兄弟技能衔接：samber/developer-relations-skills@devtools-business-model（前置，定义收入模型，约束第 2 步驱动选择）、@developer-first-gtm（前置，先定采用动作）、@developer-journey-map（交接，映射完整旅程，本战略把目标钉在其步骤上）、@devrel-metrics（交接，定义每个下注信号的测量框架）、@devrel-team-structure（交接，在序列与下一招聘确定后设计组织拓扑）、@devrel-budget-allocation（交接，按本战略命名的支柱分配资金）。

适用边界 · 注意事项

• 不适用于制定前 90 天计划——那用 samber/developer-relations-skills@developer-relations-kickoff。
• 不适用于指标、组织架构图或预算算术——分别交给 @devrel-metrics、@devrel-team-structure、@devrel-budget-allocation。
• 不产出演讲、文章、文档或活动本身，只产出决策与章程。