图形化误区

                图形化误区--再论IVR语音平台的选择

      选择IVR平台工具的时候，往往会被花哨的图形化工具所吸引。以至于很多做语音卡开发的人，他们也试图开发出类似的图形化流程编辑工具。
      这在我看来，实在是个天大的误区，白白浪费了很多优秀程序员的青春年华。
     其实，根本的原因我在《以语言为中心--论语音平台的开发》(http://www.bluespace.com.cn/koodoo/article_ctilan.htm)一文中作了阐述，也在各专业论坛上和图形化的拥护者进行过多番辩论。这篇小文试图从另外一个角度，也就是用户角度来探讨一下图形化拖拉工具的误区。

    图形化拖拉来代替编程不是什么新鲜想法，我们拿最新的最时髦的是UML的双向转换工具来做例子，UML的很多图形，如类图、用例图是很好的设计工具，尤其是在需求分析阶段，可以很方便地和多方参与人员进行交流。很自然的想法是，如果不用编程，画好的图就可以编译出可执行程序多好？
    也的确有厂家是这么做的，我在去年的高交会上，看到一个国内厂家的产品，采用非标准的仿UML图生成可执行程序，展台前就围满了感兴趣的人群。
    但这种做法并不高明，它不由自主地增加了复杂性，原本作为设计思想表述或需求分析表述的UML图，本身并不要求那么严格、那么精密，可以省略很多的细节--也必须省略很多的细节才能看清楚突出主要的设计思想。但作为代替编程工具的图形则不然了，必须考虑每一个细节，也必须增加更多的语法装置。

    敏捷开发先驱Martin Fowler曾写过一本《UML精粹（第三版）》书，堪称精品－－虽然作者自谦说“这是一本小书”，其中的主要观点非常有借鉴意义，他提出了UML的三种使用方式：“用作草图绘制语言，用作蓝图绘制语言以及用作程序编制语言”，他倾向与第一种应用，对于第三种应用，他评论道：“但我怀疑这样做的意义。我并不确信，对大多数编程任务而言，图示形式要比文字形式更富有成效；并且即使如此，对一种语言来说，也很难被广泛接受”。(说句题外话，这本书被徐家福差劲的翻译糟蹋了)

    回到IVR流程设计，我认为应该对各阶段的人群进行这样的划分：
1.IVR流程设计者，也就是采用语音平台开发工具的人，他们可能是集成商，也可能的用户单位电脑中心的开发人员，总之是懂电脑的人；
2.IVR系统的日常维护人员，可能很懂电脑，大部分是一般的应用水平；
3.IVR系统的使用者，他们是最终用户，在电话机上操作。

    从需求的角度，“1.IVR流程设计者”需要良好的语音平台工具，以实现业务流程的快速开发，因为他们是掌握编程语言的人，所以高级编程语言类的工具让他们降低了学习曲线，图形化的工具因为表达能力的限制效率很低下；
对于“2.IVR系统的日常维护人员”，他们实际上是“1.IVR流程设计者”的用户，因为他们不一定懂编程，所以他们可能需要容易使用的配置工具，如修改ini配置文件，图形化的配置工具等等。问题是：日常维护人员需要去开发修改全部业务流程吗？这些业务流程往往是复杂的，所以“1.IVR流程设计者”应该分析出业务流程之中经常可能变化的部分，抽象出来作为ini文件，或者做成图形化的配置文件，所配置的仅仅是很小的一部分。否则，如果配置很复杂很全面，“1.IVR流程设计者”的设计是失败的。
    换一个角度，假如“2.IVR系统的日常维护人员”可以编制、修改全部业务流程了，那说明他有编程能力，可以将他归类到“1.IVR流程设计者”了。
    至于“3.IVR系统的使用者”，他需要操作简便，一致性好的界面，所以要求“1.IVR流程设计者”对业务系统和最终用户心理有良好的把握，具体牵涉到“交互设计”技术。可以参考相关的文章，包括拙文《易用为王》。

    从上面的用户层次划分我们可以明白，IVR语音平台的真正用户是“1.IVR流程设计者”，他们需要精良快捷的开发工具。图形化拖拉工具试图让没有程序设计经验的“2.IVR系统的日常维护人员”来做最底层的开发，进入了一个误区。

    当然，给“1.IVR流程设计者”提供的工具中，应该包括方便的配置方法，如蓝星际公司的Koodoo语言支持文件包含，可以把配置文件直接包含进脚本文件。也可以实时读取数据库的配置项目。