在大多数情况下，从征求服装建议到寻求对下一个科学发现的同行评审，我们都会借助周围的人来讨论和分析潜在的后续步骤。几乎没有人能立即想出完美的解决方案；这是一个迭代的过程，充满了试验和错误、调整和新的实验。
这是一个我们可以不断改进的过程。本章提供了一些关于如何做到这一点的建议。
什么是反馈循环？
反馈循环应该很棒，并且可以解决各种问题。那么，它们到底是什么呢？
还记得你小时候画的第一只猫吗？你骄傲地把它展示给你的父母，他们建议你给它加上一条尾巴。你回到画板（字面意思），加上了尾巴，给他们看了结果，然后他们把画贴在了冰箱上。
这对你来说就是一个早期的反馈循环：一个自我循环的过程，就像蛇吃自己的尾巴一样。
你可能熟悉另一个早期的反馈循环，称为“戴明循环”
计划 – 执行 – 检查 – 行动
W. Edwards Deming 后来将其更新为
计划 – 执行 – 研究 – 行动
……我同意这是一个更好的描述。
类似的循环或过程还有休哈特循环、六西格码（界定 – 测量 – 分析 – 改进 – 控制）和精益创业（构建 – 测量 – 学习）。
所有这些的共同点是对迭代模式工作采取科学的方法：尝试一些东西，从中学习，并在前进时相应地调整你的工作。换句话说
熟能生巧并非完美。练习使之成为永久。反馈使之完美。
为什么反馈循环很重要？
更短的反馈循环（即，在你尝试某件事的时刻和你了解其效果或结果的时刻之间花费的时间更少的循环）允许你快速修复或改进工作，并更快地获得额外的价值。执行一个小修复，接收关于它的反馈，然后再次尝试不应该是一个巨大的负担——如果你已经在一个事情上工作了很长时间，并且发现你将不得不重新开始，那将会是巨大的负担。换句话说，你可能在朝着错误的方向前进，但是如果你及早收到反馈，那么当你重新开始时，你将不会有那么长的路要退回。
各种敏捷软件开发方法认为短反馈循环对于保持敏捷并在最短的时间内产生正确的结果非常重要。
团队可以通过诸如“结对”或“群组编程”、每日站立会议和冲刺等技术来安排和完成这些反馈循环。例如，当通过结对或群组编程工作时，开发人员可以直接在共同处理任务的人员之间体验反馈循环。在每日站立会议中，他们从同事那里获得反馈。在一个冲刺之后，他们最好从客户那里收到反馈。在所有这些情况下，人们收到的反馈帮助他们在开始某个过程中的额外步骤之前改进他们的工作。
这种工作方式甚至在软件开发之外也是可能的。但在这里，我想特别关注它如何增强 IT 组织。我将介绍一些通用术语，这些术语适用于所有部门、团队和工作方式。
我们如何增强 IT 组织中的反馈循环？
在 IT 组织中，保持透明是给予和接收反馈的先决条件。人们可以对其正在进行的工作和计划中的工作保持透明。
例如，我在运营团队中使用看板时有过积极的经验。当看板对所有利益相关者、经理和其他团队可见时，每个人都会收到关于工作项的当前状态和当前优先级的反馈。人们也有机会从查看看板的人那里收到自发的反馈，并注意到一些东西，例如，另一个团队可能也在做的事情，或者不再重要的事情，或者（更好的是）看板上缺少但肯定应该在上面的非常重要的东西。
我建议尽早寻求反馈——如果可以，从一开始就寻求反馈。我经常勾勒出一个任务的轮廓，并让经理和主要利益相关者过目。这是了解我是否正确理解任务的最佳方式，并帮助我设定他们对我接下来交付内容的期望。
这一切听起来都很简单。那么，为什么这通常如此难以实施呢？最常见的障碍是什么？你可以做些什么来改进或促进更好的反馈？
为了使反馈循环良好地工作，你需要有一个开放的环境，一个人们感到安全分享他们想法的环境。顺便说一句，关注反馈循环也可以帮助你改善组织中当前的环境。这就是反馈循环的美妙之处：因为它会自我循环，如果你周围的环境和文化默认情况下不开放，那么你可以通过自己更开放来改变这一点，提供反馈，确保从他人那里获得反馈，内化反馈，并改进。一点一点地，你和你周围的组织也会得到改善。正如圣雄甘地所说
欲变世界，先变自身。
记住：保持你的反馈循环短。你应该在对某事投入过多的时间和金钱之前寻求反馈。那么，如果需要这样做，改变事情就不会那么困难。
你还需要确保你有机会从通常不乐于公开分享想法的人那里获得有价值的反馈。通常，人们会在演示或会议上征求反馈——这意味着他们亲自这样做，并在人们发言时接收反馈。对于所有人来说，这可能不是最好的沟通形式，坚持这种单一的反馈环境可能会让你错过你原本想知道的深刻见解。改进这一点的一种方法可能是向所有参与者发送会后电子邮件，提醒他们将反馈直接发送给你（最好在设定的时间范围内）。有些人更喜欢在自己的时间内并通过更适合他们的媒介（而不是在所有人面前发言！）来表达他们的想法。
你可以收到的最好的反馈是直接来自实际用户或客户的反馈——但是当你与远离客户的多个层级的基础设施打交道时，你该怎么办呢？
在最好的世界里，客户反馈会涓滴细流到所有相关领域和团队，但我们都知道这很困难，并且通常在现实生活中不会发生。根据你的产品或服务，你可以与客户一起安排研讨会，并将来自组织各个层面的人员包括在内。我已经这样做过，效果很好。否则永远不会出现的讨论和想法突然出现，行动计划也随之制定。
如果你定期与客户开会，你可以偶尔邀请组织其他部门的人员作为嘉宾参加。根据我的经验，所有各方都赞赏这种举措。
在其他组织中，人们可能会将周围的内部团队和部门视为客户，并促进与他们的反馈循环。反过来，他们可以从他们的客户那里获得反馈。我建议你尝试在所有团队中建立这一点，因为你不仅需要来自外部客户的良好反馈，还需要来自你的合作伙伴和同行的良好反馈。
最后但并非最不重要的一点：记住，反馈循环不一定需要涉及人的互动。例如，你应该从你的监控系统和事件管理工具中收到有价值的反馈。自动化反馈可以让你意识到响应时间变慢，这可能表明新版本存在潜在问题，反复发生的次要事件可能是即将发生故障的硬件导致的，这些硬件可能会导致重大中断，并且显示你的服务用户群不断增长的统计数据应该触发一个计划，以便及时扩展环境，以免其遭受性能问题。
关于反馈的一些反馈
最终，团队进行反馈循环的能力归结为两个因素：沟通和透明度。
当你对你的进展保持开放并愿意接受他人的见解时，你可以更快地适应并创造最佳结果。长期以来，在准备好展示你的结果之前在孤岛中工作一直是常态；然而，随着我们发现将更多人和想法纳入设计和执行过程的优势，这种情况正在改变。
世界变化的速度比以往任何时候都快，快速适应从未如此重要。忽视你周围发生的所有反馈循环可能会导致你的解决方案或想法出现得太晚——或者追逐完全错误的问题。另一方面，反馈使之完美。
本文是《开放组织 IT 文化变革指南》的一部分。
评论已关闭。