谷歌和亚马逊如何做产品

紫色的李 2015-05-15 0

翻译的不好，作者本身是有水平的，但是讲的东西太初级，随便看看吧，没有收获很多的感觉。

秦岭山人 2014-09-16 0

力赞！

Joy姜猴猴 2016-05-20 0

从0到1的描述，，不过章节的名称起的有点没水平，啥都赢。。。。

PHZ 2014-08-24 1

越是困难的产品，如果做出来，越可能成功，大赞！

PHZ 2014-08-24 1

越是困难的产品，如果做出来，越可能成功，大赞！

紫色的李 2015-05-15 0

翻译的不好，作者本身是有水平的，但是讲的东西太初级，随便看看吧，没有收获很多的感觉。

秦岭山人 2014-09-16 0

力赞！

Joy姜猴猴 2016-05-20 0

从0到1的描述，，不过章节的名称起的有点没水平，啥都赢。。。。

我想说两句

书刚看完。。

1417135456 2014-05-28 0赞

书到手，刚看完

用来放办公桌边上装个样子还不错

最想看的案例不多

变个法儿把理论重复了一遍而已，实用工具也不多，

有点小失望

啊，长点，评论能有多长啊，你以为写文档呢

能产生共鸣的好书

凤栖梧别居 2014-05-28 0赞

　大概做产品的人都喜欢简练，所以这本书仍用简练的语言把做产品的精髓做了很好的诠释。

案例、工具、重点，都很清晰。除此之外的语言，虽然都是铺垫，但是只有实打实经历过的人才能写得出来，因此看的过程中很有共鸣！

对于新手而言，这本书可以很好地帮你入门。
对于老手而言，更多是在这里寻找共鸣以及对当前工作的槽点^^

哈！推荐！

理论都是这一套，换个背景描述了一遍

耗子吴 2014-08-24 0赞

第一部分作者从战略、产品定义、用户体验、项目管理、测试、量化评估、发布等方面介绍了如何交付卓越产品；第二部分介绍了 PM 所需技能。

纵观大部分关于产品的书，内容结构上大抵都如此，所要遵循的原则，定义也都大同小异，主要的差异体现在因为作者的不同，经历的背景不同，所描述的案例和场景有所不同，但表达的思想都是大抵一致的，这类书看过之后算是了解了关于 PM 的理论，最最重要的还是将这些理论应用到实践，因为很多东西，听起来简单，但真正放在项目中很可能就不是预期的效果。

PM 最重要的是要形成一套自己的理论和实践体系，这样无论做什么项目、在什么团队都会游刃有余，如果水平还不够，那么就多看别人的，在实践中慢慢积累和总结。

帽子扣得比较大，流水账

二四字节 2014-11-30 0赞

可能适合大公司的产品人员看？

小公司、创业公司的产品，包括CEO，是绝逼没有这么多时间和精力去拉这么长的产品策划和需求准备周期的。流水账般的方法可以在需要的时候翻出来参考下，但绝不是一本有太多启发的书。

“新闻稿”部分倒是感觉不错，也是自己之前做得不够好的地方。在自己的身份下，总是觉得开发团队不够努力去理解需求，去揣摩需求。但其实，产品如果能更加作为一个发言人身份去用简单易懂的新闻稿帮助所有相关方了解需求和鼓劲，或许是前期激发开发团队兴趣的一个好办法。

写得不错

小兵 2015-01-30 0赞

谷歌和亚马逊如何做产品从实战中的反思，值得学习

请问书中的所提到的电子表格副本在哪可以下载到？

http://www.shippinggreatness.com/ 打开后是空页面，谢谢！

了解一下先进企业的产品方式

徐毅 2016-09-19 0赞

第一部分交付卓越产品，步步为“赢”

其实有一套更为有效的交付过程，它分成7个阶段，任何团队主管都可按图索骥，收获成功与快乐。
阶段一，确定正确的产品方向。
阶段二，尽可能清晰详细地定义产品。
阶段三，设计用户体验。
阶段四，做一些基础的项目管理工作，不要太多也不要太少。
阶段五，开始测试。
阶段六，你差不多可以准备发布了，不过在发布之前要清楚知道怎样才算成功，这就要求你建立一套衡量产品成败的指标。
最后，正式发布产品。

第1章赢在使命和策略

1.1　如何找到正确的需求

从拉里和杰夫身上，我们学到必须专注于解决真正的客户问题。

如果说拉里和杰夫告诉你必须解决真正的客户问题，布林会告诉你这还不够，你得确保这是个很多客户都存在的大众问题。

1.2　如何构建卓越的使命

卓越的使命需要完全符合以下三点要求
1. 能够唤起人们的兴趣
2. 提供言之有物且能指明方向的原则
3. 适合印在T恤上

最后一个衷告：你需要的是一个能够反映代表性产品或服务的使命，而不是一个面面俱到的使命。

1.3　如何制订正确的策略

策略是指在竞争对手的压力下，利用公司独特的优势来争取目标用户的粗略计划。

当你开始思考公司、客户和竞争这三大问题时，需特别注意如何才能长期为客户提供比竞争对手更优质的产品。

既然现在你已经知道了谁是产品的忠实拥趸以及产品如何保持长期的竞争优势，那么请用最多三段文字写下来，然后再将这些想法的本质浓缩成一段文字。越简短的策略越容易实现，也越容易获得他人的认同。

第2章赢在产品定义

这时需要借助文字来告诉你的团队你要做什么事情以及目标是什么。

当设法细化产品方案时，你会发现产品要解决的一些客户问题都是你主观臆断的，而且因为你的使命和策略都是建立在客户问题上的，因此这些主观臆断也混入了其中。

所以要采用一些方法来证明臆断是否正确。即便它们十有八九是正确的，也要经过证明，而证明的最好方法就是把产品提供给客户使用，然后听听他们的意见。

不管最小化可行产品是大是小，你都可以参照下面的产品定义过程来定义产品。通过快速重复这个过程，你可以验证不同的客户问题，并添加更多更好的产品特性。当迭代越小越快时，你甚至不需要花大力气去猜测客户的需求，而是更多按照客户告诉你的去做，这样成功的可能性更大。

产品定义过程主要分为10步。每一步都建立在上一步完成的基础上。
1. 撰写新闻稿。新闻稿是一篇脱胎于策略的文章，篇幅不超过1页，主要用于促进各方了解和公开透明。
2. 创建并不断更新FAQ文档。这份“活跃”的FAQ主要用于记录一些争议点和重要细节。
3. 绘制线框图或流程图。线框图和流程图是产品的可视化描述，在讨论或答疑中使用可以让观点更明晰。
4. 撰写产品单页或10分钟的演示文稿。产品单页是一篇写给高管或多数风险投资人看的产品介绍文章，你需要把控好介绍的详略程度。
5. 在FAQ中添加API文档。API是产品的第一个技术触角，在第6步会把它们全部整合到需求文档中。你可以先花数小时简单起草一些API，后续再在工程团队的帮助下完善它们。
6. 撰写功能规格文档。功能规格文档又名产品需求文档（Product Requirements Document，PRD，谷歌常用此名），或市场需求文档（Marketing Requirements Document，MRD，微软常用此名）。它是阐述产品各功能详情以及为什么要有这些功能的最权威的文档。产品的规模以及成熟度决定了你需要几天还是几周才能写完功能规格文档。
7. 邀请设计团队和工程团队主管参与产品评审。这一步是为了获得项目组对产品的认可，并让他们帮忙寻找产品中存在的各种极端及边缘情况。
8. 找客户测试产品概念。在此阶段，你需要了解产品方案是否真正能解决客户问题。
9. 命名、定价以及预测收益。你可以晚些时候再想这些事情，只要对产品有足够的信心。
10. 向管理层汇报。

2.1　第1步：撰写新闻稿

所谓新闻稿是指一篇向市场宣布将要推出新产品的通告。不管是新闻稿还是博客文章，都应该简单明了地传达关于产品的关键信息。

好的新闻稿包含以下六大要素：
- 产品命名
- 发布时间
- 目标客户
- 解决了什么问题
- 如何解决（务必简明扼要）
- CEO的公开赞辞

2.2　第2步：创建并不断更新FAQ文档

创建并维护FAQ文档有两大好处。第一，它能节省你大量回复邮件的时间，还能抵御一些内部责难。第二，当你的客户支持团队和科技写作团队开始整理所有面向公众的内容时，FAQ将是一个很有价值的资源。

2.3　第3步：绘制线框图和流程图

流程图可以帮助你准确地解释用户工作流和系统交互相关问题，简要线框图则可以帮助你具象化产品各环节的用户体验，并在之后的汇报中发挥不可思议的作用。除此之外，在白板或空白纸上画草图并用手机拍照也是一个沟通想法的好办法。

2.4　第4步：撰写产品单页和制作10分钟的演示文稿

这两份文档所需包含的五个要素：
- 产品名称
- 目标客户+数量有多少
- 解决了什么问题+这个问题对于目标客户来说有多大价值
- 解决方案+这个解决方案类似线上哪个产品，为什么你的方案能让竞争对手在长时间内都无法模仿
- 何时交付+主要的里程碑有哪些？
- 团队背景（仅针对VC）

最后再提一个关于10分钟产品演示的建议：你的听众无论来自公司内部还是公司外部，无论关心技术还是关心商业，他们大部分人对你的行业都有充分的认识和独到的见解，但并不了解你要做的事情的前因后果。因此你演示的最佳方式是先讲用户现状，再延展开来（参考先前的五大要素），迅速把要点讲完后再留出时间供这些聪明的听众就他们关心的点刨根问底。

2.5　第5步：在FAQ中增加API文档

API文档可以说明你的团队如何与其他团队协作、外部开发者如何使用这套系统以及你需要存储什么数据。预先定义清楚API还有个好处，它可以帮助你搭建由这些API构成的面向服务的体系架构

不只如此，API最重要的作用是明确系统的各个边界，而明确的边界有助于人们了解各类功能或输出分归哪方负责。这样在项目初期各方就建立了理解和术语上的一致性，为后续高效沟通产品需求打下了坚实基础。

2.6　第6步：撰写功能规格文档

虽然各家命名不同，但对于它功用的看法却是一致的：它是用来详细描述用户应该如何体验产品的文档。它不包含系统在后台如何运行之类的技术细节，这类细节应该包含在工程主管撰写的技术规格或设计文档中。

功能规格文档的读者一般为你的工程团队、设计团队，偶尔还有市场营销团队。功能规格文档包含以下九个内容块，按照先整体后细节的顺序排列，我将逐一详细介绍：
1. 简介（使命和策略）：这块内容与产品单页相同。
2. 目标与非目标：简介中虽已大致描述了产品的方向，但你需要将其细化成不同目标，每个目标都应保持清晰简洁并将它们按优先级排列，这样工程团队就可以合理地进行设计与开发了。如果说目标是告诉别人你要做什么，那么非目标则是告诉别人你不要做什么。
3. 用例或用户场景：有些人把用例和用户场景分开单列。用例是指用简要的语句来描述那些用户必须执行的操作，用户场景则是指用叙述故事的方式来描述用户是如何体验产品的。用例（或者用户故事）这个敏捷模型强调的是用户类型与用户行为，在实际工作中非常有用。当用户行为趋向复杂时则更适合使用用户场景。无论是只写用例还是只写用户场景甚至两者都写，你都需要敲定它们的优先级。衡量功能或Bug的重要性与紧迫度通常很难，因此建立通用的分级标准并尽早对它们进行分级是非常有益的。
4. 原型图或线框图
5. API
6. 负载规划：负载规划是指对未来一段时间内用户的使用量进行粗略估计并制订应对计划，这对工程团队来说非常重要。他们会根据你预估的使用量来确定哪些地方需要添加缓存，哪种类型的服务器和存储需要准备，哪些授权问题可能产生，等等。总之，关于负载规划你要做的就是进行合理的预估，你的工程主管则负责根据预估值来构建一个能稳定运行的系统。
7. 依赖：你需要将全部依赖方及其负责人列出来，如果有应急方案也一并列出来。功能规格定稿后你也应该发给各依赖方的负责人，让他们知道你需要他们的支持。依赖不需要描述得太详细，你只需简单说明我们需要这个依赖的原因以及依赖会受到什么影响，比如流量或者异常情况。
8. FAQ和开放问题
9. 关键事件

2.7　第7步：找出边界情况并得到团队认可

接下来你需要和团队一起细究文档以找到所有的问题。

你的团队将开始寻找边界情况或者极端情况，即极少出现的产品行为或场景。

除了确保处理好边界情况，你还需要确保工程和用户体验团队认可你的产品规划。

第7步充满风险。一方面你必须承认并整合所有你的团队找到的边界情况，另一方面还必须捍卫产品的核心原则。

2.8　第8步：客户测试

我在这里主张的“客户测试”并不是让你马上把软件开发出来然后扔给客户挑刺，我主张的是去找一批现存的或潜在的客户，向他们介绍你的产品设想和原型，并听听他们的反馈。
这个测试可以避免你做出一个没人想用的产品或者遗漏一些核心功能。

2.9　第9步：想清楚基本的商业要素——命名、定价和收益

先谈产品命名。你需要一个客户喜欢的、能注册商标并通过版权审查的名称，后者可以让律师把关。

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

既然收益模型就是一个拍脑袋出来的东西，为什么我们仍然需要构建它呢？
第一，不管是VC还是业务主管，你需要让他们感知到你规划的是一个多么重要的业务。
第二，构建收益模型能使产品设想具象化并证明产品机会有多大。
第三，一个简洁的模型支持你任意调整变量并反复进行预测。

你可以清晰地发现该模型对假设是高度敏感的，这不是它的问题而是它的优点，因为它揭示了你的假设以及特定变量的重要性。一套合理的简洁的模型能帮你理清逻辑、明确核心指标、理解商业模式并最终赢得管理层的支持。但你仍需注意不要花过量时间在它上面——真实的用户和真实的数据永远比预测更有效。

2.10　第10步：取得上层的认可

预售是一个非常直接的爬向食物链顶端的过程

2.11　产品已经准备就绪，去构建它吧

但你无法一个人就把产品构建出来，真正的难点已摆在面前：驱动你的团队在现实的重重困境中依然构建出可靠的软件。

第3章赢在用户体验

为了让设计团队发挥出最佳水平，你需要先理解设计，再让设计团队理解你。

3.1　了解各类设计角色：用户体验，用户界面，信息架构，视觉设计，用户体验研究……以及角色模型
- 用户体验（UX，User Experience）关注的是用户如何完成任务以及该如何优化向用户展现信息的方式。
- 用户体验设计师对信息架构（IA，Information Architecture）尤为关注。不同于工程架构，信息架构研究的是信息该如何在用户界面中呈现，而不关心底层的数据结构。你通常可以提这样的问题来思考信息架构：“页面中最重要的信息是什么？”
- 信息架构专注于理解用户怎样才能接收到信息，而不是系统怎么才能正常运作。
- 用户界面（UI，User Interface）是用户体验的旧称，它更关注单个页面或屏幕的设计，是用
户体验的组成部分。
- 视觉设计（VisD，Visual Design）是关于如何通过一种既赏心悦目、夺人眼球又清晰明了的方式来展示内容的一门学问。视觉设计师往往具有较强的平面设计、排版和美术功底。
- 用户体验研究（UXR，User eXperience Research）是用户体验的一个特殊组成部分，它专注于研究用户是如何看待你的产品的。用户体验研究者们擅长通过研究来获得关于产品成败的统计显著性数据，一个出色的用户体验研究者还会出具报告，说明用户体验中哪些部分有效哪些部分无效，这样的指导极富价值。

角色模型（Persona）是一个由雅各布·尼尔森倡导并备受欢迎的方法，这个方法提供给你和你的设计团队、工程团队一个评估设计的框架。你的设计和业务团队将创建一组虚拟角色来代表目标客户，这些角色模型拥有姓名、薪水和目标，你还可以赋予他们任何你知道的目标客户的特征，然后利用这些角色模型来评估设计的效果。

3.2　了解如何评估设计

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

3.2.1　该用户界面要求用户完成的最重要的任务是什么？

“主要角色必须完成的主要任务是什么？该用户界面要求主要角色完成的主要任务又是什么？”

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

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

3.2.2　这是最简单的解决方案吗？

用户完成任务的能力与该任务的复杂程度呈非线性函数关系。换成简单易懂的话来说：你对用户要求得越多，用户完成的能力和意愿就越低，而且低得不是一点点。

前田约翰在他的《简单法则》一书中提出了一个简单化的框架。他把这个框架称做SHE：简化（simplify）、隐藏（hide）和附加（embody）。

3.2.3　信息是否组织得当

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

3.2.4　设计是否易用并且一目了然

当识别出了用户最需要完成的核心任务后，你需要问问自己这些任务是否是可发现且可理解的。可发现性是指用户发现行动点的能力。

解决可发现性问题的方法有很多，以下为三种常用方法，你可以做些尝试。
1. 定位
2. 视觉设计
3. 惯例

如果你对一个特性的可发现性和可用性存有疑问，一个最好的办法便是让真正的用户来测试。

3.2.5　标准是否一致

这里有一些惯例，你可以利用它们来使用户界面更易于理解。
- 所有主要按钮都应尺寸放大且配色一致。
- 一个用户界面中只有一个主要按钮。
- 使用一组按钮来表示“是”或“否”这样的选择。
- 不同优先级的行动点使用不同的样式。例如在Amazon.com上有“立即购买”按钮（主要行动点，我们唯一期待的）和很多较小的“了解更多”链接（次要行动点），其中按钮要比链接明显得多，而且全站都遵循这个惯例，包括“你的账户”页面，这使得亚马逊这套体系运作良好。
- 当一个流程有3或4张页面时，告诉用户目前处于哪一步以及共有多少步。
- 在你的应用程序中使用下划线或者其他配色来强烈区分链接和普通文本。
- 遵守互联网CSS标准（如：鼠标划过链接时指针变为手的形状）。

3.2.6　能否减少用户点击次数

如果你的默认设置符合用户的需求，用户就可以少点击几次，同时也少遇到一些异常结果。另一个可减少点击次数的重要方面是减少用户在键盘和鼠标之间来回切换的次数。

3.3　了解如何与设计师沟通

请听取下方的沟通建议并做些变通，以迎合每一位独一无二的设计师。
1. 以用户的口吻说话
2. 以提问的方式建立共识
3. 反复讲述业务目标，如果有些目标相互冲突，则反复讲述它们之间的相对优先级。帮助设计师了解他必须解决的问题是什么。避免设置主观目标也能帮助你的团队。
4. 用数据说话统计用户点击数、浏览屏幕的数量和页面加载时间可使交流更为具象。应积极开展可用性测试。
5. 提供一些竞争对手或类似体验中运作良好的案例

3.4　学习如何借助图画进行沟通

这些手机拍下的白板图画是非常强大的沟通工具，而且易于制作。
灰度线框图
视觉稿
红线标注版视觉稿
可点击原型

制作线框图时需关注以下基本原则。
- 只制作用户界面中相关部分的原型。
- 总是使用完整的、经过适当编辑的文本。
- 控制花在视觉设计上的时间。
- 使用灰度色，不要使用其他颜色。
- 预期你的线框图会发生很大改动。
- 当心视觉花招。

对于大段的文本你可以使用设计师常用的“这里有一段话”之类的文字填充，但对于任何表单、按钮、对话框或其他有意义的控件你必须使用准确的高质量文案。

文案还是煤矿坑中的金丝雀：如果发现需要写一大段文字来解释某个特性该如何使用，你就应该重新设计这个特性，因为用户可不会读大段的说明。

在制作线框图时，你需要考虑如何搭建才能确保后续能快速修改。

设计师们发明的一些不错的快捷制作简单原型的方法

第一个是使用如只能在Windows中运行的Visio或只能在OS X系统中运行的Omnigraffle那样的流程图绘制程序来绘制线框图，第二个则是使用Fireworks、PhotoShop或者画图工具来绘制较小的、高保真的、基于现有用户界面的改动。

3.4.1　使用Omnigraffle制作简单的线框图

由Konigi出品的非常出色的线框图模板库，这个库中包含你可能会用到的任何元素。你可在这里下载它：http://konigi.com/tools/omnigraffle-wireframe-stencils。

3.4.2　快速制作高保真原型

第4章赢在项目管理

我会在电话面试产品经理时问：“你如何知道产品是否可以按时交付？”

我的问题可以回答得很出彩，只要这个回答包含三项低成本的工作。
1. 创建一张简单的计划表并持续维护。
2. 跟踪Bug，观察燃尽图，计算实现零Bug率（ZBB，Zero Bug Bounce）的日期。
3. 谨慎管理你的依赖。

4.1　创建一张简单的计划表并持续维护

www.shippinggreatness.com
余量是一个“容差系数”，用于容纳那些未曾预见的问题和一般的生产力损失所消耗的时间。
这些分心的事情根本无法预料，所以我发现60%的生产率估值非常合理。
“假定推送时间”
查看电子表格的任务分配区域，你会找到那个剩余开发时间最长的工程师。这个工程师有时会被称为“长杆”或“处在关键路径上”。试着把他或她归属于V1的任务分配给其他不饱和的工程师。

4.2　如何拿到评估量

