书名：持续交付2.0：业务引领的DevOps精要（增订本）
ISBN：978-7-115-57739-9
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
著 乔 梁
责任编辑 刘雅思
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
读者服务热线：(010)81055410
反盗版热线：(010)81055315
本书“重新定义”了持续交付，增补了组织管理和架构两个维度，辅助以真实案例，对持续交付的诸多原则和实践加以解读，并对持续交付过程中的取舍原则加以论述。
本书分为3个部分：第一部分作者根据自己近十年的工作及咨询经历，通过不断总结、提炼和反思，对原有的持续交付进行修正，重新定义持续交付为实现组织战略目标的能力，并引入持续交付的能力模型；第二部分阐述组织打造持续交付能力模型所需遵循的原则，包括基础原则、组织原则和架构原则；第三部分通过对多个互联网公司案例的解读，阐述如何根据组织的当前状况应用相关原则对最佳实践进行取舍，并快速达到组织能力目标。
本书适合大型互联网公司的技术VP、技术负责人，中小型互联网公司的CTO、技术VP、研发/测试/运维负责人、主管及骨干，以及组织变革者阅读。
2007年，我在北京第一次遇到乔梁，并与之合作，共同开发一款软件产品，名为 GoCD，这是第一个支持部署流水线的CI/CD工具。我们在构建这款产品过程中的思想碰撞与经验总结为《持续交付》一书提供了非常关键的素材。
在过去10年中，这些内容已经从前沿的想法变为业界公认的智慧。每个追求卓越的科技公司都希望能够随时随地发布，而无须工程师在晚上或周末进行部署。能够快速、频繁且安全地发布软件，并实现小批量交付，意味着我们可以快速获得对我们的想法的反馈。我们可以构建原型并使用真实用户对其进行测试，从而避免开发那些对用户没有任何价值的功能。反过来，这也意味着产品更好，客户更满意，员工更快乐。这些能力对需要这种工作方式的每个组织来说，都是非常关键的。
然而，获得这种能力并不是一件容易的事情。组织需要对软件系统架构进行不断演进，使其支持尽快且有效的测试，以及快速部署，同时，还需要培养快速试验的文化。文化因素对于成功实施持续交付和通过持续交付实现产品管理实践至关重要。
乔梁曾与中国的各类组织合作，帮助它们实施持续交付并实现其效益。我想不出比乔梁更合适的人选，来写一本关于如何根据实际经验实现这些想法的书。希望本书的每位读者都能在提高软件交付能力的不断尝试中取得圆满成功，并利用这种能力来构建更好的产品和服务，以及更快乐、更高效的团队。
Jez Humble
《持续交付》一书作者，DORA联合创始人兼CTO
我们处在移动互联网时代的下半场。这意味着，对主流人群来说，头部的基本需求或许已经被满足或者说“饱和”，而未来的方向或许是现有模式的颠覆，或许是长尾个性化需求的充分满足，又或许是小众人群的挖掘。无论如何，我相信未来创新的成本和创新失败的可能性有很大的机会持续走高。
在这种大背景下，如何通过极致的产品研发运营效率，快速发现新的机会，降低创新成本就变得尤为重要。乔梁老师是软件工程领域的大师，同时作为腾讯的敏捷咨询顾问，也和我们合作多年，亲历了移动互联网发展的全过程。乔梁老师对产品研发运营体系的种种问题可谓洞若观火，对于效率的追求可谓孜孜不倦。
“在快速变化的互联网环境下，软件产品团队如何在质量与速度上取得平衡？如何让软件产品以最快的速度抵达用户手中，使团队得到最快速的反馈？”我与乔梁老师在多年前就曾针对这些问题进行过深入的探讨。“质量与速度根本不存在平衡，只有在产品能够承受的一定质量水准基础上，追求交付的速度才有意义。”他的观点如此鲜明，没有咨询师的“口头禅”——“It depends”（视情况而定），却道出了产品整个生命周期中的一个不变法则。虽然不同的产品阶段对产品质量要求有不同的定义，但在同一产品阶段中，质量要求却几乎是稳定的。本书中所讨论的内容全部围绕“如何在满足质量要求的前提下快速交付产品价值”这一问题展开。
为了快速发现新的机会，必须加快产品迭代速度，而迭代速度的加快也会让一些固定成本，例如为达到发布质量所需的测试成本，以及产品发布流程所需承担的成本，在每个迭代中所占的比例突显。这种事务性成本在很大程度上阻碍了产品的迭代速度。乔梁老师在书中对持续交付“价值探索环”与“快速验证环”中每个步骤的详细拆解，一方面会让你开阔对业务问题的思考维度与角度，另一方面也能让你发现，在日常工作中就有很多细节可以优化，从而降低迭代中的固定成本，有效提升产品创新效率。与此同时，也会在潜移默化中提高团队的整体战斗力。
本书是乔梁老师在大量实战项目中总结出来的理论框架，可谓经历千锤百炼。本书也许没有太多高深抽象的概念，但每一项原则和方法的后面，都有足够多的正反例支持，和乔老师的为人一样，低调、务实、简单，值得每一位钻研和应用高效产品研发运营体系的读者阅读体会。我相信，在互联网行业，效率代表未来。
曾宇
腾讯副总裁
2002年，我偶然得到一本书，名为《解析极限编程》。书中介绍的软件开发方法与现实中使用的工作方法截然不同。书中的很多实践看上去都不现实，如测试驱动开发、持续集成、结对编程、用户故事等，这让我感到很新奇，怎么会有团队这么做呢？但这些方法看上去的确很诱人，于是我带着“怀疑”的态度，在实际工作中引入了其中一些方法，但执行上还是打了一些折扣。例如：我没有做测试驱动开发，而只是增加一些单元测试；我没有做结对编程，而是要求代码评审（code review）；我没有做持续集成，而是每日构建。一段时间后，虽然能感受到一些收益，但并没有那么显著。
直到2005年，我的一个朋友向我展示了他们如何使用这种开发方式交付真实的软件项目，以及真实的编写代码的过程。每一次修改代码，都编写并执行一系列的自动化测试用例；每一次提交，都会进行持续集成。这是一种从未有过的编码体验，开发工程师很少需要启动程序，通过单步调试来找出代码中的问题。这使我真正相信，的确存在按照这种敏捷方式工作的团队，而且离我并不遥远。
2007年，我加入ThoughtWorks，希望能体验敏捷软件开发方式。作为一名需求分析师和交付经理，我加入了持续交付平台GoCD的产品研发，我的搭档就是Jez Humble（该产品的产品经理），他也是《持续交付》的作者之一，书中很多实践都来自我们团队自己的软件产品研发过程。从想法的诞生到产品上架，我经历了一个完整的产品研发过程，也真正认识了敏捷开发方法，掌握了持续交付实践。
2009年以后，我作为外部顾问或内部教练，开始为国内外很多企业提供相关的组织敏捷与精益转型咨询服务，客户既有PC互联网时代的巨头，也有传统IT企业；既有国内知名大企业，也有高速成长的移动互联网创业公司。在与客户合作的过程中，我对“持续交付”有了更深刻的理解，也对如何帮助组织实现“持续交付价值”有了全新的认识。
2007年，我认为包括极限编程在内的众多敏捷开发实践是快速高质量软件交付的法宝。2010年之后，我发现实践本身虽然非常重要，但更重要的是支撑实践的组织管理方法、工作思路与理念。于是，我的口头禅成了“别提敏捷，只解决问题！”。自2012年后，更多的软件开发方法与敏捷流派在国内开始盛行，但其背后的核心理念与主要工作原则并没有根本性的变化。无论什么样的方法，都应该以“解决问题”为出发点，而“解决问题”的一个重要前提是“能够正确定义问题，并达成共识”。
我当然不是思想无用论的支持者。相反，我认为思想对每个人对事物的认知和理解至关重要。但咨询经历告诉我，对事物的正确理解，并不能确保正确的思想和理念在现实中落地，也不能确保对企业有大的和直接的帮助。对方法应用者而言，其目标是通过对思想理念的认知，能够尽早解决自己（或者客户）所面临的棘手问题。
正如企业经营管理一样，软件工程发展的历程也是各种方法论不断出现与发展的过程。从20世纪60年代“软件工程”这一术语的诞生，到20世纪70年代提出瀑布软件开发模型，以及1985年提出的迭代增量开发和1986年Barry Boehm在“A Spiral Model of Software Development and Enhancement”一文中提出的喷泉模型，20世纪90年代的软件能力成熟度模型集成（capability maturity model integration，CMMI）的产生和多种轻量级软件开发方法，21世纪初敏捷宣言的正式发表，再到精益软件开发方法、看板方法，以及持续交付和DevOps运动，所有这一切变化，既反映出该领域的快速变化，也反映出没有哪一种理论或方法能够完全解决这个领域面临的所有问题。
本书希望能够让读者在了解“持续交付”全貌的基础上，当遇到与IT组织效能相关的问题时，能够以适当的思考方式和背景知识来应对，在今后的工作中少走一些弯路，至少遇到相似问题时，可以有所参考。
从“软件工程”这一名词诞生以来，“质量”和“效率”就是它的目标。IT组织大多在这条路上探寻，从最初的瀑布模型，到CMMI，很多组织曾经尊其为软件开发过程的“圣经”。而当“敏捷运动”兴起时，他们想要“做”敏捷；当听说“持续交付”时，他们想要“做”持续交付。现在，DevOps也来了！在各种各样的交流大会里，不断传来DevOps胜利的凯歌，各种媒体也在报道它的好处。很多公司又想要“DevOps”了……
我们的确听到过一些美妙的“故事”，但它们可能都不属于我们自己。在自己身边，就连“如何让大家对这些理念或实践达成共识”都成了一大困难，这令你感到无比困扰。就像走在一团迷雾之中，耳边一直听到美妙的音乐响起，也隐约看到远处的点点亮光，然而脚下的“路”却忽明忽暗。
多年工作经历让我对这一领域有了新的认识，并进行总结与反思。“持续交付”是一个非常有吸引力的名字，总会让人浮想联翩，业务人员似乎看到了一丝希望，“所有的需求，上午提出来，下午就能拿到手”。然而，太多的企业低估了自己所面临的困难。这些困难一部分是显性的，如没有自动化测试，也做不到自动化部署，主干开发更是不可想象；还有一部分困难是隐性的，例如，职能部门之间的“墙”存在已久。业务人员嫌开发团队的软件交付速度慢，开发团队嫌业务人员提出的需求不靠谱。这很可能归因于每个人的价值思考方式。
本书的目标是希望企业中所有角色转换价值思考的角度，改进软件服务端到端的商业价值交付方式，提升相关人员之间的协作效率，最终以安全可靠的方式快速验证想法，缩短实现真正商业价值的时间。也就是说，本书不仅关注“从需求列表到可运行的软件”这一过程，还提出“价值探索-快速验证”双环，如图0-1所示，这也是本书的书名“持续交付2.0”的由来。
事实证明，没有放之四海皆准的企业管理解决方案能够完美解决每个企业遇到的问题。但是，管理者只有从整体视角出发，抵住局部优化的诱惑，才能在资源有限的情况下，引领企业创造更大的价值。本书提供了一个整体框架，给出了这个框架中各节点所涉及的原则与相关的实践方法，同时介绍了它们的优势与约束。
图0-1 持续交付双环模型
如果你将“持续交付2.0双环模型”应用到整个企业范围，就是一种企业级的组织管理变革指引；如果你将它引入某一个团队，对这个团队来说，就是团队工作模式的改进套路。既然“持续交付2.0”是一个管理框架，企业势必要根据自己的实际情况来进行定制。因此，书中列举了很多实际案例，告诉你其他企业或团队如何应用这些实践方法，达到它们的目标。这些案例也说明，解决方案与实施路径很难在企业之间进行复制，企业必须应用书中的原则，结合自身的实际情况（产品形态及所处的商业竞争阶段、团队的规模与人员技能水平、软件系统架构，以及组织管理机制与文化等），逐步探索出自己的道路。
本书主要服务于那些身处IT业务一线的管理者，或即将成为一线管理者的骨干技术人员，当然也包括那些从事软件产品项目管理和软件过程改进的人们。本书对新公司的创立者或高速发展的成长期公司技术高管也有参考作用，它并不是为那些已经成熟的大型软件企业的高层管理者服务的。当然，如果他们也认为本书有帮助，那我也非常高兴。
对于产品经理、开发经理、测试经理和运维经理，他们可以从本书中获得更全面的工作视角，发现自己领域之外更多的信息，以及如何与其他角色协作共赢。
对于过程改进者或者变革者，他们可以从本书中了解其他团队或公司的做法，希望能给你带来工作上的灵感。
对于新公司的创立者与高速成长期公司的高管，希望他们可以从本书中找到一些管理方式与高效方法，使得公司在成立和发展之初，就能够以尽可能少的成本，支持事业的持续高速发展。
书中有很多案例，用于帮助读者理解“持续交付2.0”的双环模型，与其中各环节应用的不同实践。
在进入正文之前，先谈谈本书的结构和内容。全书共包括3部分内容：第一部分会介绍“持续交付2.0”的双环模型；第二部分主要讨论使用“持续交付2.0”框架时可能遇到的问题，以及改进过程中需要遵循的原则；第三部分主要是案例分享，目的是让读者体会在持续改善过程中，不同企业和团队的实施重点与解决方案的不同。下面我们一起浏览一下各章的具体内容。
第一部分主要讲述“持续交付2.0”双环模型（即持续交付“8”字环）和“持续交付2.0”的4个工作原则，还会介绍两个闭环“价值探索”与“快速验证”的执行步骤与相关原则。
第二部分主要阐述“持续交付2.0”的实施七巧板中，三大主要板块的工作原则与实践方法。这三大板块包括组织机制、软件架构与基础设施。其中组织机制是一个复杂课题，本书仅讨论持续交付所需的文化，以及塑造文化的四步法。组织架构、人才结构、激励机制等内容将在本书的续篇中专题讨论。基础设施部分是产品研发过程中最基础的工作。这部分首先讨论持续交付部署流水线及其工具设计原则，然后分别介绍部署流水线的建立与优化必须关注的五大领域，也就是说，业务需求协作流程、分支与配置管理、构建与环境管理、自动化测试管理以及部署发布与监控管理。
第三部分主要是实战案例的分析。它们分别代表不同类型的公司、不同大小的团队以及不同的软件产品特点。我将带你深入案例现场，了解当时状况，分析问题，并提出解决思路。
如何阅读本书取决于读者的目标是什么。你可以按照章节从头到尾读下来。这样，你可以了解我在工作中应用到的知识体系，最终了解为什么“持续交付2.0是一种组织能力”，如何衡量这种组织能力，以及如何在具体的工作场景中运用相关原则解决具体的问题。
当然，读者也可以根据自己的兴趣以及工作中遇到的问题，选取不同的章节。例如，后面4章的具体案例分析包括小团队的改进案例、大团队的变革案例，甚至超大公司所用的一些工作方法与工具。这样，读者也许可以为明天将要进行的艰难说服工作找到一丝破局的思路。
无论怎样，我都非常重视你的反馈。让我知道你对这本书有什么想法——你喜欢什么？你还希望知道哪些内容？你可以扫描下面的二维码，关注“持续交付2.0”微信公众号，或者访问www.continuousdelivery20.com网站查看相关的扩展阅读内容。
很多人为本书做出了贡献。首先要感谢编辑团队给予我的大力支持，尤其是杨海玲编辑的敬业精神打动了我，让我有勇气将自己多年咨询过程中曾经使用的方法与实践写下来，与更多人分享。尽管它们并不完美，但也算是对自己过去工作的总结。其次，感谢我的朋友任发科对本书诸多章节的审校，以及提出的宝贵意见。
另外，我要感谢我在ThoughtWorks工作时的同事，尤其是GoCD团队和Jez Humble。从他们那里，我真正领会了敏捷与精益思想，并在后来的工作中熟练应用持续交付领域的诸多技术实践，帮助我的客户解决实际问题。还要感谢我的朋友王鹏超，他就是让我认识到极限编程独特魅力的那个人，他目前在Facebook公司工作，负责Cassandra的开发。
最后，感谢我的妻子霞和儿子天，我的挚爱。我一度想放弃本书的写作，是他们的鼓励才让我走出低谷。而且，霞不厌其烦地帮助我修订文稿，提出改进建议，帮助我提炼总结，使得本书结构更加合理。
本书由异步社区出品，社区（https://www.epubit.com/）为您提供相关资源和后续服务。
作者和编辑尽最大努力来确保书中内容的准确性，但难免会存在疏漏。欢迎您将发现的问题反馈给我们，帮助我们提升图书的质量。
当您发现错误时，请登录异步社区，按书名搜索，进入本书页面，点击“提交勘误”，输入勘误信息，点击“提交”按钮即可。本书的作者和编辑会对您提交的勘误进行审核，确认并接受后，您将获赠异步社区的100积分。积分可用于在异步社区兑换优惠券、样书或奖品。
我们的联系邮箱是contact@epubit.com.cn。
如果您对本书有任何疑问或建议，请您发邮件给我们，并请在邮件标题中注明本书书名，以便我们更高效地做出反馈。
如果您有兴趣出版图书、录制教学视频，或者参与图书技术审校等工作，可以发邮件给本书的责任编辑（liuyasi@ptpress.com.cn）。
如果您来自学校、培训机构或企业，想批量购买本书或异步社区出版的其他图书，也可以通过邮件发给我们。
如果您在网上发现有针对异步社区出品图书的各种形式的盗版行为，包括对图书全部或部分内容的非授权传播，请您将怀疑有侵权行为的链接发邮件给我们。您的这一举动是对作者权益的保护，也是我们持续为您提供有价值内容的动力之源。
“异步社区”是人民邮电出版社旗下IT专业图书社区，致力于出版精品IT图书和相关学习产品，为作译者提供优质出版服务。异步社区创办于2015年8月，提供大量精品IT图书和电子书，以及高品质技术文章和视频课程。更多详情请访问异步社区官网https://www.epubit.com。
“异步图书”是由异步社区编辑团队策划出版的精品IT专业图书的品牌，依托于人民邮电出版社的计算机图书出版积累和专业编辑团队，相关图书在封面上印有异步图书的LOGO。异步图书的出版领域包括软件开发、大数据、AI、测试、前端、网络技术等。
异步社区
微信服务号
经典图书《持续交付》（Continuous Delivery）已出版8年，一直受到软件行业从业者的关注。书中的软件开发原则和实践也随着商业环境VUCA特性的明显增强而逐渐受到软件技术人员的认可。
VUCA是volatility（易变性）、uncertainty（不确定性）、complexity（复杂性）和ambiguity（模糊性）的首字母缩写。VUCA这个术语源于军事用语，在20世纪90年代开始被普遍使用，用来描述冷战结束后的越发不稳定的、不确定的、复杂、模棱两可和多边的世界。在2001年9月11日恐怖袭击发生之后，这一概念和首字母缩写才真正被确定。随后，VUCA被战略性商业领袖们用来描述已成为“新常态”的、混乱的和快速变化的商业环境。
然而，在应用这些为达成持续交付目标所需的软件技术相关原则与实践时，我们会遇到很多难题。例如：业务压力太大，没有时间改进；开发和测试的时间被压缩得太少了，没有时间这么干；这么做的风险太高了，质量很难保障。而这些难题正是由软件工程的发展惯性带来的，是时候改变了。
“软件工程”这一学科出现于1968年，当时正值第一次软件危机。第一次软件危机是落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。人们试图借鉴建筑工程领域的工程方法来解决这一问题，以实现“按预算准时交付所需功能的软件项目”的愿望。
瀑布软件开发模型由Dr. Winston W. Rovce在1970年发表的“Managing the development of large software systems”一文首次提出，如图1-1所示。它将软件开发过程定义为多个阶段，每个阶段均有严格的输入和输出标准，项目管理者希望通过这种重计划、重流程、重文档的方式来解决软件危机。很多人将具有以上3个特征的软件开发方法统称为“重型软件开发方法”。
图1-1 瀑布软件开发模型
在20世纪，瀑布软件开发模型的每个阶段都需要花费数月的时间。在写出第一行产品代码之前，甲乙双方需要花费大量精力确定需求范围，审核比《新华字典》厚得多的软件需求规格说明书。即便如此，双方还是要为“是否发生了需求范围的变更”“是否准时交付了软件”“交付的软件是否满足了预先设定的业务需求”而纠缠不清。
从20世纪80年代开始，微型计算机快速普及。20世纪90年代，人们对软件的需求迅速扩大。然而，Standish Group的Chaos Report 1994显示，软件交付项目的失败或交付困难的比率仍旧很高（成功率只有16.2%，受到挑战的项目占比52.7%，而失败率为31.1%）。此时，很多优秀的软件工作者不满意瀑布软件开发方法的交付成果，并在各自工作实践中总结了各种新的软件开发方法，例如我们现在经常听说的Scrum和极限编程，都是在那个时代涌现出来的软件开发方法。
2001年，17位软件大师齐聚美国犹他州的一个小镇——雪鸟（Snowbird），总结了当时涌现的这些轻量级软件开发方法所具备的特点，共同发表了“敏捷宣言”，提出敏捷软件开发方法应该遵循的十二原则，见附录A。与会人员一致同意，凡符合这一宣言所倡导的价值观且遵循十二开发原则的方法均可被认为是“敏捷软件开发方法”。因此，“敏捷软件开发方法”这一说法从其诞生开始就是一簇软件开发方法的代名词，而不是特指某一种软件开发方法。
敏捷软件开发方法强调发挥人的主观能动性，提倡面对面沟通、拥抱变化、通过迭代和增量开发尽早交付有价值的软件。此时，很多团队已认识到，软件开发实际上是一个不断迭代学习的过程，即软件工程师需要快速学习并理解领域知识，并将其转化成数字世界的表达形式，通过与业务专家的交流讨论来学习并持续迭代这个过程。一个软件交付计划被划分成多个迭代，强调在每个迭代结束时应该得到可运行的软件，如图1-2所示。
图1-2 迭代开发，多批次部署发布
与瀑布软件开发方法只在项目交付后期才能看到可运行的软件相比，敏捷软件开发方法在这方面有很大的进步。“持续集成”作为敏捷开发方法中的一个工程实践，率先被更广泛的IT组织所接受，即便那些没有采纳敏捷开发方法的团队也会使用它，因为其强调的频繁自动化构建和自动化测试减少了质量保障团队的重复工作量，也排除了开发团队与质量保障团队之间的沟通障碍。
当时的主流软件需求仍旧是来自企业级定制软件开发。虽然敏捷开发方法使用的是迭代模型，但两次软件发布之间的间隔时间仍旧较长（通常是数月，甚至一年以上）。因此，业务人员与研发团队之间关于需求变更和研发效率的矛盾仍旧是主要矛盾。系统的部署发布工作在整个发布周期中所占用的时间和成本相对较小，部署和运维工作还不是突出矛盾。另外，部署活动通常由专门的技术运维团队执行，产品研发团队对其无感。
在这一时期，无论瀑布开发还是敏捷开发，在软件行业中最重要的关注点都是可交付的软件包本身，即如何快速地将软件需求变为可交付的软件包。
DevOps的萌芽源于2008年8月敏捷大会多伦多站的一个临时话题“敏捷基础设施”（Agile Infrastructure）。当时比利时独立IT咨询师Patrick Debois非常感兴趣，并且分享了关于“将敏捷实践应用于运维领域”。2009年10月，Patrick在比利时的根特组织了一个“DevOpsDays”社区会议，并正式启用了“DevOps”这个术语。
2010年“The Agile Admin”网站上发表的一篇题为“What is DevOps”（什么是DevOps）的文章中指出：“DevOps是一组概念集合的代称，虽然并非全部都是新概念，但它们已经催化为一种运动，并迅速在整个技术社区中传播。”同时，该文章也给出了其原始定义，即“DevOps是运维工程师和开发工程师参与整个服务生命周期（从设计到开发再到生产支持）的一组实践”，并提出，DevOps应该倡导运维人员更多地使用和开发人员使用的相同技术来进行系统运维工作。
DevOps在维基百科上的定义也在随着时间的推进而不断变化着。截止到2017年，其定义为：
DevOps是一种软件工程文化和实践，旨在统一整合软件开发和软件运维。DevOps运动的主要特点是强烈倡导对构建软件的所有环节（从集成、测试、发布到部署和基础架构管理）进行全面的自动化和监控。DevOps的目标是缩短开发周期，提高部署频率和更可靠地发布，与业务目标保持一致。
事实上，到写作本书之时，业界对DevOps并没有统一的标准定义。正如“敏捷”一样，每一位从业者、每一个企业都有自己所理解的DevOps。有些人认为DevOps是敏捷的一个子集，有些人认为“敏捷做对了，就是DevOps”，还有人则将DevOps看作围绕自动化实施的一套实践，或多或少与敏捷有些关联性。
从历史时间点上来看，DevOps源于敏捷思想和实践在运维领域的应用，但当时的实操指导性不足，而近乎同期出版的《持续交付》一书使其更加具象化，在企业实践方面更具有可操作性。书中给出了一系列的原则、方法与实践，使DevOps运动的参与者有线索可循，例如持续交付中强烈倡导的“一切皆代码，自动化一切，部署流水线尽早反馈”等。
DevOps并非一个标准、一种模式或者一套固定方法，而是一种IT组织管理的发展趋势，也就是说，通过多种方式打破IT职能部门之间的隔阂，改变IT组织内部的原有合作模式，使之更紧密结合，从而促进业务迭代速度更快。这种发展趋势将会引起IT组织内部原有角色与分工的变化，甚至范围更大，会影响到相关的业务组织。对互联网公司来说，其软件产品对业务发展起到极其关键的作用，业务结果与IT效能强关联，因此顺应这一发展趋势的动力更加明显和迫切。
既然DevOps是一种组织管理的发展趋势，那么它就是IT领域普适的。对于不同行业、不同企业中的IT组织，需要根据其所在行业的行业特点以及企业实际状况进行一系列的管理定制。
2006年，Jez Humble、Chris Read和Dan North共同发表了一篇题为“The Deployment Production Line”（部署生产线）的文章。文中讨论了软件部署带来的生产效率问题，并首次提出“部署生产线”模式：
……测试和部署是软件开发过程中最困难且耗时的阶段。即使团队已经使用自动构建完成了代码的测试工作，也需要几天时间做生产部署的情况仍旧很常见……我们描述的原则和实践使你可以一键创建、配置和部署新的环境。
……通过多阶段自动化工作流程，测试和部署过程可以完全自动化。利用这种“部署生产线”，可以将已经过验证的代码快速部署到生产环境中，并且一旦发生问题，就可以轻松地回退到以前的版本。
该文章的3位作者当年均就职于ThoughtWorks公司，而该公司是敏捷软件开发方法的践行者、倡导者和推广者。该公司使用的软件开发方法也源自极限编程方法。作者通过各自的实践总结出了“部署流水线”模式的雏形，并且对如何使自动化部署活动更轻松给出了以下4条指导原则。
（1）每个构建阶段都应该交付可工作的软件，即中间产物的生成（例如搭建软件框架）不应该是一个单独的阶段。
（2）用同一个制品（artifact）向不同类型的环境部署，即将其与运行时配置分开管理。
（3）自动化测试和部署，即根据测试目的，分成几个独立的质量关卡。
（4）这个部署生产线设计也应该随着你的应用程序的发展而不断演进。
2007年，ThoughtWorks公司的Dave Farley也发表了一篇题为“The Deployment Pipeline- Extending the range of Continuous Integration”（部署流水线——持续集成的延伸）的文章。文中指出，部署流水线就是通过自动化方式将多个质量验证关卡及其中的验证内容联系在一起，如图1-3所示。
图1-3 Dave Farley在2007年定义的部署流水线
同年12月，ThoughtWorks在北京正式组建了产品研发团队，启动了以这种部署流水线为指导思想的软件持续发布管理工具的研发。当时Jez Humble是产品经理，我负责该产品的交付与业务分析。该产品的第一个版本发布于2008年7月，取名为Cruise（现名为GoCD）。其最重要的一个功能特性就是“部署流水线”（deployment pipeline）。而且很多特性设计（包括内置的制品仓库、多阶段之间的制品引用）也体现了“一次构建，多次使用”的原则。
在开发GoCD期间，Jez Humble和Dave Farley合著了《持续交付》一书，英文版于2010年正式出版，该书于2011年获得Jolt杰出大奖，中文版也于2011年在国内上市，这标志着“持续交付”这一术语的正式诞生。Jez Humble说：“持续交付是一种能力，也就是说，能够以可持续方式，安全快速地把代码变更（包括特性、配置、缺陷和试验）部署到生产环境上，让用户使用。”本书将这一定义称为“持续交付1.0”。
在《持续交付》一书中，讲述了持续交付1.0所遵循的理念、原则和众多方法与实践，并在该书最后一章指出：“它不仅仅是一种新的软件交付方法论，而且对依赖软件的业务来说，是一个全新的范式[1]。”
持续交付1.0提供的很多原则及方法是DevOps运动的具体实操指引，它们可以为企业的IT团队将DevOps运动落地实施提供非常具体的指导，如图1-4所示。
图1-4 持续交付将发布权交还给业务方
从所涉及的协作角色来看，敏捷开发更多地涉及产品需求方、软件开发工程师和软件测试工程师。在历史上，DevOps更多地涉及软件研发团队（包括开发工程师和测试工程师）与运维工程师，而持续交付1.0涉及产品需求方、软件研发团队和运维工程师，如图1-5所示。
图1-5 相关概念在组织角色的主要触达点
持续部署与持续交付
很多人认为，持续部署（continuous deployment）是持续交付（continuous delivery）的进阶状态，是指代码提交后一旦成功通过所有质量验证，就立即自动部署到生产环境中，不需要任何人的审批。事实上，“部署”与“交付”这两个主干词的意义并不相同。
“部署”是一种技术领域的操作，也就是说，从某处获取软件包，并按照预先设计的方案将其安装到计算节点上，并确保系统可以正常启动，但它并不一定意味着“必须包含业务功能的发布或交付”。“交付”则是一个业务决策活动，通常也被称为“发布”，也就是说，如果将新构建的特性交付到客户（用户）手中，用户就可以看到并使用它们。
之所以“部署”与“发布”几乎成为等价词，是历史原因造成的。很久以前，软件的发布周期较长，每次新功能部署之后就会立即发布。久而久之，“部署”就成了“发布”的代名词。为了保证软件质量，IT部门通常不允许无关代码（即与本次发布新特性集合无关，例如未开发完成的功能、不完善的功能集）被带到生产环境中。因此，每次部署就一定是重大功能的发布。
随着互联网软件的出现，“部署”和“发布”内容与频率不同的情况也是很常见的。我们可以向环境多次部署，但只有当业务需要时才向用户发布，如图1-4中的箭头所示。例如，Facebook公司的发布工程师Chuck Rossi在2011年该公司举办的技术分享会上指出：“我们现在每天会对Facebook网站进行一次部署操作……Facebook公司在半年后将要主推的功能特性，现在已经上线了，只是用户看不到而已。”
持续交付1.0关注于“从提交代码到产品发布”的过程，如图1-6所示，并且提供了一系列工作原则和优秀的实践方法，可以提升软件开发活动的效率。
图1-6 持续交付1.0的关注点
但是，我在实际咨询过程中发现，一些软件功能在开发完成之后，对用户或者业务来说，并没有产生什么影响，有些功能根本没有用户来使用。可是，这些功能的确花费了团队的很多精力才设计实现。这是一种巨大的浪费。这种“无用”的功能生产得越多，浪费就越大。我们是否可以找到一些方法，让我们付出的努力对业务改善更加有效，或者只用很少的成本就可以验证对业务无效呢？
2011年出版的《精益创业》一书给了我一些启示。其核心思想是，开发新产品时，先做出一个简单的原型——最小化可行产品（Minimum Viable Product，MVP），这个原型的目标并不是马上生产出一个完美的产品，而是为了验证自己心中的商业假设。得到用户的真实反馈后，从每次试验的结果中学习，再快速迭代，持续修正，在资源耗尽前从迷雾中找到通往成功的道路，最终适应市场的需求。
Eric Rise在书中强调，精益创业就是一个“开发—测量—认知”的验证学习过程，如图1-7所示。也就是说，把创意快速转化为产品，衡量顾客的反馈，然后再决定是改弦更张，还是坚守不移。
图1-7 “开发—测量—认知”环
该书主要关注于创业初始阶段，将精益思想贯穿于产品“从0到1”的过程。事实上，它也可以用于产品“从1到n”的过程中。
1996年，Womack、Jones和Roos在《精益思想》一书中指出：精益思想是指导企业根据用户需求，定义企业生产价值，按照价值流来组织全部生产活动，使价值在生产活动之间流动起来，由需求拉动产品的生产，从而识别整个生产过程中不经意间产生的浪费，并消除之。
在精益管理理论中，“浪费”是指从客户角度出发，对优质产品与良好服务不增加价值的生产活动或管理流程。并指出，业务生产中所有活动都可以归结为以下两种活动，也就是增加价值的活动和不增加价值的活动，而不增加价值的活动就是浪费。在被归类为“浪费”的活动中，又可以分为必要的非增值活动和纯粹的浪费。必要的非增值活动是指从客户的角度看虽没有价值，却可以避免（潜在的）更大的浪费或降低系统性风险的活动，如图1-8所示。
图1-8 软件产品开发中的活动浪费
例如，生产流水线上的装配工作是增值活动，质量检查是必要的非增值活动，而因材料供应不足产生的生产等待以及因质量缺陷导致的返工都被认为是浪费。在软件产品服务的全生命周期中，也同样包含多种“浪费”，例如，无效果的功能特性、各生产环节中的等待（如图1-9所示）、没人看的文档、软件缺陷、机械性的重复工作等。
图1-9 用户视角的增值活动与浪费
尽管“消除所有浪费”几乎是不可能的，但是，我们仍旧要全面贯彻“识别和消除一切浪费”的理念，持续不断地优化流程与工作方式，达到高质量、低成本、无风险地快速交付客户价值的目的。
自2009年Flickr（一个聚合全球知名热门图片分享网站）声称其网站每天部署10次之时起，“主干开发+持续集成+持续发布”已成为硅谷知名互联网公司应对VUCA环境的一种主流软件研发管理模式。这种变化的原动力并不是来自技术团队本身，而是来自业务与产品方的诉求。为了在VUCA环境中更快地了解海量用户，快速验证大量业务假设和解决方案，他们改变了业务探索的模式，并催生了软件研发管理模式的改变，两种模式相互促进，从而形成了互联网软件产品研发管理的双环模式，即“持续交付2.0”，如图1-10所示。
图1-10 持续交付2.0的双环模型
“持续交付2.0”是一种产品研发管理思维框架。它将精益创业与持续交付1.0相结合，强调业务与IT间的快速闭环，以“精益思想”为指导，全面贯彻“识别和消除一切浪费”的理念，通过一系列工作原则与实践，帮助企业以一种可持续方式，高质量、低成本、无风险地快速交付客户价值。
对企业来说，开发软件产品的目标是创造客户价值。因此，我们不应该仅仅关注快速开发软件功能，同时还应该关注我们所交付的软件的业务正确性，以及如何以有限的资源快速验证和解决业务问题。也就是说，不断探索发现真正要解决的业务问题，提出科学的目标，设计最小可行解决方案。通过快速实现解决方案并从真实反馈中收集数据，以验证该问题是否得以解决。这是一个从业务问题出发，到业务问题解决的完整业务闭环，简称为持续交付“8”字环。
它由两个相连的环组成（见图1-10）：第一个环为“探索环”，其主要目标是识别和定义业务问题，并制订出最小可行解决方案进入第二个环；第二个环为“验证环”，其主要目标是以最快速度交付最小可行方案，可靠地收集真实反馈，并分析和验证业务问题的解决效果，以便决定下一步行动。
探索环包含4个可持续循环步骤，分别是提问、锚定、共创和精炼。
（1）提问，即定义问题。通过有针对性的提问，找出客户的具体需求，并找出具体需求后的原因，即具体需求后要解决的根本问题。在提问中形成团队期望达成的业务目标或者想要解决的业务问题。如果问题无法清晰定义，那么找到的答案自然就会有偏差。因此，在寻找答案之前，应该先清晰地定义问题。
（2）锚定，即定义结果目标指示器。针对问题进行信息收集，经过分析，去除干扰信息，识别问题假设，得到适当的衡量指标项，并用其描述现在的状况，同时讨论并定义我们接下来的行动所期望的结果。
（3）共创，即共同探索和创造解决或验证该问题的多种具有可行性的解决方案。
（4）精炼，即对所有的可行试验方案进行选择，找到最小可行性解决方案，它既可能是单个方案，也可能是多个方案的组合。
验证环也包含4个可持续循环的步骤，分别是构建、运行、监测和决策。
（1）构建，是指根据非数字化描述，将最小可行性解决方案准确地转换成符合质量要求的软件包。
（2）运行，是指将达到质量要求的软件包部署到生产环境或交到用户手中，并使之为用户提供服务。
（3）监测，是指收集生产系统中产生的数据，对系统进行监控，确保其正常运行。同时将业务数据以适当的形式及时呈现出来。
（4）决策，是指将收集到的数据信息与探索环得出的对应目标进行对比分析，做出决策，确定下一步的方向。
探索环就像是一部车子的前轮，把握前进方向。验证环则像车子的后轮，使车子平稳且驱动快速前进。它们之间相互促进，探索环产生的可行性方案规模越小，越能够提高验证环的运转速度；如果价值验证环能够提高运转速度，则有利于探索环尽早得到真实反馈，有利于快速决策，及时对前进方向进行验证或调整。
“持续交付2.0”是指企业能够以可持续发展的方式，在高质量、低成本及无风险的前提下，不断缩短持续交付“8”字环周期，从而与企业外部频繁互动，获得及时且真实的反馈，最终创造更多客户价值的能力。下面逐一介绍缩短持续交付“8”字环周期的4个核心工作原则。
在咨询的过程中，最常听到的一句话就是：“我们最大的问题是人力不足。”无论公司实力如何，想做的事情永远超过自己的交付能力，需求永远做不完。然而，做得多就一定有效吗？我们应该抵住“通过大量计划来构建最佳功能”的诱惑，坚持少做，想办法对新创意尽早验证。
Moran在Do It Wrong Quickly一书中写道：“Netflix认为，他们想做的事情中，可能有90%是错误的。”Ronny Kohavi等共同发布的文章“Online Experimentation at Microsoft”中也指出，在微软，“那些旨在改进关键指标而精心设计和开发的功能特性中，只有1/3左右成功地改进了关键指标”。
正如当年Mike Krieger（Instagram的联合创始人兼CTO）被问及“5个工程师如何支持4000万用户”时所说的那样——“少做，先做简单的事情”。
复杂的业务问题中一定会包含很多不确定因素，它们会影响问题解决的速度和质量。在实施解决方案之前，通过对问题的层层分解，可以让团队更了解业务，更早识别出风险。企业应该坚信，即便是很大的课题或者大范围的变更，也可以将其分解为一系列小变更，快速解决，并得到反馈，从而尽早消除风险。与其设计一大堆特性，再策划一个持续数月的一次性发布，不如持续不断地尝试新想法，并各自独立发布给用户。
当把问题分解以后，如果我们仍旧只是一味地埋头苦干，而忽视对每项已完成工作的结果反馈，那么就失去了由问题分解带来的另一半收益，确认风险降低或解除。只有通过快速反馈，我们才能尽早了解所完成工作的质量和效果。
无论做了什么样的改进，如果无法以某种方式衡量它的结果，就无法证明真的得到了改进。在着手解决每个问题之前，我们都要找到适当的衡量方式，并将其与对应的功能需求放在同等重要的位置上，一起完成。
某数据公司就曾因无度量数据，而无法提出有效改进方向的情况。该系统是一个数据标注志愿者招募考试系统。虽然它被分成多个迭代，每个迭代都发布了很多功能，但是，由于没有实现产品人员所关注的数据收集与统计分析功能，使得团队仅知道人们可以使用这个系统完成工作，却无法知道是否能够高效完成工作，也很难提出下一步的产品优化方向。
我们讨论了“持续交付2.0”的指导思想、工作理念和核心原则。大家很容易意识到，它对适应快速变化的市场环境和激烈的市场竞争是非常有效的。那么，企业如何让“持续交付2.0”成为一种组织能力，成为组织的DNA，持续发挥作用，从而领先竞争对手，成为自己的一种竞争优势呢？
持续交付双环模型的实施与改进将涉及企业内的多个部门与不同的角色，无法由某个部门独立实施，必须在整个组织范围内贯彻执行“持续交付2.0”的思想、理念与原则。企业需要在组织管理机制、基础设施以及软件系统架构3个方面付诸行动，而每一个方面都包含多项内容，如图1-11所示。
图1-11 持续交付七巧板
条条大路通罗马，而且，罗马也不是一天建成的。每个企业的实施路径可能各不相同，所需要的周期也各有长短，对各方面的能力需求也不完全一致。正如中国传统玩具七巧板一样，每个企业都应根据自己的意愿和诉求，拼出属于自己的持续交付实践地图。
“持续交付2.0”建立在“持续交付1.0”的“可持续地快速发布软件服务”及精益创业的“最小化可行产品”两种理念基础之上，强调要以业务为导向，从一开始就将业务问题进行分解，并通过不断的科学探索与快速验证，减少浪费的同时，快速找到正确的业务前进方向，简称为“双环模型”。因此，其涉及组织中的多个团队，需要各个团队之间紧密合作，才能缩短“8”字环的周期，如图1-12所示。
图1-12 持续交付2.0的相关角色
“持续交付2.0”的4个核心工作原则是坚持少做、持续分解问题、坚持快速反馈和持续改进并衡量。只有这样，才能不断缩短持续交付“8”字环的运行周期，提升用户反馈速度，从而提高业务的敏捷性。这要求管理者跳出原有软件交付管理思维模式，摆脱“害怕失败”的恐惧感，拥抱“科学探索—快速验证”思维方法，快速试错，提升持续交付能力，进而发展现有业务，并快速开创新业务。
[1] 范式（paradigm）就是指在某一学科或领域内的一种哲学理论框架，它由理念（或思考模式）及其指导下的一系列研究方法与标准组成。简言之，“范式=理念+方法”。
“们最优先要做的是通过尽早、持续地交付有价值的软件来使客户满意”，这是敏捷开发十二原则的第一条。然而，对于“什么是价值？”这个问题，组织中的每个人可能都会有自己的看法。管理大师彼得 • 德鲁克（Peter F. Drucker）说：“价值只能由企业外部的客户来定义。”一个新产品的推出，可能是灵机一动的产物，也可能是大量市场调查的结果，能否被市场接受，只有用户说了算。如今，客户已不再满足于类似“办公室的打印机能够清晰打印”这种基本功能需求，而是有了更多的高级需求。
如何发现和识别用户的真实需求是目前所有企业面临的难题。本章主要讨论持续交付“8”字环中的探索环（如图2-1中的方框所示）中的原则与方法。通过一系列方法，帮助大家分析和解决这一问题。
图2-1 持续交付“8”字环中的探索环
当很多企业设计开发新产品时，项目早期会采用“概念验证”或“产品原型法”，收集潜在用户的反馈，以降低产品方向产生错误的风险。一旦接受了这些概念验证与产品原型后，企业就会启动一个历时较长的产品完整功能开发过程。而相对于最终产品，这些概念验证与产品原型本身就是不完整的，因此总会有一些差异。
现在的市场变化很快，当花大量时间将产品功能全部开发完成后，产品常会因为潜在用户对原型的理解偏差，或者用户需求发生了变化，导致当初的设计不再适应市场需求。事实上，这反映了产品或服务开发过程中常见的风险假设。一是用户假设，即我们提供的产品服务是针对某类潜在用户人群的需求的假设；二是问题假设，即目标用户群之所以有这种需求，是因为他们的确存在某些痛点（或问题）需要解决的假设；三是解决方案假设，即我们提供的解决方案可以解决这些痛点或问题，而且比其他现存的解决方案都有效且高效。
这3类假设中，任何一个假设不成立，都会导致我们事倍功半，甚至前功尽弃。因此，探索环的目标就是要持续识别和定义这些有价值的假设，选择并验证其中风险最高或最易验证的价值假设，并借助价值验证环得到数据反馈，以便深入理解用户需求，把握业务前进方向。
例如，持续交付工具GoCD（一款面向软件研发过程管理的产品）在其启动之初，目标客户就被定义为那些希望以敏捷开发方式交付软件，并希望提升软件交付速度与质量的中小软件企业或团队，直到现在也没有变化。产品希望解决的主要问题仍旧是这些客户在开发软件过程中的集成与发布管理问题。然而，在2007年项目启动时曾经规划的近两百个功能特性中，到目前为止，几乎有一半的规划特性被废弃了。因为这些功能特性并不是解决中小软件企业的软件集成与发布管理问题的最佳解决方案。这也说明，在2007年时，该产品解决方案中的很多假设是不成立的。
该产品研发过程中实际上一直秉承“持续交付2.0”的理念，通过将大特性分解成多个小功能，持续快速发布（团队每周使用自己的最新版本，并且每两周对外部客户发布一次），获得真实用户反馈，从而调整产品功能策略，为产品成功打下了基础。
因此，在探索环中，我们就是要从业务问题出发，与团队一起，共同找出这3类假设，通过分析评估，确认最大的风险点，并制订相关的衡量指标，找出相应的最小可行的验证方案。然后再借助验证环的高速运转，尽早获得反馈，并根据衡量指标来验证这些风险点。
探索环（Discovery Loop）是指团队通过一系列工作环节，能够识别和定义业务问题，制订相应的衡量指标，并找出低成本且可快速验证的最小可行解决方案（Minimum Viable Solution）。这是一个理解真实需求、判断优先级、再评估需求的过程，具体包括以下4个环节。
（1）提问：通过有针对性的提问与讨论，找出团队期望达成的业务目标或者希望解决的业务本质问题。
（2）锚定：针对该问题进行信息收集，经过分析，去除干扰信息，得到适当的指标项，并用其描述现在的状况，以及我们希望的结果或状态。
（3）共创：通过深入讨论，找到所有可能的解决方案。它是一个深入理解和验证问题的环节。
（4）精炼：结合实际情况，进行评估，筛选出最小可行性解决方案或方案的集合，以作为验证环的输入。等待它的真实反馈，再做价值判断。
以下详述实施这4个关键步骤的具体方法。
该环节是持续交付“8”字环的起点。其目的在于通过不断地提问，澄清客户需求背后要实现的真正目标，以便找寻更多解决问题的方法，同时也有助于团队成员从业务问题出发，充分理解业务问题。
敏捷软件开发方法已经非常流行，“用户故事”作为一种描述需求的方式也被广泛采用，然而，软件研发团队更关注“需求是什么”的问题。例如，我们经常遇到下面这种团队需求讨论的场景。
业务人员：你按照这个文档中的业务流程和界面样例开发就行了。
开发人员：这个流程走到这里时，遇到（……）这种情况时，这个字段里应该包含哪些选项？
业务人员：你可以这么做（……）
开发人员：那这样处理以后，接下来怎么办？
上述的提问目标是澄清用户的直接需求（即业务人员提出的解决方案）。从“满足客户需求”的服务心态来看，这样的工作方式也没有什么问题。然而，按照业务人员编写的文档开发，就能满足他们真实的需求吗？
探索环中的提问环节要求不仅仅是找到“实现什么”以及“如何实现”，更是要了解客户需求背后要解决的真正问题“为什么要实现”，以便规划更加方便快捷的验证方案或解决方案。
由于角色惯性，从开始讨论的那一刻起，我们就很容易跳过最重要的问题，也就是说，如何更好地为客户解决真正的问题，而这恰恰是我们应该做的。因此，要通过持续提问，对问题进行深入探究。
设想一下，我们正举办一个为期一天且付费的小型线下聚会，主题是“DevOps和持续交付2.0”。午休期间，有位听众希望下午能够喝上一杯星巴克咖啡。为了更好地为客户服务，作为主办方，我们耐心地询问他“需要哪种口味的咖啡？”“热的，还是冰的？”“大杯，还是中杯？”“希望什么时间拿到？”。
然而，所有这些问题都只是在问“做什么”和“怎么做”，并没有任何一句问及原因。如果客户想要解决的真正问题是“在下午听讲时不会因为困意而错过了听讲”，我们也许有很多方法解决他的诉求？也许我们可以录制视频，这样即使参与者在过程中开小差，在沙龙结束后，他们也能够回顾一下沙龙的所有内容。我们还有更多的方法来满足用户不错过精彩内容的需求，例如：
（1）沙龙的组织者可以将演讲模式改成互动参与模式，增加互动环节；
（2）安排站立区，允许参与者走动；
（3）发言者的发言更有吸引力；
（4）在会场角落提供其他冷热饮品。
这个假想的案例可能并不准确，但你一定已经领会了其中的含义。的确，为了解决客户的问题，我们可能会找到很多种解决方案，但前提是我们必须发现“正确的需求”。所谓“正确的需求”，是那些能够解决客户真正想要解决的问题，而不一定是由客户提出的解决方案。
因此，当我们接到一个工作任务时，我们应该更多地深入理解所要解决的问题，了解其背后的真正原因，不要过早地进入解决方案环节的讨论，而忽视了对问题的讨论。这样才能更好地解决问题，而不仅仅是完成软件功能的开发工作。
在“提问”这一环节中，组织者需要注意以下4点。
（1）问题域的提出方及解决方案的提供方代表尽量到场，参与讨论。
（2） 多问几个“为什么”。尽量避免因为感觉自己熟悉这个问题域，而过早地放弃探索。
（3）在条件允许的情况下，尽可能收集数据信息，以便作为问题理解和分析的佐证。
（4）移情，使用同理心。设身处地站在客户或问题提出方的角度思考问题，还原客户问题的场景。
当我们已经选定要解决的问题领域时，接下来就要确定我们要达成的具体目标与结果。“锚定”是设定目标以及目标分解的讨论过程，其目的是确定要达成的目标以及可以衡量它的指标，并能够指导后续的共创与精炼活动。
我们应该尽量避免模糊不清的目标，它会影响团队成员之间的交流。清晰地描述目标让我们自己知道当前所在的位置，离目标还有多远。只有这样，我们才能以终为始，结合现实环境，选择和制订相对合理的解决方案。清晰的目标通常是具体且可衡量的，并有时间限定。如果没有时间限定，它很可能会成为一个企业愿景，就无法直接指导企业日常生产管理的具体活动，如图2-2所示。
图2-2 愿景与目标
最好的方式是让目标可客观衡量。有时，我们很难立即拿出一个可衡量的标准。但是，我们可以通过描述目标状态，并根据这一目标状态可能产生的结果来寻找可客观衡量的目标结果。如何发现可衡量的指标呢？我们可以这样来思考：如果某个产品满足了用户的需求，那么用户会非常满意，而用户的满意会带来复购，同时会有更好的品牌知名度，从而带来更多的用户。那么，我们是否可以设定用户数量和营业收入作为产品的指标维度，如图2-3所示。这两个指标的特点是：容易收集和容易量化，这有利于降低收集衡量指标的成本。
图2-3 易收集、易量化的目标
例如，对某个提供新闻信息流服务（Feed流）的移动应用产品来说，企业希望“让用户喜欢它所提供的信息服务”。然而，“喜欢”是一个很难量化和佐证的目标，这就需要进一步锚定。如图2-4所示，我们可以推断，假如用户喜欢这个产品，那么：
（1）用户会阅读更多的内容，而且会花费更长的时间。
（2）用户会将产品推荐给朋友，朋友们也会喜欢并成为产品的用户。
图2-4 Feed流产品的指标选择示意图
从上面的假设中，我们提及3个易收集和易衡量的指标，它们分别是推荐朋友数、单位时间内的用户数和单个用户平均使用时长。这3个指标都能作为企业目标的指标维度。到底选择哪些指标作为目标，需要根据企业现状、产品处在的生命周期阶段以及外部市场环境进行综合判断来决定。
另外，目标需要针对不同的组织层级而设定。一个企业的总目标应该是整个企业范围内的目标，而不应该只是企业中某个团队的目标。一旦制订了企业总目标，企业中的每个团队都要以它为方向，根据自身团队的职责与性质，制订各自相应的目标，并为实现它而集思广益，群策群力。例如，提高用户操作流畅度，提高API请求响应速度，推荐给用户更多他们喜欢的内容，提高服务的稳定性，等等（如图2-5所示）。
图2-5 总目标与子目标
对于目标的选择，应该遵循两点：一是识别价值指标，而非虚荣指标；二是指标应该可衡量且可获取，易于客观对比。虚荣指标这一概念是《精益创业》一书中提及的。它是指让你的产品效果看起来很好的那些指标，如注册用户数、网站最高访问量等。虽然这些指标在一定程度上反映了产品的状态，但并不是最有价值的衡量指标。相比较而言，日活跃用户、月活跃用户、日留存率、月留存率、有效购买率等可能是更好的价值衡量指标。
当然，对于更加具体的问题域或者产品阶段，我们还会发现比活跃用户、留存率等更恰当的价值衡量指标。这需要团队根据业务特点及阶段侧重点自行发掘和定义。
共创就是指：当我们制订了想要达到的目标后，团队为设法验证或达成目标而找出多种可行性解决方案的过程。共创要在理解问题和制订目标之后进行，否则会因为缺少目标约束，使得解决方案容易过于发散。这一环节的产出应该是很多带有量化指示器的解决方案。事实上，每一个解决方案都是基于一定的假设条件或猜想得出的，而每一个假设都等同于一个风险项。因此，每个解决方案都只是“试验方案”，试图解决问题域中的某个具体问题。
这一环节的分析方法有很多，在这里介绍其中的两个，一是“量化式影响地图”；二是“用户旅行地图”。
Gojko Adzic在《影响地图：让你的软件产生真正的影响力》中解释了什么是影响地图，它是用Why-Who-How-What的分析法，通过结构化的显示方式（如图2-6a所示），让团队寻找达成业务目标的方法。对科学验证来说，这还显得不够完整。我们不但应该知道“做XXX可以影响YYY”，还应该了解当前的影响程度，以及对实施后达到效果的预期。也就是，从业务问题域出发，按“角色—影响—方案—量化”的顺序进行讨论，如图2-6b所示，从而尽可能多地发掘出可行性解决方案。我们可以称它为“量化式影响地图”。
图2-6 量化式影响地图
量化式影响地图的具体制作步骤如下所示。
（1）角色：列出该问题域所涉及的人或角色。
（2）影响：针对每类人或角色，思考他们有哪些途径可以影响该问题的解决（既可能是积极的影响，也可能是消极的影响）。
（3）方案：针对每一种途径，讨论并列出所有可能影响该问题的解决方案。
（4）量化：如果可能，尽量为每个解决方案定义一个可衡量的指标项。
下面，我们以某移动App应用的用户增长目标（两个月后达到20万用户）为例，可能涉及的内外部人员包括：（1）App的使用者；（2）推广渠道；（3）客服团队；（4）产品研发运营团队；（5）内容提供商以及更多角色。按照上面给出的4个步骤，列出多种可实施方案，如图2-7所示。
图2-7 量化式影响地图示例
我们有时无法马上对所有指标进行量化。例如还没有收集和统计过与指标相关的数据。此时可临时性地收集一部分数据，并进行相应的推断，通过一段时间的运行，进行指标量化的校准即可。例如，某公司希望提升研发效率10%（目标），其中一个方案是提升运维人员的部署操作效率。但是，之前并没有收集过部署操作所需时间。因此，我们利用一周时间，对当周进行的两次部署任务进行了数据采集，并据此进行推断，共同定义了团队认可的部署操作时间周期。另一种可能是希望衡量的指标较难直接量化。此时可通过一些过程指标或相近指标来替代。需要注意的是，这两种情况都存在一定的偏差，因此在数据的应用过程中，应该格外注意。
用户旅行地图（user journey map）是指以可视化方式，将用户与产品或服务之间的互动，按业务流分阶段呈现出来。用户旅行地图通常包括以下4部分。
（1）用户接触点：旅程中的重要关键时刻（如短信消息、软件操作界面等）。
（2）接触阶段：将整个旅程按顺序划分成不同的阶段（例如商品查询、下单、付款等）。
（3）用户痛点：在用户与系统服务的互动过程中，对什么感到不足。
（4）用户情绪：在旅程中的每一个阶段，有哪些情绪变化。
用户旅行地图的制作步骤如下。
（1）定义用户：明确指定为某一类用户定义用户旅行地图。
（2）定义任务或阶段：在这些任务或阶段中，会有哪些不同事件发生。
（3）用户与服务接触点的互动行为：在不同事件发生时，用户如何操作，操作顺序如何。
（4）用户的动机：用户在每个操作背后会产生什么样的想法，有什么痛点。
（5）用户的心理：在每个操作中，用户心理会有哪些变化，情绪会如何起伏。
当将其操作流可视化以后，捕获每个阶段的相关信息（如操作时间、等待时间、操作次数等数据信息），通过用户痛点发现其中可能存在的问题，从而提出相应的解决方案，以改善最初的业务目标。这些解决方案既可能是对原有流程的全面改造，也可能是对某个环节的局部优化。
例如，对线上电商服务来说，一个重要的问题领域是如何缩短从“用户开始查找商品”到“最终收取货物”之间的周期。针对这个问题，我们可以通过对整个流程建模（如图2-8所示），对流程的各环节进行分析（该环节参与的角色、所花费时间及成本）。当获得问题症结的假设后，通过创建新的流程或者选择一些环节进行方案优化，并确定量化指示器。
图2-8 电商平台的业务流程示意图
对电商平台上的商家服务来说，假如电商平台的目标是“提升商家满意度”，那么，很可能缩短账期，商家就会对平台更加满意，而这可能需要对原有的财务结算系统和商家管理系统进行改造升级。
在“共创”这一环节中，需要注意两个陷阱，分别是分析瘫痪（paralysis by analysis）和直觉决策（extinct by instinct）。分析瘫痪是指因为过度分析（或过度思考）而无法决策或采取行动，最终影响结果产出的一种状态。通常是由于有太多的细节选项，或者过于寻求最佳或“完美”的解决方案，并担心做出任何可能导致错误结果的决定。而直觉决策是指不做分析，基于匆忙的判断或直觉反应而做出致命的决定。它是与分析瘫痪相反的另一个极端。
同时，值得注意的是，很多解决方案产生的结果是相互影响和关联的。一个解决方案可能会影响多个结果指示器。
精炼环节就是对共创环节中得出的众多方案进行评估，从中筛选出团队认为最小可行性解决方案的过程。评估因素包括备选方案的实施成本、时间与人力、效果反馈周期，以及该方案对业务目标的影响程度。
在VUCA环境中，时间是最大的隐形成本。如果实现方案所需时间太多，我们就可能错失了机会。而且，某些方案实施以后，需要经过一定的执行周期，才能看到它带来的真实效果，这也会增加时间成本。我们希望尽可能多地选择试验方案，因为每个方案都有可能有助于解决我们的问题，达成我们的目标。
作为一个电商网站，Etsy的搜索导航条在2007年如图2-9所示。尽管当时并没有认为这个设计是永久性的，但直到2012年，它也没有发生很大的变化。事实上，大多数买家并不知道怎么用它。例如，几乎根本没有人使用其中的搜索项“商店”（Shops）。
图2-9 Etsy的搜索导航条
在这5年中，搜索下拉框上已经增加了很多内容，承担了过多的职责，而且并不是所有项目之间都具有直接关联性。因此，团队决定对其进行大改造，于是专门成立了一个改造项目。团队成员提出了很多改造的想法和解决方案。最终他们精炼出一份任务清单，如下所列：
（1）重新设计页面上的搜索区；
（2）默认为“所有项目”；
（3）更丰富的自动化推荐提示；
（4）在搜索结果列表中给出推荐的商店；
（5）可以将常用过滤器加入搜索收藏夹；
（6）将搜索栏分别放到商品和商店页面上；
（7）删除原有的搜索下拉列表。
其中，每一项任务的开发时间都很短，而且每项改造任务的前后效果都可衡量，并且任务之间相对独立。在改造过程中，每当完成一项，都可以进行评估，并且有机会根据每一次的评估结果修订原有的项目执行计划，以更好地达到业务目标。
在上述精炼任务清单中，有一些任务是成功的，有一些任务则并不成功。如图2-10所示，在第一项改造（在页面上增加一个商品搜索区）后，用户数据显示，几乎没有用户注意到它；而在第三项改造（增加自动化推荐）后，数据效果则比较明显。
图2-10 Etsy网站搜索导航的两个优化项
因此，我们不难看出，即使是一项巨大的改造工程，其解决方案也可以是一组迷你方案的集合。精炼的目标并不是为了删除在共创阶段得出的解决方案，而是将它们按优先级排列，并让团队将解决方案进一步分解，顺序选出共同认可的最重要改进项，并确保它能够尽早被验证。
通过精炼之后，被选择的方案就可以进入验证环了。那么，如何判断我们已经准备好，可以进入验证环了呢？一个简单的方式就是你能够将探索的成果以下述形式表述出来，并且达成团队共识：
我们相信，通过实现（xxxxx这样的最小功能组合），我们的指标可以达到（yyyyy程度），说明我们关于（zzzzz）的假设是成立的。
为了能够加快探索环的速度，缩短整个“8”字环的运行周期，避免陷入“分析瘫痪”的境地，在探索环的工作中应该遵循“分解并快速试错”“一次只验证一点”“允许失败”原则。
“一次到位式”解决方案通常需要较高的实施成本，而其带来的实际效果具有较高的不确定性。由于前期投入的成本较高（即沉没成本），即使这个解决方案未能带来预期效果，团队也不愿意放弃这一方案，决策者通常选择保留它，或者仍会持续优化，使其慢慢“死去”，而这会带来不必要的产品复杂性和维护成本。
如果我们能够换一种思路，更多地使用低成本的快速试验方式，那么在相同的成本下，可以尝试更多的方法，尝试更多的次数，这意味着可能会有更多的收益。如图2-11所示，在相同的成本下，尽管快试错失败次数多，但可能会得到更多成功的想法。
图2-11 慢失败与快试错
一次只验证一个需求假设。在执行整个试验方案过程中，我们仍旧要保持开放心态，不断优化这些试验方案。时刻提醒自己，我们的目标是验证我们的假设，试验方案只是我们验证假设的手段，而不是我们的目标。
国外电商Etsy网站曾经对其商品的搜索结果页进行彻底地大改造，将商品列表的展示效果改为瀑布流式，这个功能类似于百度图片搜索结果页的无限下拉效果。也就是说，当返回多于一页的商品结果时，所有商品可以依据一定的排序规则形成一个瀑布流。用户只要向下滑动页面，商品就会持续不断地展示出来，直到所有搜索结果全部显示出来。
团队撸起袖子，闷头干了好长时间，这个改造终于可以与用户见面了。谨慎起见，他们做了一个A/B试验，结果令他们大吃一惊。因为在瀑布流的“实验组”中，有连续浏览行为的人数是40，而在“对照组”中，这一人数为80，其数据如图2-12所示。商品点击率下降了约10%，购买率下降了约22.5%，物品收藏率下降了约8%。这个“瀑布流”根本没有达到预期的效果，反而更糟糕。
图2-12 瀑布流搜索页的试验结果
（资料来源：2012年Dan McKinley的“Design for Continuous Experimentation”）
当刚刚得到这样的结果时，团队所有人都认为一定是软件中存在缺陷，才会导致这个结果。于是，团队进行了各种排查，例如将用户按浏览器和地理位置进行分片。派人到公共图书馆使用古老的计算机登录网站。团队确实发现了一些软件缺陷，但修复它们后也没有改变整体结果。
大家又怀疑是因为不同浏览器的体验不同，就针对不同的浏览器进行优化。每个优化在不同的浏览器上表现不一致。能够想到的优化都改完以后，情况也没有什么好转。最终团队接受了这样一个事实，即瀑布流方式让产品变得更糟。在这个过程中，团队一次性改变了太多的东西，很难发现任何线索，找出“罪魁祸首”。
事实上，如果仔细分析，我们会发现，在“瀑布流”这个功能背后的假设是：更快地为用户展示更多的商品，会让用户的购物体验更好，用户会购买更多的商品。而这个假设由两部分组成，分别是（1）显示越多的搜索结果给用户，页面的转化率指标越好；（2）用户越快地看到商品，页面的转化率指标越好。
事实上，我们可以找到更快速的验证方法来检验这两个假设。对于第一个假设，在现有页面上展示出当前显示数量两倍的商品数量，看是否提高了详情页的转化率。这个验证方案的实现成本应该比原来无限瀑布流的设计要少很多。事实的结论是：浏览商品落地页的用户只增加了一点点，而且这个增加量也不稳定，而在商品购买转化率上并没有变化。
对于第二个假设，可能会稍显困难。因为在原有性能的前提下，再次提升商品显示速度，可能是一个更大的技术挑战。但是，我们可以反其道而行之，也就是说，人为地在页面上增加延迟时间（如200 ms），以验证用户的购买率会下降。当然，这并不是一个完美的试验方案。不过，只要做好小流量测试，使其不大幅影响整个网站的收入，作为对“延迟时间影响用户购买行为”这一假设的验证方法，还是可以接受的。试验的最终结果是“对数据没有任何影响”。
尽管每个产品经理都希望所有方案都获得成功，但是我们却无法保证每个方案都会获得成功。但是，只要具有开放的心态，我们就可以从所有方案中都学到很多新的知识，而这些收获无论是对产品今后的成功，还是团队人员的能力提升，都具有非常重要的作用。国外著名电商网站Etsy曾经做过一次商品详情页的改版，这个商品详情页如图2-13所示。
为了促进下单转化率，产品经理打算重新设计商品详情页。他先后提供了14个试验方案，其中每个方案的改动都不是很大。例如，将价格以美元显示改成按用户所在地所使用的货币显示；将商品图片放在网页的右侧。其他方案还包含字体或按钮的大小及颜色变化等。这14个试验的最终结果是，每个方案对下单转化率都没有太多的影响，甚至有一些方案的下单转化率还有所下降。然而，在这14个试验过程中，产品团队获得了一些新的用户认知，例如用户关注哪些要素，对哪些要素不是很敏感。最终，在这些试验的基础上，该页面做了一个全面的改版，而这个版本的结果使订单转化率提升显著，该项目成为当年该公司最成功的项目。
图2-13 商品详情页
价值探索环的使用前提是团队拥抱“先假设后开发”的思考方式，能够识别前面提到的3类假设，即问题假设、人群假设和解决方案假设。当然，有了这些假设以后，我们还需要一些方法能够快速设计与实现。只有这样，我们才能以最快的速度完成价值验证闭环。下面就通过示例向大家介绍一些实用的方法。
所谓装饰窗方法（Decorative Window），就是指为新功能预留一个“入口”，让用户能够看到，但实际上并没有真正实现其功能。就像一个装饰性的窗户，如图2-14所示。这是一种了解用户喜好的方法，其目的是利用最小成本，来验证用户是否喜欢某个功能，以及其紧迫程度，为是否研发后续更全面的解决方案提供数据支持。
国内某垂直电商公司在2013年做了一次商户平台的体验改进。在负责商户端产品的产品经理进行的用户访谈中，多个商户提及账期问题“竞品的账期已经改为两周了，而我们还要3周”。
图2-14 装饰窗方法
产品经理针对用户的这个抱怨，设计了一个新的功能“即刻提现”，即商户可以随时通过商户管理系统的页面，点击“立即提现”的按钮，就可以将账户上的钱提到自己的银行卡中。
在产品经理看来，这是一个非常简单的功能，用不了多长时间就可以上线。然而，经过负责商户管理系统的研发团队的评估，需要6周才能上线，而且有一个前提，那就是需要负责财务系统的开发团队积极配合对接才行。一听需要6周，产品经理一脸的不高兴，但仔细想想，也知道没有想象的那么简单。原因有以下几个。
（1）商户端开发团队本身还有其他功能需求正在开发中，只有这些需求做完之后才能开始做这个需求。
（2）需要负责财务系统的研发团队一起修改现有的财务流程。
（3）即使全部开发完了，也要一起进行联调，再经过测试团队的测试，才能正式上线。
用户到底是否喜欢这个功能，它是雪中送炭还是锦上添花，在没有真实的用户反馈前，这是个未知数。能否快速找到答案呢？于是，产品经理与开发工程师一起想到了装饰窗方法。
团队在商户结算详情页上提供了一个可点击的按钮。当用户点击以后，会弹出一个页面，给出一段文字说明，如图2-15所示，大意是：假如商户对这个功能感兴趣，可以留下自己的联系手机号，一旦功能开通，即可立即收到通知。
图2-15 装饰窗页面设计
这个功能所需的开发工作量如下所列。
（1）对原有页面1进行修改，增加一个按钮“立即提现”。
（2）增加功能说明页面2。
（3）用户提交后，保存手机号码。
此时，需要验证的假设可以描述为：“我们相信，在没有强烈提示用户的前提下，假如在一周内收集到800个商户的电话号码，则说明有较多的商户对这个功能感兴趣，我们可以开始进行下一步验证。”
事实上，这个“装饰窗”功能发布以后，并没有广而告之，而是依赖自然流量。几天后，收集到了1000多个手机号码，而且，重复登记两次以上的手机号码一共有120个，似乎这个功能很吸引用户。产品经理很兴奋，花费这么少的资源和时间，就获得了用户的反馈，还是非常值得的。
最小可行特性法（Minimum Viable Feature）是指在产品从1到n的过程中，寻找用户可直接感知到的需求假设作为产品的最小可行特性优先开发的方法，以尽可能少的成本快速增加或修改某个产品特性，让用户使用，收集真实反馈，专注于验证功能改进，同时也可提升用户使用体验。
此时，等待验证的假设是：“我们相信，如果在两周内，那些多次预留手机号码的120个商户中，有60个商户使用该功能，则说明商户的这一诉求的确强烈，该功能能够大大提高商户满意度，可以进一步开发全自动化流程。”
团队并没有实现原方案中的全部功能，而仅仅开发了用户可直接感知到的那部分，如图2-16所示。从用户的角度看，这个功能的确完成了。
图2-16 用户的最小可行特性
然而，对企业内部来说，这只是一个非常简陋的版本。当用户确定提现申请后，后台服务会发送一封邮件给团队的指定人员，邮件中包含结算提现所需要的必要信息。该负责人需要打印该信息，到财务人员那里手工走完账务流程，完成整个交易过程。用户如果想要取消这个功能的话，需要通过客服热线申请，而无法自助完成。因此，这其实是该特性的一个最小功能集。因为这一最小功能集易于在短时间内、投入较少的人力来实现，根本没有涉及财务管理系统的开发工作。
对开发团队来说，可以在最短时间内收集数据，验证用户是否喜欢该功能，再决定是否还要继续开发后续的功能；对用户来说，平台在短时间内实现了立即提现的需求，提升了用户体验。这样，形成了可进可退的双赢局面。
特区法（Special Zone）是指在特定用户范围内进行试验，以验证某个新功能的有效性。这样，即使新功能无效或者效果不好，也不会影响特区外的用户。这种方法对于资源有限、成本敏感，但仍希望为用户提供良好服务的业务来说，是非常有效的方法。大家所熟知的共享汽车和共享单车，都曾采用这种方法，也就是说，从某个城市或某个区域开始提供服务，试图回答“该需求是否真实存在？该需求是否强烈？”这类的问题。
在“立即提现”案例应用了“装饰窗方法”以后，团队将重复录入多次的120个商户作为“特区用户”，向他们发送手机短信，通知该功能已经上线。当天下午就有第一个商户申请立即提现。在之后两天里，申请商家并没有想象的那么踊跃。于是，运营人员向这120个商户再次发送了短信通知，还同时发送了一条商户站内通知。
该功能上线两周后，得到的结果是：只有45个商户在此期间点击过第一个页面的“申请提现”按钮，真正完成提现操作的商户也只有33个。其中，仅提取一次的商户数为25个，提取两次的商户数为7个。只有1个商户提取了8次。比团队预计的目标（50%的商户）少了很多，并没有达到预期。产品经理想知道原因，于是采用了下面的“定向探索法”。
定向探索法（Directional Explorer）是指针对具有某种特定行为的特定用户群体，依据该用户的具体行为模式，设计调查提纲，有针对性地探索其行为背后的动机。这种定向探索法与一般用户访谈的不同点在于：团队已经掌握了被访谈对象的具体行为（包括行为细节与发生时间等），以事实为依据，进行定向式的探索发现，而非宽泛的通用提问。
针对用户不同的行为，团队将用户进行了定向分类。例如：
（1）收到了通知，但没有进行操作的用户；
（2）访问了页面，但是没有进行申请确认操作的用户；
（3）申请过一次的用户；
（4）申请超过一次的用户。
针对这些不同的用户，设计不同的问卷，进行用户访谈，以便理解用户行为，为后续的服务提供有效的输入。
最终，团队得出的结论是：该功能属于锦上添花的功能，可以解决少量商户的诉求。另外，通过定向探索，团队还深入发现了两个新的用户痛点，为进一步提升用户体验提供了改进方向。
稻草人法（Corn Dolly）就是指：不开发任何真实的功能，只假装这个功能已经完成了，并向用户展示该功能的真实效果，从而得到用户的真实反馈。这种方法与装饰窗方法的区别在于它让用户真实地感受到了功能提供的结果，而事实上并没有开发这个功能。
这种方法早在20世纪80年代的IBM公司就使用过。当时，大多数人不会打字，只有程序员、秘书和作家才会使用打字机和计算机。IBM公司很希望个人计算机能够被广泛使用，于是其市场部门就做了市场需求调研。在调研之后，市场部强烈认为，假如IBM公司能够发明一种技术，可以将语音直接翻译成文字并自动录入计算机，不需要手工打字，那么会有很多人购买这种计算机，即使售价高达一万美元。但这一技术的研发需要投入相当大的成本。于是，有人提出是否可以做个小型试验来验证一下：“人们是否会花一万美元购买这种具有语音输入能力的计算机”，其试验方案如图2-17所示。
图2-17 IBM公司的人工智能翻译试验
首先在一个房间中有一只麦克风，直接连接到一个显示屏上。邀请那些潜在购买者来体验这一技术成果。试验者进入这个房间后被告知，只要对着麦克风说话，所说的内容就会被自动翻译出来，显示到屏幕上。事实上，这并不是机器自动翻译的。在另一房间中，一个打字速度飞快的打字员边听边打出来，传到试验者的屏幕上。这个打字员被要求不要漏掉任何信息，例如试验者的一些口头语、衔接停顿音等。试验结果也许你已经猜到了，在那个年代，没有人真想花一万美元购买这样一种打字机器。
最小可行产品法（Minimum Viable Product）通常是在产品从0到1的过程中使用。它是以尽可能少的成本快速开发产品的核心功能，并找到用户，收集真实反馈，验证真实的用户需求，以确定新产品方向和形态的方法，其目标是找到合适的产品形态。
国外垂直品类电商平台Zappos最早根本没有自己的物流管理系统，创始人尼克·斯威姆（Nick Swinmurn）和谢家华只是搭建了一个简单的图片展示网站，并跑到隔壁鞋店拍摄一批鞋子的照片放在这个网站上。当有人下单时，他们就去那个鞋店把鞋买回来，然后手工发货。
这就是使用最简单的方式来验证最初的业务想法，而不是先建立软件开发团队，构建一个完备的软件支撑系统。
为了更好地执行价值探索，在整个过程中有以下6点值得注意。
探索环涉及业务领域的很多方面，包括问题的发现与定义、目标与衡量的制订等多种产物，而不仅仅是产出一个功能需求列表。因此，建议与业务领域问题及产品解决方案相关的各类角色都能够参与其中。而且，参与其中的每个人均应该对上述内容有所贡献。
“即时提现”案例就是由团队多个角色共同贡献，使方案从“大而全的一次到位式”转变到“分步快速试验式”。当开发工程师了解产品经理的原始想法以后，从不同的视角分解问题，并一起集思广益，得出了这种投入回报率最高的最简方案，以较少的资源投入（只需一人做技术实现，其他开发人员还在开发其他功能），最快地得到了问题的答案。从第一步的“装饰窗”，到最后一步的“定向探索”，前后也只用了大约6周，就得到了最终的结论。
正像敏捷大师、Scrum方法的倡导者Mike Cohn所说：“你的整个产品Backlog（需求列表）不必全部来自Product Owner（产品总负责人或产品经理）。当团队其他人对它也做出贡献时，是团队参与感进入良好状态的一种信号，此时团队更可能成功地做出敏捷转型。”
探索过程中存在很多的不确定性，因此4个环节中也必然存在一定的反复与循环。这是正常现象，尤其是当业务领域比较复杂、涉及环节比较多，业务流程中所涉及的角色也比较多时，更容易发生。很可能在讨论某个问题的可行解决方案时，会发现另一个隐藏的重要业务问题。
另外，探索过程强调“度量与量化”。在讨论过程中经常会出现对衡量指示器及量化结果理解不一致的现象，很可能会对原来达成一致的指标项产生异议。这是值得高兴的事情，因为我们发现了在日常沟通中不易被发现的理解偏差。对于这些偏差的处理，参与探索者既可以先把它记录下来，后续再进行探索，也可以将当前讨论的结果记录下来，并针对这一新问题开启探索之旅，甚至将探索者分成两组，分别探讨，再进行同步。无论遇到哪种异议，采取哪种行动，参与探索的人都应该对行动达成共识。
我们会从每个业务问题中分析出很多风险或假设，假如我们为每个假设都设计出多种试验方案，并且坚持实施所有试验方案，很可能会消耗太多的成本，并错过市场时机。因此，我们仅需对那些被评估为风险较大的假设进行验证方案设计，并尽量以较低成本进行验证。而对于那些低风险项，团队要在设计解决方案时，提出一些衡量指标器，并在方案执行后，一同收集相关的数据结果。
由于在某个领域工作时间较长，有些人认为自己非常了解用户，常常“闭门造车”，并美其名曰“注重用户体验”。然而，当产品上线后却发现，用户对产品功能有很大的意见。
2017年，某互联网公司的人工智能部门收集了大量不同类型的数据，需要进行标注。由于需要标注的数据类型较多，不同数据类型的标注方法不同，因此对标注者的技能要求也有所不同。该公司原来招募标注人员的工作是通过线下考试的方式，即以文件的方式通过邮件将材料发送给应聘者，应聘者完成后，再邮件回复。这一工作由数据运营人员和数据顾问负责，他们制订了标注人员招聘的整个线下流程和规则。
但是，由于标注需求量越来越大，而标注人员的流动性也较大，因此，标注人数的缺口持续扩大，使用线下考试方式已经不能满足对标注人数的需求。经过讨论，公司决定组织一个产品开发团队，开发一个标注人员在线考试系统，代替原有的线下手工考试方式，提高标注人员招聘环节的效率。产品开发团队的产品经理通过向数据运营人员和数据顾问了解业务领域知识和业务需求，分析并撰写了在线考试系统的需求说明书。产品经理认为，数据标注人员招聘工作已经通过线下操作方式进行了一段时间，数据顾问对该系统的软件需求足够明确，从数据顾问那里了解的业务需求应该足够充分，因此直接设计了一整套的用户交互界面，该系统包括题库、设计试卷、举办考试、收集试卷、评分等功能，涉及出题人、出卷人、答卷人和管理员4个角色。
当该系统的第一个版本开发完成后，产品经理找来了数据运营人员和数据顾问进行系统验收。验收通过以后，就马上开始灰度测试。灰度测试第一天，就收到了答卷人的大量反馈（吐槽），系统的很多功能都不是很方便。
从在线考试系统这个想法的产生，到第一次灰度上线，时间跨度近5个月。在复盘时，这个项目团队一致认为有两个严重的失误，它们是：
（1）团队成员自认为已经掌握了答卷人的所有需求，因此直到所有的产品开发工作都完成，产品流程的设计者也没有找该系统真正的使用者进行验证。
（2）团队认为完全有能力开发一个满意的在线考试系统，因此根本没有考虑先设计一个最小可发布版本（MVP），而是直接设计了一个“大而全”的版本，开发时间较长。
之后，团队还讨论了假如重新做这个项目，团队会如何做？经过热烈讨论，团队找到了很多可行方法来提前验证功能需求。例如：
（1）“纸上原型交互”方法，就是将系统交互原型打印到纸上，邀请用户试验，观察用户的行为，并与用户沟通，从而得到用户反馈，当然现在有很多电子工具支持这种需求；
（2）“MVP”法，即快速推出“面向标注人”的简化考试版本，仅实现其中一种类型标注的在线考试功能，而题库以及出题人相关的功能均暂时先由内部人员用手工方式进行准备。
当我们建立起数据指标体系，搭建好我们的试验机制，并且能够收集到大量指标数据以后，有一点需要格外注意，那就是：所有收集到的数据只能告诉你当前的状态是什么，并不能直接告诉你背后的原因是什么，也无法完全预测未来，尤其当业务市场发生改变，而数据又无法展示时。
短视频移动应用“快手”的前身是一款移动端GIF图片生成工具（名为“GIF快手”），当时用户规模也到了一定数量（GIF快手鼎盛时拥有几千万用户，日活跃用户上百万，但同时也有工具型产品的弱点：留存率偏低）。2013年，它转型做短视频应用，最低点时日活跃用户跌落至万级，然而，现在日活跃用户近亿。试想如果只看数据，坚持做GIF图片生成，是否还能有现在这么庞大的用户群呢？
因此，拿到指标数据之后，我们仍旧需要仔细思考，分析各项数据背后的原因，思考未来的发展趋势，甚至提出一些我们没有完全把握的问题或方向，再次开启探索环。
还有一种情况，比较常见。团队针对问题制订了一系列的试验方案A，并开始执行验证。但在还没有执行完成或得到结果之前，团队又有了新的想法和方案B，并且对新的想法兴奋不已，马上开始执行方案B。没有多久，可能又想到了一个新的方向，如此循环，如图2-18所示。
这经常发生在中小企业因资金到位而人员快速膨胀的时候。既可能是因为试验方案需要较长的时间，也可能是因为管理者关注的问题点转变得过快。我们无法排除原来打算解决的业务问题已经失效的可能性，但这种情况对于团队的管理有极大的挑战。
图2-18 蛇行效应
本章讨论了持续交付“8”字形环之探索环中的4个关键环节，包括提问、锚定、共创和精炼。希望顺利实施这4个环节，需要遵守3个基本实施原则，分别是分解并快速试错、一次只验证一点和允许失败。
本章还花了大量篇幅介绍共创与精炼环节中经常用到的6种方法，也就是装饰窗方法、最小可行特性法、特区法、定向探索法、稻草人法和最小可行产品法。这6种方法可以帮助团队用最少的时间、最小的成本来找出用户的真实需求，避免最终的产品与用户需求的偏差，达到事半功倍的效果。
探索环中的最小可行方案，对价值验证的速度有极大的影响。希望大家在日常工作中能够使用这些方法，以最小的成本来实现更多的价值交付。
