《产品研发过程实践》（12）需求讨论过程

作者:asky 日期:2007-04-29

字体大小: 小中大

曾经参加过MS的一次笔试（哈哈，一个做得很烂的笔试，居然为我赢得了1个机会，呵呵，看来天下比我笨的人还比较多哦。哈哈，说一个比较自豪的哦，显摆一把，曾经参加过一个公司的IQ测试，结果发现是他们历史上参加这个测试的人员中，得分非常高的一个，于是我突然有一种高兴的感觉，呵呵，看来人都是有点虚荣啊。包括在这里写这件事，好像也挺孩子气的），题目是：“如果给你叁个月，你将如何设计一个资源管理器的Shell”。看到这个题目，的确让我很挠头，看来我们就如同穷困惯的孩子，在一下子得到了一大笔财产的时候，几乎不知所措了。

不说别人如何做的了，对于我们来说，一般的做法是这样的。下面的东西也许太简单了，但是我们实际就是如此做，也只能理解到这里了。

首先，我们会企图先花一些时间，先列出几个典型用户场景出来；比如举一个例子说：当用户手机地址本和服务器的地址本进行了无线同步以后，如果同步成功，将自动给用户的地址本做一个镜象，使得将来用户能够从这个镜象中取得自己某一个时间段的完整的地址本。OK，我们想像一下，我们是客户（当然，如果有现成的客户在眼前，而且这是他以前日常的一个工作，就不要想像了，问问别人就是了，胡思乱想没有什么好处），我们会如何使用这个功能。“我掏出手机(这一点一定要写，不要只是写系统的行为)à进行同步à同步成功à收到一条短信，告诉我同步成功，并且地址本已经保存”。很简单，不是吗？

OK，这时候，我们会拿起准备的一些基本的原则（比如你的系统中有多少概念？比如对于Word来说，保存就是一个概念），看看用户在这个操作过程中，是否和原来的概念有冲突？如果存在冲突概念，请想出合乎逻辑的处理方式。比如，在这里例子中，由于在网站上，我们也提供了用户手工备份地址本镜象的操作，那么这个自动操作，是否会覆盖用户手工的地址本镜象呢？如果是一个镜象区，那么当然会发生，于是合理的一个做法是，类似于游戏软件的存储，有一个自动备份的Save文件，其他的是用户自己Save的文件来处理。

然后，我们会结合一些我们在产品定义中写明的一些东西，比如我们的客户是商务人员，那么我们觉得在上面写得“掏出手机”这一点过于简单了，更可能的是：在收到一张名片，并且记录下来以后，然后进行和服务器的地址本同步（或者在开车回家的路上，闲着也是闲着，把手机同步功能打开，进行和服务器的同步操作），OK，场景发生了一点点变化哦。当我们把客户引入进来以后，会发生什么变化呢？

这些客户由于对地址本保险的要求很高，而且接待的客户也比较多，恩，那么说，一天同步的次数会很多了？那么也就是说，需要在备份区，不仅仅用日期，而且用时间来告知用户，这是哪一次同步以后保存的结果了。也许这样更好一些吧。

OK，剩下的，就是拿起粉笔的时候了，给没个操作过程中，可能发生问题的地方都打上叉叉，说，如果这个地方发生问题了，该如何处理？比如用户同步到一半，电话进来了，由于通话优先级是最高的，很多手机将中止同步过程，让位给电话接听，那么这个记录，是否还要记录？如果用户进行同步的时候，结果发现一条数据也没有添加、删除、修改，那么这个情况，也需要进行备份吗？我的一个建议是，在业务讨论的时候，尽量把情况设想得坏一点。所谓“系统没有那么复杂，不会出现问题的。”这种说法是一种极其不负责任的做法，即使如此做，我们也需要一个明确的说法，是“不管，错了也备份”还是“不成！”。在大家思路还很清晰的时候，把这些问题尽量多地解决掉，可以避免在开发过程中，不断暴露出这样那样的问题。出现考虑步骤这种情况实际上还是难免的，但是我们要让这种情况相对少一些，因为由开发人员提出的这种问题，是把宝押在开发人员身上，如果我不考虑这些问题呢？或者由于工作很紧，略过了呢？更为重要的是另外一点：在后期提出，由于这种问题众多，产品人员往往需要很快做出一个决定，这时候的决定往往是不慎重的，立即做出的；结果我们发现大量的概念冲突现象，而这些概念冲突一旦在客户方面体现出来，将极大地损害我们的声誉，因为客户不会理解这些修改情况，会认为我们的思路非常混乱；而且，有时候，某些概念的出现，实际上是为了弥补以前的概念的冲突，这种概念集越来越大的时候，我们将越来越难以把恐。

