在某海外音频科技公司的“产品故事”播客第八集中，我们分享了构建并开源内部开发者门户的故事，以及从中获得的经验教训。

对于快速增长的工程组织来说，内部开发者门户的价值不只是集中展示工具和服务，更在于提升开发者体验、降低上下文切换成本、改善服务可发现性，并帮助新工程师更快进入有效贡献状态。类似地，在企业实际落地研发管理时，也需要有工具承载从目标、反馈、需求、开发、测试、发布到知识沉淀的完整链路。例如，PingCode 这类智能化研发管理工具，可以帮助团队把研发管理过程自动化、数据化、智能化，让研发过程中的信息更顺畅地流转起来。

你将了解到，为什么这样一个对开发者友好、以平台市场为导向的开发者门户，只能诞生在一个高度重视自主权，而不是依赖自上而下命令的组织中；也会看到，为什么这种产品最终能够以灵活的方式适用于其他公司。

如果你想用轻松有趣的方式了解这些来之不易的经验，可以直接收听这一期节目；也可以继续阅读下文，了解本期亮点，并回顾这家公司发展历程中的一个关键阶段。

起因：新员工入职效率低，“就像洗了个冷水澡”

故事始于五年前。当时，这家海外音频科技公司遇到了一个难题：公司发展得太快了。真的，太快了。

这本该是个令人羡慕的问题。但现实是，不断增加的新员工并没有让组织跑得更快，反而拖慢了整体速度。

正如一位工程总监在播客中解释的那样，平台团队用于衡量生产力的指标之一，是新员工完成入职并进入有效贡献所需的时间。更具体地说，他们关注的是：一名新工程师加入公司后，需要多长时间才能合并自己的第十个拉取请求？

答案并不理想——超过 60 天。

也就是说，从工程师踏入公司大门那天算起，还要再过两个月，他们才能以第十个拉取请求的形式贡献代码。

但单凭数字，并不能完全传达那种冲击感。播客主持人问这位工程总监：第一次看到“60 天”这个指标时，她是什么感受？

主持人问：当时你的感觉是“也许还可以”？还是“这看起来太长了”？

工程总监回答：我之前在其他公司做了 15 年工程师，看到这个数字时，感觉就像被泼了一盆冷水。

确实很冷。

于是，她所在的团队首先要做的，就是弄清楚到底是什么让新员工如此沮丧。为什么员工人数持续增长，生产力却不断下降？

开发者体验的前提：工程师也是用户

对于自己的员工，公司往往会忽略用户调研。毕竟，与其询问，不如直接发号施令来得快，对吗？

但这家公司的平台团队并不这样看。他们把内部开发者视为自己的客户。开发者的优先事项，就是平台团队的优先事项；开发者的痛点，就是平台团队需要解决的问题。

因此，为了找出影响工程师效率的因素，他们首先要做的，就是直接询问工程师。

根据这位工程总监的总结，导致生产力下降的常见原因主要有两个。

第一个是上下文切换。

人们经常被打断。新员工不得不不断向别人请教，因为几乎没有足够清晰的文档可供查阅。

第二个是可发现性。

人们找不到自己需要的东西。就是这么简单。找到合适的服务要花很长时间。生态系统中存在许多几乎重复的服务——它们并不完全相同，但差异也没有那么大。工程师都很聪明，他们会意识到这一点。

同一个服务可能有 15 个不同版本，每个版本都针对不同团队的轻微差异做了调整。如果一个新团队也需要类似服务，会发生什么？

他们通常不会花大量时间筛选所有现有版本，而是干脆再为自己构建一个新的版本。

某种程度上，这正是这家公司过去行之有效的方法：小型、自主的团队快速构建。但这种基础的敏捷模式已经接近极限。团队越多，混乱就越多，而新员工入职效率指标已经证明了这一点。

新员工甚至不知道从哪里开始，更别说理解那团如“意大利面条”般缠绕在一起的代码和服务生态了。除非他们去问其他工程师，否则根本无从下手。

这种工作方式变得越来越普遍，以至于团队给它起了一个名字——“谣言驱动开发”。

随着公司持续发展，这个问题只会越来越严重。

平台工程的难题：速度、规模、自主性，只能选两个吗？

既然问题已经明确，解决方案似乎也很明显：集中化。