为了能更轻松地拿到评估量并减少工程团队高昂的评估成本，你可以尝试下面的技巧。
1. 如果你不是工程经理，那么让你的工程经理去要评估量。
2. 表面上接受评估结果
3. 认识到你的权力
4. 只跟踪剩余时间：只跟踪完成任务所需剩余时间是敏捷管理的一个原则，我很喜欢这个原则，因为它着重于项目的实际情况，便于你发现项目何时可以编码完成。
5. 要求不考虑余量的评估
6. 每周一次在团队会议上评估各任务的剩余时间

4.3　跟踪Bug并创建Bug燃尽图

Bug下降的比率，或者说这条曲线的斜率，被称作发现/修复率。

4.4　管理依赖

管理依赖并没有什么秘诀可言。你唯一能做的便是将风险最小化，而最小化这些由依赖引发的风险有一些关键技巧，我称它们为“五个如果”。
1. 如果去除它也可以运转，那就去除它。
2. 如果内部能构建，那就内部构建。
3. 如果必须添加一个依赖，那就趁早添加。
4. 如果必须添加一些依赖，那就依靠它上一个已构建的版本。
5. 如果交付得早，被依赖伤害的可能性就小。

第5章赢在测试

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

5.1　坚持测试驱动开发：“调试过劳死，测试嗨翻天。”

5.2　围绕优秀的测试主管组建测试团队

一个优秀的测试主管会不断培训缺少经验的测试人员并帮助设计优秀的测试自动化架构。
5.2.1　选择一：降低标准雇佣测试人员并聘请管理者去管理他们
5.2.2　选择二：按高标准雇佣外包团队
5.2.3　选择三：按高标准雇佣测试人员，不使用外包团队

5.3　亲自评审测试计划和测试用例

一个测试计划由很多测试用例构成，这些用例是从你的产品需求文档中派生出来的。如果你的产品需求文档写得十分糟糕，你的测试团队就无法测试。测试计划通常是用电子表格创建的，因此你能方便地整理测试用例。

5.4　自动化测试

还记得聘请一个优秀的测试主管是多么艰难吗？应对这项挑战的一个最靠谱的方法是找到一位愿意编写测试自动化程序的测试主管。

5.5　推行内部试用

强制你和你的团队使用自身研发的软件，体会用户的痛，能帮助你们逐步提升紧迫感，理解用户困扰。

总之，你需要想尽办法让内部试用成为你团队文化的一部分，即使别的团队没有这么做。

如果你决心虔诚地推行内部试用，下面列举一些你可遵循的且会对你会有很大帮助的最佳实践。
1. 计划一次内部试用发布：内部试用发布是指将你的软件发布给公司内部同事使用。
2. 使其他试用者能够方便地提交Bug报告：建立邮件列表收集试用Bug是一个很好的监控缺陷数量的方式。
3. 软件发布后应继续进行内部试用：亚马逊和谷歌都维护了一套允许内部试用者看到特定特性的实验性框架。这些框架允许某些软件在生产环境中运行但只能被内部试用者看到。
4. 让进行内部试用成为企业核心价值观

5.6　如何开展找虫总动员

找虫总动员是指发动你的团队或者你的整个公司专门花一定时间，通常是一个小时，来寻找尽可能多的内部试用产品的Bug。

以下四件事情有助于找虫总动员获得成功。
- 设立奖项，提供物质激励。T恤之类的奖品效果很惊人。
- 在项目计划中增加找虫总动员这样一个关键事件。安排好找虫总动员的时间以方便你的整个大团队了解何时可以参与。
- 将找虫总动员排进你的开发和测试日程表中。
- 感谢每一个Bug。铭记这一点：“坏的消息就是好的消息。”每发现一个坏Bug都是好消息。

5.7　准确且有条理地处理Bug

在我看来只需简单的3步就能有条不紊地把Bug处理好。
1. 基于频率、严重性和解决成本对Bug进行分级。
2. 每天与开发主管和测试主管碰一次，评审新增的Bug。
3. 不断施加压力以减少新的阻碍发布的Bug出现。如果不这么做你就永远到达不了零Bug率（零Bug率是指没有任何阻碍发布的Bug再被引入）。如果到达不了零Bug率，你就永远发布不了。

在对一个Bug分级时你需考察以下三个方面。
1. 频率
2. 严重性
3. 修复成本

每天开一个Bug处理碰头会来决定哪些Bug需要修复。
1. 确定通用的Bug评判标准
2. 先处理最严重的Bug
3. 限定会议时长
4. 只围绕频率、严重性和修复成本来讨论
5. 讨论每个Bug的时间不要超过一分钟

5.8　发挥可信测试者的作用

可信测试者是指在保密协议的约束下，在产品发布前使用产品内部试用版的用户。他们比你的团队有着更丰富的多样性，包括更多不一样的电脑，更多不一样的期望，而且他们还不像你们那么懂技术。因此他们的反馈具有更大的价值。

为了让可信测试者们能够帮助我们改善产品，我遵循以下几条最佳实践。
1. 让企业用户签署保密协议并提供正确的联系方式
2. 制作粗略的新手指南文档，其中包括已知问题的列表
3. 创建一个包含整个工程团队的邮件组
4. 让这些用户使用和工程师同样版本的试用产品
5. 调研可信测试者
6. 当产品更新时通知可信测试者们

5.9　思想火花：以新用户的方式来使用整个产品

但产品开箱体验的好坏取决于产品中一些最复杂的部分。

这里有一个小技巧能帮助你准确体验到一个新用户会体验到的东西：抵达特性完成阶段后删掉你所有数据和账号然后从零开始使用软件，抵达编码完成阶段后再这样操作一次。

第6章赢在量化

一个团队的能力怎么样，通常要看他们的量化数据表现怎么样。

6.1　如何采集正确的量化数据且只采集正确的量化数据

一个优秀的量化指标应具备5个关键特点。
1. 测量成本低廉
2. 测量可靠且可重复检验
3. 能频繁地测量，最好能实时测量
4. 团队能够根据它做出明智的改变：每个团队都想把订单量升上去，但亚马逊的产品数量太庞大了，任何团队都无法根据全球订单量的变化来衡量他们造成的影响有多大，但如果你们团队是负责购物车的，你可以测量用户从开始结算到购买成功的转化率，这个数字反映了用户体验和系统性能的好坏，并给了你一个可以瞄准的目标。
5. 专注于客户：我喜欢购买转化率这个指标的另一个原因是，它反映了客户的体验状况。只有贴近客户的指标才富有意义且可被理解。专注于客户的另一个要点是尽可能测量客户体验的末端。比如你开发了一个可供下载的iPhone软件，那么哪个指标更有意义呢，是下载量，还是软件启动量？我认为是软件启动量，下载量只告诉了你营销做得怎么样，软件启动量才会告诉你用户的参与度和增长情况。

6.2　你需要采集的三类量化数据

如果想在未来证明你的业绩，你需要事先准备一根基准线。

确立基本指标并不困难，比如说工程团队的执行能力就是一个基本指标。

执行力可以通过考察产品能否在你要求的日期内发布来衡量。

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

产品发布后你可能需要更换指标，因为你新引入了一个重要的数据源：客户及其行为数据。

三类发布后需要跟踪的关键指标：目标进度、经营绩效和系统性能。
6.2.1　目标进度：目标指标会告诉你目标的完成进度。在谷歌一个重要的目标指标是“7天活跃用户数”。它是指近7天使用产品的独立用户数。如果你确实在做一个预期人们会每天使用的产品，那么比较单天活跃用户数和7天活跃用户数之间的差额也是很有意义的。你还可以跟踪如利润、注册量、下载量或安装量等目标指标。我更喜欢精确增量表达法（Great Delta Convention，第10章有详述）
6.2.2　经营绩效：经营绩效指标会告诉你产品的问题在哪里以及如何提升用户体验。这些指标通常是用比率表示，比如从点击购买按钮到付款成功的转化率。埃里克·莱斯在他的《精益创业》一书中并不推崇那些总是在增长的指标。他称它们为虚荣指标。这也是为什么你要关注转化率、参与度等指标的原因。另一个避免“虚荣”指标的方法是衡量应用中改动带来的影响。最好能让改动前和改动后两个版本横向而不是纵向对比测试
6.2.3　系统性能：系统性能指标能说明你产品的实时健康度。这类指标包括99.9%平均延迟、每秒请求数、并发用户数、每秒下单数以及其他基于时间的指标。你还可以天马行空地从统计过程控制（SPC，Statistical Process Control）的视角来考察你的指标。爱德华兹·戴明是最早推广使用SPC来精确测量一个指标的正常下降范围的人之一。戴明假设你的系统存在一定的波动，伴随着波动存在一个可以接受的系统变化范围。在这个范围内的波动被认为是正常变化或I型误差。系统还会有一些持续一小段时间的不良的尖峰波动，戴明称它为异常变化或II型误差。你可以忽略正常误差或正常波动，即误差或波动落在平均值的正负标准误差区间内。标准误差是指你的数据的平均值的标准偏差。

6.3　专注于目标本身，忽略细枝末节

第7章赢在发布

发布可不只是把文件上传到服务器。这里有几个主要的发布步骤，遵循它们可以确保发布质量。
1. 对改动说不。
2. 开启作战室。
3. 营造紧迫的气氛。
4. 核查发布清单。
5. 撰写博文。
6. 发布软件。
7. 亲自验证软件。
8. 应对发布带来的各种影响。

7.1　对改动说不

在准备发布的过程中你必须尽量频繁地对新的特性、新的Bug以及用户体验上新的改动说不！如果不这样做，你就永远完成不了软件，自然也就永远交付不了。

这里有一个方法可以让你的团队愿意说不，即建立一个“发布后第一时间”（IPL，Immediately Post-Launch）修改的需求清单。

另一个你应该对新冒出来的改动说不的主要原因是，几乎所有对代码的改动——更合适的叫法为代码移动，都会引发新的风险，如引入新的Bug或重新引入老的Bug。

7.2　开启作战室

在这个节点上你应改开每日例会并不再禁止与会者在会上争论一些问题。

每日例会能帮助你高效做出决策并营造一种紧迫的氛围。

试想如果需要沟通的两个人坐在一起，那么他们之间的信息传递时间实际上为零。

7.3　营造紧迫的气氛

我认为凭借冲刺来完成项目没有什么不好。只要这样的冲刺不超过1个月，大多数团队和他们的家人还是可以接受的，特别是你还会补偿给他们一定的休息时间。

不要让你的团队冲刺超过1个月，或者最多2个月。

狗屎三明治

你还需要记住你的任务不是去解决问题，而是创造出一个有利于问题解决的环境。当所有人都被召集到电话会议中后，确保他们说的是同样的语言，并在过程中将你的紧迫感传递给相关方。

7.4　完成发布清单的核查

要想出色地完成发布，你需要拟定一张发布清单。这份清单的目的在于确保软件发布中所有需要跟进的事项都被有序安排且被详细描述。发布清单还能促进团队内部不同职能的交流。

7.5　撰写博文

你可以从产品预告中挑选有用的文字，如果仍然需要使用具体案例则需抛开细节。

博文还是你产品演示的脚本。你可以准备一个一分半钟到三分钟之间的视频放在博文后面，这样那些没有权限或者对试用缺乏耐心的用户仍然能体验到你产品的卓越之处。

7.6　发布软件

发布特性的最佳方法是借助一套实验性框架。它允许新旧两套代码同时在产品服务器上运行，这样无需重启服务器即可在版本1和2之间快速切换。长期来看，投入资源构建一套实验性框架几乎总是值得的。

亚马逊称这样的发布为网页实验室（Weblabs），因为他们会去比较拥有新特性的用户和未拥有新特性的用户之间的差异，进而衡量新特性对用户产生的影响。

然而实施这套实验性的方法还是面临很多挑战。当你的服务需要改动底层数据模型时，你可能没有办法回滚，或者回滚之后会产生一些不相交的数据集。这些问题都很棘手，因此有可能的话你最好让你的数据模型向后兼容，这样可以彻底避免这些问题。

再多的努力也很难让你做到一次性发布成功。因此建立一套机制来确保所有东西在发布前就已衔接完成并配置完好是极具价值的，这样你才不会把问题暴露给上百万的用户。

7.7　亲自验证软件

在将所有服务推送至生产环境后，你需要在2天内完成产品验证。

版本验证测试（BVT，Build Verification Test）

其次，你需要以新用户的身份来亲身体验整个产品，确保产品所有主要功能都可正常使用。

7.8　应对发布带来的各种影响

下面列出五项发布后需要做的事情。
1. 应对回滚。
2. 处理产品危机。
3. 演示产品。
4. 应对媒体。
5. 庆祝发布。

7.8.1　出现问题，回滚软件
这句话值得反复强调：只要成功回滚，发布就还没有失败。
最终你会发现：最好的防守是制定周详的撤退计划。

7.8.2　应对产品危机
危机有时会突然爆发出来，可能是你的网站被瞬间大规模的流量冲垮，也可能是出现安全漏洞、隐私侵害或者定价事故，又可能是一个实习生把本应重定向到数据中心的产品站点重定向到他的个人桌面了（真实故事）。
做事之前，先做准备！
先做准备部分意味着你需要事先安排好人员轮班待命并给他们配备寻呼机。
一个准备充足的产品应该拥有可以快捷关闭服务或限制服务速率的软件开关。切记只要有可能就应该在实验性框架下发布软件，或者软件中带有可禁用特性的标记。
你还可以更早做好应对灾难的准备。在早期软件设计评审会议中，你就可以要求工程团队针对可能的错误设计应对方案。
退避（backoff）时间
确保在交付之前建好退避机制。
你还可以准备得更好一些，比如取得某个服务器专家的联络方式，哪怕你的团队里没有这个角色。如果能维护一套紧急联络簿并牢记于心，并在内部公开那自然更好。
你还可以使用另一种方法来提前建立有效的沟通渠道：创建一个危机扩大邮件组（-escalation@yourcompany.com）以便所有相关人员都能被纳入进来。
如果存在持续的风险（例如一次发布），你需要确保所有相关人员都知道这个风险可能引发的问题。你必须乐于劳烦别人以获得帮助，要知道如果遇上了大危机你是没有时间去遮掩的。
你需要准备的最后一件事情是把下面的内容打印出来，钉在墙上，然后在大麻烦来临之际按照这个剧本行事。

危机应对“剧本”：0～5分钟
不要惊慌。
检查这是否是一起突发事件并评估影响范围。
确定这个问题不止在你这里出现。
你要找到一个确实存在该问题的客户。
不要逃避大问题，出现了就是出现了。不要拼命去欺骗自己说这不是个大问题，没有多少用户受到影响。
发起电话会议。
在主持电话会议的过程中，请不要去掺和讨论解决方案。
打开一个Bug。
你将使用这个Bug来记录对系统做出的改动。
知会危机扩大邮件组成员。

危机应对“剧本”：5～30分钟
问：“我们能回滚吗？”
推迟任何公关计划。
知会相关方。
不要断定危机只对你有影响，确保危机没有危害到其他服务方。
同样地，你也需要确保你没有被其他服务方牵连。
知会社区。
如果你有一个社区论坛或者其他常用的与客户交流的途径，你也许想通过它们让客户知道“目前某某功能看起来出了一点问题，我们正在积极研究如何解决，预计将在某某时间提供更多信息或解决方案”。
然而不要避讳承认产品存在问题，用户会欣赏你的诚实。
保持Bug的更新。
不要把Bug的最新情况藏着掖着，更新出来不会对解决危机有什么负面影响。
寻找并引入专家协助团队解决问题。
知会管理层。

危机处理“剧本”：31分钟及以后
你需要立即进入持久战模式并继续修复问题。此时不存在任何快速而简单的工作清单，相反，这时的工作都需要你日复一日坚持去做，如下。
定期发送状态更新，当有人请求时也可马上发送。
不要把客户晾在一边。控制客户对问题的期望，并保持与他们的沟通。
继续解决问题。
确保满足从事问题解决的人们的需求，提供给他们食物、服务器以及其他团队的支持等。
建立轮班制度，不要让一个开发者持续工作24小时。
采用变通或应急方案。具体来说，就是临时找个方法来替代目前已经瘫痪的系统。

危机处理“剧本”：收尾以及撰写事故调查报告
1. 检查修复情况。你需要再三确认问题是否修复完成了，你需要亲自验证修复情况，就像在发布前亲自验证软件一样。
2. 如果你或者你的公关团队认为有必要对外公布此次危机情况，那么准备一篇博客文章。
3. 在团队路线图中增加任务项并把他们的进展同步给老板或投资人。
4. 撰写事故调查报告。事故调查报告是发给你的管理层的一份基于数据的检讨。

下面列举你老板可能会问的问题。
发生了什么事？
谁受到了影响？
问题是何时出现，又何时终结了？
为什么会发生这个事情？
如何防止这类问题再次发生？
事故调查报告也被称为“故障原因”（COE，Cause Of Error）报告

7.8.3　演示产品
演示的目的在于用讲故事的方式来讲述产品，并在每一步凸显产品使命。
演示也需要遵循既定的策略。先从问题和使命讲起。
在演示开始时一定要让用户明白他为什么应该关心这个产品。
接下来以讲故事的方式把演示串起来。好的演讲总是利用一些故事来吸引听众并让他们产生代入感
不过固然你可以跳过这些小缺陷，但对付它们最好的方法是不让它们出现。所以那些做得最好的演示需要花费数周时间进行准备。
尽管给你列举了很多前车之鉴，但如果你要做一场全程直播的产品演示，那么再多的准备都不为过。你必须为每一段产品演示都准备截图或者视频，因为你永远预测不出所有可能出错的情况。

7.8.4　应对媒体和客户
那些博主喜欢别人也把他们当做媒体），尽可能让他们对你的业务产生深刻印象。
你在产品发布后最值得马上去做的事情之一，就是处理用户的请求，与用户在在线群组中交流。

7.8.5　庆祝发布
每一个令人瞩目的产品发布都离不开团队成员做出的点滴牺牲（有些时候还是巨大的牺牲），因此感谢你的团队为之付出的心血是非常重要的。不要吝惜任何赞美之词，它会让你的团队欢欣鼓舞。
你最好等你的团队度过手忙脚乱的局面后，再庆祝发布以及感谢他们做出的努力。
嘉奖先进个人也很重要，但公开嘉奖具体的某些人既有好处也有风险。这样做之前你需要想清楚有什么好的理由支持你公开嘉奖。我有时候这样做是因为我认为任何事情都是教学的机会，公开嘉奖这些杰出个人，可以让团队明白做到什么程度才算杰出，这样他们就有了明确的前进目标。
不过公开嘉奖一定要谨慎。
不要因为你的考虑不周而令团队成员蒙羞。

第8章胜在团队

一个杰出的团队最终将成为你的长期竞争优势。

8.1　如何组建一支团队

为了组建一支高效的团队，你必须找到能默契配合的工程主管、产品主管和设计主管。
《爱他们，还是失去他们？》
你需要雇佣一名工程经理、一名产品经理、一名项目集经理、一名项目经理或者集四种职能为一体的人。为简洁起见，本书中把这类人叫做PM。

8.1.1　项目集经理
项目集经理的职责重点在于整合不同团队和不同工作职能。
另一种看待项目集经理的方式是把它看做是一个比产品经理更少关注业务、比项目经理更少关注项目的技术角色。

8.1.2　产品经理
通常产品经理的职责更偏重软件的业务方面。甚至有些产品经理不负责软件，他们是典型的MBA出身，专注于品牌管理、定价、市场进入策略等。你的软件的产品经理将负责所有这些工作，还需要努力从用户的角度出发来帮助确定特性开发的优先级。

8.1.3　项目经理
项目经理的主要职责在于排定项目计划和协调团队工作，在谷歌这个职位也被称作技术项目经理。他们负责向工程师要评估值，辨识从属关系以及弄清楚如何在更短的时间内做更多事。
（http://en.wikipedia.org/wiki/MacArthur_Maze）

8.1.4　工程经理
工程经理常常是由老牌的程序员担任的。最佳的工程经理是那些由于热爱团队、善解人意、精通交付并乐于构建卓越产品而晋升到该职位的人。
产品经理、项目集经理或者项目经理，甚至是技术项目经理都可以是工程经理的属下，但也可以是合作伙伴。
每个工程团队都需要工程经理，但不是每个团队都需要产品经理、项目集经理或者项目经理。

8.1.5　如何雇佣产品经理、项目集经理或者工程经理
下面有5个主要的雇佣主管的原则。
雇佣比你聪明的人。
雇佣懂得自己不是来当老板的人。
雇佣表达清晰、言之有物的人。
雇佣用数据说话的人。
雇佣充满活力的人。

