《谷歌和亚马逊如何做产品》摘录

xman

阶段一，确定正确的产品方向。如果总是设计垃圾软件，那么你永远不可能交付卓越的产品。好的产品一定要满足众多客户所共有的某个真实的需求。你的使命就是找到一种独特而有意义的方法去满足这一需求，并且在交付过程中的所有努力都应围绕着这个使命。

阶段二，尽可能清晰详细地定义产品。这个过程需要10个主要步骤，包括撰写新闻稿、创建并不断更新FAQ文档、撰写功能需求文档等。

阶段三，设计用户体验。你需要从用户的角度出发，和设计团队不断沟通、反复迭代，最终构建出良好、直观、简洁的用户体验。你应不断提出问题，促使设计团队始终围绕着产品使命展开工作。

阶段四，做一些基础的项目管理工作，不要太多也不要太少。当工程团队拿到详细的产品原型图和需求文档开始编码后，你就需要做一些基础的项目管理工作了，包括跟踪交付物的进展、指出问题以及控制项目范围。

阶段五，开始测试。随着各个功能的代码块陆续提交，实际产品逐渐浮出水面，团队的工作速度将会提高，测试团队也将开始全心投入测试。这一阶段虽不需要多少创造性，却依旧令人兴奋不已。作为团队主管，你需要主导bug的处理并慎重决定哪些可以容忍出现在版本1而哪些又必须在发布之前修复掉。

阶段六，你差不多可以准备发布了，不过在发布之前要清楚知道怎样才算成功，这就要求你建立一套衡量产品成败的指标。让团队

阶段六，你差不多可以准备发布了，不过在发布之前要清楚知道怎样才算成功，这就要求你建立一套衡量产品成败的指标。让团队利用剩余工时来把这些指标纳入监控并搭建产品状态面板。

最后，正式发布产品。发布一款卓越的产品可不只是上传一些文件到服务器上那么简单，你需要制订市场营销和公关方案，并在发布前仔细核查清单中的每一项内容。基

亚马逊CEO杰夫·贝索斯一直强调团队必须“以客户为导向，而不是以竞争为导向”，公司业绩因此持续攀升，股东也获益不小。他的观点非常清晰地揭示出这样的原则：团队应该始终积极地去解决客户的问题，而不是紧盯竞争对手，被动地做出反应。

随着产品方案的不断细化，各种问题也层出不穷，其中大部分都非常重要，指出了产品的不足之处。我会迅速把这些问题记到一个内部FAQ文档中并尽我所能回答提问者。

如果觉得某个问题外部用户也会问到，我会把它记到FAQ文档的“外部问题”部分。通过不断添加新问题，这份文档将变成那些有疑惑的人寻找答案的动态更新的可信资源。

当悬而未决的问题趋近于零时，你就能够写出出色的产品单页或产品需求文档了。

API文档可以说明你的团队如何与其他团队协作、外部开发者如何使用这套系统以及你需要存储什么数据。预先定义清楚API还有个好处，它可以帮助你搭建由这些API构成的面向服务的体系架构（SOA，Service-Oriented Architectures，第3章有更详细说明）。因此预先撰写API文档对每个人都有很大帮助。 不只如此，API最重要的作用是明确系统的各个边界，而明确的边界有助于人们了解各类功能或输出分归哪方负责。这样在项目初期各方就建立了理解和术语上的一致性，为后续高效沟通产品需求打下了坚实基础。

功能规格文档的读者一般为你的工程团队、设计团队，偶尔还有市场营销团队。功能规格文档包含以下九个内容块，按照先整体后细节的顺序排列，我将逐一详细介绍： 1. 简介（使命和策略） 2. 目标与非目标 3. 用例或用户场景 4.原型图或线框图 5. API 6. 负载规划 7. 依赖 8. FAQ和开放问题 9. 关键事件

有些人把用例和用户场景分开单列。用例是指用简要的语句来描述那些用户必须执行的操作，用户场景则是指用叙述故事的方式来描述用户是如何体验产品的。

当用户行为趋向复杂时则更适合使用用户场景。

无论是只写用例还是只写用户场景甚至两者都写，你都需要敲定它们的优先级。这样工程团队才能给工程任务定优先级并优化设计。

P0 没有该功能产品无法演示。 P1 没有该功能产品无法交付。 P2 锦上添花的功能。 P3 哈哈哈！ P3的功能基本上要被裁减掉，甚至P2的功能也在裁减候选名单中。

有时候你认为一些用例无须在版本1（V1）中实现，但团队成员又认为它们比较重要时，可以给这些用例加上V2的前缀或者其他标签，让他们明白这些用例会在V2中安排处理。

你需要将全部依赖方及其负责人列出来，如果有应急方案也一并列出来。

