Working Backwards 的实践 - PR/FAQ 的写法与 Amazon 式产品开发流程
解说 Amazon 创造的 Working Backwards 流程的详情、PR/FAQ 文档的结构与写法、PR/FAQ 与 6-Pager 的选用，以及在企业自身项目中采用的方法。
什么是 Working Backwards
Working Backwards 是 Amazon 一直以来使用的产品开发流程。它不是以技术或业务方面的情况为起点，而是先定义理想的客户体验，再从那里倒推，明确应该构建什么。它诞生于 Jeff Bezos 的领导之下，是一种即使规模扩大也不降低创新质量的机制。这一流程的核心是一份名为 PR/FAQ 的文档。在写下哪怕 1 行代码之前，先写出产品完成时要发布的新闻稿和预想的 FAQ，以此验证对客户而言是否真的有价值。
PR/FAQ 的结构与写法
PR（新闻稿）例如由以下要素组成。（1）标题：用一句话表达对客户的价值。（2）副标题：补充目标客户和主要收益。（3）问题段落：具体描述客户当前面临的问题。（4）解决方案段落：说明该产品如何解决这一问题。（5）客户之声：写下虚构客户的推荐评论，从客户的视角表达价值。（6）开始使用的方法：展示客户立即开始使用的具体行动。FAQ 由外部 FAQ 和内部 FAQ 2 部分组成。外部 FAQ 回答客户视角的问题（使用方法、费用、限制、与现有服务的区别）。内部 FAQ 回答公司内部利益相关者视角的问题（技术可行性、开发成本、收益模式、风险）。
叙述文化以及 PR/FAQ 与 6-Pager 的选用
在 Amazon，会议不使用 PowerPoint，而是使用叙述（文章）形式的文档。条目式的幻灯片容易掩盖逻辑上的跳跃和模糊之处；与此相对，用文章来写，作者会深化思考，读者也能一边确认逻辑的衔接一边读下去。在会议开始时安排所有参会者默读文档的时间，在所有人掌握相同信息的状态下开始讨论。PR/FAQ 和 6-Pager 的用途不同。PR/FAQ 用于新产品或新服务的提案。它是用来验证尚不存在之物的价值的文档。6-Pager 用于对现状的理解和方向的决定，例如现有问题的分析、战略提案、年度计划等。两者都以短小的篇幅写成，因此也兼作提炼要点的练习。
在 AWS 服务中的应用案例
Working Backwards 流程也一直被用于 AWS 服务的开发。例如，S3 是从“开发者用一个 API 就能使用可扩展的存储”这一客户体验倒推设计出来的。Lambda 诞生于“想在完全不管理服务器的情况下运行代码”这一客户的声音。这一流程不仅适用于新服务，也适用于现有服务的功能添加。将客户提出的需求以 PR/FAQ 的形式整理，并在团队内评审，从而在开发前判断该功能对客户而言是否真的有价值。PR/FAQ 缺乏说服力的提案，即使在技术上有趣，有时也不会进入开发。
在企业自身项目中采用
Working Backwards 并非 Amazon 独有，任何组织都可以采用。第一步是尝试为接下来要开发的功能或服务写一份 PR/FAQ。如果无法在标题中用一句话概括客户价值，该项目的目的可能是模糊的。如果无法在问题段落中具体描述客户的问题，说明对客户的理解不足。如果无法在 FAQ 中回答技术可行性或成本的问题，说明研究不充分。撰写 PR/FAQ 本身，就会成为重新审视项目目标的思考过程。如果让全体团队成员默读并反馈的文化扎根，就可以减少开始开发后的返工。
在动手构建之前停下来的判断
PR/FAQ 的重要作用之一，是成为判断是否着手开发的关卡。在将完成后的样子写成新闻稿、并为预想的疑问准备答案的过程中，该企划是否真的解决客户的问题、是否有价值，就会变得清楚。如果写成文章后发现缺乏说服力、无法完全回答疑问，那就是尚未到应该构建的阶段的信号。在向实现投入大量资源之前，可以在成本低的文章撰写阶段判断是放弃还是重新推敲。这种在开始构建之前停下来审视价值的纪律，会降低花费了精力却做出无人使用之物的风险。
总结
Working Backwards 是从客户体验倒推来设计产品的 Amazon 式开发流程。通过 PR/FAQ 将新闻稿形式的假设文档化，并在叙述文化中通过深入的讨论打磨创意。将这一也被应用于 AWS 服务开发的方法引入企业自身的项目中，会带来以客户为起点的产品开发。
参考资料（AWS 官方）
本页的第一手信息来源是 AWS 官方网站及官方文档。最新的规格与价格请以下列官方页面为准。
如本页内容与官方文档不一致，请以官方文档为准。