1. 雇佣比你聪明的人：如果你乐于放权并相信他们能够胜任队伍领导者的工作，你就必须且只能雇佣比你聪明的人。最佳的检验纯粹智慧的方式是背景调查。在名牌学校拥有很高的平均绩点是额外加分项之一，它预示着候选人能够胜任该角色。实际推出过很多产品是关键的加分项，说到底，如果想要交付出卓越的产品，有过交付经验还是非常重要的。
2. 寻找那些懂得自己不是来当老板的候选人判断PM是否懂得这一点的唯一方法是与他当面接触。我在面对面的面试时会抛出一个从麦肯锡公司那里借来的问题：“讲一个你是如何改变某些人想法的经历吧，以及你使用的技巧。”我等着听候选人是如何应对这种不在掌控的情况的。我会注意其中是否有合作决策（见第11章），是否有基于数据的争论（见第6章）和聪明的向上反馈（见第11章）。
3. 寻找那些表达清晰、言之有物的人
4. 雇佣习惯用数据说话的候选人一个好的技术主管应该具备独立计算的能力。
5. 雇佣充满活力的人主管常常是团队背后的驱动力，如果他们不能给团队带来活力，你的目标就会落空。要在面试中判断候选人是否充满活力，一个可能观察到的迹象是他是否有奇思妙想，我还会看在围绕问题解决过程中他是否有兴奋感。

8.2　如何收购一家公司
通常考虑收购一家公司会出于四个目的。
1，知识产权：你能使用这家公司构建的技术、内容和专利。
2，人才：你能使用这家公司雇佣的人才。
3，客户：你能凭借这家公司的客户来加快业务增长。
4，防御：你买这家公司是为了让别人没法买它。

8.2.2　人才收购
面试还会帮助你了解雇员适合的岗位。我将这些人才分成三大类。
1，关键人才：他们是那些闪闪发光的人，缺了他们，你就得马上找人替代。但他们的专业功底深厚，你都很难找到类似的人来填补他们遗留的空缺。
2，好的雇员：他们是一群你乐于招进来做当前业务的人。他们是一流的候选人，但这种人你自己花个把月也能找得到。
3，多余人才：他们是一群达不到雇佣要求的员工，你需要二选一：和他们续约一段时间以使你能平稳将他们开掉，或者立即终止与他们的雇佣关系。这看起来是个艰难的过渡，但收购的现实就是这样。

8.2.3　客户群收购
确保你正在使用的是正确的数据基线。

8.2.4　防御性收购

8.2.5　收购的陷阱和最佳实践
最后这里还有一些建议和警告，你在考虑收购一家公司时需铭记在心。
1. 计划将你团队的部分人员调入他们团队：不要低估文化适应的重要性，也不要低估新人适应领导风格所需要的时间。
2. 计划整合产品：你不仅需要知道如何将他们的服务器架设在于你的虚拟IP之下，还需要知道如何处理他们的品牌以及如何将双方的计费系统打通。
3. 了解之前所有的交易和负债：在确定收购金额之前，通过会谈了解清楚该公司的欠款、负债以及任何签署过的交易是非常重要的。

8.3　如何与远程团队合作

这很有挑战性，但你可以做一些事情来使生活更轻松一点。事实上有9件事情：
1. 组建一支工程师团队
2. 充分沟通
3. 不要外包设计或PM角色
4. 适应文化差异
5. 构建清晰的需求
6. 忍受时差，通过任何方式会面
7. 委任得力的主管。
8. 大量出差，或者完全不出差
9. 与远程团队共饮

8.3.1　不要租用工程师——组建一支工程师团队
利用由协作产生的动力的最佳方法是组建一支包含至少3名工程师的拥有共同纲领的团队。
共同纲领能给予团队方向感，它还帮助团队独立进行决策，当缺乏时间照管他们的时候你会需要它的。
为团队定义清晰的共同纲领还能帮助他们减少对未来的焦虑。

8.3.2　充分沟通
我注意到在与远程团队合作时有一个常识性的真理：离你越远的团队越焦虑。
为了减轻这种感觉，你能做的最有效的事情是充分地、反复地沟通。
使用Skype、Google+Hangouts、WebEx以及你手边能用的任何工具来提升与远程团队的沟通质量。

8.3.3　尽量不要外包设计和PM角色

8.3.4　重视文化差异
你不需要理解每种文化的独特之处，但需要认识到美国东海岸团队的规矩和西海岸是不同的，西海岸和英国也是不同的。你必须积极了解那些可能有差异的地方，然后想办法去平衡。你能通过在大量的沟通中寻找反应模式来着手了解这些差异。

8.3.5　构建清晰的需求
新团队不管位于何处，都会有些相似点。其中一个相似点是他们真的不知道该干些什么或者为什么该干这个。

8.3.6　忍受时差
我只想出了两个办法来应对时差。
使用数字录像机。
大早上起来工作，或者大晚上工作。无论你更适应哪个，请将你的会议总是安排在一天的开始或结束。

8.3.7　委任得力的主管
让得力的技术主管加入到新团队非常有利于文化和流程的移植，这也是我在团队收购中推荐这种做法的原因。

8.3.8　大量出差，或者完全不出差

8.3.9　与远程团队共饮
这个故事告诉我们，除了尊重文化差异外，你还应该认识到人们在不同的环境会讲不同的真话。酒吧和饭店就是两个能讲真话的地方（我认为是最好的两个地方），它们都是靠酒精来刺激的。

8.4　如何加入到一个新团队
无论你是组建了一支新团队，还是从高层空降到火车失事现场来解决问题，都需要做两件重要的事情：弄清楚你应该扮演的角色，以及下好第一步棋。

你需要立刻做两件重要的事情。
第一件事，不要和团队说你们的产品一团糟这种话。后来我才认识到在大多数情况下你都应该尽量先将事情本身搞清楚，而不是张口就说产品一团糟这种话。
发现问题后你必须做的第二件事情是做一个选择：你是打算延期交付以解决这种混乱状况，还是承认它的存在然后正常交付。

根据我的经验，你将加入的团队可能有五种主要的类型。每种类型都有最佳的应对方式。表8-1展示了如何根据他们说的话来识别团队类型并正确回应。
表8-1　团队类型和回应方式

第9章胜在技术

如果你想顺利地通过面试或者从容地掌控产品开发过程，你需要了解四个S：服务器（server）、服务（service）、速度（speed）和扩容（scaling）。

9.1　第一个S：服务器

尽量不要买服务器。首先，优秀的工程师会尝试学习如何避免去做运维的琐事。如果你因为某些特殊的原因而必须拥有自己的系统，那么不妨向提供商租赁它们。数据层一般是一个数据库，客户记录等数据都放在里面。业务逻辑是运营的大脑。所有复杂的运算都发生在这层。展现层通常是HTML和JavaScript。

9.2　第二个S：服务
SOA将包含业务逻辑的中间层分解成一系列独立的服务。这些服务可能运行在相同的服务器上，但它们的构建、版本管理和运行都是独立的。这些API都需要写进产品需求文档中。关于什么系统应该放在什么服务的边界并不特别重要。对于你的系统来说真正重要的东西是快速和可扩容。如果你想要一个快速的系统，请尽可能避免服务链。所以尽量不要使用服务链，多去寻找能替代它的方案。

SOA的缺陷
尽管SOA有这样的缺陷，史蒂夫和我依然相信，如果你想追求可扩容性（或称可伸缩性）、可扩展性（或称可升级性）以及其他优秀的特性，面向服务是一个值得遵循的好方法。

9.3　第三个S：速度
为了应对这些复杂性管理带来的挑战，一个可行的工作方法是分开加载应用程序的各个独立模块。
文件和服务的独立性将帮助你快速扩容和修改你的服务。这种方法和JavaScript一次性加载所有东西的区别在于封装（Encapsulation）。
缓存（Caching）是另一种解决服务链速度问题的方法。
一个缓存了所有数据的系统被称为“完整缓存”（cache complete）
当你的服务需要的数据不在缓存中时，称为“缓存缺失”
聪明的缓存策略不只会通读后备存储器，它还会将读取到的数据缓存起来。
如果你能建立用户和缓存的黏性，你就能实现通写缓存，让数据先写入缓存，再写入后备存储器。缓存要么通过通读来填满，要么通过“预热”来填满。

9.4　第四个S：扩容

虚拟IP（VIP）：VIP允许使用单个互联网地址来表示拥有的所有服务器。

你接下来一定会听到系统能“线性”或“纵向”扩容之类的词。真正的极客可能会说“常数时间”或“N”。

这时面向服务的架构的一个好处是你可以独立为每个服务扩容

要想这种支持扩容的设计正常工作，你必须将数据存储起来以便它能快捷延伸至新增的服务器。

这虽然不好，但它能够快速返回给你结果并最终完成数据的传送。我们把这个叫做最终一致性。

你还可以通过创建索引来解决某些类型的性能瓶颈。

9.5　如何询问正确的技术问题
以下是一些可以询问的问题。
1. 能请你给我画张系统图吗？你的目的是理解系统图中所有方框都是干什么的。
2. 结果从这个方框传到那个方框的延迟是多少？你应该能通过通览系统图来识别出服务链，询问这类设计的必要性，并弄清楚整体响应时间是多少和最坏的情况下是多少。
3. 可以扩容到N吗？想想当你使这个数字变得无比巨大时会发生什么。
4. 去掉B方框有什么影响？了解你的系统包括了解它会如何出错并如何恢复（希望它能恢复）。
5. 我们是围绕组织边界或系统边界来架构吗？有时你会发现SOA反映的是公司的运营方式，而不是数据或应用程序的结构方式。当出现一些团队难以协作而导致多余的或不正常的系统被构建出来时，检查上面这一点并主动应对。

6. 能通过缓存什么数据来提升性能吗？识别静态数据和常规查询并讨论如何缓存它们。不要忘记询问关于缓存完整性的问题。
7. 能通过独立加载什么数据来提升性能吗？你也应该询问系统的某些部分是否可以分离。

第10章胜在沟通

其中一个关键的技巧是尽可能少开会，但不要不开会。很多时候通过一封优质的邮件就能完全避免开会。

10.1　如何写好邮件
爱因斯坦曾说：“如果不能将事物简单地表达出来，你就没有真正地理解它。”
作为一位出色的领导者，如果想让上司更认可你并获得更高的薪水，你需要不断向团队传递清晰的、具体的信息，使他们明确方向、坚守使命。你还必须做好向上管理，这意味着你要向比你更忙的、有更多邮件需要处理的人们传达与决策或进展相关的大小事项。因此写好邮件对你能否成功至关重要。写邮件最主要的目标应该是清晰、简要地传递单个信息。

10.1.1　像记者写新闻一样写邮件
优秀的记者会将他们想表达的最重要的事情放在文章开头。
在拙劣的发件人写就的邮件中，撰写人“主次不分”，
优秀的发件人则没有犯这种错误，他还多用了20秒时间来为邮件加上称呼、敬语和署名，这样可以帮助信息传递给正确的受众（特别是邮件还抄送给一些人的时候），还可以帮助减少潜在的恶意。
优秀的发件人还有个最为出色的地方在于使用了精确增量表达法。

10.1.2　使用精确增量表达法
精确增量表达法是一种让数字更易被理解的技巧，适合应对那些超快速阅读的人们。

10.1.3　分点阐释原因
优秀的发件人将他的逻辑依据从视觉上划分成多个点进行阐释，从而人们能够轻松发现要点。
在优秀的发件人写就的邮件中，各点之间的行间距是很有意义的。适当留白能帮助你清晰分隔出邮件中重要或特殊的部分。

10.1.4　立即停笔，你已经写完了这封邮件

10.1.5　设法用建议取代质疑

问“为什么工作量都还没估完就确定了发布日期”是一种带有倾向性或引导性的质疑。建议会比质疑更容易被接受。建议能让他人挑挑刺，而质疑是直接冲着他人的，会加剧他人的抵触情绪。不妨试下这种建议式问法。

10.1.6　考虑受众的感受
如果你不根据受众适当调整邮件风格，上到副总裁，下到个体贡献者，你都免不了要得罪。

10.2　如何应对五种类型的会议
如果邮件不管用，那可能是到了要开会的时候。开会可能会痛苦，也可能会高效甚至快乐（是的，你能让开会变得快乐）。让开会变得快乐的最佳途径是理解每种会议的结构、目的和效果。下面有五种你需要掌握的会议类型，排名不分先后。
1. 团队会议：这类会议用来了解近况以及利用团队合力来深入讨论和解决特定问题。
2. 站会：站会是一种超级简短的会议，它只用来交流近况，促使团队内部信息透明、责任到位。
3. 1对1：1对1会议是指只有你和另外一个人之间的会议。
4. 产品/工程/用户体验评审：这是一种大规模会议，通常会有一些大老板参加。这个会议既要向高管通报产品进展，又要收集组织内最富有经验的人们的反馈建议。
5. 头脑风暴会：这是所有会议中最有趣的，它形式自由，能激发想法，还能让团队主动参与到问题的解决中去。

10.2.1　团队会议

团队会议每周开一次，每次30~60分钟，你和你的工程团队需要参加，一般由你主持。这类会议的目的是促使团队坚守使命并就当前一些悬而未决的问题达成共识。议事日程需要提前发布。当你开始团队会议的时候，一个不错的开场方法是先回顾你的数据指标。你还可以利用团队会议来达到更高层次的目的。在季度开始，我会重新审视团队季度目标，并调整目标直到所有人都认同。在季度中间，团队会议可以确保你不会在方向盘上睡觉以至于团队状态“哗”地从绿到红，或许至少可以让团队状态先从绿到黄，再从黄到红。在季度结束，我们会在团队会议上评估我们相对于目标的进展情况。当项目计划表更新完毕，即会议的信息更新部分结束后，你或许需要聊下所有需要团队成员知晓的最新进展，这些重要进展包括行业变化、业务近况和其他与使命相关的事项。切记，确保团队坚守使命是你的工作。会议的最后部分专用于讨论并解决那些悬而未决的问题。处理完这些问题后，问下团队是否还有其他的东西需要讨论。

10.2.2　站会
我喜欢每天开一次站会，因为这能促使团队内部责任到位、信息透明。每个人在站会中应该汇报下列信息：
我昨天做了什么
我今天要做什么
我是否遇到阻碍

10.2.3　1对1会议
1对1会议非常适合主管们相约在一起坦率地进行交流并公开问题。它小而专注的特点也使得它很适合用来完成需要合作的工作。请安排每周或每两周与所有主管开一轮1对1的会议，即便你觉得没有必要。

10.2.4　产品、用户体验和工程设计评审会
任何种类的“评审会”通常都是有大老板参加的大规模会议。其中产品评审会的首要目标是让老板们认可你的产品方向，提供给你反馈，或让他们知道你的最新进展。你要先想清楚你要传递的确切信息是什么，然后尽可能清晰、简洁地传递出去。用户体验评审会则只需要准备产品原型图就可以了。最好让设计师演示他们自己制作的原型。工程评审会的目标是：赋予开发主管权力，收集周围经验最丰富的工程师的专业反馈，以及尽量少花时间在演示上。

10.2.5　头脑风暴会
它的目标是收集尽可能多的想法，不管是新的产品名称，扩容问题的解决方案，还是系统错误的可能的根本原因，它都收集。我会在头脑风暴会上遵循4个基本规则，我确信它们能为会议带来更多创造性的效果。这些规则是：
λ 不要在头脑风暴过程中批评他人的想法
λ 说“是的，嗯……”
λ 通过结构化来促进讨论
λ 在头脑风暴结束时明确告知大家头脑风暴结束了

1. 不要在头脑风暴过程中批评他人的想法
还有一个有助于避免批评并鼓励人们贡献想法的方法，是将所有想法都写在白板上。大幅的画画在专用画纸上也可以，会议结束后你还可以带走它们。
2. 说“是的，嗯……”
即兴表演中有一个演员们制定（也可能是在面对大量嘘声中逐渐形成的）的用于避免情节停顿的规则。它叫“是的，嗯……”规则
3. 通过结构化来促进讨论
结构化地讨论更有条理并能鼓励创造性。
4. 在头脑风暴结束时明确告知大家头脑风暴结束了

10.3　如何组织好会议

如第11章关于如何处理冲突的最佳实践就适用于处理会议中的冲突。除去这个，我还遵循四个最佳实践：
1. 会后立即发出主题纪要
2. 允许改变开会的目的
3. 拒绝在团队会议中发泄负面情绪，但允许在1对1会议中发泄
4. 使用鱼骨图等辅助工具解决问题

10.3.1　会后立即发出主题纪要
你之所以需要在会后立即发出会议纪要，是因为只有这样它的作用才能最大化，你的团队才能感觉到他们是会议的参与者和下一步计划的执行者。在纪要中先放结论和下一步计划，再放讨论的详情，这样那些不认同结论的阅读者也能了解你们得出它们的原因。请写一段清爽的，2~5行的概要放在纪要顶部，人们会感谢你的。

10.3.2　允许改变开会的目的
开会有三大目的：解决问题、收集信息、传递信息。开会目的是可以改变的，你千万要记住这点。

10.3.3　拒绝在团队会议中发泄负面情绪，但允许在1对1会议中发泄

10.3.4　使用鱼骨图等工具来解决问题

10.4　如何做好演示

下面是总结出来的技巧：
λ 将演示时间控制在15分钟内
λ 永远传达且只传达一个信息
λ 讲故事
λ 制作“综述单页”
λ 重点演示用户体验
λ 极度专注倾听

10.4.1　将演示时间控制在15分钟内

10.4.2　永远只传达一个信息
如果你连关键信息是什么都不知道，还是取消演示吧。一旦准备好了你要传递的信息后，始终围绕它来做演示。去掉与这个信息无关的数据或议题。制作完演示稿后不要忘记多检查几次，务必确保它就是你要传递的信息。

10.4.3　讲故事
人们喜欢听故事。故事有代入感，能将你要传递的信息与真实的生活连接起来。除了去掉了故弄玄虚的字眼和缩写词，你还通过讲故事做到了其他五件事情。将创意与个人生活关联起来，从而使听众产生了代入感。让观众跟着你的节奏走。提供了一个人们都能理解的具体例子。描述了你将要解决的问题。描述了你的解决方案将如何提升用户的生活品质。我经常看到偏技术的演示者不去描述用户场景，而是大谈特谈特性细节。有决断力的高管常常会在演示中间叫停演示并强制演示者清晰阐述用户场景，在近况汇报会议上，你只需简单地列举证据来支持要传递的信息即可。其他类型的演示，如用户体验评审或推销，适合讲故事的原因是你能围绕用户组织内容。

10.4.4　制作“综述单页”
谷歌前工程总监彼得·威尔逊发明了“综述单页”法。彼得的“综述单页”法是指演示稿的第一张幻灯片，即位于标题页之后的第一页，必须包含你演示的关键要素。 “综述单页”法和“讲故事”法并不兼容，因此你需要谨慎使用这种方法

“综述单页”应该包含以下四块内容。
1. 你想讨论的东西是什么
避免缩写词和新名词。
需要向高管解释的东西越少越好。
2. 机会
换句话说，你和高管们愿意花费时间讨论这个议题的原因是什么？
你也可以将演示的核心数据压缩成1到2个重要数据点。将这些数据点添加到“综述单页”中能增加其合理性并在开始阶段就打消受众的疑虑。
3. 提供的解决方案
请用清爽的文字来阐述解决方案，
添加原型图的链接，这样当需要时你可以快速将它拉出来。
4. 成本和实施时间表
某些情况下它还可能是你要问的内容，你需要管理层给你这些东西。
如果你的管理层打算给你承诺，他们也需要你给他们一个类似的承诺。你需要提供一张你能负责的时间表。

10.4.5　重点演示用户体验
打破成见并在脑海中建立新的具体图景的最佳方式之一是使用图片。具体来说便是重点演示用户体验的原型图。
在重点演示用户体验时仍然阐明关键信息。
为了从外部用户的角度来描述你的原型，请首先说明首要用户目标而非描述特性。然后你可以指出用户体验是如何满足这个目标的。

10.4.6　极度专注倾听
能否分清建议和需求决定了你是能卓越地完成交付还是什么也交付不了。一个有效地捕捉各种意见细微之处的方法是让一个值得信任的同事一字不差地把它们记下来。提前了解谁是关键的利益相关者将使你聚焦在最重要的反馈上，并让你高效地分配记笔记的时间。

10.4.7　更多的演示技巧
如果一页幻灯片上不只是一幅图加一句话时，请把这页的信息要点放在标题里。苹果那帮人很擅长这个技巧，不过在户外或对较大规模人群进行演示时这样做的确是最好的。
如果你发现先前的技巧并不适用，请把信息要点放在标题里。
如果你没有模板，请使用基本的商学院的那种蓝色背景，配上黄色和白色的字。它们在任何投影仪中都能得到很好的呈现。
阅读并遵循罗宾·威廉姆斯所著的《写给大家看的设计书》一书中提及的基本视觉设计原则。
阅读并遵循爱德华·塔夫特所著的The Visual Display of Quantitative Information，2nd Edition一书中提及的信息展示原则。
不要担心留白。人们喜欢留白多的幻灯片。
不要使用“构建版本”这类字眼，除非你想让听众认为你华而不实。
不要使用红色来代表除危险或糟糕之外的任何其他意思。

第11章胜在决策

软件是决策的物质载体。做决策不是简简单单地说“行”还是“不行”。软件不像大多数英文编撰物，它的复杂性决定了它是团队共建的产物，因此它也是团队决策的反映。你必须设法让你的团队成员对他们所钟爱的事情说不。

11.1　推后：“我们明天再完成。”
由于人类畏惧冲突的天性，很多软件团队主管害怕说不，于是“蠕变特性”（Featuritis或者Creeping Featurism）成为一种常见病。将不属于绝对最小化可行特性集的所有特性放到V2。

