本书讲了什么

在软件行业中，我们把设计、打造、发布一款符合市场需求的软件称为交付（shipping）。一旦走上了软件交付之路，你将面临产品、方案、项目和工程管理各方面的挑战。本书讲的就是作者在谷歌和亚马逊的交付经验之谈。

作者什么来头

Chris Vander Mey，Facebook产品经理，曾任谷歌高级产品经理、亚马逊技术产品开发经理和工程经理，他交付的软件正在被亿万人所使用。Chris曾多次带队在消费者或企业领域开发软件，其中包括亚马逊的实名制系统，也包括Google Maps。

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

有效交付过程的7个阶段

阶段一，确定正确的产品方向。好的产品一定要满足众多客户所共有的某个真实的需求。你的使命就是找到一种独特而有意义的方法去满足这一需求。

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

阶段三，设计用户体验。你需要从用户的角度出发，和设计团队不断沟通、反复迭代，最终构建出良好、直观、简洁的用户体验。

阶段四，做一些基础的项目管理工作。项目管理工作包括跟踪交付物的进展、指出问题以及控制项目范围。

阶段五，开始测试。你需要主导bug的处理并慎重决定哪些可以容忍出现在版本1而哪些又必须在发布之前修复掉。

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

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

第1章赢在使命和策略

如何找到正确的需求

团队应该始终积极地去解决客户的问题，而不是紧盯竞争对手，被动地做出反应。我们学到必须专注于解决真正的客户问题。当把一个问题不断放大时，你覆盖的客户会不断增多，而问题的解决也会使更多人受益，这意味着你的潜在收益会更大，财富、名望、成功也就随之而来了。

如何构建卓越的使命

卓越的使命需要完全符合以下三点要求：

能够唤起人们的兴趣。

提供言之有物且能指明方向的原则。

适合印在T恤上。

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

如何制订正确的策略

策略是指在竞争对手的压力下，利用公司独特的优势来争取目标用户的粗略计划。它只是一段用于说明对目标客户来说你的产品将如何长期保持比竞争对手更强的吸引力的话。简而言之，你需要阐明三件事：客户、公司和竞争。

当你开始思考公司、客户和竞争这三大问题时，需特别注意如何才能长期为客户提供比竞争对手更优质的产品。你需要深思远虑，因为要想取得商业上的成功就必须保持长期的竞争优势，否则竞争对手就会迅速模仿并推出一个和你的产品功能一样、价格却更低廉的新品牌来将你一举击溃。

第2章赢在产品定义

产品定义过程主要分为10步：

第1步：撰写新闻稿

所谓新闻稿是指一篇向市场宣布将要推出新产品的通告，应该简单明了地传达关于产品的关键信息。新闻稿的媒体属性注定了它天生就更简洁、可读性更强且更关注真实的产品能给真实的用户带来什么价值。好的新闻稿包含六大要素：产品命名、发布时间、目标客户、解决了什么问题、如何解决、CEO的公开赞辞。

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

随着产品方案的不断细化，各种问题也层出不穷，我会迅速把这些问题记到一个内部FAQ文档中并尽我所能回答提问者。创建并维护FAQ文档有两大好处。第一，它能节省你大量回复邮件的时间，还能抵御一些内部责难。第二，当你的客户支持团队和科技写作团队开始整理所有面向公众的内容时，FAQ将是一个很有价值的资源

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

在FAQ中撰写问题答案时，你会发现其中一些答案用流程图或线框图来表述会更好一些，尤其是涉及用户体验（UX）的细节时。流程图可以帮助你准确地解释用户工作流和系统交互相关问题，简要线框图则可以帮助你具象化产品各环节的用户体验。

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

这两份文档所需包含的五个要素：

产品名称。

目标客户数量有多少。

解决了什么问题。

这个问题对于目标客户来说有多大价值。

解决方案。

何时交付。主要的里程碑有哪些？

团队背景（仅针对VC）。

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

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

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

