【谷歌和亚马逊如何做产品】交付为王

所有的流程和规范最终都是为了解决实际问题的,不要贸然引入流程,除非已经碰到问题,否则尽量简化流程,提高效率。


更新历史

  • 2023.04.28:完成初稿

读后感

本来以为是写做产品的,实际发现是做交付的,交付其实就是一种产品,里面给出了一些很不错的指引,可以时不时看一看。

读书笔记

不过在阅读此书时要注意一点,所有的流程和规范最终都是为了解决实际问题的,不要贸然引入流程,除非已经碰到问题,否则尽量简化流程,提高效率。要交付一个产品,其中最重要的只有3 点:1)确定用户需求和预期指标;2)以最小成本实现最主要的需求;3)发布并获得数据反馈,确定下一个迭代目标。建议从这个最小集开始,哪个环节出现问题,再参考本书引入相应流程,可能更有效。

只要精通交付,你就不用担心软件商业化会失败,也不用害怕与大公司展开竞争,因为你的市场嗅觉会更加灵敏,行动更加迅捷!倘若你因不懂交付而导致延期、发布产品时门庭冷落或苦心构建的产品无人问津,你的团队会变得急躁,你的客户会直接写信给你的大老板投诉,而你最好的结局是晋升无望,最坏的则是和你的团队一起卷铺盖走人,你们也终于可以有时间琢磨下简历或者亲自动手洗车了。

换个角度说,软件交付的过程一定会伴随痛苦、混乱、艰辛。直到游刃有余时,你才能感受到强烈的成就感。这好比在砾石球道上打高尔夫,如果你是新手,一杆挥毕,球不知飞到哪里。球童被你折磨崩溃了,你也不能幸免,整日在烈日下寻找那个正绝望地躺在某个石头底下的小球。

打造一款卓越的软件似乎并非难事,但事实往往不尽如人意。通常产品要么逾期交付,要么没抓住真正的用户需求,要么发布后还有一个又一个烂摊子等着去收拾。究其原因,很重要的一点便是我们不知道如何正确地组织交付过程。我们经常会舍本逐末,将关键步骤忘个干净,或者瞎冲乱撞,一头扎进琐碎之中出不来,以为凭借运气、加班加点和美好的愿望就能把产品成功推向市场。

有一套更为有效的交付过程,它分成7个阶段,任何团队主管都可按图索骥,收获成功与快乐。

  • 阶段一,确定正确的产品方向。如果总是设计垃圾软件,那么你永远不可能交付卓越的产品。好的产品一定要满足众多客户所共有的某个真实的需求。你的使命就是找到一种独特而有意义的方法去满足这一需求,并且在交付过程中的所有努力都应围绕着这个使命。例如,你应根据使命来制定产品切入市场的策略。一旦确定了使命和策略,产品定义就会更清晰,而不会沦为垃圾,因为它完全符合你出色的策略。
  • 阶段二,尽可能清晰详细地定义产品。这个过程需要10个主要步骤,包括撰写新闻稿、创建并不断更新FAQ文档、撰写功能需求文档等。完成这些步骤后,工程团队就会对项目形成统一的认识,管理层或投资者也会了解并认可产品的设计。这时候所有人都会异常兴奋,而你也可以稍作休息了。
  • 阶段三,设计用户体验。你需要从用户的角度出发,和设计团队不断沟通、反复迭代,最终构建出良好、直观、简洁的用户体验。你应不断提出问题,促使设计团队始终围绕着产品使命展开工作。你还应该让工程团队和设计团队保持密切合作,确保设计最终可被实现。
  • 阶段四,做一些基础的项目管理工作,不要太多也不要太少。当工程团队拿到详细的产品原型图和需求文档开始编码后,你就需要做一些基础的项目管理工作了,包括跟踪交付物的进展、指出问题以及控制项目范围。
  • 阶段五,开始测试。随着各个功能的代码块陆续提交,实际产品逐渐浮出水面,团队的工作速度将会提高,测试团队也将开始全心投入测试。这一阶段虽不需要多少创造性,却依旧令人兴奋不已。作为团队主管,你需要主导bug的处理并慎重决定哪些可以容忍出现在版本1而哪些又必须在发布之前修复掉。
  • 阶段六,你差不多可以准备发布了,不过在发布之前要清楚知道怎样才算成功,这就要求你建立一套衡量产品成败的指标。让团队利用剩余工时来把这些指标纳入监控并搭建产品状态面板。当产品bug趋近于零时你就可以准备监控产品发布效果了。记得买好香槟放在冰箱里以备庆功时尽情畅饮。
  • 最后,正式发布产品。发布一款卓越的产品可不只是上传一些文件到服务器上那么简单,你需要制订市场营销和公关方案,并在发布前仔细核查清单中的每一项内容。基本上每次发布都会有一些糟糕的事情发生,不过只要处理得好,大部分用户都不会察觉到。记得观察产品状况面板各项指标的走势,它会告诉你是否正走向成功。