11.2　谈判：“行，再给你10分钟。”
几乎所有特性或用户体验的争论最后就会变得像绑匪谈判。依靠谈判快速达成共识是通往成功的必经之路。谈判的第一步是正确地认识到不管你是不是
产品的负责人，你都不是老板。团队主管常常会召开小范围的经营决策会议，这是错误的。要想交付卓越的产品，你需要让团队成员体验到参与感和发言权。更好的团队决策制定过程是在早期就让所有团队成员都参与进来。如果在你思考让谁参与决策时有什么指导性原则需要遵从的话，那一定是信息透明。请将决策的理由透明，将决策的时间透明，将团队参与决策的途径透明。一旦将关键人物聚到一起后，你需要通过谈判而不是击败别人来达成共识。安妮塔·伍利和托马斯·马龙对此进行了一些研究，为我们提供了出现这种情况的原因的深入见解。因此你的目标是促使产生一个满足各方需求的创造性的解决方案。哈佛谈判项目（The Harvard Negotiation Project）认为这个过程的首要关键步骤是达成对目标的共识拥有创建满足各方需求的共赢的解决方案的能力是作为领导者最重要也最令人满意的方面之一，它还会鼓励你将每次谈判都视为创建解决方案的机会。有时候甚至还未讨论目标你就陷入谈判中了。这时候有三种帮助你回归正轨的方法。聚焦于促进。不要一开始就尝试去解决问题，否则你会带着先入为主的观点以至于无法保持中立，这会使讨论更加复杂。你应该首选确保听到每个人说的话。 “先寻求理解，再寻求被理解。”你需要极其努力地理解他们到底在说什么。问问你自己，他们真正关心的是什么？然后通过提问来验证你的假设。如果你已经有了倾向性的判断，不妨先说出来，然后让其他人继续发表观点。我认为当其他人已经知道你有倾向时，你不妨开场先阐明你的倾向，然后把指挥棒交给其他人以便能专心倾听。这个方法真诚且高效。有一个常见的场景需要一些稍微专业的技能：财务谈判。

11.2.1　阶段1：这不是你的错
财务谈判几乎总是会令人心烦，究其原因是因为商业社会里公司媒介精英为了实现自我价值而将谈判的强度拉得越来越大。

11.2.2　阶段2：公平谈判并使用数据支持
最公平地谈成某个数字的方法是参考交易数据。

11.2.3　阶段3：那个数据没谈成……我们编个新数据吧！
由于你或你的对手会不断披露和编造新的信息，因此财务谈判会耗费很长的时间。编造信息特别有挑战性。

11.2.4　阶段4：寻找可免费提供的东西
在阶段4，各方都会设法往交易中塞一些没有价值、无须成本的扯淡的东西。

11.2.5　阶段5：转身离开并安静思考
这对谈判来说是个好事，双方都可暂时离开并回到产品上面。这个重新拉开的距离允许你再次思考现实的情况。

11.2.6　阶段6：协议、文书工作、以及互相指责
就在你觉得交易已经完成时，你会发现任何公平的、有价值的交易都还有大量的文书工作要做。这些细枝末节的东西之所以存在是因为任何合同都需要非常清晰才能具备效力。为了增加明晰程度，你必须定义一切细节，这时你会发现你们的沟通尚有很多不明之处，而这些不明之处会导致冲突。

11.3　处理冲突
第三个也是最后一个你需要借以达成卓越共识的工具是冲突管理。更可能的是和你一起工作的都是拥有超低沟通能力和极高专业能力的人们。
不要假设这场冲突的另外一方一定就是一个讨厌鬼，考虑另外一些可能的背景情况。如果你脑补出另一些可能的背景情况，你就能以更积极的心态来应对冲突。
等到你相信你所面对的家伙不一定是个讨厌鬼时，你就能找到问题的根源。90%的情况下冲突的根源都是沟通不畅。另外10%中有1%是因为你面对的的确是个讨厌鬼，剩下9%是因为目标的方向错了。你真正需要了解的只是那90%的情况，你和对方在“各说各的”。换句话说，你们对重要的事情达成了共识但却纠缠在一些细节或措词问题上。我发现当工程师和工程经理真的关心某件较大的事情时，他们会经常把焦点放在细节上，如不要写重复的代码等，毕竟细节更容易被具象化。由于你知道这时你们有很大可能在各说各的，你便可以回到上一步并问问自己其他人真正想说的是什么。这是第一步。

一旦确定你们正在各说各的，你便可以借此机会建立一个通用的术语表，这样你们在讨论中就不会因为措词问题而导致沟通不畅。两个关键且常见的背景元素。第一，时间总是一个挑战，清晰地说明时间上的限制有助于其他人了解什么是可能做到的。不相信时间会成为一个问题？让一个朋友打两个中等复杂的结，然后你和另一个朋友蒙着眼睛去解开这两个结，整个过程不准说话。
第二，常常有一些别人并不知道的假设或者别人自己做出的假设。
再补充一点，请设法确保你的项目名称在产品的整个生命周期中是一致的，否则你会让那些不知情的人们感到迷惑。有时候别人听不懂你说的话，而你企图通过分类法和背景介绍来澄清它们也遭遇抵制或让人丧气时，请转向白板。我发现图画和列表能使事物变得清晰。然而有时冲突并非由明显的沟通不畅或根本的观点分歧导致的。当有人戳中你不想被别人戳中的地方时冲突也会产生。如果想要更好地控制每个人都会有的强烈的情绪反应，你需要先识别出是什么引发了这样一个反应。虽然你可以管理自己的情绪反应，但因为软件工作强度很高所以偶尔发发脾气是很正常的。所以无须惊讶他们的情绪会很强烈，你最好马上接受这个现实：惹恼他们是不可避免的，尤其在你设法交付的时候。但如果你能客观地进行交流，也许可以减少惹恼他们的次数。客观地交流是指只围绕软件、用户或问题进行讨论，而不把人牵扯进来。

我最钟爱的三个客观化的方法是：
λ 不说“你”或“我”。
λ 聚焦在角色模型上，而不是人上。
λ 使用客观指标。

11.3.1　不说“你”或“我”
试着修改邮件中所有使用了“我”或“你”的句子。这样能让邮件内容变得客观而且聚焦在产品的表达上，而不是聚焦在“你”觉得怎样或“我”提出什么上。如果你在口头交流中也能去掉“你”和“我”，那就更好了。

11.3.2　聚焦在角色模型上，而不是人上
引入莎拉这个角色可以大幅增加交流的客观性。更重要的是，当到了要做艰难决策的时候角色模型能发挥更大的作用，因为你在砍掉某个具体特性时，感觉受到不公平待遇的不是那个发明它的人，而是某个角色模型。

11.3.3　使用客观指标
如果同意事实没有观点重要，那你接下来就需要一套与观点打交道的方法。幸运的是我们有可用性测试和决策矩阵来帮忙。决策矩阵则是一个简单的图表，它可以帮助你做多选一的决策。如果时间充足，进一步使用决策矩阵是很有价值的。你可以增加一列“权重”或“优先级”

第12章胜在从容

长期以来，我和同事一道致力于交付事业，下面这些就是我收集并践行的经过实践检验的建议的精髓部分。我把它分为5个类别，希望能对你有所帮助。
如何平衡交付、质量和影响、团队这三者的关系，你才能交付一款卓越的软件。
如何应对随机情况，你才能继续按原定节奏交付一款卓越的软件。随机情况是指当你的管理层掷给你一个弧线球或者你的团队脱离正轨时出现的情况。随机情况是每个在谷歌或亚马逊工作的人都理解的词之一，因为它是与帮助团队专注于交付相对立的。
如何妥善地管好你的精力，你才能1个顶3个。
如何找人以及在什么时候找人，你才能让合适的人做合适的事。
如何咽下狗屎三明治，因为有时候你的确得咽下去。

12.1　如何平衡交付、质量和影响、团队这三者的关系
现在你还可以使用一些工具来检查你是否失去平衡，如团队周会的气氛、高中蒙羞测试以及你的产品需求文档。

12.2　如何应对随机情况
为了应对新的特性需求，你可以创建一个简单的共享文档来集中记录它们。将文档对每个人开放，这种透明度会减少人们出于恐惧的关心和你收到的问题数量。当随机的建议来自管理层或投资人时，你可以使用版本1测试来帮忙打消这个想法。你需要从开发时间、系统设计、容量以及其他你所依赖的职能部门（如法务）等方面来评估成本。这时你们可以就成本和收益进行真实、理性的交流。在成本评估前你没有任何理由退回任何一个需求，除非这个需求是不正当的。如果这个建议真得非常奇葩但又必须放在版本1，有时候你最该做的事情不是去反对。遇到这些情况你可以和你的团队一起投入最小的精力并以最快的速度将这个特性部署到你的可信测试者那儿去，然后等待并观察。在评审会议上认真倾听能帮助你避免某些随机情况。切记，如果大老板说你应该做某件事，你几乎一定需要做这件事。不要存在侥幸心理认为老板们会忘了他们提出过这个需求。还有很多随机情况的来源是你无法控制的，比如公司优先级发生了变化。而有的人脑袋里就没有一根政治的筋。我属于后一种人，所以我只能提供五条基本的策略来应对公司优先级的变化，这五条策略是按先后顺序排列的。
1. 弄清楚公司优先级的变化是不是真的。
2. 更改产品的表达方式以迎合变化。
3. 尽可能小地改动。请和你的工程团队合力找出一条成本低见效快的方法。请进行小的改动，然后回归正常的节奏。
4. 请求通融。
5. 忍。

所有这些策略也适用于应对大规模的基础设施变更。

一个关于如何与你所依赖的基础设施打交道的经验法则：你需要坐在火车中部。

找到两到三个可供参考他们进展的团队。当发现某个团队切换到新基础设施的过程相当轻松，那么你也是时候切换了。

12.3　在交付过程中如何管理精力
它教导我必须学会为每个任务分配合理的时间。因为不可能做完团队需要你做的所有事情，所以你需要优先做最应该做的事情，且不要在意没有做完所有事情。彼得·德鲁克在《卓有成效的管理者》中也呼应了这个观点。他说你首先应该做那些只有你能做的事情。这个工作方法有助于将你起到的作用最大化并防止你成为阻碍者。如果你觉得学会高效利用时间和精力太难了，或者认识到这是一个你完全缺失的技能时，考虑从托尼·施瓦茨的能量工程中学会该如何做吧。施瓦茨曾在《哈佛商业评论》上发表了一篇名为“管理你的精力，而不是时间”（Manage your energy, not your time）的卓越文章并随后围绕优化个人精力这个概念出版了一本书并开发了一套业务。最后一个管理精力的技巧是制定工作日程表。

12.4　如何把向上求援当成工具而非托词
当遇到下面任何一种情况时，你很可能需要向上求援。
你正设法为一个在某些方面比较愚蠢的管理层下达的命令辩护。
你真心不懂为什么你要做这些事情。像这种情况，你最好能单独从大老板那里得到一个解释，因为大老板可能会更清楚一些。
你不负责这个问题。这里需要重点说明的是我并非主张你应事不关己高高挂起。
当你发现有个问题是其他人负责的，且那个人不喜欢你越俎代庖，那就向上求援吧。
你需要与之打交道的高管不愿接见你。

12.5　如何咽下狗屎三明治并生存下去
你现在就需要接受这个事实：你团队主管的生涯中一定会经历一些令人厌恶的时刻。你可以把这些三明治当作高中生活，生存下来才是重点。当收到一个三明治时你应保持微笑，咽下三明治，然后继续前行。

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

附录2 团队不可或缺的工件

你能从www.shippinggreatness.com上下载到其中一些工件的模板。

轮值表——将寻呼器号码和手机号码的清单复制到一张钱包大小的纸上。
使用Wiki搭建的“联络簿”，用于遇到故障、突发事件或问题时寻找相关负责人。这个列表应该包括法务、公关、市场、产品团队、工程团队和网络运维（或者任何负责生产基础设施的部门）的负责人和联系信息。
描述使命的语句。
关于未来两年的清晰策略。
一页简要说明产品的人物/事件/原因/时间/方法的文档。
产品需求文档，或者叫功能规格说明。
新闻稿。
线框原型图或者餐巾纸草图。
内部FAQ文档，其中部分问答打上外部FAQ标签以作为客户支持内容的原始素材。
沟通文档，包括关键信息、有潜在危险的问题和对这些问题的回应。
发布时穿的T恤衫。
包含测试时间的开发计划表。
未来两年的路线图。
内部用户列表和迁移时间表（适用于基础设施项目）。
可信测试者列表（适用于面向外部的产品）。
特性需求列表，并将内部和外部客户中呼声最高的三个特性需求高亮。
开放问题列表，并清晰标记这些问题的状态。
进行中的会议纪要。最好建一个文档保存项目所有的历史会议纪要。
发布计划或发布规程。
记录什么特性在什么时间发布的生成变更列表。在排查客户问题时特别有用。
对增长预测和硬件配置需求提前进行计划的生产设计文档。
专利注册文件、商标注册文件和版权申明文件。
隐私说明。
出色的数据指标——包含内部的状态面板和一些供外部消费的清洗过的数据指标。
为幻灯片、演示、评审、发布准备的产品截图。
团队本季度目标以及上季度目标完成情况。
Bug状态面板和阻碍每个发布的Bug列表。
错误原因报告或事后调查报告。
会议纪要和团队周会、用户界面评审、产品评审、工程评审、Bug处理、法务评审、业务拓展周会以及客户支持碰头会的时间计划表。

谷歌和亚马逊如何做产品

疏桐 2016-12-24 0赞

快速翻了一下，感觉更适合IT经理，内容比较全面，有一定实用性。用户体验当面有两点印象深刻： 1，用户体验设计师尤为关注信息架构，这里的信息架构和EA架构中的信息架构不同，侧重信息该如何在用户界面中呈现，而不关心底层数据结构。 2，用户体验要关注6个问题：该用户界面要求用户造成的最重要的任务是什么？这是最简单的解决方案吗？信息是否组织得当？设计是否易总且一目了然？能否减少用户点击次数？

产品交付之道

paul 2014-12-16 1赞

这本书读起来轻松，收获也不能算多。吸引我来读的当然是谷歌和亚马逊这两个大名头，本书中有不少作者的经验，但感觉缺少点系统性，语言上有时轻浮过，我想在表达时怎么把握这个度是要考虑的。
这本书实际上讨论了一个产品从产品立项、产品定义、用户体验、开发、测试、度量、发布的全流程和方方面面。
适合于遇到问题，来这里找找答案，说不定作者的一些做法和观点能给你参考，但如果指望照着作者的描述系统进行一个产品的开发交付，估计是不够的。

部分摘录：
        * 有效的交付过程7阶段：确定正确的产品方向、清晰详细的定义产品、设计用户体验、做基础性的项目管理工作、测试、建立衡量产品成败的指标、正式发布产品。
        * “以客户为导向，而不是以竞争为导向”，专注于解决真正的客户问题。
        * 卓越的使命需要符合三点要求：能够唤起人们的兴趣，提供言之有物且能指明方向的原则，适合印在T恤上。
        * 最简单的项目管理方法：
        *
                * 创建一张简单的计划表并持续维护。
                * 跟踪Bug，观察燃尽图，计算实现零Bug率的日期。
                * 谨慎管理你的依赖。

        * 优秀的量化指标：测量成本低，测量可靠且可重复检验，能频繁测量（最好实时），团队能根据它做出明智改变，专注于客户。例子：超市某产品的过期数量，理想值是1，超过1就降低存货水平，如果为0，就提升存货水平。
        * 因为不可能完成团队需要你做的所有事，所以需要优先做最应该做的事情，且不要在意没有做完所有事情。首先应该做那些只有你能做的事情。
        * “能安全走出机舱的着陆就是最好的着陆”，能交付的软件就是最好的软件。

不要让书名蒙蔽了你的双眼

萧三纹 2015-06-03 3赞

这本书读了有2周半，其中1周因为出国所以没怎么看。

总的来说，本书的名头有点大，一个「谷歌」另一个「亚马逊」就足够把人吓尿了，实际还是一本比较偏向项目管理的产品经理入门书。

书的前面3章，策略、定义和用户体验，算是偏向产品的一部分。其中收益模型表格很值得参考，产品嘛，给上头或投资人汇报的时候，一定要告诉他们「产品能带来多大的收益」，产品的本质还是商业。需要提一下，文中给出的模板地址是错误的，实际地址是：http://blog.shippinggreatness.com

关于用户体验这章，其中有6个自问自答的问题还不错，能够比较好的梳理当前界面的是否符合用户预期。第1个问题是该界面要求用户完成的最重要任务是什么？一个页面最好只有一个任务；这是最简单的解决方案吗？把方案简化到最低；信息组织是否得当？即信息的内容和层次是否清晰；第4个问题，设计是否易用且一目了然，感觉有点啰嗦的问题；5标准是否一致？其实就是统一性问题；最后一个能否减少用户点击次数？这个是大家很容易忽视的问题，产品经理为了确保产品逻辑严谨，可能会有很多让用户确认的地方，保证不让用户出错，其实没必要，也是按照第2个问题能省则省。少点几次，用户不会感觉到失去什么，只会觉得更流畅。

剩下的内容我就没有细看了。有一段是关于开会的，包括会议的类型，开会的时间，会后立刻发布会议纪要等，比较合理，知道后尝试去做就好。

所以，以后的教训是，不要被书名给骗了。

交付产品是一种怎样的体验

leeforce 2016-11-22 5赞

此书的经验，一线人员最有感触。

读书笔记：

1. 设定「目标」告诉别人你要什么，设定「非目标」告诉别人你不要什么。为产品设定「非目标」非常有用。// 诚如乔布斯所说，重要的不是做什么，而是不做什么。

2. 做表格时，将可编辑的单元格设为黄色，以便于识别哪些是预估值、哪些是计算值。

3. 数字模型往往对假设高度敏感，这不是它的问题，而是优点。

4. 努力做「细节帝」。// 亚马逊的 CEO 贝索斯就是如此。

5. 好的 UI 设计师会善用栅格系统来排列元件，以增强产品体验的一致性。// 这就是我常说的，「对齐」是一切设计最重要的元素。

6. 一个界面只有一个主要按钮。

7. 若一个流程有 3 ~ 4 步，要告诉用户当前在哪一步、共有多少步。

8. 与设计师沟通，首先要在某些设计原理上达成共识。

9. 需同时考虑新用户、老用户分别看到什么内容。

10. 通常五天的开发时间里只有三天是具备生产力的，因为有各种变动事项。对生产率估值 60% 是比较合理的做法。// 我的经验，50% 都有可能，但 50% 应是底线。

11. 项目管理，只跟踪剩余时间，其他均无视。

12. 高中蒙羞测试：我能确信当一个高中老同学看到我的产品时，我不会羞愧吗。

13. 调试过劳死，测试嗨翻天。// Debug v.s. Testing，谷歌贴在厕所里的段子。

14. 一流的人雇佣一流的人，二流的人雇佣三流的人。

15. 测试应包括试图破坏你的网站。// 安全威胁，无论怎么过虑都不为过。

16. CEO 经常会遭遇一些别人从未遭遇过的糟糕体验。

17. 感谢每一个 Bug。

18. 讨论每个 Bug 的时间不要超过一分钟：频率，严重性，修复成本。

19. 开箱体验：删掉帐号，重新关注如何创建帐号及为帐号添加信息。

20. 不要让团队冲刺超过 1 个月。

21. 不要选择周五或临近假期作重大发布。// 但现实常常不允许啊。

22. 一个准备充足的产品应当有快捷关闭服务或限制服务速率的软件开关。

23. 产品演示，先从问题和使命讲起。

24. 不要相信面试，要相信背景调查。

25. 面试佳题：讲一个你如何改变别人想法的经历，以及你的技巧。

26. 工程师团队协作的临界数量是 3 人。

27. 离你越远的团队越焦虑。

28. 如果不能将事物简单地表达出来，你就没有真正理解它。// 爱因斯坦说的。

29. 尽可能少开会，但不要不开会。

30. 精确增量表达法：将 xx 增加或减少 xx，即从 xx 增加或减少到 xx。// 重点是后半句必须写出来，在沟通中。

31. 书面表达中，行间距有其深刻意义。

32. 建议比质疑更容易被接受。

33. 团队会议结束之前，给 7 秒钟的安静时间。

34. 多说「Yes, and …」。

35. 会议现场，善用结构化来促进讨论。

36. 会后，立即发出会议纪要。

37. 标准的演示时间控制在 10 ~ 15 分钟。

38. 项目概要：问题，机会，解决方案，成本，时间表。

39. 先寻求理解，再寻求被理解。

40. 当你相信你面前的家伙不一定是个讨厌鬼时，你就能找到问题的根源。

41. 少说「你」或「我」。// 多说角色，保持客观。

42. 记得弄清楚优先级的变化是不是真的。

43. 首先应该做那些只有你能做的事情。

44. 别人越慌乱，你要越镇定。

45. 能交付的软件，就是最好的软件。

这是我第一本翻译的书，虽然翻译不尽人意，但书的确是好书。

燕窝 2014-05-22 13

先说书本身，再说翻译。

