基于WF的工作流平台（一）：需求分析
上一篇文章我们说了为什么要首先开发一个工作流平台，然后才能进行应用的开发。本文介绍一下我们的工作流平台的需求。
很多公司把平台作为一个产品独立的进行开发，这种方式对业务积累要求高、投入大、周期长，需要公司具有相当的实力。我们部门的主要业务是项目的开发和实施，没有投入专门的产品研发人员，所以只能在项目开发过程中构建产品的原型，然后进行重构，从而实现一个产品；这种方式投入低，但对技术要求高，风险也比较高；其实有足够的技术能力和较高的标准要求，每一个项目完成以后，都应该完成一个产品的原型，但大多数管理者没有用这个标准来要求，也没有这个奢望。
下面的需求分析，只是谈到我们的项目，我知道肯定还有更复杂的需求，但我们上文谈到WF的特点是细粒度的流程设计模式，实际上不论多复杂的流程，都是可以用WF高效地设计出来的。
我们第一个项目是一个全国性的大型外资房地产企业的办公管理流程，因为他们的组织结构、流程和业务都很复杂，所以他们前面两个版本的工作流系统都没有满足要求，我们是第三个版本了，因此客户要求非常高，但同时客户对需求非常明确，并且客户的项目经理非常负责任，几乎承担了所有和用户沟通的职责；一个好的客户项目经理，是一个项目最好的起点。
流程的需求
部门经理逐级审批
客户的组织结构有全国总部、区域级、城市级和部门级等，所有的流程都要求从申请人所在部门开始，逐级向上由各级经理审批，直至权限足够的经理。
每级经理可以对每一项业务设置权限
不同级别的经理的权限是不同的，比如休一天假，只要部门经理批即可；休三天假就要区域总经理批。
每一项业务的权限也是不同的，比如休假是天数，借款是金额等等。
流程处理角色和申请人所在的部门相关
每一项业务都需要一个角色进行处理，但承担角色的人是和申请人所处的部门相关的；比如北京的休假申由华北的人事休假管理员负责，而上海和广州的休假申请都由华东的人事休假管理员处理。
问题的分解
分层是解决问题的一个方法，它降低了系统的难度，提高了灵活性；同样的，一个复杂的流程看起来很难，但如果把它分解为上文提到的三个层，就相对容易一些了。
首先一定要分离页面逻辑和流程逻辑
客户的流程复杂在交互逻辑和流程逻辑都很复杂，按照很多人的做法是把它混在一起处理；我们的建议是一定要分清楚，流程的部分都放到流程中，交互的部分放到界面中。所以在上面的描述中，我们已经忽略了很多的交互逻辑，否则内容会多得多。
其次要充分利用WF的功能
对粗粒度的模式来说，每个业务功能可能都需要一个组件完成；所以我们经常听到有人问，你们的工作流有没有实现什么什么功能？对于WF这种细粒度的模式来说，他的每一个功能都是很多组件共同完成的，所以他几乎可以实现所有的流程功能，关键是你能不能设计出来。我们以前总结过六种通用的会签模式，用WF的流程设计器都可以非常方便的实现。
通用的部分抽取到平台
流程的大部分功能WF已经替我们实现了，剩下的要么在平台中实现，要么在特定流程中实现，如何确定呢？我们的原则有两个：
一、只要两个流程都用到的部分就放到平台实现，否则只在需要的流程中实现；
二、具体业务相关的部分放到特定流程实现，因为平台不应该知道任何特定业务的信息。
用WF的思想来设计逻辑图
前面提到要充分利用WF的功能，WF因其细粒度流程设计模式，可以实现强大的功能，并具有很高的灵活性，但同时学习难度也稍高。
逻辑图是流程的关键，清晰明确的逻辑图是流程实现的基础，可很多有多年工作流经验的设计人员画出来的逻辑图还是让人摸不着头脑；在我看来有两方面的原因，
一是客户怎么说就怎么画，但有时客户并不具备逻辑图设计能力；其实画逻辑图是一个设计的过程，是把你将来的可能的实现方法，用客户可以理解的方式展现出来；而且客户由于经验所限，需求经常是矛盾的，必须在画逻辑图的过程中发现并纠正，不能拖到开发期才发现。
二是和经验有关；现有的大多数流程开发方式都是粗粒度的，很多流程逻辑被封装在了代码之中，在流程图上也就无法展现这些流程逻辑了，缺少了细节，流程图也就难以理解了。
一个好的逻辑图应该是WF流程图的抽象，开发人员根据逻辑图就可以进行WF流程的设计；用户又很容易理解流程真实的运行模式。
这是我们示例的一个部门逐级审批的逻辑图和WF流程图，实际的还有更多的内容，但这两个图的流程逻辑是一样的，用户也很容易理解。
我们一般在需求报告采用职能图，系统设计采用逻辑图，代码就是WF流程图了。
下面是两个真实的逻辑图和WF流程图，节点多但不是太复杂，因为所有的流程逻辑都在状态机上，所以两个图非常接近。
第一个项目完成以后，立即就应用到第二个项目，不需要做重构就满足了第二个项目的绝大多数需求，剩下的需求只是在某些节点增加了一些功能。
这个项目是一个国营的测绘院的办公和生产流程，他们的生产流程就是从签合同、下任务书、测量、绘图、质监到归档，生产的产品就是测绘图。和上面的项目的区别是组织结构简单，但角色复杂，每一个流程都有很多的角色同时参与，几乎涉及到全部的六种会签模式。
经过两个项目的完善以后，其他的项目在应用工作流平台的时候就几乎都能够满足要求了，没有再进行太大的修改。
我是敏捷的推崇者，我们的实践也基本遵从敏捷，我觉得敏捷的宗旨是诚实和真实。
当我们第一个项目的时候，因为技术是新的，有很多技术难点需要研究克服；平台也只有架构，还有许多设计需要完善，只能一边摸索一边前进，没有写文档的时间，也写不出来，这时候任何不成熟的设计，和墨守陈规都是前进的阻力。
后来的项目中，因为已是成熟的东西，所以都是先详细设计，然后严格按照设计进行开发。
所以我的建议是当你设计和文档的时候，一定要对内容有信心，否则宁可不写；当你采用新技术的时候，要尽量避开阻止你前进的东西。