除了获得财富和名望,成功交付的关键还在于快速且充分地满足客户需求。因此,你的使命就是解决客户的问题,你的策略就是找到一种独特的方法来满足这个群体或细分市场的共同需求。这听起来简单,理论上也不难。但就像赛车,理论上你只需在正确的位置刹车、转弯和加速就能赢得比赛,但实际上你很难做到这一点,让车子在跑道上发挥出最佳性能并不简单。同理,要想准确识别客户需求并围绕客户需求构建使命、制订策略也实属不易。为此你需要掌握一些特殊的技能,并对一些要点给予特别的关注

亚马逊CEO杰夫·贝索斯一直强调团队必须“以客户为导向,而不是以竞争为导向”,公司业绩因此持续攀升,股东也获益不小。他的观点非常清晰地揭示出这样的原则:团队应该始终积极地去解决客户的问题,而不是紧盯竞争对手,被动地做出反应。无独有偶,谷歌CEO拉里•佩奇也常说一句类似的话:“立足客户,向外拓展。”他的理念与杰夫相似,只是更为抽象一些。从拉里和杰夫身上,我们学到必须专注于解决真正的客户问题。 谷歌创始人兼总裁谢尔盖•布林对此也有些真知灼见。他多次提及:“不要只想着解决简单的问题,越困难的问题越值得去努力。”当把一个问题不断放大时,你覆盖的客户会不断增多,而问题的解决也会使更多人受益,这意味着你的潜在收益会更大,财富、名望、成功也就随之而来了。如果说拉里和杰夫告诉你必须解决真正的客户问题,布林会告诉你这还不够,你得确保这是个很多客户都存在的大众问题。

团队一定要有自己的使命。如果你没有清晰地阐述使命则会导致失败,因为你的团队、组织和投资人会根据自己对使命的不同理解而各自为战,从而导致冲突、混乱和痛苦。这种情况屡见不鲜。还有些团队不愿意清晰地阐述使命,他们害怕会因此陷入到使命是什么的争论中去,但这不过是掩耳盗铃,一旦人人都意识到自己和别人步调不一致,争论将不可避免地爆发。因此,只有尽早确立卓越的使命,才能真正从总体上减少冲突,解决这个问题。

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

  1. 能够唤起人们的兴趣。要想吸引人并使他们认同你的使命,最重要的是确保你的使命能够唤起他们的兴趣。只有长期吸引利益相关者的注意,你才有时间去挖掘产品细节。
  2. 提供言之有物且能指明方向的原则。你的使命应该能够指导你朝着哪个方向去努力。千万不要把使命定成“永争第一”之类小学生常喊的口号。通过在使命中指明方向,你将希望达成的结果清晰化了。
  3. 适合印在T恤上。你也许不打算把使命印在T恤上,但不妨试试看,人们会更容易记住它。而只有团队牢牢记住它,他们才能依照使命做出各种决定。

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

交付的下一阶段是让你的产品方案具体且可理解。通过制订使命和策略,你知道了你的客户是谁,他们的需求是什么。你也知道如何做才能比对手更出色、更具备差异性。有了这些知识再加上一些头脑风暴,便可以得出一个大致的产品方案。或者你像我们大多数人一样,老板会对你说:“那就做出来看看吧。”

当设法细化产品方案时,你会发现产品要解决的一些客户问题都是你主观臆断的,而且因为你的使命和策略都是建立在客户问题上的,因此这些主观臆断也混入了其中。我不想扫你的兴,但事实是你的这些臆断很可能是错的。这一点儿也不奇怪,亚马逊、谷歌和其他大公司都犯过这样的错误。所以要采用一些方法来证明臆断是否正确。即便它们十有八九是正确的,也要经过证明,而证明的最好方法就是把产品提供给客户使用,然后听听他们的意见。

产品定义过程主要分为10步。每一步都建立在上一步完成的基础上。其中有些步骤比较简单,有些步骤(比如撰写新闻稿)你可以只在首次迭代时进行(当后续的迭代都只是小的功能升级时),所以整体上来看产品定义过程没有想象中的那么长。