好的产品经理可以一而再、再而三的成功，比如张小龙从foxmail、QQ邮箱到微信，再比如周鸿祎从3721、360安全卫士到浏览器。

为什么可以不断成功呢？我觉得背后一个很重要的原因在于他们不断成熟的思考框架。

这是一个思考产品如何才算成功、如何才能走向成功的框架。这本书便是想传递一个这样的思考框架。

它的一本纯粹的干货。作者在Google和Amazon都带过产品研发团队。他通过反思自己的经验，总结出了产品从萌芽到上线你所必须思考以及实践的东西。

这本书堪称产品经理百科全书的导读，你可以通过一览目录来了解它的广度。而且这本书每个章节都不是蜻蜓点水，字里行间都充满了实践的智慧。

所以不管你是新手或者老手，都值得拥有。

再说翻译。

翻译是绝对的“慢工出细活”。

一段话，咀嚼1个小时，还是咀嚼2个小时，修改1次，还是修改2次，最后出来的质量一定是不一样的。这点我比较惭愧，投入的时间还是不够。所以当我拿到样书后再看一遍后，发现好些地方还是非常拗口，即使改过4、5遍。

翻译还讲究境界，这个境界来自于你的积累。我经常会遇到这样的场景：读中文的时候百般拗口，然而回头再看看下英文，又觉得似乎要准确表达意思又只能如此。

所以先向大家道歉，请原谅我这种投入时间不够、境界又不到的译者。真希望有机会出个修订版。

最后，如果各位对文章有任何疑问的点，请回帖，谢谢。

交付产品是一种怎样的体验

leeforce 2016-11-22 5

此书的经验，一线人员最有感触。

读书笔记：

1. 设定「目标」告诉别人你要什么，设定「非目标」告诉别人你不要什么。为产品设定「非目标」非常有用。// 诚如乔布斯所说，重要的不是做什么，而是不做什么。

2. 做表格时，将可编辑的单元格设为黄色，以便于识别哪些是预估值、哪些是计算值。

3. 数字模型往往对假设高度敏感，这不是它的问题，而是优点。

4. 努力做「细节帝」。// 亚马逊的 CEO 贝索斯就是如此。

5. 好的 UI 设计师会善用栅格系统来排列元件，以增强产品体验的一致性。// 这就是我常说的，「对齐」是一切设计最重要的元素。

6. 一个界面只有一个主要按钮。

7. 若一个流程有 3 ~ 4 步，要告诉用户当前在哪一步、共有多少步。

8. 与设计师沟通，首先要在某些设计原理上达成共识。

9. 需同时考虑新用户、老用户分别看到什么内容。

10. 通常五天的开发时间里只有三天是具备生产力的，因为有各种变动事项。对生产率估值 60% 是比较合理的做法。// 我的经验，50% 都有可能，但 50% 应是底线。

11. 项目管理，只跟踪剩余时间，其他均无视。

12. 高中蒙羞测试：我能确信当一个高中老同学看到我的产品时，我不会羞愧吗。

13. 调试过劳死，测试嗨翻天。// Debug v.s. Testing，谷歌贴在厕所里的段子。

14. 一流的人雇佣一流的人，二流的人雇佣三流的人。

15. 测试应包括试图破坏你的网站。// 安全威胁，无论怎么过虑都不为过。

16. CEO 经常会遭遇一些别人从未遭遇过的糟糕体验。

17. 感谢每一个 Bug。

18. 讨论每个 Bug 的时间不要超过一分钟：频率，严重性，修复成本。

19. 开箱体验：删掉帐号，重新关注如何创建帐号及为帐号添加信息。

20. 不要让团队冲刺超过 1 个月。

21. 不要选择周五或临近假期作重大发布。// 但现实常常不允许啊。

22. 一个准备充足的产品应当有快捷关闭服务或限制服务速率的软件开关。

23. 产品演示，先从问题和使命讲起。

24. 不要相信面试，要相信背景调查。

25. 面试佳题：讲一个你如何改变别人想法的经历，以及你的技巧。

26. 工程师团队协作的临界数量是 3 人。

27. 离你越远的团队越焦虑。

28. 如果不能将事物简单地表达出来，你就没有真正理解它。// 爱因斯坦说的。

29. 尽可能少开会，但不要不开会。

30. 精确增量表达法：将 xx 增加或减少 xx，即从 xx 增加或减少到 xx。// 重点是后半句必须写出来，在沟通中。

31. 书面表达中，行间距有其深刻意义。

32. 建议比质疑更容易被接受。

33. 团队会议结束之前，给 7 秒钟的安静时间。

34. 多说「Yes, and …」。

35. 会议现场，善用结构化来促进讨论。

36. 会后，立即发出会议纪要。

37. 标准的演示时间控制在 10 ~ 15 分钟。

38. 项目概要：问题，机会，解决方案，成本，时间表。

39. 先寻求理解，再寻求被理解。

40. 当你相信你面前的家伙不一定是个讨厌鬼时，你就能找到问题的根源。

41. 少说「你」或「我」。// 多说角色，保持客观。

42. 记得弄清楚优先级的变化是不是真的。

43. 首先应该做那些只有你能做的事情。

44. 别人越慌乱，你要越镇定。

45. 能交付的软件，就是最好的软件。

不要让书名蒙蔽了你的双眼

萧三纹 2015-06-03 3

这本书读了有2周半，其中1周因为出国所以没怎么看。

总的来说，本书的名头有点大，一个「谷歌」另一个「亚马逊」就足够把人吓尿了，实际还是一本比较偏向项目管理的产品经理入门书。

书的前面3章，策略、定义和用户体验，算是偏向产品的一部分。其中收益模型表格很值得参考，产品嘛，给上头或投资人汇报的时候，一定要告诉他们「产品能带来多大的收益」，产品的本质还是商业。需要提一下，文中给出的模板地址是错误的，实际地址是：http://blog.shippinggreatness.com

关于用户体验这章，其中有6个自问自答的问题还不错，能够比较好的梳理当前界面的是否符合用户预期。第1个问题是该界面要求用户完成的最重要任务是什么？一个页面最好只有一个任务；这是最简单的解决方案吗？把方案简化到最低；信息组织是否得当？即信息的内容和层次是否清晰；第4个问题，设计是否易用且一目了然，感觉有点啰嗦的问题；5标准是否一致？其实就是统一性问题；最后一个能否减少用户点击次数？这个是大家很容易忽视的问题，产品经理为了确保产品逻辑严谨，可能会有很多让用户确认的地方，保证不让用户出错，其实没必要，也是按照第2个问题能省则省。少点几次，用户不会感觉到失去什么，只会觉得更流畅。

剩下的内容我就没有细看了。有一段是关于开会的，包括会议的类型，开会的时间，会后立刻发布会议纪要等，比较合理，知道后尝试去做就好。

所以，以后的教训是，不要被书名给骗了。

产品交付之道

paul 2014-12-16 1

这本书读起来轻松，收获也不能算多。吸引我来读的当然是谷歌和亚马逊这两个大名头，本书中有不少作者的经验，但感觉缺少点系统性，语言上有时轻浮过，我想在表达时怎么把握这个度是要考虑的。
这本书实际上讨论了一个产品从产品立项、产品定义、用户体验、开发、测试、度量、发布的全流程和方方面面。
适合于遇到问题，来这里找找答案，说不定作者的一些做法和观点能给你参考，但如果指望照着作者的描述系统进行一个产品的开发交付，估计是不够的。

部分摘录：
        * 有效的交付过程7阶段：确定正确的产品方向、清晰详细的定义产品、设计用户体验、做基础性的项目管理工作、测试、建立衡量产品成败的指标、正式发布产品。
        * “以客户为导向，而不是以竞争为导向”，专注于解决真正的客户问题。
        * 卓越的使命需要符合三点要求：能够唤起人们的兴趣，提供言之有物且能指明方向的原则，适合印在T恤上。
        * 最简单的项目管理方法：
        *
                * 创建一张简单的计划表并持续维护。
                * 跟踪Bug，观察燃尽图，计算实现零Bug率的日期。
                * 谨慎管理你的依赖。

        * 优秀的量化指标：测量成本低，测量可靠且可重复检验，能频繁测量（最好实时），团队能根据它做出明智改变，专注于客户。例子：超市某产品的过期数量，理想值是1，超过1就降低存货水平，如果为0，就提升存货水平。
        * 因为不可能完成团队需要你做的所有事，所以需要优先做最应该做的事情，且不要在意没有做完所有事情。首先应该做那些只有你能做的事情。
        * “能安全走出机舱的着陆就是最好的着陆”，能交付的软件就是最好的软件。

书刚看完。。

1417135456 2014-05-28 0

书到手，刚看完

用来放办公桌边上装个样子还不错

最想看的案例不多

变个法儿把理论重复了一遍而已，实用工具也不多，

有点小失望

啊，长点，评论能有多长啊，你以为写文档呢

能产生共鸣的好书

凤栖梧别居 2014-05-28 0

　大概做产品的人都喜欢简练，所以这本书仍用简练的语言把做产品的精髓做了很好的诠释。

案例、工具、重点，都很清晰。除此之外的语言，虽然都是铺垫，但是只有实打实经历过的人才能写得出来，因此看的过程中很有共鸣！

对于新手而言，这本书可以很好地帮你入门。
对于老手而言，更多是在这里寻找共鸣以及对当前工作的槽点^^

哈！推荐！

理论都是这一套，换个背景描述了一遍

耗子吴 2014-08-24 0

第一部分作者从战略、产品定义、用户体验、项目管理、测试、量化评估、发布等方面介绍了如何交付卓越产品；第二部分介绍了 PM 所需技能。

纵观大部分关于产品的书，内容结构上大抵都如此，所要遵循的原则，定义也都大同小异，主要的差异体现在因为作者的不同，经历的背景不同，所描述的案例和场景有所不同，但表达的思想都是大抵一致的，这类书看过之后算是了解了关于 PM 的理论，最最重要的还是将这些理论应用到实践，因为很多东西，听起来简单，但真正放在项目中很可能就不是预期的效果。

PM 最重要的是要形成一套自己的理论和实践体系，这样无论做什么项目、在什么团队都会游刃有余，如果水平还不够，那么就多看别人的，在实践中慢慢积累和总结。

帽子扣得比较大，流水账

二四字节 2014-11-30 0

可能适合大公司的产品人员看？

小公司、创业公司的产品，包括CEO，是绝逼没有这么多时间和精力去拉这么长的产品策划和需求准备周期的。流水账般的方法可以在需要的时候翻出来参考下，但绝不是一本有太多启发的书。

“新闻稿”部分倒是感觉不错，也是自己之前做得不够好的地方。在自己的身份下，总是觉得开发团队不够努力去理解需求，去揣摩需求。但其实，产品如果能更加作为一个发言人身份去用简单易懂的新闻稿帮助所有相关方了解需求和鼓劲，或许是前期激发开发团队兴趣的一个好办法。

写得不错

小兵 2015-01-30 0

谷歌和亚马逊如何做产品从实战中的反思，值得学习

请问书中的所提到的电子表格副本在哪可以下载到？

http://www.shippinggreatness.com/ 打开后是空页面，谢谢！

了解一下先进企业的产品方式

徐毅 2016-09-19 0

第一部分交付卓越产品，步步为“赢”

其实有一套更为有效的交付过程，它分成7个阶段，任何团队主管都可按图索骥，收获成功与快乐。
阶段一，确定正确的产品方向。
阶段二，尽可能清晰详细地定义产品。
阶段三，设计用户体验。
阶段四，做一些基础的项目管理工作，不要太多也不要太少。
阶段五，开始测试。
阶段六，你差不多可以准备发布了，不过在发布之前要清楚知道怎样才算成功，这就要求你建立一套衡量产品成败的指标。
最后，正式发布产品。

第1章赢在使命和策略

1.1　如何找到正确的需求

从拉里和杰夫身上，我们学到必须专注于解决真正的客户问题。

如果说拉里和杰夫告诉你必须解决真正的客户问题，布林会告诉你这还不够，你得确保这是个很多客户都存在的大众问题。

1.2　如何构建卓越的使命

卓越的使命需要完全符合以下三点要求
1. 能够唤起人们的兴趣
2. 提供言之有物且能指明方向的原则
3. 适合印在T恤上

最后一个衷告：你需要的是一个能够反映代表性产品或服务的使命，而不是一个面面俱到的使命。

1.3　如何制订正确的策略

策略是指在竞争对手的压力下，利用公司独特的优势来争取目标用户的粗略计划。

当你开始思考公司、客户和竞争这三大问题时，需特别注意如何才能长期为客户提供比竞争对手更优质的产品。

既然现在你已经知道了谁是产品的忠实拥趸以及产品如何保持长期的竞争优势，那么请用最多三段文字写下来，然后再将这些想法的本质浓缩成一段文字。越简短的策略越容易实现，也越容易获得他人的认同。

第2章赢在产品定义

这时需要借助文字来告诉你的团队你要做什么事情以及目标是什么。

当设法细化产品方案时，你会发现产品要解决的一些客户问题都是你主观臆断的，而且因为你的使命和策略都是建立在客户问题上的，因此这些主观臆断也混入了其中。

所以要采用一些方法来证明臆断是否正确。即便它们十有八九是正确的，也要经过证明，而证明的最好方法就是把产品提供给客户使用，然后听听他们的意见。

不管最小化可行产品是大是小，你都可以参照下面的产品定义过程来定义产品。通过快速重复这个过程，你可以验证不同的客户问题，并添加更多更好的产品特性。当迭代越小越快时，你甚至不需要花大力气去猜测客户的需求，而是更多按照客户告诉你的去做，这样成功的可能性更大。

产品定义过程主要分为10步。每一步都建立在上一步完成的基础上。
1. 撰写新闻稿。新闻稿是一篇脱胎于策略的文章，篇幅不超过1页，主要用于促进各方了解和公开透明。
2. 创建并不断更新FAQ文档。这份“活跃”的FAQ主要用于记录一些争议点和重要细节。
3. 绘制线框图或流程图。线框图和流程图是产品的可视化描述，在讨论或答疑中使用可以让观点更明晰。
4. 撰写产品单页或10分钟的演示文稿。产品单页是一篇写给高管或多数风险投资人看的产品介绍文章，你需要把控好介绍的详略程度。
5. 在FAQ中添加API文档。API是产品的第一个技术触角，在第6步会把它们全部整合到需求文档中。你可以先花数小时简单起草一些API，后续再在工程团队的帮助下完善它们。
6. 撰写功能规格文档。功能规格文档又名产品需求文档（Product Requirements Document，PRD，谷歌常用此名），或市场需求文档（Marketing Requirements Document，MRD，微软常用此名）。它是阐述产品各功能详情以及为什么要有这些功能的最权威的文档。产品的规模以及成熟度决定了你需要几天还是几周才能写完功能规格文档。
7. 邀请设计团队和工程团队主管参与产品评审。这一步是为了获得项目组对产品的认可，并让他们帮忙寻找产品中存在的各种极端及边缘情况。
8. 找客户测试产品概念。在此阶段，你需要了解产品方案是否真正能解决客户问题。
9. 命名、定价以及预测收益。你可以晚些时候再想这些事情，只要对产品有足够的信心。
10. 向管理层汇报。

2.1　第1步：撰写新闻稿

所谓新闻稿是指一篇向市场宣布将要推出新产品的通告。不管是新闻稿还是博客文章，都应该简单明了地传达关于产品的关键信息。

好的新闻稿包含以下六大要素：
- 产品命名
- 发布时间
- 目标客户
- 解决了什么问题
- 如何解决（务必简明扼要）
- CEO的公开赞辞

2.2　第2步：创建并不断更新FAQ文档

创建并维护FAQ文档有两大好处。第一，它能节省你大量回复邮件的时间，还能抵御一些内部责难。第二，当你的客户支持团队和科技写作团队开始整理所有面向公众的内容时，FAQ将是一个很有价值的资源。

2.3　第3步：绘制线框图和流程图

流程图可以帮助你准确地解释用户工作流和系统交互相关问题，简要线框图则可以帮助你具象化产品各环节的用户体验，并在之后的汇报中发挥不可思议的作用。除此之外，在白板或空白纸上画草图并用手机拍照也是一个沟通想法的好办法。

2.4　第4步：撰写产品单页和制作10分钟的演示文稿

这两份文档所需包含的五个要素：
- 产品名称
- 目标客户+数量有多少
- 解决了什么问题+这个问题对于目标客户来说有多大价值
- 解决方案+这个解决方案类似线上哪个产品，为什么你的方案能让竞争对手在长时间内都无法模仿
- 何时交付+主要的里程碑有哪些？
- 团队背景（仅针对VC）

最后再提一个关于10分钟产品演示的建议：你的听众无论来自公司内部还是公司外部，无论关心技术还是关心商业，他们大部分人对你的行业都有充分的认识和独到的见解，但并不了解你要做的事情的前因后果。因此你演示的最佳方式是先讲用户现状，再延展开来（参考先前的五大要素），迅速把要点讲完后再留出时间供这些聪明的听众就他们关心的点刨根问底。

2.5　第5步：在FAQ中增加API文档

API文档可以说明你的团队如何与其他团队协作、外部开发者如何使用这套系统以及你需要存储什么数据。预先定义清楚API还有个好处，它可以帮助你搭建由这些API构成的面向服务的体系架构

不只如此，API最重要的作用是明确系统的各个边界，而明确的边界有助于人们了解各类功能或输出分归哪方负责。这样在项目初期各方就建立了理解和术语上的一致性，为后续高效沟通产品需求打下了坚实基础。

2.6　第6步：撰写功能规格文档

虽然各家命名不同，但对于它功用的看法却是一致的：它是用来详细描述用户应该如何体验产品的文档。它不包含系统在后台如何运行之类的技术细节，这类细节应该包含在工程主管撰写的技术规格或设计文档中。

功能规格文档的读者一般为你的工程团队、设计团队，偶尔还有市场营销团队。功能规格文档包含以下九个内容块，按照先整体后细节的顺序排列，我将逐一详细介绍：
1. 简介（使命和策略）：这块内容与产品单页相同。
2. 目标与非目标：简介中虽已大致描述了产品的方向，但你需要将其细化成不同目标，每个目标都应保持清晰简洁并将它们按优先级排列，这样工程团队就可以合理地进行设计与开发了。如果说目标是告诉别人你要做什么，那么非目标则是告诉别人你不要做什么。
3. 用例或用户场景：有些人把用例和用户场景分开单列。用例是指用简要的语句来描述那些用户必须执行的操作，用户场景则是指用叙述故事的方式来描述用户是如何体验产品的。用例（或者用户故事）这个敏捷模型强调的是用户类型与用户行为，在实际工作中非常有用。当用户行为趋向复杂时则更适合使用用户场景。无论是只写用例还是只写用户场景甚至两者都写，你都需要敲定它们的优先级。衡量功能或Bug的重要性与紧迫度通常很难，因此建立通用的分级标准并尽早对它们进行分级是非常有益的。
4. 原型图或线框图
5. API
6. 负载规划：负载规划是指对未来一段时间内用户的使用量进行粗略估计并制订应对计划，这对工程团队来说非常重要。他们会根据你预估的使用量来确定哪些地方需要添加缓存，哪种类型的服务器和存储需要准备，哪些授权问题可能产生，等等。总之，关于负载规划你要做的就是进行合理的预估，你的工程主管则负责根据预估值来构建一个能稳定运行的系统。
7. 依赖：你需要将全部依赖方及其负责人列出来，如果有应急方案也一并列出来。功能规格定稿后你也应该发给各依赖方的负责人，让他们知道你需要他们的支持。依赖不需要描述得太详细，你只需简单说明我们需要这个依赖的原因以及依赖会受到什么影响，比如流量或者异常情况。
8. FAQ和开放问题
9. 关键事件

2.7　第7步：找出边界情况并得到团队认可

接下来你需要和团队一起细究文档以找到所有的问题。

你的团队将开始寻找边界情况或者极端情况，即极少出现的产品行为或场景。

除了确保处理好边界情况，你还需要确保工程和用户体验团队认可你的产品规划。

第7步充满风险。一方面你必须承认并整合所有你的团队找到的边界情况，另一方面还必须捍卫产品的核心原则。

2.8　第8步：客户测试

我在这里主张的“客户测试”并不是让你马上把软件开发出来然后扔给客户挑刺，我主张的是去找一批现存的或潜在的客户，向他们介绍你的产品设想和原型，并听听他们的反馈。
这个测试可以避免你做出一个没人想用的产品或者遗漏一些核心功能。

2.9　第9步：想清楚基本的商业要素——命名、定价和收益

先谈产品命名。你需要一个客户喜欢的、能注册商标并通过版权审查的名称，后者可以让律师把关。

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

既然收益模型就是一个拍脑袋出来的东西，为什么我们仍然需要构建它呢？
第一，不管是VC还是业务主管，你需要让他们感知到你规划的是一个多么重要的业务。
第二，构建收益模型能使产品设想具象化并证明产品机会有多大。
第三，一个简洁的模型支持你任意调整变量并反复进行预测。

你可以清晰地发现该模型对假设是高度敏感的，这不是它的问题而是它的优点，因为它揭示了你的假设以及特定变量的重要性。一套合理的简洁的模型能帮你理清逻辑、明确核心指标、理解商业模式并最终赢得管理层的支持。但你仍需注意不要花过量时间在它上面——真实的用户和真实的数据永远比预测更有效。

