《开发者关系 - 方法与实践》读书笔记 - 第一部分形成广泛的共识
第二篇读书笔记贴到 Facebook 账号后，有朋友来问怎么都是序，我承认读书太慢，这次出差到南京的火车上再次拿起随行的这本书，把第一部分形成广泛的共识的第1章开发者关系基本概念读完了，现在感觉这本书不是一本讲道理的书，而是一本给项目经理的手册。
在启动开发者关系项目之前，相关人员有必要对开发者关系形成广泛的公司和。这里的“相关人员”指的是开发者关系的从业人员和开发者关系业务的利益相关者，其中不仅包括企业的最高管理层，如首席执行官和董事会成员，也包括所有涉及开发者关系活动的部门（如首席技术官办公室、市场部门、产品部门、客户服务部门等）的员工，还包括公司外部的团队（如营销机构、公关公司或承包商）的成员。
看完这第一段让我有点不知所以然，这么重要的话题不是应该更深层次的讨论，达成广泛共识的基础是什么？翻了翻这一部分的其余 4 章，并没有对达成共识基础的内容。第 4 章开发者的经济价值看上去是讲开发者能产生的价值，对于形成共识并不具有指导意义。
在商言商，一个公司的核心利益是为股东服务的，说直白点就是为了“赚钱”，所以一个公司讲自己不赚钱而做什么样什么样的开源，贡献社会共建社区，千万别信这就是骗局。我的观点是，经济价值的体现，是公共你是内形成广泛共识的基础。一个产品如果通过开发者关系获得利益，也就得到了这个产品团队、研发团队的共识，不管这个利益是有形资产还是无形价值。一个主要面向 2B 国产新创的操作系统，你说让它变成一个所有开发者都使用的操作系统，带来新的收益者明显是和产品价值逻辑不相符的，所以不会得到相关产品团队和研发团队的共识。即使采用“硬广”砸钱的方式宣传，也改变不了它不是为开发者服务的根本，其所谓的看到这关系不过是公司政治层面的一朵绣花而已。共识的基础是共同的价值，不能带来价值就没有共识。
在前言中有一些文字，也带来对共识的思考，就是谁对开发者关系而负责？
开发者关系（Developer Relationship，DevRel）的定义在行业内和行业外均存在着分歧，这反应了开发者关系的复杂性。事实上，每一家已有或计划开展开发者关系项目的公司，都应任命一位与 CTO、CIO 同级的开发者关系负责人（Chief Developer Relation Officer，CDRO）。只有开发者关系负责人在企业中为开发者发声，才能确保开发者关系部门的工作与公司核心的战略部门保持一致。
这些文字的背面透露着作者也不愿说的事实，其实在当前的国内外企业中，都没有定义清楚到底谁为开发者关系而负责，引申的就是开发者关系价值没有被接受，负责开发者关系的预算也无从着落。这一系列尴尬的背后，说明开发者的价值还不被主流经济模式接受。从我的观点，产品是开发者关系的最终受益者，每一个产品经理都应该具有相关的意识，这是产品设计的核心逻辑。在之前的一次演讲中介绍过我对 TKEStack 产品设计的逻辑，大家可以在 B 站看到我的表述。如果有哪个公司在找 CDRO ，真心推荐我的朋友，也是这本书的译者林旅强，可以找我要他的联系方式，请用推荐费请我喝啤酒 😂 。
你可以通过一对一的交流加你共识，但更好的做法是在开发者关系项目启动会上，让所有利益相关者聚在一起，充分沟通，发现并解决跨部门的问题和争议，最终达成一致。
这个我就完全不认同了，在国内公司的传统做法就是学习外企搞个项目启动会，共识不共识的不是关键，关键是要请一位高层领导来展台，压住下面各个心怀鬼胎的利益方在表面达成一致。我更喜欢一对一的交流，通过信息不对称形成一个小闭环，让事情进展下去，达成一致这种事儿是不可能的，还是让幻想早点破灭吧 😂 。
事实上，开发者关系团队需要投入足够的时间和精力，比如召开项目例会、定期汇报进度，确保重要利益相关者了解开发者关系项目的进展，并持续提供支持。
这个翻译一下就是因为价值归属不明确，必须经常去高层汇报，从高层获得支持持续向各利益方施压维持，这真是一个又累又卷又不讨好的工作。
以下是第 1 章开发者关系基本概念阅读时的一些记录。
事实上，开发者关系至今尚未成为高等或专科教育的一门专业，也没有形成类似开发者关系协会的专业性组织。
国内一些开发者媒体在当前充当着这样的橘色，有总比没有好。但是这样的媒体属性，必然是偏向利益驱动的，专业性就打折扣了。
开发者关系包括两个方面：在企业外部，想开发者推广技术产品；在企业内部，促进开发者关系项目取得成功。
其实这就是我执意这本书是一个手册的原因，连共识是什么都没有观点，怎么能定义成功呢？ 现在的开发者关系全屏公司高层对这个事儿的理解，所以才有前文要搞启动会、例会和汇报等内容。如果不仔细分析，还以为作者在某某公司工作过，某某是哪家公司请勿对号入座 😂 。
开发者体验通常所写为 DX（Developer Experience），位与树冠的中心，它是任何开发者关系的核心。
国内的产品逻辑是让管理者更好的管理开发者，让他们朝九晚五，产品的核心价值用户是管理层。因为管理层是能决定买单的人，所以国内产品的逻辑不是解决开发者的问题，是解决提出问题的开发者。
开发者培训（Developer Eduction）对开发者采用平台技术至关重要。
这个是好事儿，但是经常演变为卖证书。开发者为什么要买证书？因为招标文件上有证书数量要求。为什么招标文件上有证书数量要求？问太多了就不好了。要问还是问为什么开源还要定标准这事儿吧。
正如树木的成长离不开树干和树根，成功的开发者关系项目离不开活跃的开发者社区（Community）。整个嗯开发者关系项目的核心目标就是要融入、服务并且培育你的开发者社区。
这里的问题来了，这里 ”你的社区“ 到底是谁的社区。从公司角度来讲肯定是属于公司的社区，社区的人需要接受公司的管理和领导，社区不容许分裂等等。如果这是一个开源社区呢，上面的逻辑还成立么？
共识在一家商业公司中是非常难，如果没有乔帮主那样的大神镇场子，Apple 不会成为现在这样的公司，每个公司都应该有一个灵魂人物，这个人是影响到公司对开发者关系的认知。 开源社区也是一种精英社区文化，少数人领导多数人。所以开发者关系在国内的推动我觉得一两本书是不可能让那些“商业领袖”认识到价值，国内需要一个强开发者关系的伟大产品和其精神领袖才能让这个相对封闭的体系认可生态带来的可能性。
文章评论，请到 Craft 链接