等到10步都完成后,你便拥有了一份定义完整、描述清晰的产品文档,你的工程团队也可以进入编码阶段了。

  • 撰写新闻稿。亚马逊喜欢这个不同寻常的第1步。新闻稿是一篇脱胎于策略的文章,篇幅不超过1页,主要用于促进各方了解和公开透明。你可能需要几天时间才能成稿。
  • 创建并不断更新FAQ文档。这份“活跃”的FAQ主要用于记录一些争议点和重要细节。你可以花1个小时搭建框架,然后在开发过程中以及上线后抽一些“业余”时间更新维护。你可以使用Wiki或Google Doc等现成的工具搭建和维护FAQ,这样可以节省费用。
  • 绘制线框图或流程图。线框图和流程图是产品的可视化描述,在讨论或答疑中使用可以让观点更明晰。绘制可能需要1天到1周不等的时间,鉴于这是最有力的沟通工具,还是值得投入这么多时间的。
  • 撰写产品单页或10分钟的演示文稿。产品单页是一篇写给高管或多数风险投资人看的产品介绍文章,你需要把控好介绍的详略程度。演示文稿和产品单页内容一致,只是表现形式不同。你可以花几个小时的时间写份初稿,然后收集一些同事的反馈并做修改,如此反复几次便可定稿,整个过程通常需要1~2周。
  • 在FAQ中添加API文档。 API是产品的第一个技术触角,在第6步会把它们全部整合到需求文档中。你可以先花数小时简单起草一些API,后续再在工程团队的帮助下完善它们。
  • 撰写功能规格文档。功能规格文档又名产品需求文档(Product Requirements Document,PRD,谷歌常用此名),或市场需求文档(Marketing Requirements Document,MRD,微软常用此名)。它是阐述产品各功能详情以及为什么要有这些功能的最权威的文档。你可以将新闻稿、FAQ、线框图、产品单页和API文档等内容粘贴到功能规格文档的不同章节中。除去这些主料,还需要添加负载规划、非目标以及非常见用例(用于清晰表述FAQ中各种非常见情况的用例)等佐料。
  • 产品的规模以及成熟度决定了你需要几天还是几周才能写完功能规格文档。如果产品尚不成熟,你应当尽可能缩小产品规模以快速验证客户需求的真实性。如果产品规模庞大且已臻成熟(如苹果的iPhone),你就需要一份健全的功能规格文档了。
  • 邀请设计团队和工程团队主管参与产品评审。这一步是为了获得项目组对产品的认可,并让他们帮忙寻找产品中存在的各种极端及边缘情况。你应该邀请他们一起评审产品,这样一天时间评审就可以完成。评审过程中他们可能没有贡献细致的反馈,但至少有机会去想一想你的产品方案,否则等到猴年马月他们也未必会读你的文档。至于如何让你的团队参与阅读和评审,你应该已经驾轻就熟了。
  • 找客户测试产品概念。在此阶段,你需要了解产品方案是否真正能解决客户问题。花一天时间做一次完整的认知走查1或花数天时间进行在线调研都是不错的测试方法。

第1步:撰写新闻稿

撰写新闻稿是产品定义的一个另类却有效的开始。它是由亚马逊 CEO 杰夫•贝索斯率先倡导的。所谓新闻稿是指一篇向市场宣布将要推出新产品的通告。不管是新闻稿还是博客文章,都应该简单明了地传达关于产品的关键信息。之所以选择撰写新闻稿作为第一步,是因为相比FAQ、产品单页而言,新闻稿的媒体属性注定了它天生就更简洁、可读性更强且更关注真实的产品能给真实的用户带来什么价值。 好的新闻稿包含以下六大要素:

  1. 产品命名
  2. 发布时间
  3. 目标客户
  4. 解决了什么问题
  5. 如何解决(务必简明扼要)
  6. CEO的公开赞辞

如果跳过了撰写新闻稿这步,等到完成后面两步时,你会发现仍然需要写一篇与新闻稿类似的文章,即产品单页。由于没有写作新闻稿这类面向客户的文章的经验,你会发现产品单页难以下笔,所以最好不要跳过第一步。但在某些情况下跳过这步又是合理的,比如是内部系统开发、产品特性改进或者处于一个新奇事物(如产品开发前的新闻稿)不受欢迎的公司环境中。

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

随着产品方案的不断细化,各种问题也层出不穷,其中大部分都非常重要,指出了产品的不足之处。我会迅速把这些问题记到一个内部FAQ文档中并尽我所能回答提问者。我喜欢那些愚蠢的问题,因为它们让我感觉好像没花多少精力就消灭了一个问题,这真是一种少有的乐趣啊。 如果觉得某个问题外部用户也会问到,我会把它记到FAQ文档的“外部问题”部分。通过不断添加新问题,这份文档将变成那些有疑惑的人寻找答案的动态更新的可信资源。

创建并维护FAQ文档有两大好处。第一,它能节省你大量回复邮件的时间,还能抵御一些内部责难。节省时间是因为FAQ已经回答了那些显而易见的问题,你就不再需要对每个问题都回复一封长长的邮件。能抵御内部责难(这点更为重要)是因为你很可能因为一些小问题上的疏忽而被问责,这时你可凭借细致周到的FAQ文档来证明你是尽职的,它会帮你浇灭大部分无谓的怒火。 第二,当你的客户支持团队和科技写作团队开始整理所有面向公众的内容时,FAQ将是一个很有价值的资源。由于你已经把FAQ分为了内部问题和外部问题两个部分,因此他们知道哪些内容可以公开。所以创建并维护FAQ文档是个非常出色的主意,在产品研发过程的诸多关键时候它都能帮你节省时间,比如在产品发布前你们团队还需要依靠它来完善帮助内容。

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