有些人把这种测试叫做“焦点小组”，也有些人把它叫做“试售”或对现存客户的“路线图演示”。你的用户体验团队或许会认为这个过程是一次认知性遍历：客户通过你对产品原型图的介绍来体验产品，然后提供关于功能和实用性的反馈（后面有详述）。以上林林总总的叫法或做法并不重要，重要的是你去做了这个测试！所以在产品演示文稿准备妥当之后你应该马上安排持续3周、每周3至5次的面向潜在客户的产品演示。

但千万不要让参加测试的人大半都是极客。

你只需理解产品定价的三个基本方法：按成本定价、按价值定价以及对比定价。

用户界面（UI，User Interface）是用户体验的旧称，它更关注单个页面或屏幕的设计，是用户体验的组成部分。

视觉设计（VisD，Visual Design)是关于如何通过一种既赏心悦目、夺人眼球又清晰明了的方式来展示内容的一门学问

用户体验研究（UXR，User eXperience Research）是用户体验的一个特殊组成部分，它专注于研究用户是如何看待你的产品的。

如果需要负责交付一套卓越的用户体验，你就必须问以下6个用户体验问题。你还需要理性、思虑周全地回答，以确保答案合乎情理。若能做到，你将最终收获一个设计精良的产品。记住在每次检查原型或设计时都要问这些问题。

该用户界面要求用户完成的最重要的任务是什么？ 这是最简单的解决方案吗？ 信息是否组织得当？ 设计是否易用且一目了然？ 标准是否一致？ 能否减少用户点击次数？

面对一个新的用户界面时，你应该首先问自己：“主要角色必须完成的主要任务是什么？该用户界面要求主要角色完成的主要任务又是什么？”关注主要角色而非全体用户可以帮助你更好确定优先级

与设计师沟通时千万别这样说：“登录按钮太突出了，减弱些吧。”也不要这样说：“将这个推广信移到顶部去吧。”我们要做的是清晰地阐述我们的业务目标以及它们之间的优先级，之后将权力交给设计团队，让他们以此为基础进行一系列的优化。

因此在面对一个新的设计时你应该先问自己以下三个问题： 谁是最重要的用户？ 这类用户必须完成的最重要的任务是什么？ 这个任务在用户界面中是最重要且最简洁的部分吗？

在实际工作中你可能没有这样一个衡量指标来使你的设计变得简单（但工程师们却要头疼不已）。你需要深入思考你的数据和特性该如何合理组织起来。为了做到这一点，你应遵循以下条件。 最重要的客户类型最关注的信息应该最突出。 信息的排列方式应该像报纸文章那样从标题到摘要一一排列。 信息应该尽可能个性化且实时，也应在合理的前提下尽可能详细。当你能提供“销量排名：1327”时为什么只提供“销量排名：前1000”呢？用户喜欢适度精确的信息。 最常用的控件出现在最容易找到的地方。

另一个可减少点击次数的重要方面是减少用户在键盘和鼠标之间来回切换的次数。用户每次重新握上鼠标并找到屏幕上的指针都需要可观的成本。应尽可能减少这些切换事件。

从来没有人能真正知道产品是否可以按时交付。但你可以预估它。因此，我的问题可以回答得很出彩，只要这个回答包含三项低成本的工作。 创建一张简单的计划表并持续维护。 跟踪Bug，观察燃尽图，计算实现零Bug率（ZBB，Zero Bug Bounce）的日期。 谨慎管理你的依赖。

Bug燃尽图是一张反映你的Bug数量随时间变。

情况的图表。它可以预测产品何时能够交付。制作燃尽图需要为不同严重等级的Bug各绘制一条其数量随时间变化的曲线。你还可能想要绘制一条描述Bug总量随时间变化的曲线。图4-2向你展示了一个示例的Bug燃尽图。

那么，如何确保你交付的软件不会让你蒙羞呢？你可以遵循下面8个主要步骤，这些步骤对产品质量有着重大影响。 坚持测试驱动开发。 围绕优秀的测试主管组建测试团队。 亲自评审测试计划和测试用例。 自动化测试。 虔诚地推行内部试用（Dogfood）。 开展找虫总动员。 勤勉且有条理地处理Bug。 任命可信测试者以构建最后一道防线。

美国管理学大师爱德华兹?戴明曾写道：“无法测量的东西也就无法提升。

零Bug到达日期是一个优秀的反映开发进度的指标：它几乎没有获取成本（大部分Bug跟踪系统都能免费提供该数据），它可靠且可重复，它能实时更新，它能为团队指明方向。

附录1 十大交付原则：你不是来当老板的——团队主管是仆人，他们存在的目的就是为了伺候工程团队。 从用户角度出发。 用独特的方法解决很多人都有的大问题。 坏的消息就是好的消息。——杰克·韦尔奇 先寻求理解，再寻求被理解。——史蒂芬·柯维 构建最简洁的可用的产品。 交付手中有的，而非脑中想的。 无法测量的东西也就无法提升。——开尔文勋爵 你不可能做完所有工作，所以你应首先做那些只有你能做的工作。 永远走在交付的康庄大道上。