devops的重要性_为什么反馈而不是指标对DevOps至关重要

devops的重要性

大多数经理和敏捷教练依赖于指标，而不是来自团队，用户甚至客户的反馈。 实际上，有相当多的人将反馈和度量同义地使用，它们以一堆数字或这些数字的图形表示形式呈现来自团队或客户的反馈。 这不仅是不幸的，而且可能会引起误解，因为它仅代表故事的一部分，而不代表全部事实。

当涉及两个关键因素时（我们如何管理或指导团队以及我们如何操作和影响团队正在开发的产品），很少有杰出的领导者和团队能够正确地做到这一点。 一方面，掌握数据和指标变得非常容易。 此外，仍然很难从团队和用户那里获得真正的反馈。 它需要大量的投资和精力，并且除非每个人都了解它的迫切需求，否则获得和提供反馈的优先级往往较低，并且会不断被淘汰。

如何管理和指导团队

随着敏捷的接受，许多团队在度量标准（例如速度，燃尽图，累积流程图（CFD）等）上赋予了高得离谱的价值，而不是团队在每次迭代或部署中提供的价值。 重点放在产生的交付或输出上，而没有清楚地了解这与个人绩效或对项目，产品或服务的影响之间的关系。

一些经理和敏捷教练甚至滥用指标来惩罚甚至惩罚他们的团队，从而滥用了敏捷的真正精神。 他们没有创建授权环境，而是转而使用命令和控制方法，在该方法中，度量标准被用来欺负团队以使其屈服。

在我们小组中，最好的经理每周与每个团队成员进行一对一的会面。 这些会议不仅给了他们真正的团队士气，还深刻理解了该项目以及为推动该项目而做出的决定。 这个每周的反馈循环还可以帮助团队成员更好地交流技术，功能甚至个人问题。 因此，团队在了解整体项目需求以及能够Swift做出决策方面更具凝聚力。

这些领导者还跳过各个级别（与他们下面的两个或三个级别的团队成员进行联系），并与与团队定期互动的其他小组成员进行频繁对话。 这些行动为经理们提供了一个整体的图景，如果他们依靠一个经理或领导者的反馈就无法获得这些信息，并帮助他们确定领导者和经理者可能存在的任何盲点。

这些一对一的会议有效地将经理转变为对每个团队成员都有深刻了解的教练。 这些经理就像一位优秀的教练一样，就产品，决策透明性，团队认为管理落后的地方以及被忽略的领域，向团队成员提供并从中获得反馈。 这可以使团队发声，而不是在年度会议或年度调查中偶尔发出声音，而是每周发出声音。 这是DevOps团队应成功履行其承诺的级别。

这需要大量的时间和精力投入，但结果远不能证明其合理性。 另一种选择是依靠度量标准以及年度审查和调查，这惨遭失败。 除非我们开始评估指标的反馈，否则我们将继续看到我们希望看到的指标，但项目失败且团队士气低落。

影响项目和产品开发

我们在项目或产品方面看到了类似的行为，与用户和开发人员的对话太少，而对指标的关注却太多。 让我们以发布给社区或市场的软件为例，成功的主要指标是下载或安装的数量。 可能有以下几种原因造成欺骗：

1. 该产品被打包到用户安装的另一软件中。 即使用户甚至不知道您产品的存在或用途，它仍然被认为是成功和用户需要的东西。

2. 市场营销团队花费了大量的预算来推广该产品，甚至激励开发人员下载该产品。 激励因素是下载量的来源，而不是用户的需求或欲望，但该指标仍然被视为衡量成功的标准。

3. 即使软件更新是非用户推送而不是由用户启动的非自愿更新，也算作下载。 即使用户一年前可能曾经将其用于特定任务，但仍会不断增加该数字。

在这些情况下，无论用户喜欢还是使用该软件，用户都将基于下载的事实和接受更新的信息，自动成为用于报告该产品运行状况的指标。 相反，我们应该专注于产品的实际使用情况以及这些用户必须提供给我们的反馈，而不是停止下载次数。

SaaS产品也是如此，我们应该查看用户使用该产品或服务的频率，而不是注册的数量。 本身进行注册的意义不大，尤其是对于DevOps团队而言，该团队专注于获得持续的反馈并努力不断进行改进。

收集反馈

那么，为什么我们这么依赖指标呢？ 我的猜测是，它们很容易收集，并且营销团队对将产品移交给用户更感兴趣，而不是评估产品的外观。 除非工程团队花费大量时间来通过跟踪收集反馈，以捕获程序执行的频率和最常使用的组件，否则收集反馈会很困难。

在开源社区中工作的一大优势是，我们首先将软件发布到了一个社区中，我们可以在该社区中获得反馈。 大多数开放源代码爱好者都根据他们对产品的经验，花时间记录问题和错误。 如果我们可以通过跟踪对这些数据进行补充，那么团队将有关于产品使用方式的准确记录。

打开尽可能多的交流渠道（聊天，电子邮件，Twitter等），并允许用户选择自己的反馈渠道。

一些DevOps团队集成了蓝绿色部署，A / B测试和Canary版本，以缩短反馈循环。 设置这些框架并不是一件容易的事，需要大量的前期投资和不断的更新以使其无缝运行。 但是，一旦一切都设置好并且数据开始流动，团队就可以基于与每个发布的新软件的真实用户交互，基于真实的反馈采取行动。

大多数敏捷从业者和精益运动活动家都在推动建立，部署，度量，学习的周期，为此，除了指标之外，我们还需要收集反馈。 从短期来看，这似乎很昂贵并且很耗时，但是从长远来看，这是一种万无一失的学习方法。

反馈有回报的证明

无论是涉及人员还是项目，都需要依靠第一手反馈而不是指标，而这些指标很少以公正的方式进行解释。 我们在其他行业中有充分的证据，在这些行业中，诸如Zappos和Virgin Group这样的公司仅通过听取客户的意见就为他们的业务创造了奇迹。 我们没有理由不能效仿，特别是我们在开源社区工作的人。

反馈是我们发现盲点的唯一有效方法。 度量标准在这方面没有太大帮助，因为我们在处理未知数时无法找出问题所在。 盲点会在现实与我们认为的知识之间造成严重的鸿沟。 反馈不仅鼓励持续改进，无论是在个人层面还是在产品层面上，而且简单的倾听和采取行动就可以提高信任度和忠诚度。

---

接下来要读什么

翻译自: https://opensource.com/article/19/3/devops-feedback-not-metrics

devops的重要性