在FAQ中撰写问题答案时,你会发现其中一些答案用流程图或线框图来表述会更好一些,尤其是涉及用户体验(UX,User Experience)的细节时。确实如此,流程图可以帮助你准确地解释用户工作流和系统交互相关问题,简要线框图则可以帮助你具象化产品各环节的用户体验,并在之后的汇报中发挥不可思议的作用。除此之外,在白板或空白纸上画草图并用手机拍照也是一个沟通想法的好办法。

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

这一步你只需准备产品单页和10分钟的演示文稿,也可以两者选其一。在产品单页中根据需要来添加线框图或流程图就可以了,不必考虑它们所占用的篇幅。 在亚马逊,产品单页尤为重要。高级副总裁们(SVP,又称S团队)会围坐一圈安静地阅读你的单页,然后讨论是否通过。整个现场就像高考一样,身边每个人都想第一个完成考卷然后逃离这个充满诡异气氛的考场。但不管怎么样,这样的决策机制已经运作数年了。

面对VC时,两样都需要准备,因为你既需要发邮件介绍你的产品,又需要面对面做产品演示。不过无论你在哪里工作,这两份文档的内容都是一样的,它们都是新闻稿的延伸。下面介绍这两份文档所需包含的五个要素:

  1. 产品名称
  2. 目标客户 + 数量有多少
  3. 解决了什么问题 + 这个问题对于目标客户来说有多大价值
  4. 解决方案 + 这个解决方案类似线上哪个产品,为什么你的方案能让竞争对手在长时间内都无法模仿
  5. 何时交付 + 主要的里程碑有哪些?

团队背景(仅针对VC)

你会发现产品单页和演示文稿实际上是新闻稿的延伸,它们增加了市场机会(用户量)、收益机会(解决方案的价值)和长期竞争优势(对手长时间内无法模仿)这三方面内容。如果你还不能在产品单页中清晰地表述以上几点,请继续努力!

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

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

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

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

功能规格文档的读者一般为你的工程团队、设计团队,偶尔还有市场营销团队。功能规格文档包含以下九个内容块,按照先整体后细节的顺序排列,我将逐一详细介绍:

  1. 简介(使命和策略)
  2. 目标与非目标
  3. 用例或用户场景
  4. 原型图或线框图
  5. API
  6. 负载规划
  7. 依赖
  8. FAQ和开放问题
  9. 关键事件

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

你的团队将开始寻找边界情况1或者极端情况2,即极少出现的产品行为或场景。不要抱怨这个看似繁琐的事情,如果不找出所有边界和极端情况,你就无法采取应对措施,它们就迟早会给你带来伤害,现实世界中尤为如此。

第8步:客户测试

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

软件业通常不适合按成本定价,除非你提供增值技术支持或售卖软件许可协议(SLA,Software License Agreement)。不过即使这样也不适合按成本定价,因为成本定价的一个最大弊端就是很难真正统计成本,比如投资成本、一线支持成本、工程支持成本、长远法务支持成本、市场营销等。也许你能通过记账来得到精确的成本,但那只是昨天的成本,你如何能知道明天的成本呢?

如果打算按价值定价,可以去调研客户,看看产品在什么价位他们最愿意购买,在什么价位即使需要他们也不会购买。拿到这个数据以后,不管去问MBA还是去问高中生,都能得到关于最佳定价的答案。不过这个方法只是看起来合理,实际上并不具备可操作性。首先,你的产品还不存在,客户怎么知道是不是真的需要它?如果不知道是不是真的需要,他又怎么知道什么定价最合适呢?其次,客户很少会如实回答关于定价相关的问题,他们甚至还经常出尔反尔。让我们再看下一种定价方法。

对比定价比其他两种方法要合理得多,但它有两个前提:1)有一个合理的比较目标;2)假定市场是弹性的,即产品会在价格下降时销量增加,价格上升时销量减少(很多产品都是这样的)。所以你得先在市场上找到比较目标。当你的产品比对手功能强大时,收费就高一些,反之亦然。如果市场上没有类似的产品,或者你的产品大体上算一个新产品时,对比定价就不起作用了。

有了定价之后你就可以建立收益模型了。我见过很多团队主管和高级销售卡在这个环节。等我自己做了这个事情几年之后我才知道为什么他们会被卡住:他们害怕拍脑袋的事情,而收益模型中50%以上的内容都是拍脑袋出来的。剩下50%中有一半是从那些免费的高德纳研究执行概要中剪切出来的市场研究内容,另外一半是一些凭直觉想当然的东西。那些市场研究内容可以给你的模型贡献一些数字,不过它们只是让你的预测从“拍脑袋”变成“科学地拍脑袋”。既然收益模型就是一个拍脑袋出来的东西,为什么我们仍然需要构建它呢?

  • 第一,不管是VC还是业务主管,你需要让他们感知到你规划的是一个多么重要的业务。因此你需要一个模型来向他们展示未来3年的月度收益预测。
  • 第二,构建收益模型能使产品设想具象化并证明产品机会有多大。收益模型包含了你的市场研究、你作为消费者的直觉以及一些数学运算,它们组合在一起可赋予你深刻的洞察力。你可能会惶恐地发现你设想的10亿美元收益实际上最好也不过百万——不过这不正是你需要的评估吗?
  • 第三,一个简洁的模型支持你任意调整变量并反复进行预测。你可以借此了解定价、支持成本、市场费用等各种财务维度是如何影响盈亏的,这有利于你做出理性的决策。

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

