本书由“PDF 电子书网”整理

    PDF 电子书网(www.xgv5.com):免费提供各类精品

    电子书的网站!PDF 电子书网提供的书籍绝对可以当

    得起你书架上的一席之地!总有些书是你一生之中

    不想错过的!

    好读书，读好书，找好书就到 PDF 电子书网 www.xgv5.com

    www.xgv5.com

    PDF 电子书网所有书籍全部免费分享，只为以书会

    友，欢迎大家支持!

    择，O'Reilly 现在还将先锋专家的知识传递给普通的计算机用户。无论是通过书

    籍出版，在线服务或者面授课程，每一项O'Reilly 的产品都反映了公司不可动摇

    的理念——信息是激发创新的力量。

    业界评论

    “O'Reilly Radar 博客有口皆碑。”

    ——Wired

    “O'Reilly 凭借一系列(真希望当初我也想到了)非凡想法建立了数百万美元的业

    务。”

    ——Business 2.0

    “O'Reilly Conference 是聚集关键思想领袖的绝对典范。”

    ——CRN

    “一本O'Reilly 的书就代表一个有用、有前途、需要学习的主题。”

    —— Irish Times

    “Tim 是位特立独行的商人，他不光放眼于最长远、最广阔的视野并且切实地按

    照Yogi Berra 的建议去做了：‘如果你在路上遇到岔路口，走小路(岔路)。’回顾

    过去 Tim 似乎每一次都选择了小路，而且有几次都是一闪即逝的机会，尽管大路

    也不错。”

    ——Linux Journal

    中文版推荐序

    这是一本不错的产品经理或项目经理的入门级手册，对于一些刚选择做产品经理

    的人来说，能成为指路明灯。我在做了5 年技术后转行做产品经理时，也像作者

    一样，没有人指路，整整自己摸索了一年。如果当初能看到这本书，肯定会少走

    很多弯路。书中用到了不少作者在谷歌和亚马逊工作时的例子，能帮忙读者更好

    地理解产品交付的全过程。所以即使是老手，也可以从中收获到一些来自优秀公

    司内部的最佳实践。

    不过在阅读此书时要注意一点，所有的流程和规范最终都是为了解决实际问题

    的，不要贸然引入流程，除非已经碰到问题，否则尽量简化流程，提高效率。要

    交付一个产品，其中最重要的只有3 点：1)确定用户需求和预期指标；2)以最

    小成本实现最主要的需求；3)发布并获得数据反馈，确定下一个迭代目标。建

    议从这个最小集开始，哪个环节出现问题，再参考本书引入相应流程，可能更有

    效。

    另外，附录的十大交付原则中提到“从用户角度出发”，这点无疑是最重要的，这

    和文中提到的产品定义的第一步撰写新闻稿居然是一脉相承。用用户能理解的语

    言去描述你要交付的产品带给他们的价值和好处十分重要，如果写不出来，或者

    写出来用户看了一点兴趣都没有，请尽快停止这个产品，因为即使整个产品开发

    和交付过程极其完美，这也注定会是一个失败的产品。

    最后，请记住：一个互联网产品的交付上线不是意味着结束，而是意味着刚刚开

    始。所以尽快从产品交付的喜悦中回来，进入下一个迭代，在迭代中和产品共同

    成长吧!

    陶伟华

    360 手机助手高级总监

    前言

    交付卓越

    在软件行业中，我们把设计、打造、发布一款符合市场需求的软件称为交付

    (shipping)。软件交付可不是打打包，举办个发布仪式那么简单。它要求你找到

    合适的产品，克服过程中的复杂与多变，并快速完成发布!这个世纪真没生出多

    少新工种，交付却是其中之一。也许你会质疑，交付不就是“管理”嘛，哪个软件

    项目没有一个管理者呢。确实，哪里会没有高谈阔论的管理者呢!就算是原始人

    搬运猛犸骨头，后面都站着一批讨论库存管理的酋长们呢。管理太泛滥了，各种

    理论层出不穷，有的甚至没有任何实践依据，所以我宁愿使用“交付”这个词。交

    付这一工作很新，我们呱呱坠地时它还没有出现，甚至等到我们的孩子出生时它

    也不过刚在角落里长出嫩芽，在学校里更不可能学到它了。

    尽管时日尚短，交付却已展现出非凡的价值。它简直是一剂灵丹妙药。它能解决

    钱的问题，因为投资人给你追加投资的前提是你取得了好结果；它能解决客户的

    问题，因为交付能力的强弱决定了你是否能推出客户需要的功能和补丁；它能解

    决团队的问题，因为没有什么比取得进展更能让团队士气大振!所以，如果你想

    追逐名望、财富、幸福感，那么，交付出卓越的软件，你将赢得一切。

    只要精通交付，你就不用担心软件商业化会失败，也不用害怕与大公司展开竞

    争，因为你的市场嗅觉会更加灵敏，行动更加迅捷!倘若你因不懂交付而导致延

    期、发布产品时门庭冷落或苦心构建的产品无人问津，你的团队会变得急躁，你

    的客户会直接写信给你的大老板投诉，而你最好的结局是晋升无望，最坏的则是

    和你的团队一起卷铺盖走人，你们也终于可以有时间琢磨下简历或者亲自动手洗

    车了。

    所以，精通交付则前途似锦!但要让团队精通交付可不是件简单的事情，不过这

    也正是你读此书的原因吧!

    这本书将告诉你如何快速精通交付，就好比麦肯锡的“迷你MBA”培训。这家全球

    最有名、最昂贵、最顶级的管理咨询公司每年都会招一批科学博士，进行为期两

    周的称为“迷你MBA”的培训，培训完成后这些科学博士通常比那些受过两年培训

    的MBA们还要出色。本书将提供给你一个同样简单、精炼的方法，让你轻松完成

    交付或者更好地理解团队主管的工作。

    为什么我想要写这本书呢？当我初入这个领域时，没有前人指路，只能筚路蓝

    缕，以启山林。后来我发现很多产品经理、测试主管、工程经理以及其他各式各

    样的团队主管们也像我当初一样迷茫，经受着同样的困扰。但幸运的是，在我苦

    闷之时我得以与一些“伟大的老师”相伴，如达特茅斯学院、亚马逊公司、谷歌公

    司，以及我那些错误的商业投资等，我从中学到了很多经验。我想把这些经验总

    结出来并分享给同行们。

    我的第一个老师是我自己开的公司。我那时非常狂妄，以为会写软件就够了，定

    义最小可行产品、管理项目、迭代、发布、市场推广等其他与软件交付相关的事

    情都不是问题。我因此得到了很多有价值的教训，也知道了狂妄的代价。我后来

    又加入了一家创业公司做CTO并耗费数年时间在业务扩张上。在这个过程中我得

    到了一些新的教训并重蹈了狂妄的覆辙。羞愧之下，我只身前往达特茅斯学院的

    塞耶工程学院和塔克商学院学习了一段时间，并取得了工程管理硕士学位。

    离开达特茅斯后，我加入亚马逊担任技术产品开发经理和工程经理(所谓的双比

    萨团队 1

    主管)。在客户评论、个性化、反欺诈基础建设等项目中，我亲眼目睹

    了杰夫·贝索斯和他的副手们是如何工作的，并试着效仿商界中一些最佳工作方

    法。

    1 双比萨团队是亚马逊CEO杰夫·贝索斯提出的概念，即团队人员不能太多，两个比萨大家就都能吃饱

    了。——译者注

    后来我加入谷歌担任高级产品经理。我花了5年多的时间研究可扩容性、商业决

    策以及软件团队内部的人际动力学。我将Google Pack 2

    发展壮大，把Google

    Update服务应用到数十款产品中，帮助构建采用移动同步服务的Google Apps项

    目、Microsoft Outlook连接器和数据导入工具。我还推出了Google创新多路视频通

    信产品，现在它是Google Hangouts的一个功能。我甚至为Google Maps工作过一段

    时间。我见证了公司的成长和改变，真切感受到了产品因何成功，却又因何失

    败。这为我进一步完善软件交付方法提供了大量经验。

    2 本书中所有的互联网产品名称都将沿用原著中的英文名称，以避免混淆，部分英文名译者会提供注释。

    Google Pack指谷歌向用户免费提供的软件包，在第2章中会谈及。——译者注

    关于交付，你可以从亚马逊、谷歌的那些杰出的业务主管那里学到很多。但请切

    记，交付是个新事物，与此配套的技术、流程、技巧等都极度缺乏。微软倒是有

    一些软件交付的经验，不过它的方法都是从开发大型、耐用的软件过程中总结出

    来的，确切来说，就是从开发占据业界统治地位的Windows的过程中总结出来

    的。不过互联网兴起后，那种三年开发周期、通过软盘售卖的老方式已经失去了

    价值。快速迭代、部署、互联网服务托管已经变成了主流。工程师们越来越关心

    如何搭建一个可以快速响应的应用开发框架，如何进行可用性的研究，以及如何

    构建一个更好的scrum这样的过程框架。但是关于交付的知识太少了，亚马逊和谷

    歌的成功经验在外面流传的也不多，我们更多时候只能摸着石头过河，一不小心

    就可能误入歧途。

    这本书将涵盖我从工作中学到的、提炼出来的关于交付各阶段的较为完备的知识

    体系。一旦走上了软件交付之路，你将面临产品、方案、项目和工程管理各方面

    的挑战。因为软件交付不只是如何管理项目，也不只是如何提升开发效率，你必

    须具备更全面的技能。你既要加深对技术的理解，又要贡献更好的产品创意，更

    重要的是，整个过程中，你需要展现出你强有力的商业洞察力。你也许要做所有

    工作，包括要求工程师编写测试用例，或者用Photoshop绘制产品原型。这个工作

    要求你追求极致，只要你不惧挑战，它终将成为你的舞台!

    换个角度说，软件交付的过程一定会伴随痛苦、混乱、艰辛。直到游刃有余时，你才能感受到强烈的成就感。这好比在砾石球道上打高尔夫，如果你是新手，一

    杆挥毕，球不知飞到哪里。球童被你折磨崩溃了，你也不能幸免，整日在烈日下

    寻找那个正绝望地躺在某个石头底下的小球。但如果你是高手，嘿，连续漂亮的

    击球后你轻而易举地站到了果岭之上，环顾四周一群新手正汗流浃背地在砾石堆

    里寻找着他们那个不起眼的球，这一刻你一定知道这意味着什么，这意味着荣

    耀!

    本书将分为两大部分来帮助你精通软件交付。第一部分是关于那些在亚马逊和谷

    歌做得最好的团队是如何交付软件的。我按照项目开始到发布的顺序来安排章

    节，包括用户需求研究、用户体验设计、项目管理、测试、发布等。第二部分是

    关于团队主管带领团队成功交付所需要的技术积累、最佳实践和技能。第一部分

    建议逐章阅读，按照软件交付的过程一步步来，第二部分则可按任意顺序阅读。

    你还可以根据工作需要针对性地阅读某些章节。

    本书所提供的工具和建议都是通用的、方向性的。美国西部传奇警长怀亚特?厄普 3

    为了能更快开枪，会卸掉柯尔特左轮手枪的安全锁，磨平击锤凸轮。你也可以

    将这些工具和建议抽丝剥茧以彻底为你所用。如果你想看到对软件策略的深入分

    析，不好意思，这本书不是你想要的。但如果你想找一个经过实践检验、学习起

    来简单且能带领你的团队走向成功的方法，那么请继续读下去吧!

    3 美国西部传奇警长。——译者注

    鸣谢

    特别感谢Brian Marsh，他是这个世界上最好的工程经理，过去八年我和他在同一

    间办公室里共事，他帮我弄明白了什么是交付。这本书中有很多内容来自于他的

    建议(当然不是那些蹩脚的笑话)。非常感谢Aaron Abrams，他是我最好的读

    者，他第一个告诉我要“让观点更犀利点儿”。谢谢Ali Pasha、Steve Saito、Matt

    Shobe和Mike Smith，你们阅读了初稿并提供了非常棒的反馈。最后，特别感谢

    你，Tim，感谢你的耐心、无微不至的帮助和永远的支持。

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

    打造一款卓越的软件似乎并非难事，但事实往往不尽如人意。通常产品要么逾期

    交付，要么没抓住真正的用户需求，要么发布后还有一个又一个烂摊子等着去收

    拾。究其原因，很重要的一点便是我们不知道如何正确地组织交付过程。我们经

    常会舍本逐末，将关键步骤忘个干净，或者瞎冲乱撞，一头扎进琐碎之中出不

    来，以为凭借运气、加班加点和美好的愿望就能把产品成功推向市场。

    这样做也许能成功一次两次，但却不可持续、没有效率，所以亚马逊的顶尖团队

    不会这么做；这样做也毫无乐趣可言，所以谷歌的顶尖团队未予采纳。其实有一

    套更为有效的交付过程，它分成7个阶段，任何团队主管都可按图索骥，收获成

    功与快乐。

    阶段一，确定正确的产品方向。如果总是设计垃圾软件，那么你永远不可能交付

    卓越的产品。好的产品一定要满足众多客户所共有的某个真实的需求。你的使命

    就是找到一种独特而有意义的方法去满足这一需求，并且在交付过程中的所有努

    力都应围绕着这个使命。例如，你应根据使命来制定产品切入市场的策略。一旦

    确定了使命和策略，产品定义就会更清晰，而不会沦为垃圾，因为它完全符合你

    出色的策略。

    阶段二，尽可能清晰详细地定义产品。这个过程需要10个主要步骤，包括撰写新

    闻稿、创建并不断更新FAQ文档、撰写功能需求文档等。完成这些步骤后，工程

    团队就会对项目形成统一的认识，管理层或投资者也会了解并认可产品的设计。

    这时候所有人都会异常兴奋，而你也可以稍作休息了。

    阶段三，设计用户体验。你需要从用户的角度出发，和设计团队不断沟通、反复

    迭代，最终构建出良好、直观、简洁的用户体验。你应不断提出问题，促使设计

    团队始终围绕着产品使命展开工作。你还应该让工程团队和设计团队保持密切合

    作，确保设计最终可被实现。

    阶段四，做一些基础的项目管理工作，不要太多也不要太少。当工程团队拿到详

    细的产品原型图和需求文档开始编码后，你就需要做一些基础的项目管理工作

    了，包括跟踪交付物的进展、指出问题以及控制项目范围。

    阶段五，开始测试。随着各个功能的代码块陆续提交，实际产品逐渐浮出水面，团队的工作速度将会提高，测试团队也将开始全心投入测试。这一阶段虽不需要

    多少创造性，却依旧令人兴奋不已。作为团队主管，你需要主导bug的处理并慎

    重决定哪些可以容忍出现在版本1而哪些又必须在发布之前修复掉。

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

    入监控并搭建产品状态面板。当产品bug趋近于零时你就可以准备监控产品发布

    效果了。记得买好香槟放在冰箱里以备庆功时尽情畅饮。

    最后，正式发布产品。发布一款卓越的产品可不只是上传一些文件到服务器上那

    么简单，你需要制订市场营销和公关方案，并在发布前仔细核查清单中的每一项

    内容。基本上每次发布都会有一些糟糕的事情发生，不过只要处理得好，大部分

    用户都不会察觉到。记得观察产品状况面板各项指标的走势，它会告诉你是否正

    走向成功。

    纵观以上7个阶段，推出一款卓越的软件并不是件难事。你只需按顺序完成各阶

    段的具体任务，就能打造快乐的团队，交付成功的产品。

    从以上阶段可见，我们一直在努力缩小项目范围，简化用户体验，提升推进速

    度。整个过程越快，迭代就越快，交付的产品也就越好，因为每次迭代都会吸收

    上一次迭代中客户提出的建议和意见。虽然每个产品有每个产品的功能，但它们

    的交付流程是一样的，所以你只要熟练掌握上述7个阶段，就能成功交付所有产

    品。下面让我们来详细考察每个阶段，先从制订使命和策略开始。

    第1章 赢在使命和策略

    除了获得财富和名望，成功交付的关键还在于快速且充分地满足客户需求。因

    此，你的使命就是解决客户的问题，你的策略就是找到一种独特的方法来满足这

    个群体或细分市场的共同需求。这听起来简单，理论上也不难。但就像赛车，理

    论上你只需在正确的位置刹车、转弯和加速就能赢得比赛，但实际上你很难做到

    这一点，让车子在跑道上发挥出最佳性能并不简单。同理，要想准确识别客户需

    求并围绕客户需求构建使命、制订策略也实属不易。为此你需要掌握一些特殊的

    技能，并对一些要点给予特别的关注。下面我将一一道来。

    首先来看看如何找到一个大众共有的需求。

    1.1 如何找到正确的需求

    如果仅凭别人一句“哇，太酷了，就做它吧”就确定要开发某个产品，财富、名望

    和成功绝不会向你招手。你可能想迎合某类群体的需求，可是他们有很多不同的

    需求，你又怎么确定首先要满足哪个关键需求呢？还是让我们回过头来，先看看

    那些极为富有的著名成功人士有什么好建议吧。

    亚马逊CEO杰夫·贝索斯一直强调团队必须“以客户为导向，而不是以竞争为导

    向”，公司业绩因此持续攀升，股东也获益不小。他的观点非常清晰地揭示出这样

    的原则：团队应该始终积极地去解决客户的问题，而不是紧盯竞争对手，被动地

    做出反应。无独有偶，谷歌CEO拉里?佩奇也常说一句类似的话：“立足客户，向

    外拓展。”他的理念与杰夫相似，只是更为抽象一些。从拉里和杰夫身上，我们学

    到必须专注于解决真正的客户问题。

    谷歌创始人兼总裁谢尔盖?布林对此也有些真知灼见。他多次提及：“不要只想着

    解决简单的问题，越困难的问题越值得去努力。”当把一个问题不断放大时，你覆

    盖的客户会不断增多，而问题的解决也会使更多人受益，这意味着你的潜在收益

    会更大，财富、名望、成功也就随之而来了。如果说拉里和杰夫告诉你必须解决

    真正的客户问题，布林会告诉你这还不够，你得确保这是个很多客户都存在的大

    众问题。

    我们以Google Pack为例来看看谷歌是如何解决一个真正的难题的。Google Pack是

    一个免费软件集合，为个人电脑提供实用软件，我曾在2007年~2008年负责这个

    产品。当时我们发现很少有用户去升级他们安装过的软件，因为升级过程极为复

    杂。而用户不升级软件，系统速度就会变慢，安全漏洞就会增多，孩子们在假期

    使用电脑时也会遇到很多麻烦。

    我们提出的解决方案是不设法优化每一个关于升级的用户体验，而是构建一套无

    需用户操作即可自动升级所有软件的系统，而且这套系统对第三方软件同样适

    用。显然这个方案更难实施，特别是考虑到第三方软件各有各的升级安装过程，但一旦构建成功，就能帮助到数以亿计的用户。Google Toolbar和Google Chrome

    后来也使用了这套系统，最终它以Google Update开源软件的形式推出供所有人使

    用。我认为这是一个极其成功的产品，它作为平台被业界广泛应用。而它之所以

    能够成功，要诀便在于它解决的问题比我们最初意识到的那个问题要难得多!

    如果你已经找到了这样一个大问题，那么就完成了产品定义过程中最重要的一

    步，而且更为重要的是你将开始以一种富有意义的方式去帮助一大批人!真实、大众、共有这些大问题的标准尽管很明显，却依然经常被忽略。这些标准还构成

    了使命的基石。下一步你应围绕这些基石构建使命并制订策略。

    1.2 如何构建卓越的使命

    团队一定要有自己的使命。如果你没有清晰地阐述使命则会导致失败，因为你的

    团队、组织和投资人会根据自己对使命的不同理解而各自为战，从而导致冲突、混乱和痛苦。这种情况屡见不鲜。还有些团队不愿意清晰地阐述使命，他们害怕

    会因此陷入到使命是什么的争论中去，但这不过是掩耳盗铃，一旦人人都意识到

    自己和别人步调不一致，争论将不可避免地爆发。因此，只有尽早确立卓越的使

    命，才能真正从总体上减少冲突，解决这个问题。

    卓越的使命需要完全符合以下三点要求——只有这三点。

    1. 能够唤起人们的兴趣

    要想吸引人并使他们认同你的使命，最重要的是确保你的使命能够唤起他们

    的兴趣。只有长期吸引利益相关者的注意，你才有时间去挖掘产品细节。

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

    你的使命应该能够指导你朝着哪个方向去努力。千万不要把使命定成“永争第

    一”之类小学生常喊的口号。通过在使命中指明方向，你将希望达成的结果清

    晰化了。

    3. 适合印在T恤上

    你也许不打算把使命印在T恤上，但不妨试试看，人们会更容易记住它。而

    只有团队牢牢记住它，他们才能依照使命做出各种决定。不要以为有一个高

    智商天才组成的团队就不必这样做，他们的天才能力可不一定表现在对这类

    事情的记忆上。因此，为了让你和你的团队更容易记住使命，应控制它的长

    度，适合印在T恤上就对了。

    我们举个例子来说明什么样的使命能够满足这些要求。亚马逊有一个非常出色的

    主要负责产品个性化推荐的团队，他们为自己定义的使命是“带给客户更多欣

    喜”。这个响亮的使命完全符合以上这些要求。

    能唤起人们的兴趣。因为每一位团队成员都希望自己的工作能带给客户欣

    喜。

    言之有物且指明方向。它指明了我们的方向是开发更多让客户欣喜的功能。

    它还言之有物，让人想到了意料之外的发现、探索以及愉悦感。

    适合印在T恤上。虽然过去这么多年我还依然记得它。

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

    面面俱到的使命。

    1.3 如何制订正确的策略

    很多人觉得制订策略是一件高深莫测的事，这可能是由很多方面的原因造成的。

    比如业界的咨询公司为了赚取更多的钱，会把这一过程人为地复杂化。当工程经

    理面对问题感到束手无策时，就会炮制出一些旁人看来难以理解、似是而非的策

    略来。但一个更为常见的原因是策略本身就是个模糊的东西，有时候你明明心中

    有一个很好的想法却不知如何表达出来。不过幸好我们是在软件行业，可以大刀

    阔斧地简化策略制订过程。

    首先我们要知道什么是策略。策略是指在竞争对手的压力下，利用公司独特的优

    势来争取目标用户的粗略计划。它就是这个样子，既不是详细的产品描述，也不

    是一页细致入微的计划。它只是一段用于说明对目标客户来说你的产品将如何长

    期保持比竞争对手更强的吸引力的话。简而言之，你需要阐明三件事：客户、公

    司和竞争。

    举个例子。我在Google Talk时肩负的使命是“使人与人之间在任何地点均能通过

    任何终端沟通”。纵观统一通信、视频会议和VoIP领域的竞争格局，我发现谷歌

    有一个竞争对手短期无法赶上的独特优势，即它拥有庞大的云服务基础设施，我

    们可以在此基础上利用交换技术来提供视频会议服务，这比Skype或其他视频服

    务供应商过时又昂贵的混合编解码技术要先进得多。部署一套他们的多通道视频

    系统通常需要上万美元，并且由于硬件原因，使用过程中会有很多延迟，实际效

    果不尽如人意。谷歌则没有这个问题，它的技术独一无二且竞争对手短期内难以

    复制，因为这个技术需要一个巨大的数据中心，而没有人能建立比谷歌更庞大的

    数据中心。

    因此无论是从公司角度还是从竞争对手的角度来看，这都是个合适的策略，我们

    能够通过这种独一无二、成本低廉的服务来取得领先地位。通过观察Google Apps

    数百万的客户与行业的发展趋势，我发现了一个新兴的由两类客户组成的细分市

    场，其中一类是企业中在不同地域工作的员工，另一类是在家办公的人，这两类

    群体都在日益扩大。此外电话会议市场的发展潜力也很大，而针对这个市场我们

    有优势明显的Google Voice服务。

    综上所述，我认为可以通过为企业提供低成本的统一通信服务来赢得市场。这个

    策略能让我们为中小企业以及中端市场提供比Skype更先进、比微软更低廉的服

    务。虽然最终谷歌没有采纳它，而是将Google Talk和Google Voice应用在Google+

    Hangouts上，重点发挥它们的社交属性，但你应该能从上面的思考过程中了解到

    该如何制订策略!

    当你开始思考公司、客户和竞争这三大问题时，需特别注意如何才能长期为客户

    提供比竞争对手更优质的产品。这也是在交付过程中唯一一次需要考虑竞争的时

    候，所以一定要想清楚!你需要深思远虑，因为要想取得商业上的成功就必须保

    持长期的竞争优势，否则竞争对手就会迅速模仿并推出一个和你的产品功能一

    样、价格却更低廉的新品牌来将你一举击溃。

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

    短的策略越容易实现，也越容易获得他人的认同。

    这里再举一个例子。假设我们是亚马逊旗下子公司IMDb(Internet Movie

    Database)的产品负责人，经过一轮头脑风暴后制订了如下使命。

    使命：启发视频观看者。

    这个使命能唤起人们的兴趣吗？我认为能。“启发”这个词就引起了我的兴趣。可

    能对于一些工程师读者来说更是如此，不过先看看我们的产品是如何适用这个词

    的吧。我们把“启发”定义为提供背景资料、鼓励探索甚至是帮助你了解朋友们的

    想法等。所以看起来是合适的。

    这个使命是否言之有物并指明方向？当然。它告诉了我们需要关注的对象，即观

    看者。这里，我没有限定“观看者”必须是“电影观看者”，因为我认为YouTube、Hulu等平台的观看者也是我们的目标群体，但不包括照片或其他形式艺术作品的

    受众，所以我用“观看者”这个词来限定需要关注的对象。同时“启发”这个词告诉

    我们应提供信息和数据服务，因此这个使命指明了团队应为目标用户提供哪些服

    务。

    这个使命适合印在T恤上吗？很适合，只要别把它翻译成德文并用大号字体印

    刷。

    现在我们有了一个大家都认同的使命，接下来便围绕这个使命制订策略。

    策略：随着越来越多内容的产生，用户每天消费的内容也越来越多，但对于

    20~40岁的工薪一族来说，他们在海量的内容面前却不知道如何选择。我们

    需要给这些用户以启发，帮助他们找到想看的视频，并让他们在看的过程中

    对内容有更深的理解。

    我们之所以首先选择工薪一族是因为，与有大把的时间耗在Facebook和

    YouTube上的青年不同，工薪一族时间有限，但他们人际网络丰富、个人主

    见强烈，还有可自由支配的收入，愿意在内容上消费。

    我们有独特的方法来解决用户挑选视频的问题。通过整合IMDb独有的电影数

    据集、亚马逊对数码内容分门别类的能力以及可靠的个性化推荐技术，我们

    可以构建出有效的视频推荐算法。虽然其他竞争对手(如Netflix)也有一套

    推荐引擎，但我们覆盖的平台多，拥有的数据也更丰富，能够提供比竞争对

    手更有趣的观看体验和更精准的推荐。

    我们将把这种观看体验通过各种载体来传递给观看者，这些载体展现了与内

    容相关的背景数据(如YouTube视频的演员阵容)，包括YouTube等网站的

    浏览器插件、手机应用程序等。我们还会提供丰富的与内容相关的信息以启

    发观看者，并提示观看者进行反馈——这就创建了一个良性循环并惠及所有

    用户。

    这个策略满足了所有要求：阐述了IMDb应该提供什么产品以及为什么这家公司适

    合提供这类产品，分析了竞争对手的情况以及IMDb应如何与之差异化竞争，还论

    证了IMDb为什么要针对这样一个特别的消费者群体。该策略不但简明扼要、详略

    得当，还直接指明了我们的具体目标，即整合所有视频来源并展现影片背后有趣

    的故事。

    你是否注意到一个小细节？在我写目标要瞄准工薪一族时用了“首先”这个词。它

    的言外之意是“青少年的需求将在版本2中考虑”，虽然这有点像空头支票，但好在

    能让我们先专注于一个更小的群体且无需彻底否认青少年的重要性。12.2节介绍

    了更多有关“放到版本2”技巧的信息。

    写完一个基本成型的使命和策略后(你可能已经写得过于具体了)，你该坐下来

    和主管讨论一下你所写的东西。这是获得大家认同与支持的第一步。如果在这一

    层面都无法取得共识，你就寸步难行了，因为后续要做的只不过是不断细化使命

    和策略而已。

    当你和团队主管们取得初步一致后便可以定义产品细节了。

    第2章 赢在产品定义

    交付的下一阶段是让你的产品方案具体且可理解。通过制订使命和策略，你知道

    了你的客户是谁，他们的需求是什么。你也知道如何做才能比对手更出色、更具

    备差异性。有了这些知识再加上一些头脑风暴，便可以得出一个大致的产品方

    案。或者你像我们大多数人一样，老板会对你说：“那就做出来看看吧。”这时需

    要借助文字来告诉你的团队你要做什么事情以及目标是什么。换句话说，需要思

    考用什么样的文字才能非常贴切地描述出你的产品，使设计师可以借此设计原

    型，HR可以借此雇佣工程师，而你可以借此拿到项目经费去购买面包和服务器!

    当设法细化产品方案时，你会发现产品要解决的一些客户问题都是你主观臆断

    的，而且因为你的使命和策略都是建立在客户问题上的，因此这些主观臆断也混

    入了其中。我不想扫你的兴，但事实是你的这些臆断很可能是错的。这一点儿也

    不奇怪，亚马逊、谷歌和其他大公司都犯过这样的错误。所以要采用一些方法来

    证明臆断是否正确。即便它们十有八九是正确的，也要经过证明，而证明的最好

    方法就是把产品提供给客户使用，然后听听他们的意见。

    多次在软件行业创业的埃里克?莱斯比较认同这个方法。他在《精益创业》一书中

    充分论证了为什么该构建一个最小化可行产品 。最小化可行产品是指产品最小的

    组成部分。通过把它提供给一定量的用户使用，你可以验证之前关于客户问题的

    臆断是否正确。你可以视需要来定义最小化可行产品、选择参与测试的客户数量

    以及决定一次验证几个问题。但不管最小化可行产品是大是小，你都可以参照下

    面的产品定义过程来定义产品。通过快速重复这个过程，你可以验证不同的客户

    问题，并添加更多更好的产品特性。当迭代越小越快时，你甚至不需要花大力气

    去猜测客户的需求，而是更多按照客户告诉你的去做，这样成功的可能性更大。

    产品定义过程主要分为10步。每一步都建立在上一步完成的基础上。其中有些步

    骤比较简单，有些步骤(比如撰写新闻稿)你可以只在首次迭代时进行(当后续

    的迭代都只是小的功能升级时)，所以整体上来看产品定义过程没有想象中的那

    么长。当你确定了产品策略后便可以开始产品定义的第一个步骤了。等到10步都

    完成后，你便拥有了一份定义完整、描述清晰的产品文档，你的工程团队也可以

    进入编码阶段了。

    1. 撰写新闻稿。 亚马逊喜欢这个不同寻常的第1步。新闻稿是一篇脱胎于策略

    的文章，篇幅不超过1页，主要用于促进各方了解和公开透明。你可能需要几

    天时间才能成稿。

    2. 创建并不断更新FAQ文档。 这份“活跃”的FAQ主要用于记录一些争议点和重

    要细节。你可以花1个小时搭建框架，然后在开发过程中以及上线后抽一

    些“业余”时间更新维护。你可以使用Wiki或Google Doc等现成的工具搭建和

    维护FAQ，这样可以节省费用。

    3. 绘制线框图或流程图。 线框图和流程图是产品的可视化描述，在讨论或答疑

    中使用可以让观点更明晰。绘制可能需要1天到1周不等的时间，鉴于这是最

    有力的沟通工具，还是值得投入这么多时间的。

    4. 撰写产品单页或10分钟的演示文稿。 产品单页是一篇写给高管或多数风险投

    资人看的产品介绍文章，你需要把控好介绍的详略程度。演示文稿和产品单

    页内容一致，只是表现形式不同。你可以花几个小时的时间写份初稿，然后

    收集一些同事的反馈并做修改，如此反复几次便可定稿，整个过程通常需要1

    ～2周。

    5. 在FAQ中添加API文档。 API是产品的第一个技术触角，在第6步会把它们全

    部整合到需求文档中。你可以先花数小时简单起草一些API，后续再在工程团

    队的帮助下完善它们。

    6. 撰写功能规格文档。 功能规格文档又名产品需求文档 (Product

    Requirements Document，PRD，谷歌常用此名)，或市场需求文档

    (Marketing Requirements Document，MRD，微软常用此名)。它是阐述产

    品各功能详情以及为什么要有这些功能的最权威的文档。你可以将新闻稿、FAQ、线框图、产品单页和API文档等内容粘贴到功能规格文档的不同章节

    中。除去这些主料，还需要添加负载规划、非目标以及非常见用例(用于清

    晰表述FAQ中各种非常见情况的用例)等佐料。

    产品的规模以及成熟度决定了你需要几天还是几周才能写完功能规格文档。

    如果产品尚不成熟，你应当尽可能缩小产品规模以快速验证客户需求的真实

    性。如果产品规模庞大且已臻成熟(如苹果的iPhone)，你就需要一份健全

    的功能规格文档了。

    7. 邀请设计团队和工程团队主管参与产品评审。 这一步是为了获得项目组对产

    品的认可，并让他们帮忙寻找产品中存在的各种极端及边缘情况。你应该邀

    请他们一起评审产品，这样一天时间评审就可以完成。评审过程中他们可能

    没有贡献细致的反馈，但至少有机会去想一想你的产品方案，否则等到猴年

    马月他们也未必会读你的文档。至于如何让你的团队参与阅读和评审，你应

    该已经驾轻就熟了。

    8. 找客户测试产品概念。 在此阶段，你需要了解产品方案是否真正能解决客户

    问题。花一天时间做一次完整的认知走查 1

    或花数天时间进行在线调研都是

    不错的测试方法。

    1 认知走查是指通过分析用户的心理加工过程来评价用户界面的一种方法，最适用于界面设计的初期。分

    析者首先选择典型的界面任务，并为每一任务确定一个或多个争取的操作序列，然后走查用户在完成任

    务的过程中在什么方面出现问题并提供解释。本解释摘自周荣刚和张侃所著的《界面可用性评价之认知

    过程走查法》一文。——译者注

    1. 命名、定价以及预测收益。 你可以晚些时候再想这些事情，只要对产品有足

    够的信心。对我而言，这一步的价值是让我睡得更为安稳，因为通过收益预

    测我会更加确信我的产品能给投资人带来回报。但我并不认同一些MBA花两

    周时间去弄这些东西，我觉得你只需(而且应该)投入几个小时或者更短时

    间。如果花的时间比这长，那你肯定是想多了。

    2. 向管理层汇报。 上面9步完成之后你便可以向管理层或VC汇报你的产品了。

    你可以使用10分钟产品演示文稿来汇报，并视需要展示FAQ、线框图等。一

    旦通过，就可以动工了。通常汇报需要30分钟或者更长。

    你是否觉得这样的产品定义过程太难了？不用担心，你的能力足以应付!这个详

    尽的产品定义过程已经把七零八落的事项重组成了一串非常细致但又连贯的工

    作。只要循序渐进，为跨越每一步而欢欣鼓舞，你就会拥有一段快乐的时光。产

    品定义过程的大多数步骤(第6步和第7步除外)都很快而且有意思(如果你和我

    一样也是个极客)。让我们从第一步开始吧。

    2.1 第1步：撰写新闻稿

    撰写新闻稿是产品定义的一个另类却有效的开始。它是由亚马逊 CEO 杰夫?贝索

    斯率先倡导的。所谓新闻稿是指一篇向市场宣布将要推出新产品的通告。不管是

    新闻稿还是博客文章，都应该简单明了地传达关于产品的关键信息。之所以选择

    撰写新闻稿作为第一步，是因为相比FAQ、产品单页而言，新闻稿的媒体属性注

    定了它天生就更简洁、可读性更强且更关注真实的产品能给真实的用户带来什么

    价值。

    好的新闻稿包含以下六大要素：

    产品命名

    发布时间

    目标客户

    解决了什么问题

    如何解决(务必简明扼要)

    CEO的公开赞辞

    请注意，新闻稿不要深入细节。它很少包含图片且从不包含财务信息。它只是从

    用户视角出发简明扼要地阐述产品是什么、什么时候发布以及为什么要做这个产

    品。如果你已经确立使命和策略，那你应该思考过如何从用户视角来阐述产品

    了，这会让你在撰写新闻稿时得心应手。事实上新闻稿的这些要素都是直接来源

    于你的策略，比如CEO所表扬的内容正是你那套切入市场的独特方式。

    我在负责Google Apps时曾帮助撰写了后面这篇博文，虽然只在前面几段序言中探

    讨了大致的业务难点(在2009年企业用户还难以部署Google Apps)，但大体上你

    还是能看出一篇好的博文是什么样的。因为只是一篇博文，所以没有引用CEO的

    赞辞，而是换成了一个大客户的推荐语。这篇博文的效果令人兴奋不已，它让我

    们知道了这个产品是如何完美地契合了客户的需求，而这不正是本阶段我们要达

    成的目的吗？(访问http:googleenterprise.blogspot.com200906use-microsoft-

    outlook-with-google-apps.html 可查看完整的文章。)

    使用Microsoft Outlook管理Google Apps的邮件、通讯录及日历

    2009年6月9日，周二

    去年一年我们都专注于如何降低企业部署Google Apps的成本。在过去的几个

    月已经有若干改进面世，包括离线Gmail、用户文件夹同步以及与黑莓的全

    面互通性。

    今天我们非常兴奋地宣布又一项改进面世了，它就是面向Microsoft Outlook

    的Google Apps同步插件(Google Apps Sync)。该插件允许你通过Microsoft

    Outlook无缝管理Google Apps专业版或教育版，从此企业部署Google Apps的

    又一个关键障碍被排除了。

    相较于商务用户以往使用的产品而言，Gmail的界面和特性更受他们喜爱，但有些时候总有一批用户只喜欢Outlook。为了方便他们使用Google Apps，我们开发了面向Microsoft Outlook的Google Apps同步插件。它允许Outlook的

    用户管理Google Apps的商业邮件、通讯录和日历，并且当他们的工作电脑不

    在身边时还可以通过Gmail的网页端来获取这些信息。

    它的核心功能点如下。

    邮件、日历和通讯录同步。同步插件使用离线Gmail协议来同步邮件，比

    IMAP及其他协议速度要快很多。

    空闲忙碌状态查看和全局邮件列表功能，不管你的同事是使用Outlook日历还

    是Google日历，你都可以轻松发送会议邀请。

    简单的数据迁移工具。只需要两次点击，企业雇员就可以把Exchange或者

    Outlook的现有数据复制到Google Apps中。

    如果读完之后产生这样的感慨：“如果我是谷歌CEO埃里克?施密特，我肯定会明

    白为什么这些家伙愿意为这个项目付出数年努力，这绝对值得!”那么你已经明白

    了新闻稿的作用，马上开始写你的产品的新闻稿吧。但如果你心里觉得：“这家伙

    就是一个脑残，什么时候我们才能开始写API啊？”那么没有关系，跳过这一步

    吧，但请不要再跳过其他步骤!

    如果跳过了撰写新闻稿这步，等到完成后面两步时，你会发现仍然需要写一篇与

    新闻稿类似的文章，即产品单页。由于没有写作新闻稿这类面向客户的文章的经

    验，你会发现产品单页难以下笔，所以最好不要跳过第一步。但在某些情况下跳

    过这步又是合理的，比如是内部系统开发、产品特性改进或者处于一个新奇事物

    (如产品开发前的新闻稿)不受欢迎的公司环境中。

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

    随着产品方案的不断细化，各种问题也层出不穷，其中大部分都非常重要，指出

    了产品的不足之处。我会迅速把这些问题记到一个内部FAQ文档中并尽我所能回

    答提问者。我喜欢那些愚蠢的问题，因为它们让我感觉好像没花多少精力就消灭

    了一个问题，这真是一种少有的乐趣啊。

    如果觉得某个问题外部用户也会问到，我会把它记到FAQ文档的“外部问题”部

    分。通过不断添加新问题，这份文档将变成那些有疑惑的人寻找答案的动态更新

    的可信资源。

    当遇到回答不上的问题时，我也会把它放入FAQ并期望有人能够回答它。最坏情

    况下你也可以把这个FAQ当作个人的Bug列表或者团队讨论主题库，当悬而未决

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

    创建并维护FAQ文档有两大好处。第一，它能节省你大量回复邮件的时间，还能

    抵御一些内部责难。节省时间是因为FAQ已经回答了那些显而易见的问题，你就

    不再需要对每个问题都回复一封长长的邮件。能抵御内部责难(这点更为重要)

    是因为你很可能因为一些小问题上的疏忽而被问责，这时你可凭借细致周到的

    FAQ文档来证明你是尽职的，它会帮你浇灭大部分无谓的怒火。

    第二，当你的客户支持团队和科技写作团队开始整理所有面向公众的内容时，FAQ将是一个很有价值的资源。由于你已经把FAQ分为了内部问题和外部问题两

    个部分，因此他们知道哪些内容可以公开。所以创建并维护FAQ文档是个非常出

    色的主意，在产品研发过程的诸多关键时候它都能帮你节省时间，比如在产品发

    布前你们团队还需要依靠它来完善帮助内容。

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

    在FAQ中撰写问题答案时，你会发现其中一些答案用流程图或线框图来表述会更

    好一些，尤其是涉及用户体验(UX，User Experience)的细节时。确实如此，流

    程图可以帮助你准确地解释用户工作流和系统交互相关问题，简要线框图则可以

    帮助你具象化产品各环节的用户体验，并在之后的汇报中发挥不可思议的作用。

    除此之外，在白板或空白纸上画草图并用手机拍照也是一个沟通想法的好办法。

    因为绘制线框图或流程图非常重要，我会在第4章用一个完整小节来讨论绘制的

    过程和方法，这里不再赘述。

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

    到现在为止，关于客户是谁、要解决他们的什么问题以及采取哪种解决方案应该

    都有定论了。接下来你需要去争取工程团队、管理层、VC(风险投资人)或其他

    利益相关方的初步支持。你需要弄清楚他们对产品的认可程度，否则等到第7步

    功能规格文档都快完成了，而他们还对产品的价值存有疑义，你将面临不断的返

    工。另外在这时准备演示还有一个优势，因为经历上面几步后你对产品方案的细

    节以及可能受到的挑战都有了更全面的理解，所以在应对他们的诘问时能胸有成

    竹、进退有度。

    这一步你只需准备产品单页和10分钟的演示文稿，也可以两者选其一。在产品单

    页中根据需要来添加线框图或流程图就可以了，不必考虑它们所占用的篇幅。

    在亚马逊，产品单页尤为重要。高级副总裁们(SVP，又称S团队)会围坐一圈安

    静地阅读你的单页，然后讨论是否通过。整个现场就像高考一样，身边每个人都

    想第一个完成考卷然后逃离这个充满诡异气氛的考场。但不管怎么样，这样的决

    策机制已经运作数年了。

    谷歌的决策机制与亚马逊不同。在谷歌，即使准备脱离幻灯片直接介绍产品，你

    也需要准备一份演示文稿，因为需要你亲自演示，且谷歌没有建立像亚马逊那样

    的“高考”机制。第5章会谈到如何制作卓越的10分钟演示文稿。

    面对VC时，两样都需要准备，因为你既需要发邮件介绍你的产品，又需要面对面

    做产品演示。不过无论你在哪里工作，这两份文档的内容都是一样的，它们都是

    新闻稿的延伸。下面介绍这两份文档所需包含的五个要素：

    产品名称

    目标客户 + 数量有多少

    解决了什么问题 + 这个问题对于目标客户来说有多大价值

    解决方案 + 这个解决方案类似线上哪个产品，为什么你的方案能让竞争对手

    在长时间内都无法模仿

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

    团队背景(仅针对VC)

    你会发现产品单页和演示文稿实际上是新闻稿的延伸，它们增加了市场机会(用

    户量)、收益机会(解决方案的价值)和长期竞争优势(对手长时间内无法模

    仿)这三方面内容。如果你还不能在产品单页中清晰地表述以上几点，请继续努

    力!

    在10分钟的演示文稿或产品单页中同时包含这5个要素似乎是件充满挑战的事

    情，大多数团队负责人初次尝试都无法做到既完备又简洁。我见过成百上千寻求

    投资或收购而做的产品演示，其中只有极少数能够快速、清晰、连贯地把产品介

    绍到位。因此，每个团队负责人都应把进行一份简洁、清晰的产品演示视作一个

    必须完成的任务，它能帮助你立即赢得尊重、关注并拿到产品启动的通行证。第

    10章有关于如何做好演示的详细介绍。

    最后再提一个关于10分钟产品演示的建议：你的听众无论来自公司内部还是公司

    外部，无论关心技术还是关心商业，他们大部分人对你的行业都有充分的认识和

    独到的见解，但并不了解你要做的事情的前因后果。因此你演示的最佳方式是先

    讲用户现状，再延展开来(参考先前的五大要素)，迅速把要点讲完后再留出时

    间供这些聪明的听众就他们关心的点刨根问底。不要埋怨他们咄咄逼人，他们并

    非喜欢看你理屈词穷的样子，这只是他们考察你的一种方式，所以欣然面对吧!

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

    API文档可以说明你的团队如何与其他团队协作、外部开发者如何使用这套系统

    以及你需要存储什么数据。预先定义清楚API还有个好处，它可以帮助你搭建由

    这些API构成的面向服务的体系架构(SOA，Service-Oriented Architectures，第3

    章有更详细说明)。因此预先撰写API文档对每个人都有很大帮助。

    不只如此，API最重要的作用是明确系统的各个边界，而明确的边界有助于人们

    了解各类功能或输出分归哪方负责。这样在项目初期各方就建立了理解和术语上

    的一致性，为后续高效沟通产品需求打下了坚实基础。

    虽然API的作用很大，但也会带来一些麻烦。和你合作的开发工程师或许会觉得

    你抢了他们的工作，所以谨慎起见你应先了解他们的立场。如果理解你撰写API

    的目的是为了让高层同意你定义的关于数据存储和接口维护的责任归属，他们很

    可能会默许你的做法。如果工程师们依然不理解你的良苦用心，不要继续纠结，换个方式来说服他们吧。记得提醒自己工程团队是你的左膀右臂，别让任何事情

    影响到你们的关系。

    举一个提前撰写API的例子吧。当时我们在亚马逊负责构建客户评论中的内容评

    分系统。作为产品定义的一部分，我需要告诉客户评论团队如何调用我们的系统

    拿到评分，于是我在FAQ中增加了一个简单的API：

    Float getContentQualityScore(string reviewId,string userId){}

    这个API(用某种未知的程序语言写的)相当简单，但依然说明了一些重要的事

    情。

    我们假定了索引值不是ASIN(亚马逊产品ID)，而是评论ID。

    我们假定了评分为非整数数字。

    我们未来想支持类似Netflix的评论评价系统 1

    ，这样就能给你这样的用户提供

    最有价值的评论了。所以我们认为API最好也提供评论的评价数据。

    1 用户可以通过点击有用或者没用来评价其他用户撰写的评论，豆瓣也有该功能。——译者注

    你可能想更简单一些，但对于提供给开发者的东西，即使他隶属于其他团队，你

    都应该考虑得更周全一些，以防止后续出现问题。比如在上面这个例子中我们若

    不说明评分是一个非整数数字，客户评论团队就会以为我们提供的是类似ABC这

    样的等级评价，而按等级的排序算法和按分数的排序算法是截然不同的。

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

    你已经精心构思了一个可以解决真实客户的真实需求的产品方案。你也完成了演

    示并赢得了重要利益相关者的认可，然后又与依赖方一起定义了系统该如何交

    互，现在可以考虑实施细节并制作一份详尽的功能规格文档了。

    微软称这份文档为市场需求文档，因为它整合了市场研究者从客户访谈中收集到

    的一系列需求。谷歌称之为产品需求文档，因为它通常是由产品经理负责撰写

    的。亚马逊则把它称为功能规格，因为它描述的是产品应提供什么功能给用户使

    用。虽然各家命名不同，但对于它功用的看法却是一致的：它是用来详细描述用

    户应该如何体验产品的文档。它不包含系统在后台如何运行之类的技术细节，这

    类细节应该包含在工程主管撰写的技术规格或设计文档中。

    功能规格文档的读者一般为你的工程团队、设计团队，偶尔还有市场营销团队。

    功能规格文档包含以下九个内容块，按照先整体后细节的顺序排列，我将逐一详

    细介绍：

    1. 简介(使命和策略)

    2. 目标与非目标

    3. 用例或用户场景

    4. 原型图或线框图

    5. API

    6. 负载规划

    7. 依赖

    8. FAQ和开放问题

    9. 关键事件

    2.6.1 简介

    这块内容与产品单页相同。你也许认为没有必要把它放在这个文档中，但你的工

    程团队需要它。它说明了为什么要做这个产品以及做些什么，每个新进入项目的

    成员都可以从中了解到必要的背景信息。同时它还说明了文档中一些术语的含

    义，你可能因为使用习惯了这些术语而忘记别人其实并不理解。

    2.6.2 目标与非目标

    简介中虽已大致描述了产品的方向，但你需要将其细化成不同目标，每个目标都

    应保持清晰简洁并将它们按优先级排列，这样工程团队就可以合理地进行设计与

    开发了。

    如果设定的某个目标表面上与产品方向没有多大关联，你需要解释清楚为什么将

    它设为目标，否则工程师会认为这些目标以及后面的功能需求都是你拍拍脑袋定

    的。他们不喜欢这种随意的需求，就像他们不喜欢随意定下的交付日期一样。你

    要慎重对待这件事情。

    如果说目标是告诉别人你要做什么，那么非目标则是告诉别人你不要做什么。所

    以设定非目标非常有用，那些持不同意见的人能通过非目标来理解你为什么会这

    样规划产品。例如，你的设计团队如果担心你定义的产品必须拥有键盘才能正常

    使用，你可以告诉他们：“移动端和无键盘支持是非目标。”

    2.6.3 用例或用户场景

    有些人把用例和用户场景分开单列。用例是指用简要的语句来描述那些用户必须

    执行的操作，用户场景则是指用叙述故事的方式来描述用户是如何体验产品的。

    下面是一个Google+ Hangouts的用例：

    用户能共享屏幕

    再看一个更有意思的用例，它包含了上述用例：

    当用户试图共享屏幕时，如果其他用户正在共享，该用户会收到系统让他确

    认是否替代目前正在共享的其他屏幕的提示。

    用例描述非常精细，你不加思考便能读懂，工程师也能根据用例准确地判断该做

    哪些工作。因此用例(或者用户故事)在敏捷开发中发挥着巨大作用，每个核心

    任务都会描述成一个类似下面结构的用例：

    作为视频聊天参与者之一，我希望能【共享我的屏幕给其他视频聊天参与

    者】。

    这个敏捷模型强调的是用户类型与用户行为，在实际工作中非常有用。当用户行

    为趋向复杂时则更适合使用用户场景。例如，如果将Hangouts的用例重写成用户

    场景，你会发现开发者对预期的用户体验会有一个更好的理解。

    乔迪希望共享她的屏幕。她点击了“共享屏幕”按钮。系统弹出提示要她选择想要

    共享的窗口或者共享整个桌面。每一个选项都有窗口预览图和标签描述，并且预

    览图是实时的，就像一个个小视频。当乔迪点击了其中一个选项后，她的屏幕就

    成功展现在视频群聊中了。但如果有其他人正在群聊中展示屏幕，系统会弹出提

    示：“瑞克正在共享他的屏幕，你想替代成你的屏幕吗？”如果乔迪点“不”，她则

    回到初始状态；如果乔迪点“是”，瑞克的视频界面将会切回到他的摄像头，乔迪

    的屏幕将会显示在群聊中。

    无论是只写用例还是只写用户场景甚至两者都写，你都需要敲定它们的优先级。

    这样工程团队才能给工程任务定优先级并优化设计。说到优先级，我曾听亚马逊

    一个高管这样评论道：“优先级就是个扯淡的事!”离这种高管远点吧!如果不定

    优先级，资源有限的工程团队如何能够裁减功能以赶上发布日期呢？所以优先级

    非常重要!谷歌和亚马逊用的是相同的优先级规则，共分4级：

    P0

    没有该功能产品无法演示。

    P1

    没有该功能产品无法交付。

    P2

    锦上添花的功能。

    P3

    哈哈哈!

    P3的功能基本上要被裁减掉，甚至P2的功能也在裁减候选名单中。由于这套优先

    级规则也适用于之后的Bug处理，你的团队将开发出一套通用的词汇表和标准。

    衡量功能或Bug的重要性与紧迫度通常很难，因此建立通用的分级标准并尽早对

    它们进行分级是非常有益的。参考第5章了解更多关于优先级在交付后续阶段的

    应用。

    有时候你认为一些用例无须在版本1(V1)中实现，但团队成员又认为它们比较

    重要时，可以给这些用例加上V2的前缀或者其他标签，让他们明白这些用例会在

    V2中安排处理。其实P3差不多就是V2，但列成V2的好处是让所有人都知道这个

    用例在V1中是不可能做的。但不管用例是放在V2还是放在V1中，你都需要现在

    就把它们描述清楚，这有助于工程和设计团队构思一个具备良好扩展性的系统，同时也有助于你少回答一些“呃，不过要是出现这种情况……”的蠢问题。

    2.6.4 原型图或线框图

    由于正在遵循一个行之有效的产品定义过程，因此你已经绘制了一些粗糙的原型

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

    2.6.5 API

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

    2.6.6 负载规划

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

    对工程团队来说非常重要。他们会根据你预估的使用量来确定哪些地方需要添加

    缓存，哪种类型的服务器和存储需要准备，哪些授权问题可能产生，等等。

    预估使用量是件极其困难的事情。我曾在一个发布会上听到一个Xbox Live的负责

    人讨论他们的负载规划。他说他当时选了一个他觉得能在首年达到的最大值，结

    果他们最后做到了这个值的两倍。这在产品上是一个巨大的成功，但对他们的负

    载能力却是一个严峻的考验。

    Xbox预估的负载量虽然过高，但这并不是说它的方法彻底错了。在亚马逊和谷歌

    都是依据类似的方法来制订负载规划的。首先你会建一个表格来制订年度或季度

    负载能力规划。然后你需要预估存储量(帖子数量、图片数量、图片大小等)和

    流量(访客数量、访客停止时间、人均页面流量数)。在谷歌你还需要预估出口

    流量(从数据中心获取的数据量)和进口流量(你的服务器请求量)。包括亚马

    逊网站在内的大部分应用的出口流量都远远大于进口流量。但如果你构建了一个

    用户可以上传图片、视频或者其他内容的应用，你的进口流量就会非常大，所以

    请根据实际情况制订负载规划。

    你需要维持适当的余量并预测一个余量值，这个值可能并不准确。例如，你可以

    这样说：“我设想需要100%的余量来应对超出预期的增长。”

    你需要预估日均峰值，通常预估为均值的3到4倍是安全的，因为这个值代表了美

    国不同时区用户的重叠峰值。如果你的产品与众不同，比如是一个设计成开机启

    动的软件升级系统，你的峰值则会远远大于均值，所以请根据实际情况调整预估

    数值。

    如果业务面向全球，还需要考虑如何缓解延迟问题，是部署多个数据中心，还是

    使用阿卡迈(Akamai)等公司提供的内容分发网络(CDN，Content Delivery

    Network，也称为边缘缓存)。

    你需要制订预案以应对突发的高峰，比如在产品发布时期剧增的访问量。这时期

    的用户行为极为不同，你需要采用不同的应对计划。比如当《60分钟》 6

    报道了

    你的产品时，你该如何应对突增的用户量呢？我在一家创业公司时曾经历了这样

    的事情，不过好在尽管延迟增加、网页做了分页处理，但产品始终是可以访问

    的。虽然并不完美，但至少我们扛住了。

    1《60分钟》是美国哥伦比亚广播公司(CBS)主打的一档电视新闻杂志栏目。——译者注

    你需要制订备用策略以应对最坏的情况。一次分布式拒绝服务(DDOS，Distributed Denial-Of-Service)攻击、一篇《华尔街日报》的报道或者一次数据中

    心故障都可能置你的产品于最坏的境地。不过灾难并不可怕，可怕的是你没有任

    何准备。你应该适当部署一些有效的危机管理系统，如流量限制系统、“系统目前

    繁忙，请稍后再试”的出错页面或者保存在CDN上的应用静态版本。

    你可以在撰写负载规划这节时与工程团队就系统设计进行充分的讨论。你需要了

    解当系统过载时是部分彻底不可用还是整体被拖慢？系统是支持纵向扩展(指你

    每增加一台服务器，你就能获得这台服务器的负载能力)还是非线性扩展？

    总之，关于负载规划你要做的就是进行合理的预估，你的工程主管则负责根据预

    估值来构建一个能稳定运行的系统。不要花太长时间在预估上面，只需花几个小

    时写个初稿，再找几个团队成员讨论下并将讨论出来的数值翻倍就大功告成了。

    2.6.7 依赖

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

    格定稿后你也应该发给各依赖方的负责人，让他们知道你需要他们的支持。他们

    可能只会阅读你的简介部分，不过这就够了，因为这部分已经清楚阐释了你要做

    些什么。

    依赖不需要描述得太详细，你只需简单说明我们需要这个依赖的原因以及依赖会

    受到什么影响，比如流量或者异常情况。例如当我负责Google Pack时，我列出了

    以下依赖：

    下载服务 (dl-eng@负责，m_@接口)：我们需要下载服务托管已签名的第

    三方二进制文件，我们会每两周推送一次更新，然后已签名客户端会通过

    HTTP请求有效负载，所以不需要大量的SSL流量。我们只通过SSL请求

    manifest文件，manifest文件会包含二进制文件的签名信息。我们会尽量避免

    临时的紧急的更新，但一年还是可能会有1至3次。

    2.6.8 FAQ和开放问题

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

    来，不过我建议最好保持FAQ的独立性，这样就不需要维护多个版本的FAQ了。

    2.6.9 关键事件

    你可能有一些硬性时间要求(比如苹果有它的世界开发者大会，又比如你的资金

    只能支撑到某个时间)，这些时间都需要放入文档。你最好能列出主要事件的达

    成时间，如特性完成时间、可信测试者版发布时间，如果具体的工程量尚未评估

    出来，那预计的时间应该保守一些。在这一部分应该把重点放在硬性时间而非工

    程事件，另外再放上项目计划(参考第5章)的链接。

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

    最困难的部分已经过去了。虽然你写的是一份没有人能全部读完的超级大文档，但每块内容都会有一些利益相关者关注，并且在写的过程中你也清晰地理解了产

    品的愿景。同时这份文档也是一份出色的职业材料，它会让你在未来跳槽时更受

    潜在雇主的青睐。目前一切都做得很出色!

    接下来你需要和团队一起细究文档以找到所有的问题。在这个阶段你可能不得不

    承受尖刻的批评并做好变更的准备。不要为此焦躁或沮丧，你应该趁此机会好好

    与你的工程、设计、业务团队磨合。没有人能在第一次就创造一个完美的产品，否则还需要团队干什么呢？所以深呼吸迎接挑战吧!

    你的团队将开始寻找边界情况 1

    或者极端情况 2

    ，即极少出现的产品行为或场

    景。不要抱怨这个看似繁琐的事情，如果不找出所有边界和极端情况，你就无法

    采取应对措施，它们就迟早会给你带来伤害，现实世界中尤为如此。

    1 edge cases，指在一个最大或最小运行参数下发生的情况。——译者注

    2 corner cases，指在多项运行参数同时处于极端水平下发生的情况。——译者注

    Motricity的资深项目经理、曾为摩托罗拉等客户管理过大型项目的艾伦·阿布拉姆

    斯认为，发现边界情况的最好方法是“漫步于功能之中”。确实如此，你需要时间

    来仔细地、创造性地思考用户会如何弄坏你的软件或者在某种意义上没有按照你

    的预期来使用软件。当你“漫步”时，请将想到的所有可能的边界情况以及应对策

    略写在FAQ或者产品需求文档中。

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

    划。最好的做法是在开始时就把产品需求文档发给开发主管、测试主管以及用户

    体验主管。如果有其他主管也对产品感兴趣，如客户支持、法务、公关等，也一

    并发给他们。

    文档发出去后，他们未必都有时间阅读你的文档(通常不止1个人没有时间)。

    你最好邀请他们开一个类似于设计评审的会议(第10章有更多关于设计评审会议

    的说明)，给他们充分评论这份文档的机会。这些主管经常会贡献一些富有启发

    的独到见解，还能进一步指出一些你需要应对的边界情况。

    第7步充满风险。一方面你必须承认并整合所有你的团队找到的边界情况，另一

    方面还必须捍卫产品的核心原则。如果产品有硬伤，你将很难得到工程团队的认

    可。而工程团队都不买账的产品，还指望你的客户会买账？工程师虽然看起来像

    一群穿着睡衣、无视专利的怪人，但并不意味着他们不能是精明的客户。所以你

    必须认真倾听并考虑他们的意见，同时尽你所能去说服他们，让他们相信这是一

    个令人惊叹的产品!

    如果团队认可你的观点则万事大吉，如果他们仍不认可，那么解决方案也很简

    单：重复第7步，从使命开始一步步想清楚问题到底出在哪里，然后调整产品规

    划直到他们认可为止。你并不需要团队的每一个人都相信你的规划是完美的，而

    是需要他们同意朝一个方向前进并把产品视作是一个极有可能成功的实验!一旦

    得到了团队这种程度的认可，你就可以进入第8步了。

    2.8 第8步：客户测试

    拿客户做测试听起来不像个好主意，但亚马逊和谷歌实际上都在这么做。他们会

    向部分客户发布一些实验性功能，然后监测他们的使用情况。除了客户测试，亚

    马逊还会专门雇佣一些测试团队，而谷歌则坚定不移地奉行单元测试(不是功能

    测试)。但尽管有这样那样的测试，产品出炉后依然会有大量Bug存在。不过我

    在这里主张的“客户测试”并不是让你马上把软件开发出来然后扔给客户挑刺，我

    主张的是去找一批现存的或潜在的客户，向他们介绍你的产品设想和原型，并听

    听他们的反馈。

    这个测试可以避免你做出一个没人想用的产品或者遗漏一些核心功能。谷歌高级

    副总裁艾伦·尤斯塔斯曾指出，团队会轻易陷入一场为莫须有的客户问题构建完美

    解决方案的狂欢中。所以你需要这个客户测试来验证你的目标、非目标以及优先

    级是否合理。

    有些人把这种测试叫做“焦点小组”，也有些人把它叫做“试售”或对现存客户的“路

    线图演示”。你的用户体验团队或许会认为这个过程是一次认知性遍历：客户通过

    你对产品原型图的介绍来体验产品，然后提供关于功能和实用性的反馈(后面有

    详述)。以上林林总总的叫法或做法并不重要，重要的是你去做了这个测试!所

    以在产品演示文稿准备妥当之后你应该马上安排持续3周、每周3至5次的面向潜

    在客户的产品演示。

    如果你手头没有现成的客户，那就让用户体验主管去做些基础性的用户研究：他

    会邀请一些潜在客户来体验你的产品，并通过面谈来了解你的产品是否适合他

    们。有时候用户体验研究者会在美国最热门的分类信息网站Craigslist上招募一些

    志愿者来参加研究，并提供100美元的亚马逊礼品券作为回报。如果与你共事的

    人中有市场营销人员，你也可以让他帮你邀请一批客户来参加测试。如果实在找

    不到客户，那么家人和朋友也可以，但千万不要让参加测试的人大半都是极客。

    举一个经典例子来说明为什么客户测试对你的产品方案如此重要。我在亚马逊曾

    负责一个叫做“实名制”(Real Name ? ) 1

    的项目。我们希望通过引入责任机制

    来遏制用户在评价中肆意吹捧或者抹黑商品。简单来说，就是在用户提交评价时

    我们要求他提供真实姓名，并要求他输入信用卡信息以验证名字真伪。目前在

    Amazon.com上还可以体验到这个功能。

    1 2004年纽约时报的社论“评价的评价”对该产品有更多描述：

    http:www.nytimes.com20040803opinionthe-review-of-reviews.html。

    在公司内部我们就方案的一些细节进行了激烈的争论，比如是否应该允许用户继

    续以假名发布商品评价。由于久久相持不下，我将这个问题抛给那些最频繁写评

    价的客户，当然会先让他们签署一份保密协议。那些客户在收到我们的问题后，表现出极其强烈的反对态度，甚至有一个客户直接给杰夫·贝索斯本人写了一封措

    辞激烈的邮件。杰夫非常关注客户的意见，于是这封邮件迅速让我们团队达成一

    致，允许用户在评价中使用真名或假名或两者都用。我事后意识到如果没有这个

    客户的反馈，我们一定会经历一次悲剧的发布。当然我不是说有了这个客户的反

    馈发布就异常顺利，事实上也没有特别顺利，但至少避免了因为执意要求每个人

    填写真名并进行信用卡验证而可能引发的更大危机。

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

    益

    到现在为止你的重心一直放在“客户是谁”“客户有什么问题”“我们该如何解

    决”上。这是真正正确的做事方法，只要你解决的是大众所共有的大问题，那么接

    下来的任务不过是小菜一碟。但如果你选择的是一个极小的利基市场，那么下面

    这些步骤会让你最终意识到你的错误。

    在这一步需要考虑的基本商业要素是产品命名以及产品能带来多大收益。当你向

    高管或投资者汇报产品方案时，需要一个确定的名称来确保你们讨论的是同一个

    东西。你还需要告诉他们产品能带来多大收益，从而使他们更认真地对待你的方

    案，而要想预估产品收益就得先给产品定价。因此现阶段你只需要考虑命名、定

    价和收益，像销售培训、营销方案、发布技巧等可以放在以后讨论，你的汇报对

    象当下也不关心这些东西。

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

    者可以让律师把关。事实上讨论名称是一件极其主观且争议较大的事情，能比它

    还夸张的也只有定价了。所以我建议你挑一个能描述产品是什么的名称就好了!

    这里举个谷歌的例子。Google Hangouts是Google Talk团队的产品。当初为了给这

    个产品命名，产品和工程主管开了不下十次会议来讨论到底该叫Google Voice还

    是Google Talk又或者其他名字，比如GVC。最后，谷歌负责社交产品的SVP维克·

    古多塔把它命名为Hangouts——他非常喜欢这个名称。这个例子提供了另一种产

    品命名的方法：把命名权委托给其他人。其实名称并没有那么重要，它再出色也

    不能帮你做成这个产品或者毁掉这个产品，所以不要浪费太多时间纠结于此，赶

    紧定一个!

    再谈产品定价。前面已经提到定价是一件比命名更糟糕、更痛苦的事情!它看起

    来很科学——毕竟里面包含了一堆数字——但最终大部分定价都是拍脑袋出来

    的。你和你的团队成员通常得花大量时间捯饬Excel模型中的各种定价公式，因为

    你可能发现即使半价客户也不会购买，或者高管认为使用产品应该免费然后通过

    广告赚钱，你于是不得不推翻原有公式并重新捯饬。我总是乐观地认为，如果你

    的产品好，你的客户基数大，你满足的需求真实有效，那产品的初始定价对长远

    成功有什么影响呢？所以这不值得你耗费太多时间。

    但也不能凭空给定一个初始价格，你需要讲出个所以然来。我不建议你花时间阅

    读300多页的深度经济分析报告，它们大多时候都毫无用处。你只需理解产品定

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

    软件业通常不适合按成本定价，除非你提供增值技术支持或售卖软件许可协议

    (SLA，Software License Agreement)。不过即使这样也不适合按成本定价，因

    为成本定价的一个最大弊端就是很难真正统计成本，比如投资成本、一线支持成

    本、工程支持成本、长远法务支持成本、市场营销等。也许你能通过记账来得到

    精确的成本，但那只是昨天的成本，你如何能知道明天的成本呢？

    如果打算按价值定价，可以去调研客户，看看产品在什么价位他们最愿意购买，在什么价位即使需要他们也不会购买。拿到这个数据以后，不管去问MBA还是去

    问高中生，都能得到关于最佳定价的答案。不过这个方法只是看起来合理，实际

    上并不具备可操作性。首先，你的产品还不存在，客户怎么知道是不是真的需要

    它？如果不知道是不是真的需要，他又怎么知道什么定价最合适呢？其次，客户

    很少会如实回答关于定价相关的问题，他们甚至还经常出尔反尔。让我们再看下

    一种定价方法。

    对比定价比其他两种方法要合理得多，但它有两个前提：1)有一个合理的比较

    目标；2)假定市场是弹性的，即产品会在价格下降时销量增加，价格上升时销

    量减少(很多产品都是这样的)。所以你得先在市场上找到比较目标。当你的产

    品比对手功能强大时，收费就高一些，反之亦然。如果市场上没有类似的产品，或者你的产品大体上算一个新产品时，对比定价就不起作用了。

    再给你一些针对高科技产品的宽泛的行之有效的建议。

    分析竞争对手。如果能够对比定价，你就有了一个好的起点。

    调研客户愿意支付多少钱购买产品，虽然他们不一定会说实话。如果你是对

    比定价，这个数据可衡量定价是否可靠。如果你打算彻底启用一个新定价，这个数据也可参考。

    简化初始定价以降低用户理解成本。Google Apps的价格分两个：50美元1年

    或免费(仅限10个以内用户使用)，而微软Live365的定价五花八门，让人眼

    花缭乱，莫非这正是他们的策略之一？

    把已经满足需求的定价再提高一些。等产品正式推出后再想涨价就难了。

    不要在定价上争吵不休。通常有些等级更高、脾气更坏的人会对定价有强烈

    的主张。我建议你立即做出让步，然后继续推进产品的交付，因为定价不是

    交付的全部——它只不过是其中一个小小的步骤而已。加油!

    有了定价之后你就可以建立收益模型了。我见过很多团队主管和高级销售卡在这

    个环节。等我自己做了这个事情几年之后我才知道为什么他们会被卡住：他们害

    怕拍脑袋的事情，而收益模型中50%以上的内容都是拍脑袋出来的。剩下50%中

    有一半是从那些免费的高德纳研究执行概要中剪切出来的市场研究内容，另外一

    半是一些凭直觉想当然的东西。那些市场研究内容可以给你的模型贡献一些数

    字，不过它们只是让你的预测从“拍脑袋”变成“科学地拍脑袋”。既然收益模型就

    是一个拍脑袋出来的东西，为什么我们仍然需要构建它呢？

    第一，不管是VC还是业务主管，你需要让他们感知到你规划的是一个多么重要的

    业务。因此你需要一个模型来向他们展示未来3年的月度收益预测。

    第二，构建收益模型能使产品设想具象化并证明产品机会有多大。收益模型包含

    了你的市场研究、你作为消费者的直觉以及一些数学运算，它们组合在一起可赋

    予你深刻的洞察力。你可能会惶恐地发现你设想的10亿美元收益实际上最好也不

    过百万——不过这不正是你需要的评估吗？

    第三，一个简洁的模型支持你任意调整变量并反复进行预测。你可以借此了解定

    价、支持成本、市场费用等各种财务维度是如何影响盈亏的，这有利于你做出理

    性的决策。

    所以你无需担心收益模型大部分是基于假设的，只需尽力保持它的简洁性。当你

    向其他人介绍这个模型时，如果他们质疑你的假设，那不妨根据他们的意见进行

    调整，毕竟你做这个模型的目的是争取资金支持以尽快开发出真正的产品，而不

    是预测未来。

    下面将教你如何构建一个非常简洁的收益模型。你可以从

    http:www.shippinggreatness.com 下载电子表格的副本。

    1. 估算买家总体市场规模

    (1)在我负责Google Talk时，通过估算企业在视频会议、语音会议以及长途

    IP电话上投入的费用，我发现这个市场规模极具吸引力。

    (2)许多消费性产品会向市场推出免费版，即你可以免费使用大部分功能，但如果需要更大的存储空间或更高级的功能或一些有用的道具，你得为此付

    费。这种模式的特点是优先考虑市场规模，后面再考虑付费转化。举个例

    子，假如Facebook的用户量为8亿多，那么它的市场规模也是8亿上下。

    (3) 分析报告能帮助你进行估算。如果做的是一个新产品，你可以从公开

    免费的市场研究摘要或者VC提供的报告中摘取一些数字进行估算。

    2. 预估市场规模的增速。它将是你的基线。当市场规模扩大时，你的销售规模

    也应扩大。

    3. 估算你的目标市场占总体市场的比率：

    (1)估算你针对的细分市场(比如小型企业、中型市场或者大型企业)占总

    体市场的比率。

    (2)估算你可触及的国家的市场规模占总体的比率。你的产品可能一开始只

    在美国推出，但世界那么大，扩展到其他国家将带给你巨大的价值。

    4. 估算通过市场推广你能触碰到的用户规模。你可以把预估的市场预算除以关

    键词的千人印象成本(CPM，Cost Per Mileimpression)来简单估算出该值。

    5. 预估触碰产品的人中会有多少转化成产品用户。

    6. 找到其他新用户增长渠道并加入到模型中。假设你的产品中有一套“邀请朋

    友”机制，你便可以预估它的转化率并加到模型中。

    7. 最后，将产品定价乘以每个时期增长的用户数便是收益了。如果产品是付费

    订阅类的，你还可以预估一个续费率然后计算利润。

    在下面这个简单模型中(图2-1)，我假设我们正在销售一款名为“愤怒的山羊”的

    游戏(嘿嘿，我们是“快速模仿者”)。它不需要付费订阅，但它提供了在游戏内

    需付费购买的道具，这是我们收益的真正来源。在我的第一版模型中，我设想用

    户可以这款游戏，然后我们依赖应用内购买获利。

    图2-1 基本收益预测

    我喜欢把可编辑的单元格标记为黄色(本书印刷版中会显示成灰色)以便快速识

    别模型中哪些是预估值而哪些是计算值。比如图2-1中的模型大部分数据都是预估

    值。这个模型告诉我即使占据3.4%的目标市场份额，“愤怒的山羊”这个游戏也没

    有多少赢利可言。你是否注意到我不是只预估了市场份额这一数值，我还预估了

    用户增长情况并将它同市场份额交叉验证。我认为这样做更加直观，它不仅告诉

    我们的用户会增长多少，还告诉我们这些增长从哪里来。

    在汇报“愤怒的山羊”这个产品方案之前，我们还需要回过头来思考一下我们做出

    的这些假设。我构建的模型对这些假设(或者叫做变量)非常敏感。比如，互联

    网广告获取新用户的成本是每个用户1美元，但实际上我花费1美元获得的是1.15

    个用户(假设病毒传播率为15%)。然后这些用户中20%的人会给我带来每人3美

    元的平均收入，或者说我能从每个用户那里平均获得0.60美元的收益。天啊!我

    的市场推广计划竟然导致每引入一个用户就净亏损0.40美元!

    幸好改动这个模型很方便，而且现在改动总比之后被新来的在线市场营销总监缩

    减预算要好。为了赢利，我预计要减少那些成本高但转化率低的广告投入。换句

    话说，我需要降低目前广告竞价的最大出价以使我们的广告在转化成本可接受时

    才出现。我还需要修改产品定价模型，把应用从改为需要0.99美元购

    买，这样做虽然会导致用户转化率下降(我估计最多50%)，但会为我们赢得更

    大利润空间。图2-2展示了我们改动后的模型 1。

    图2-2 盈利的基本收益预测

    1 作者实际上改动的不止以上各点，还包括：

    1. 图2-2中假定该版本不再只推向英文国家，而是面向全球，这使得目标市场的

    规模扩大5倍并且每季度的新功能发布会引来更大规模的用户。

    2. 图2-1中应用内购买总体收益是“用户数应用内购买用户占比 应用内购买平均

    金额”，图2-2中是“用户数应用内购买平均金额 ”，也就是说图2-2中应用内购

    买平均金额(2美元)的概念等于图2-1中应用内购买用户占比应用内购买平

    均金额(20%3美元=0.6美元)的概念，之间之所以相差了3倍多是因为付费

    购买应用的用户再购买应用内道具的可能性更大。——译者注

    现在就差不多了。我们正在缓慢增长。虽然没有加入运营成本，但单纯从产品视

    角来看我们是赢利的。接下来我们还需要进一步降低支持成本，目前约20%的收

    益都花在了这上面，对于一个游戏来说这太高了。更为重要的是我们还需要找到

    更多低成本扩大用户量的办法，比如病毒传播功能能否再优化一下？

    你可以清晰地发现该模型对假设是高度敏感的，这不是它的问题而是它的优点，因为它揭示了你的假设以及特定变量的重要性。一套合理的简洁的模型能帮你理

    清逻辑、明确核心指标、理解商业模式并最终赢得管理层的支持。但你仍需注意

    不要花过量时间在它上面——真实的用户和真实的数据永远比预测更有效。

    我知道有些MBA学员在看到如此简陋的表格时会不屑一顾。它确实很简陋，你还

    可以添加大把的内容进去。但实践的真相是你只是一个软件团队主管，且在这个

    阶段你需要更多内容来支持你进行聪明的决策。你只需要“科学地拍脑袋”，而这

    份电子表格能帮你很好地做到这点。

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

    如果是自己创业，那么你或许可以休息一下了，因为你可以自己批准自己的方

    案。除非你拿了风投，那就没有这么自由了，一个投资了1%的人也会认为他有资

    格知道你打算把他的钱用来干嘛，尽管那些钱他们赚得毫不费力。

    如果按照计划把产品卖给了你的开发团队，你就应该知道文档中存在争议或者谬

    误的地方并做了处理。为了让最后的产品汇报更容易一些，我建议你先花点时间

    预售 产品。在谷歌，最优秀的主管都知道怎么做这件事情，因为预售可以让管理

    层在公开回应你的产品方案之前先了解一些背景。在类似亚马逊和谷歌这种人人

    都极度繁忙的环境中，预售是一个非常有效的技巧。

    预售是一个非常直接的爬向食物链顶端的过程，为了让负责决策的高管最终认可

    你的产品方案，你需要预先争取中间每一级老板的支持，然后让直接向该高管汇

    报的家伙预先顺畅地了解你的产品概念。如果预售得不好，你可能会提前出局。

    更糟糕的是由于他们没有理解你的产品理念，自然也就无法准确地传达给最终决

    策的高管，而高管通常都是一边收发邮件一边和人交谈，所以他也没有心思仔细

    去探究其中的谬误，于是你会悲剧地发现你还没来得及汇报，高管就对你的产品

    留下了一些不好的或偏差较大的印象。

    还有一种预售方式是“路过式”预售。趁着负责决策的高管站在走廊或者倒咖啡的

    时候走到他身边和他聊一两分钟你想做的产品，这时候你追求的不是一个决策，而仅仅是让他知道有这么一个事，这样你之后的汇报至少会顺畅些，同时你对他

    可能有什么激烈反应也心里有个底。

    等到直接和高管汇报产品方案时你又得体会另一番折磨。以向杰夫·贝索斯汇报为

    例，我在亚马逊工作的时候坊间已到处流传杰夫是一个非常敏锐的细节帝。当你

    想做一个几乎全新的产品时必须得到杰夫的同意。我只向杰夫汇报过几次，虽然

    我很快就忘记了当时是怎么汇报的，但有一点我印象深刻，就是我从未有机会按

    正常顺序演示过我的幻灯片。杰夫会让你快速翻到后面去直接讨论方案细节。我

    在谷歌共事过的一位高管也是如此，不过他会在讨论细节一段时间后又要求返回

    到前面去看一下产品背景，而杰夫从不这样。

    这种不让你按常理出牌的情况会发生在谷歌、亚马逊、VC以及所有的给聪明绝顶

    的亿万富翁做演示的时候。不过VC还好一些，埃里克·施密特会在你演示时一直

    处理邮件，你都注意不到他的思维其实已经跳到后面去了。

    因此，在向这种位高权重的人汇报产品方案时，首先请确保你了解产品的所有信

    息。虽然你注定做不到这点，但你需要尽力做好一些。万一被问到一些忘记了的

    事情或者还没来得及去了解的事情时(比如事情发生在昨天而那时你在忙着准备

    演示)，不要试着糊弄过去，继续保持你英明神武的状态并回答他们：“这点我不

    是很清楚，我之后会去了解一下然后给您反馈。”记住，你面对的是一群高智商的

    亿万富翁，他们能轻易嗅到你的谎言，就像嗅到车里放的屁一样。试着按照你的

    方式去承认这个错误没有什么大不了的，这不过是向他们证明了作为一个菜鸟你

    无法理解他们有多么优秀。

    其次，他们想了解什么你就说什么。不要坚持你的顺序，带他们去了解他们想了

    解的地方。只要他们对你的产品理解是正确的，那就随他们的兴致，想看哪块就

    看哪块。当投资者们想要知道你这个产品能赚多少钱时，不要和他们说“嘿，我还

    没讲到那里呢，让我们先了解下团队每个成员的背景吧”，直接转到定价那页!如

    果你认为必须做一些铺垫，可以试着说：“我们马上就会谈到这个了，不过我希望

    先谈另外一些重要的事情。”不过说真的，还是直接转到定价那页吧，不要以为你

    对重要性的判断要好过这些家伙。

    最后，请阅读10.4节了解并实践“综述单页”法。那些亿万富翁都喜欢这个方法，因为它可以让你就最核心的部分进行互动交流且无需浪费时间在不重要的细节

    上。

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

    在这个点上你已经找到了一个覆盖面广、重要性高的用户需求，你还提出了一个

    独特的解决方案。你能通过产品单页或者10分钟的演示来介绍方案，也能凭借功

    能规格(包括FAQ、API和依赖清单)来讲述产品的所有细节。你还努力构建了

    一个简陋却令人振奋的收益模型，它正是你做这块业务的原动力。

    不过在庆功之前你还需要去见一些人。你要把这次见面看做是一次与意中人的约

    会，扣好衬衫，打理好头发，准备好风情万种的表情，然后去见他们，恳请他们

    的帮助。构建产品可是个艰难的部分，不是吗？

    我非常关注这一点。任何一个聪明一点的团队主管都能发明一个“策略”或者一个

    合理的产品方案，然后欢庆成功，因为这个环节衡量你成功与否的是你写下的文

    字和会议上许下的承诺。但你无法一个人就把产品构建出来，真正的难点已摆在

    面前：驱动你的团队在现实的重重困境中依然构建出可靠的软件。我应该告诉过

    你必须在正确的时间点完成开发吧？而且你还必须让你的团队喜欢你和你的产品

    吧？

    第3章 赢在用户体验

    用户体验不仅是产品的外观样式，它还是产品的使用方式。交付卓越产品就是指

    交付卓越的用户体验。人们若是不知道如何使用产品、不喜欢产品的外观或者找

    不到登录入口，这个产品就谈不上卓越。因此，就算你雇佣或借调而来的用户体

    验设计师再能干，你也不能把事情全部抛给人家然后坐等上线，你需要和他们通

    力合作以构建完美的用户体验。不过你的工作不是去解决所有的用户体验问题，而是确保产品尽可能提供最好的用户体验，这意味着你要让设计团队发挥出他们

    的最佳水平。

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

    可以从了解设计师的各种不同角色出发来了解设计。等你了解了每个角色是做什

    么的后，第二个需要了解的东西便是如何评估设计，了解了它你才能和设计师进

    行有意义的互动。等你了解了该怎么和设计师对话后，第三个需要了解的东西便

    是如何和每种设计角色有效地沟通，其中包括了解如何评论视觉稿以及如何向设

    计师提供反馈。第四个也是最后一个了解设计的要点是学会使用线框图或原型图

    来辅助沟通，你可以通过Photoshop或其他画图程序来绘制这些图形。

    3.1 了解各类设计角色：用户体验，用户界面，信息架

    构，视觉设计，用户体验研究……以及角色模型

    不同头衔的设计师专注的领域不同，即便头衔相同，设计师们也倾向于专攻某个

    细分的领域。因此尽管设计师可以处理你的任何需求，但你还是有必要了解他她

    更倾向于向哪个领域发展，然后相应调整你的期望。

    用户体验 (UX，User Experience)关注的是用户如何完成任务以及该如何优化向

    用户展现信息的方式。通常用户体验设计师会通过制作流程图或原型图来说明用

    户体验，其中原型图是用来描述用户界面某一部分外观的图形。有时候用户体验

    设计师会制作可点击原型 ，它由多张原型图组成，一些原型图上有可点击的对

    象，点击之后会切换到另一张原型图。可点击原型可以让你在有限的场景下模拟

    产品的使用过程，加深对产品的体会。

    用户体验设计师对信息架构 (IA，Information Architecture)尤为关注。不同于工

    程架构，信息架构研究的是信息该如何在用户界面中呈现，而不关心底层的数据

    结构。例如在一个确认订单信息的表单中，所有信息都是关联在订单号或者客户

    的电子邮箱地址上的，因此系统最关注的是订单号，而设计师最关注的则是用户

    必须完成的主要任务：提交订单。你通常可以提这样的问题来思考信息架构：“页

    面中最重要的信息是什么？”上面这个例子中最重要的信息是购买的商品及其数量

    和价格，而非订单号。信息架构专注于理解用户怎样才能接收到信息，而不是系

    统怎么才能正常运作。

    通常关于信息架构的问题没有绝对正确的答案，因此团队主管需要密切参与到设

    计过程中来。作为产品主管，你应该比设计师更了解用户，比如你要做一个棒球

    网站，你可能知道用户关心球队新闻甚过关心积分榜，这样你便可以与设计师共

    同确立一个新闻优先级高于积分榜的信息架构。

    用户界面 (UI，User Interface)是用户体验的旧称，它更关注单个页面或屏幕的

    设计，是用户体验的组成部分。

    视觉设计 (VisD，Visual Design)是关于如何通过一种既赏心悦目、夺人眼球又

    清晰明了的方式来展示内容的一门学问。视觉设计师往往具有较强的平面设计、排版和美术功底。他们根据既定的信息架构，使用调色板之类的工具增强或削弱

    信息在用户界面上的醒目程度。好的视觉设计师会基于栅格系统排列按钮、文本

    及其他控件以增强产品体验的一致性。这种通过在设计界面中添加固定间距的虚

    线来辅助设计的栅格系统为设计师提供了一套有序控制留白和内容的框架，从而

    提升了用户寻找内容的便利性和不同场景下用户体验的一致性。

    用户体验研究 (UXR，User eXperience Research)是用户体验的一个特殊组成部

    分，它专注于研究用户是如何看待你的产品的。用户体验研究者们擅长通过研究

    来获得关于产品成败的统计显著性数据，这些数据会提供给工程团队，虽然它们

    有些概念化但意义重大。用户体验研究者了解如何挑选参与者，如何构建一个有

    序且不带偏见的研究，以及如何指导用户在研究中避免带有偏见的反馈。不止如

    此，一个出色的用户体验研究者还会出具报告，说明用户体验中哪些部分有效哪

    些部分无效，这样的指导极富价值。遗憾的是用户体验研究者的工作并不包含提

    供问题的解决方案，这个任务落在你和用户体验设计师身上，不过要是他们有想

    法的话你最好听一听。

    “但是等等，”你也许在想，“我怎样才能从一组5到10个用户体验研究参与者中拿

    到具备统计显著性的数据呢？”答案是你可以通过比较所有提过的问题来建立显著

    性。假设共有5位参与者参与16项任务，其中15项任务都相同，只有1项任务不

    同，当参与者完成所有任务后，你获得的不只是1组5个不同的数据点，而是5×16

    个数据点，这样子显著性就建立起来了。如果你对这个逻辑有些怀疑，那也不奇

    怪，因为在选择个体参与者的过程中，你和用户体验研究者可能将较高程度的偏

    见带入到研究中，所以对个体参与者的评估需要慎之又慎。例如在我们位于西雅

    图的研究中，所有参与者会因为咖啡和阴雨绵绵的天气而显得敏感、忧郁，于是

    我们采取了一些措施来调整参与者的状态以避免可能的偏见。

    角色模型 (Persona)是一个由雅各布·尼尔森倡导并备受欢迎的方法，这个方法

    提供给你和你的设计团队、工程团队一个评估设计的框架。你的设计和业务团队

    将创建一组虚拟角色来代表目标客户，这些角色模型拥有姓名、薪水和目标，你

    还可以赋予他们任何你知道的目标客户的特征，然后利用这些角色模型来评估设

    计的效果。例如在一个度假规划应用中，你可能会这样思考：“保罗是一个高级用

    户，他每个月都在使用这个工具，所以他不希望每次使用时都需要重新输入他的

    出发地址……也许我们可以帮他保存这个信息？然后还允许他修改？”

    3.2 了解如何评估设计

    许多软件从业者在刚开始理解用户体验设计时都会觉得无所适从，尤其是那些纯

    工程或商业背景的人。大多数团队主管从未接受过设计师的训练，也从未想过要

    成为设计师，但他们却莫名其妙地背上了用户体验的相关责任，他们被要求确保

    用户体验是“优美的”或“直观的”，最可怕的是被要求“要像苹果公司推出iPhone时

    那样尽善尽美”!是的，我就曾被这样要求过。

    如果需要负责交付一套卓越的用户体验，你就必须问以下6个用户体验问题。你

    还需要理性、思虑周全地回答，以确保答案合乎情理。若能做到，你将最终收获

    一个设计精良的产品。记住在每次检查原型或设计时都要问这些问题。

    6个用户体验问题

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

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

    信息是否组织得当？

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

    标准是否一致？

    能否减少用户点击次数？

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

    面对一个新的用户界面时，你应该首先问自己：“主要角色必须完成的主要任务是

    什么？该用户界面要求主要角色完成的主要任务又是什么？”关注主要角色而非全

    体用户可以帮助你更好确定优先级。若以上两个问题答案一致，则设计是符合要

    求的，反之你就需要做些工作了。在某些用户界面下这两个问题很好回答，比如

    一些类似结账流程的界面，但对于棒球网站主页这类用户界面它们就不好回答

    了。你得通过充分讨论不同角色模型将如何体验这个用户界面，来找到这两个问

    题的答案。

    在棒球网站主页这个例子中，你可以这样思考：高级用户保罗和临时用户查克都

    希望知道最新的比分，所以在信息架构中应让比分信息最为突出。新用户爱伦可

    能希望关注某个喜欢的球队，但我们知道爱伦是有更强定制欲望的用户，所以主

    要任务不是允许用户在主页上快速完成定制过程，而是让爱伦能在主页上快速发

    现 有定制这样的功能。类似地，当高级用户保罗已经指定过喜欢的球队，我们必

    须给他提供一个快捷登录入口，让他可以登录查看他喜欢的球队信息，若已确认

    其身份，则应将预定制的用户界面呈现给他。

    在这个例子中，把握好多个目标之间的平衡并将之清晰传达给你的设计团队至关

    重要。如果你想为那些骨灰级棒球玩家构建一个应用，你通过市场调研已了解到

    这些人是一群技术控，并且他们想要一些强大的工具，那么你可以告诉设计团

    队，他们需要关注的最重要的角色是高级用户保罗，然后是新用户爱伦，最后是

    临时用户查克，因为查克可以通过其他各类体育节目获取他关心的球队的信息。

    但如果你的网站是纽约时报，你的绝大多数用户可能便是查克这样的临时用户，并且他们还大部分还来自纽约，因此你的角色模型按照优先级排列可能是：纽约

    的临时用户、其他临时用户、新用户、高级用户。

    与设计师沟通时千万别这样说：“登录按钮太突出了，减弱些吧。”也不要这样

    说：“将‘你最喜欢哪支球队？’这个推广信息移到顶部去吧。”我们要做的是清晰

    地阐述我们的业务目标以及它们之间的优先级，之后将权力交给设计团队，让他

    们以此为基础进行一系列的优化。

    还有一种可行的沟通方法是问一些直接的问题，如“为什么登录按钮在屏幕中

    间”。如果设计师回答：“我想让它非常明显!”你可以说：“你确实做到了!但我

    们的目标是优先满足来自纽约的临时用户的需求，根据我们设定的角色优先级，你做出的是正确的选择吗？”好的设计师会理解你的意思并相应调整用户界面。

    设计、业务和工程团队必须紧密合作，共同定义每种角色的优先级。如果你无法

    清晰说明优先级，设计团队将缺乏工作热情，他们只能机械地按照你的意思设

    计，你最终得到的也会是一个有缺陷的用户体验。因此在面对一个新的设计时你

    应该先问自己以下三个问题：

    谁是最重要的用户？

    这类用户必须完成的最重要的任务是什么？

    这个任务在用户界面中是最重要且最简洁的部分 吗？

    前两个问题是业务问题，它们为最后一个设计问题提供了背景信息。如果发现用

    户需要经历一系列复杂的步骤才能完成任务，或者需要折腾半天才能开启任务，你就必须停下来重新设计这块用户界面。如果这时候设计团队看起来没什么信

    心，那么很有可能是你要求他们兼顾太多相互竞争的优先级了，你需要返回去再

    次思考问题1和问题2的答案。

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

    用户完成任务的能力与该任务的复杂程度呈非线性函数关系。换成简单易懂的话

    来说：你对用户要求得越多，用户完成的能力和意愿就越低，而且低得不是一点

    点。问问你自己，你解决用户问题的方案是最简单的吗？如果用户想把一篇关于

    某个棒球运动员的文章通过邮件转发给朋友，他一定要先注册账号吗？你不能先

    让他享受到转发文章这个福利然后再引导他去注册账号吗？后面这种方式用户更

    为满意，而且还能省却不少步骤。当然它也会放大关于滥用的问题，因此你需要

    在这里做个聪明的产品决策。在这个例子中，过往经验告诉我们应首先着眼于可

    用性的优化，滥用的问题等它出现了再解决也不迟。我极少见到这种解决问题的

    方式失败过，而由于试着解决也许永远不会出现的滥用问题而导致产品开发步履

    维艰的情况我倒见到过。

    前田约翰在他的《简单法则》一书中提出了一个简单化的框架。他把这个框架称

    做SHE：简化(simplify)，隐藏(hide)和附加(embody)。与我之前的建议类

    似，前田主张“简化”特性，让用户只做他们必须做的，然后“隐藏”那些偶尔使用

    或者次重要的高级特性。其中一个隐藏这种复杂性的方法是把那些针对高级用户

    的特性放入一个叫做“高级选项”的对话框中，或者使用带收起展开箭头或“+-”符

    号的选项框把它们收起来，不过要记住它们在界面中必须是可发现的。

    如果一些特性可以用更简单的东西表达出来，你应将这个东西“附加”到特性中

    去，让它们并行展示。例如在T恤颜色选择器中，如果你只是提供一个文本下拉

    框，然后下拉框中每个选项都用文字来表达，用户就可能理解混乱。比如说当你

    看到“颜色：鲑鱼色”时，你会认为它是粉橙色(鲑鱼肉色)呢，还是银蓝色(鲑

    鱼外表色)呢？这恐怕得取决于你是否是一个素食主义者了。而解决这个问题很

    简单，你只需要给每个选项附加一张该颜色T恤的图片就可以了。

    3.2.3 信息是否组织得当

    有时候你想展示的信息会有多个行动点，你需要让它们保持平衡。亚马逊的产品

    详情页面便是一个经典案例。这张页面上的信息虽然数量庞大但组织优美，几乎

    所有内容块都统一按照它们的收益能力排序。有些特性的直接影响很难评估，如

    客户评价，它们被放到了页面底部。有些特性则很容易评估，如“看过此商品后顾

    客买的其他商品”，它被放在靠近页面顶部的地方。

    在实际工作中你可能没有这样一个衡量指标来使你的设计变得简单(但工程师们

    却要头疼不已)。你需要深入思考你的数据和特性该如何合理组织起来。为了做

    到这一点，你应遵循以下条件。

    最重要的客户类型最关注的信息应该最突出。

    信息的排列方式应该像报纸文章那样从标题到摘要一一排列。

    信息应该尽可能个性化且实时，也应在合理的前提下尽可能详细。当你能提

    供“销量排名：1327”时为什么只提供“销量排名：前1000”呢？用户喜欢适度

    精确的信息。

    最常用的控件出现在最容易找到的地方。

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

    当识别出了用户最需要完成的核心任务后，你需要问问自己这些任务是否是可发

    现且可理解的。可发现性 是指用户发现行动点的能力。以“加入购物车”这个行动

    点为例，如果你的用户连“加入购物车”的按钮都很难找到，你这份工作也别想再

    干下去了。同样的道理，要是在你的负责下出现了用“+”号按钮来表示“加入购物

    车”这种事，你的设计不会通过可理解性测试，而你则会被扫地出门。

    解决可发现性问题的方法有很多，以下为三种常用方法，你可以做些尝试。

    1. 定位

    在西方文化中信息的优先级是从左上角向右下角递减的。如果你想把行动点

    放在最显眼的地方，你很可能需要把它放在内容的左上角。

    但这个原则也有一些关键的例外，其中一个便是“广告盲区”，由于用户总是

    发现网页顶部中央会放些“打猴子” 1

    的广告，以至于会习惯性地忽视那个位

    置的内容。同样有很多网站会采用左导航的设计方案，如果你把基于上下文

    的行动点也放在左导航那个位置，也可能被用户忽视。

    1 类似于国内某些网站在页面顶部放的网页游戏类广告，因此国内用户也存在这个“广告盲区”——译者注

    你可能曾听设计师说某某视觉元素是在“一屏以下”。这是一个老式印刷术

    语，指一些新闻报道位于报纸的下半部分，而由于摆在报摊上的报纸都是折

    起来的，所以这些新闻报道无法被一眼扫到。在网页浏览器中，折线位于浏

    览器与屏幕下方边缘交界的地方，在主流屏幕中浏览器从顶端到折线这一区

    域高约600像素 1。iPad、Android以及其他一些设备由于屏幕分辨率不同而使

    得折线位置也不同。如果一项内容不在折线以上，那么它的可发现性就会急

    剧下降。

    2 浏览器从顶端到折线这一区域其实就是网页打开后在屏幕中的可视区域，其他区域需要滚动鼠标向下拉

    才可看到。——译者注

    2. 视觉设计

    视觉设计能有效解决可发现性问题，你可通过改变元素大小，使用差异化配

    色，或者跳出栅格来使你的行动点变得易于发现。不幸的是，视觉设计同样

    也会催生很多问题。我们知道让事物变美观的一个最好的办法是让它们简

    洁、平滑，比如说把汽车的门把手抹平。车子固然美观了，但车门也无法打

    开了。所以你需要特别注意那些华而不实的视觉效果，它们会削弱可用性和

    可发现性。

    3. 惯例

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

    歌地图中，街道是用制图学中规定的白色和黄色来标注的。如果你的设计师

    把湖也标注成白色，这将产生混乱。同样，如果你随意对调对话框中“确

    认”按钮和“取消”按钮的位置，用户就会不断点错。因此，要想将软件做好，你需要让设计师先阐明惯例，并之后通过检查来确保他们始终遵循。

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

    用户来测试。可用性测试可以告诉你用户能否发现你的行动点。另外，你可以通

    过利用Google Analytics这类工具监控目标点击情况来衡量转化率，还可以通过部

    署AB对比实验来了解哪种设计的效果最好。

    3.2.5 标准是否一致

    惯例提供了某种设计上的简捷性，利用它，用户几乎能在你的用户界面中跳跃向

    前。例如Mac界面中“确认”按钮总是在用户界面的右下角，所以用户可以直接点

    击按钮而无须阅读按钮上方的文案或按钮的名称。但郁闷的是PC并不遵循该惯

    例，它的“确认”按钮位于右下角“取消”按钮的左侧。因此对于网页应用来说这个

    惯例就没有意义了。不过你最好确保你的应用程序中按钮始终位于同一位置，特

    别是当它们运行在iOS或者Android上时。

    这里有一些惯例，你可以利用它们来使用户界面更易于理解。

    所有主要按钮都应尺寸放大且配色一致。

    一个用户界面中只有一个主要按钮。

    使用一组按钮来表示“是”或“否”这样的选择。

    不同优先级的行动点使用不同的样式。例如在Amazon.com上有“立即购买”按

    钮(主要行动点，我们唯一期待的)和很多较小的“了解更多”链接(次要行动

    点)，其中按钮要比链接明显得多，而且全站都遵循这个惯例，包括“你的账

    户”页面，这使得亚马逊这套体系运作良好。

    当一个流程有3或4张页面时，告诉用户目前处于哪一步以及共有多少步。

    在你的应用程序中使用下划线或者其他配色来强烈区分链接和普通文本。

    遵守互联网CSS标准(如：鼠标划过链接时指针变为手的形状)。

    3.2.6 能否减少用户点击次数

    由于用户体验的大体流程已经确定，你可以着手去考虑如何减少用户点击的次

    数。比如你可能问自己：“我能把一个表单从两页合成一页吗？”用户必要的点击

    次数会极大影响用户完成这个任务的能力，亚马逊还持有一个与之相关的专

    利：“一键下单”购买(美国专利号：5960411)。

    你还需要仔细考虑用户选项中的默认设置。如果你的默认设置符合用户的需求，用户就可以少点击几次，同时也少遇到一些异常结果。设计师通常将默认勾选的

    复选框称为“退出框”，默认未勾选的称为“选入框”。

    另一个可减少点击次数的重要方面是减少用户在键盘和鼠标之间来回切换的次

    数。用户每次重新握上鼠标并找到屏幕上的指针都需要可观的成本。应尽可能减

    少这些切换事件。

    3.3 了解如何与设计师沟通

    设计师的工作很不容易，因为每个人对设计都有自己的观点。也正因这个原因，设计师很少会被当做专家来对待。然而要是把他们当做专家来对待，并专注于问

    一些得体的问题，你就能驱动他们交付一份极高质量的设计并帮助他们建立工作

    的主人翁意识。不过每个人都有不同的工作方式，设计师也一样。有些设计师会

    比旁人更敏感一些，有些设计师则要宽容许多。有些设计师也许乐于听到“感觉有

    点挤”这类评价，有些设计师要是听到你这样说会恨不得重击你一拳。所以请听取

    下方的沟通建议并做些变通，以迎合每一位独一无二的设计师。

    1. 以用户的口吻说话

    反馈意见时使用“作为【某种用户类型】我想……”这样的开头非常有效，Scrum项目管理方法就是使用这套句式来创建“用户故事”以指导开发者编

    码。

    2. 以提问的方式建立共识

    例如，你可能问：“iOS中后退按钮有什么惯例吗？这个惯例是一致的吗？”你

    的目的不是让他们详细地讲述这个体验，而是通过问这个问题来使双方建立

    对设计原理的共识，你的团队将根据这个共识来形成具体的设计。

    3. 反复讲述业务目标，如果有些目标相互冲突，则反复讲述它们之间的相对优

    先级。

    帮助设计师了解他必须解决的问题是什么。设计师们每天要做出上千个决

    策，他们根据自身丰富的经验来优化产品。你能够帮得上忙的便是确保他们

    能理解你的目标。为此，要将目标具象化。例如：“不应该要求大部分用户去

    滚动页面。因此，我们应该把输入框放在折线上方，对吗？”

    避免设置主观目标也能帮助你的团队。像“用户需要在应用中体验到家的感

    觉”或“它需要让人感觉更友好一些”这类目标会让我感到不安。你怎么知道你

    已经达成目标了呢？是在可用性测试的参与者表露出了这种感觉并还小憩了

    一会的时候吗？不要提这样的目标，你应该寻找导致这类设计问题的根本原

    因。例如：“我们正在要求用户在没看到任何价值之前就得在首页支付10美

    元。我们得想出一个替代目前体验的方案来，让用户先了解我们会提供给他

    们什么价值，而不是先填写信用卡信息。”

    4. 用数据说话

    统计用户点击数、浏览屏幕的数量和页面加载时间可使交流更为具象。应积

    极开展可用性测试。同上条一样，不要说些主观的东西，比如以“这感

    觉…”或“我喜欢…”开头的句子。

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

    与设计师分析竞争对手的体验将帮助你创建一套集大成的设计语言。你也可

    以让用户体验研究者去考察其他竞争产品，并分析行业内的最佳实践。

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

    有很多方法可以制作原型。其中一个最简单有效的方法便是在白板上涂涂画画。

    当你发现设计师好像在听你讲天书般茫然盯着你时，请转向白板画出你在讲的东

    西。你还可以进一步整理下你画出的东西，然后用手机拍下来。这些手机拍下的

    白板图画是非常强大的沟通工具，而且易于制作。我见过一些团队非常喜欢这些

    图画的风格，他们会把这些收集的照片制成视频动画。

    正规的原型有很多种形式，其中简单的一种形式是灰度线框图 ，它着重于文案、布局而非视觉设计，可用于展示你应用的结构。视觉稿 是一种更为精致的视觉原

    型，它不仅能帮助人们理解每个元素的视觉分量，还同时为你的团队提供了一份

    详细的页面规格，尤其是引入了红线标注 后。红线标注版视觉稿是一个用红色引

    线标注每个元素尺寸和颜色都十分细致的原型。最后一种主要的原型形式是可点

    击原型 ，它是线框图的扩展，也是构建成本最高的原型。可点击原型作用巨大，你可以在可用性研究中提供给用户使用，然后观察用户实际上会如何体验产品。

    当在文档或演示中需要借助原型来传达想法时，我会首先使用线框图，因为它们

    的形式最简单。如果在原型中添加了太多细节，如颜色、图片以及其他华丽的东

    西，你会发现一些负责评审原型的人会陷入到对这些细节的纠结中去。制作线框

    图时需关注以下基本原则。

    只制作用户界面中相关部分的原型。

    总是使用完整的、经过适当编辑的文本。

    控制花在视觉设计上的时间。

    使用灰度色，不要使用其他颜色。

    预期你的线框图会发生很大改动。

    当心视觉花招。

    只制作用户界面中相关部分的原型 例如你可以先制作一张完整的页面原型，后

    续只制作用户界面中发生变动的部分，如一个弹出的对话框和一个邮件验证通过

    的信息片段。这样做既可以节省你的时间，又可以避免创建出来的多个页面之间

    细节不一致，还可以免除每次调整页面时所需要的重复劳动。

    总是使用完整的、经过适当编辑的文本 文本或“文案”对解释界面的意图有着极

    为重要的作用。因此对于大段的文本你可以使用设计师常用的“这里有一段话”之

    类的文字填充，但对于任何表单、按钮、对话框或其他有意义的控件你必须使用

    准确的高质量文案。这类文案可以帮助你的团队正确理解用户界面中不同元素的

    作用。文案还是煤矿坑中的金丝雀 1

    ：如果发现需要写一大段文字来解释某个特

    性该如何使用，你就应该重新设计这个特性，因为用户可不会读大段的说明。

    1 金丝雀对一氧化碳、甲烷这类气体敏感，煤矿坑若是发生灾变，金丝雀会比人提早中毒死亡，相当

    于“生物报警器”。——译者注

    控制花在视觉设计上的时间 视觉设计、品牌、命名等元素都是主观的，与用户

    能否完成任务的关系也不大。不像文案，这些花哨的元素不会帮助你理解用户体

    验，要是你把它们添加到原型中反而可能产生关于样式的争论，而这种争论与你

    想要解决的问题一点关系都没有。你应该使用标签明确的占位符框来替代这些视

    觉元素，然后继续下一步。

    使用灰度色，不要使用其他颜色 一般来说色彩会加大线框图的复杂度，并催生

    与视觉设计和品牌相关的各种质疑。参见之前关于线框图的提示。

    预期你的线框图会发生很大改动 线框图非常适合快速沟通想法并可以促进讨

    论。当就线框图取得一致后，你的设计团队将开始构建高保真原型，但此时的线

    框图与你最初设想的会有很大不同。因此在制作线框图时，你需要考虑如何搭建

    才能确保后续能快速修改。当别人把你的线框图改得面目全非的时候你无需担

    心，这只不过意味着你正有力地推动着对话向前发展。

    当心视觉花招 设计与编码不同，它可以轻易地耍些花招来争取人们的认可。例

    如，使边角变圆或增加透明度会使事物更加美观。法务要求必须展示的退出框和

    法律文案会被轻易抛之脑后。为了网页或界面丰满用户会被顺手加上各种个人信

    息。当心这些花招。构建原型时需要同时考虑新、老用户分别会看到什么内容，同时确保设计出来的效果能够真正实现。

    如果幸好有一位设计师帮助你制作原型，也许就不需要知道这方面的知识了。若

    你还能为了拥有同理心而去了解一些线框图的基础知识的话，那真是再好不过

    了。但软件行业大部分的主管总会在某些时候需要亲自绘图，这时候，设计师们

    发明的一些不错的快捷制作简单原型的方法就可能对你有帮助了。其中有两个大

    部分设计师都在使用的简单方法。第一个是使用如只能在Windows中运行的Visio

    或只能在OS X系统中运行的Omnigraffle那样的流程图绘制程序来绘制线框图，第

    二个则是使用Fireworks、PhotoShop或者画图工具来绘制较小的、高保真的、基于

    现有用户界面的改动。两个方法都值得了解，我们会在后面一一介绍。

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

    我使用Omnigraffle制作线框图。它是一个非常出色的程序，在使用它工作的过程

    中你就能学到很多设计知识，它的创造者在塑造软件出色的使用体验上下了很大

    功夫，有不少亮点。Visio也能完成类似的操作，但它缺少Omnigraffle一些好用的

    功能。

    如果打算为用户体验的线性走查制作一系列幻灯片，你可能需要用到图层 。图层

    就像描图纸，你可以让其可见、不可见或按任意方式叠加。你可以利用图层来创

    造通用元素，如将一张空白浏览器的截图作为单独的图层移到堆叠的底部，这样

    该截图就会显示在所有其他图层中，你的线框图也就看起来像是显示在浏览器

    中。为了避免在制作其他图层时不小心编辑到这个图层，你可以将该图层“锁

    定”。图3-1中我创建了一个带标题的浏览器模板并将其锁定。

    图3-1 在Omnigraffle中创建图层

    下一次，为你将要演示的每一张幻灯片创建一个图层。换句话说，为每次点击或

    者用户体验中每个步骤创建一个图层。

    一个便于改动的基本线框图模板已经具备了，你需要扩展这个模板以继续增加它

    改动的便利性，比如可以增加一个通用头：创建一个新的图层，把它移到其他图

    层的最上面，这样它便能覆盖其他步骤(图3-2)。然后将其锁定以便于后面的操

    作。

    图3-2 在Omnigraffle中制作通用头

    现在你可以准备制作单个页面了。Omnigraffle之所以在制作线框图上如此出色，有一个很重要的原因便是因为它的模板特性(Visio也有类似特性)。模板是指一

    组可编辑模具(图3-3)，你可将用户界面元素拖入线框图中进行编辑。我使用了

    一个由Konigi出品的非常出色的线框图模板库，这个库中包含你可能会用到的任

    何元素。你可在这里下载它：http: konigi.comtoolsomnigraffle-wireframe-stencils。

    图3-3 Omnigraffle模板, 陈列着各类按钮

    将所有未锁定的图层隐藏，然后点击你想要编辑的步骤所在图层。将模板中的按

    钮、文本框、标签以及其他元素拖入到线框图中。

    如果需要增加注释，你可以给需要注释的元素添加红色引线标注或者先前提到过

    的红线标注。该功能效果很好，对吗？

    到现在为止我们关注的还是线性工作流，你也已经具备了制作演示幻灯片的能力

    了。但对于既定的任务，用户常常会有不同的处理方式，你需要说明这些异常情

    况。在这类例子中，你可以构建多个线框图并组合成流程图的样子。

    要制作一个基于线框图的流程图，你需要像之前一样先绘制线框图，但不用考虑

    图层。图3-4是一个Hello World应用的简单示例。

    然后添加第二步的线框图，用线把它与第一步连接起来，并各自标明是第几步

    (图3-5)。你可能需要再增加一些说明文字来解释发生了什么。

    图3-4 流程式线框图，步骤1：绘制第一张线框图

    图3-5 流程式线框图，步骤2：连接线框图

    这里有一个值得优化的地方：第三步你可以只绘制一个对话框，而不是绘制完整

    的用户界面(见图3-6)。

    图3-6 流程式线框图，步骤3：绘制对话框，完成流程图

    Omnigraffle是一个强大的工具，使用线框和简单文字元素构成的设计不但有趣而

    且易于改动。如果想构建更加复杂精致的原型，你可以创建可引用的组件作为对

    象，使改动应用起来更为迅捷。为对象设置属性和脚本可以创建用于测试的可点

    击原型。使用Visio或Fireworks可以实现许多相同的操作，并且Fireworks还能导出

    已构建成型的原型。不过你的目的是清晰快速地传达需求，这些高级的工具还是

    留给设计师们为好，你的原型应该保持简洁。

    3.4.2 快速制作高保真原型

    然而在某些时候线框图也没那么好用。或许产品改动很小以至于用线框图来表示

    显得麻烦。或许你真的需要彻底弄明白某些特性的重要改动点。像这类改动我倾

    向于使用Photoshop、Fireworks或者其他图片编辑器，因为比起使用Omnigraffle，我可以花费更少功夫做出一个高保真原型来。而且幸运的是，快速制作简单的高

    保真的原型并不需要你是一个Photoshop或Fireworks专家。

    比方说我们想要将我们的Hello World程序放在亚马逊首页顶部Kindle的下方。首

    先你要将需要改动的用户界面截图截下来，用你的软件(在这些例子中使用的是

    Fireworks)打开并调整画布大小以留出操作的空间。

    使用矩形选框工具将需要改动或者需要腾出空间添加内容的部分删除。为了插入

    一个新的选项，我把需要改动的部分切出来并向下移(指针停留在矩形选框上，按住Option和Shift键并拖动鼠标 1)。见图3-7。

    1 OSX中Fireworks CS6的快捷键为Command+Shift+拖动。——译者注

    图3-7 切开页面

    若要复制基本元素，需要先用矩形选框选中它，然后按住Command和Option键并

    拖动到目标区域。在这个例子中我打算复制Kindle这个条目。复制好了之后，再

    把Kindle文字所在区域删除并用合适的背景填充该区域和其他区域(见图3-8)。

    这里有一个小技巧，你可以继续使用矩形选框工具选中其他区域的背景色然后复

    制并粘贴到Kindle文字所在区域，而不是尝试使用油漆桶工具和橡皮擦。

    图3-8 复制和粘贴基本元素

    添加元素。如图3-9所示，我添加了Hello World元素和一个绿色的“NEW!”提示

    符。你肯定不会做这么愚蠢的事情。(杰夫也绝不会允许。)我估摸着使用了一

    个相近的字体，但你也许知道你的产品使用的是什么字体。或者你还可以审查元

    素的CSS!

    图3-9 添加你的具体内容

    清除下方空白并将图片缩放回正常尺寸。大功告成!(见图3-10。)

    图3-10 Fireworks中制作完成的原型

    这个例子本身微不足道，但你可以从中发现使用这个方法能让你在短期内制作可

    观数量的高质量原型。

    第4章 赢在项目管理

    随着产品开发工作的进行，你需要总揽项目全局以便协调其他团队、安排发布计

    划以及确保各依赖满足要求。你需要肩负起这种程度的项目管理，同时还不能落

    下其他任何需要完成的事情。时间变成了稀缺资源，这让你的团队忧心忡忡，但

    你的薪水却有机会蹭蹭上涨。作为团队主管，你无法依靠Microsoft Project这类工

    具使一个复杂的项目模型变得易于构建和维持，也无法通过增加兼职人手夜以继

    日地工作来使项目在更短时间内完成。要想在交付上取得突破，你需要低成本的

    项目管理。

    理解项目管理非常重要，所以我会在电话面试产品经理时问：“你如何知道产品是

    否可以按时交付？”坦白说，这是一个伪问题，从来没有人能真正知道产品是否可

    以按时交付。但你可以预估它。因此，我的问题可以回答得很出彩，只要这个回

    答包含三项低成本的工作。

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

    2. 跟踪Bug，观察燃尽图，计算实现零Bug率(ZBB，Zero Bug Bounce)的日

    期。

    3. 谨慎管理你的依赖。

    无论是在瀑布式还是敏捷式的开发过程中，这三项成本低廉的工作都可以起到很

    好的作用。虽然你共事的每个团队都希望用不同的方法来管理项目，但这三项工

    作是必选的。快速掌握它们能让你在项目管理上无往不利。即便做不到这样，你

    也能通过它们了解哪些方面真的需要改变了!

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

    你需要一张计划表来告诉你何时可以交付。一张简单的计划表只需包含任务列表

    和每个任务的工程评估量，这个量是指工程师或设计师完成该任务所需要的时

    间。你只需将这些任务按照他们认可的特性优先级排序并分配给团队成员，然后

    一张计划表就成型了。不要做其他画蛇添足的事情。

    你会想当然地认为项目管理很复杂。于是你会因为不知如何管理敏捷开发过程中

    的待开发特性而烦躁不已，或者你会寄希望于Microsoft Project这样的软件来帮助

    你管理项目。我也是在被这些系统折磨了数年之后才认识到，对我和我的团队来

    说，一张简单的Google电子表格就足以管理这些任务和评估量了。这张由我制作

    的电子表格包含了真正需要的所有东西。并且除了免费之外，你的整个团队还可

    以实时编辑它!你可以在www.shippinggreatness.com 上找到一个工作示例，如图

    4-1所示。

    图4-1 项目管理电子表格示例

    接下来将介绍这份电子表格的使用方法。你可以在www.shippinggreatness.com下

    载，然后根据需要来决定要不要按照下面的步骤使用。第一步，你需要和开发主

    管合作将各项任务填入到任务分解区域。计划内的假期也应当做任务填进去(计

    算余量时不包含这块)。下一步，评估每个任务在不考虑余量的情况下所需的剩

    余开发者日，并猜测哪个工程师可以承担这个工作。将每个任务都归属到产品的

    某个目标版本中。你可能知道这些版本被称为“迭代”，其实它们也同样是你的发

    布版本。余量假设和你大致需要的开发测试比(例如，每3天的开发时间需要测

    试团队1天的测试时间)也必须填写。开发测试比取决于测试团队的规模。在图4-

    1展示的这个电子表格中，我加入了一些计算规则，以确保任务的截止时间点不

    在周末。

    因为这个模型在评估时使用的是“理想”的开发者日，所以在评估任务工程量时不

    必考虑余量，但在评估发布日期时就很有必要考虑它了。余量是一个“容差系

    数”，用于容纳那些未曾预见的问题和一般的生产力损失所消耗的时间。一些团队

    判断五天的开发时间中只有三天是具备生产力的。剩余的两天则会发生各种各样

    的事情，最有可能的是一些联合会议、破碎的构建、配对问题以及失败的开始

    等。这些分心的事情根本无法预料，所以我发现60%的生产率估值非常合理。如

    果你的产品中有部分系统已经在运行了，你的效率甚至会更低，因为你要维护它

    们并服务现有的客户群体。早期项目则因为根本不存在什么Bug需要修复所以效

    率更高一些。还有一个关键的东西需要注意，这个60%的余量只假设了修复Bug

    的时间和不在计划内的私人事假，不包括计划内的假期。

    我还在电子表格中增加了“假定推送时间”这个字段，用来建议工程师们不要在周

    五的时候把新软件推送到服务器上，这个建议很有必要。你肯定不想在午夜时分

    拼命去把那些在酒吧里买醉的工程师们抓出来去修复一个关于隐私侵犯的问题!

    另一方面，团队成员也需要固定的发布日期，这样运维那帮家伙才会友好地协助

    他们完成推送。在这个例子中，我假定团队只在周二和周四推送代码。

    现在信息已全部填好，计划表也差不多成型了。下一步需要和开发主管来平衡每

    个人的工作量，并按照对发布日期的要求来调整各版本的任务数。查看电子表格

    的任务分配区域，你会找到那个剩余开发时间最长的工程师。这个工程师有时会

    被称为“长杆”或“处在关键路径上”。试着把他或她归属于V1的任务分配给其他不

    饱和的工程师。如果调整得当，你的工程团队的任务就会分配均匀，每个工程师

    的工作量就会相近。

    现在你的计划更为均衡了，你可以把注意点转向发布日期了。如果V1看起来需要

    相当长的时间才能完成，而你又想尽早推出第一版或者想确保每两周就有一个版

    本发布，你可以把一些任务从V1移到V2去。优先移走V1中那些最不重要的任

    务，将任务分解区域中这些任务的目标版本值从V1改为V2即可完成移动，然后再

    把团队内的任务分配调整均匀。检查发布日期是否处于假期，以免造成严重的团

    队工作中断。当一切看起来都没问题的时候，计划表就完成了!

    我喜欢这个表格，理由有很多。

    它是我制作的。永远不要低估这种自豪感……

    它便于你的团队更新剩余时间以及查看项目进展。谷歌文档中电子表格的可

    协作性还使得他们能在发现有遗漏的任务时立即添加进去。

    它便于发现长杆工程师。

    它便于配置或自定义。

    它便于跟踪假期，因为假期在这里也是一个任务。

    它便于挪动任务至后续版本。如果发现版本发布时间不满足要求，你可以将

    该版本中一些任务的“目标版本值”改成后续的版本号。你也能使用这个模型

    来跟踪里程碑。

    它还适用于管理项目最后30天的冲刺。

    它便于平衡团队内的任务分配。如果不想让克里斯在V1版本的关键路径上，可以将他的任务重新分配给维奇。

    它便于预测项目各时间节点，包括编码完成时间、测试完成时间以及发布完

    成时间。现在你的测试团队知道什么时候可以开始新一轮的测试，你的市场

    部门也知道这款产品什么时候可以面世。

    它预先将你的假设传达给了你的团队。

    “天”是一个很好的用于跟踪任务的度量单位。你也许常用“0.2天”来描述那些

    非常小的任务，但我发现跟踪这些任务的最佳办法是放到Bug列表中。

    虽然这张电子表格缺乏一些整洁的特性，如整合Bug跟踪系统或源码库，但这不

    是它的主要缺点，它唯一的主要缺点是无法跟踪依赖。我已经学会了如何处理这

    个问题，一方面是在每行任务旁边添加注释，另一方面是在每日例会上与团队进

    行讨论。

    当项目所有主体工作尘埃落定，整个团队都集中精力于修复Bug时，我会停止使

    用项目计划表并转而使用Bug列表和Bug燃尽图。我们将很快谈到如何创建并使用

    燃尽图。

    4.2 如何拿到评估量

    一些经理发现找工程师评估工作量是件纠结的事情。而且有的工程师会过高评估

    工作量，有的会过低评估工作量。你要是没有和这个团队共事过一段时间，你将

    无法知道某个工程师会估高还是估低。为了能更轻松地拿到评估量并减少工程团

    队高昂的评估成本，你可以尝试下面的技巧。

    1. 如果你不是工程经理，那么让你的工程经理去要评估量。

    这点毋庸置疑。

    2. 表面上接受评估结果

    如果评估出来的工作量太大(超过一个星期)，让工程师将这个任务分解成

    多个小任务。除此之外，向工程经理发发牢骚。

    3. 认识到你的权力

    如果你是工程经理，那么在评估这件事情上你是有绝对权力的。所以可以向

    团队承诺你会全力支持他们，而他们则要做出类似的承诺，即全力以赴支持

    项目。这很公平。所以放轻松点，告诉他们只要你还在这个团队你的承诺绝

    不会变。

    4. 只跟踪剩余时间

    我只跟踪一个任务还剩多少时间可以完成，其他如任务完成比例、任务评估

    用时与实际用时之比等我则毫不关心。评估用时与实际用时之比这个衡量指

    标，除了能识别出谁的评估最靠谱之外无法给你提供任何真正的见解，而你

    总要学习识别谁的评估最靠谱的方法。你还会发现缺乏经验的工程师几乎总

    是低估了所需时间，而富有经验的工程师则恰恰相反，因此你完全可以用这

    个经验法则来替代跟踪评估用时与实际用时之比。

    只跟踪完成任务所需剩余时间是敏捷管理的一个原则，我很喜欢这个原则，因为它着重于项目的实际情况，便于你发现项目何时可以编码完成。

    5. 要求不考虑余量的评估

    你可以在项目计划表中加入余量这个参数并把它明示出来，这样你的团队可

    以知道你为可能(甚至必定)出现的问题提供了时间上的补偿。我看到关于

    评估是否该考虑余量有很多信仰层面的争论，但上述是我见过的最清晰的做

    法。

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

    每周评估一次可以防止你的团队被你频繁打扰，并让团队成员有机会了解并

    告诉大家为什么开发会快于预期或慢于预期。这个过程还有助于识别谁的进

    度受阻。

    4.3 跟踪Bug并创建Bug燃尽图

    Bug燃尽图是一张反映你的Bug数量随时间变化情况的图表。它可以预测产品何时

    能够交付。制作燃尽图需要为不同严重等级的Bug各绘制一条其数量随时间变化

    的曲线。你还可能想要绘制一条描述Bug总量随时间变化的曲线。图4-2向你展示

    了一个示例的Bug燃尽图。

    图4-2 Bug燃尽图示例

    你应该期望接近编码完成时Bug数量会随时间不断增加，然后接近发布时Bug数量

    会随时间不断下降。这些Bug下降的比率，或者说这条曲线的斜率，被称作发现

    修复率。当发现修复率小于1，即每天修复的Bug数量超过每天发现的Bug数量

    时，你才能确定Bug的具体规模并精准地预测发布日期。

    当Bug发现修复率降到1以下时，你便能通过计算Bug数归零的日期来预测产品何

    时能够按照给定的质量等级发布了。在图4-2中，你会发现按照这样的Bug走势，我们可以底气十足地告诉大家，我们可以在10月31日发布内部试用版本之前，修

    复完成所有最最严重的Bug，然后在11月15日左右正式交付。如果你对测算出来

    的发布日期不满意，你只有两个选择：降低你的质量标准，或者增加工程人力以

    更快修复更多Bug。

    4.4 管理依赖

    管理依赖并没有什么秘诀可言。你唯一能做的便是将风险最小化，而最小化这些

    由依赖引发的风险有一些关键技巧，我称它们为“五个如果”。

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

    少做少错是不言而喻的。减少特性总是能减少你的风险。在产品的早期版本

    中，将某些特性改由人工实现可以消除风险。例如将开发客户支持申请表单

    换成直接提供一个客户支持邮箱(形式为mailto:xxx@xxx.com)，诚然这会

    增加一些工作量，因为工作人员需要理清楚客户想要咨询的问题，但你并不

    知道到底会增加多少的量，所以你应该推迟对该特性资源投入以减免风险。

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

    在谷歌一些最高效的团队，尤其是Android和Chrome，都强调要遵循“所有东

    西都构建在内部”的方法。事实上他们也是这样做的，虽然这会让其他人不

    爽，还会在某些方面拖慢开发速度，但它创造了一个允许高频率交付的环

    境。谁能抗拒交付的诱惑呢!

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

    把风险最高的问题放在最前面去解决，这样才能更早发现风险，更早采取适

    当的矫正措施，从而增强按期发布项目的信心。

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

    总有人会这样鼓动：“版本2的Foo会更加好用，它的开发团队也进展良好!

    计划用版本2吧，版本1实在是太丑陋了。”其实这样做基本上是不经济的。风

    险是交付的敌人。

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

    这条原则看起来有悖常理，实际上却很靠谱。你计划依赖的系统和产品总是

    在你眼皮底下悄悄地发生改变。例如一个你依赖的有利的业务关系会因为合

    作方雇佣了一个新的CEO而失效，而你根本无法预测这样的事件。因此，早

    点交付总能帮助你降低风险。

    第5章 赢在测试

    如果你交付的软件无法正常工作 ，卖不出去是一方面，更糟糕的是你会因此蒙

    羞。这就是为什么我会对任何打算交付的产品进行“高中蒙羞测试”。这个测试很

    有效。在高中年代谁没有因为荷尔蒙引发的冲动而留下过深深的心理伤痕，好莱

    坞等电影行业还从中挖掘从而产生了巨大的社会影响力。你也可以利用这些心理

    伤痕。你只需扪心自问：“我能确信当一个高中老同学看到我的产品时我不会感到

    羞愧吗？”这就是“高中蒙羞测试”的全部。

    这个测试能帮助你确保你的团队是快乐的。汤姆·德马可和蒂姆·李斯特在他们合

    著的《人件：富有成效的项目和团队》中指出：“伤害团队的一个最佳方法是要求

    团队成员去做一些他们并不引以为豪的事情。”记住，你的工程团队成员都有一帮

    高中老同学，别让他们因为你的产品而蒙羞。

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

    1. 坚持测试驱动开发。

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

    3. 亲自评审测试计划和测试用例。

    4. 自动化测试。

    5. 虔诚地推行内部试用(Dogfood)。

    6. 开展找虫总动员。

    7. 勤勉且有条理地处理Bug。

    8. 任命可信测试者以构建最后一道防线。

    做好以上8步能帮助你在交付卓越软件的道路稳步前行。接下来让我们深入讨论

    细节。

    5.1 坚持测试驱动开发

    谷歌公司洗手间的墙上张贴着一句类似俗套小广告的话：“调试过劳死，测试嗨翻

    天。”这句咒语充满力量。调试需要你去解构、分拆软件直到找到问题为止，这简

    直就是在通往交付的路上开倒车。测试驱动开发则可以帮助你确信你做的不是无

    用功，它还可以帮助你的团队在复杂的系统环境中生存下来，因为在你依赖的某

    个接口被其他工程师或团队损坏后，测试会立即报错。

    你可以参考其他资料以全面了解测试驱动开发(参见附录3)，这里仅简要描述

    测试驱动开发的过程。

    1. 埃迪工程师将代码分成多个片段，每个片段负责执行一些简单的操作。这些

    片段称为单元。例如，countToTen 是一个软件单元。

    2. 在写countToTen 这个方法之前，埃迪先写了一个测试，即单元测试 。大体是

    这样写的：If countToTen is equal to 10, then pass;else,fail.

    3. 单元测试写完后，他开始写countToTen 方法，如果索引在循环中意外失效导

    致countToTen 实际上输出的是9，测试就会失败。

    4. 当软件构建时，所有的单元测试会自动执行。

    挺简单，是吗？确实是，不过要想掌握它你还需要一些训练。测试驱动开发还有

    一个额外出色的点在于，发现回归Bug会变得更加容易，因为每个构建都会自动

    运行测试。你可以研究下JUnit(面向Java的单元测试框架)这类软件以实现自动

    化构建和程序验证。

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

    无论你的工程团队多么优秀、编写了多少单元测试，总是避免不了Bug的。找到

    这些Bug的最佳策略就是雇佣或者任命一位测试主管。测试主管是软件发布质量

    的主要负责人，同时也是产品经理、工程主管和市场主管的关键合作者。测试主

    管需要确保测试用例撰写准确、覆盖完整，且被正确执行。一个优秀的测试主管

    会不断培训缺少经验的测试人员并帮助设计优秀的测试自动化架构。如果你拥有

    一个真正强势的测试主管，测试团队的每个人都会减少妥协，追求完美，开发团

    队就不得不去创建更多更好的单元测试。

    不止如此，你在开始阶段就需要一名优秀的测试主管还有另一个关键原因。测试

    团队和工程团队的团队文化通常是不一样的。测试团队无时无刻不在想办法找出

    问题。如果碰到一个典型的能力不足的工程团队，测试团队会每天抱怨不停且难

    以排解负面情绪。测试团队和标准的工程团队在流程、规范和标准上也都不太相

    同。因此即便你把测试和工程团队融和得很好，也需要一个优秀的测试主管来帮

    助你管理测试团队，这对你有很大帮助。

    测试主管还可以帮助你解决在雇佣测试人员时所面临的特有问题。越是优秀的测

    试工程师越难雇到，他们中的大多数人在技术上都有很深的造诣，因此他们更愿

    意开发自己的软件而不是去测试你的工程团队开发的软件。有两个办法可以让你

    跳出困境：降低标准雇佣测试人员并聘请管理者去管理他们，或者按高标准雇佣

    外包团队。两个方法各有利弊，我更偏好后一种。

    5.2.1 选择一：降低标准雇佣测试人员并聘请管理者去管理他们

    我不喜欢聘请管理者然后让他去雇佣一群平庸的测试工程师。我坚信这种方式会

    建立错误的动机。它强调层级，并且你那个聪明的测试经理还需要花费大量时间

    管理那些平庸的执行者们。当然，有机会做管理者对一些人还是有很强吸引力

    的。

    降低标准雇佣测试人员这种方式还有更大的弊端，未来你是需要晋升这帮家伙中

    的一些人的。比如5年后，他们将认为自己有权晋升了，而你将面临一群二流的

    人才进入管理层的境况。常言道：“一流的人雇佣一流的人，二流的人雇佣三流的

    人”，很不幸它在软件行业是绝对的真理，你的生产力、产品品质将会因为雇佣了

    一群三流员工而直接下降。

    5.2.2 选择二：按高标准雇佣外包团队

    与外包测试人员一起工作会有些弊端。

    你需要一个开发主管负责与测试人员的联系。这会增加工程团队的成本。

    培训成本是沉没成本并且不可回收。

    能力突飞猛进的测试人员期满离开后可以把在这边学到的知识用在其他地

    方。

    但相比这些弊端，我认为它的优点更多。

    在人员管理层面，外包的组织成本比全职雇佣低。

    与外包商合作比与内部成员合作顾忌更少，你可以要求更快的速度、更高的

    产能以及稳定的质量。

    你不需要晋升那些三流员工。

    5.2.3 选择三：按高标准雇佣测试人员，不使用外包团队

    这不算一个选择。谷歌曾经尝试过，但发现雇不到符合要求的人，于是要么交付

    后还有Bug，要么工程师自己去做测试，项目到最后总是窘迫地收场。如果你还

    是要选择这个方式，那么后果自负。

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

    无论选择哪种方式组建测试团队，你都需要有人来撰写测试计划并且自己来确保

    测试用例的质量，这意味着你需要亲自评审并确认通过测试计划。

    一个测试计划由很多测试用例构成，这些用例是从你的产品需求文档中派生出来

    的。如果你的产品需求文档写得十分糟糕，你的测试团队就无法测试。但如果你

    把自己的工作做好了，你的测试主管就能把工作做得一样好甚至更好。

    测试计划通常是用电子表格创建的，因此你能方便地整理测试用例。检查测试用

    例是否包含下列描述性要素。

    1. 领域

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

    2. 严重性

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

    3. 前置条件

    前置条件指定了测试人员在测试前必须做的事情。比如测试购物车中信用卡

    验证过程，前置条件应该是用户已登录、购物车已添加货品、送货地址已填

    写，然后测试才能开始。

    4. 需执行的任务

    任务由多个步骤组成，是测试的主要内容。任何步骤失败测试都失败。

    5. 后置条件

    后置条件描述了应用程序在任务执行完毕后所处的状态。以上一个例子为

    例，后置条件可能是用户看到一个包含确认编号的确认页面，同时信用卡会

    在10秒内扣除相应的金额。

    图5-1展示了一个测试用例的示例。

    图5-1 测试用例表格

    如果时间不够宽裕，你可以每轮测试只执行高严重性的测试用例，这样虽然完整

    性有所欠缺但速度更快。这个方式也适用于验证一些微小的产品变更。你可以只

    测试发生微小变化的部分和高严重性的测试用例，这比全部测试一遍要省很多时

    间。在这里重新执行一遍高严重性的测试用例非常重要，即便你觉得这个微小的

    变更与其他特性毫不相干。你需要确保一些基本的特性不会意外停止服务。在单

    元测试覆盖率较低的复杂软件系统中，微小的变更很容易导致主要特性瘫痪，所

    以为了避免在老同学面前蒙羞，你需要防范于未然。

    一轮全面测试后的输出物是Bug列表，有时候这个测试结果会让人诧异。这个时

    候很关键，作为团队主管，你需要一边向团队强调“坏的消息就是好的消息”，一

    边大力表扬测试团队的努力和成果，毕竟你还需要测试团队继续鼓起干劲寻找错

    误。如果你的团队在每轮测试后都士气低落，或者测试和开发之间的关系势同水

    火，产品潜藏的Bug就会越来越多，而找到的Bug却越来越少，这样的产品要是上

    线，你就等着被羞辱吧。

    评审测试用例十分繁琐。你必须亲力亲为，即便只是为了维护与测试团队的感

    情。这里有一个小诀窍：固然坚持评审完所有测试用例是最理想的，且每一个注

    意到的人都会对你赞赏不已，但你也可以选择只关注以下三块内容。

    1. 用户体验

    确保测试用例覆盖了用户体验中最重要的部分，尤其是“新用户操作指引”流

    程和出错情况。

    2. 安全和隐私

    测试应该包括试图破坏你的网站。

    3. 依赖

    如果你依赖了一些非内部构建的数据库、第三方服务或软件，确保这些依赖

    将被严格测试。它们可能会在没有告知的情况下变更或损坏。

    如果测试计划覆盖了这些主要领域，你便有了一个良好的开端。

    5.4 自动化测试

    还记得聘请一个优秀的测试主管是多么艰难吗？应对这项挑战的一个最靠谱的方

    法是找到一位愿意编写测试自动化程序的测试主管。如果你的测试主管能够精心

    搭建一套独立于产品代码的测试系统，你的测试工程师们将受益极大。更为重要

    的是，测试自动化程序会不间断运行，干着数十人才能干完的活。

    你可能想：“哎呀，这得额外写多少程序啊!”不要担心，大多数测试自动化程序

    可以用脚本语言编写，它们也不需要多好的扩展性，而且还有现成构建好的框架

    可以使用，因此测试自动化的开发会更有效率。

    作为团队主管你可能不需要亲自编写测试自动化程序，但你需要确保它正被不断

    地构建出来，因为你永远负担不起完成测试工作所需的全部人力，但你负担得起

    运行测试自动化程序所需的全部机器。

    5.5 推行内部试用

    微软主张“欲卖狗食，必先尝之”的理念，意思是说你应该把打算推向市场的软件

    先在公司内部试用。换句话说，不要自己团队吃人食，而让用户吃狗食。强制你

    和你的团队使用自身研发的软件，体会用户的痛，能帮助你们逐步提升紧迫感，理解用户困扰。亚马逊和谷歌都笃信内部试用的理念。

    推行内部试用也会遇到挑战，特别是你要大家试用的软件已经有了一个比较好

    的、没什么Bug的替代品时。比如谷歌想让员工去试用谷歌文档，但大家都在使

    用微软Office，这时候解决该问题的最佳办法就是停止在公司电脑上默认安装微

    软Office，这不但能推动员工去试用谷歌文档，还能节省办公软件成本。

    有时候降低试用的门槛也能起到推动作用。比如亚马逊为了让员工试用亚马逊金

    牌服务(Amazon Prime)而专门提供了员工折扣。一些团队会提供T恤或iPad等奖

    品给报告不重复Bug最多的人。我曾经见到一个工程总监为了找到一个“非必现

    Bug”(heisenbug)的必现方法而提供5000美元悬赏。非必现Bug是指一种不按逻

    辑出现和消失的Bug，遵循海森堡测不准原则，这个Bug常常让人崩溃。总之，你

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

    在内部试用过程中你还会发现一个有趣的现象，即你的CEO经常会遭遇一些别人 ......