2.10　第10步：取得上层的认可

预售是一个非常直接的爬向食物链顶端的过程

2.11　产品已经准备就绪，去构建它吧

但你无法一个人就把产品构建出来，真正的难点已摆在面前：驱动你的团队在现实的重重困境中依然构建出可靠的软件。

第3章赢在用户体验

为了让设计团队发挥出最佳水平，你需要先理解设计，再让设计团队理解你。

3.1　了解各类设计角色：用户体验，用户界面，信息架构，视觉设计，用户体验研究……以及角色模型
- 用户体验（UX，User Experience）关注的是用户如何完成任务以及该如何优化向用户展现信息的方式。
- 用户体验设计师对信息架构（IA，Information Architecture）尤为关注。不同于工程架构，信息架构研究的是信息该如何在用户界面中呈现，而不关心底层的数据结构。你通常可以提这样的问题来思考信息架构：“页面中最重要的信息是什么？”
- 信息架构专注于理解用户怎样才能接收到信息，而不是系统怎么才能正常运作。
- 用户界面（UI，User Interface）是用户体验的旧称，它更关注单个页面或屏幕的设计，是用
户体验的组成部分。
- 视觉设计（VisD，Visual Design）是关于如何通过一种既赏心悦目、夺人眼球又清晰明了的方式来展示内容的一门学问。视觉设计师往往具有较强的平面设计、排版和美术功底。
- 用户体验研究（UXR，User eXperience Research）是用户体验的一个特殊组成部分，它专注于研究用户是如何看待你的产品的。用户体验研究者们擅长通过研究来获得关于产品成败的统计显著性数据，一个出色的用户体验研究者还会出具报告，说明用户体验中哪些部分有效哪些部分无效，这样的指导极富价值。

角色模型（Persona）是一个由雅各布·尼尔森倡导并备受欢迎的方法，这个方法提供给你和你的设计团队、工程团队一个评估设计的框架。你的设计和业务团队将创建一组虚拟角色来代表目标客户，这些角色模型拥有姓名、薪水和目标，你还可以赋予他们任何你知道的目标客户的特征，然后利用这些角色模型来评估设计的效果。

3.2　了解如何评估设计

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

3.2.1　该用户界面要求用户完成的最重要的任务是什么？

“主要角色必须完成的主要任务是什么？该用户界面要求主要角色完成的主要任务又是什么？”

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

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

3.2.2　这是最简单的解决方案吗？

用户完成任务的能力与该任务的复杂程度呈非线性函数关系。换成简单易懂的话来说：你对用户要求得越多，用户完成的能力和意愿就越低，而且低得不是一点点。

前田约翰在他的《简单法则》一书中提出了一个简单化的框架。他把这个框架称做SHE：简化（simplify）、隐藏（hide）和附加（embody）。

3.2.3　信息是否组织得当

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

3.2.4　设计是否易用并且一目了然

当识别出了用户最需要完成的核心任务后，你需要问问自己这些任务是否是可发现且可理解的。可发现性是指用户发现行动点的能力。

解决可发现性问题的方法有很多，以下为三种常用方法，你可以做些尝试。
1. 定位
2. 视觉设计
3. 惯例

如果你对一个特性的可发现性和可用性存有疑问，一个最好的办法便是让真正的用户来测试。

3.2.5　标准是否一致

这里有一些惯例，你可以利用它们来使用户界面更易于理解。
- 所有主要按钮都应尺寸放大且配色一致。
- 一个用户界面中只有一个主要按钮。
- 使用一组按钮来表示“是”或“否”这样的选择。
- 不同优先级的行动点使用不同的样式。例如在Amazon.com上有“立即购买”按钮（主要行动点，我们唯一期待的）和很多较小的“了解更多”链接（次要行动点），其中按钮要比链接明显得多，而且全站都遵循这个惯例，包括“你的账户”页面，这使得亚马逊这套体系运作良好。
- 当一个流程有3或4张页面时，告诉用户目前处于哪一步以及共有多少步。
- 在你的应用程序中使用下划线或者其他配色来强烈区分链接和普通文本。
- 遵守互联网CSS标准（如：鼠标划过链接时指针变为手的形状）。

3.2.6　能否减少用户点击次数

如果你的默认设置符合用户的需求，用户就可以少点击几次，同时也少遇到一些异常结果。另一个可减少点击次数的重要方面是减少用户在键盘和鼠标之间来回切换的次数。

3.3　了解如何与设计师沟通

请听取下方的沟通建议并做些变通，以迎合每一位独一无二的设计师。
1. 以用户的口吻说话
2. 以提问的方式建立共识
3. 反复讲述业务目标，如果有些目标相互冲突，则反复讲述它们之间的相对优先级。帮助设计师了解他必须解决的问题是什么。避免设置主观目标也能帮助你的团队。
4. 用数据说话统计用户点击数、浏览屏幕的数量和页面加载时间可使交流更为具象。应积极开展可用性测试。
5. 提供一些竞争对手或类似体验中运作良好的案例

3.4　学习如何借助图画进行沟通

这些手机拍下的白板图画是非常强大的沟通工具，而且易于制作。
灰度线框图
视觉稿
红线标注版视觉稿
可点击原型

制作线框图时需关注以下基本原则。
- 只制作用户界面中相关部分的原型。
- 总是使用完整的、经过适当编辑的文本。
- 控制花在视觉设计上的时间。
- 使用灰度色，不要使用其他颜色。
- 预期你的线框图会发生很大改动。
- 当心视觉花招。

对于大段的文本你可以使用设计师常用的“这里有一段话”之类的文字填充，但对于任何表单、按钮、对话框或其他有意义的控件你必须使用准确的高质量文案。

文案还是煤矿坑中的金丝雀：如果发现需要写一大段文字来解释某个特性该如何使用，你就应该重新设计这个特性，因为用户可不会读大段的说明。

在制作线框图时，你需要考虑如何搭建才能确保后续能快速修改。

设计师们发明的一些不错的快捷制作简单原型的方法

第一个是使用如只能在Windows中运行的Visio或只能在OS X系统中运行的Omnigraffle那样的流程图绘制程序来绘制线框图，第二个则是使用Fireworks、PhotoShop或者画图工具来绘制较小的、高保真的、基于现有用户界面的改动。

3.4.1　使用Omnigraffle制作简单的线框图

由Konigi出品的非常出色的线框图模板库，这个库中包含你可能会用到的任何元素。你可在这里下载它：http://konigi.com/tools/omnigraffle-wireframe-stencils。

3.4.2　快速制作高保真原型

第4章赢在项目管理

我会在电话面试产品经理时问：“你如何知道产品是否可以按时交付？”

我的问题可以回答得很出彩，只要这个回答包含三项低成本的工作。
1. 创建一张简单的计划表并持续维护。
2. 跟踪Bug，观察燃尽图，计算实现零Bug率（ZBB，Zero Bug Bounce）的日期。
3. 谨慎管理你的依赖。

4.1　创建一张简单的计划表并持续维护

www.shippinggreatness.com
余量是一个“容差系数”，用于容纳那些未曾预见的问题和一般的生产力损失所消耗的时间。
这些分心的事情根本无法预料，所以我发现60%的生产率估值非常合理。
“假定推送时间”
查看电子表格的任务分配区域，你会找到那个剩余开发时间最长的工程师。这个工程师有时会被称为“长杆”或“处在关键路径上”。试着把他或她归属于V1的任务分配给其他不饱和的工程师。

4.2　如何拿到评估量

为了能更轻松地拿到评估量并减少工程团队高昂的评估成本，你可以尝试下面的技巧。
1. 如果你不是工程经理，那么让你的工程经理去要评估量。
2. 表面上接受评估结果
3. 认识到你的权力
4. 只跟踪剩余时间：只跟踪完成任务所需剩余时间是敏捷管理的一个原则，我很喜欢这个原则，因为它着重于项目的实际情况，便于你发现项目何时可以编码完成。
5. 要求不考虑余量的评估
6. 每周一次在团队会议上评估各任务的剩余时间

4.3　跟踪Bug并创建Bug燃尽图

Bug下降的比率，或者说这条曲线的斜率，被称作发现/修复率。

4.4　管理依赖

管理依赖并没有什么秘诀可言。你唯一能做的便是将风险最小化，而最小化这些由依赖引发的风险有一些关键技巧，我称它们为“五个如果”。
1. 如果去除它也可以运转，那就去除它。
2. 如果内部能构建，那就内部构建。
3. 如果必须添加一个依赖，那就趁早添加。
4. 如果必须添加一些依赖，那就依靠它上一个已构建的版本。
5. 如果交付得早，被依赖伤害的可能性就小。

第5章赢在测试

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

5.1　坚持测试驱动开发：“调试过劳死，测试嗨翻天。”

5.2　围绕优秀的测试主管组建测试团队

一个优秀的测试主管会不断培训缺少经验的测试人员并帮助设计优秀的测试自动化架构。
5.2.1　选择一：降低标准雇佣测试人员并聘请管理者去管理他们
5.2.2　选择二：按高标准雇佣外包团队
5.2.3　选择三：按高标准雇佣测试人员，不使用外包团队

5.3　亲自评审测试计划和测试用例

一个测试计划由很多测试用例构成，这些用例是从你的产品需求文档中派生出来的。如果你的产品需求文档写得十分糟糕，你的测试团队就无法测试。测试计划通常是用电子表格创建的，因此你能方便地整理测试用例。

5.4　自动化测试

还记得聘请一个优秀的测试主管是多么艰难吗？应对这项挑战的一个最靠谱的方法是找到一位愿意编写测试自动化程序的测试主管。

5.5　推行内部试用

强制你和你的团队使用自身研发的软件，体会用户的痛，能帮助你们逐步提升紧迫感，理解用户困扰。

总之，你需要想尽办法让内部试用成为你团队文化的一部分，即使别的团队没有这么做。

如果你决心虔诚地推行内部试用，下面列举一些你可遵循的且会对你会有很大帮助的最佳实践。
1. 计划一次内部试用发布：内部试用发布是指将你的软件发布给公司内部同事使用。
2. 使其他试用者能够方便地提交Bug报告：建立邮件列表收集试用Bug是一个很好的监控缺陷数量的方式。
3. 软件发布后应继续进行内部试用：亚马逊和谷歌都维护了一套允许内部试用者看到特定特性的实验性框架。这些框架允许某些软件在生产环境中运行但只能被内部试用者看到。
4. 让进行内部试用成为企业核心价值观

5.6　如何开展找虫总动员

找虫总动员是指发动你的团队或者你的整个公司专门花一定时间，通常是一个小时，来寻找尽可能多的内部试用产品的Bug。

以下四件事情有助于找虫总动员获得成功。
- 设立奖项，提供物质激励。T恤之类的奖品效果很惊人。
- 在项目计划中增加找虫总动员这样一个关键事件。安排好找虫总动员的时间以方便你的整个大团队了解何时可以参与。
- 将找虫总动员排进你的开发和测试日程表中。
- 感谢每一个Bug。铭记这一点：“坏的消息就是好的消息。”每发现一个坏Bug都是好消息。

5.7　准确且有条理地处理Bug

在我看来只需简单的3步就能有条不紊地把Bug处理好。
1. 基于频率、严重性和解决成本对Bug进行分级。
2. 每天与开发主管和测试主管碰一次，评审新增的Bug。
3. 不断施加压力以减少新的阻碍发布的Bug出现。如果不这么做你就永远到达不了零Bug率（零Bug率是指没有任何阻碍发布的Bug再被引入）。如果到达不了零Bug率，你就永远发布不了。

在对一个Bug分级时你需考察以下三个方面。
1. 频率
2. 严重性
3. 修复成本

每天开一个Bug处理碰头会来决定哪些Bug需要修复。
1. 确定通用的Bug评判标准
2. 先处理最严重的Bug
3. 限定会议时长
4. 只围绕频率、严重性和修复成本来讨论
5. 讨论每个Bug的时间不要超过一分钟

5.8　发挥可信测试者的作用

可信测试者是指在保密协议的约束下，在产品发布前使用产品内部试用版的用户。他们比你的团队有着更丰富的多样性，包括更多不一样的电脑，更多不一样的期望，而且他们还不像你们那么懂技术。因此他们的反馈具有更大的价值。

为了让可信测试者们能够帮助我们改善产品，我遵循以下几条最佳实践。
1. 让企业用户签署保密协议并提供正确的联系方式
2. 制作粗略的新手指南文档，其中包括已知问题的列表
3. 创建一个包含整个工程团队的邮件组
4. 让这些用户使用和工程师同样版本的试用产品
5. 调研可信测试者
6. 当产品更新时通知可信测试者们

5.9　思想火花：以新用户的方式来使用整个产品

但产品开箱体验的好坏取决于产品中一些最复杂的部分。

这里有一个小技巧能帮助你准确体验到一个新用户会体验到的东西：抵达特性完成阶段后删掉你所有数据和账号然后从零开始使用软件，抵达编码完成阶段后再这样操作一次。

第6章赢在量化

一个团队的能力怎么样，通常要看他们的量化数据表现怎么样。

6.1　如何采集正确的量化数据且只采集正确的量化数据

一个优秀的量化指标应具备5个关键特点。
1. 测量成本低廉
2. 测量可靠且可重复检验
3. 能频繁地测量，最好能实时测量
4. 团队能够根据它做出明智的改变：每个团队都想把订单量升上去，但亚马逊的产品数量太庞大了，任何团队都无法根据全球订单量的变化来衡量他们造成的影响有多大，但如果你们团队是负责购物车的，你可以测量用户从开始结算到购买成功的转化率，这个数字反映了用户体验和系统性能的好坏，并给了你一个可以瞄准的目标。
5. 专注于客户：我喜欢购买转化率这个指标的另一个原因是，它反映了客户的体验状况。只有贴近客户的指标才富有意义且可被理解。专注于客户的另一个要点是尽可能测量客户体验的末端。比如你开发了一个可供下载的iPhone软件，那么哪个指标更有意义呢，是下载量，还是软件启动量？我认为是软件启动量，下载量只告诉了你营销做得怎么样，软件启动量才会告诉你用户的参与度和增长情况。

6.2　你需要采集的三类量化数据

如果想在未来证明你的业绩，你需要事先准备一根基准线。

确立基本指标并不困难，比如说工程团队的执行能力就是一个基本指标。

执行力可以通过考察产品能否在你要求的日期内发布来衡量。

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

产品发布后你可能需要更换指标，因为你新引入了一个重要的数据源：客户及其行为数据。

三类发布后需要跟踪的关键指标：目标进度、经营绩效和系统性能。
6.2.1　目标进度：目标指标会告诉你目标的完成进度。在谷歌一个重要的目标指标是“7天活跃用户数”。它是指近7天使用产品的独立用户数。如果你确实在做一个预期人们会每天使用的产品，那么比较单天活跃用户数和7天活跃用户数之间的差额也是很有意义的。你还可以跟踪如利润、注册量、下载量或安装量等目标指标。我更喜欢精确增量表达法（Great Delta Convention，第10章有详述）
6.2.2　经营绩效：经营绩效指标会告诉你产品的问题在哪里以及如何提升用户体验。这些指标通常是用比率表示，比如从点击购买按钮到付款成功的转化率。埃里克·莱斯在他的《精益创业》一书中并不推崇那些总是在增长的指标。他称它们为虚荣指标。这也是为什么你要关注转化率、参与度等指标的原因。另一个避免“虚荣”指标的方法是衡量应用中改动带来的影响。最好能让改动前和改动后两个版本横向而不是纵向对比测试
6.2.3　系统性能：系统性能指标能说明你产品的实时健康度。这类指标包括99.9%平均延迟、每秒请求数、并发用户数、每秒下单数以及其他基于时间的指标。你还可以天马行空地从统计过程控制（SPC，Statistical Process Control）的视角来考察你的指标。爱德华兹·戴明是最早推广使用SPC来精确测量一个指标的正常下降范围的人之一。戴明假设你的系统存在一定的波动，伴随着波动存在一个可以接受的系统变化范围。在这个范围内的波动被认为是正常变化或I型误差。系统还会有一些持续一小段时间的不良的尖峰波动，戴明称它为异常变化或II型误差。你可以忽略正常误差或正常波动，即误差或波动落在平均值的正负标准误差区间内。标准误差是指你的数据的平均值的标准偏差。

6.3　专注于目标本身，忽略细枝末节

第7章赢在发布

发布可不只是把文件上传到服务器。这里有几个主要的发布步骤，遵循它们可以确保发布质量。
1. 对改动说不。
2. 开启作战室。
3. 营造紧迫的气氛。
4. 核查发布清单。
5. 撰写博文。
6. 发布软件。
7. 亲自验证软件。
8. 应对发布带来的各种影响。

7.1　对改动说不

在准备发布的过程中你必须尽量频繁地对新的特性、新的Bug以及用户体验上新的改动说不！如果不这样做，你就永远完成不了软件，自然也就永远交付不了。

这里有一个方法可以让你的团队愿意说不，即建立一个“发布后第一时间”（IPL，Immediately Post-Launch）修改的需求清单。

另一个你应该对新冒出来的改动说不的主要原因是，几乎所有对代码的改动——更合适的叫法为代码移动，都会引发新的风险，如引入新的Bug或重新引入老的Bug。

7.2　开启作战室

在这个节点上你应改开每日例会并不再禁止与会者在会上争论一些问题。

每日例会能帮助你高效做出决策并营造一种紧迫的氛围。

试想如果需要沟通的两个人坐在一起，那么他们之间的信息传递时间实际上为零。

7.3　营造紧迫的气氛

我认为凭借冲刺来完成项目没有什么不好。只要这样的冲刺不超过1个月，大多数团队和他们的家人还是可以接受的，特别是你还会补偿给他们一定的休息时间。

不要让你的团队冲刺超过1个月，或者最多2个月。

狗屎三明治

你还需要记住你的任务不是去解决问题，而是创造出一个有利于问题解决的环境。当所有人都被召集到电话会议中后，确保他们说的是同样的语言，并在过程中将你的紧迫感传递给相关方。

7.4　完成发布清单的核查

要想出色地完成发布，你需要拟定一张发布清单。这份清单的目的在于确保软件发布中所有需要跟进的事项都被有序安排且被详细描述。发布清单还能促进团队内部不同职能的交流。

7.5　撰写博文

你可以从产品预告中挑选有用的文字，如果仍然需要使用具体案例则需抛开细节。

博文还是你产品演示的脚本。你可以准备一个一分半钟到三分钟之间的视频放在博文后面，这样那些没有权限或者对试用缺乏耐心的用户仍然能体验到你产品的卓越之处。

7.6　发布软件

发布特性的最佳方法是借助一套实验性框架。它允许新旧两套代码同时在产品服务器上运行，这样无需重启服务器即可在版本1和2之间快速切换。长期来看，投入资源构建一套实验性框架几乎总是值得的。

亚马逊称这样的发布为网页实验室（Weblabs），因为他们会去比较拥有新特性的用户和未拥有新特性的用户之间的差异，进而衡量新特性对用户产生的影响。

然而实施这套实验性的方法还是面临很多挑战。当你的服务需要改动底层数据模型时，你可能没有办法回滚，或者回滚之后会产生一些不相交的数据集。这些问题都很棘手，因此有可能的话你最好让你的数据模型向后兼容，这样可以彻底避免这些问题。

再多的努力也很难让你做到一次性发布成功。因此建立一套机制来确保所有东西在发布前就已衔接完成并配置完好是极具价值的，这样你才不会把问题暴露给上百万的用户。

7.7　亲自验证软件

在将所有服务推送至生产环境后，你需要在2天内完成产品验证。

版本验证测试（BVT，Build Verification Test）

其次，你需要以新用户的身份来亲身体验整个产品，确保产品所有主要功能都可正常使用。

7.8　应对发布带来的各种影响

下面列出五项发布后需要做的事情。
1. 应对回滚。
2. 处理产品危机。
3. 演示产品。
4. 应对媒体。
5. 庆祝发布。

7.8.1　出现问题，回滚软件
这句话值得反复强调：只要成功回滚，发布就还没有失败。
最终你会发现：最好的防守是制定周详的撤退计划。

7.8.2　应对产品危机
危机有时会突然爆发出来，可能是你的网站被瞬间大规模的流量冲垮，也可能是出现安全漏洞、隐私侵害或者定价事故，又可能是一个实习生把本应重定向到数据中心的产品站点重定向到他的个人桌面了（真实故事）。
做事之前，先做准备！
先做准备部分意味着你需要事先安排好人员轮班待命并给他们配备寻呼机。
一个准备充足的产品应该拥有可以快捷关闭服务或限制服务速率的软件开关。切记只要有可能就应该在实验性框架下发布软件，或者软件中带有可禁用特性的标记。
你还可以更早做好应对灾难的准备。在早期软件设计评审会议中，你就可以要求工程团队针对可能的错误设计应对方案。
退避（backoff）时间
确保在交付之前建好退避机制。
你还可以准备得更好一些，比如取得某个服务器专家的联络方式，哪怕你的团队里没有这个角色。如果能维护一套紧急联络簿并牢记于心，并在内部公开那自然更好。
你还可以使用另一种方法来提前建立有效的沟通渠道：创建一个危机扩大邮件组（-escalation@yourcompany.com）以便所有相关人员都能被纳入进来。
如果存在持续的风险（例如一次发布），你需要确保所有相关人员都知道这个风险可能引发的问题。你必须乐于劳烦别人以获得帮助，要知道如果遇上了大危机你是没有时间去遮掩的。
你需要准备的最后一件事情是把下面的内容打印出来，钉在墙上，然后在大麻烦来临之际按照这个剧本行事。

