Working Backwards 与以客户为起点的创新 - AWS 服务开发与其他厂商根本不同的原因
解析 AWS 服务开发流程核心的 Working Backwards（逆向思维），分析从 PR/FAQ 开始的以客户为起点的开发文化与 Azure、GCP 产品开发方式的差异。
服务质量由开发流程决定
在云服务比较中，功能列表和基准测试结果往往受到关注。然而，决定服务长期质量和进化方向的是其背后的开发流程和组织文化。AWS 的服务开发基于名为 Working Backwards（逆向思维）的独特流程。这一流程根植于 Amazon 整体的文化，是 AWS 服务「解决客户真正需要的问题」而非「展示技术能力」的根本原因。
Working Backwards 的具体流程
Working Backwards 是从「客户体验」逆向推导来推进产品开发的流程。当新服务或功能的想法产生时，AWS 首先从撰写新闻稿（PR）和 FAQ 开始。这份新闻稿是内部文档，不会对外公开。新闻稿中需要写明该服务为谁解决什么问题、对客户的具体好处是什么、与现有解决方案的区别在哪里。FAQ 部分预想客户和内部利益相关者的问题并准备回答。如果新闻稿无法清晰地传达客户价值，则该想法会被退回重新审视。这一流程确保了在投入开发资源之前验证客户价值。
90% 源自客户的声音
AWS 公开表示「90% 的服务源自客户的声音」。这不仅是营销口号，而是 Working Backwards 流程的必然结果。AWS 的产品经理通过与客户的直接对话、支持工单分析、论坛反馈、re:Invent 会后问答等多种渠道收集客户课题。收集到的课题经过优先级排序后，成为 Working Backwards 流程的输入。剩余 10% 是 AWS 基于技术趋势预判客户未来需求而主动开发的服务，但即使这些也以客户课题的假设为起点。
Azure 的方式 - 与 Microsoft 生态系统的整合
Azure 的服务开发以与 Microsoft 现有产品群的整合为重要轴心。Active Directory 与 Azure AD（现 Entra ID）的整合、Office 365 与 Azure 的联动、SQL Server 与 Azure SQL Database 的兼容性、.NET 与 Azure Functions 的亲和性等，Microsoft 生态系统内的无缝体验是 Azure 的核心价值主张。这种方式对已经使用 Microsoft 产品的企业来说是巨大优势，但对 Microsoft 生态系统之外的用户吸引力有限。
GCP 的方式 - 技术驱动的创新
GCP 的服务开发倾向于以 Google 的技术优势为起点。BigQuery 是将 Google 的大规模数据处理技术（Dremel）对外提供，Kubernetes 是将 Google 内部容器编排（Borg）开源化，Spanner 是将 Google 内部分布式数据库商业化的服务。这种技术驱动方式产生了技术上先进的服务，但有时会出现「技术上优秀但客户不知如何使用」的情况。GCP 的服务文档有时偏向技术说明而缺乏实践指南，这也是技术驱动文化的反映。
开发文化的差异决定服务的性格
三家的开发方式差异明确反映在服务的性格上。AWS 的服务聚焦于「解决客户课题」，倾向于优先实用性和运维便利性而非技术精致度。文档充实、对边缘情况的处理细致也是以客户为起点的开发文化的体现。Azure 的服务以「与 Microsoft 生态系统的整合」为优势，对现有 Microsoft 用户提供无缝的迁移路径。GCP 的服务以「技术先进性」为优势，在特定领域（数据分析、ML、容器）提供最先进的功能。 如需了解 AWS 的开发文化和创新方法论，相关书籍 (Amazon) 也可供参考。
总结
AWS 的 Working Backwards 流程将从新闻稿和 FAQ 开始的以客户为起点的服务开发制度化。这种文化使 AWS 的服务根植于客户的实际课题，支撑着 90% 源自客户声音的实绩。Azure 以 Microsoft 生态系统整合、GCP 以技术先进性为各自的轴心，但在以客户为起点的开发文化的彻底程度和由此产生的服务实用性方面，AWS 保持独特的优势。