它是用来详细描述用户应该如何体验产品的文档。它不包含系统在后台如何运行之类的技术细节，这类细节应该包含在工程主管撰写的技术规格或设计文档中。功能规格文档包含以下九个内容块：

简介。它说明了为什么要做这个产品以及做些什么，每个新进入项目的成员都可以从中了解到必要的背景信息。

目标与非目标。你需要将产品方向细化成不同目标，每个目标都应保持清晰简洁并将它们按优先级排列。

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

原型图或线框图。将这些图粘贴到功能说明中，它们是用户场景的重要补充。

API。如果你还没写API文档，那就现在写，不过前提是已征得工程团队的同意。

负载规划。负载规划是指对未来一段时间内用户的使用量进行粗略估计并制订应对计划。

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

FAQ和开放问题。你可以直接将FAQ和开放问题的链接地址放入功能文档中，也可以把内容复制过来。

关键事件。你最好能列出主要事件的达成时间，如特性完成时间、可信测试者版发布时间。

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

你的团队将开始寻找边界情况或者极端情况，即极少出现的产品行为或场景。不要抱怨这个看似繁琐的事情，如果不找出所有边界和极端情况，你就无法采取应对措施。

第8步：客户测试

去找一批现存的或潜在的客户，向他们介绍你的产品设想和原型，并听听他们的反馈。这个测试可以避免你做出一个没人想用的产品或者遗漏一些核心功能。

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

考虑产品命名以及产品能带来多大收益。当你向高管或投资者汇报产品方案时，需要一个确定的名称来确保你们讨论的是同一个东西。你还需要告诉他们产品能带来多大收益，从而使他们更认真地对待你的方案，而要想预估产品收益就得先给产品定价。

第10步：取得上层的认可

为了让负责决策的高管最终认可你的产品方案，你需要预先争取中间每一级老板的支持，然后让直接向该高管汇报的家伙预先顺畅地了解你的产品概念。

第3章赢在用户体验

6个用户体验问题

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

主要角色必须完成的主要任务是什么？该用户界面要求主要角色完成的主要任务又是什么？关注主要角色而非全体用户可以帮助你更好确定优先级。若以上两个问题答案一致，则设计是符合要求的，反之你就需要做些工作了。我们要做的是清晰地阐述我们的业务目标以及它们之间的优先级，之后将权力交给设计团队，让他们以此为基础进行一系列的优化。

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

用户完成任务的能力与该任务的复杂程度呈非线性函数关系。你对用户要求得越多，用户完成的能力和意愿就越低。简化特性，让用户只做他们必须做的，然后隐藏那些偶尔使用或者次重要的高级特性。

信息是否组织得当？

有时候你想展示的信息会有多个行动点，你需要让它们保持平衡。亚马逊的产品详情页面，几乎所有内容块都统一按照它们的收益能力排序。有些特性的直接影响很难评估，如客户评价，它们被放到了页面底部。有些特性则很容易评估，如“看过此商品后顾客买的其他商品”，它被放在靠近页面顶部的地方。最重要的客户类型最关注的信息应该最突出。信息应该尽可能个性化且实时，也应在合理的前提下尽可能详细。用户喜欢适度精确的信息。最常用的控件出现在最容易找到的地方。

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

当识别出了用户最需要完成的核心任务后，你需要问问自己这些任务是否是可发现且可理解的。可发现性是指用户发现行动点的能力。以“加入购物车”这个行动点为例，如果你的用户连“加入购物车”的按钮都很难找到，你这份工作也别想再干下去了。

解决可发现性问题的三种常用方法：

定位。在西方文化中信息的优先级是从左上角向右下角递减的。如果你想把行动点放在最显眼的地方，你很可能需要把它放在内容的左上角。

视觉设计。视觉设计能有效解决可发现性问题，你可通过改变元素大小，使用差异化配色，或者跳出栅格来使你的行动点变得易于发现。

惯例。应用程序、网站和企业都依赖于某种设计语言来使任务可被理解。

标准是否一致？