危机应对“剧本”：0～5分钟
不要惊慌。
检查这是否是一起突发事件并评估影响范围。
确定这个问题不止在你这里出现。
你要找到一个确实存在该问题的客户。
不要逃避大问题，出现了就是出现了。不要拼命去欺骗自己说这不是个大问题，没有多少用户受到影响。
发起电话会议。
在主持电话会议的过程中，请不要去掺和讨论解决方案。
打开一个Bug。
你将使用这个Bug来记录对系统做出的改动。
知会危机扩大邮件组成员。

危机应对“剧本”：5～30分钟
问：“我们能回滚吗？”
推迟任何公关计划。
知会相关方。
不要断定危机只对你有影响，确保危机没有危害到其他服务方。
同样地，你也需要确保你没有被其他服务方牵连。
知会社区。
如果你有一个社区论坛或者其他常用的与客户交流的途径，你也许想通过它们让客户知道“目前某某功能看起来出了一点问题，我们正在积极研究如何解决，预计将在某某时间提供更多信息或解决方案”。
然而不要避讳承认产品存在问题，用户会欣赏你的诚实。
保持Bug的更新。
不要把Bug的最新情况藏着掖着，更新出来不会对解决危机有什么负面影响。
寻找并引入专家协助团队解决问题。
知会管理层。

危机处理“剧本”：31分钟及以后
你需要立即进入持久战模式并继续修复问题。此时不存在任何快速而简单的工作清单，相反，这时的工作都需要你日复一日坚持去做，如下。
定期发送状态更新，当有人请求时也可马上发送。
不要把客户晾在一边。控制客户对问题的期望，并保持与他们的沟通。
继续解决问题。
确保满足从事问题解决的人们的需求，提供给他们食物、服务器以及其他团队的支持等。
建立轮班制度，不要让一个开发者持续工作24小时。
采用变通或应急方案。具体来说，就是临时找个方法来替代目前已经瘫痪的系统。

危机处理“剧本”：收尾以及撰写事故调查报告
1. 检查修复情况。你需要再三确认问题是否修复完成了，你需要亲自验证修复情况，就像在发布前亲自验证软件一样。
2. 如果你或者你的公关团队认为有必要对外公布此次危机情况，那么准备一篇博客文章。
3. 在团队路线图中增加任务项并把他们的进展同步给老板或投资人。
4. 撰写事故调查报告。事故调查报告是发给你的管理层的一份基于数据的检讨。

下面列举你老板可能会问的问题。
发生了什么事？
谁受到了影响？
问题是何时出现，又何时终结了？
为什么会发生这个事情？
如何防止这类问题再次发生？
事故调查报告也被称为“故障原因”（COE，Cause Of Error）报告

7.8.3　演示产品
演示的目的在于用讲故事的方式来讲述产品，并在每一步凸显产品使命。
演示也需要遵循既定的策略。先从问题和使命讲起。
在演示开始时一定要让用户明白他为什么应该关心这个产品。
接下来以讲故事的方式把演示串起来。好的演讲总是利用一些故事来吸引听众并让他们产生代入感
不过固然你可以跳过这些小缺陷，但对付它们最好的方法是不让它们出现。所以那些做得最好的演示需要花费数周时间进行准备。
尽管给你列举了很多前车之鉴，但如果你要做一场全程直播的产品演示，那么再多的准备都不为过。你必须为每一段产品演示都准备截图或者视频，因为你永远预测不出所有可能出错的情况。

7.8.4　应对媒体和客户
那些博主喜欢别人也把他们当做媒体），尽可能让他们对你的业务产生深刻印象。
你在产品发布后最值得马上去做的事情之一，就是处理用户的请求，与用户在在线群组中交流。

7.8.5　庆祝发布
每一个令人瞩目的产品发布都离不开团队成员做出的点滴牺牲（有些时候还是巨大的牺牲），因此感谢你的团队为之付出的心血是非常重要的。不要吝惜任何赞美之词，它会让你的团队欢欣鼓舞。
你最好等你的团队度过手忙脚乱的局面后，再庆祝发布以及感谢他们做出的努力。
嘉奖先进个人也很重要，但公开嘉奖具体的某些人既有好处也有风险。这样做之前你需要想清楚有什么好的理由支持你公开嘉奖。我有时候这样做是因为我认为任何事情都是教学的机会，公开嘉奖这些杰出个人，可以让团队明白做到什么程度才算杰出，这样他们就有了明确的前进目标。
不过公开嘉奖一定要谨慎。
不要因为你的考虑不周而令团队成员蒙羞。

第8章胜在团队

一个杰出的团队最终将成为你的长期竞争优势。

8.1　如何组建一支团队

为了组建一支高效的团队，你必须找到能默契配合的工程主管、产品主管和设计主管。
《爱他们，还是失去他们？》
你需要雇佣一名工程经理、一名产品经理、一名项目集经理、一名项目经理或者集四种职能为一体的人。为简洁起见，本书中把这类人叫做PM。

8.1.1　项目集经理
项目集经理的职责重点在于整合不同团队和不同工作职能。
另一种看待项目集经理的方式是把它看做是一个比产品经理更少关注业务、比项目经理更少关注项目的技术角色。

8.1.2　产品经理
通常产品经理的职责更偏重软件的业务方面。甚至有些产品经理不负责软件，他们是典型的MBA出身，专注于品牌管理、定价、市场进入策略等。你的软件的产品经理将负责所有这些工作，还需要努力从用户的角度出发来帮助确定特性开发的优先级。

8.1.3　项目经理
项目经理的主要职责在于排定项目计划和协调团队工作，在谷歌这个职位也被称作技术项目经理。他们负责向工程师要评估值，辨识从属关系以及弄清楚如何在更短的时间内做更多事。
（http://en.wikipedia.org/wiki/MacArthur_Maze）

8.1.4　工程经理
工程经理常常是由老牌的程序员担任的。最佳的工程经理是那些由于热爱团队、善解人意、精通交付并乐于构建卓越产品而晋升到该职位的人。
产品经理、项目集经理或者项目经理，甚至是技术项目经理都可以是工程经理的属下，但也可以是合作伙伴。
每个工程团队都需要工程经理，但不是每个团队都需要产品经理、项目集经理或者项目经理。

8.1.5　如何雇佣产品经理、项目集经理或者工程经理
下面有5个主要的雇佣主管的原则。
雇佣比你聪明的人。
雇佣懂得自己不是来当老板的人。
雇佣表达清晰、言之有物的人。
雇佣用数据说话的人。
雇佣充满活力的人。

1. 雇佣比你聪明的人：如果你乐于放权并相信他们能够胜任队伍领导者的工作，你就必须且只能雇佣比你聪明的人。最佳的检验纯粹智慧的方式是背景调查。在名牌学校拥有很高的平均绩点是额外加分项之一，它预示着候选人能够胜任该角色。实际推出过很多产品是关键的加分项，说到底，如果想要交付出卓越的产品，有过交付经验还是非常重要的。
2. 寻找那些懂得自己不是来当老板的候选人判断PM是否懂得这一点的唯一方法是与他当面接触。我在面对面的面试时会抛出一个从麦肯锡公司那里借来的问题：“讲一个你是如何改变某些人想法的经历吧，以及你使用的技巧。”我等着听候选人是如何应对这种不在掌控的情况的。我会注意其中是否有合作决策（见第11章），是否有基于数据的争论（见第6章）和聪明的向上反馈（见第11章）。
3. 寻找那些表达清晰、言之有物的人
4. 雇佣习惯用数据说话的候选人一个好的技术主管应该具备独立计算的能力。
5. 雇佣充满活力的人主管常常是团队背后的驱动力，如果他们不能给团队带来活力，你的目标就会落空。要在面试中判断候选人是否充满活力，一个可能观察到的迹象是他是否有奇思妙想，我还会看在围绕问题解决过程中他是否有兴奋感。

8.2　如何收购一家公司
通常考虑收购一家公司会出于四个目的。
1，知识产权：你能使用这家公司构建的技术、内容和专利。
2，人才：你能使用这家公司雇佣的人才。
3，客户：你能凭借这家公司的客户来加快业务增长。
4，防御：你买这家公司是为了让别人没法买它。

8.2.2　人才收购
面试还会帮助你了解雇员适合的岗位。我将这些人才分成三大类。
1，关键人才：他们是那些闪闪发光的人，缺了他们，你就得马上找人替代。但他们的专业功底深厚，你都很难找到类似的人来填补他们遗留的空缺。
2，好的雇员：他们是一群你乐于招进来做当前业务的人。他们是一流的候选人，但这种人你自己花个把月也能找得到。
3，多余人才：他们是一群达不到雇佣要求的员工，你需要二选一：和他们续约一段时间以使你能平稳将他们开掉，或者立即终止与他们的雇佣关系。这看起来是个艰难的过渡，但收购的现实就是这样。

8.2.3　客户群收购
确保你正在使用的是正确的数据基线。

8.2.4　防御性收购

8.2.5　收购的陷阱和最佳实践
最后这里还有一些建议和警告，你在考虑收购一家公司时需铭记在心。
1. 计划将你团队的部分人员调入他们团队：不要低估文化适应的重要性，也不要低估新人适应领导风格所需要的时间。
2. 计划整合产品：你不仅需要知道如何将他们的服务器架设在于你的虚拟IP之下，还需要知道如何处理他们的品牌以及如何将双方的计费系统打通。
3. 了解之前所有的交易和负债：在确定收购金额之前，通过会谈了解清楚该公司的欠款、负债以及任何签署过的交易是非常重要的。

8.3　如何与远程团队合作

这很有挑战性，但你可以做一些事情来使生活更轻松一点。事实上有9件事情：
1. 组建一支工程师团队
2. 充分沟通
3. 不要外包设计或PM角色
4. 适应文化差异
5. 构建清晰的需求
6. 忍受时差，通过任何方式会面
7. 委任得力的主管。
8. 大量出差，或者完全不出差
9. 与远程团队共饮

8.3.1　不要租用工程师——组建一支工程师团队
利用由协作产生的动力的最佳方法是组建一支包含至少3名工程师的拥有共同纲领的团队。
共同纲领能给予团队方向感，它还帮助团队独立进行决策，当缺乏时间照管他们的时候你会需要它的。
为团队定义清晰的共同纲领还能帮助他们减少对未来的焦虑。

8.3.2　充分沟通
我注意到在与远程团队合作时有一个常识性的真理：离你越远的团队越焦虑。
为了减轻这种感觉，你能做的最有效的事情是充分地、反复地沟通。
使用Skype、Google+Hangouts、WebEx以及你手边能用的任何工具来提升与远程团队的沟通质量。

8.3.3　尽量不要外包设计和PM角色

8.3.4　重视文化差异
你不需要理解每种文化的独特之处，但需要认识到美国东海岸团队的规矩和西海岸是不同的，西海岸和英国也是不同的。你必须积极了解那些可能有差异的地方，然后想办法去平衡。你能通过在大量的沟通中寻找反应模式来着手了解这些差异。

8.3.5　构建清晰的需求
新团队不管位于何处，都会有些相似点。其中一个相似点是他们真的不知道该干些什么或者为什么该干这个。

8.3.6　忍受时差
我只想出了两个办法来应对时差。
使用数字录像机。
大早上起来工作，或者大晚上工作。无论你更适应哪个，请将你的会议总是安排在一天的开始或结束。

8.3.7　委任得力的主管
让得力的技术主管加入到新团队非常有利于文化和流程的移植，这也是我在团队收购中推荐这种做法的原因。

8.3.8　大量出差，或者完全不出差

8.3.9　与远程团队共饮
这个故事告诉我们，除了尊重文化差异外，你还应该认识到人们在不同的环境会讲不同的真话。酒吧和饭店就是两个能讲真话的地方（我认为是最好的两个地方），它们都是靠酒精来刺激的。

8.4　如何加入到一个新团队
无论你是组建了一支新团队，还是从高层空降到火车失事现场来解决问题，都需要做两件重要的事情：弄清楚你应该扮演的角色，以及下好第一步棋。

你需要立刻做两件重要的事情。
第一件事，不要和团队说你们的产品一团糟这种话。后来我才认识到在大多数情况下你都应该尽量先将事情本身搞清楚，而不是张口就说产品一团糟这种话。
发现问题后你必须做的第二件事情是做一个选择：你是打算延期交付以解决这种混乱状况，还是承认它的存在然后正常交付。

根据我的经验，你将加入的团队可能有五种主要的类型。每种类型都有最佳的应对方式。表8-1展示了如何根据他们说的话来识别团队类型并正确回应。
表8-1　团队类型和回应方式

第9章胜在技术

如果你想顺利地通过面试或者从容地掌控产品开发过程，你需要了解四个S：服务器（server）、服务（service）、速度（speed）和扩容（scaling）。

9.1　第一个S：服务器

尽量不要买服务器。首先，优秀的工程师会尝试学习如何避免去做运维的琐事。如果你因为某些特殊的原因而必须拥有自己的系统，那么不妨向提供商租赁它们。数据层一般是一个数据库，客户记录等数据都放在里面。业务逻辑是运营的大脑。所有复杂的运算都发生在这层。展现层通常是HTML和JavaScript。

9.2　第二个S：服务
SOA将包含业务逻辑的中间层分解成一系列独立的服务。这些服务可能运行在相同的服务器上，但它们的构建、版本管理和运行都是独立的。这些API都需要写进产品需求文档中。关于什么系统应该放在什么服务的边界并不特别重要。对于你的系统来说真正重要的东西是快速和可扩容。如果你想要一个快速的系统，请尽可能避免服务链。所以尽量不要使用服务链，多去寻找能替代它的方案。

SOA的缺陷
尽管SOA有这样的缺陷，史蒂夫和我依然相信，如果你想追求可扩容性（或称可伸缩性）、可扩展性（或称可升级性）以及其他优秀的特性，面向服务是一个值得遵循的好方法。

9.3　第三个S：速度
为了应对这些复杂性管理带来的挑战，一个可行的工作方法是分开加载应用程序的各个独立模块。
文件和服务的独立性将帮助你快速扩容和修改你的服务。这种方法和JavaScript一次性加载所有东西的区别在于封装（Encapsulation）。
缓存（Caching）是另一种解决服务链速度问题的方法。
一个缓存了所有数据的系统被称为“完整缓存”（cache complete）
当你的服务需要的数据不在缓存中时，称为“缓存缺失”
聪明的缓存策略不只会通读后备存储器，它还会将读取到的数据缓存起来。
如果你能建立用户和缓存的黏性，你就能实现通写缓存，让数据先写入缓存，再写入后备存储器。缓存要么通过通读来填满，要么通过“预热”来填满。

9.4　第四个S：扩容

虚拟IP（VIP）：VIP允许使用单个互联网地址来表示拥有的所有服务器。

你接下来一定会听到系统能“线性”或“纵向”扩容之类的词。真正的极客可能会说“常数时间”或“N”。

这时面向服务的架构的一个好处是你可以独立为每个服务扩容

要想这种支持扩容的设计正常工作，你必须将数据存储起来以便它能快捷延伸至新增的服务器。

这虽然不好，但它能够快速返回给你结果并最终完成数据的传送。我们把这个叫做最终一致性。

你还可以通过创建索引来解决某些类型的性能瓶颈。

9.5　如何询问正确的技术问题
以下是一些可以询问的问题。
1. 能请你给我画张系统图吗？你的目的是理解系统图中所有方框都是干什么的。
2. 结果从这个方框传到那个方框的延迟是多少？你应该能通过通览系统图来识别出服务链，询问这类设计的必要性，并弄清楚整体响应时间是多少和最坏的情况下是多少。
3. 可以扩容到N吗？想想当你使这个数字变得无比巨大时会发生什么。
4. 去掉B方框有什么影响？了解你的系统包括了解它会如何出错并如何恢复（希望它能恢复）。
5. 我们是围绕组织边界或系统边界来架构吗？有时你会发现SOA反映的是公司的运营方式，而不是数据或应用程序的结构方式。当出现一些团队难以协作而导致多余的或不正常的系统被构建出来时，检查上面这一点并主动应对。

6. 能通过缓存什么数据来提升性能吗？识别静态数据和常规查询并讨论如何缓存它们。不要忘记询问关于缓存完整性的问题。
7. 能通过独立加载什么数据来提升性能吗？你也应该询问系统的某些部分是否可以分离。

第10章胜在沟通

其中一个关键的技巧是尽可能少开会，但不要不开会。很多时候通过一封优质的邮件就能完全避免开会。

10.1　如何写好邮件
爱因斯坦曾说：“如果不能将事物简单地表达出来，你就没有真正地理解它。”
作为一位出色的领导者，如果想让上司更认可你并获得更高的薪水，你需要不断向团队传递清晰的、具体的信息，使他们明确方向、坚守使命。你还必须做好向上管理，这意味着你要向比你更忙的、有更多邮件需要处理的人们传达与决策或进展相关的大小事项。因此写好邮件对你能否成功至关重要。写邮件最主要的目标应该是清晰、简要地传递单个信息。

10.1.1　像记者写新闻一样写邮件
优秀的记者会将他们想表达的最重要的事情放在文章开头。
在拙劣的发件人写就的邮件中，撰写人“主次不分”，
优秀的发件人则没有犯这种错误，他还多用了20秒时间来为邮件加上称呼、敬语和署名，这样可以帮助信息传递给正确的受众（特别是邮件还抄送给一些人的时候），还可以帮助减少潜在的恶意。
优秀的发件人还有个最为出色的地方在于使用了精确增量表达法。

10.1.2　使用精确增量表达法
精确增量表达法是一种让数字更易被理解的技巧，适合应对那些超快速阅读的人们。

10.1.3　分点阐释原因
优秀的发件人将他的逻辑依据从视觉上划分成多个点进行阐释，从而人们能够轻松发现要点。
在优秀的发件人写就的邮件中，各点之间的行间距是很有意义的。适当留白能帮助你清晰分隔出邮件中重要或特殊的部分。

10.1.4　立即停笔，你已经写完了这封邮件

10.1.5　设法用建议取代质疑

问“为什么工作量都还没估完就确定了发布日期”是一种带有倾向性或引导性的质疑。建议会比质疑更容易被接受。建议能让他人挑挑刺，而质疑是直接冲着他人的，会加剧他人的抵触情绪。不妨试下这种建议式问法。

10.1.6　考虑受众的感受
如果你不根据受众适当调整邮件风格，上到副总裁，下到个体贡献者，你都免不了要得罪。

10.2　如何应对五种类型的会议
如果邮件不管用，那可能是到了要开会的时候。开会可能会痛苦，也可能会高效甚至快乐（是的，你能让开会变得快乐）。让开会变得快乐的最佳途径是理解每种会议的结构、目的和效果。下面有五种你需要掌握的会议类型，排名不分先后。
1. 团队会议：这类会议用来了解近况以及利用团队合力来深入讨论和解决特定问题。
2. 站会：站会是一种超级简短的会议，它只用来交流近况，促使团队内部信息透明、责任到位。
3. 1对1：1对1会议是指只有你和另外一个人之间的会议。
4. 产品/工程/用户体验评审：这是一种大规模会议，通常会有一些大老板参加。这个会议既要向高管通报产品进展，又要收集组织内最富有经验的人们的反馈建议。
5. 头脑风暴会：这是所有会议中最有趣的，它形式自由，能激发想法，还能让团队主动参与到问题的解决中去。

10.2.1　团队会议

团队会议每周开一次，每次30~60分钟，你和你的工程团队需要参加，一般由你主持。这类会议的目的是促使团队坚守使命并就当前一些悬而未决的问题达成共识。议事日程需要提前发布。当你开始团队会议的时候，一个不错的开场方法是先回顾你的数据指标。你还可以利用团队会议来达到更高层次的目的。在季度开始，我会重新审视团队季度目标，并调整目标直到所有人都认同。在季度中间，团队会议可以确保你不会在方向盘上睡觉以至于团队状态“哗”地从绿到红，或许至少可以让团队状态先从绿到黄，再从黄到红。在季度结束，我们会在团队会议上评估我们相对于目标的进展情况。当项目计划表更新完毕，即会议的信息更新部分结束后，你或许需要聊下所有需要团队成员知晓的最新进展，这些重要进展包括行业变化、业务近况和其他与使命相关的事项。切记，确保团队坚守使命是你的工作。会议的最后部分专用于讨论并解决那些悬而未决的问题。处理完这些问题后，问下团队是否还有其他的东西需要讨论。

10.2.2　站会
我喜欢每天开一次站会，因为这能促使团队内部责任到位、信息透明。每个人在站会中应该汇报下列信息：
我昨天做了什么
我今天要做什么
我是否遇到阻碍