6个用户体验问题

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

几乎所有的指标都可以通过一些巧妙的手法进行操纵。以之前举过的发布日期这个例子为例,为了将发布日期提前,我们可以将更多Bug归到“不影响发布”这一类去,也可以简单地终止测试(表面上看还是一个“双赢”的做法)。但实际上你和你的团队是不可能糊弄系统的,指标只是一个指示器,不是你的老板,所以请放心,你的核心指标是不可能被糊弄过去的。当指标变成了你的老板,你需要花费数天乃至数周的时间去为你指标数值的合理性辩护时,你就该换个指标了,或者换个工作也行。

万事俱备,只欠发布,不过发布可不只是把文件上传到服务器。这里有几个主要的发布步骤,遵循它们可以确保发布质量。

  1. 对改动说不。
  2. 开启作战室。
  3. 营造紧迫的气氛。
  4. 核查发布清单。
  5. 撰写博文。
  6. 发布软件。
  7. 亲自验证软件。
  8. 应对发布带来的各种影响。

你之前已经知会过危机扩大邮件组成员了,因此这个时候你的团队都了解目前发生了什么事情。不过你的老板还不了解,但是他们需要了解,因为他们不想在收到他们的老板转过来的用户投诉邮件时茫然不知所措。因此你需要将你老板的电子邮件添加到地址栏,拷贝下面内容到邮件正文并填写完整,然后点击发送。

各位团队成员, 我们正在积极解决关于_______(名词)的一个问题,这意味着__________(2句描述用户痛点的话)。 问题是在________(时间)发生的,我们预计会有______(用户数量)受到影响。 我们预计此次问题会导致________________(多少数据丢失或者多少收益损失等)。 目前________(工程师)和________(电话会议组织者)负责确定解决方案。他们下一步将________(动作) 我们预计问题将在________(时间)修复,除此之外,我们会先在________(时间,小于两小时)发布一次更新。 这是关于该问题的跟踪Bug:________(Bug编号),更多信息请直接查看Bug。另外,我们将召开电话会议讨论该问题,你们可以通过这些方式加入:________________(IRC3频道或者电话会议号码)

________________(你的昵称), ________________(你的正式职位和名字)

根据这些行业趋势以及你对优秀工程人才的无尽渴望,你终会有一天需要考虑与家乡之外的工程师合作。这很有挑战性,但你可以做一些事情来使生活更轻松一点。事实上有9件事情:

  1. 不要租用工程师——组建一支工程师团队
  2. 充分沟通
  3. 不要外包设计或PM角色
  4. 适应文化差异
  5. 构建清晰的需求
  6. 忍受时差,通过任何方式会面
  7. 委任得力的主管。
  8. 大量出差,或者完全不出差
  9. 与远程团队共饮

如果想快速交付一款卓越的产品,你必须会询问富有洞见的问题,会正确地引导方向,并明智地决定哪些事必须现在做,哪些事可以之后再做。你还要会评估和雇佣工程经理。因此,你对技术的了解程度最不济也要与对你车里的汽油的了解程度相当。知道汽油并不意味着你就会开车,但这意味着你知道车最好要加满油,否则你的道奇车就会变成一个超大号砖头。这就是你为了能开车回家所真正需要的全部关于汽油的知识。

虽然你需要足够专业才能做好这些事情,但我相信你并不需要有计算机科学学位才能交付卓越产品。只要你能理解我在这章讲述的系统方法,你就能做到这一点。事实上,我确信要是理解了这些东西,你就能游刃有余地通过谷歌、亚马逊、微软等公司主管级别技术环节的面试。如果你想顺利地通过面试或者从容地掌控产品开发过程,你需要了解四个S:服务器(server)、服务(service)、速度(speed)和扩容(scaling)。一旦理解了这四个基本元素,你就能够向团队询问恰当的问题了。

如何询问正确的技术问题

