反馈的问题

反馈往往被吹捧成万用灵丹，似乎它能够解决所有软件开发中的灾难的。嗨，我们当然喜欢它！但我们也需要牢记反馈中的某些重要方面，而不是简单地宣称：“更多、更频繁的反馈”是所有问题的答案。

1. 不是所有的反馈都是均等的。
2. 反馈有其代价。

这意味着我们需要明智地选择从何处收集反馈，以及打算如何使用它。

1) 反馈并不均等

反馈不是预言，因为数据并不会告诉我们应该做什么——它只是简单地反应某个问题。订单系统告诉我们，与去年同期相比，本月销售业绩有所下降。那么显然我们会想要问个究竟。或许我们会致电某位客户，询问为何今年没有购买我们全新升级的产品，他们则会给我们提供一些理由。

反馈可以分为截然不同的两类——一种是定量的，另一种是定性的。这两种反馈都会为我们揭示一些事情，但又都无法告诉我们需要做什么。而即使需要采取行动，该做什么也并不总是显而易见的。或许去年我们发起了广告推广，并由此带来了销量激增。但我们不应该因此就期望今年的销量能与去年比肩。实际上，为了针对某个假想问题做出响应而调整产品，也许反而会带来更糟糕的问题。

因此，我们需要大量反馈，用来确保能够去除所有妨碍信号的“噪声”——而这并不总是容易实现的。虽然数字形式的硬反馈（例如销售业绩、使用率和注册率等）并不会撒谎，但是有时候需要对它们进行合理解读。销售业绩下降或许是灾难性的，然而引人注目的数字，却很少包含解决问题的线索。

但是请注意，这种反馈至关重要。它是如此重要，以至于我们建议时刻努力让“概念兑现”反馈回路变得尽可能的紧凑和快速。

这是因为主观数据和反馈可能会带来误导。人们并不总是会对我们开诚布公地反馈其喜恶的真实想法。例如大量研究显示：人们宣称自己需要健康饮食，然而实际上他们往往却会选择不健康的食品。如果我们是咖啡店老板，并基于第一个数据集（人们宣称的）决定在菜单上提供多种沙拉，那么我们或许会发现利润下滑——相反，隔壁的汉堡店每天都能比我们多卖出数百份不健康的食品。

这不完全是由于人们在刻意地或非刻意地进行误导，而是因为他们或许也不知道自己想要什么。所以我们会使用诸多反馈技术——例如原型设计和测试环境——来帮助我们了解客户实际使用和行为的（而不是人们宣称的情况）。

当墨尔本的 Monash 大学希望了解学生（作为潜在用户）对学校课程查询系统看法的时候，他们没有直接询问学生的意见。相反，他们针对两种不同的设计思路创建了纸面原型。接下来，学生们与这些“纸面计算机”进行互动来完成任务。虽然工作人员稍后也询问了学生们更喜欢哪一种方案，但大部分重要信息仍是来自于观察学生们的实际表现——学生们与哪个系统沟通起来更容易。这一测试的结果，使得产品团队选择了他们从设计角度来看并不喜欢的那套方案，不过显然学生觉得这一套设计方案更易于使用。更重要的是，这个练习还引出了其他问题，例如几乎 1/3 的学生都不能完成任务，因为他们无法理解从何处获取进一步的信息。没有哪种主观的问题集能够引出这样高质量的反馈。

最后，如果说并非所有类型的反馈都是均等的，那么同样地，消息来源也并不是都均等的。回到我们假想的那个销售下滑的公司……当我们开始拨打客户电话收集反馈时会发生什么？他们将给出各自不同的回答，甚至是互相对立的信息。而当我们加入市场总监、CFO 乃至 CEO 的侄子，甚至还有其他人的意见时，我们又该听谁的意见？

许多组织机构都在回避这个问题——或许因为他们知道真正的答案是什么，但是也太清楚这会与实际发生的情况不同。我们全都遇到了 HiPPO（工资最高的人的意见）的问题，而我们必须努力确保高层意见不会盖过客户的声音。为了实现这一点，我们需要确保让自己的工作与真正的客户保持尽可能紧密的联系。