我的建议是把这种东西，写成一张小卡片式样的东西，在这里没有什么客户看不懂的东西，都是自然语言，只是在描述客户的看到的流程，至于你将来要如何做，那是后面的时候。

这一点做完了，习惯性的做法是，把这个大致的流程拿出来，让UI工程师进行UI流程设计（当然，如果有UI工程师的话，虽然现在国内并没有很多很优秀的UI工程师），如果你们公司没有这样的UI工程师，也不要省略这一步，产品经理和高级工程师们，也需要进行这项工作。这项工作的要点是：把你自己当做一个什么都不太懂的客户（虽然这一点很难做到，比如我觉得Word很容易使用，当需要保存的时候，我直接就是Ctrl+S了，但是对于我的父亲来说，他总是点开文件，然后选择保存，而且在保存过程中，有任何对话框出现，都将使得他非常困惑。），然后从最初的操作开始，按照如下的一些要点来衡量：

是否我们在一个界面上提供了太多的功能选择？做为一个工程师来说，我们当中很多人喜欢的一种形式是那种老手模式：没有太多的提示，没有太多的说明，很多的导航都在一个界面中，这将使得操作速度最快，而且界面也最容易做，呵呵，不是吗？但是，这一点对于一个第一次接触你这个系统的客户来说，就是一场灾难，我曾经在20个PageDown的网页中，寻找一个注册或者登录的口，结果发现，他在最下面，这是因为我使用了IE的搜索框找到“注册”这个词，才发现的。

是否我们在出现错误的时候，给了用户一个良好的提示，并且告知他应该如何进行下一步工作？说到这一点，我不由想起了，就在上个月，我企图在Sina上下载一个软件，Sina需要我登录，于是我第一次在Sina上进行了注册。一个大约只有10多项的注册填写页面中，我足足提交了6次（还好那天我真的很需要那个软件，我才继续了下去）。原因何在？其实很简单，首先，他在必须填写项前面没有用上大家约定俗成的“*”，于是对于我这种只想弄个用户名和密码的用户来说，所有没有”*”的项目我都是不填写的，结果他不断提示我，应该填写完整。于是我只能一次一次填写。然后，在问题提示和问题回答这两项上，问题提示是需要我自己填写的（虽然对于很多站点来说，也许更好的做法，是让用户选一个问题就可以了），我也填写上去了“Where are you from?”，问题回答上写上“Shanghai”，错误提示是“使用了非法字符”，而且也没有告诉我，到底是哪个地方存在非法字符。于是我找啊找，我没有使用任何的￥％￥％之类的东西啊。最后，我注意到问题提示中，有一些空格符，是不是这样呢？我只能把问题写成了“whereareyoufrom”，注册成功！这一点是产品就这样设计的呢？还是其他环节出了问题？如果产品就是如此设计的，我想这应该打板子了。不过顺便插一句，这也说明了Sina要么在技术方面无法监控失败注册的人数的手段，要么没有人监控，否则，一定会发现不少用户的放弃注册的案例。这一点Yahoo做得就很不错。

