近期终于有了大块的时间打算把自己做开发者关系的一些经历都梳理出来。背景我们做了一个类似 Windows 注册表的配置管理模块并在上面增加了配置叠加和分层权限管控。它的核心价值是这样的之前之后系统集成团队想改某个应用的行为比如禁用休眠需要找研发提需求、排期、改代码直接修改配置文件系统集成团队自己操作不再依赖研发省的不是体力而是沟通和排期成本。但上线之后几乎没有开发者主动接入。冷启动过程第一步重写文档采纳率低我们首先想到的是开发者不会用。既然不会用那就写清楚一点——这是最直觉的反应。于是我们重构了使用文档把接入步骤梳理得更清晰加了示例配置。文档确实好读多了阅读量也上去了。但接入率几乎没有变化。同时在写文档的过程中我们也意识到机制本身很复杂而我们只是把这个复杂的机制讲清楚了并没有把它变简单。我们只是降低了学习门槛并没有降低学习成本。机制复杂带来的是看懂了也觉得麻烦。两个问题需要两种解法我们当时只做了前者。第二步培训利益相关方手把手陪跑文档没有解决问题我们意识到光等开发者自己来学是不够的需要主动出击。系统集成团队是最大的受益方先让他们真正用起来再借助他们的影响力带动其他开发者——这是我们当时的想法。于是我们培训了这个团队帮他们理解机制怎么运作、怎么使用同时开始主动找开发者陪跑——约会议、当场演示、一起调试。陪跑确实有效一些开发者在我们的帮助下成功接入也开始认可这个模块的价值。但覆盖范围非常有限没有人推的地方依然原地不动。更根本的问题在培训过程中被系统集成团队指了出来这个产品的出力方和受益方是分开的。 系统集成团队是受益方接入越多他们能管控的范围越大但接入这件事要靠研发来做。研发花时间接入收益却归别人对自己没有直接回报。这是一个激励结构问题陪跑只是用我们自己的时间去补贴这个成本本质上无法规模化。第三步提供配置转换工具激励结构短期内改变不了我们转而想能不能降低研发的接入成本——让接入这件事变得足够简单即使没有直接收益开发者也愿意顺手做了。为此我们开发了一个转换工具让开发者把原有的配置格式自动转换成我们的格式。工具做完了也没什么人用。回过头来想问题很清楚——转换工具的逻辑依然是你来适应我们。开发者还是需要主动发现这个工具、学会怎么用、然后执行迁移。只要需要开发者主动行动就会有摩擦激励不对齐的问题也依然没有解决。第四步直接兼容 gsettings转换工具失败之后我们意识到问题不在于工具够不够好而在于还是要求开发者主动做一件额外的事。真正的解法应该是让开发者什么都不用做——我们去适应他们而不是让他们来适应我们。Linux 生态里有一个成熟的配置方案 gsettings很多开发者已经在用了我们决定直接兼容它让系统读取 gsettings 的配置格式并自动转换开发者什么都不需要改。结果是决定性的采纳率大幅提升最终达到了原来的 4 倍。这一步和提供转换工具表面上都是在做格式转换但逻辑完全不同提供转换工具直接兼容 gsettings谁来行动开发者我们迁移成本开发者需要发现、学习、执行开发者什么都不用做心理门槛我要改东西直接就能用结果没人用采纳率×4降低采纳门槛最有效的方式不是教育用户而是消除迁移成本。兼容 gsettings 同时也绕过了激励不对齐的问题——当接入成本趋近于零出力这件事本身就变得微不足道了。后续正向飞轮转起来了接入的应用越来越多系统集成团队可以统一管控的范围越来越大权限管控的价值开始真正兑现。之后新项目配置我们会直接引导接入我们的配置体系不再走 gsettings。先把门槛压到最低让人进来再慢慢建立使用习惯这是开发者产品冷启动的正确顺序。总结我学到的四件事1. 好文档降低的是学习门槛不是学习成本。文档清晰之后阅读量上去了但接入率没有同步增长。更值得注意的是写文档的过程本身是一次产品审计——我们在整理文档时发现了机制过于复杂但没有推动去简化它。清晰的文档是必要的但它替代不了对产品本身的打磨。2. 出力的人和受益的人如果不是同一个采纳率天然有上限。激励不对齐的问题靠文档和培训都解决不了。我们最终的解法是把迁移成本压到接近零让出力这件事变得微不足道绕过了激励问题而不是真正解决了它。3. 工具解决不了意愿问题。提供迁移工具本质上还是在把成本转嫁给用户。只要用户需要主动行动就会有摩擦。4. 最好的开发者体验是无感迁移。让开发者用已有的习惯就能接入你的系统是降低门槛的天花板。兼容存量生态比建设新生态容易十倍。