InfluxData 的 DevRel 是什么
作者:Anais Dotis-Georgiou / 开发者
2024 年 5 月 21 日
导航至
开发者布道师或开发者关系 (DevRel) 的角色可能既关键又令人困惑。DevRel 作为个人贡献者做什么?DevRel 团队作为一个整体如何运作?
与许多其他公司一样,DevRel 职位的轮廓模糊了技术倡导、社区互动、营销和产品推广之间的界限,使其成为最不被理解但又至关重要的角色之一。这种模糊性不仅突出了该职位的独特性,也给招聘新人才带来了重大挑战。
当我们深入探讨在 InfluxData 担任 DevRel 的意义时,我旨在揭开这个角色的神秘面纱,并阐明其在组织内的重要作用。我还将花一些时间分享我在此职位上学到的一些经验教训。
DevRel 做什么?
当有人问 DevRel 做什么时,我通常会给出一个复杂的答案,例如“DevRel 是代表公司面向社区,反之亦然的人。” 我喜欢这个答案,因为尽管它确实很模糊,但 DevRel 的角色是广泛的。每家公司对开发者布道师的角色都有不同的看法。以下是一些常见的类型/模型
-
技术影响者:一些公司只有一个 DevRel 充当公司的“面孔”。这是一种营销导向的 DevRel。您可以将他们视为“技术影响者”。他们专注于自己的社交媒体粉丝,并为这些渠道制作短视频。他们通常不深入技术细节,而是专注于品牌、信息传递和设计。我不认为这是真正的开发者布道;它更像是一个营销角色。对我而言,DevRel 最好的利用方式是进一步深入销售漏斗,构建技术解决方案和内容,帮助用户解决复杂问题,以便营销团队可以专注于销售漏斗顶端的指标,如浏览量和订阅者。
-
前端/后端开发者布道:其他(通常是规模较大的)团队将 DevRel 工作分为“前端开发者布道”和“后端开发者布道”。在这种模型中,一些 DevRel 创建技术内容、演示和文档。其他人则负责通过网络研讨会、会议等公开分享这些内容。
-
内部产品顾问:一些 DevRel 认为他们应该领导产品规划,并充当整个组织的内部顾问,以帮助整合用户反馈,并使产品与用户的需求保持一致。这些 DevRel 也充当兼职解决方案架构师,并且通常与销售和客户成功工作联系更紧密。他们的工作不是销售产品,而是在销售电话中充当潜在客户的教育者,并利用这些知识来帮助指导产品开发。
-
开发者布道工程师:这些开发者布道师非常“后端”。他们大部分时间都在回答社区问题、查看 GitHub 问题,并根据需要贡献少量错误修复或功能请求。他们通常是高级全栈开发人员,可以根据需要对开源项目的任何部分做出少量贡献。他们也可能为上游项目或其他开源工具做出贡献,以提高互操作性。
-
教育 DevRel:大型 DevRel 团队可能有一些成员专注于与大学以及本科生或研究生进行外联。
-
Meetup/活动和合作伙伴 DevRel:这些 DevRel 花时间为他们的公司组织 Meetup。这包括推广活动、寻找赞助商和演讲者、组织活动和赠品等。他们也可能组织黑客马拉松和其他包容性编码活动,如在线答疑。他们还会花时间发展合作伙伴关系,并寻找与其他组织合作的机会。
在 InfluxData,我们由两人组成的强大团队最接近“前端/后端开发者布道”模型,尽管我们什么都做一点。在我看来,我们在代表公司面向社区方面做得很好,但我们没有太多机会代表社区向公司反馈(稍后会详细介绍)。
认识团队
Zoe Steinkamp 是 InfluxData 的高级开发者布道师。她更像是一位“前端开发者布道师”,在 Influx 工作了五年。她最初是一名前端开发人员,大约在四年前转入 DevRel 领域。Zoe 热衷于进行技术演示并与社区建立关系。她的母语是 JavaScript,但与所有开发者布道师一样,她也会花时间用多种语言进行编码。
我,Anais Dotis Georgiou,是首席开发者布道师,在 InfluxData 工作了六年。我热衷于所有与数学、数据分析和数据科学相关的事物。我的母语是 Python。我专注于创建技术代码示例、博客文章、虚拟网络研讨会和 InfluxDB 大学课程。
InfluxData 的 DevRel 也曾花时间为产品和文档做出贡献、建立合作伙伴关系、组织 Meetup、担任临时解决方案架构师,并参与客户成功工作。但让我们来看看我们今天如何分配时间。
InfluxData DevRel 如何花费时间
我们通常将时间花在以下方面
- 创建技术演示、POC 和代码示例
- 在面对面和虚拟会议上演讲
- 回答社区问题
- 撰写技术博客文章或教程
- 创建 InfluxDB 大学课程
这是 Zoe 和我今年第一季度至今的大致时间分配估算…
技术演示、POC 和代码示例
InfluxData 的 DevRel 团队创建了 InfluxCommunity,一个 GitHub 组织,其中包含多个展示如何将 InfluxDB 与各种其他开源工具结合使用的代码仓库。它也是 InfluxDB v3 的所有客户端库的维护地。
我们独立地、作为一个团队以及与 InfluxData 的其他社区成员或工程师一起贡献演示和代码示例。这些教程的目的是帮助用户开始使用特定的技术栈或用例。我们的目标始终是使入门尽可能容易。我们通过确保我们的演示已进行 Docker 化、利用开源工具或免费版本以及文档齐全(带有 README.md 或随附的博客文章)来实现这一目标。
我们最受欢迎的一些代码仓库(按 GitHub 星星数排名,不包括客户端库)是
- InfluxDBv2_Telegraf_Docker:一个关于如何在容器中运行 InfluxDB v2 和 Telegraf 的示例。
- Plant_buddy:一个演示项目,使用 InfluxDB 平台作为 Flask Web 服务的后端。
- Notebooks:关于异常检测、预测和 InfluxDB 的 Jupyter Notebook 教程集合。
- Telegraf-Community-Configs:一个代码仓库,旨在促进 Telegraf 社区中配置的创建、共享和重用。任何人都可以提交新的配置或对现有配置的改进,并在他们自己的架构中使用它们。
- Quix-anomaly-detection-example:这个项目提供了一个如何使用 Quix 和 InfluxDB 3.0 构建机器异常检测数据管道的示例。
我们还有一些代码示例,展示了如何将 InfluxDB 与以下技术结合使用
- 数据工程和流处理:Kafka, Minikube, Quix, Mage。
- 可视化:Grafana, Superset, Tableau
- 物联网:HiveMQ, OpenTelemetry, MQTT, OPC UA, RabbitMQ
- 数据分析和数据科学:Pandas, Spark, Polars 以及各种用于异常检测和预测的 Python 库
今年,Zoe 和我贡献了
- 快速入门教程,用于消费 MQTT 数据和利用 Kafka
- 一个飞行演示,展示了如何使用 Python、InfluxDB 和 Grafana 准备、摄取和可视化空中交通数据
- 一个教程,关于准备时间序列数据并将其转换为向量,以便向量数据库摄取,从而执行相似性搜索和异常检测
InfluxDB 被广泛应用于各个行业和用例。好奇心是任何 DevRel 都需要的,尤其是在 InfluxData 的 DevRel,因为我们不断学习新的技术栈。
面对面会议和虚拟活动
开发者关系的一部分是技术推广。这意味着在面对面会议和虚拟活动中分享这些技术演示。这也意味着提交 CFPs、申请参加 Meetup 以及在会议上执行展位职责。这项工作的一大亮点是与人们面对面交流——从用户、客户和合作伙伴到我们自己的 Influx 员工。到目前为止,今年 Zoe 参加了世界各地的七次会议,但在她作为 Influx 的 DevRel 的三年里,她曾以各种身份去过 34 个城市和 14 个国家。
Zoe 和我还主持了 15 场网络研讨会,主题涵盖“InfluxDB 基础知识”到“利用时间序列数据库和 OpenTelemetry 的力量”。我们在 InfluxData 网络研讨会、虚拟会议和 Conf 42 和 DBTA 等网络研讨会上发表演讲。感谢营销团队帮助我们找到可以申请的会议并赞助网络研讨会!
回答社区问题
在 InfluxData,回答问题是角色中的关键部分。在 InfluxData,我们主要监控我们的 Slack 和社区论坛(尽管我们也回复在 Reddit 和 Twitter 上发布问题的人)。社区问题是 DevRel 了解用户遇到的障碍类型以及我们产品的优势和局限性的绝佳方式。
- 了解用户遇到的障碍类型以及我们产品的优势和局限性。自然而然地,您也将成为 InfluxDB 和 Telegraf 方面的专家。
- 您会收到各种语言和各个领域的问题——从 C# 到 JavaScript,从 Arduino 问题到 CISCO 网络问题,再到特定预测问题的算法选择问题。您最终也会成为各种其他工具的专家,例如 Grafana 或 Pandas。
- 从技术演示或书面内容中获得灵感。当我们看到用户反复提出类似问题时,我们就知道是时候制作关于该主题的内容了。
- 与社区成员建立关系。我们得以连接从事类似项目的不同社区成员。我们还找到了让社区成员通过网络研讨会或社区贡献的博客文章与更广泛的社区分享其项目的机会。
今年,我们已经在论坛和 Slack 上回答了 600 多个问题,我们参与社区活动促成了与以下公司的合作关系和内容合作:
- Drona
- JetBrains
- Quix
- Mage
我们也非常幸运能有一个文案团队来校对,确保我们的书面内容符合品牌形象,并为我们处理发布和分发事宜。
技术博客文章
今年,Zoe 和我已经在 InfluxData 博客和外部博客上贡献了 12 篇博客文章。它们包括关于以下主题的技术教程:
我建议您查看 Nick Groenen 关于“4 种类型的技术文档”的文章,以了解存在的技术内容类型以及每种类型的用途。向 Influx 的文档团队致敬,他们创建了出色的参考和解释文档。
创建 InfluxDB 大学课程
最后,InfluxData 的 DevRel 团队创建了八门 InfluxDB 大学课程。InfluxDB 大学提供免费的、实时的、自定进度的培训,以帮助您获得技能并快速入门。今年,我们创建了关于 InfluxDB v3 客户端库、InfluxDB v3 中的任务、Telegraf 等课程。在此处查看完整的课程目录。非常感谢营销团队帮助编辑和包装我们交付的内容,使其成为完整的课程。没有他们,我们无法完成这项工作。
好的、坏的和丑陋的…
事实是,DevRel 可能负责很多事情。通常,DevRel 的工作量过大,以至于一部分开发者布道工作被忽视。以下是我作为 InfluxData 的 DevRel 学到的一些经验教训。
代表社区向公司反馈
作为一个两人团队,我们没有足够的精力来担任内部顾问,也无法真正地将我们从社区获得的反馈转化为产品改进。过去,我们更加注重将每个社区问题分类为功能请求,以使用 Product Board 促进数据驱动的产品开发方法。 Product Board 具有与 Slack 和社区论坛轻松集成的功能。
然而,仅仅是仔细地组织社区问题和创建功能请求就可能是一项全职工作。在我们尝试这种方法时,InfluxData 的团队也很小,我们发现以如此精细的程度整合社区反馈是不可持续的。我们在将社区反馈转化为产品方面目前也做得不够。这主要是因为我们尚未发布 InfluxDB v3 OSS 版本(但这目前正在进行中!)。
Meetup、黑客马拉松和在线答疑
创建 Meetup 和组织黑客马拉松也很具挑战性。组织线下活动非常耗时且成本高昂。如果您决定将组织活动作为开发者布道工作的一部分,我建议您确保公司在 Meetup 的覆盖范围或可接受主题上达成一致。确保其范围足够广泛,以便您可以继续吸引各种有吸引力的演讲者。
我见过的表现良好的 Meetup 通常围绕行业领域或语言,例如数据科学 Meetup、Python Meetup 或数据 Meetup。预计会邀请人们展示竞争对手的解决方案,并专注于促进跨组织的教育和社区,而不是将其用作直接营销的工具。如果您的团队规模较小,我建议您申请成为 Meetup 的演讲者。我发现这样做更成功。只需联系 Meetup 组织者,并分享您可以做的相关演讲列表即可。
我们过去常常在 YouTube 上主持在线答疑,但在直播结束后观看次数明显更多。我们观察到,开发人员在解决问题时通常更喜欢异步工作。如果您无法异步解决问题,我建议您主动提出与某人进行虚拟会议。我们在线答疑遇到的问题是,开发人员通常会在社区中遇到问题时立即发布问题,而不是等待预定的时间。与等待每周的在线答疑相比,他们发布问题并获得答案的平均响应时间也更快。
高等教育推广
我希望我们有足够的带宽来关注这一点,尤其因为我已经与许多将 InfluxData 用于他们研究生研究的社区用户交流过。也许有一天我们会实现。
结论
目前,团队专注于利用 InfluxDB v3 提供的互操作性,并寻找专门构建的解决方案来替代 InfluxDB v2 中存在的一些功能。我们试图将 InfluxDB 打造成适用于您的 IoT、流处理、警报、ETL 和数据分析工具的一站式商店的日子已经一去不复返了。
相反,我们希望教育社区如何利用合适的工具,为他们的特定用例构建定制的技术栈。这意味着学习如何将各种其他工具与 InfluxDB 结合使用,并创建技术演示来解决不同领域的问题。
我们将继续从社区汲取灵感,并利用这些互动来指导我们的工作。我们将继续通过线上和线下的演示分享工作成果。一如既往,请从InfluxDB Cloud 3.0开始使用。如果您需要帮助,请联系我们的社区网站或Slack 频道。