最好确保你的应用程序中按钮始终位于同一位置，特别是当它们运行在iOS或者Android上时。所有主要按钮都应尺寸放大且配色一致。一个用户界面中只有一个主要按钮。使用一组按钮来表示“是”或“否”这样的选择。不同优先级的行动点使用不同的样式。当一个流程有3或4张页面时，告诉用户目前处于哪一步以及共有多少步。

能否减少用户点击次数？

问自己：“我能把一个表单从两页合成一页吗？”用户必要的点击次数会极大影响用户完成这个任务的能力。你还需要仔细考虑用户选项中的默认设置。如果你的默认设置符合用户的需求，用户就可以少点击几次，同时也少遇到一些异常结果。另一个可减少点击次数的重要方面是减少用户在键盘和鼠标之间来回切换的次数。

了解如何与设计师沟通

把他们当做专家来对待。

以用户的口吻说话。

以提问的方式建立共识。

反复讲述业务目标。

帮助设计师了解他必须解决的问题是什么。

避免设置主观目标也能帮助你的团队。

用数据说话。

提供一些竞争对手或类似体验中运作良好的案例。

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

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

控制花在视觉设计上的时间视觉设计、品牌、命名等元素都是主观的，与用户能否完成任务的关系也不大。不像文案，这些花哨的元素不会帮助你理解用户体验，要是你把它们添加到原型中反而可能产生关于样式的争论，而这种争论与你想要解决的问题一点关系都没有。你应该使用标签明确的占位符框来替代这些视觉元素，然后继续下一步。

第4章赢在项目管理

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

你需要一张计划表来告诉你何时可以交付。一张简单的计划表只需包含任务列表和每个任务的工程评估量，这个量是指工程师或设计师完成该任务所需要的时间。你只需将这些任务按照他们认可的特性优先级排序并分配给团队成员，然后一张计划表就成型了。一张简单的Google电子表格就足以管理这些任务和评估量了。如图。

这份电子表格的使用方法：

你需要和开发主管合作将各项任务填入到任务分解区域。

评估每个任务在不考虑余量的情况下所需的剩余开发者日，并猜测哪个工程师可以承担这个工作。

将每个任务都归属到产品的某个目标版本中。你可能知道这些版本被称为“迭代”，其实它们也同样是你的发布版本。

如何拿到评估量

让你的工程经理去要评估量。

表面上接受评估结果。

认识到你的权力。

只跟踪剩余时间。

要求不考虑余量的评估。

每周一次在团队会议上评估各任务的剩余时间。

跟踪Bug并创建Bug燃尽图

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

你应该期望接近编码完成时Bug数量会随时间不断增加，然后接近发布时Bug数量会随时间不断下降。这些Bug下降的比率，或者说这条曲线的斜率，被称作发现/修复率。当发现/修复率小于1，即每天修复的Bug数量超过每天发现的Bug数量时，你才能确定Bug的具体规模并精准地预测发布日期。

当Bug发现/修复率降到1以下时，你便能通过计算Bug数归零的日期来预测产品何时能够按照给定的质量等级发布了。如果你对测算出来的发布日期不满意，你只有两个选择：降低你的质量标准，或者增加工程人力以更快修复更多Bug。

管理依赖

如果去除它也可以运转，那就去除它。

如果内部能构建，那就内部构建。

如果必须添加一个依赖，那就趁早添加。

如果必须添加一些依赖，那就依靠它上一个已构建的版本。

如果交付得早，被依赖伤害的可能性就小。

第5章赢在测试

如果你交付的软件无法正常工作，卖不出去是一方面，更糟糕的是你会因此蒙羞。高中蒙羞测试：你只需扪心自问：“我能确信当一个高中老同学看到我的产品时我不会感到羞愧吗？”记住，你的工程团队成员都有一帮高中老同学，别让他们因为你的产品而蒙羞。

如何确保你交付的软件不会让你蒙羞呢？你可以遵循下面8个主要步骤，这些步骤对产品质量有着重大影响：

坚持测试驱动开发