仅仅看过几页架构相关的内容并不能让你获得计算机科学学位。不要仅仅根据本书的说明就试图去设计系统,你会伤害到自己和其他人的。但你现在的知识已经足够向工程团队询问一些重要的问题并听懂他们大部分的回答了。那些还听不懂的部分则很可能是星球大战的黑话。你必须询问一些这类问题,它们会揭示出一些潜藏的问题并帮助你的团队想清楚他们的设计。你也许相信团队已经想清楚设计了,但考虑到他们眼中的“设计”是什么样,你会大吃一惊的。以下是一些可以询问的问题。

  1. 能请你给我画张系统图吗?
    1. 你的目的是理解系统图中所有方框都是干什么的。先从离客户最近的方框入手,询问它存放了什么数据,它干了什么,它接收和发送了什么数据。按照你的方式询问所有方框的情况,直到了解了它们都是干什么的。寻找我们这章讨论过的东西,如服务分离、服务链、索引和扩容。
  2. 结果从这个方框传到那个方框的延迟是多少?
    1. 你应该能通过通览系统图来识别出服务链,询问这类设计的必要性,并弄清楚整体响应时间是多少和最坏的情况下是多少。如果你发现图中有个地方的响应延迟非常长,询问怎样才能通过缓存、纵向扩容该服务,或将部分逻辑分到其他服务中去来提升它的性能。
  3. 可以扩容到N吗?
    1. 考虑到这本书将有很大概率帮助你取得无比巨大的成功,因此你必须扩容到的N也将是一个无比巨大的数字。想想当你使这个数字变得无比巨大时会发生什么。我把“无比巨大”定义为每秒有1万个请求,或者1亿条客户记录,抑或每天1百万个订单。那么你的工程团队需要干什么?增加更多的A方框就够了吗,还是需要打电话给Oracle并让老板签下一张无比肉痛的支票呢?去掉B方框有什么影响?
    2. 解你的系统包括了解它会如何出错并如何恢复(希望它能恢复)。确保自己了解到了系统的哪些部分会产生致命的错误,并让工程团队优先考虑对保证这部分的稳定性进行投入。
  4. 我们是围绕组织边界或系统边界来架构吗?
    1. 有时你会发现SOA反映的是公司的运营方式,而不是数据或应用程序的结构方式。而由于公司的组织结构不是遵照摩尔定律设计的,所以要避免这样的设计。当出现一些团队难以协作而导致多余的或不正常的系统被构建出来时,检查上面这一点并主动应对。
  5. 能通过缓存什么数据来提升性能吗?
    1. 我们花了大量时间在缓存上,因为它们很重要。它们能提升性能,提升稳健性并降低运维成本。识别静态数据和常规查询并讨论如何缓存它们。不要忘记询问关于缓存完整性的问题。
    2. 能通过独立加载什么数据来提升性能吗?
    3. 就像我们讨论过将回答服务和决策服务独立开来分别返回结果一样,你也应该询问系统的某些部分是否可以分离。例如,如果你能够单独加载广告,那么那些系统就可以完全独立运行,你的整个系统就更有弹性,即便广告系统坏了,用户也可以完成他们的首要任务。

作为一位出色的领导者,如果想让上司更认可你并获得更高的薪水,你需要不断向团队传递清晰的、具体的信息,使他们明确方向、坚守使命。你还必须做好向上管理,这意味着你要向比你更忙的、有更多邮件需要处理的人们传达与决策或进展相关的大小事项。因此写好邮件对你能否成功至关重要。写邮件最主要的目标应该是清晰、简要地传递单个信息。在亚马逊,人们普遍使用“清爽”这个词来定义清晰、简要的信息。注意到没有,亚马逊正试着用一个词来代表两个词(清晰、简要)——行动胜于千言!然而在谷歌,清爽的信息在个体贡献者中推行得并不是很好,因为这里的文化带点消极反叛,这时候你需要快速切换方式以迎合受众。你应从始至终精心撰写你的邮件,使其短小、具体、详实且清晰传递了单个信息。为了达成这些目标,我试着像记者写新闻一样写邮件。

像记者写新闻一样写邮件

拙劣的撰写人会这样写:我们发现名称查找服务直到14号才能准备就绪。除此之外,我们团队的两个成员(查理和萨莎)都得了流感,因此我们失去了两个星期的生产力。由于这些并非我们过错的阻碍,我们不太可能按期发布。

优秀的撰写人则会这样写:

汤姆和杰瑞,

我们必须将发布日期延后2周,即从8月7日延后至8月21日。我们不得不这样做的原因是: 工程团队有人生病,开发进度受到了影响; 我们所依赖的名称查找服务要到8月14日才能准备就绪。

使用精确增量表达法

精确增量表达法是一种让数字更易被理解的技巧,适合应对那些超快速阅读的人们。使用它很简单,只需将你的数字改成下面的格式:

将某个变量增加或减少XXX(差值),即从XXX(开始值)增加或减少到XXX(结束值)。

这个格式让阅读者知道发生了什么事情,即某个变量将增加或减少。那么多少呢?见差值。那之前是多少呢?见开始值。如果阅读者真正关心的只是最后的交付日期呢?他可以简单地跳去看结束值。注意到优秀的发件人正是按照精确增量表达法来表达他的更新的:

我们必须将发布日期延后2周,即从8月7日延后至8月21日。

如果你想试着做得更好,可以给目标加上开始时间、结束时间、总持续时间等基于时间的要素。新的格式将是这样:

在XXX(开始时间)到XXX(结束时间)这XXX(总持续时间)时间内,将某个变量增加或减少XXX(差值),即从XXX(开始值)到XXX(结束值)。

使用这种格式能让任何人都能快速看懂你做了什么,将产生多大影响,你将何时开始,何时可与你确认是否完成。你仅通过一句话就可以无歧义地表达所有事情。精确增量表达法就是这样一个能极大提升明晰度的有力工具。但它也不容易学会,所以在刚开始实践的时候会不舒服是正常的,不要气馁。它是那么简洁又那么强大,你值得努力去掌握。

