非开发者如何成为优秀的技术布道者

问：“搭建开发者社区的工作一定要由开发者来完成吗？”

这样的问题，我已经听过无数次了。这个问题会出现在每一个社区群组中，而提出这个问题，通常都是那些想要在科技行业闯出一片天地，但是自己又没有技术背景的人。他们不确定自己能否在科技行业生存下去。

我一行代码都没有写过，而我却成功成为了 Estimote 的社区布道者。我们是一家专注于移动开发者的初创企业。一路走来，我学到了许多经验，所有以社区运营为职业的人，都会觉得这些经验非常实用。我们都在以产品为中心，召集更多的开发者，我们不仅可以使用这些经验，还可以一起对它进行讨论、推广，并且不断的做出更多贡献，让经验越来越丰富。以产品为导向的社区，就像是蜂巢一样，所有人都在为一个共同的目标贡献自己的力量。大多数时候，我们的工作重点其实并不是技术自身。

我也并不是唯一一个非技术专业出身的例子，就连 SendGrid 和 Twilio 这样以打造开发者社区而出名的企业，其社区团队中也有非开发者出身的成员 (hi Tim, hi Lisa!)。

我们就再来讨论一次这个问题：要想搭建开发者社区，你自己必须是开发者出身吗？

不，但是你要学会像个开发者一样思考

就算你不会用代码进行思考，但是你应该学着像开发者一样思考。

从事任何职业的人，都有自己的习惯、术语以及看待世界的特别方式。你的任务是要打造一个能让开发者感觉到宾至如归的地方。当然，任何一名开发者都有自己的特性，但是你见过的开发者越多，你就会发现越多他们的共同点。他们总是会说着同样的东西，比如 pull request、forked repos 和 API tokens 等。没错，你需要学习这些东西。不要给自己找借口逃避。

很多开发者都非常痴迷于效率。他们脑子里想的都是系统、辨识规律，以及对各种问题都进行详细的分析。

这样的描述有点太空泛了？没错。在一定的数量级内，这个描述是准确的。但是如果有人跟你说，他能用几句话解释开发者（或是设计师 / 记者 / 建筑工人）的思考方式，请你一定不要相信他。

学习开发者的思维模式，没有任何捷径可循。唯一的方式，就是与开发者进行对话。

和公司内的技术团队一起吃饭，参加他们的会议，关注 Slack/HipChat 频道的新动向，与负责用户反馈的人一起进行讨论。你也可以在公司外部寻求学习的机会，例如参加你所在城市内举行的科技大会，在 tack Overflow 上关注与你社区有关的话题标签。

一些话题你可能完全不理解，例如“你创建过的最复杂的 C 语言代码是什么？”。你其实并不需要把这个问题理解的过于透彻，在阅读的时候，你只需要看着别人讨论的细节，从中找到快乐。这些做法都能让你成为一名更好的社区运营人员以及技术布道者。

不，但是你需要了解产品

所有社区的核心都是人。但是开发者社区的核心除了人之外还有产品。开发者社区凭借特别的工具或是目的，将开发者吸引在一起。就算你不能成为使用这些工具的专家，你也应该要成为解释它们的专家。

你可以阅读一些成功的故事，以此来了解那些最佳的实践，以及开发者在哪些情境下会使用你的工具：如果你所在的公司还没有发布这些内容，你可以请客户成功团队 / 商业开发团队 / 其他社区的运营人员和你进行分享。你还要了解产品的演变过程：查看旧帖，并且阅读产品的更新日志。

了解了产品和用户，你就可以展示相关的案例研究，回答一般性的问题，并且鼓励人们通过自己写内容来为社区做出贡献。鼓励其他人做出贡献，是最为重要的一点。当社区的成员感觉到你在乎他们时，他们就会为你的工具写指导、针对你的产品安排聚会。如果你的产品是开源产品，他们甚至还会帮你修复 bug，他们会皈依你的产品信仰。

如果确定自己是否已经足够了解了公司的 SDK 和 API？比较好的方式之一，就是看看当一个人在部署某个产品功能遇到问题的时候，你是否可以告诉他在产品说明文档的哪一页可以找到答案。这意味着，即使你自己不会使用产品，你也已经熟悉了产品，并且知晓问题的根源处在哪里。很明显，如果你能够做到这一点，足以证明你不是在凭运气解决问题。软件一直在改变，尤其是在这个所有人都在强调敏捷和每日更新的时代。也就是说，你之前所学的，也会马上过时，因此你需要不断学习。

