运用反馈技术构建网站 gov.uk

Jake Benilov 于 9 月 27 日在布鲁塞尔做了一场关于在构建网站 gov.uk 的过程中所使用的反馈技术的演讲。其内容基于他自己的博客文章《使 gov.uk 变得更棒的七种反馈技术》：

借助软件系统的帮助，现在人们可以更廉价、更频繁地获得各种反馈信息。但很奇怪的是，行业中的多数产品团队还只是仅仅满足于专门的测试团队为其提供的一些功能性的和非功能性的测试结果。

在其博客文章中，Jake 描述了他所见到的情况，在这个人数超过 250 人的团队中正在使用的以下所列各种反馈技术：

• 及早发布
• 产品分析
• 性能监视器
• 对用户的研究
• 无障碍性测试
• DevOps
• 直接来自用户的反馈

在 2013 敏捷之旅布鲁塞尔站，Jake 为大家展示了 GDS 团队用于提高其每天工作质量的各种创新性的反馈技术。InfoQ 就如何使用反馈技术以及团队如何运用精益创业（Lean Startup）的原则，使用最简可用的产品原型来做用户研究这些话题采访了 Jake。

InfoQ：网站 gov.uk 期望达到的最终目标是什么？产品团队又做了哪些不同的工作从而使得 gov.uk 能够实现这个目标？

Jake: 为了解决信息发布的难题，在 2010 年到 2011 年间产生了创办 gov.uk 的构想。在当时，英国中央政府通过互联网发布很多的材料，但当时的模式存在着严重的可用性问题（例如大量重复的信息，使用户很难找到其所要找的信息）以及信息的极度分散化（多数部门和机构都有其自己的发布网站，而且在信息表述和网站交互上每个又都有其特殊的方式）。

为了解决这些不足，gov.uk 团队开始构建一个可以被用作唯一入口的网站。它使得用户与政府间的任何交互——例如从领取汽车完税证到查询下一个法定假日是哪天——都可以通过它完成。同时它也有着自己独特的品牌风格。品牌风格相当重要，因为它渗透于网站的各个方面，从视觉识别和交互设计，一直到底层的承载内容的文字及声音。

为了避免重复犯过去的错误，gov.uk 的产品团队尝试着只开发一些对具体且明确的用户（非政府）有用的功能。在从老系统迁移到 gov.uk 的过程中，通过坚持这样的原则，使得大量的对终端用户不是那么有用的工具和内容得以去除。

该项目获得成功的另一大因素是项目团队愿意先发布一个最简可用的产品。虽然这时的产品还不很完美，但可以根据实际用户的反馈进行迭代开发。同时这也意味着 gov.uk 也许永远不会停止改进，一直持续到网站关闭的那一天。我们看到，仅在头八个月里就有多达 1000 次的功能发布，也就是说平均每个工作日有 7 次的更新。

InfoQ：对于产品团队而言，为什么获得反馈信息如此的重要？它究竟能够带来哪些好处？

Jake: 在开发新产品时，团队通常会就是否存在某种特定的用户需求以及所采用的实现方法是否能够圆满地满足这样的需求而提出种种假设。项目越大，其涉及的范围也就越大，就会有更庞大的、更多种多样的用户群，最终导致要做出更多的假设。反馈机制使我们可以对这些假设进行验证。虽然说经验丰富的项目团队通常会做出合理的假设，但智者千虑必有一失。而尽早地、尽可能多地获得用户的反馈就能避免团队在错误的路上走得更远。我无法想象一个类似 gov.uk 这样的规模和复杂度的项目如何在缺少一个快捷的反馈循环的情况下获得成功。

InfoQ：为什么你们的团队使用了这么多不同种类的反馈方法？只选择其中的几种来使用会不会更容易一些？

Jake:政府部门服务数字化的设计准则中的第三个准则就是以数据指导设计。在开发周期的不同阶段，不同种类的反馈信息可以提供不同视角的数据。实验测试（Lab Testing）和远程的用户测试在功能开发阶段极为有用；而在项目投产后，产品分析和直接来自于用户的评论则可以帮助我们了解产品的功能是否满足用户的需要。

不同的反馈机制间也可以相互补充和增强。例如，如果缺少了DevOps 的参与，我们就很难实现尽早的、尽可能多的发布。这样的系统总是会频频出错，而运维团队也会因此郁闷得发狂。又如，产品分析可以帮助告诉我们发生了什么问题，但如果缺少了用户研究，我们很难马上理解为什么会发生这些问题。所以只有既做产品分析又做用户研究，我们才能认识到问题的全部。

InfoQ：刚才提到你们的团队使用一个最简可用的产品原型来做用户研究，能不能举个例子来说明具体是怎样做的？

Jake: 在 gov.uk 正式上线前，我们曾经发布过网站的 Alpha 和 Beta 两个版本，并让它们与旧的系统同时运行。网站的 Alpha 版本确实是一个真正的最简可用产品。Eric Ries 把它定义成是一个主要用于学习而不是生产用途的产品。Alpha 版本从开发到投产只用了 12 周的时间，这里面还包括了招聘及组建团队的时间。这样做的好处是使我们仅在项目开始的几周后就开始得到有用的反馈，而无需等上数月甚至数年。虽然网站的 Beta 版本比产品原型要完整很多，但当它投产时还是缺少了很多关键的功能。随后我们测试了大量的现有功能，还添加了很多新的功能，并且重新设计和开发了很多遍直到它们满足需要为止。

例如，在公众用户的测试和反馈过程中，网站的主页就经历了四次彻底的重设计。针对于不同的用户群，如专业人员，求职者，企业主，退休者，残障用户以及不同年龄段和互联网经验的用户，负责用户研究的团队做了游击性测试（Guerilla Testing）（实验环境外的快速的、便捷的用户测试），以及多轮更为正规的实验测试和远程的用户测试。这些测试发现了很多以往不会在早起被发现的，有关设计决策的问题。例如，由于受到Google 主页的启发，早期版本的网站主页上只包含了很少的信息，完全依靠网站的搜索功能来导航到具体的内容。但是，用户测试的结果却显示了这样的主页对于那些习惯使用搜索引擎的用户来说并不是很有用。同时它也不能满足那些需要通过浏览目录的方式来找到他们所需要的信息的用户的需求。因此我们在随后的重设计阶段充分考虑了以上的这些实际需求，所以当gov.uk 正式上线的时候，其主页满足了各类用户的需求。

InfoQ：你们的团队中采用了 DevOps 的模式，以此来加强开发人员和运维人员间的合作。可以和我们分享一下这样做究竟带来了哪些好处么？

Jake: 一个非常明显的好处就是发布新的软件时要走的流程明显减少了。假设如果我开发了一个新功能，并且通过了代码评审并被产品负责人所接受，那么我几乎可以立即把它发布出去。这里不再需要有任何的麻烦的操作交接流程，但是一旦发布过程中出现任何问题，开发人员也就自然地难辞其咎。这样做大大加速了把原始构想转化为实际运行中的功能所需的时间。同时这也意味着每一个单独的发布都是十分安全的，因为它并不包含大量的功能变化。

这样的安排也使得 Web 运维人员和负责基础架构的人员能够专心致力于系统平台层面的性能提高，而不用每天忙于解决应用程序的缺陷，从而更好地发挥了这些人的专业技术特长。另一方面，由于了解了系统的基础架构，开发人员最终也能开发出调试更加方便的、更加健壮的应用服务。

查看英文原文： Using Feedback Techniques for the gov.uk Website

感谢侯伯薇对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。