分点阐释原因

优秀的发件人将他的逻辑依据从视觉上划分成多个点进行阐释,从而人们能够轻松发现要点。你的团队可能想阅读全部的逻辑依据,而VP若是对你信任有加,他会略过它们而只阅读你邮件的第一行。

如果你无法分点写出逻辑依据,而且原因还是你不知道要传递的关键信息背后的缘由是什么,那你的问题就大了。你最好不要发这个邮件,没有比冒然推迟日期但不知道为什么更白痴的行为了。如果你必须提供某种近况的更新,那么依靠你可悲而浅薄的知识勉强说些什么吧,但不要说些莫须有的东西。自愿承受后果并再承诺一个有事实依据的时间吧。

下面有五种你需要掌握的会议类型,排名不分先后。

  1. 团队会议。这类会议用来了解近况以及利用团队合力来深入讨论和解决特定问题。虽然团队会议中解决的大多数问题理论上通过邮件也能解决,但只是理论上而已,所以你还是需要这种会议来承担这些工作。
  2. 站会。站会是一种超级简短的会议,它只用来交流近况,促使团队内部信息透明、责任到位。在会议中每个人都站着,这样可以帮助保持会议的简短。
  3. 1对1。1对1会议是指只有你和另外一个人之间的会议。这类会议或许是最值得开的,因为在会议中你们能坦率地交谈。而且会议也给了你们专门时间来完成需要互相协作的任务。
  4. 产品/工程/用户体验评审。这是一种大规模会议,通常会有一些大老板参加。这个会议既要向高管通报产品进展,又要收集组织内最富有经验的人们的反馈建议。团队需要仔细准备这类会议,如果搞砸了,项目势必被要求重来,所以从这个角度来说这类会议是相当昂贵的。
  5. 头脑风暴会。这是所有会议中最有趣的,它形式自由,能激发想法,还能让团队主动参与到问题的解决中去。

每个领导者组织会议的方式或多或少有些不同。会议常常是你个人风格的表现,这意味着没有哪种最优的方法能组织好所有会议。然而有些最佳实践能让你组织的每个会议都更好一些,且不限于你的个人风格和组织的会议类型。如第11章关于如何处理冲突的最佳实践就适用于处理会议中的冲突。除去这个,我还遵循四个最佳实践:

  1. 会后立即发出主题纪要
  2. 允许改变开会的目的
  3. 拒绝在团队会议中发泄负面情绪,但允许在1对1会议中发泄
  4. 使用鱼骨图等辅助工具解决问题

史蒂夫·乔布斯级别的演示是你学习的参照,但它需要海量的准备时间,而且你也不一定有那么多精彩的内容,所以通常大多数人都达不到那个标准。好消息是,如果你花大量时间去上关于演示的课、学习演讲、接受训练等,你会发现有一些基本的东西可以帮助你的演示取得成功。更好的消息是,我在下面写下了这些基本规则和技巧。坏消息呢?坏消息是演示还得你亲自上马。下面是总结出来的技巧:

  1. 将演示时间控制在15分钟内
  2. 永远传达且只传达一个信息
  3. 讲故事
  4. 制作“综述单页”
  5. 重点演示用户体验
  6. 极度专注倾听

由于人类畏惧冲突的天性,很多软件团队主管害怕说不,于是“蠕变特性”(Featuritis或者Creeping Featurism)1成为一种常见病。有时候人们也不是害怕产生冲突,而是害怕做得不够好。对于软件团队主管来说,他们常常害怕软件的功能还不够多,而他们又最知道软件有多少功能。于是这种害怕催生出来的设计会使产品过于复杂而无法发布。

将不属于绝对最小化可行特性集的所有特性放到V2。检测这种特性的方法是:“这样的软件做出来后用户能完成他们的基本任务吗?”如果用户不需要这个特性也能完成任务,那么即便任务完成得再糟糕、再丑陋,你也可以把这个特性放到V2。你必须坚持进行检测,因为每行代码(除了单元测试)都会降低你发布的可能性,而没有发布,卓越发布就无从谈起。

几乎所有特性或用户体验的争论最后就会变得像绑匪谈判。你控制了人家的孩子,或者人家控制了你的孩子,除非某一方开出的条件被接受,否则孩子就会被撕票。无论你们是争论某个Bug是否是阻碍者,还是争论图标该是绿色还是蓝色,这都是谈判——而处在危险中的孩子就是你的产品。如果你是大老板,可以抱起孩子就跑,可惜你不是。你也许基本上没有或是没有正当的权力,因此依靠谈判快速达成共识是通往成功的必经之路。

谈判的第一步是正确地认识到不管你是不是产品的负责人,你都不是老板。你的团队之所以和你一起工作是因为他们喜欢你或者你的产品,而不是因为别无选择。软件行业中的一个现实情况是:如果你想要与某人合作,别人也都想要与之合作。因此你一定要让你的团队成员参与决策,让他们与你共同拥有这个产品。

