关闭

图形化误区

2457人阅读 评论(10) 收藏 举报

                图形化误区--再论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语言支持文件包含,可以把配置文件直接包含进脚本文件。也可以实时读取数据库的配置项目。

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:184743次
    • 积分:3131
    • 等级:
    • 排名:第11055名
    • 原创:94篇
    • 转载:1篇
    • 译文:0篇
    • 评论:455条
    文章分类
    最新评论