有时候我们也不会听命于客户。客户有时希望我们的公司做一些我们明知缺乏利润、或是在某种程度上会损害利润的事情。在某些情景下，大量反馈会带来干扰视线（或许某个观点是如此的激进，以至于现阶段没有人能够真正理解它）的风险。客户不应该控制开发过程，但毫无疑问开发过程应该吸取来自客户的信息。只有客户能够告诉我们他们会为了什么买单。忽略客户的声音将带来风险。

EricRies 在他的著作《精益创业》中讲了这样一个故事：一位少女正在测试产品，而在弄明白产品是否很酷，她不想邀请任何朋友来聊一聊这个产品。Ries 转而招募了另一位青少年……同样的故事再次上演。对此 Ries 沮丧地评论道：“我们开始遇到一个模式，而无论我们有多么固执，都无法否认肯定是有什么地方出问题了”。

问题在于，许多组织机构都很少与实际客户进行沟通。相反，他们或许会安排一些“内部客户”，或是“客户代理”。无论我们称之为产品所有者、客户代表或“业务客户”，其实都没有什么差别。尽管这看起来像是一条有效的捷径——客户代理会做出全部优先次序方面的决定，并接受或拒绝产品——但实际上他们依旧不是真正的客户，因此他们反馈的价值也是有限的。团队依旧需要让产品进入真正客户和用户手中——这是无可替代的。

然而，缺乏与实际客户之间的沟通，并不是做大量预先探索的借口。就像刚刚讨论的那样，没有任何模拟的或主观的反馈能够与真实数据相媲美。这也意味着需要持续不断地、尽可能地缩短概念兑现周期，从而让产品进入真正的、掏钱的客户手中。

还有另外一个复杂的因素，会让这个话题变得更加困难一些。反馈的类型和来源并不均等，同样我们关注程度也并不均等。我们所有人——无论自认为多么经验老道、学识丰富——都会受到认知偏见的影响。这种影响意味着我们对于与自己的观点相似的证据，无意识地赋予了更大的权重，却忽视与我们观点相左的证据。

我们并不会因为得到了有助于项目改进的新输入而欢欣鼓舞；相反，我们将反馈看作返工的引子。有多少次我们听到团队中的某个人在抱怨：“我又得全部重来了！”？诚实地讲，有多少次我们自己也有同样的想法？大部分组织机构或个人认为，与寻找一个真正客户加入团队、打造更短的开发周期或是设立测试以观察用户和客户反馈相比，对反馈进行检索、特别是检索不受欢迎的那些反馈要更加困难。对这样的组织机构和个人来说，他们都需要重大的文化转型。

2) 反馈有其代价

反馈的价值巨大。微软技术研究院 Brian Harry 满怀热情地表示，“反馈帮助我们理清自己的理解、从新的角度看待事物、修正自己的方向，并且还帮助我们学习。它让我们和我们的工作都变得更好。无论是否采用特定的敏捷实践，及早并经常地反馈是取得进一步成功的关键。”

反馈支持敏捷宣言的许多方面。我们基于反馈实现迭代交付，而且许多敏捷实践已经将反馈的时机规范化了，从 XP 中的结对编程，到 Scrum 中的示范和回顾莫不如此。

在所有有关如何以及何时在软件开发中嵌入反馈回路的讨论中，对于反馈的一个重要方面——也就是它的代价——有时候会出现奇怪的沉默。

在被抗议的声浪淹没之前应该澄清的是，我们并不认为强调反馈的代价意味着不应该收集反馈。这有点像买房子——检验报告不是免费的，但与买下没有测量报告的房子后发现房子下沉、干腐、泛潮或是有木虫等问题的代价相比，检验报告的费用就微不足道了。显然，反馈也是一样，它不仅能够帮助我们避免灾难，还有助于找出客户喜好、改进质量并提高价值。