埃迪工程师将代码分成多个片段，每个片段负责执行一些简单的操作。这些片段称为单元。例如，countToTen()是一个软件单元。在写countToTen这个方法之前，埃迪先写了一个测试，即单元测试。大体是这样写的：If countToTen() is equal to 10, then pass;else,fail.单元测试写完后，他开始写countToTen方法，如果索引在循环中意外失效导致count

ToTen实际上输出的是9，测试就会失败。当软件构建时，所有的单元测试会自动执行。

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

无论你的工程团队多么优秀、编写了多少单元测试，总是避免不了Bug的。找到这些Bug的最佳策略就是雇佣或者任命一位测试主管。测试主管需要确保测试用例撰写准确、覆盖完整，且被正确执行。

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

一个测试计划由很多测试用例构成，这些用例是从你的产品需求文档中派生出来的。测试计划通常是用电子表格创建的，因此你能方便地整理测试用例。检查测试用例是否包含下列描述性要素：

领域。这一列描述哪部分的用户体验将被测试，你可以合并相近的项。

严重性。该列定义了如果测试失败你会将此归为哪个级别的Bug，通常有1～4级。

前置条件。前置条件指定了测试人员在测试前必须做的事情。

需执行的任务。任务由多个步骤组成，是测试的主要内容。

后置条件。后置条件描述了应用程序在任务执行完毕后所处的状态。

如果时间不够宽裕，你可以每轮测试只执行高严重性的测试用例，这样虽然完整性有所欠缺但速度更快。这个方式也适用于验证一些微小的产品变更。你可以只测试发生微小变化的部分和高严重性的测试用例，这比全部测试一遍要省很多时间。在这里重新执行一遍高严重性的测试用例非常重要，即便你觉得这个微小的变更与其他特性毫不相干。

一轮全面测试后的输出物是Bug列表，有时候这个测试结果会让人诧异。这个时候很关键，作为团队主管，你需要一边向团队强调“坏的消息就是好的消息”，一边大力表扬测试团队的努力和成果，毕竟你还需要测试团队继续鼓起干劲寻找错误。

评审测试用例十分繁琐。你必须亲力亲为，即便只是为了维护与测试团队的感情。这里有一个小诀窍：固然坚持评审完所有测试用例是最理想的，且每一个注意到的人都会对你赞赏不已，但你也可以选择只关注以下三块内容。

用户体验。

安全和隐私。

依赖。

自动化测试

如果你的测试主管能够精心搭建一套独立于产品代码的测试系统，你的测试工程师们将受益极大。更为重要的是，测试自动化程序会不间断运行，干着数十人才能干完的活。

推行内部试用

推行内部试用会遇到挑战，特别是你要大家试用的软件已经有了一个比较好的、没什么Bug的替代品时。比如谷歌想让员工去试用谷歌文档，但大家都在使用微软Office，这时候解决该问题的最佳办法就是停止在公司电脑上默认安装微软Office，这不但能推动员工去试用谷歌文档，还能节省办公软件成本。

如何开展找虫总动员

找虫总动员是指发动你的团队或者你的整个公司专门花一定时间，通常是一个小时，来寻找尽可能多的内部试用产品的Bug。四件事情有助于找虫总动员获得成功：

设立奖项，提供物质激励。

在项目计划中增加找虫总动员这样一个关键事件。

将找虫总动员排进你的开发和测试日程表中。

坏的消息就是好的消息。每发现一个坏Bug都是好消息。

准确且有条理地处理Bug

只需简单的3步就能把Bug处理好：

基于频率、严重性和解决成本对Bug进行分级。

每天与开发主管和测试主管碰一次，评审新增的Bug。

不断施加压力以减少新的阻碍发布的Bug出现。

Bug分级时你需考察以下三个方面。

频率。Bug出现的频率越高，修复它的重要性就越高。

严重性。你需要评估Bug对用户体验的伤害有多大。

修复成本。评估修复一个Bug需要耗费多少资源。

发挥可信测试者的作用

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

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