是否我们界面上搞了太多专业名词？以至于用户根本不了解意义何在？我们的产品不是自娱自乐，也不是为了卖弄我们的专业知识；让用户很难了解你的产品，最后无非是给你自己增加麻烦而已。这一点，我们可以想一下。讲到这里，举一个其他的例子，我曾经在一家公司的介绍手册上，看到了极其难懂的企业价值观，老总的提语，也让我看了3遍才明白说了一些什么东西。以至于我现在根本想不起来他们到底是干什么的。也许你遣词造句的能力很强，但是市场不是象牙塔，我们没有必要卖弄这些复杂的句式，简简单单说出来就可以了。我一直赞同一句话，如果一个人员，无法用半张A4纸，说明他的理由或者说明他的声明，我很容易把他看成一种遁词。因为很可能他故意让我看不懂而已。OK，还是简简单单的比较好一些了。

你的界面安排是否合理？比如举一个很极端的例子来说吧，用户根据姓名来Search，结果在查询的结果中，看不到这一项，你说如果你是具体使用的人，会是什么感受？很郁闷，不是吗？

……

类似的还有很多很多，你把自己放在一个客户的角度来使用这个系统会发现很多很多的问题的。这些是产品化过程中必须要解决的问题。不要太企图于改造用户和教育用户，要记住，是你的产品为客户服务，而不是客户为你的产品服务。当然，这一点所花费的成本会让我们很吃惊的。而且这种改善和改造将是一个长期行为。并且，更加令人郁闷的是，当我们面临一个比较严重的时间压力的时候（我们大多数项目或者产品都面临很严格的时间压力），这个将被当做最低的一个要求被放弃掉。这一点的确是无可厚非的，当一个系统连正常运行都无法做到，又有多少人在乎他到底是点击3次，还是点击4次鼠标呢？但是这不是说他不重要，问题是你对于你这个产品的一个看待方式了，如果仅仅是得过且过，那么就无所谓了；如果你希望你的产品能够被大多数人所使用，这一点不解决，将来就是一个超级大问题了。

OK，界面大致流程出来了，把这个流程发给目标客户，让他们来简单试用一下，或者让公司其他员工或者任何你所能找到的，将来可能使用这个软件的人，来试试，看看，是否存在问题。他们会给你很多很好的建议，这些建议往往是你在做的过程中，没有发现的一些概念上的误导，或者是一些界面上的元素导致的注意力分散。这是很难发现的，以为就象你编写程序，那么你会很容易理清其中的思路，但是当一个其他人来看你的程序，在最初的时候，他会感觉一些挫折感，因为每个人都有每个人的一个思路习惯，经常看别人代码的人，能够体会到这一点，在第一天，我们看这个人的代码，可能仅仅推进250行，来了解他的常规思路，但是在后来，推进速度会越来越快。同样也是，让其他的思路，其他的角度来看看你的成果，将是一个好的选择。不要怕别人的建议（虽然很多时候，建议隐含着一种批评在内），因为，这些问题如果暴露在客户面前，问题会更严重。

好了，功能点以及分支流程，我们大致知道了；一些小的细节，可能需要后面再补充或者修整，界面的安排已经大致也知道了。那么这份需求规约书，基本上可以提交开发了。虽然并不是那么完善，但是我个人觉得，应该差不多了。

最后说一点，一般的来说，在需求阶段我们是不考虑如何实现的，而且要尽量避免讨论这些问题。但是有一种情况下，我建议还是考虑一下相对好一些。比如你的系统面临大量的压力风险，或者面临其他技术风险，那么用户在操作过程中，某些时候也许会引发大量的服务器事务，那么多多少少考虑到这一点，会比将来发现了性能问题，然后再来解决这些性能问题，会好一些。至于其中的平衡和站位的方面，就不多说了，因为这是一个经验的问题，很难说明一定如此做是对的，那样做就一定是错的！

到了这个时候，真的比较振奋人心啊，看看，一个假的系统已经可以看见了，用户甚至可以在界面上进行一定程度上的流转了。而且我们和客户一样也比较清楚，我们在将来会看见的系统会是什么样子的了，他将完成、以及用什么方式来完成用户的业务了。