10.2.3　1对1会议
1对1会议非常适合主管们相约在一起坦率地进行交流并公开问题。它小而专注的特点也使得它很适合用来完成需要合作的工作。请安排每周或每两周与所有主管开一轮1对1的会议，即便你觉得没有必要。

10.2.4　产品、用户体验和工程设计评审会
任何种类的“评审会”通常都是有大老板参加的大规模会议。其中产品评审会的首要目标是让老板们认可你的产品方向，提供给你反馈，或让他们知道你的最新进展。你要先想清楚你要传递的确切信息是什么，然后尽可能清晰、简洁地传递出去。用户体验评审会则只需要准备产品原型图就可以了。最好让设计师演示他们自己制作的原型。工程评审会的目标是：赋予开发主管权力，收集周围经验最丰富的工程师的专业反馈，以及尽量少花时间在演示上。

10.2.5　头脑风暴会
它的目标是收集尽可能多的想法，不管是新的产品名称，扩容问题的解决方案，还是系统错误的可能的根本原因，它都收集。我会在头脑风暴会上遵循4个基本规则，我确信它们能为会议带来更多创造性的效果。这些规则是：
λ 不要在头脑风暴过程中批评他人的想法
λ 说“是的，嗯……”
λ 通过结构化来促进讨论
λ 在头脑风暴结束时明确告知大家头脑风暴结束了

1. 不要在头脑风暴过程中批评他人的想法
还有一个有助于避免批评并鼓励人们贡献想法的方法，是将所有想法都写在白板上。大幅的画画在专用画纸上也可以，会议结束后你还可以带走它们。
2. 说“是的，嗯……”
即兴表演中有一个演员们制定（也可能是在面对大量嘘声中逐渐形成的）的用于避免情节停顿的规则。它叫“是的，嗯……”规则
3. 通过结构化来促进讨论
结构化地讨论更有条理并能鼓励创造性。
4. 在头脑风暴结束时明确告知大家头脑风暴结束了

10.3　如何组织好会议

如第11章关于如何处理冲突的最佳实践就适用于处理会议中的冲突。除去这个，我还遵循四个最佳实践：
1. 会后立即发出主题纪要
2. 允许改变开会的目的
3. 拒绝在团队会议中发泄负面情绪，但允许在1对1会议中发泄
4. 使用鱼骨图等辅助工具解决问题

10.3.1　会后立即发出主题纪要
你之所以需要在会后立即发出会议纪要，是因为只有这样它的作用才能最大化，你的团队才能感觉到他们是会议的参与者和下一步计划的执行者。在纪要中先放结论和下一步计划，再放讨论的详情，这样那些不认同结论的阅读者也能了解你们得出它们的原因。请写一段清爽的，2~5行的概要放在纪要顶部，人们会感谢你的。

10.3.2　允许改变开会的目的
开会有三大目的：解决问题、收集信息、传递信息。开会目的是可以改变的，你千万要记住这点。

10.3.3　拒绝在团队会议中发泄负面情绪，但允许在1对1会议中发泄

10.3.4　使用鱼骨图等工具来解决问题

10.4　如何做好演示

下面是总结出来的技巧：
λ 将演示时间控制在15分钟内
λ 永远传达且只传达一个信息
λ 讲故事
λ 制作“综述单页”
λ 重点演示用户体验
λ 极度专注倾听

10.4.1　将演示时间控制在15分钟内

10.4.2　永远只传达一个信息
如果你连关键信息是什么都不知道，还是取消演示吧。一旦准备好了你要传递的信息后，始终围绕它来做演示。去掉与这个信息无关的数据或议题。制作完演示稿后不要忘记多检查几次，务必确保它就是你要传递的信息。

10.4.3　讲故事
人们喜欢听故事。故事有代入感，能将你要传递的信息与真实的生活连接起来。除了去掉了故弄玄虚的字眼和缩写词，你还通过讲故事做到了其他五件事情。将创意与个人生活关联起来，从而使听众产生了代入感。让观众跟着你的节奏走。提供了一个人们都能理解的具体例子。描述了你将要解决的问题。描述了你的解决方案将如何提升用户的生活品质。我经常看到偏技术的演示者不去描述用户场景，而是大谈特谈特性细节。有决断力的高管常常会在演示中间叫停演示并强制演示者清晰阐述用户场景，在近况汇报会议上，你只需简单地列举证据来支持要传递的信息即可。其他类型的演示，如用户体验评审或推销，适合讲故事的原因是你能围绕用户组织内容。

10.4.4　制作“综述单页”
谷歌前工程总监彼得·威尔逊发明了“综述单页”法。彼得的“综述单页”法是指演示稿的第一张幻灯片，即位于标题页之后的第一页，必须包含你演示的关键要素。 “综述单页”法和“讲故事”法并不兼容，因此你需要谨慎使用这种方法

“综述单页”应该包含以下四块内容。
1. 你想讨论的东西是什么
避免缩写词和新名词。
需要向高管解释的东西越少越好。
2. 机会
换句话说，你和高管们愿意花费时间讨论这个议题的原因是什么？
你也可以将演示的核心数据压缩成1到2个重要数据点。将这些数据点添加到“综述单页”中能增加其合理性并在开始阶段就打消受众的疑虑。
3. 提供的解决方案
请用清爽的文字来阐述解决方案，
添加原型图的链接，这样当需要时你可以快速将它拉出来。
4. 成本和实施时间表
某些情况下它还可能是你要问的内容，你需要管理层给你这些东西。
如果你的管理层打算给你承诺，他们也需要你给他们一个类似的承诺。你需要提供一张你能负责的时间表。

10.4.5　重点演示用户体验
打破成见并在脑海中建立新的具体图景的最佳方式之一是使用图片。具体来说便是重点演示用户体验的原型图。
在重点演示用户体验时仍然阐明关键信息。
为了从外部用户的角度来描述你的原型，请首先说明首要用户目标而非描述特性。然后你可以指出用户体验是如何满足这个目标的。

10.4.6　极度专注倾听
能否分清建议和需求决定了你是能卓越地完成交付还是什么也交付不了。一个有效地捕捉各种意见细微之处的方法是让一个值得信任的同事一字不差地把它们记下来。提前了解谁是关键的利益相关者将使你聚焦在最重要的反馈上，并让你高效地分配记笔记的时间。

10.4.7　更多的演示技巧
如果一页幻灯片上不只是一幅图加一句话时，请把这页的信息要点放在标题里。苹果那帮人很擅长这个技巧，不过在户外或对较大规模人群进行演示时这样做的确是最好的。
如果你发现先前的技巧并不适用，请把信息要点放在标题里。
如果你没有模板，请使用基本的商学院的那种蓝色背景，配上黄色和白色的字。它们在任何投影仪中都能得到很好的呈现。
阅读并遵循罗宾·威廉姆斯所著的《写给大家看的设计书》一书中提及的基本视觉设计原则。
阅读并遵循爱德华·塔夫特所著的The Visual Display of Quantitative Information，2nd Edition一书中提及的信息展示原则。
不要担心留白。人们喜欢留白多的幻灯片。
不要使用“构建版本”这类字眼，除非你想让听众认为你华而不实。
不要使用红色来代表除危险或糟糕之外的任何其他意思。

第11章胜在决策

软件是决策的物质载体。做决策不是简简单单地说“行”还是“不行”。软件不像大多数英文编撰物，它的复杂性决定了它是团队共建的产物，因此它也是团队决策的反映。你必须设法让你的团队成员对他们所钟爱的事情说不。

11.1　推后：“我们明天再完成。”
由于人类畏惧冲突的天性，很多软件团队主管害怕说不，于是“蠕变特性”（Featuritis或者Creeping Featurism）成为一种常见病。将不属于绝对最小化可行特性集的所有特性放到V2。

11.2　谈判：“行，再给你10分钟。”
几乎所有特性或用户体验的争论最后就会变得像绑匪谈判。依靠谈判快速达成共识是通往成功的必经之路。谈判的第一步是正确地认识到不管你是不是
产品的负责人，你都不是老板。团队主管常常会召开小范围的经营决策会议，这是错误的。要想交付卓越的产品，你需要让团队成员体验到参与感和发言权。更好的团队决策制定过程是在早期就让所有团队成员都参与进来。如果在你思考让谁参与决策时有什么指导性原则需要遵从的话，那一定是信息透明。请将决策的理由透明，将决策的时间透明，将团队参与决策的途径透明。一旦将关键人物聚到一起后，你需要通过谈判而不是击败别人来达成共识。安妮塔·伍利和托马斯·马龙对此进行了一些研究，为我们提供了出现这种情况的原因的深入见解。因此你的目标是促使产生一个满足各方需求的创造性的解决方案。哈佛谈判项目（The Harvard Negotiation Project）认为这个过程的首要关键步骤是达成对目标的共识拥有创建满足各方需求的共赢的解决方案的能力是作为领导者最重要也最令人满意的方面之一，它还会鼓励你将每次谈判都视为创建解决方案的机会。有时候甚至还未讨论目标你就陷入谈判中了。这时候有三种帮助你回归正轨的方法。聚焦于促进。不要一开始就尝试去解决问题，否则你会带着先入为主的观点以至于无法保持中立，这会使讨论更加复杂。你应该首选确保听到每个人说的话。 “先寻求理解，再寻求被理解。”你需要极其努力地理解他们到底在说什么。问问你自己，他们真正关心的是什么？然后通过提问来验证你的假设。如果你已经有了倾向性的判断，不妨先说出来，然后让其他人继续发表观点。我认为当其他人已经知道你有倾向时，你不妨开场先阐明你的倾向，然后把指挥棒交给其他人以便能专心倾听。这个方法真诚且高效。有一个常见的场景需要一些稍微专业的技能：财务谈判。

11.2.1　阶段1：这不是你的错
财务谈判几乎总是会令人心烦，究其原因是因为商业社会里公司媒介精英为了实现自我价值而将谈判的强度拉得越来越大。

11.2.2　阶段2：公平谈判并使用数据支持
最公平地谈成某个数字的方法是参考交易数据。

11.2.3　阶段3：那个数据没谈成……我们编个新数据吧！
由于你或你的对手会不断披露和编造新的信息，因此财务谈判会耗费很长的时间。编造信息特别有挑战性。

11.2.4　阶段4：寻找可免费提供的东西
在阶段4，各方都会设法往交易中塞一些没有价值、无须成本的扯淡的东西。

11.2.5　阶段5：转身离开并安静思考
这对谈判来说是个好事，双方都可暂时离开并回到产品上面。这个重新拉开的距离允许你再次思考现实的情况。

11.2.6　阶段6：协议、文书工作、以及互相指责
就在你觉得交易已经完成时，你会发现任何公平的、有价值的交易都还有大量的文书工作要做。这些细枝末节的东西之所以存在是因为任何合同都需要非常清晰才能具备效力。为了增加明晰程度，你必须定义一切细节，这时你会发现你们的沟通尚有很多不明之处，而这些不明之处会导致冲突。

11.3　处理冲突
第三个也是最后一个你需要借以达成卓越共识的工具是冲突管理。更可能的是和你一起工作的都是拥有超低沟通能力和极高专业能力的人们。
不要假设这场冲突的另外一方一定就是一个讨厌鬼，考虑另外一些可能的背景情况。如果你脑补出另一些可能的背景情况，你就能以更积极的心态来应对冲突。
等到你相信你所面对的家伙不一定是个讨厌鬼时，你就能找到问题的根源。90%的情况下冲突的根源都是沟通不畅。另外10%中有1%是因为你面对的的确是个讨厌鬼，剩下9%是因为目标的方向错了。你真正需要了解的只是那90%的情况，你和对方在“各说各的”。换句话说，你们对重要的事情达成了共识但却纠缠在一些细节或措词问题上。我发现当工程师和工程经理真的关心某件较大的事情时，他们会经常把焦点放在细节上，如不要写重复的代码等，毕竟细节更容易被具象化。由于你知道这时你们有很大可能在各说各的，你便可以回到上一步并问问自己其他人真正想说的是什么。这是第一步。

一旦确定你们正在各说各的，你便可以借此机会建立一个通用的术语表，这样你们在讨论中就不会因为措词问题而导致沟通不畅。两个关键且常见的背景元素。第一，时间总是一个挑战，清晰地说明时间上的限制有助于其他人了解什么是可能做到的。不相信时间会成为一个问题？让一个朋友打两个中等复杂的结，然后你和另一个朋友蒙着眼睛去解开这两个结，整个过程不准说话。
第二，常常有一些别人并不知道的假设或者别人自己做出的假设。
再补充一点，请设法确保你的项目名称在产品的整个生命周期中是一致的，否则你会让那些不知情的人们感到迷惑。有时候别人听不懂你说的话，而你企图通过分类法和背景介绍来澄清它们也遭遇抵制或让人丧气时，请转向白板。我发现图画和列表能使事物变得清晰。然而有时冲突并非由明显的沟通不畅或根本的观点分歧导致的。当有人戳中你不想被别人戳中的地方时冲突也会产生。如果想要更好地控制每个人都会有的强烈的情绪反应，你需要先识别出是什么引发了这样一个反应。虽然你可以管理自己的情绪反应，但因为软件工作强度很高所以偶尔发发脾气是很正常的。所以无须惊讶他们的情绪会很强烈，你最好马上接受这个现实：惹恼他们是不可避免的，尤其在你设法交付的时候。但如果你能客观地进行交流，也许可以减少惹恼他们的次数。客观地交流是指只围绕软件、用户或问题进行讨论，而不把人牵扯进来。

我最钟爱的三个客观化的方法是：
λ 不说“你”或“我”。
λ 聚焦在角色模型上，而不是人上。
λ 使用客观指标。

11.3.1　不说“你”或“我”
试着修改邮件中所有使用了“我”或“你”的句子。这样能让邮件内容变得客观而且聚焦在产品的表达上，而不是聚焦在“你”觉得怎样或“我”提出什么上。如果你在口头交流中也能去掉“你”和“我”，那就更好了。

11.3.2　聚焦在角色模型上，而不是人上
引入莎拉这个角色可以大幅增加交流的客观性。更重要的是，当到了要做艰难决策的时候角色模型能发挥更大的作用，因为你在砍掉某个具体特性时，感觉受到不公平待遇的不是那个发明它的人，而是某个角色模型。

11.3.3　使用客观指标
如果同意事实没有观点重要，那你接下来就需要一套与观点打交道的方法。幸运的是我们有可用性测试和决策矩阵来帮忙。决策矩阵则是一个简单的图表，它可以帮助你做多选一的决策。如果时间充足，进一步使用决策矩阵是很有价值的。你可以增加一列“权重”或“优先级”

第12章胜在从容

长期以来，我和同事一道致力于交付事业，下面这些就是我收集并践行的经过实践检验的建议的精髓部分。我把它分为5个类别，希望能对你有所帮助。
如何平衡交付、质量和影响、团队这三者的关系，你才能交付一款卓越的软件。
如何应对随机情况，你才能继续按原定节奏交付一款卓越的软件。随机情况是指当你的管理层掷给你一个弧线球或者你的团队脱离正轨时出现的情况。随机情况是每个在谷歌或亚马逊工作的人都理解的词之一，因为它是与帮助团队专注于交付相对立的。
如何妥善地管好你的精力，你才能1个顶3个。
如何找人以及在什么时候找人，你才能让合适的人做合适的事。
如何咽下狗屎三明治，因为有时候你的确得咽下去。

12.1　如何平衡交付、质量和影响、团队这三者的关系
现在你还可以使用一些工具来检查你是否失去平衡，如团队周会的气氛、高中蒙羞测试以及你的产品需求文档。

12.2　如何应对随机情况
为了应对新的特性需求，你可以创建一个简单的共享文档来集中记录它们。将文档对每个人开放，这种透明度会减少人们出于恐惧的关心和你收到的问题数量。当随机的建议来自管理层或投资人时，你可以使用版本1测试来帮忙打消这个想法。你需要从开发时间、系统设计、容量以及其他你所依赖的职能部门（如法务）等方面来评估成本。这时你们可以就成本和收益进行真实、理性的交流。在成本评估前你没有任何理由退回任何一个需求，除非这个需求是不正当的。如果这个建议真得非常奇葩但又必须放在版本1，有时候你最该做的事情不是去反对。遇到这些情况你可以和你的团队一起投入最小的精力并以最快的速度将这个特性部署到你的可信测试者那儿去，然后等待并观察。在评审会议上认真倾听能帮助你避免某些随机情况。切记，如果大老板说你应该做某件事，你几乎一定需要做这件事。不要存在侥幸心理认为老板们会忘了他们提出过这个需求。还有很多随机情况的来源是你无法控制的，比如公司优先级发生了变化。而有的人脑袋里就没有一根政治的筋。我属于后一种人，所以我只能提供五条基本的策略来应对公司优先级的变化，这五条策略是按先后顺序排列的。
1. 弄清楚公司优先级的变化是不是真的。
2. 更改产品的表达方式以迎合变化。
3. 尽可能小地改动。请和你的工程团队合力找出一条成本低见效快的方法。请进行小的改动，然后回归正常的节奏。
4. 请求通融。
5. 忍。

所有这些策略也适用于应对大规模的基础设施变更。

一个关于如何与你所依赖的基础设施打交道的经验法则：你需要坐在火车中部。

找到两到三个可供参考他们进展的团队。当发现某个团队切换到新基础设施的过程相当轻松，那么你也是时候切换了。

12.3　在交付过程中如何管理精力
它教导我必须学会为每个任务分配合理的时间。因为不可能做完团队需要你做的所有事情，所以你需要优先做最应该做的事情，且不要在意没有做完所有事情。彼得·德鲁克在《卓有成效的管理者》中也呼应了这个观点。他说你首先应该做那些只有你能做的事情。这个工作方法有助于将你起到的作用最大化并防止你成为阻碍者。如果你觉得学会高效利用时间和精力太难了，或者认识到这是一个你完全缺失的技能时，考虑从托尼·施瓦茨的能量工程中学会该如何做吧。施瓦茨曾在《哈佛商业评论》上发表了一篇名为“管理你的精力，而不是时间”（Manage your energy, not your time）的卓越文章并随后围绕优化个人精力这个概念出版了一本书并开发了一套业务。最后一个管理精力的技巧是制定工作日程表。

12.4　如何把向上求援当成工具而非托词
当遇到下面任何一种情况时，你很可能需要向上求援。
你正设法为一个在某些方面比较愚蠢的管理层下达的命令辩护。
你真心不懂为什么你要做这些事情。像这种情况，你最好能单独从大老板那里得到一个解释，因为大老板可能会更清楚一些。
你不负责这个问题。这里需要重点说明的是我并非主张你应事不关己高高挂起。
当你发现有个问题是其他人负责的，且那个人不喜欢你越俎代庖，那就向上求援吧。
你需要与之打交道的高管不愿接见你。

12.5　如何咽下狗屎三明治并生存下去
你现在就需要接受这个事实：你团队主管的生涯中一定会经历一些令人厌恶的时刻。你可以把这些三明治当作高中生活，生存下来才是重点。当收到一个三明治时你应保持微笑，咽下三明治，然后继续前行。

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

附录2 团队不可或缺的工件

你能从www.shippinggreatness.com上下载到其中一些工件的模板。

轮值表——将寻呼器号码和手机号码的清单复制到一张钱包大小的纸上。
使用Wiki搭建的“联络簿”，用于遇到故障、突发事件或问题时寻找相关负责人。这个列表应该包括法务、公关、市场、产品团队、工程团队和网络运维（或者任何负责生产基础设施的部门）的负责人和联系信息。
描述使命的语句。
关于未来两年的清晰策略。
一页简要说明产品的人物/事件/原因/时间/方法的文档。
产品需求文档，或者叫功能规格说明。
新闻稿。
线框原型图或者餐巾纸草图。
内部FAQ文档，其中部分问答打上外部FAQ标签以作为客户支持内容的原始素材。
沟通文档，包括关键信息、有潜在危险的问题和对这些问题的回应。
发布时穿的T恤衫。
包含测试时间的开发计划表。
未来两年的路线图。
内部用户列表和迁移时间表（适用于基础设施项目）。
可信测试者列表（适用于面向外部的产品）。
特性需求列表，并将内部和外部客户中呼声最高的三个特性需求高亮。
开放问题列表，并清晰标记这些问题的状态。
进行中的会议纪要。最好建一个文档保存项目所有的历史会议纪要。
发布计划或发布规程。
记录什么特性在什么时间发布的生成变更列表。在排查客户问题时特别有用。
对增长预测和硬件配置需求提前进行计划的生产设计文档。
专利注册文件、商标注册文件和版权申明文件。
隐私说明。
出色的数据指标——包含内部的状态面板和一些供外部消费的清洗过的数据指标。
为幻灯片、演示、评审、发布准备的产品截图。
团队本季度目标以及上季度目标完成情况。
Bug状态面板和阻碍每个发布的Bug列表。
错误原因报告或事后调查报告。
会议纪要和团队周会、用户界面评审、产品评审、工程评审、Bug处理、法务评审、业务拓展周会以及客户支持碰头会的时间计划表。

我要写长评

想读在读读过

标签(多个标签以“，”分开):

保存

谷歌和亚马逊如何做产品

推荐文章

猜你喜欢

附近的人在看

推荐阅读

拓展阅读