但同样显而易见的是，集中式团队的效率往往远低于众多小型团队。那么，这家公司是否必须用速度来换取规模？

事实证明，这个问题本身并不成立。

平台团队肩负着恢复生产力的责任。他们意识到，自上而下、集中式的方案在这家公司行不通，而且原因不只是执行难度高，还有一个更根本的问题：它不符合这家公司的文化基因。

正如那位工程总监在播客中解释的那样：

所以我们基本上知道，自己无法构建一个集中式解决方案。它根本行不通。没人会用它。甚至我们自己内部也没人真正相信它。我们加入这家公司的原因，就是我们都热爱自主性。我们认为赋予人们自由是一件很棒的事。因此，那里的企业文化深深影响了我们：你不能选择构建一个中心化系统，然后强制所有人使用。

换句话说，这家公司过去的工程优势，如今反而成了阻碍：过大的自主权。

但正是这种自主文化，也催生出了一种比简单的技术需求清单或自上而下指令更好的解决方案。正如一位工程副总裁所说，开发者门户要想在工程师中获得成功，它必须是一个更好的选择，而不是唯一的选择。

他说：

大多数情况下，如果我们告诉人们该做什么，他们只会耸耸肩，然后继续按自己的方式做。所以我们真的需要说服他们。我们所做的一切，都必须让他们的工作变得更轻松。因此，如果我们想治理技术生态系统中的碎片化问题，企业文化确实会影响我们采用的方法。

这家公司想要的是一个能够同时满足所有需求的工具：速度、规模，以及它所珍视的自主权。

这就是内部开发者门户诞生的背景。

内部开发者门户的效果：不仅被采用，而且被欣然接受

如果没有人使用一个产品，我们就无法知道它是否真正有效。

如今，在这家公司内部，每天都有 280 个工程团队使用这套开发者门户，管理 2000 多个后端服务、300 个网站、4000 条数据管道，以及 200 个移动端功能。

更令人印象深刻的是贡献数量。公司内部已有超过 200 位工程师为这套开发者门户贡献功能。目前，50 多个团队开发了 120 多个插件。而且，80% 的贡献来自核心团队以外的内部用户。

用户可以轻松找到所需内容，而不必不断打扰其他开发者。任何内部用户，不仅是工程师，也包括合规和安全团队成员，都能轻松发现技术生态系统中的所有软件，查看它们的所有者，并在统一位置访问技术文档。

在一个追求速度、且高度去中心化的环境中，能够如此便捷地获取这些信息至关重要。对于更通用的团队协作场景，Worktile 这类项目协作系统也能帮助团队把任务、项目、文档、目标、日历、甘特图、工时和审批等信息统一管理起来，减少协作过程中的信息分散和反复沟通。

对于一家快速发展的公司来说，这无疑是一项颠覆性改进。它显著提升了生产力，也提升了开发者满意度，而我们认为这两者密不可分。

这家公司也相信，开源版本同样能够改变其他科技公司。开发者门户的诞生，正是他们像对待用户一样用心对待开发者的体现。根据公司内部调查，80% 的内部用户对这套开发者门户感到满意。

想知道后来发生了什么吗？

想知道接下来发生了什么吗？

那项令人胆寒的“60 天合并第十个拉取请求”入职指标，后来究竟被缩短了多少？

这套自主开发的开发者门户，又是如何发展成为公司最大的开源项目的？

还有，那个看似不起眼的服务目录动画，究竟有什么意义？

完整故事可以在“何时自建、何时购买、何时开源”这一期节目中找到。你将听到几位亲历者的分享，也会听到一家采用“开放核心”模式的海外技术公司创始人的观点。

如果你想了解更多这家海外音频科技公司的创建历程，并直接听亲历者讲述，也可以继续收听“产品故事”系列。这个系列分享了他们在产品战略中学到的重要经验，并由亲历者亲自讲述。

在每一集中，公司首席研发官都会与内部嘉宾和外部特邀嘉宾一起，讲述产品、技术和战略背后的故事。

比如：

P2P 网络和本地缓存，如何在第一款应用中创造出近乎神奇的体验？

公司又是如何从把服务器塞进橱柜，发展到运行超大规模云端数据处理任务的？

构建真正以机器学习为优先的产品，究竟意味着什么？

创作者和音频格式的下一个前沿，又会在哪里？

这些问题，都可以在这个系列中找到答案。