谁应该用流程设计器

在业务的梳理和设计阶段都有可能用到流程设计器，这里提到的流程设计器是指有图形界面，可以通过拖拽图形设计流程图的设计器，而不是说一个开发者专用的XML编辑器。

既然涉及了图形化，就可以实现通过流程图与最终用户进行交互，对实际业务进行梳理和重组。图形比文字更容易让双方理解，这一点应该不会有什么反对意见吧？

下面就引出我们这次讨论的问题：“那么这个流程设计器到底是应该面向程序开发人员使用，还是面向最终用户使用呢？”

这个问题会衍生出多种不同的推断，讨论的焦点基本是围绕在：“是否要放权给客户进行设计工作呢？”

对 于这个问题大部分程序员都能及时给予否定的答案：“怎么能让不懂技术的人去负责设计工作呢？他们设计出来的东西要是用程序无法实现该怎么办？”社区中力挺 这种观点的人不在少数，比如OSWorkFlow就建议开发者通过直接编辑流程定义XML的方式设计流程，它们认为流程设计完全属于开发范畴，不需要也不 应该由最终用户介入。

但是，从最终客户方面又常常传来：“需要对业务进行定制调整”的声音，于是迫于市场和客户方面的压力，开发设计人员又开始研究如何让最终用户可以在应用层面对业务实现进行干预，于是出现了关于自动建表，定制表字段，自动生成表单等等相关的技术。

面对如此浪潮蜂拥，诸如MDA体系架构也开始蠢蠢欲动，想当初多少人怒吼着：“让开发人员失业，零编码实现业务系统。”那时的开发人员真是岌岌可危啊，总是担心害怕自己哪一天就被某个程序给替代了。可实际上过了这些年，也没看到开发人员集体失业的情况。

难 道是客户方面定制业务的需求减少了吗？好像不是因为这个原因，还是有很多客户抱怨市场瞬息万变，应用系统不好支持多边的市场风向。既然不是客户的需求减 少，而实际开发人员又没有被诸多的业务定制系统挤掉工作，那只能说明之前烽火连天的业务定制系统还无法完全满足客户的需求，客户依然需要通过开发人员才能 实现自身特定的业务需求。

现在我们依然需要面对的问题是：“客户需要随着市场的变动对业务作出调整和变化。”这个需求是现实存在的，既然市场提出了需求，势必会导致我们联想到是否可以将图形化的流程设计器直接提供给最终用户实现，以便用户对业务进行修改呢？

必须事先了解一点：“最终客户不是开发人员”， 他们不可能像程序开发设计人员那样信手拈来的编写代码，对业务模块进行调用，这一点就决定了我们最终提供给业务人员的设计器必定是功能受限的，不能把所有 功能都对其开发，而是应该限制他们的操作范围，让他们的操作保持在可控范围内，避免出现业务人员设计出一个完全不可能运行的流程图来，同时又要加强用户交 互的易用性，从这些方面来看，不论对设计和开发方面对我们提出了不小的挑战——如何帮助用户在不犯错的情况下，很容易设计出一个业务流程呢？

我们可以看到，如果要满足客户定制的需求，就需要提供两套流程设计器，开发版流程设计器需要提供各种接口方便开发扩展调试，最好还能和实际开发的环境集成。业务版流程设计器就要更加强调易用性，在功能方面进行限制，丰富校验和提示方面的信息。