在我看来人们常常是被细微的事情所打动。如果你的内部试用搞得好，产品的大部分地方都不会让你蒙羞。但产品开箱体验的好坏取决于产品中一些最复杂的部分。抵达特性完成阶段后删掉你所有数据和账号然后从零开始使用软件，抵达编码完成阶段后再这样操作一次。

第6章赢在量化

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

优秀的量化指标应具备5个关键特点。

测量成本低廉。

测量可靠且可重复检验。

能频繁地测量，最好能实时测量。

团队能够根据它做出明智的改变。

专注于客户。

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

无法测量的东西也就无法提升。如果你辛苦了一年去提升某个产品的某些客户的使用周期，但到头来你无法量化业绩，你凭什么能晋升呢？如果想在未来证明你的业绩，你需要事先准备一根基准线。因此你必须尽早确立指标并在产品开发过程中不断更新。确立基本指标并不困难，比如说工程团队的执行能力就是一个基本指标。

执行力可以通过考察产品能否在你要求的日期内发布来衡量。你的发布时间通常取决于待修复的Bug数量。很多Bug跟踪系统能够生成发现/修复率和Bug数量趋势图。因此综合发现/修复率和Bug数量你可以预测“零Bug”到达日期。要了解更多有关如何生成该指标数据以及它为什么这么重要的内容。

产品发布后你可能需要更换指标，即客户及其行为数据。你需要借助基于它们的指标数据来向投资方或管理层汇报，形成产品发展策略，并指导你的团队。三类发布后需要跟踪的关键指标：

目标进度。目标指标会告诉你目标的完成进度。

经营绩效。经营绩效指标会告诉你产品的问题在哪里以及如何提升用户体验。这些指标通常是用比率表示，比如从点击购买按钮到付款成功的转化率。

系统性能系统。性能指标能说明你产品的实时健康度。

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

几乎所有的指标都可以通过一些巧妙的手法进行操纵。指标只是一个指示器，不是你的老板，所以请放心，你的核心指标是不可能被糊弄过去的。当指标变成了你的老板，你需要花费数天乃至数周的时间去为你指标数值的合理性辩护时，你就该换个指标了，或者换个工作也行。

第7章赢在发布

对改动说不

在准备发布的过程中你必须尽量频繁地对新的特性、新的Bug以及用户体验上新的改动说不！如果不这样做，你就永远完成不了软件，自然也就永远交付不了。发布手中有的，而非脑中想的。有时候你不得不交付你的产品，即使它并不完美，因为交付一个过得去的产品比为了追求完美而什么也交付不了好。

开启作战室

随着发布日期的临近，每周开一次会的节奏已经不合时宜了，所有人都在朝着目标加速冲刺。在这个节点上你应改开每日例会并不再禁止与会者在会上争论一些问题。每日例会能帮助你高效做出决策并营造一种紧迫的氛围。

营造紧迫的气氛

所有的项目都是看似时间分配得井井有条，但到最后都需要冲刺一把才能赶上发布时间。只要这样的冲刺不超过1个月，大多数团队和他们的家人还是可以接受的，特别是你还会补偿给他们一定的休息时间。

完成发布清单的核查

要想出色地完成发布，你需要拟定一张发布清单。这份清单的目的在于确保软件发布中所有需要跟进的事项都被有序安排且被详细描述。发布清单还能促进团队内部不同职能的交流。正确地使用清单能让它发挥不可思议的作用，每个民航飞行员在每次飞行前都必须核查一遍清单，可见清单的价值和重要性。

撰写博文

博文的目的在于阐述你的使命、你的目标客户以及你能解决的问题。从传统新闻的角度来看它就是你的“导语”。

发布软件

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

亲自验证软件

你需要以新用户的身份来亲身体验整个产品，确保产品所有主要功能都可正常使用。有些产品功能常常会出现问题，如注册流程、上传数据（如图片）、搜索、表单提交等。它们都依赖于一些子系统，所以有时会因为配置疏忽而指向到了错误的服务器。这种类型的错误无时无刻不在发生。因此你的团队应该等待你和你的测试主管、开发主管全部验收通过后，再把产品推向更大面积的用户。

