图形化分析方法获得用户一致好评

虽然快速开发工具是个内部的项目，但也要确定需求规格。因此在功能范围明确之后随即开始需求调研，因为未来的“用户”既是同事又是技术人员，所以第一天的调研工作非常顺利。

“用户”一张口就滔滔不绝地讲解开来：一个功能的工作流程应该包括哪些步骤，每个步骤应该用什么界面，界面上应该有哪些字段，字段的长度、类型、格式和显示方式应该怎么样，字段之间逻辑关系如何，出了错误怎么处理等等都说得清清楚楚，甚至对界面布局和实现方法都会直接给出建议。

晚上小M按照调研的记录整理出了需求规格文档，第二天一早就请对方确认。没想到昨天还滔滔不绝的调研对象看了需求规格之后却连连摇头，表示与自己的描述相去甚远。虽然有点不以为然，但小M只好按照“用户”的要求进行修改并再次确认，这样反复了两三次之后才最终完成。

一轮下来小M就发现沟通方法有问题了：界面是非常形象具体的东西，说的人其实脑子里都有一个画面。现在的调研方式其实是一个人在描述自己脑子中的画面，一个人再根据听到的描述勾勒还原别人脑子中的画面。这个转换过程有点多余，也容易出问题。

首先，语言描述的歧义性比较大，比如，“三角在圆的上面”这样一句话就可能有两种理解，而且两种都是对的，如图2-1所示。因此，沟通的双方虽然说着同样的话，脑子里却可能是完全不同的画面。

图2-1 语言歧义：三角在圆的上面

其次，语言的传递过程是线性的，不利于表达复杂的结构关系。如果一个功能的工作场景比较复杂，涉及多个画面，用语言就很难描述清楚这些结构关系了。甚至有时说的人已经在描述下一个画面了，听的人脑子里还停在上一个画面中，因此越说越远。

小M试着改变了访谈的方式——把语言描述改成“看图说话”。如果想讨论一个界面，就把这个界面的草图用铅笔画出来，然后对着草图边谈边改。界面上有哪些字段、字段的规格和逻辑关系都可以标注在草图上，对着同一个图讨论就不会有歧义了。如果要讨论工作流程这样比较抽象的东西，就画个流程图，将抽象的流程转变成具体的流程图。

比较麻烦的是一些复杂的流程，根据不同的执行情况会跳转到不同画面，因此很难在一张纸上表述清楚。小M想起了电影里指挥中心的那种大型作战图，于是找来了一块巨大的白板，先把完整的流程画在上面，再把每个环节上的界面草图贴在对应的节点上。这样，一个复杂流程的工作场景就尽收眼底了：流程从哪个画面进入，完成一个步骤之后进入哪个画面，出错了切换到哪个画面。因为所有的讨论都集中在一张大图上，所以怎么切换场景都不会跑题，如图2-2所示。

图2-2 白板+草图画复杂场景(www.xing528.com)

这种白板加草图的方式虽然土了点，但因为整体感强、产生歧义少，基本可以一次性地确认需求规格，所以很快成了大家的标准工具。

当然，完成草图之后还需要整理需求规格文档。大家发现，根据草图已经可以进行界面的开发了。而把草图整理成的文档工作量和直接开发出界面的工作量其实差不多，还不如跳过文档环节直接开发界面原型呢！如果在界面原型上增加一些简单的控制，就可以演示流程的执行效果，用户特别容易理解。

小M也觉得这个建议非常好，于是自作主张将需求规格文档省了，让大家拿着草图直接开发界面，以后有空再把草图整理成文档。大家都认可这种事半功倍的创新方法！大师兄虽然有保留意见，但只能提醒小M千万保存好那些铅笔草图，否则以后其他人只有通过看代码才能了解最初的需求是什么了。

通过界面原型交流一般只要第二次确认就能精确锁定需求，所以大家逐渐摸索出了“讨论、确认、锁定”的工作三部曲：

第一天，白天讨论需求，完成铅笔草图；晚上，将草图开发成界面原型。

第二天，确认界面原型的执行效果，收集修改意见；晚上进行修改。

第三天，再次演示界面原型的修改结果，锁定需求规格。

如果有多个流程需要调研，滚动起来的工作日历就像表2-2这样。

表2-2 规格确认三部曲

这种工作方法效率很高，强度也确实很大，每天晚上都要加班。但是团队的工作热情更高，从来没有人抱怨。经过1周紧张工作，快速开发工具的界面原型终于完成了。通过实际演示用户对于系统功能甚至以后如何使用都比较清楚了，并对这个图形化的分析方法给予了一致好评。