关于devops:DevOps成长路线影响地图-IDCF

2次阅读

共计 1683 个字符，预计需要花费 5 分钟才能阅读完成。

为了写这篇文章，把无敌哥的视频《买通任脉的影响地图》又看了一遍，麻利无敌的书里也有专门一个章节来介绍。看视频的时候，竟然很多内容都没什么印象了，可见我的记性是有多大。连忙把这两天的学习心得记录下来，省的又遗记了。

测试小 T 走到开发小 D 身边，对小 D 说，这个性能逻辑有点怪，为什么要这么实现呢？小 D 眼睛一翻，我只负责实现，至于为什么，你得去问设计。

如何您碰巧也是一位测试，或者项目经理，这样的场景是否很相熟呢？开发人员只关怀 how，对于 why，很少去想。甚至，他本人也感觉这性能逻辑有点怪，但还是会持续去做。这难道就是事实版的“背道而驰”？

也已经和开发聊过，为什么开发都不怎么关怀业务？失去的答复是，IT 技术更新迭代太快了，而且分工越来越细，每个细分畛域都有很多技能要学习。咱们开发，都想把精力放在技术的打磨上，没有太多的精力和趣味去理解业务，再说，不是还有产品经理吗。

听下来也没故障！只是，让我想起了一句话“每个人都感觉本人做的很好，但最终后果却是一团糟”。给大家举个例子。

在 20 世纪 80 年代，美国制作受到了德国和日本的微小冲击，尤其是在汽车制作行业，德国和日本的汽车以更优的品质和较好的舒适度迅速霸占了美国市场。令美国厂商百思不得其解的是，美国在生产技术、配备、设计和工艺方面并不比德国和日本差，在汽车制作畛域积攒的工夫甚至超过他们，然而为什么美国汽车的品质和精度就是赶不上人家？

在那个时候，品质治理曾经汽车制作畛域非常遍及了。光学测量被利用在产品线上当前，在零部件生产和车身拆卸的各个工序已积攒大量的测量数据。但问题是，即使测量非常精准，在各个工序和零部件生产和车身拆卸都进行严格的品质管制，然而在组装结束后仍然有较大的误差。于是美国的汽车厂商不得不花大量工夫重复批改和匹配工艺参数，最终的品质却仍然不稳固，时常呈现每一个工序都在品质管制范畴内，但最终的产品质量仍然不能达标。

可见, 工业制作早曾经通知咱们, 单个阶段的最优化, 并不代表整体最优。业务与开发之间的隔膜，怎么破？如何预防“背道而驰”？

指标定好了，能够通过谁的行为来达成这个指标呢？很显然，须要业务和开发本身去扭转行为，其余干系人一起协同，比方 Scrum Master。

干系人的行为应如何来扭转？如何帮忙咱们达成指标？

对于不同的干系人（Actors），别离列出各自的行为。假如通过这些行为，指标就能实现。

须要做什么来反对影响的实现，也就是说须要交付什么性能。

咱们假如，交付物如果可能提供图中列的这些性能，比方可视化指标和性能的关系，共享全景视图，最短门路，助力思维转变，就能促使各干系人去采取相应的口头，最终达成指标。

这个交付物是什么呢？置信大家都曾经猜出来了，没错，它就是影响地图。用来解决文中提到的 2 个问题：

业务指标与性能之间映射关系的含糊和不统一。
业务职能和开发职能之间交换决策的隔膜。

影响地图这个工具，个别用来做战略规划，产品布局等。本文利用影响地图来解释影响地图自身，介绍了影响地图中四个关键字（why，who，how，what）的根本含意。图中我列出的 how 和 what 条目，只作为举例用，并不残缺。影响地图里很重要的一点就是“永远不要执行完影响地图中的所有 What”，因为所有的事项，都是基于假如，只有找出最短门路，而后去疾速验证。等验证完了，后面的某些假如，可能曾经生效了。所以每验证一次，就要从新评估每个假如，而后开始新一轮验证。