更好的团队决策制定过程是在早期就让所有团队成员都参与进来。根据我的经验,这种方式从长期看来更富成效,因为你有机会在项目早期就向整个团队解释商业目标和团队目标。如果换成和级别较高的利益相关人开很多小规模的会议然后直接向团队传达制定好的完整计划,你未来可能需要更多的小规模会来处理后续出现的各种忧虑。更糟糕的是,有些忧虑是合理的,你将不得不大量修改计划,而优秀的项目管理方法告诉你应尽可能在开发过程早期完成所有修改。

有时候甚至还未讨论目标你就陷入谈判中了。这时候有三种帮助你回归正轨的方法。

  1. 聚焦于促进。不要一开始就尝试去解决问题,否则你会带着先入为主的观点以至于无法保持中立,这会使讨论更加复杂。你应该首选确保听到每个人说的话。重点关注那些外向的人,他们常常会说很多。内向的人不太喜欢在人群中发言,但当他们发言时你务必认真倾听。
  2. “先寻求理解,再寻求被理解。”个人成长导师史蒂芬·柯维在他的《高效能人士的七个习惯》一书中提出了这条原则。它说得非常到位。我发现一个组织中最具权势的那些人也是最不擅长交流并处在极不正常压力下的那些人。因此,你需要极其努力地理解他们到底在说什么。问问你自己,他们真正关心的是什么?然后通过提问来验证你的假设。
  3. 佛罗里达州立大学电影艺术学院院长弗兰克·帕特森有一次教我了一个和他那儿演员合作的范例。在试着为一个演员指明方向之前,先清晰表达你所观察到的东西:“我听到你在说……”通过将信息反述给信息的发送者,你使得那个人可以纠正你的错误以减少误传。这个方法很出色,它强调了你渴望先寻求理解,再寻求被理解。

如果你已经有了倾向性的判断,不妨先说出来,然后让其他人继续发表观点。我认为当其他人已经知道你有倾向时,你不妨开场先阐明你的倾向,然后把指挥棒交给其他人以便能专心倾听。这个方法真诚且高效。

举个例子。刚加入谷歌地图团队时,我被设计团队搞得真心恼火。他们看起来聪明而友好,但我不断被他们气得想撞墙。当我问一些常规问题时,如“你要解决的用户问题是什么”,他们会回答说:“我们设计的目标是‘地图即用户界面’。你还是多花点时间去和其他产品经理聊吧。”

于是我倾向于认为地图的设计师们都是白痴,因为“地图即用户界面”不是一个设计目标,它对用户没有任何帮助。直到有次我一边喝着白葡萄酒一边吐槽时,我的一个设计师朋友给我讲述了一个不一样的背景情况。“他们没有业务目标,”他说,“就因为这个,他们被人随意抱怨了好多年,于是他们不得不凭借自己的力量来设法完成那些本该由你完成的工作。他们发明了一套组织原则来承受这些来自任意副总裁的任意微不足道的抱怨。而且他们可能把你当成又一个要抱怨的副总裁了。”

等到你相信你所面对的家伙不一定是个讨厌鬼时,你就能找到问题的根源。90%的情况下冲突的根源都是沟通不畅。另外10%中有1%是因为你面对的的确是个讨厌鬼,剩下9%是因为目标的方向错了。

你真正需要了解的只是那90%的情况,你和对方在“各说各的”。换句话说,你们对重要的事情达成了共识但却纠缠在一些细节或措词问题上。我发现当工程师和工程经理真的关心某件较大的事情时,他们会经常把焦点放在细节上,如不要写重复的代码等,毕竟细节更容易被具象化。由于你知道这时你们有很大可能在各说各的,你便可以回到上一步并问问自己其他人真正想说的是什么。这是第一步。

长期以来,我和同事一道致力于交付事业,下面这些就是我收集并践行的经过实践检验的建议的精髓部分。我把它分为5个类别,希望能对你有所帮助。

  • 如何平衡交付、质量和影响、团队这三者的关系,你才能交付一款卓越的软件。
  • 如何应对随机情况,你才能继续按原定节奏交付一款卓越的软件。随机情况是指当你的管理层掷给你一个弧线球或者你的团队脱离正轨时出现的情况。随机情况是每个在谷歌或亚马逊工作的人都理解的词之一,因为它是与帮助团队专注于交付相对立的。
  • 如何妥善地管好你的精力,你才能1个顶3个。
  • 如何找人以及在什么时候找人,你才能让合适的人做合适的事。
  • 如何咽下狗屎三明治,因为有时候你的确得咽下去。

十大交付原则

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

在管理产品开发的过程中,你会创建很多文档、指南、核查清单以及其他工件。下面这张列表是贯穿产品生命周期中你可能期望创建的工件的略述。你很可能需要创建以下所有工件,所以它们没有按照特别的顺序排列。你能从www.shippinggreatness.com上下载到其中一些工件的模板。

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