获得和改进快速反馈的七种方法

在高中和大学里我作为游泳运动员时学到了快速反馈的重要性。像绝大多数人一样，我在游泳池开启了我的游泳生涯。如果你在游泳池偏离了方向，很快就会碰到泳道线并得到反馈。

最终，我厌倦了在游泳池里一圈一圈地游，转而到开放水域里。与在游泳池里每25米折返一次不同，游泳运动员在开放水域里通常在两个或者多个点之间要游数英里，比如游跨海湾。

在海里游泳的时候并没有泳道线帮你保持在航道上，而是你自己要设定一条路径，如果你偏移太多，你最终会比你预期的游得更长。

游泳运动员保持航道的主要策略是时不时地抬头以确认路径。

他们获得反馈的频率越高偏离航道的可能性就越低，于是多久抬一次头就很关键，太频繁很容易累，次数不足就会容易偏航。

这与敏捷团队如出一辙，在Scrum中短的反馈循环为团队提供了多种检查和调整的机会以确保产品朝着正确的方向发展。

增加和改进反馈

让我们看看做哪些可以改善反馈的时机和它的用处。

首先，如果你还没在每个迭代结束的时候举行评审会，那是时候开始了。一些团队认为他们是在通过降低冲刺评审频率来节约时间，但这会因为一次迭代中的小误解可能在几个迭代后变得更严重而产生问题。

在员工分布在全球各地的时候，你还需要考虑给那些没办法参加现场评审的员工分享一下会议记录。在某些情况下你可以实录评审会，不过在大多数情况下，为新功能演示创建一个讲解视频对你更有帮助。

如果在每个迭代你都创建这样的屏幕录制，这件事儿就会变得很快，毕竟通常不会有太多的新增功能。屏幕录制的链接可以所有人共享，也可以仅仅给那些没能参加的人。你可以要求人们直接发给你反馈或者让人在视频的页面下面留下反馈。

在迭代评审会之外，你也许会考虑开展一系列一次一个的特性评审。在实现每个特性时，只给少数提需求的干系人和用户展示以征求他们即时反馈。

并不是每个参与迭代结束评审的人都需要对每个特性提供反馈。和对应的干系人进行一次一个的评审通常可以尽早产生更高质量的反馈。

在征求反馈的时候需要问多样化的问题。在很多评审会上，唯一被问到的问题是“你觉得怎么样？”，而通常也仅仅会得到像“我喜欢”这类很难对其有任何行动的评论。

我喜欢很多东西，但是很多东西都有变得更好一些的可能。我喜欢来自附近玉米卷卡车的玉米卷，但如果能更辣就更好了。

问“你觉得怎样”通常得不到我们需要的更确切的反馈。取而代之要问更多具有目的性的问题，诸如：

进一步深入：当问这些问题的时候，考虑向特定的人发问，而不是问所有人。当然，要对任何人的评论都保持开放的态度。但是向特定的参与者直接提问可以减少尴尬的沉默，并且有时可以带来更好的对话。

评审的时机也很关键，请尝试在这些特性100%完工之前就演示和获得反馈。假想你在开发一个仅能在10个产品待办列表的条目完成以后才可以交付的新功能。别等到第10个，也就是最后一个待办项完成以后才征求反馈。

只要可行，尽量直接从用户而不是代表用户发评论的干系人那里获取反馈。对于内部使用的产品，尽可能简单直接地邀请用户一起参与评审。对于商业化的产品，你可能需要为用户能分享反馈而创建一个公共论坛。

最后，确定团队在做计划的时候为这些反馈所需采取的行动规划了时间。对干系人和用户来说没有什么比自己提的反馈被忽视更令人沮丧的了。

下面是七个可以帮你提升反馈的质量和实效性的要点：

快速且频繁地获取反馈让团队可以打造满足用户需求的产品。一个团队如果很少收到反馈，那么在发现偏航时就不应该感到惊讶，好比一个游泳运动员对是否接近尼亚加拉瀑布失察一样。

你怎么看？

你如何确保你能尽早获得有价值的反馈？请在下面的评论区分享你的想法。

注：部分图片来源于网络

原文地址：

https://www.mountaingoatsoftware.com/blog/7-ways-to-get-and-improve-fast-feedback

Mike是敏捷联盟及Scrum联盟创始人之一，是帮助企业适应和改进敏捷过程及技术，以建立极致高效团队的专家。著有《用户故事与敏捷方法》，《敏捷估算与规划》，《Scrum敏捷软件开发》以及视频课程《更好的用户故事》。

Scrum中文网是全球第一个Scrum中文网站，中国最早的Scrum和敏捷教育及推广机构，也是国际Scrum联盟（ScrumAlliance）官方授权教育机构和大规模敏捷SAFe官方机构SAI在中国的授权合作伙伴。

Scrum中文网是国内领先的敏捷培训及教练咨询机构，作为中国敏捷教练的摇篮，启蒙和培养了数万名敏捷专业人士，帮助数百家知名企业成功转型敏捷。