我们为什么选择工作流。
一直感觉很难对那些从未接触过工作流的同学们解释清楚。
还记得有一个活动中，有人提问：“工作流到底是做什么的？”回答的同志希望根据具体的实例解释一下，就反问他：“你们公司的报销流程是怎么走的？”结果提问的同志直接说：“直接找财务啊。”引得下面一阵喧哗：“不用领导签字就可以随便报销啊。”
那个提供的同志心里一定感觉很无辜：“我也不知道公司的请假流程应该找谁啊，大家每次都直接给财务了。”其实对于小公司来说，里边工作的人本来不多，可能都是报销这种事情都是这样两步完成了，可实际上真实的流程应该是这样：
大家对图中的环节估计不会有什么异议，只是对于直接拿发票找财务报销的人来说，中间的核实部分变成了完美的黑盒，他不了解，也没有必要去了解报销的整个过程，站在当事人的角度，他只要最后知道这次报销能拿到多少钱就可以了。
对
于一个公司的内部事务来说，这样就最好的，员工没有必要去了解每个环节是如何进行的，但是在为这种公司进行软件开发时无疑要面临着掉进陷阱的危险。假设你
只对员工进行需求调研，他会只给你发票的单据，告诉你报销流程就是找财务。如果再去找财务进行需求调研，他会告诉你只要看一下没问题就可以报销了，最有可
能略过，也可能是最关键的特别情况需要经过老板审核的步骤，这个步骤可能是5000元以上必须经老板过目，也可能是特殊事项需要老板签字，但是因为公司日
常不会出现很多这种情况而被人们无意识的忽略掉，有可能到程序开发到中段时才突然想起来，然后就需要把流程重改。
说到这里，那么使用了工作流就可以避免出现这类需求变更问题吗？
答
案是否定的，软件开发时的需求变更常常是因为客户对本身业务要求和业务流程的不熟悉所导致的，软件开发的过程常常伴随着流程的梳理和细化，这也是为什么很
多程序员都说：“这个项目做完了，我比他们公司里的人都懂业务了。”其实不是你比他们还懂业务，真正办公的时候你还是会被各种情况冲的头昏脑胀，但是因为
你在软件开发的过程中对各个部门之间的依赖和关联进行了完全的梳理，所以对各个部门之间的数据流和业务流了解的更为通透。
话
说回来，工作流虽然不能解决因为客户对本身业务的深化而造成的需求变更问题，但是它确实可以把这个风险提前，我们知道，风险总是越早解决越有利，因为当我
们一张张单据化为流程图时，客户也能够更好的参与到流程的解读中来，通过流程图可以加快业务的深化，提早暴露出之前没有考虑到的问题，便于我们尽快的尽早
的解决。
那么我们直接用visio不就可以了？何必使用工作流呢？
答案是
visio也可以，只要可以限制图形中的语义，不要让客户任意发挥，就完全可以实现工作流的效果。为什么要限制语义呢？因为只有流程图可以直接映射为开发
完成的程序，对流程图的细化才是真正有意义的，否则客户画了一张完全无法用程序实现的图形，我们该怎么办呢？工作流一般都提供了自己定义的一套语义，大多
都是以XML格式保存的，只要以此为基础画出的流程图都是可以转换为实际程序的，再加上与客户的沟通，让客户和程序员对流程中每个环节的理解保持一致，就
可以尽量避免理解上的偏差，减少修改和返工现象。
但是工作流的学习曲线太高了，原本程序中我只需要设置几个状态位就可以解决问题，值得兴师动众的配上工作流吗？
对
这个问题的回答还需要对实际情况进行分析，小型系统中，你只需要制作一个CMS，不同的管理员负责不同版块内容的审批，这种逻辑简单，流程固定的需求确实
没有必要使用工作流，使用了工作流反而会加大开发和维护的复杂度，使用状态位模拟FSM有限状态机也完全可以实现。但是在复杂的业务情况中可能存在着同步
并行，多路决策，循环遍历等情况，这种情况下使用状态位就无法满足客户的业务需求，因此随着业务需求复杂度的上升，我们必然需要选择功能更强大的武器来解
决这一系列的问题。