标签: 产品管理

《逆向工作》是内部人士对亚马逊的文化、领导力和最佳实践方法的剖析，来自两位长期的亚马逊高层管理人员。 Carr于 1998 年加入亚马逊；Bryar于 1999 年加入。在《逆向工作》中，这两位长期服务的亚马逊高管揭示并编纂了推动世界上最杰出的公司之一取得成功的原则和实践。他们有着 27 年的亚马逊经验，其中大部分是在早期——一个无与伦比的创新时期，带来了包括 Kindle、亚马逊 Prime、亚马逊工作室和亚马逊云计算产品和服务。 通过敏锐的分析和在您自己的公司（无论规模大小）中应用它的实际步骤，作者阐明了亚马逊的十四项领导原则如何为各级决策提供信息，并揭示了公司文化如何由四个特征定义：客户至上，长期思考、对发明的渴望和卓越运营。Bryar 和 Carr 解释了一套基本的实践，确保这些实践转化为行动并贯穿于业务的各个方面。 《向后工作》是一本实用指南和企业叙事，充满了作者在对“成为亚马逊人”是什么样的以及它如何影响个人和职业生活的回忆。证明亚马逊规模的成功并非由任何一位领导者的天才实现，而是通过对一套明确定义、严格执行的原则和实践的承诺和执行。 这本书读起来像是一本操作指南，可以肯定的是，亚马逊提供了很多值得钦佩的地方。该公司的员工人数接近 100 万，与 1997 年的 600 人相比有了惊人的增长。Bryar 和 Carr 的书的书名源自亚马逊从期望的客户体验开始设计业务部门的做法。嗯，很多傲慢的人会觉得，那没什么了不起的。但亚马逊的出色部分是因为它为自己所做的一切制定了严格的程序。亚马逊的做法可以简单地安装在其他公司吗？请随我阅读心得试试看吧。 一、建立明确的领导准则 二、不断提高招聘标杆 亚马逊的招募流程十分独特，他们有所谓的「抬杆者」，任务是确保公司可以聘雇到更聪明、 更优秀的人才，而不会因为工作太多、 急需人手而将就。设计抬杆者的目的，是为了形成一套 可扩大、可重复且正式的流程，以便 持续在聘用人才时做出良好决策。在 面试新人的过程中，会有一名经过专 门训练和任命的抬杆者参与其中，他 们有权否决任何聘用，甚至可以推翻 招募经理的偏好和决定。 三、建立单线领导模式 亚马逊能够快速创新的原因之一，就 是单线领导，简称 STL。简单地说， 这是指一个人全权负责一项重大计画， 领导一个高度自主的团队。挑选一位领导者，要求他 或她放下所有其他职责，专心建立 一支团队来开启一项新计画。一位 STL 领导者可能带领一支小团队， 也可能掌管一支非常庞大的团队专 门进行某个大案子。关键在于这位 领导者必须全心全意投入专案，而 非部分时间努力创新，其余时间从 事其他事务。 STL 的出现是亚马逊快速成长的结果。随着亚马逊从在美国卖书发展成为一 家什么都卖的跨国公司，公司发现经 理人必须花更多时间进行协调，用于 创新思考的时间变少。 亚马逊后来提出著名的「2 份披萨 团队」 模式──让 2 份大披萨就够 吃的小团队进行自主创新。数百个 这样的团队因此建立，其中有些确 实提出了伟大的创新。这种团队往 往在产品开发方面表现出色，但在零售、法律、人资及其他维护业务正常运作的作用就小得多了。出色 的「2 份披萨」团队最终成为凤毛 麟角，因为部分商业创新需要 10 人 以上才能成功。 四、禁止PPT，采用6页纸沟通方式 2004 年，杰夫.贝佐斯读到耶鲁大学教授爱德华・塔夫特写的一篇文章， 文中指出严肃的议题和报告，使用书 面叙述远比使用资料单薄的 PPT 投影 片好得多。经过一番讨论后，杰夫发了一封电子邮件给 S 团队成员，宣布会议禁止使用 PPT，立即生效。S 团队的普遍反应是:「一 定是在开玩笑」。 杰夫规定 S 团队成员开会必须准备书面备忘录。有人交出 30 至 40 页的文件，于是后来决定篇幅最多只能 6 页，可增加附录补充更多细节， 但构想本身不得超过 6 页。这是将一个想法解释清楚的完美长度，读完大约需 要 20 分钟，也就是说一场 1 个小时 的会议大约有 40 分钟可以进行讨论和 分析。一份撰写妥当的文件可以在 20 分钟的时间内传达许多有用的资讯。 五、从用户期望的体验出发 亚马逊在创立初期尝试过各种不同的 创新方法。他们有时会从编写使用手册开始发想，有的专案则只仰赖模型。诸如此类的方法最终都适得其反，亚马逊最后终于想出 PR/FAQ 流程。 当酝酿新构想或开发新产品时， 永远都要从期望的顾客体验开始逆向思考，最好的做法就是撰写新闻稿和 FAQ(常见问题)。利用这些工具提前解决棘手的问题。 新闻稿是发表产品时需要撰写的产品 说明，仿佛产品就要上市。常见问题 或 FAQ 是指你提出并回答顾客可能会 问的棘手问题。一份理想的常见问题 应该是一系列深入追究的问题，加上 你(在此阶段)对这些显而易见的问 题预备采取的答覆。 PR/FAQ 法的主要优点是: ■ 不看什么对你的公司有利，而是直 接导入顾客观点──处理你的产品 是否足以吸引人来购买的关键问 题。 ■ PR 的重点放在强调顾客体验 ── FAQ 的部分则是针对实际执行 情况提出清晰的评估。两者都很重 要，团队经常需要写出 5 个或更多 版本，才有办法写好 PR/FAQ。 ■ PR/FAQ为快速迭代创造了一个框架--也有能力迅速纳入反馈。快速而简洁地提出新的版本。 ■ PR/FAQ 可以迫使你去芜存菁──切中要点，不要废话连篇。 ■ PR/FAQ 可在会议上有效完成检讨 ──大家目标一致，同心协力，而 非乱无章法。借此可以找出缺漏， 并且即时整合改进意见，或经共同 讨论之后纳入改进意见。 ■ 你可以透过 PR/FAQ 快速找出想 法中的缺失与疏漏──以免旷日废 时，耗尽资源。 ■ PR/FAQ 迫使你必须记下所有要素 和限制条件──这在开发从未尝试 过的全新事物时，是件好事。 ■ PR/FAQ 做得好可以提高获得批准 和投资的机会──而且后续仍可持 续修改和注入新的元素。 六、管理投入而非产出 将顾客置于所有绩效指标的中心。强 调你能管理和掌控的投入，以及能够 产生预期成果的活动。做好这件事， 营收和股价等产出指标自然水到渠 成。 亚马逊成立后不久，公司就发展到杰 夫.贝佐斯无法亲自参与每个业务环 节的阶段。没了第一手经验和直接观 察，他不得不开始仰赖管理干部告诉 他的情况，此外也不时会出现一些临 时报告，但杰夫仍然很难真正了解业 务的进展情况。 公司高阶主管天天开会，想要掌握所 有数据，了解业务进展情况。节日购 物旺季结束后，公司进行事后检讨， 因此催生亚马逊的「每周业务检讨」 (WBR)流程。实质上来说，WBR 就 是想要提供一个全方位的角度来检视 业务。 作为亚马逊发展 WBR 的起点，杰夫. 贝佐斯和他的高阶主管采取了著名的 六标准差流程。在六标准差中，有一 套名为 DMAIC 的流程改善方法，其中 DMAIC 代表:Define-Measure-Analyze-Lmprove-Control 设定(Define):首先你需要选择和设定 你想要衡量的指标。亚马逊一直 在尝试开发领先指标(可控制的 投入指标)，而非使用落后指标 (产出指标)。自 2001 年以来， 杰夫.贝佐斯就广泛谈论亚马逊 的飞轮，它看起来就像这样: 此图说明了亚马逊零售业务成功 的原因，WBR 的首页就放了这张飞轮图片。每隔一段时间，便会选择及分析许多不同的投入指标，以便找出某些特定指标与更好的顾客体验之间的因果关系。 大多数公司都有一项杰出的创新，然后再用其余时间进行逐年改进。但 亚马逊却不断推出具突破性、改变市场规则的各项创新，并以这些创新 创造全新的庞大市场。 贝佐斯一生都在发明新事物， 他也设法将「发明 DNA」注入他所创立 的公司。如今，亚马逊是公认的市场颠 覆者，这间公司对于发明的戮力不懈， 令人钦佩。 贝佐斯曾说:「一般有两种扩展业务的方法:盘点自己擅长的领域，然后从你的技能扩展出去，也就是众所周知的核心能力概念，或是先判断你的顾客需要什么，然后再倒推回去，即使需要学习新的技能。」 亚马逊擅于培养新的能力，来满足未来 的顾客需求。最好的例子便是亚马逊的 电子书阅读器 Kindle。亚马逊于 2004 年推出 Kindle，当时这家公司完全没有制造硬体装置的经验，更别说是制造消费性电子产品。不仅如此，Kindle 还直接冲击到亚马逊在网上销售实体书的既有业务。 那么亚马逊如何创新呢? 步骤包括: 1、亚马逊会积极地向每位员工寻求点子 ──公司提供一项「点子工具」，任 何人都能用来提出新点子，而不必征 得主管的同意。亚马逊会员加值服 务 Amazon Prime 就是来自一位初阶 软体工程师，他建议亚马逊可以提供 无上限的快速送货。如今，Amazon Prime 在全球拥有超过 1 亿名会员。 亚马逊还会连络顾客，询问他们还希望看到公司贩售什么服务。亚马逊一 直在寻找简单、与众不同、值得做， 并有潜力令顾客感到惊叹及满意的点 子。 2、如果亚马逊获得一个点子，公司会很有耐心地培育它──而且方法很独特。首先，经理人会撰写一份新闻稿， 假设今天要推出这项服务，将如何向外界说明这个新点子。借此方式，找出谁是新点子的目标顾客，可以为上 市日期定出什么目标，以及实现这个 点子需要解决哪些障碍。考虑好这些 因素后，便可迅速做出通过或不通过的决定。以 Prime 为例，贝佐 斯在听到这个想法后，立即在周六召集他的高阶主管团队开会，并当场启动这项专案计划。之后，专案团队有 8 周的时间将此点子化为现实，以便在下一次推介会上发布。Prime 已为 亚马逊增加了数十亿美元的销售额。 3、谨慎组成开发团队──亚马逊采取 一项称为「2PT」的规定。此规定要 求，一个有效的团队约为 6 至 10 人， 只要两份披萨就能喂饱团队会议上的 成员。这个小团队必须是个跨部门团 队，同地协作，并全职开发这项专案。然后，创始团队会进行辩论、试验、 迭代，然后再进行更多辩论，直到顺 利完成新产品或服务。你还需要指定 合适的团队领导者，领导者将对团队 负起端对端的责任。(编注:为了弥 补小团队的不足，亚马逊后来又发展出单线领导） 4、全神关注顾客体验──亚马逊所有创 新行动，皆以此为目标。亚马逊不断努力为顾客增加价值，并开拓未开发 的领域。亚马逊深知其顾客渴望更好 的服务，所以一直努力创造「惊叹」或「神奇」的时刻。亚马逊无人商店 Amazon Go 是一个绝佳的例子── 人们走进这家实体商店，拿起他们需要的商品，然后便可离开商店，不必排队结帐。顾客描述这种购物体验 「很神奇」，这正是亚马逊在各种出 色的点子中想要追求的。 推动亚马逊各项改变的最大因素，正是顾客还不知道的需求。亚马逊必须发挥 自己内在的想像力，替顾客发明及创造 各种可能性。而使得这一切得以运作的 基础正如贝佐斯所言:「我想我们有一项与众不同之处，那就是失败。我相信亚马逊是世界上最佳失败之地 (我们的经验丰富!)，但失败和发明是一体两面，密不可分的。要发明，你必须先试验，但如果你事先知道它会成功，就不是试验了。」 要发展崇尚创新精神及文化的工作环 境，不妨时时提出几个问题: ■ 你是否经常要求员工提出最好的新点 子，并给予奖励? ■ 你是否愿意寻求新的机会，不惜让既 有产品变得过时? ■ 你是否组成优秀的团队，来接纳新点 子，并以巧妙的方式加以运用?

「Jeff Sutherland」Scrum之父，敏捷宣言（Agile Manifesto）起草人。萨瑟兰毕业于西点军校，越战期间是出色的战斗机飞行员，擅长低空飞越北越进行侦察任务。越战归来后，先在史丹佛大学取得统计硕士学位，后于科罗拉多大学医学院取得 生物统计学 博士学位，其 指导教授John Bailar是医学暨统计学最知名的研究学者之一。现在 为Scrum基金会总裁。他在空军训练中学到：观察（Observe）、导向（Orient）、决定（Decide）、行动（Act）的循环方法。 Scrum是目前全球最为广泛采用的敏捷工作法(1,500万人正在天天使用中)，Amazon有3,300个Scrum开发团队，Intel则有500个Scrum teams，Tesla、Apple、BOSCH、J.P. Morgan、及日本的TRI-AD/Toyota、Docomo、KDDI ...... 911事件发生后，事件调查 委员会试图找出事情发生的关键原因。该委员会指出，负责分析情报的人员未能取得一些原本应该要分析的情报。「FBI的资讯系统效能不彰，」报告中写道，「这意谓着情报分析人员多半得仰赖与工作部门或工作小组成员间的私交， 才能从存放情报的单位取得情报。」这是该委员会的结论:「FBI缺乏知道自己欠缺什么的能力:内部缺少一个能吸收或分享组织知识的有效机制。」 FBI「自动化案件支援」(Automated Case Support)系统架设于 1980年代曾经走在时代尖端的大型主机上。但是，很多干员根本不用这套系统，因为它实在太笨重又太迟缓。 「你得在文书处理软体中打好内容，然后列印出三份。第一份是 要请上级层层核可的;第二份是要存放起来，以防第一份遗失的;第三份你得拿一枝红笔──我没开玩笑，真的是红笔，圈出关键字，输入 资料库中，因为你得为自己的报告做索引。」 这样的情景在官僚化系统里最为常见。 这种管理方式实在太过时又松散，一度备受诟病:FBI明明早在九一一事件前几个星期就已得知，有多名 激进 组织的份子进入美国，却未能把种种迹象的关联性加以串连，有人认为部分的原因就出在档案系统上。当时FBI的某单位对某个目标起疑，另一个单位对于有这么多可疑的外国人在接受飞行训练感到事有蹊跷，还有一个单位则是把某盖达成员列入监视名单，却从未通知其他单位。在FBI 内部，没有人把这些事情全部拼凑在一起。 当参议员们开始质询FBI一些难堪的问题时，FBI基本上都会回 答:「别担心，我们已经有一个正在进行中的现代化计划了。」该计划要发展的是一套名为「虚拟案件档案」(Virtual Case File, VCF) 的系统，照理说这应该可以让一切改观。FBI的官员很懂得利用每一 次面临的危机，他们向参议院表示，该计划除了原本已拨款的1亿美元经费以外，只需要再追加7,000万美元经费就够了。假如你回头去找当时媒体对VCF系统的报导，你会发现内文大量使用诸如「革命性 的」与「转型」之类的字眼。 三年后，计划终止了，因为根本不管用，连一丝一毫的效果都没有。FBI已经花费纳税人1.7亿美元的辛苦钱，买到的却是一个永远不会有人使用的电脑系统──没有任何一行程式码、应用程式派得上用场，也不会有任何的滑鼠点击。整个计划根本是一场灾难。 2005年，FBI展开名为「哨兵」(Sentinel)的新计划。这次一定要管用，这次一定要用对预防措施，一定要跑对预算流程，一定要做好控管。毕竟FBI已经得到教训。哨兵计划造价多少?只要4.51亿美元，而且2009年就能全面上线。受雇建置哨兵系统的承包商Lockheed Martin已经用掉4.05亿美元的经费，却只完成一半的工作，而且这时候的进度还落后了一年。一项独立分析预估，这个专案可能还要六年到八年才能完成，而且纳税人为此至少必须再花3.5亿美元。FBI花费近十年的时间试图更新局里的电脑系统，但是专案看起来即将「再次」失败，成为史上最大的软体灾难。 原因不在于这些人不够聪明，也不在于FBI所托非人，甚至不是选错技术的问题。问题无关乎职业道德，或是缺乏外来的竞争刺激。原因在于大家工作的方式不对，大多数人都用错了工作方法。我们都以为工作应该要那样完成，只因为别人教我们的就是那一套。 Lockheed Martin的成员在投标前先开会检视系统需求（有1,100项需求，堆起来大概几吋厚），而后开始着手规划如何打造出一个满足所有需求的系统。他们会交由公司内部的大量人才处理，花费几个月的时间整理出必须完成的事项。接着，再花几个月的时间 规划如何完成。他们会划出许多美观的图表、解说每件必须完成的工 作，以及每件工作所需的时间。然后会小心挑选颜色，把计划的每一个部分以层层相接的形式呈现出来，看起来就像一道倾泻而下的瀑布。 大多数的软体开发专案都还是采用瀑布法，专案分成多个阶段完成，一个又一个阶段发展出准备释出 给顾客或软体使用者的终极版。流程很缓慢，也无法预知成果，而且往往会做出使用者并不想要或不愿付费购买的产品。进度延迟几个月或几年是家常便饭。这种事前先把每一步都规划好的计划， 会把所有细节都画成甘特图，也让管理高层相信开发的过程完全在掌控中，但结果往往是进度很快就开始落后，而且预算严重超支。 这类图表叫做甘特图(Gantt chart)，因为它是由亨利.甘特 (Henry Gantt)所发明的。1980年代，个人电脑的问世让大家能很容易就画出这种复杂的图表，但是也让图表变得极其复杂，甘特图于是成为一种艺术品。专案中的每一个阶段都巨细靡遗地设定好了，包括每一个里程碑、每一个交日期在内。这些图表看了真的会让人留 下深刻的印象，但唯一的问题却在于它们往往是错的。 甘特大约在1910年发明这种知名图表，最早使用甘特图的是第一次世界大战时担任陆军军械部部长的William Crozier将军。任何研究过第一次世界大战的人都知道，有效的组织能力在那次大战中实在称不上是什么突出的特质。我一直都很纳闷， 为什么甘特图这种一次世界大战时的玩意儿会变成21世纪专案管理中的既定标准工具。我们现在已经不再打壕沟战，但是当年用于规划壕沟战的思维到现在却依然流行。艾森豪威尔曾说过，为战争拟定计划固然重要，但是等到开了第一枪后，计划就化为乌有了。他很有见地的没有使用甘特图。 传统上，管理团队对于任何专案都会要求两个条件:控制和可预测性。这会带来为数众多的文件与图表，就像Lockheed Martin一样，会花好几个月的时间规划所有细节，以确保没有任何错误，没有任何成本超支，而每件事也都能按照时程完成。 问题在于，这样美好情节从未真正发生。所有用于规划的心力、用于限制变化与厘清未知事项的努力全部都是白费。每个专案一定都会出现许多的问题，冒出许多新想法。试图把任何规模的人类行为限制在全彩图表里，不但愚蠢，而且注定会一败涂地。人不是这样做事的，专案不是这样进展的，想法也不是这样落实的，美好的成果更不是这样创造的。 Scrum的固定仪式之一是询问大家很简单的三个问题:从我们上次交谈后到现在，你做了什么?在我们下次再讨论之前，你打算做什么?有什么事情干扰你吗?这可以促使 特派员们彼此讨论并分享资讯。在每次开会后，Scrum Master要负责确保任何干扰团队工作的因素在下一次开会前已经被排除，否则流程就无法“流动”。 大野耐一提出的关键概念「流程」，意思是生产流程应该流畅平顺;管理团队的重要任务之一在于找出流程中的阻碍，并且予以排除。任何挡在路中央的东西都会造成浪费。他的经典著作《丰田生产方式:追求超脱规模的经营》(The Toyota Production System)中，评定「浪费」的道德价值及商业价值:在低成长时期，这样的浪费不但是商业损失，更是社会犯罪。排除浪费必须是企业的首要目标。想要让Scrum真正发挥功能，高阶管理团队中必须有人发自内心地把阻碍视为近乎罪犯。 大野耐一谈到三种不同的浪费，他用的是日文字眼:Muri、 Mura、Muda。Muri指的是因为不合理、不恰当导致浪费;Mura指的 是因为缺乏一致性导致浪费;Muda指的是成果欠佳导致浪费。这些想法与PDCA循环高度契合，也就是规划、执 行、检核、行动。规划意谓着要避免Muri，执行意谓着要避免Mura， 检核意谓着要避免Muda，而行动意谓着我们要有意志、动机及决心把这些事做好。 节奏是Scrum的核心，运作得宜的Scrum团队可望实现我们所称的「超生产力」。 美国太空总署采用的「阶段-关卡」流程就是经典案例。美国太空总署在1960年代、1970年代及1980年代就是使用这套流程执行太空梭等计划。现在的流程已经大不相同了，这里讲述的是他们那套旧流程的运作方法。首先，从探索「阶段」着手，大家决定要设法完成的目标，比如说打造一艘登月火箭。一群策略人员坐在房里，想像着那幅场景。接着会有一个「关卡」，由一位或一群管理者签名，认可该专案有发展的价值。再来进入初步调查阶段，所有的「需求人员」 必须决定该做哪些事。接着会有另一个关卡，又要开好几次的会，产出的所有庞大文件要转交到下一个阶段──细步调查阶段，并拟定专案计划。再来，所有的计画又必须历经一连串的会议与核可，完毕之后再送到下一个阶段──开发阶段，到这时才会真的开始动手生产。接着又是一堆会议与文件，然后把产品交到另一群人手中，进入下一个阶 段──测试。测试人员先前从未看过产品，但他们还是照测不误，然后签名核可，再把产品放到另一个关卡前，也就是永无止尽的开会，这时会再产出一批根本没有人会阅读的文件。直到这里，产品总算要送到第六批人员的手中，由这些人实际推动上市。光是把这些过程写出来就累死人了，但这却是美国太空总署过去发展计划的过程。 物理学家Richard Feynman:「无论是出于内部或外部所需的任何理由，看来美国太空总署的管理当局夸大产品的可靠度已经到了幻想的地步。」 只要资料在不同团队间移交，就有发生灾难的可能。正如刊载在《美国联合部队季刊》(Joint Force Quarterly)上，一篇名为

“说两句就可以了，为什么还需要写文档这么麻烦”？很多人都会问这个问题。确实，当我们所有人都在同一办公室工作时，随便喊两句就行了，为什么还要用文档记下每一件事情这么麻烦呢？ 产品文档的价值在于，它能给整个团队一个参考点，关于这个项目中要完成的工作，产品文档提供了一个很好的依据，定义好你的产品文档，才能保证在开发过程中不会出现模凌两可的情况。当产品经理看到一篇新的文章或一个新的想法时，都会考虑增加一个新的功能。一个项目如果没有固定的目标，没有日程安排，没有预先计划好的里程碑，那项目就没有尽头。这样就没有人知道项目能得到什么收益，什么时候项目能结束。 虽然用文档来说明项目的要求是一件很麻烦的事情，但你必须要做，主要原因有： 1、有了文档你才知道目标是什么？ 一个产品的目标不仅仅是你一个人的想法，产品的实现必须通过整个团队的充分配合才能完成的。如果没有文档的记录，你的产品、你的项目就会变成一个通过口口相传的“传说”，可怕的是每个人的理解都不同，每个人的口头描述又不同，这样到最后就没有一个人知道产品的真正目标是什么。只要有了文档详细地记录项目的目标，详细地记录项目的进程安排，这样产品才不会停留在产品经理头脑里不定型的图像，它变成了产品团队里每一个人都触手可及的东西。只有把一个人的想法变成整个团队的想法时，这个项目才能完美的实现处理。 2.、有了文档你才知道正在建设什么？ 产品项目在早期的头脑风暴讨论中都会有很多的想法，很多的构思，如果当中没有文档记录下来，那在开发实现当中就会觉得很混乱，不知道当前要做的工作是什么？只要有了文档支持，把产品的目的和产品的规格详细地记录下来，才可能看起来像独立的功能模块；只有把要求确定下来了，才能让事情更加明细化。一个产品在开发中拥有一系列明确的要求，才能让你把责任分配的更清晰，有了明确的分工，才能提供工作中的协作效率。 3、有了文档你才知道什么是不需要做的？ 产品项目在如火如荼的进行时，会有很多听起来非常诱人的功能、想法浮现出来，每一个功能、想法看上去并没有多大的工作量，但是当很多想法汇集在一起时，整个项目就失去了控制，像滚雪球一样，越滚越大，项目就会无休止的膨胀，项目的上线时间就会遥遥无期。有了文档你才知道正在建设的是什么？什么是现阶段不需要做的？有想法是好事，但有想法并不意味着马上要做。你可以把这些杰出的想法用文档记录下来，然后对这些想法进行分析研究，让它们变成你的长远计划，这才是想法的真正价值。把所有的新想法汇集起来，为产品的升级、版本更新做一个储备。 文档不仅为项目的前期和开发期提供了很好的参考点，而且能记录产品的版本历史，为每一次改版升级提供很好的对照物。虽然撰写文档和更新文档是一件很麻烦的事，但这是一个在产品开发过程中必不可少的一个重要环节。 （来源：YIXIESHI / 校排：姚晶磊）