大多数管理者和敏捷教练依赖指标，而不是来自团队、用户甚至客户的反馈。事实上，很多人将反馈和指标混用，他们将来自团队或客户的反馈呈现为一堆数字或这些数字的图形表示。这不仅令人遗憾，而且具有误导性，因为它只呈现了故事的一部分，而不是全部真相。
当涉及到两个关键因素时——我们如何管理或指导我们的团队，以及我们如何运营和影响我们的团队正在开发的产品——很少有杰出的领导者和团队能够正确处理。一方面，获取数据和指标已经变得非常容易。然而，从团队和用户那里获得真正的反馈仍然很困难。这需要大量的投入和精力，除非每个人都理解它的迫切需要，否则获取和给予反馈往往会成为低优先级事项，并不断被搁置。
如何管理和指导团队
随着敏捷的普及，许多团队过分重视指标，例如速度、燃尽图、累积流量图 (CFD) 等，而不是团队在每次迭代或部署中交付的价值。重点在于交付或产出，而没有清楚地理解这与个人绩效或对项目、产品或服务的影响有何关系。
一些管理者和敏捷教练甚至滥用敏捷的真正精神，通过误用指标来斥责甚至惩罚他们的团队。他们没有创造授权的环境，反而倒退回命令和控制的方法，在这种方法中，指标被用来胁迫团队屈服。
在我们团队中，优秀的管理者每周与每位团队成员进行一对一会议。这些会议不仅让他们真正了解团队士气，而且深刻理解项目以及为推进项目而做出的决策。这种每周的反馈循环也有助于团队成员更好地沟通技术、职能甚至个人问题。因此，团队在理解整体项目需求方面更加协调一致，并能够及时做出决策。
这些领导者还会越级——接触低他们两到三个级别的团队成员——并经常与其他定期与他们的团队互动的团队成员交谈。这些行动使管理者获得全面的了解，如果他们仅依赖一位经理或主管的反馈，就无法获得这种了解，并且有助于他们识别主管和经理可能存在的任何盲点。
这些一对一会议有效地将管理者转变为教练，他们对每位团队成员都有深入的了解。像优秀的教练一样，这些管理者既给予团队成员反馈，也从团队成员那里接收反馈，内容涉及产品、决策透明度、团队认为管理层滞后的地方以及被忽视的领域。这通过赋予团队发言权来增强团队的能力，不是偶尔在年度会议或年度调查中，而是每周都进行。这是 DevOps 团队为了成功交付承诺应该达到的水平。
这需要大量的时间和精力投入，但结果证明这是非常值得的。另一种选择是依赖指标以及年度评估和调查，但这已经彻底失败了。除非我们开始重视反馈胜过指标，否则我们将继续看到我们想看到的指标，但项目失败，团队士气低落。
影响项目和产品开发
我们在项目或产品方面也看到了类似的行为，与用户和开发人员的对话太少，而对指标的关注太多。让我们以一个发布到社区或市场的软件为例，其主要成功指标是下载或安装次数。这可能会因多种原因而具有欺骗性
-
该产品被打包到用户安装的另一个软件中；即使使用者甚至不知道你的产品的存在或用途，它仍然被认为是成功，以及用户需要的东西。
-
营销团队花费了巨额预算来推广该产品——甚至为下载它的开发人员提供了奖励。奖励 驱动了下载量，而不是用户的需求或愿望，但该指标仍然被认为是衡量成功的标准。
-
软件更新被计为下载，即使它们是被强制推送的更新，而不是用户主动发起的。这会不断增加数量，即使使用者可能在一年前只使用过一次它来完成特定任务。
在这些情况下，用户自动成为一个指标，仅根据产品已被下载并接受更新这一事实，就被用来报告产品的表现如何，而不管用户是否喜欢或使用该软件。相反，我们应该关注产品的实际使用情况以及这些用户必须向我们提供的反馈，而不是仅仅停留在下载量上。
SaaS 产品也是如此——我们不应该计算注册用户数量，而应该关注用户使用产品或服务的频率。注册用户本身意义不大，尤其是对于 DevOps 团队而言，他们的重点是获得持续的反馈并努力持续改进。
收集反馈
那么，为什么我们如此依赖指标呢？我的猜测是它们容易收集，而且营销团队更感兴趣的是将产品送到用户手中，而不是评估其表现如何。除非工程团队投入大量时间通过追踪收集反馈，以捕获程序执行的频率以及最常使用的组件，否则可能难以收集反馈。
在开源社区中工作的一大优势是，我们首先将软件发布到一个社区，在那里我们可以获得反馈。大多数开源爱好者都会花时间根据他们对产品的体验来记录问题和错误。如果我们可以用追踪来补充这些数据，团队就可以准确记录产品的使用情况。
尽可能开放更多的沟通渠道——聊天、电子邮件、Twitter 等——并允许用户选择他们的反馈渠道。
一些 DevOps 团队已经集成了蓝绿部署、A/B 测试和金丝雀发布，以缩短反馈循环。建立这些框架并非易事，需要巨大的前期投入和持续的更新才能使其无缝运行。但是，一旦一切设置就绪，数据开始流动，团队就可以根据真实的用户与每次发布的新软件的交互，对真实的反馈采取行动。
大多数敏捷实践者和精益运动倡导者都提倡构建-部署-衡量-学习的循环，为了实现这一点，除了指标之外，我们还需要收集反馈。从短期来看，这似乎很昂贵且耗时，但从长远来看，这是一种万无一失的学习方法。
反馈带来回报的证明
无论是关于人还是项目，依赖第一手反馈而不是指标是值得的，因为指标很少以公正的方式解释。我们在其他行业中已经有充分的证据证明了这一点，例如 Zappos 和维珍集团等公司仅通过倾听客户的意见就为他们的业务创造了奇迹。我们没有理由不效仿，尤其是我们这些在开源社区工作的人。
反馈是我们发现盲点的唯一有效方法。指标在这方面没有太大帮助，因为当我们在处理未知事物时，我们无法找出问题所在。盲点会在现实与我们认为我们知道的之间造成严重的差距。反馈不仅鼓励持续改进，无论是个人层面还是产品层面，而且倾听和根据反馈采取行动的简单行为也能增加信任和忠诚度。
评论已关闭。