【UXRen译#31】用更具成效的东西来取代需求收集
我已经上百次在项目进程表中看到的这样的一栏。它通常都有同样的一个标签，写着：“收集需求”。而且通常周期非常短，也就1到2天，有时更短！
每当我询问项目经理这一步要做什么时，他们无一例外地会告诉我，他们会访谈主要的干系人，并收集得到的需求。项目需求收集就感觉像到草莓地里摘草莓一样简单。
这些主要的干系人是怎样知道这些需求的？哦，他们就是知道。他们已经思考过一段时间（除了那些没有思考过的）。他们已经和客户谈过了（除了大部分没有和客户交谈过的）。他们已经和销售人员、技术人员以及搞商业模型的那帮家伙（business modeling folks）都谈过了，这些人已经准确地告知干系人什么才能让产品成功（但这些人是怎么知道的呢？）。
一旦收集到这些需求后，就会写成一份文档（产品需求文档，或简称PRD）。需求文档一旦发布，就再也不会被修改或更新。它成了支撑整个项目的圣经般的存在。里面的内容就是我们即将设计和创造的东西。
避免计划脱轨
我们并不是一直不停地在收集需求，发布PRD。早期，我们的项目可能仅仅是从一个简单的目标出发的，比如“让静态的HTML内联网可以在微软协同办公平台运行。”毕竟，这能有多难呢？我们已经有了所有页面。我们只需将其导入新的平台。瞧！这不完事了！
但这不一定奏效。在项目中期的某个阶段，我们可能会遇到我们不知道的东西。一些我们本应该知道的东西。就好像HR部门刚刚购买了一套新的目标制定软件包（goal setting package ），正想要把它们整合到现有的流程中。或者保险手册的格式是PDF，我们要把它转换成别的格式。
突然间项目就脱轨了。一些我们不知道但需要做的事情添加进来。我们试图将它整合进现有的架构中，但这只会让我们里最终目标更加遥远。现在我们是在重构设计。一切都被延后了，计划就这样脱轨了。
在项目初始阶段添加一栏可以防止计划脱轨。如果我们可以让HR部门提前告诉我们目标制定软件和保险手册的事，我们可以安排时间来处理这些事情。
需求收集不一定有用
问题是，在项目初始阶段添加一栏并不能防止计划脱轨。但如果我们的目的是将责任转嫁给我们访谈过的干系人，跟他们说“我们访谈的时候你并没有事先告诉我们，”然后就算大功告成了。然而，如果我们的目的是为了创造让用户满意并满足他们需求的伟大设计的话，我们不应该停留在往项目进程中添加一栏的水平，而是开展一系列真正能起作用的活动。
我们在收集需求时，可以说团队是由两类人构成的：知道我们需求的人和需要去发现需求的人。这是一个不平衡的团队结构，从一开始就可能让每个人走错方向。
这一过程需要我们对事情是否属实有足够的信心，而且这是在没有任何制衡机制来检验我们是否对了的前提下做到的。需要我们提前知道所有事情，避开我们在之后可以了解更多的想法。在这一过程中，我们会因为一定程度上遗漏了某些细节而感到羞愧，哪怕实际上没有任何方式可以让我们知道是否存在遗漏。
为了让这一过程有效运行，干系人必须能够预测未来会发生什么，并且每个人都一清二楚。老实讲，这基本不可能。
求助科学研究方法（以及其他方法）
如果我们不收集需求，我们怎么知道我们的客户和用户需要什么？我们如何知道我们在业务及技术上的限制？
答案就是科学研究方法（以及其他的一些方法）！
我们发现，最好的团队已经用改变权力格局的4项核心活动来取代需求收集栏的方法。尽管一些人确实有想法，但它假设没有人真正知道我们需要创造什么，。如果我们想要验证并提炼这些想法，我们所有人就会更明智地知道哪些东西会取悦客户和用户。
这4项活动分别是形成假设、实施研究来检验这些假设、用场景来记录我们看到的东西、通过批评来验证我们的设计是否能够满足我们了解到的需求。有意思的是，这些活动没有一个是新的。我们一直都知道如何去实施这些事情。大部分人只是没有这么做。
形成假设
需求的核心就是假设的收集。如果我们的需求写的是“首页应该包括今日访问最多的页面链接”，我们已经把一堆假设带入里面。我们假设访问最多的页面是人们想要访问的。我们假设首页是他们进入这些页面的入口。我们甚至假设每个人都需要有着同样链接的同样首页。
我们怎么知道这些假设是正确的？例如，我们怎么知道在网站外不存在一个没有人访问但非常有用的页面？我们怎么知道人们一定会使用首页，而不是浏览器中的书签？
通过将我们的预设重申为假设，我们承认我们并不是无所不知。更重要的是，我们就可以公开讨论我们可以做什么，以及我们还不知道什么。
我们可以说，“我们相信提供最常访问页面的链接是服务用户的最好方式。让我们弄清楚是不是这样。”而不是直接陈述为一个需求。假设是需要证实或证伪的， 它让我们以这种方式在每一步都了解到了重要的东西。
实施研究来检验我们的假设
这才是科学研究真正开始的地方。当我们的团队有了检验假设的实验时，我们就可以马上观察用户是如何工作的。我们可以观察他们会访问哪些页面。更重要的是，我们可以观察他们平时本来会访问但实际上没有访问的页面（可能是因为他们不知道这一页面或太难找到了）。
我们通过拜访我们的用户并观察他们的生活和工作来对他们做研究。我们也可以做研究来了解有哪些业务及技术层面的限制。我们可以写小的原型程序来检查服务器的响应速度是否够快。我们可以对潜在客户尝试不同的定价策略，来看看他们是否能描述出这些差异。
每个实验都会让我们更明智。这是我们为什么让整个团队（包括干系人）参与进实验中的重要原因。我们可以让他们预测实验结果来提升他们的直觉能力，然后将他们的预测和真正看到的进行对比。
用场景来设想
所有这些研究都会告诉我们关于人们每天是如何工作的大量洞察。我们可以知道他们的动机和他们所处的实际环境。我们可以开始设想我们的新设计如何让他们的生活更美好。
我们可以用场景来表现这些洞察。在每个场景中，我们描述我们的未来用户需要做什么，他们为什么需要这么做，以及他们为了达到目标需要克服哪些困难。
基于研究的场景是获取需求的一种实用方法，因为它可以让整个团队聚焦在真实用户会做什么上。它直接向我们展示“为什么”，而不是解决一堆矛盾的、非人性化的“什么”列表。场景成为一块我们可以将设计注入其中的模板。它告诉我们，为创造一个伟大的体验，有哪些我们需要填补的隐匿处和裂缝。
用批评来验证
随着设计方案的形成，利用批评来保持需求的鲜活性是很必要的。好的批评会涉及到两个问题：“我们这样做是为了什么？”“有没有可替代的方案来达成同样的目标？”第一个问题有助于确保我们关注的需求仍然是一致的。
花点时间处理每个批评以重新讨论这些需求，这样我们可以确保这些需求仍然是有效的，特别是对于那些从一开始我们了解到的所有新东西。这样的讨论可以让需求一直成为关注的焦点，而不是让它们埋没在连续几个月都没有人打开过的文档里。如果每个人都有机会尝试不同的方案来满足体现需求的场景的话，我们会对团队的创造力感到惊讶。
通过花时间来省时间
写着“收集需求”的栏目是很小的。进程表上面也只会安排几天的时间。
形成假设、进行研究、创造场景，然后开始批判，这些替代性的活动会花费更长的时间。比一般步骤多得多的时间。当日程表已满时，我们要如何做这些事情呢？
我们必须把项目的其他部分放到整个大背景中来考虑。通过以更快的速度接近一个伟大的设计，我们节省了多少时间？由于每个人都对我们为什么在做我们正在做的事情有着一致的看法，我们可以挽回多少时间？
我们在实施整个项目时循序渐进地开展这些活动，而不是事先集中在一个小栏目里。它们实际上让项目表中的其他栏目变得更好更快（译者注：项目进展的更有效快速）。以一种诡异而复杂的项目物理学的方式, 我们最终通过花时间而节省了时间。
最重要的是，我们最终得到了一个利用真实需求来创造完美体验的设计。这也是我们最最需要做的事情。
译者：阿东；审校：Figo；发布日期：Jun 25, 2013 原文作者：JARED M. SPOOL
原文链接：http://www.uie.com/articles/requirements_gathering/
顶部图片来源：http://hubspot.net
版权所有：UXRen翻译组 （转载请注明出处！）