但反馈需要付出代价这个事实，确实意味着我们需要注意所追寻的反馈类型，以及我们追寻反馈的频率。就像前面所强调的，反馈常常是帮助我们了解，是否已经做了足够多——让失败提早发生以降低成本。与付出巨大投入来确保拥有必胜方案相比，这往往是一种更好的策略。

我们嵌入的反馈回路是否带来了相匹配的经济利益，这永远是个值得考虑的问题。

我们是否将要使用所收集的反馈？是否真正能够对它做出反应？提前收集反馈，是否能够剩下采用实验并判断其结果的开销？

我们的观点是，虽然通用规则——尽早、尽可能频繁地获取反馈——依旧有效，但我们还需要通过个体判断来回答这样的问题：我们需要什么类型的反馈，以及我们需要以什么频率收集反馈？

就像 JurgenAppelo 在 _《Management 3.0》_ 中提出的理智看法：“达到某个平衡点后，进一步缩短反馈周期的长度将失去意义。也许将 Scrum 的 sprint 长度从四周缩减到一周是很伟大的事情。但考虑到需要解决的麻烦，或许并不值得将它进一步缩减到一天。在某些点上，性能改进将会趋于平缓，而且其价值无法匹配为此额外增加的开销和评测成本。”

在探索阶段，我们想要找到关键的信息，而且需要尽可能快、尽可能低成本地找到它。设立模拟实验或许意味着投入将超过反馈带来的价值。作为替代品，我们可以使用线框图或纸张。同样，一些单元测试或验收标准的设立，可能会被证实其维护成本远大于收益。系统级测试会延缓整个进程。在这种情况下，稍后再修复问题实际上会更加划算。对于这个问题，个体或团队的智能判断无可替代。

值得一提的是，尽管频繁反馈的代价更高，但并不一定会出现相同量级的增长。Don Reinertsen 在 _《The Principles of Product Development Flow》_ 中写道：“拥有较长时间常数（time-constant）的反馈回路，仅能够平滑同样长的时间常数的变化。这意味着我们往往需要在缓慢的反馈回路中嵌入拥有快速时间常数的反馈回路。这些快速时间常数反馈回路并不需要巨大的动态范围，因为累积变化基本上与时间的平方根同比增长。因此，只需要更少的资源边际，就能够维持对快速反馈回路的控制。”

总结

无论反馈的代价还是噪声干扰，本文提到它们的目的都不是要阻止读者收集反馈。文中提到这两个方面都是为了提醒读者，与其他工具一样，反馈也需要合理使用。以下是在收集反馈过程中应该牢记的十大要点：

1. 投入最小的时间、精力和金钱，来回答我们的问题。
2. 反馈本身无法告诉我们应该做什么、如何排定优先级或是为我们提供一份计划。
3. 从市场上寻找反馈，而不是在内部观点或是模拟环境中创造的人造结果里寻找。
4. 反馈往往是依赖于上下文的——我们并不总是需要一份严格的双盲试验，但我们应该识别出自己的先验假设。
5. 记住，客户的行为比他们的观点更重要。
6. 速度往往比精确更重要：有时候，一系列实验会比计算更快找到答案。
7. 随着反馈收集频率的上升，单次收集的开销会降低。
8. 犯错的风险越高，我们越需要寻找反馈。这听起来显而易见——然而大部分人都在隐瞒风险。
9. 不要让测试或是内部反馈耽搁我们从客户处直接获取反馈的行动。
10. 面对反馈，我们需要正确的态度——拥抱改变，不要害怕返工。另外我们所有人都存在确认偏见，会导致我们寻找与自己一致的见解，并拒绝与我们相左的意见。

关于作者

Alex Adamopoulos**** 作为执行官在全球服务组织机构方面有着 25 年以上的经验。对于文化、工作和生活伦理学，特别是在建立一致性与跨越文化壁垒方面，他拥有广泛的经验与深入的理解。多年以来，Alex 为那些想要在全球竞争中胜出的企业，引入了专业知识和实际业务经验。专注于绩效衡量、商业价值和获利底线，Alex 成功运用工作模型和实践来加速公司的解决方案和战略驱动，从而拉动收益。

查看英文原文： What’s Wrong with Feedback