应对发布带来的各种影响

出现问题，回滚软件。只要成功回滚，发布就还没有失败。回滚是指把软件撤回到预发布状态。它简直就是家常便饭。如果可以回滚，你就能撤回对产品的改动，从容不迫地修复问题，然后再试一次。

应对产品危机危机。检查这是否是一起突发事件并评估影响范围。确定这个问题不止在你这里出现。发起电话会议。打开一个Bug。知会危机扩大邮件组成员。推迟任何公关计划。知会相关方。保持Bug的更新。寻找并引入专家协助团队解决问题。

演示产品。你的演示需要直截了当，演示的目的在于用讲故事的方式来讲述产品，并在每一步凸显产品使命。它必须简洁，最好不要超过10分钟，这样才能保持观众的注意力。

应对媒体和客户。如果你有幸能和媒体或者知名博主接触，尽可能让他们对你的业务产生深刻印象。和他们通电话并向他们演示产品。快速响应撰稿人的需求，因为他们通常都有要求的截稿时间。

庆祝发布。每一个令人瞩目的产品发布都离不开团队成员做出的牺牲，因此感谢你的团队为之付出的心血是非常重要的。不要吝惜任何赞美之词，它会让你的团队欢欣鼓舞。

第二部分　掌握卓越技能，更胜一筹

第8章胜在团队

如何组建一支团队

为了组建一支高效的团队，你必须找到能默契配合的工程主管、产品主管和设计主管。当发现这些人时，你要巴结好他们，哪怕给他们写赞美诗、买糖果甚至洗车都行。你的效率源自于团队的运作，找到一个能带好他们的主管将从根本上减轻你的工作量，还会极大促进你在其他方面努力的成效。

如何与远程团队合作

组建一支工程师团队。

充分沟通。

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

重视文化差异。

构建清晰的需求。

忍受时差。

委任得力的主管。

与远程团队共饮。

第9章胜在技术

略。

第10章胜在沟通

如何写好邮件

将想表达的最重要的事情放在文章开头。

使用精确增量表达法。

分点阐释原因。

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

设法用建议取代质疑。

考虑受众的感受。

五种类型的会议

团队会议。这类会议用来了解近况以及利用团队合力来深入讨论和解决特定问题。虽然团队会议中解决的大多数问题理论上通过邮件也能解决，但只是理论上而已，所以你还是需要这种会议来承担这些工作。

站会。它只用来交流近况，促使团队内部信息透明、责任到位。在会议中每个人都站着，这样可以帮助保持会议的简短。

1对1。指只有你和另外一个人之间的会议。这类会议或许是最值得开的，因为在会议中你们能坦率地交谈。而且会议也给了你们专门时间来完成需要互相协作的任务。

产品/工程/用户体验评审。这是一种大规模会议，通常会有一些大老板参加。这个会议既要向高管通报产品进展，又要收集组织内最富有经验的人们的反馈建议。

头脑风暴会。这是所有会议中最有趣的，它形式自由，能激发想法，还能让团队主动参与到问题的解决中去。

如何组织好会议

会后立即发出主题纪要。

允许改变开会的目的。

拒绝在团队会议中发泄。

问五轮为什么。

如何做好演示

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

永远只传达一个信息。

讲故事。

制作“综述单页”你想讨论的东西是什么，机会，提供的解决方案，成本和实施时间表。

重点演示用户体验。

极度专注倾听。

第11章胜在决策

略。

第12章胜在从容

略。

第13章　再度启航

十大交付原则

你不是来当老板的——团队主管是仆人，他们存在的目的就是为了伺候工程团队。

从用户角度出发。

用独特的方法解决很多人都有的大问题。

坏的消息就是好的消息。

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

构建最简洁的可用的产品。

交付手中有的，而非脑中想的。

无法测量的东西也就无法提升。

你不可能做完所有工作，所以你应首先做那些只有你能做的工作。

永远走在交付的康庄大道上。