从这一讲开始，我们进入 DevOps 正题。按照端到端的顺序，讲解 DevOps 中的最佳实践如何在软件开发过程中发挥作用。所谓端到端，是指从需求提出到需求被发布到生产环境交付给用户的整个过程，可以理解为软件开发的全生命周期。所谓最佳实践，是指被业界广泛采用的、被证明有效的方式方法。这个系列课程会囊括软件开发过程的各个阶段，每一课时都会对应解决这一阶段的某个或某些问题，比如需求阶段如何对用户需求达成共识，开发阶段如何保证提交代码的质量，如何平衡技术债务和开发进度等等。
今天这一讲主要介绍如何使用影响地图这个工具来解决产品规划、里程碑规划和用户需求分析的问题，保证软件开发的大方向是正确的。
为什么要进行产品规划？
首先，请你思考以下问题：
1.你所参与的软件产品开发中，有多少功能是用户真正需要的？
2.你所参与的项目，有没有做到一半就取消的功能和产品？
你可能会长舒一口气，这两种情况太多了。
软件行业是一个成功率较低的行业。据 Standish Group 发布的 CHAOS Report 显示：截至 1994 年，在研究了 8000 多个软件开发项目后，只有 16% 的软件项目是成功，其他 84% 的项目不是失败了，就存在严重的问题。
在十年后的 2004 年，当研究人员将项目样本增加到了 4 万个，发现这时软件项目的成功率提高到了 29%。为什么十年后软件开发的成功率会增加？其中一个原因就是精益思想和敏捷软件开发方法的广泛采用。
但根据 2015 年的报告，从 2011 年到2015年，软件项目的成功率并未再有大的提升，基本是在 30% 左右，可以参考下图：
其中，在这些失败的软件项目中有 31.1% 在未完成之前就取消了。软件项目的失败最终付出了金钱和时间的代价，最重要的是失去的机会是一去不复还的，有些企业失去抢占市场的先机，因此而倒闭。
"项目中途取消""需求中途取消""项目延期超支"等问题的出现，最主要的原因有以下两点：一点是"不了解用户真实需求"。在产品在开发阶段，不去调查用户需求，而是想当然的自我设定用户需求， 最终导致所开发的软件和用户想要的不一致。另一点是对产品缺乏整体的认识和理解。产品的规划没有重点，眉毛胡子一把抓，什么想都做，但最终什么都没做好，错失了产品投放市场的最佳机会。
由此可以看出，挖掘用户的真实需求是多么重要。如果一开始没有按照用户的需求进行开发，终究会落得中途废弃的下场。
因此，我们需要找到一种工具或方法，能够挖掘出用户最真实的需求，能够帮助我们对产品进行定义和里程碑规划，确保交付的软件和用户的需求一致，并且是用户最高优先级的需求。这个工具就是------影响地图。
什么是影响地图？
影响地图是一种战略规划方面的技术。它通过清晰的假设、可视化的形式，建立产品功能与商业目标之间的关系，并最终做出更合理的里程碑规划。从而使得开发人员在构建产品和交付过程中避免迷失方向。
影响地图通过回答为什么（why）、谁（who）、怎样（how）、什么（what） 这四个问题来一步一步构建完成一个思维导图。该思维导图一般是由技术人员、业务人员及其他相关人员共同协作完成。最终的思维导图框架如下图所示：
下面介绍下这四个问题的含义以及在影响地图中的作用：
1. 为什么（why）？
开发过程中，我们首先要回答的问题就是：我们为什么要做这件事？或者我们为什么要开发这个功能？问题的答案正是我们要达到的目标。设立清晰的目标听起来简单，但真正做起来非常不容易。有很多软件项目失败的原因就是目标不清晰。注意，这里的目标指的是业务目标。我们要实现的目标一定是业务目标。这个目标要有明确作用：或者能够为企业带来利润、客户，或者能够为其降低成本。
因此，目标的设定非常关键。切记不可不切实际！ 好的目标应该符合 SMART 原则：Specific（明确的），Measurable（可度量的），Action-oriented（面向行动的），Realistic（现实的），Timely（有时限的）。比如：3 个月新增用户 100 万或年底之前完成销售额 1000 万等。
2. 谁（who）？
地图的中间已经放好了要实现的目标，那么接下来的第一层就是表明实现这个目标和哪些人或角色有关系。这个关系可以是正面的，也可以是负面的。比如：谁能帮助实现这个目标？谁会阻碍实现这个目标？这里要尽可能把所有相关联的人列举出来。防止开发过程中突然出现的角色对开发过程造成影响。
罗列出的角色可以分为主要角色、次要角色和场外角色。主要角色一般指软件的最终用户；次要角色一般指软件的提供者，可能会包含产品经理、开发人员、测试人员、运维人员等；场外角色一般指不直接参与的人员，比如高层管理者。
3. 怎样（how）？
第一层列举了实现业务目标影响到的角色。第二层就要考虑这些角色是如何影响最终要实现的目标的？也就是说，考虑角色是如何帮助或阻碍目标的实现？这里就要思考角色会有哪些行为变化。我们可以根据行为的影响大小，实现难易进行优先级地排列。从而根据影响地图的层次结构清晰地掌握是谁造成了这些影响，以及他们如何影响目标的实现？
注意，这里的"影响"影响到的并不是具体的产品功能，而是角色行为的变化。是行为与之前相比的不同之处。比如：页面响应时间缩短 30%，而不是页面响应时间本身。页面响应时间在之前的功能中也有，只是实现时间较长。如果要实现 why 的目标，需要将响应时间缩短30%，这才体现出与之前的变化。
4. 什么（what）？
回答完前面三个问题，就可以讨论具体要做什么才能实现这个影响了。比如：是应该交付一个软件功能，还是组织一场线下活动？这一层就是我们的工作范围了。注意：这里罗列的内容并不是所有要交付的内容，而是交付内容的可选项。我们需要在这一层筛选出有价值的部分，同时过滤掉没有明显价值的部分。有价值的部分就可以作为里程碑规划中的内容，也是我们应当优先完成的内容。比如：为页面数据添加缓存，减少计算逻辑的再次处理等。
通过将交付的内容，内容产生的影响，影响实现的目标串联起来，我们能清楚地知道做这件事情的前因后果。从而在实际开发过程中合理分配资源，不会产生范围蔓延的问题。下面我通过一个实际的例子来描述如何使用影响地图进行需求分析。
使用影响地图进行需求分析实践
在工作中，有用户投诉说打开商品详情页特别慢，加载时间特别长。产品经理针对这个问题建了一个任务"商品详情页异步加载显示"并拖到了下一个迭代里。这种情况下，究竟要不要按产品经理说的去做？如果不做又有什么其他解决方法？下面，我使用"影响地图"来分析一下这个需求。
STEP 1：Why? 先确定任务目标。
在这个例子里，产品经理提出"商品详情页异步加载显示"的需求。透过现象看本质，产品经理的最终目的并不是要把商品详情页改造成异步加载的方式，而是要提高商品详情页的加载速度，异步加载只不过是实现这个目标的一种解决方案。因此，我们先定义好目标。
STEP 2：Who？这个目标跟谁有关？
根据经验，页面加载缓慢的因素有很多种。例如，后台的接口慢、前端的代码加载策略有问题、系统的部署架构需要优化、服务器的配置需要升级、 采用 CDN 进行静态资源分发等。因此要实现这个目标，关联方就会涉及以上提到可能因素相关的所有人员：后端开发人员、前端开发人员、架构师、设备管理员还有在购买设备和 CDN 服务时需要审批的领导等。因此，我们将影响任务目标的角色放入影响地图，如下图所示：
STEP 3：How？每种角色是如何影响这个目标的？
为了达成目标，我们根据每种角色的职责和工作范围，思考他们用什么方式影响这个目标。比如：后台开发人员提高后端接口提高响应时间，前端开发人员进行前端代码优化，架构师优化系统部署架构，通过负载均衡分散访问压力；静态资源文件单独存放加快下载速度，设备管理员提升硬件性能，领导需要加快方案落地速度等。这里要考虑的是角色行为对目前现状与改进后的差异。有些是从无到有，有些是提高，有些是减少...总之角色的行为要产生变化。这些变化要影响到目标的实现。如下图所示：
STEP 4：What？具体做什么？
这一步要求我们针对上面每种角色不同的影响，罗列具体的操作内容。也就是说，我要做什么事情才能产生上面这个影响。后台开发人员想要提高后端接口响应速度，可以通过添加分布式缓存、数据库添加索引、数据库读写分离等方式解决。前端开发人员想要优化前端代码，可以通过添加浏览器缓存、采用懒加载方式和采用 CDN 访问静态资源等方式解决。架构师想要优化服务器部署结构，可以通过改单点部署为集群部署，用负载均衡服务器分担单节点压力等方式解决。设备管理员想要提升硬件设备性能，可以通过购买高性能服务器和更换万兆光纤等方式解决。领导想要加快方案落地速度，可以通过及时审批（审查？）审批流程等方式解决。这些就是我们每个迭代需要的具体任务，在迭代结束时应该提供的交付物。如下图所示。
STEP 5：选择最短路径。
通过上面 4 个步骤，我们形成了一份可供选择的任务清单。接下来我们应该做的并不是完成所有的任务，而是选择其中成本低、效果好的完成。这里需要我们预估每个交付物的效果和成本。如下图所示，我们可以看出效果较好，成本低的交付物有：添加分布式缓存、数据库添加索引、添加浏览器缓存和采用懒加载的方式等。选择这些路径完成，将为我们减轻不少负担。
STEP 6：里程碑规划。
上一个步骤中选择的最短路径，可以作为第一个里程碑中需要交付的内容。如下图所示，标记为 ① 的任务是需要加入里程碑规划里的任务。待该里程碑完成后，我们要根据度量指标衡量目标达成的效果，再从剩余的选项中继续选择成本低、效果好的任务添加到下一个里程碑规划中，直到目标达成。
到此，我们利用影响地图对产品经理提出的需求进行了分析和里程碑规划。从而确定了需求目标、具体工作内容和里程碑规划。上面这几个图有几个特点：
& 结构化。
影响地图是结构化的。它的第一层是目标；第二层是影响哪些用户或角色能够实现这个目标，即角色；第三层是这些角色通过什么影响来帮助实现这个目标，即影响；第四层是通过什么具体的功能或事项来实现这个影响，即交付物。层层细化，非常清晰。
& 整体性。
影响地图是从目标到角色，到影响，再到交付物的树状视图。也是一个为产品开发，功能迭代中各相关角色提供的一个共享的、整体的视图。每个角色都能按照这个整体视图的脉络，理清自己的思路和职责，确保交付的功能能够帮助目标的达成。
& 协作性。
影响地图是各个角色沟通和协助的桥梁。各相关角色可以基于这张图来制定产品规划，里程碑规划。相比于过去基于"产品功能列表"的里程碑规划，基于影响地图的里程碑规划可以按照从交付物到目标的最短路径方法进行规划。这样制定出的规划更符合实际需求、更有效。
& 动态性。
这个图是需要不断迭代更新、不断完善的。因为基于影响地图的产品规划和需求分析，都是以假设为前提条件进行的，各一是假设最终的交付物能够产生各角色然后期望的影响，二是假设期望的影响能够达成最初定义的目标。这些假设是需要在迭代过程中进行验证的，然后我们也要根据验证的结果调整后续的里程碑规划。
总结
就像我在本课时开头提到的那样。大多数软件项目之所以失败，是因为在软件开发过程中投入太多精力关注软件功能本身，反而忽略了需要交付的业务目标。产品经理在进行产品规划、里程碑规划和任务分配时，只是给出"做什么"和"怎么做"，很少去解释"为什么"。这样，在不了解目标的情况下，开发工作就像一只没有方向的船在大海上航行一样，虽然一直在航行，却难以到达目的地。
这时候，影响地图这一个工具就成了大船航行的方向和航海图。它可以辅助确定业务目标，将具体的工作任务与目标相关联，在制定里程碑规划时始终考虑目标，并通过最短路径快速实现业务目标。这些对于一个产品，甚至是一个企业都是至关重要的，感兴趣的小伙伴可以在工作中尝试一下。