书名：开发者关系实践指南
ISBN：978-7-115-63430-6
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
著 ［美］卡洛琳·莱科（Caroline Lewko）
［美］尼古拉斯·索维奇（Nicolas Sauvage）
［美］安德烈亚斯·康斯坦丁努（Andreas Constantinou）
译 徐毅 汪盛 罗阳洋
责任编辑 李 瑾
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
读者服务热线：(010)81055410
反盗版热线：(010)81055315
Simplified Chinese language edition copyright ©2020 by SlashData Ltd.Published by arrangement with SlashData.
All rights reserved.
Developer Marketing & Relations:the Essential Guide,by Caroline Lewko,Nicolas Sauvage,and Andreas Constantinou.
本书简体中文版由SlashData公司授权人民邮电出版社出版。未经出版者书面许可，对本书的任何部分不得以任何方式或任何手段复制和传播。
版权所有，侵权必究。
本书是关于开发者关系的实践指南，书中呈现了那些奋战在开发者营销一线的专家的非凡见解。在本书中，许多来自知名公司的开发者营销和开发者关系的主要实践者分享了他们的知识、故事、经验和实战案例，如微软 Azure 开发者营销总监 Cliff Simpkins、Facebook 开发者营销主管Desiree Motamedi、谷歌开发者关系主管Dirk Primbs等。他们以开发者为中心，从邮件营销、社区营销、打造开发者营销计划、构建开发者关系、面向开发者重新定位品牌等方面，通过具体实例，阐述了开发者营销和构建开发者关系的重要性及其战略战术和方法措施。不管你是开发者关系领域中久经沙场的老将还是刚刚起步的新手，都会发现这些内容是非常有见地的。
本书适合从事开发者关系、开发者营销等相关工作的人员阅读参考。
在追求高质量发展的年代，互联网会逐渐从流量逻辑走向体验逻辑。虽然开源和开发者的概念已有数十年历史，但开发者关系（DevRel）这一领域的价值、意义和最佳实践，依然有三个关键方向值得深入思考和探究。
首先，虽然本书大量使用了“营销”一词，但ToDev的开发者关系与传统的流量营销或是ToB营销，在内容设计、渠道投放及交互模式上有本质的差异；其次，“开发者关系”更合适的表述也许是“开发者体验”，开发者作为有技术品位、有强独立思考能力的群体，其画像和用户旅程的独特性需要被充分发掘和尊重，这当中也会有大量的有效产品反馈出现；最后，开发者的数量和质量其实是技术增长的关键北极星指标之一，正如growth hacking（增长黑客）对于ToC业务的意义，community-led growth（社区驱动增长）对于开源项目及ToB业务的意义，其数据驱动结合体验驱动的方法论及工具集，目前都是值得深度耕耘的新领域。
2021年至今，蚂蚁集团从0到1搭建起了开源办公室（OSPO），完成了开源技术战略从原始构思到业务化的探索期，《开发者关系实践指南》这本书为我们接下来深度服务开发者的核心目标、要开展的社区驱动增长业务，以及如何在大公司系统性做开源的策略探索，提供了系统完备、高质量的“道法术”的参考。我们也很期待在不久的将来，能为大家带来更多中国公司的实战经验。
——边思康
蚂蚁集团开源技术增长业务总监，OSPO负责人
事实上在写推荐语的时候，我是犹豫的。一方面DevRel（开发者关系）确实是近几年新涌现的热门岗位；但另一方面我自己其实觉得DevRel这个名字并不贴切，我觉得更准确的称呼是DevMar（开发者市场）。可能就像书里所传递的，开发者天生就对市场营销反感，所以就连这个岗位的名字也要伪装一下，抹去市场营销的痕迹。但我可以告诉你，这就是一本教你怎么做市场的书，只是营销的对象是这个星球上对营销最免疫的群体——开发者。这本书首先是给那些想“套路”开发者的市场人准备的。当然如果你是开发者，不想被市场人“套路”，也值得阅读。是不是觉得很有道理？我也是从书里学的，赶紧入手吧。
——陈天舟
Bytebase联合创始人、CEO
这是一本深入探讨开发者关系和市场推广的宝典，旨在为专业人士提供实用的策略和见解。作者通过深入研究构建强大开发者社群和成功实现市场推广的关键要素，为读者提供了宝贵的指导和建议。书中强调了开发者关系在数字时代的重要地位，并提出了有针对性的市场推广战略。这本书的一大亮点是通过大量的调研数据和真实案例，深入行业洞察、剖析成功案例，不仅具有说服力，也能让读者切身感受开发者市场和开发者关系在技术推广中的实际应用和价值。
此外，书中的案例大多来自海外企业，可为正在考虑进行全球化的技术公司提供一定的国际视野。
总体而言，这本书提供了全面而实用的方法论，可以帮助读者在竞争激烈的科技领域取得成功，是从事开发者关系和开发者市场工作的专业人士的宝贵资源。无论是对初入行业的新手还是对经验丰富的专业人士，这本书都是不可或缺的指南和参考。
——郭悦
亚马逊云科技资深开发者运营专家
伴随着数字化时代的全面到来，一批以开发者为核心用户或重要生态伙伴的企业迅速崛起。与此同时，开发者关系也日益受到企业的重视。然而，开发者关系是一个相对新兴、垂直的领域，前人积累的共识与方法论少之又少。这本书如同宝藏一般，从开发者画像、邮件营销、技术品牌、技术活动、社区构建等方方面面，为读者提供了全球范围内领先的科技公司和一线从业者的实践案例与见解。
相较于晦涩的理论和冰冷的概念，真正来自一线实践者或成功或失败的故事往往对从业者更有帮助，这也是SegmentFault一直以来组织Dev.Together开发者生态峰会所坚持的原则。我们期待大家一手读书、一手分享，在数字化浪潮中一起Dev.Together！
——江波
SegmentFault思否COO，开源问答软件Answer联合创始人
Dev.Together开发者生态峰会发起人
随着云厂商以及开源项目的兴起，越来越多的同仁加入到了面向开发者的运营工作中来。与传统的ToC运营不同，ToD运营面向的是有较强独立思考能力的开发者，开发者旅程转换周期比较长，这使得传统的ToC运营激励在ToD运营过程中很难生效。
《开发者关系实践指南》这本书汇聚了开发者关系一线专家的真知灼见，从开发者画像、开发者营销、构建开发者关系及面向开发者的宣传定位等层面，结合具体的案例，向我们展示了构建开发者关系和开发者营销的整个过程，同时也介绍了很多构建开发者关系的战略战术。阅读这本书，你可以对开发者关系实践有一个全面清晰的认识，通过吸收一线专家的经验和智慧提升自身的开发者运营水平。
——姜宁
Apache软件基金会董事，ALC Beijing发起人
在追求商业成功的道路上，企业必须与各种利益相关者建立稳固的关系，包括公共关系、客户关系、政府关系，甚至是投资人关系。当开发者群体成为企业成功的关键因素时，开发者关系（DevRel）便显得尤为重要。忽视与开发者的关系，就很可能使企业在技术驱动的市场中失去竞争力。
作为国内首部关于DevRel的专著《开发者关系：方法与实践》的译者，我深刻理解DevRel在国内的新颖性和必要性。尽管DevRel在国际上已成为一项成熟的职能，但在国内，它仍是一个被忽视的领域。这不仅是行业短板，也是认识上的空缺。
《开发者关系实践指南》汇集了来自全球多个DevRel资深从业者的经验和案例，旨在深入浅出地介绍如何建立和维护与开发者的有效关系，不仅能够帮助读者理解DevRel的基本概念，还能提供具体的实践策略和方法。
“得开发者得天下”不只是一句口号，更是在当今技术密集型的市场环境下，企业成功的关键策略。《开发者关系实践指南》提供了这一策略的实施指南和行动框架。因此，我强烈推荐国内所有软件、互联网等IT行业的从业者阅读这本书。
看到书中海外各知名企业DevRel从业者不吝分享的精神，我也希望国内的我们能一起建立一个更加紧密的DevRel从业者社群，共享知识，互相学习，携手进步，促进我们的行业快速成长，为企业和开发者社区创造更多价值。
——林旅强
开源社联合创始人，零一万物开源负责人
《开发者关系：方法与实践》译者
近些年来，随着开发者经济在全球范围内的崛起，国内软件厂商越来越重视开发者在购买决策链条中的地位，积极投入开发者关系计划。然而，舶来的概念与具体实践的差距，是横亘在企业从开发者关系工作中获益的巨大鸿沟。到底怎么开展开发者关系工作，每个具体方向可能会遇到什么问题，成为企业与从业者迫切希望获得输入的主题。这本书虽然也是讲述海外企业的故事，但它具体展示了不同企业与产品各自面临的开发者画像，并结合具体的营销、运营和社群建设手段，讨论成功的开发者关系项目是如何设计与实施的。书中的案例包括Google和Facebook等大公司开发者＋企业的模式，也包括Atlassian和Apidays等开发者企业的模式，对于想要了解开发者关系计划实施案例与细节的读者来说，这本书是个不错的参考。
——Tison
格睿科技（Greptime）开发者关系总监
数智经济时代，开发者成为企业创新和增长的关键驱动力，建立和维护与开发者良好的关系对于企业成功至关重要。这本书用简洁明了的语言和清晰的逻辑，阐述了全球多个领先公司的多位资深专家的成功实践和经验教训，涵盖开发者关系建设和营销策略制定的所有重要工作，包括社区建设、内容营销、活动策划、API经济等，从开发者是谁到如何建设开发者社区，再到如何创建吸引开发者的内容和衡量成功的方法，系统性地探讨了多元化的开发者发展手段。书中还提供了很多实操性很强的技巧和工具，如创建高质量的API文档、使用数据驱动运营决策等。
这本书的作者和译者都是在此领域工作多年的专家，以其深厚的经验和独到的见解，为我们精心编制了一套全面且实用的开发者关系指南。无论你的经验水平如何，这本书都会让你对开发者关系有更深的理解和更强的实践能力。
总的来说，这是一本综合性强、实用性高的专业图书，对寻求搭建与开发者紧密联系的组织、企业，极具参考价值和指导意义。
——谢文龙
华为开发者发展运营总监
《开发者关系实践指南》称得上是一本开发者关系从业者的实践宝典，内容全面，不仅深入探讨了开发者关系的运营管理，更涵盖了市场、品牌、营销、活动等多个方面，为从业者提供了一套完整的指导方案。这本书的出版，无疑为国内的开发者关系领域注入了新的活力，其详尽的内容和实用的建议，能够有效地帮助从业者提升自身的专业能力，缩小与世界领先水平之间的差距。更重要的是，这本书对开发者关系相关话语体系的普及和标准化作出了重要贡献。在我看来，一个标准化的话语体系对于开发者关系岗位的普及和扩大至关重要。它不仅能够帮助新进入这一领域的从业者快速融入其中，也为整个行业的交流和协作提供了共同的语言和框架。总之，《开发者关系实践指南》是一本极具价值的参考书，是推动国内开发者关系行业发展不可或缺的重要资源，无论是刚刚步入这一领域的新手，还是已经在这一行业深耕多年的资深从业者，都能从中获得丰富的知识和实践经验。
——杨攀
极客邦科技副总裁，TGO鲲鹏会总经理
在我作为TiDB社区负责人和Maintainer的四年多时间里，我深切体会到开发者社区建设的挑战与机遇。我们从在K8s社区借鉴治理模式的尝试，到引入Apache Way的哲学，不断探索适合我们社区的治理方式。经验告诉我们，对开发者群体而言，治理不是首要任务，更重要的是激发他们的兴趣，找到合适的协作方式，并通过持续沟通保持进展的同步。
开发者关系的工作常被误解，很多人错误地将其等同于传统的市场营销。然而，开发者社区是一个独特的群体，它们的需求和动机与传统市场营销的目标大相径庭。在实践中，我深刻体会到理论学习虽重要，但真知来自实践。《开发者关系实践指南》之所以值得推荐，是因为它汇集了行业内众多成功实践者的观点和经验，通过实际案例而非空泛理论，为读者展示了与开发者群体建立和维护联系的有效方法。这种实践者的视角，比任何理论都更加贴近真实情况。
——姚维
TiDB全球开源社区/Developer Experience负责人
SlashData是开发者生态的调查分析公司，帮助TOP100科技公司理解开发者受众群体、度量开发者策略的投资回报。
凭借着十多年来坚持开发者研究所获得的成果数据，我们很清楚开发者从哪里来、到哪里去。我们累积了大量历史数据，包括开发者为何参与开发、正在学习什么、从事哪些行业和正在参与哪些项目、使用哪些技术及他们对这些技术的满意程度如何、他们对供应商和开发者社区有何期待等。我们一直在跟踪本地和全球开发者群体数量的增长趋势，以及群体构成随时间的变化情况。
我们每年两次的开发者群体调研，有150多个国家和地区总计超过30000名开发者参与，并分享他们的经验。我们的样本是多样化的、有代表性的，涵盖了几乎所有开发者社区。在全球范围内 70 多个领先社区和媒体伙伴网络的帮助下，我们每一次都将调研问卷翻译成9种语言并触达各种具有不同形式和规模的开发者社区。每次调研，我们都会重新联系开发者，每次调研都有80%以上的答卷来自新的参与者。然而，历经多次调研，我们在技术采纳与趋势方面得出的调查结果却是始终如一的。
DevRelX社区是一个学习和分享平台，致力于提升人们对开发者群体和行业趋势的了解。任何经验水平的人都可以访问这个社区并分享他们的知识。
加入DevRelX社区你可有以下收获。
● 学习和培训：加入社区主导的活动和计划。
● 数据和资源：访问大量资源和数据以提高你对开发者的理解。
● 链接：与同行建立有意义的链接，并充分利用跟领域专家在一起的学习机会。
● 贡献：分享你的想法，积极参与打造DevRelX社区的未来。
DevRelX社区欢迎所有人，现在就加入吧！
2011年，马克·安德森在《华尔街日报》上发表文章，声称“……软件正在吞噬世界”。
他在文章中指出，越来越多的大型企业运行在软件系统上，同时也向他们的客户和伙伴提供在线服务。我坚信，他在2011年所描述的这种趋势，时至今日已变得愈加明显。从全球证券交易所里那些最成功的企业、就业市场里对软件开发者的强劲需求、数字化公民对与他们互动的政企组织的要求越来越高等方方面面，都可以看到这种迹象。今天，每家公司都需要有一个软件战略，否则就有可能被行动更敏捷、适应性更强的竞争对手超越，因为他们可以更快地以更易于使用的方式交付客户所需。
在软件领域，真正的技术行家是每天都在构建和使用这些技术的开发者。他们是编译器、命令行、框架、测试套件、部署流水线及生产系统方面的大师。在企业不断推动寻求更灵活的技术方案的过程中，开发者生成了可以提升代码质量、缩短项目周期和迭代产出新特性的各种敏捷开发实践。DevOps技术和云基础设施则使得人们可以更快速、更便宜地部署这些解决方案，规模方面达到了足以响应全球需求的水平。开发者和站点可靠性工程师（SRE）7×24小时全天候待命，关注着每个系统异常或流量高峰触发的告警，一旦出现问题，他们就会负责回滚更新、消除错误和恢复秩序。
涉及技术决策的时候，承担着上述关键职责的开发者才是真正发号施令的人。
企业高管（CXO）们再也不能为了给某大学老友帮个忙，或是回报某销售员陪他开开心心打了场高尔夫，而随意地决定公司使用什么技术了。如今，是开发者在为他们所构建的系统选择工具、平台和基础设施，以求能取得最佳成果。
为开发者打造他们喜欢的工具、API或是平台，既可以取悦客户、颠覆竞争对手，还能够实现业务转型。所以，如果你们是一家想要快速发展的企业，并将软件作为参与市场竞争的方式，就必须了解并接触开发者。
如何才能接触到开发者并说服他们使用你们公司的产品？这听起来像是一个经典的营销问题，但如果你将传统的消费者营销技术应用于这个受众群体，却注定会失败，因为开发者们厌恶营销。开发者是善于分析的、细心的、忠诚的、数据驱动的，也是非常忙碌的。他们对各种营销炒作、销售话术或是充满了流行语的未来能力承诺都没有耐心。他们需要去解决自己面前那些真实存在的具体问题，他们希望得到自己信任的人和信息源的帮助。
幸运的是，参与写作本书的都是本领域的专家，他们在职业生涯中已经投入了数十年时间思考怎么跟开发者打交道。他们汇聚的群体智慧可为你和你们公司提供一张地图，指引你们创建开发者所关心的各种事物。本书将为你介绍如何发展开发者社区，如何运作开发者营销计划以吸引该领域专家并请他们为你们代言。通过本书，你可以了解开发者社区的演变模式，以及你能控制什么、不能控制什么。本书还会告诉你，线上和线下现实生活中在哪里可以找到开发者，以及如何与他们进行真正的对话，包括从组织活动到管理在线社区的所有形式。如果你不清楚自己在跟怎样的群体对话，本书有一章是专门介绍如何使用开发者画像的。本书呈现了那些奋战在开发者营销领域一线的专家们的非凡见解。
在我看来，开发者是业务创新的支点。在未来的数十年里，有些公司会敞开怀抱拥抱开发者，赢得他们的信任，帮助他们解决技术问题，而这些公司也将成为21世纪最成功的企业。
Adam FitzGerald，亚马逊AWS全球开发者营销主管
欢迎阅读《开发者关系实践指南》（原书第3版）。本书的历史可以追溯到2017年10月的未来开发者峰会。那时候，Andreas Constantinou和Nicolas Sauvage深刻地意识到，无论从公司的类型、所展示的产品还是实践者的知识情况哪个角度看，开发者关系（或称DevRel）天生就很碎片化。我们发现峰会上有很多优秀实践，但它们往往仅被这些实践的公司内部掌握。我们希望跟这些领导者合作，共同编写一份精要指南，以便与更广大的受众群体分享这些知识，他们包括布道师和倡导者、开发者营销实践者及其他开发者关系相关从业人士。
通过持续地观察DevRel实践在过去3年间的发展和演变，我们发现，人们需要不停地去教育市场，了解DevRel是什么，以及成功运作DevRel计划需要采取什么战略战术。好消息是，有很多优秀公司里的先行实践者愿意分享他们的知识、故事、学习心得和最佳实践，而本书已经把它们全部收入囊中！我们认为，不管你是开发者关系领域中久经沙场的老将还是刚刚起步的新手，都会发现这些内容是非常有见地的。
在SlashData，我们经常被问到这样一个问题：“你可以帮助我们了解Mozilla、谷歌或微软是如何实践开发者营销的吗？”（你尽可以将这些企业名称随意替换成你最喜爱的科技品牌。）没错，这就是本书想要达成的目标。
本书包括第1版的所有章，以及9个新章和1个修订章。本书按照从战略要务逐步切入战术要务的顺序来安排内容。你既可以从头一直读到尾，也可以挑着阅读，重点关注你当前最需要了解的内容。如果更关注战略制定，那你可以阅读微软Cliff Simpkins的“开发者画像的作用”；如果是正在策划项目，那可以阅读谷歌Dirk Primbs的“构建开发者关系”。如果你才刚起步，那Nutanix的Luke Kilpatrick的“打造开发者营销计划”不容错过。如果你身处大型组织内部，想拉拢更多干系人共同参与进来，那Salesforce的Arabella David的“开发者关系理事会”是必读章，这也是本书新增加的章。
开发者活动已经成为本行业的一大重要内容，本书中也有多个章节介绍开发者活动，如Atlassian的Luke Kilpatrick和Neil Mansilla共同编写的“小型开发者活动”，以及由谷歌Katherine Miller所写的“卓越开发者活动的背后”。必须指出，本书出版发行期间正值新冠疫情肆虐，导致很多项目计划的策划者不得不重新评估他们的战术选择，因此你或许需要读一读ARM的Pablo Fraile和Rex St. John所写的“无法见面如何跟开发者建立联结”。
如前所述，由于不同公司向开发者提供的产品种类是不同的，开发者计划也有很多不同类型。在“围绕芯片构建硬件开发者社区”一章，高通的Ana Schafer和Christine Jorgensen介绍了他们在硬件开发者社区方面的经验。众所周知，API是DevRel的关键产品，因此我们也很高兴为大家献上由apidays Global和GDPR.dev创始人Mehdi Medjaoui所写的新章“开发者关系和API”。
在此我们无法把所有精彩章都罗列一遍，但如果连社区相关章都不提到的话，那就太失职了，毕竟社区可是所有领先的开发者关系营销计划的核心和灵魂之所在。请务必阅读由Salesforce的Jacob Lehrbaum所写的“社区的力量”，以及由Leandro Margulis基于他在TomTom屡获殊荣的精彩历程所写就的新章“构建内聚型的开发者社区”。
Andreas Constantinou，SlashData创始人兼CEO
Nicolas Sauvage，TDK Ventures总裁兼董事总经理
Carline Lewko和Dana Fujikawa，WIP公司，本书第3版责任编辑
2020年9月
本书提供如下资源：
● 本书思维导图；
● 异步社区7天VIP会员。
要获得以上资源，您可以扫描下方二维码，根据指引领取。
作者、译者和编辑尽最大努力来确保书中内容的准确性，但难免会存在疏漏。欢迎您将发现的问题反馈给我们，帮助我们提升图书的质量。
当您发现错误时，请登录异步社区（https://www.epubit.com），按书名搜索，进入本书页面，单击“发表勘误”，输入错误信息，单击“提交勘误”按钮即可（见下图）。本书的作者、译者和编辑会对您提交的错误信息进行审核，确认并接受后，您将获赠异步社区的100积分。积分可用于在异步社区兑换优惠券、样书或奖品。
我们的联系邮箱是contact@epubit.com.cn。
如果您对本书有任何疑问或建议，请您发邮件给我们，并请在邮件标题中注明本书书名，以便我们更高效地做出反馈。
如果您有兴趣出版图书、录制教学视频，或者参与图书翻译、技术审校等工作，可以发邮件给我们。
如果您所在的学校、培训机构或企业，想批量购买本书或异步社区出版的其他图书，也可以发邮件给我们。
如果您在网上发现有针对异步社区出品图书的各种形式的盗版行为，包括对图书全部或部分内容的非授权传播，请您将怀疑有侵权行为的链接发邮件给我们。您的这一举动是对作者权益的保护，也是我们持续为您提供有价值的内容的动力之源。
“异步社区”是由人民邮电出版社创办的IT专业图书社区，于2015年8月上线运营，致力于优质内容的出版和分享，为读者提供高品质的学习内容，为作译者提供专业的出版服务，实现作译者与读者在线交流互动，以及传统出版与数字出版的融合发展。
“异步图书”是异步社区策划出版的精品IT图书的品牌，依托于人民邮电出版社在计算机图书领域30余年的发展与积淀。异步图书面向IT行业以及各行业使用IT的用户。
Alexes Mes: SlashData
用什么度量及如何度量开发者营销团队的成功和开发者营销策略的成功是个重要问题。但是，在度量开发者营销策略的成功程度之前，你得先确定你们的营销策略是什么。要想在行业里建立起竞争优势，吸引开发者的注意力并脱颖而出非常重要。要想设计出能够吸引开发者的有效外展活动，知道开发者到哪里查找信息及他们如何跟进最近技术动态是至关重要的。
在本章中，我们将探究为了触达各领域的开发者，应把时间和资源投入到哪些渠道才是最佳选择。明了开发者到哪里查找软件开发相关信息并跟进最近技术动态，能够为你提供创建定制化营销策略所需的信息。让我们一起来深入探讨一下吧！
增进对开发者群体的了解，有助于做好开发者营销策略。至于开发者的细分方法，可以说有多少开发者就有多少种细分方法。在此，我们将从基础的细分方法——按领域规模和地区分类开始。
假设你们想要吸引开发者参与使用你们新推出的SaaS平台，计划采取重拳出击的营销策略，并为之准备了大笔营销预算。面临的第一个问题跟预期客户数量有关：你们选中的这个领域有多大规模？知道该领域有多少开发者，有助于你们评估产品或服务的整体收入，也有助于调整对开发者营销工作的期望。
图1中的数据对你们的营销策划来说是个好消息：有2150万开发者在从事Web开发，他们都有可能对你们的产品感兴趣！接下来，就该考虑该领域开发者对达成什么目标感兴趣了！就Web领域而言，约70%的专业开发者的主要目标是为未来机遇做好经验积累、通过削减成本提高效率和通过开发应用程序来创收。围绕如何实现这3个目标跟专业Web开发者建立联系，你们就能够得到最好的互动参与效果。
图1 截止到2021年第三季度的开发者数量（单位：人）
我们再来看开发者在全球范围内的分布情况。制定地区策略是一种可靠的方法，能够从开发者角度改善与他们沟通的效果。我们发现，不同地区之间社会经济因素的差异不只是会影响开发者现时的观点和愿望，在宏观层面还影响到了不同地区选用技术甚至选用供应商的方式。
由图2可知，图1中的几个热门领域（Web应用/SaaS、移动应用、后端服务和桌面应用）的开发者在各个地区的分布相对较好。虽然从总体来看，Web应用/SaaS、移动应用、后端服务、数据科学/机器学习/人工智能开发者大约有2/5分布在北美及西欧地区，但在中东和非洲地区相比其他领域，这几个领域的开发者更集中。也就是说，在中东和非洲地区，相比其他领域来说，Web应用/SaaS、后端服务、移动应用和数据科学/机器学习/人工智能领域的开发者营销市场空间更大一些。
除了关注这些热门领域的开发者，我们也将目光转移到其他领域看看是什么情况！
如图2所示，北美是游戏和增强现实/虚拟现实项目领域开发者最集中的地区，该地区囊括了这两个领域各自近40%的开发者。跟其他软件领域相比，这两个领域的开发者也更有可能位于北美地区。
图2 不同行业开发者位于各区域的百分比
相比之下，数据科学/机器学习/人工智能领域的开发者的分布更分散，他们比其他领域开发者位于南亚地区的概率更大。那么如何跟此地区的数据科学/机器学习/人工智能领域开发者建立联系呢？请把注意力拉回到受众群体想要达成的目标上来：在南亚地区从事数据科学/机器学习/人工智能项目的开发者当中，有超过三分之一（34%）的开发者是为了给未来的机会积累经验，有14%的开发者期望能产生收入。也即是说，围绕发展技能与未来职业机会的主题来开展工作，是你们跟南亚数据科学/机器学习/人工智能领域开发者互动的最有效方式。
最后，各地区的开发者都分布在哪些市场领域，也是一个值得考虑的点。例如，近一半的IoT开发者（在消费电子和工业IoT领域工作）聚集在北美和西欧地区，因此，在这两个地区具有与这些开发者进行互动的最佳机会。然而，这两个地区IoT开发者所处的产业垂直领域却有很大差别。大约40%的北美IoT开发者瞄准的是物流市场，而38%的西欧IoT开发者则盯上健康和智慧城市市场。想想看，如果能针对开发者受众所瞄准的目标行业来调整沟通策略，你们的营销活动可提升多大成效？
前面我们探讨了你们想要与之互动的开发者都是哪些人（who），接下来还需要知道这些开发者都会到哪里（where）去获取信息、跟进最新技术动态，这样你们才能知道通过哪些渠道（what）可以有效地触达这些开发者。
开发者需要紧跟技术形势的变化，以免掉队。在遇到编程问题需要帮助时，多数人会采取跟社区同仁进行互动的方式，其他人则更依赖官方供应商沟通渠道和会议的形式。该怎么确保你们的信息会出现在他们搜索结果靠前靠中心的位置呢？在这里，我们将了解到开发者用于跟进最新技术动态的常用信息源，以及信息源对不同软件领域开发者的重要性。
如图3所示，开源社区是开发者用于寻找软件开发资讯、跟进最新动态最受欢迎的信息源，全球近半数（48%）的开发者都在使用这些社区。不过，最受欢迎信息源排行榜前5名的使用率基本差不多，非常接近。第一名和第五名之间只有4个百分点的差距。如果想要确保把信息源排行榜前5名纳入开发者营销策略的一部分，那最好要包括这些信息源。
图3 开发者用于获取最新信息所使用信息源的百分比
1．开源社区
2．社区网站和论坛
3．官方供应商网站
4．社交媒体
5．问答网站
其中4个信息源都是社区驱动型的，这表明开发者更喜欢活跃的、同行参与型的信息消费行为。把营销资源投放在支持GitHub等站点上的开源仓库、维护社区网站和社交媒体上的存在感、在Stack Overflow等公共问答站点上解答问题等地方是很值得的。
虽说如此，维护自家网站仍然是重中之重：在供应商驱动型的信息源当中，官方供应商网站仍然是开发者获取此类信息的绝对首选。在自家网站上，我们可以直接掌控新版本发布、缺陷修复和优化改进等相关信息，而这正是开发者喜闻乐见的。
与开发者营销策略其他诸多方面一样，我们意识到并非所有开发者都是一样的，根据所参与的具体项目，他们在寻找信息和跟进最新动态方面有着非常不同的需求和习惯。
对于Web开发者、后端开发者和第三方应用开发者，他们在跟进最新动态方面有着相似的偏好。相比其他领域的开发者，他们会更频繁地使用多个信息源：这些行业的开发者中超过80%的人会使用3个或更多个信息源，而从开发者整体来看只有73%的人会这么做。制定同时针对多个渠道的策略，能更有效地触达和留住Web、后端及第三方应用开发者。从比例看，这些开发者也最倾向于依赖官方网站，因此要保持网站持续更新！
如图4所示，利用社交媒体的开发者参与策略最适合Web应用、移动应用、游戏和增强现实/虚拟现实应用开发领域的开发者。移动应用开发者是社交媒体最重度的使用者，有超过半数的移动开发者都依赖此类信息源来跟进最新动态。社交媒体具有易于访问的优势，其有能力迅速传达信息，但其有效性极大程度上取决于所面对的开发者画像。一般来说，软件开发资历越浅的开发者越有可能使用社交媒体作为信息源。我们将在最后一节探讨开发者画像。
图4 各领域开发者依赖不同信息源的比例
我们将以开源社区这一最受欢迎信息源的介绍来结束本节。开源已经成为开发者文化中极为普遍的一部分，体现了开发者在同业间共享代码、知识和最佳实践这一广受推崇的价值观。开发者向企业寻求资源：当我们询问开发者“公司应该提供哪些支持”的时候，最受欢迎的答复通常如下。
● 教程（34%的开发者给出了此答复）；
● 开发者工具、集成和库（31%的开发者给出了此答复）；
● 培训课程和动手实验室（30%的开发者给出了此答复）。
在开源社区发布公开可用的资源和代码，能够有机会提升参与度，因为大部分开发者都很熟悉如何使用这些资源。
GitHub已经树立了自己最受欢迎开源社区之一的地位，全球80%的开发者在该平台上开设有自己的个人账号。在后端服务、Web应用和第三方应用领域，拥有GitHub账号的开发者比例达到了86%～90%，这也意味着，对于利用GitHub对这些开发者产生影响的策略，其有效性也相对较高。
游戏开发者是跟此趋势贴合度最低的开发者群体，其中有32%的人没有GitHub个人账号。这跟开发者对待为开源做贡献的态度应该关系不大，更主要是因为这么做的必要性更低。49%的游戏开发者担任非开发者类的角色，例如UI或UX设计师、业务分析师、美术师、研究员、技术写作者或CEO，而且他们不像开发者那样重度依赖GitHub进行版本控制，可能也不是非得使用GitHub不可。此外，非开发者类角色中，有相当大比例是创作者，他们很可能会产出极大量的文件类艺术资产，而众所周知这是Git的一大痛点。
前五大信息源中，唯一还有待探讨的沟通渠道就只剩下问答网站了。让我们继续阅读吧！
Stack Overflow是众多问答网站当中最知名的一个，全球85%的开发者使用该网站来寻找速修方案。将Stack Overflow等网站纳入开发者营销策略是一种有助于提升企业形象、促进跟开发者之间良性互动的好办法。
如图5所示，Stack Overflow在Web应用/SaaS、后端服务和第三方应用
图5 各领域开发者使用Stack Overflow的百分比
领域开发者群体中特别受欢迎。这些领域中有89%～94%的开发者在使用Stack Overflow。在这些领域当中，后端服务和第三方应用开发者在参与回答问题和收集徽章方面最为积极。监控这两个社区的动态，将有机会从中发掘出有关产品改进的真知灼见。
只有19%的游戏开发者在Stack Overflow上赢得过有关回答问题的徽章，相应地，人们也较少提出或回答与游戏相关的问题，相比而言，在后端服务领域则有31%的开发者已经养成了经常回答问题的习惯。游戏开发者当中，之所以有很大比例的一批人不使用Stack Overflow，或许只是因为在他们需要速修方案时无法在该平台上找到相关回答，索性也就不用了。对于一家想要提升自身社区形象的供应商而言，在平台上为游戏开发者的问题提供支持和解决方案可能会非常有效。
在前面两节，我们针对用于触达开发者的信息渠道做了调查。但不太可能某个特定领域的所有开发者都频繁地使用相同渠道，或是同样贪婪地消费信息源。此外，开发者使用的信息渠道也并非一成不变。贯穿开发者的整个职业生涯，他们对信息渠道的需求很有可能会发生迁移，早期阶段他们很可能会高度依赖学习资源类的信息源，而在其职业生涯的高峰阶段，实时跟进最新技术版本发展的愿望则更有可能会成为主导。访问信息源的原因不同可能会对开发者所消费信息的类型有所影响。在本节，我们将继续深入探讨，力求理解对于不同开发者细分群体来说，哪些信息渠道能够提供最高的回报。
我们调查了软件开发经验对信息偏好的影响，如图6所示。我们发现，社交媒体是一个相当两极分化的信息源。在缺乏经验（1～2年软件开发经验）的开发者群体当中，有超过半数的人更喜欢这种易于访问的信息源。这种偏好会随着经验增长而有所减弱。而在经验丰富（拥有超过16年经验）的开发者群体中，大约30%的人会使用社交媒体查找软件开发相关信息和跟进最新动态。
图6 不同经验开发者使用不同信息源的百分比
拥有11年以上经验的开发者表现出了对大多数其他信息源的高度倾向性，黑客马拉松除外。一般来说，经验丰富（拥有16年以上经验）的开发者是更贪婪的信息消费者，约58%的此类开发者同时使用4个或更多的信息源。而那些经验不满1年或许还不太了解怎样查找信息的开发者，只有40%的人使用4个或更多的信息源。
所处地理区域也会影响开发者对信息源的偏好。在特定区域，文化、社会和政治分歧可能会影响不同信息源的可用度或流行程度。透过地区滤镜了解开发者群体，不仅有助于确定我们选择信息渠道的短期战术方法，提供额外视角看待产品采纳率期望值的方式也有助于我们制定自己的长期战略。
如图7和图8所示，与其他地区的开发者相比，南亚、南美地区和大洋洲的开发者更倾向于使用多个信息源：其中有40%及以上的开发者使用5个或更多信息源。大洋洲和南美地区的开发者是软件开发经验最丰富的群体之一，在最有经验地区排名中分列第一位和第四位。而在本节前面部分，我们已经了解经验丰富的开发者相比经验欠缺的开发者会使用更多的信息源。
图7 不同区域开发者使用不同信息源的百分比
图8 不同地区开发者使用不同数量信息源的百分比
西欧和北美地区在最有经验地区排名中分别名列第二位和第三位，它们在信息源方面有着相似的偏好。社交媒体作为跟经验密切相关的一种信息源，在西欧的表现相较于其他地区偏弱。
南亚、中东和非洲地区是具备5年以上软件开发经验的开发者占比最高的地区。这些地区有着相似的信息源偏好，基于事件的信息源正蓬勃发展，包括研讨会、培训或工作坊，以及小型聚会和黑客马拉松。
此外，相比其他地区，南亚、中东和非洲地区的开发者更倾向于采取非正式的、社区驱动型的参与方式，尤其是社交媒体和社区群组。相似之处还不止于此，他们在学习材料的类型方面也展现了相同的偏好：相比其他大多数地区，他们更喜欢短格式文本（如博客文章、条列式文章）、播客、直播视频（如Twitch、网络研讨会），以及互动型活动（如大型会议、小型聚会）。
与此同时，大中华区的开发者则更有可能使用3个或更少的信息源：近60%的开发者都是如此。在此地区，只有少数几个最受欢迎的信息源选项。相比其他地区，大中华区的开发者更青睐官方供应商网站和官方供应商邮件通信等供应商驱动型的、文本类的信息源。
本章介绍了一些思考开发者群体及其使用信息源的方法，可用于有效理解在营销策略中使用哪种信息渠道跟开发者联系最有效。总而言之，我们讨论了以下内容。
1．思考受众的方式。
● 思考目标领域的规模；
● 该领域开发者想要达成什么目标，以及自家产品怎样帮助他们实现这些目标；
● 这些开发者所处的地理位置；
● 他们在产业哪些垂直领域工作。
2．开发者使用哪些渠道跟进最新动态，不同行业间的情况有何差异。
3．如何触达特定开发者群体。
4．检查软件开发经验对信息偏好的影响。
5．如何透过地区滤镜去理解信息消费。
这些只是冰山一角，你会发现，书中还有很多方法可以提速你们的开发者关系计划，而且你随时都可以访问DevRelX官网获取更多的免费资源，还可以向DevRelX社区求助。
Cliff Simpkins：微软Azure开发者营销总监
引言在微软，我们的使命是让地球上的每个人、每个组织都能够取得更大的成就。自微软成立以来，为了让客户变得更高效，我们构建了很多平台，从Altair BASIC到Windows、从Visual Studio到Office、从Minecraft到Azure，而客户则一直处于我们所构建的这些平台的核心位置。
随着客户基数规模变得越来越大，人们很容易被分散注意力，尤其在构建平台的时候。随着规模的扩大，工程师或许会开始为他们认识的人打造平台，产品经理开始依靠分析师来告诉他们应该构建什么，市场人员则开始以营销网站开发者为目标对象进行消息递送测试（没错，这种情况的确会发生！）。
为了让团队保持方向一致，我们需要定义出希望实现的目标，并描绘出成功时的模样。现如今有很多工程团队都在使用产品规格说明书的方式，让团队成员对所要构建的特性和功能保持一致理解，但我认为有很多公司都未能先定义清楚为什么要构建这款产品。
角色画像（persona）是我最喜欢使用的统一认识工具。大约10年前，我就开始在工程工作中使用由我们可用性实验室团队创建的用户画像了。但在过去6年间，我越来越多地把时间用到产品管理工作中，为Windows创建了多个不断演化的开发者画像，囊括了从移动应用开发者到PC/主机游戏工作室开发者的多种场景，还帮助辅导其他团队也学会了如何创建开发者画像。
在本章中，我将用一家以开发者为中心的公司作为背景框架来介绍角色画像，探讨画像在产品开发和开发者营销生命周期中产生影响的方式，并分享我在此过程中的领悟。
简单介绍一下我自己。我已经在微软工作了14年，担任过开发者布道师、.NET产品规划、Windows Phone和Windows产品管理等多种角色，最近3年从事开发者营销工作。正如我之前已经提到过的，在过去10年间，画像越来越成为我工作的核心要素，它始于我从事WCF（Windows通信框架）工作期间，随后年复一年，它愈发成为我和我团队工作的核心。在Windows工作的最后几年，三问题式画像变速箱成为我们研究、会议注册及开发者计划等一切工作的核心。我们用它来构建内容、规划营销活动，并按照目标画像开展具体工作。希望等到读完本章时，读者已经理解了好的画像是什么样的，并对使用画像帮助团队保持客户至上产生了兴趣。
为什么说开发者画像很重要在我们将产品构建完成并推向市场的时候，需要确定度量其成功的方法，不管是API、用户界面、网站还是付费广告活动，都可以。但通常来说，人们对这种度量方法并没有共识，团队要么并不清楚产品成功是什么样子的，要么就是理解不一致，关于谁在使用、如何使用这些产品，团队成员各有各的看法，结果导致产品体验变得支离破碎、缺乏整体协调性。团队需要共同定义清楚他们前进的方向，以及怎么确认他们何时取得了成功，这样所有人才能对齐。
对我来说，这种对共同定义或者说对组织级对齐的诉求是在2011年前后产生的，那时候我们团队正在探讨为一个大型开发者峰会所准备的主旨演讲。跟那次活动相关的各个部门高管都在房间中参加了讨论，包括工程部、营销部、布道师及公关部。在我们讨论演讲结构和顺序时，各种观点和兴趣既相互交织又相互冲突（正如一贯以来的那样）。每个人都是从权威的立场出发高谈阔论受众的需求，都在反复地说“……但是开发者想要……”为了支持自己的观点，他们标识出了各自不同的甚至相互冲突的核心受众需求，以及他们认为需要在讲述和演示过程中着重强调的那些关键信息（如商业价值、工具先进性、新奇科技、生产力等）。
讨论结束后，我和公关人员聊了起来，我们都认为大家对本次活动的目标“开发者”群体的理解过于分化，并考虑是否需要通过一个共同愿景来牵引设计故事线。我们决定让团队用所谓的速记法，将泛化的“开发者”拆解成规模更小、定义更明确的社区，并厘清他们的痛点和期望。我们认为，这么做有助于讨论并确定主旨演讲的范围（例如，它不是针对“彼得”，而是针对“鲍尔”和“玛丽”的），还能抬高故事线的调性，超越碎碎念的层面。
随后的一年间，我们团队总共打造了5个开发者画像，并将业务重心聚焦到“拉维”“杰瑞”和“泰勒”这3个画像上。仅用了不到两年的时间，这些开发者画像就成为我们团队的核心资产，也成为业务规划时必须考虑的一大变量。我们以这些画像各自的业务和生活目标为基础构建产品和计划。我们把这些画像放到了给营销机构的简报里，甚至我们的竞争分析也是基于这些画像开展的。例如，我们会提问“一个经验丰富的独立开发者（杰瑞）会怎么应对DevOps？”，并将答案跟另一个不同画像进行对比，如某大型公司里的一线开发者（拉娜）。
画像的神奇之处在于，它提供了一个更大受众群体的复合视图，并允许他们成为产品故事线的一部分。目前已经有很多行业将画像用于营销，我个人深信画像对于开发者营销有着至关重要的作用，原因很简单：开发者画像提供了一种更易于非开发者人士理解其开发者受众群体的方式。消费者和B2B营销都是非常成熟的领域，有既定的方法、最佳实践和基准标杆。但开发者群体的行为则有所不同：我们评估和试用产品的方式不同，他们判断和消费内容的方式不同，而且他们所偏好的销售模式也不同。
应用画像之后，我们发现公关和开发者营销的工作变得更容易也更有效了。
开发者画像是什么在维基百科上，画像词条的描述是“一个虚拟角色，代表了可能以相似方式使用网站、品牌或产品的某个用户类型……是某个假想用户群组的目标及行为的象征。大多数情况下，画像都是基于用户访谈所得数据而合成得到的……它们通常体现为一两页篇幅的表述形式，包括行为模式、目标、技能、态度及环境，以及一些虚构的私人细节信息，这样能让角色显得更像是一个真实人物。”
在我心目中，微软在Visual Studio 2005开发期间制作的开发者画像堪称典范，接下来我就用它们作为画像示例为大家进行展示。在2004年的一篇博客文章中，Nikhil Kothari将他们的三大产品画像精炼为如下内容。
● 莫特（Mort）：机会主义开发者，喜欢为迫在眉睫的问题创造速赢方案，专注于生产力和按需学习。
● 埃尔维斯（Elvis）：务实型程序员，喜欢针对整个问题域创造长效方案，并在解决问题的过程中进行学习。
● 爱因斯坦（Einstein）：偏执型程序员，喜欢为特定问题创造最高效的方案，通常都会在设计解决方案之前进行学习。
2004年，在这些画像的帮助下，我们清楚明确地定义了要为VB程序员、C#程序员和C++程序员提供什么。时至今日，即便技术已经演变，但我相信核心的开发者画像仍然存在，他们只是更倾向于使用更新型的框架和模型而已（如Ruby、PHP、Go、TypeScript等）。
2004版的画像可不只是这几句简单的描述，它们描绘了一幅清晰的画面。在开发者社区内，它们甚至引发了持续多年的争论，开发者经常吐槽这些刻板印象，以及它们导致的“对号入座”现象，尤其是那些被打上了“莫特”标签（相当于当今“精英程序员”所用讥讽词“脚本伙计”的早期版本）的开发者。
让我们进一步澄清画像到底是什么。先简要地研究一下其他一些用于描述产品用户的常用实践，如市场细分和分类属性，然后逐个探讨画像与这些方式的不同之处。值得注意的是，具体使用什么方法并不是二元选择，有很多人（包括作者的团队）都是把画像跟下述一个或多个其他方法结合起来使用的。
在维基百科上，市场细分的词条定义是“将某个（通常包括了现有客户和潜在客户在内的）广阔的消费者群体或商业市场基于某种共同特征分割为消费者子群体（也即细分）的过程”。
在商业导向方面使用细分市场是最顺手的，因为用它很容易就能制作出营销计划。我们可以干净利落地衡量出一个机会的大小，轻松地打造一个相似的受众群体，还可以用这些易于观察的受众属性来度量推广活动的投资回报率（Return on Investment，ROI）。
市场细分的概念跟画像类似，事实上，不少人经常把这两个术语当作同义词混用。这两种方法都是利用共同特征（需求、兴趣和习惯）将一个大的市场拆分成了更小的群组。不过，这两种方式及它们的输出物其实差异很大。细分市场更像是一个定量的或数据驱动型的流程，使用的是可展示、可度量的行为或特质。而用户画像则更像是一个定性的过程，使用的是个人的内在驱动力和动机。
接下来将实现一个市场细分的范例。营销团队可能会审视（跟画像涵盖的相同的）开发者群体，然后创建如下市场细分，先从比较容易度量的特性开始，如工作地点。
● 企业开发者：在拥有超过1000名员工的大型企业工作，专注于构建内部应用和服务，他们心系生产力，偏好专有技术栈。
● 新兴开发者：在初创企业工作，往往更年轻，追求技术前导性，偏好基于开放技术栈构建应用和服务。
● 伙伴开发者：在平台型或服务型企业工作，构建能提升客户生产力的产品。
团队可能还会继续细分这些市场，如按照购买模式、组织（社区、学术、中小型公司、企业）或者地区（西方市场、东方市场、新兴市场）等方式细分，因为市场细分往往始于推广活动如何瞄准用户或者如何度量销售转化的分析。
我个人更倾向于认为，在产品和推广活动创建方面，画像比市场细分更有效，但在产品上市的执行和成功度量方面市场细分更有效。市场细分通常依赖受众的可观察特征，如他们在哪里和他们做什么，这有利于营销团队完成寻找目标客户群和落地执行的任务。画像则往往聚焦于受众需求中不太可见的那一部分，如驱使他们采纳和使用我们产品的那些因素。虽说打造一款针对 “创业型兼职者”的产品还算容易，但要在某个相似受众群体中定量识别并找到这批人就困难得多了。
如果打算同时使用这两种方法，我强烈建议读者设法找到一种简便方式用于映射它们之间的关联关系，而且能够理解和接受这种映射关系从来都不是1∶1的（例如，“伙伴”类软件公司里可能“爱因斯坦”和“埃尔维斯”两类开发者都有，大型企业中可能“莫特”和“埃尔维斯”两类开发者都有）。
将某个目标受众群体锚定在某个用户分类里的某个特定属性上，如角色、行业或编程语言，也是很普遍的一种实践。
● 用户角色：工程团队最常采用此方法用以说明在哪些工作活动中使用其产品的人，如后端服务开发者、Web应用开发者、移动应用开发者。
● 行业（或称“垂类”）：适用于不同类型的业务（例如，制造业、政府、教育业）领域存在自己的特殊需求、要求或行为的情况。
● 编程语言：这是一种不言自明的分组方法，如使用C++、Java、C#、JavaScript、Node、Angular的开发者。
用户属性对于理解产品被使用的方式和场景来说很重要，这道理我懂，但我仍然认为，以这些属性为锚点去定义或理解受众群体，可能会把我们引入一个过于狭窄的利基市场。此外，它还容易把我们带偏，让我们围绕产品特性讲故事，而不是去思考我们想要满足何种潜在需求。
画像最简洁的形式就是有背景故事和自己旅程的虚构角色，故事和旅程能让角色显得更有深度，也能增加对读者、工程师和商业合作伙伴的吸引力。
如果读者很有经验，可以基于个人直觉和跟开发者相处的经验来编写这个故事。如果读者还不太熟悉自家产品的开发者，可以选择组建焦点小组或者直接跟他们当面交流，以更好地理解他们。我认为，基本画像需要具备以下细节。
● 基本人口统计特征：若想让这个人显得更真实，可以给他取个名字，并基于对当前开发者群体的了解创建一个复合形象。如果读者近期在参加会议时遇到了某个足以代表自家产品用户群基底的人，也可以把他当作蓝本：他多大年纪？他在哪里生活？他在哪里工作？
● 客户旅程：现在再深入挖掘一下自身对开发者的理解（可以采用讨论、客户会议、焦点小组或调查等方式）。开发者的世界跟自家产品或平台是如何对接的？在他们穿越自己的世界并跟我们产生接触的时候，他们的旅程通常是什么样的？根据受众群体及产品成熟程度的不同，这个旅程可以是他们个人旅程（过去→现在→未来）的一种基本视图，也可以是那种传统形式的采纳漏斗（背景→认知→参与→采纳→倡导）。
● 动机和愿望：这个人的驱动力是什么？他为什么从事这份工作？他有什么动机？是什么激发了他？是谁激发了他？他的目标是什么？
● 痛点和恐惧：这依然与他的驱动力有关，只不过是从相反角度来看的。是什么让他夜不能寐？他畏惧什么？他焦虑什么？他有哪些盲区（已知的或未知的、专业的或个人的）？
制作完成开发者基本画像之后，我们开始深入研究这个虚构角色，探索足以塑造其旅程故事的另外两个特征。
● 转折点（采纳的触发器）：在他生活当中有哪些跟我们产品相关的重大时刻？是什么促使他走到了做出改变的那一点？探索这种改变的过程是怎样的？
● 采纳的引导师：我们可以为这个角色做些什么？我倾向于将这个问题拆解成至少3个组织级“行动召唤”（Call To Action，CTA），包括工程、计划和报价、营销。比如说，针对“可以做些什么来帮助鲍勃？”给出了1～3个非常清晰明了的行动召唤，用以指引我们切实帮助开发者尽可能地减少痛点、实现愿望。
写好基础角色故事之后，可以用市场趋势数据和事实来充实其内涵，让它变得更鲜活。这么做有助于完善画像，让它免受奇闻轶事的影响，并融入真实世界之中。为了达到此目的，我选择求助于调查数据和联合研究，它们总结了目标群体身边更宏大的市场趋势。
此时，有人或许会问，为什么只吸纳市场趋势信息和数据呢？其他东西，如果不是出自数据，那是出自哪里？让我们回顾一下定义画像的过程：作为某个群体的“目标和行为的代表”，我们是从了解他们的内在驱动力开始的，而不是他们的输出或者可观察的行为。如果我们一开始就用市场数据来定义分群，那就是在做市场细分了。
开发者画像样本集2012年，我开始着手构建首个画像集，即我在本章开头提到的那些画像。当时我在负责Windows手机的开发者营销工作，我们团队总共构建了5个画像作为当时市场上移动开发者群体的写照。
● 拉维（Ravi）：在大公司工作，公司希望将自家品牌定位为移动设备商，但他们并不是移动公司。尽管拉维是技术人员，但他却很有商业头脑，非常关注每一笔移动投资的投资回报率。
● 杰瑞（Jerry）：在移动优先型的小公司工作，该公司努力希望在平台创新方面取得领先。杰瑞有开发者背景，对身处移动行业感到非常兴奋。他知道自己擅长什么（编程），也明了自己不擅长什么（商业）。
● 拉娜（Lana）：移动开发者团队的一员，既是团队成员也是团队负责人，但在日常工作中，她也有参与到更大的应用或网站团队扮演着多个不同角色。她对自己的角色充满热情，很有雄心壮志，非常关心自己和自己团队的产出情况。
● 泰勒（Tyler）：兼职移动应用开发者，经常在夜晚和周末时分满怀激情地构建应用。尽管他并不以移动应用开发为谋生之道（通常是因为缺少原创知识产权或商业计划），但他认为需要对自己的应用和用户负责。
● 纳特（Nate）：移动爱好者，他涉足移动开发领域只是为了进行试验或学习，构建完成之后，他就不怎么关注也不怎么投入精力了。
需要注意的是，时至今日，移动领域相比早些年已经发生了很大变化，上述画像只能代表西方移动开发领域的旧况。这些年来，随着时代和营销团队需求的变化，画像本身也在不断地发展演变，以便能够涵盖PC、XBox、Web、物联网和混合现实设备等更多领域的开发者群体。
2012年那些画像，是基于多年来自然形成的包含定性和定量两方面的受众理解而生成的。我们还进行了持续一年的特定画像研究，并跟美国和西欧两地近百名开发者进行交谈，了解他们之所以从事他们所做工作的原因。画像研究形式也是我个人的最爱，我们点对点地采访开发者（也称为“二人组”），并提出诸如“如果你是一名超级英雄开发者，你的超能力是什么?谁会成为你的伙伴？”等问题。引导师很享受这些交谈带来的乐趣，还能让一群原本很有戒备心的开发者敞开心扉畅聊，帮助我们从中发现了一些心理瑰宝。
我想指出这些画像当中一些为模型增添了韵味的有趣元素。
● 开发者可以而且经常会呈现多幅画像——我见过很多开发者，他们在工作中是拉维或拉娜，但一到了晚上或周末试验新技术或平台时，就又变成了泰勒或纳特。
● 移动开发者画像同样适用于应用开发者和游戏开发者群体，这是公司内部长期争执不下的话题。通过聚焦于个体驱动力的探究，我们发现，尽管应用开发者和游戏开发者在技术、逆向工作表和团队角色方面有所不同，但他们却有着相似的个人目标和挑战。与此同时，小型组织或团队（杰瑞）和大型企业（拉维）之间也存在这种相似性，因为大多数的大型游戏工作室（如史克威尔·艾尼克斯株式会社）都将移动游戏视为主机和个人计算机产品的延伸（跟Facebook一样，当年它们也是将移动应用视为它们以桌面浏览器为主的用户体验的延伸）。
● 类似地，这些画像同样适用于东西方开发者厂商。在亚洲地区使用时，虽然我们也需要为杰瑞和泰勒的画像创造变体，以体现个体和文化驱动力方面的不同，但这些画像的核心是不变的。
我们还制作了很多参考资料用于充实这些画像，以提升其效用：我们为这些内容制作了一页着陆页、一份总体介绍这5个开发者的演示文稿（包括整套幻灯片和演讲录像）、这5个画像各自的专属幻灯片材料，以及我们为3个重点营销画像制作的辅助交付件（平台决策者拉维，以及杰瑞和泰勒）。
辅助交付件之一就是我们为这3个重点画像制作的墙面海报。图1-1是杰瑞的画像海报，从上半部分内容可以看出，海报试图让画像变得栩栩如生（说句题外话：杰瑞的头像照实际上是当时一位移动应用先行开发者的照片，为了营造真实的开发者氛围，我们特意以提供照片使用权的发布形式购买了专业头像照）。我们综合运用个人信息、真实移动开发者的真实言论、市场趋势数据（例如，出自SlashData等分析公司针对该画像类型的平台采纳趋势数据，相关内部调研及其他来源数据），让画像和客户旅程显得更加真实。
图1-1 杰瑞的画像海报
海报的下半部分专注于“我们怎么帮助杰瑞”，重点关注我们从开发者那里听来的常见问题：他们的动机、平台的选择、团队的诉求、流程的痛点、他们对代码的需求，及他们自己想要什么。这部分非常直截了当：左侧抛出引言（如在“流程”下面的“上市速度至关重要”），右侧则突出显示针对性的建议（如“在认证期间展现透明度——把他们的应用显示出来，这样他们就可以评估响应并快速迭代，从而快速发布流程”）。
这些画像海报就贴在公司走廊的墙上，既能帮助内部客户采纳我们团队的产品（即我们的研究和观点），也能帮助读者进一步了解市场和我们的目标客户，从而内化并真正应用这些画像。
使用画像画像到手之后，就可以拿来使用了，用于团队内外都可以。具体在哪里使用及如何使用，取决于我们所经营公司的类型。虽然有些研发伙伴在工程场景和产品价值主张工作中使用画像作为预期“受众速记”，但主要还是开发者营销组织在使用这些画像。事实上，在画像完工之后的5年中，我们团队越来越多地以这些画像为核心来开展营销工作。有关画像主题的教育性演讲，我做过很多次，以至于时至今日仍被微软某些部门戏称为“Windows画像人”，认同此道者对我很尊敬，但那些不理解此方式所蕴含价值的人也经常给我白眼。话虽如此，仍有不少人会请我喝一杯（含不含酒精或咖啡因的都有），他们都是那些曾经瞧不起画像概念，换过岗位或换过公司后又相信了画像的人。
在跟机构合作开展营销活动或内容开发时，我们团队使用了目标画像的简化版本（就是从一大堆幻灯片里抽取的10～12张幻灯片）。我们之所以这么做，起初只是因为有一家机构想要用它增进对受众的理解，但由于第一次尝试就产出了更好的营销用语，所以它很快就变成了我们请求建议书（Request for Proposal，RFP）流程的最佳实践。
如果已经做完了功课，并已知悉目标受众的动机，那么接下来就可以糅合自己在客户旅程和采纳决策方面的见解，针对受众类型构建营销计划了。
例如，在Windows手机部门，我们针对三大关键画像制定了不同的开发者营销提案。
● “拉维”型开发者：跟企业高管层决策者进行更广泛的对话通常是投资的关键，这时候我们都会叫上业务拓展团队一起参加。
● “泰勒”型开发者：我们跟诺基亚一起协同打造了名为DVLUP的游戏化的开发者计划，并在社区层面的参与下营造了充满乐趣和友爱的氛围。
● “杰瑞”型开发者：我们发起了多项计划和报价，旨在帮助他们改善业务（设计帮助、业务咨询和营销帮助），以及让他们感受到自己是我们生态系统的重要一员。
每个营销人员传递信息的方式都不相同。在微软，我们通常都会遵循标准的产品定位和信息传递框架流程。这个流程囊括了该产品的顶级营销信息和3个信息传递支柱。对于如何让产品信息和定位实现最佳匹配，这些内容已经远远超出了本章的范围，我更想探讨的是，怎么使用画像推动团队工作方式发展为类似信息传递框架那样的结构化产品。
经过几次迭代修订Windows手机开发者信息后，我们尝试调整方法，创建了内含4个变体的信息传递框架：一个遵循常规流程的核心信息框架，以及为3个关键画像量身定制的信息框架变体。该方法包括如下三个步骤。
首先，我们与开发者焦点组一起对我们的信息进行定性测试，以便能够从概念和措辞方面了解，对于我们最核心最精练的开发者信息，他们喜欢什么、不喜欢什么。
其次，继续问一些有关我们产品在更宽泛概念层面的问题，探寻其中可以让他们感到高兴或是“踩雷”的区域。
最后，针对这些受众调整信息，也有可能会调整信息的传递顺序，有时候甚至直接把某条核心信息彻底替换成另一条全新的信息。接着再回过头来，基于这些意见重新审视核心信息，评估是否需要对更高阶框架进行调整。
顺着这条路往下走，重要的是要以成长的心态来处理开发者信息。对我来说，早期跟一些专业焦点组的合作对我帮助很大，让我学会了如何带着好奇心（而不是试图去纠正那些最初可能会被视为误导或误传的观点）加入讨论，并获得有关为开发者打造故事的见解。
值得注意的是，我们用开发者画像来评估营销平台易用性的效果也很好。在思考如何选用或定位一个平台时，我们很可能会想到那些特性集，以及有什么、缺什么的复选框。这些思考只能解决定量那一半的问题，而体验是愉快的还是痛苦的，也即定性那一半同样重要。最近，我新见识了一种称为摩擦分析的方法。审视信息内容时，我们注意到不同画像对平台的体验是不同的。这又把我们带回到了“莫特、埃尔维斯、爱因斯坦”模型，用来分析他们使用用户控件构建用户界面（User Interface，UI）的方式。每个画像都想要一些不同的开发体验，也都有自己的需求和偏向的组合。例如，莫特想要快速直观地布置UI，他觉得UI模板非常高效；而埃尔维斯则非常重视可以微调用户控件属性和覆写默认行为的功能。
一旦理解了画像的视角，我们就可以针对受众群体正确地构建和定位产品了。把相同画像集共享给营销和工程部门，让所有团队使用同一视角来设计和构建产品。这样，特别是在将受众按优先级排序并阐明其诉求和需要时，构建满足受众需求并能取悦他们的产品就会容易很多。
画像创建技巧接下来，我们继续讨论创建画像的流程。正如本章前面部分已探讨过的，画像可以很简单也可以很复杂，可以很便宜也可以很昂贵，就看你如何选择。在本节，我汇总了一些在启动画像创建流程时需要考虑的要点。
当启动画像创建工作之后，重要的是要汇集包括扩展范围在内的所有干系人。我发现，要想了解受众知道什么，以及提供哪些附加信息能更好地满足他们的需求，让营销、工程和开发者关系等跟产品密切相关的关键人员参与进来非常关键。
我们建议读者也跟组织焦点组一样，把大部分时间都用来跟那些目标和心态一致的干系人座谈。而且，类似运作焦点组，也应该引入中立第三方或引导师（无论来自公司外部还是团队外部均可）以减轻干系人对组织偏见的担忧。在对话中，我们需要探索以下内容。
● 他们在工作中会如何运用开发者画像？
● 他们今天用了什么？
● 他们对目标受众了解多少？
● 如果必须将受众分成三组，他们会怎么做？
● 他们如何度量开发者受众的成功？
● 他们能否跟目标受众分享最新的业务进展回顾信息？
为了提高效率，可以拉通安排一场启动会，针对即将发生什么、何时发生，以及想要（需要）每个人做些什么设定好上下文边界。这不仅有助于定义待完成的工作，还能够让每个人都知道这项工作汇集了整个公司的声音和看法。
事情推进后，还需要跟所有团队就项目总体进展进行沟通，频率不低于每月一次。如果有调查结果涉及某个团队的问题或难题，还需要跟他们沟通其团队进展。不要低估开展更大范围团队沟通的价值，让每个人都厘清项目的全过程，有助于他们从更广的视角去看待画像，而不是只从自己的角度出发。
如果我们负责的是产品管理或开发者营销，那么审视我们现有的客户群细分，以及公司针对市场细分采取的上市策略就显得尤为重要了。正如我们之前探讨过的，有很多种方式可以用来拆解重组受众群体，每个人都可以用自己的方式来切割和拆分受众群体。
我们需要用业务语言说话，还要清楚说明打算怎么让画像进入市场，才能让画像扎根于业务。如果不能以此方式勾勒画像，那我们将会耗费大量时间跟现有模型作斗争，费劲解释画像a跟细分市场b的关系，或者承担所有工作成果都变成“摆设”的风险。拉通整个公司统一对齐目标和受众以推动组织前进，这才是我们使用画像的初心。
在构建画像时，别把所有时间都用来躲在单向玻璃背后静观。虽然付费研究也能产生应有的效果，但到开发者身边观察他们原生态的行为表现，去了解这些开发者，同样至关重要。
● 去开发者的工作环境实地拜访。构建画像时，要融入开发者受众群体并跟他们交谈，以了解他们做了什么、为什么做，以及在哪里做的。到了那里，记得多拍些照片供报告使用。因公出差时，可以找几个当地开发者聊聊天，无论通过领英（LinkedIn）跟他们联系，还是通过自家工程团队或开发者关系团队跟其中一些人取得联系都可以。如果他们是客户或伙伴，他们会很乐意看到我们的拜访。
● 在活动中跟开发者交谈。参加相关活动时，可以在自家展位上多待会儿，或是动动腿在房间里多走走，介绍介绍自己，多结识些人脉。一开始可能会感觉有点怪，但你会惊讶于自己在活动中通过谈话得到的收获。这是以非引导性的视角获取有关自家公司、市场和开发者所思所想信息的绝佳途径。毕竟，这些参会者都是付费来参加活动的，因此他们必然已经在此议题上有所投入。
在我们开始理解业务需求及开发者的诉求后，就是时候发挥创造力并进行迭代、迭代再迭代了。这部分过程不像科学，更像是黑魔法，但也有些方法效果很好。
● 便利贴：在本章“画像的特征”部分，我喜欢把感兴趣的东西都写下来，然后再找出（他们之间的）共性，就像是基于数量的聚类分析方法……只不过这些都是他们脑海里的东西。
● 三问变速箱：在分组时，注意看是否可以挑选出3～5个可以定义这个组的特征。为了便于理解想要触达哪些画像，或是要测试哪些信息，可以把这些特征转变成用于调查或活动注册时提出的3个调查问题。如对于移动应用开发者画像来说，问题可以是他们为什么这样做（纯粹出于爱好、兼职、利润）；团队或公司的规模；决策权。
● 颗粒度：通常，用于呈现受众的角色画像不宜过多，我们应该尽可能地进行简化和合并，但仍需维持在一定的颗粒度水平，以确保画像有效。
● 测试：最后，额外构建一个角色画像组合，用于跟干系人和工作交付件一起进行验证。如果有助于推动进展，那就太棒了！如果不行，那就该迭代了！
总是在奔忙画像虽然完工，工作可不会停下来。这跟我们的工程伙伴很像，实现了一个最小可行产品，那就把它交付出去，然后继续奔忙并迭代推动其持续改进。
不管工作在小公司还是大企业，都千万别低估在内部宣传推广工作成果的重要性，人们要么采纳我们的成果，要么把它们放在架子上吃灰、锁在某个文件夹里或是遗弃在某个怪玩具堆里。就我个人经验来说，专题海报和月度专题演示都很有效。但读者的情况可能会有所不同。
完成构建并交付初始产品（记住，一直在交付）之后，还要检查一下是否存在无意识偏差与样本偏差。就我们的情况来说，我们是基于美国和西欧地区的经验与数据点来构建画像的。随后一年，我们在亚洲（包括中国、印度、日本和韩国）地区进行了测试，发现了一些有意思的文化差异，它们影响着社区互动和职业发展等不同方面。比如中国，尤其是在中国一线城市，我们发现大多数开发者都不太有兴趣冒险去尝试那些新的或截然不同的平台，他们担心这会导致他们偏离从编程向管理方向发展的轨迹。
如有必要，调整我们的画像，或者记下如何根据当地情况或受众的变化去执行营销活动。
永远在学习最后，科技行业是不断变化的，我们（和我们的画像）也应该做好随之变化的准备。始终带着成长心态去工作，并假定所做的一切都需要进行年度审视，以确保我们始终跟开发者所代表的市场保持着密切联系。
● 评估产品是否触达了目标画像群体，是营销事后分析（针对事件、系列活动和发布）工作的一部分。我们有触达目标开发者吗？另外，接触到的开发者与目标画像吻合吗？比如在我们的故事里，画像“杰瑞”在他生命的第一年里就有了很大变化，团队从1～2人变成了1～5人，从专注于创业的开发者变成了赋能者之一。
● 跟受众待在一起，每年至少应参加2～3场开发者活动。注意，自己举办的活动不算！就像构建角色画像时所做的那样，跟开发者谈谈，确保我们跟社区的脉搏同频。如果感觉到受众的情绪或动机正在发生变化，那就是时候重新审视一下我们的画像了。
● 最后，跟紧行业趋势，并确保团队每隔2～3年彻底重新评估一次角色画像，以确认分组是否仍然有效。尽管某些分组可能是常青树（莫特、埃尔维斯、爱因斯坦），但本章介绍的移动开发者画像则肯定会变得过时并不再有效。持续审视行业视点，有助于避免在受众群体变得越来越小的时候，身处泡沫之中而不自知。
久而久之，你可能会变得跟我一样，把角色画像当作一组亲密的虚拟朋友。记住，还在一起的时候就要享受跟他们共处的时光，并准备好在分道扬镳之际跟他们坦然道别！