在 Estimote 内部，我们建立了两周一次的“stack review”活动：开一个简短的会议，确保每一个人都学习了最新一次的产品 Release。这个会议最多只需要 20 分钟，但是它能让我们确保每一个人的步调一致。

由于软件产品的变化速度快，因此当你不理解或是不记得某些东西的时候，不要灰心。一个公司内，就算是开发者也无法全部搞清产品的所有细节，即使产品是他们自己开发的，没有什么可自卑的，软件产品过于复杂，一个人不可能凭脑子记住巨大的代码库。当你遇到问题的时候，你只需要让自己知道该向谁请教就好。

如果你所在的公司使用了 Confluence 或是 Asana 这样的协作工具，你应该为产品维护一个带有技术细节说明和 FAQ 的文档。

如果你公司没有使用协作工具，你可以使用 Google Doc。要注意的是，一定要有专人负责对它进行更新。过期的文档比没有文档还要糟糕。

不，但是团队中需要有开发者

在面向开发者的领域内，任何社区团队都必须要有一名开发者。起初，我们的团队并没有全职的开发者。这样的模式维持了一段时间，我们在世界范围内的活动内维持了一定的曝光量，我们不断地改善内容，并且提供了高质量的客户服务。

但是我们马上就遇到了瓶颈。我们支持黑客马拉松活动的能力有限。再编写技术性内容的时候也感到力不从心。那些困难的支持请求会拖延好几天的时间，因为团队优先处理 shipping 问题，然后才轮到 troubleshooting，这部分支持请求占全部请求的 10%。

在我们找来了会写代码的技术布道者之后，整个团队都变得更有效率了：客户支持、内容、活动、反馈收集、开发者关系等，我们在社区眼中变得更加主动、可接近。

给团队配备一名具有专业能力的成员，能让团队的效率呈几何级数增长。如果你想让你的开发者社区团队从“不错”变成“牛掰”，你就要给团队配上一名开发者出身的技术布道者。

Estimote Community 团队 (从左至右), Wojtek, Witek (团队领导), Ula (社区经理), Piotr (技术布道者)

不，但是自己学学编程也没什么不好的

你们可能觉得我是在说大话。毕竟，我已经承认了自己从来没写过代码。怎么说呢？我们经常给别人出主意，但是自己却很少真的这样去做。所以我劝各位去学习，不要重蹈我的覆辙。

很有可能，通过学习你也无法成为一名优秀的开发者。但是你并不需要成为一名优秀的开发者。

你都不需要自己去开发产品。你去学习编程，是为了让你打造出一个开发者社区，让你更好的像个开发者一样去思考。即使是最基础的编程知识，也能大大的帮你理解社区，以及你的产品的用意。要想参与到开发者社区中，这是一项最基本的知识。

除了编程之外，你也可以学习其他东西。面向开发者的产品，其用户除了写代码之外，还会做很多其他事情。如果你和我一样，对 Xcode 和 Android Studio 世界就是没有好感，你可以在其他领域内进行学习。读读产品管理方面的书籍，上一些 UI 设计的课程，学学 UX，这个世界上有数不完的东西等着你去学习。Coursera、Udemy、iTunes U 和大量的博客都为你提供了各种各样的智慧，这些东西都是你梦寐以求的学习资料，你要学会善用它们。

最重要的是：学习领域内的知识。只要放开眼界，不再局限于社区搭建知识，学习其他一些知识能让你更轻松的搭建起开发者社区。在相关的领域内扩展你的知识储备，它能让你更流畅的和社区成员进行对话。

有没有例外？

确实有这样一些开发者社区团队，最初的时候我觉得他们一定都有着相当丰富的开发者经验。例如 Docker 或是 MongoDB 这样的公司。它们的产品技术性都非常强，提到它们你就一定会想到技术代码，就像提到 Estimote 就一定会想到微定位、提到 Twilio 就一定会想到文本信息，或是提到 Oculus 就一定会想到电子游戏一样。

但是在研究了他们对“社区管理”职位的要求之后，我发现这些职位并不要求应聘者有技术背景。或许这没有什么值得惊讶的。如果你想要搭建一个开发者社区，直接去做就好了。你不需要成为 Linus Torvalds，一样可以成功。

作者：Wojtek Borowicz (Wojtek is the community evangelist at Estimote in Krakow, Poland.)

原文：How to Become An Awesome Developer Evangelist When You’re Not a Developer

转载自：DevRel 开发者关系-非开发者如何成为优秀的技术布道者

译者：鲁行云