这并不是一次正式的评估，而是一种访谈性的非正式评估(当时称之为交流)。事情的来由是这样的，公司有一个项目组承接了国家的863项目开发一个工作流产品，部门的领导对这个东西有较高的期望，但并没有提供与这种期望相应的支持。项目的结果并不太理想，因此部门领导对这个项目组非常不满，另一方面开发小组经常加班，成员因为得不到认可，士气低落。我当时并不在这个项目组中，但我觉得这个项目的不成功（从领导的期望来说）是有很多不属于项目组的原因，作为公司的一名资深的技术人员，我希望能够做一次简单的评估，以帮助领导能够清楚地了解项目的现状、形成的原因，好的和不好的地方，能够公平的看待项目组的努力（希望如此）。但最后这份报告并没有提交，开发室的主管有一些担心，而我也尊重他的意见，只在小组成员中进行了交流。
本文的主题涉及到公司进行863项目的一些内容，希望不会成为人们抨击公司和863项目本身的工具，我的目的是提供一些关于失败的教训或值得借鉴的经验。
原文序：2月11号下午，工作流项目组成员、部门主管XXX和我进行了一次比较长的关于工作流项目情况的总结性交流，以下是我通过交流对项目的一些认识和看法，从项目的最终结果的状态、项目的目标、项目开发过程中的好的和需要改进的地方等多个方面进行了分析。
项目背景
项目来源于公司申报的国家863项目。工作流项目于2002年4月启动，12月份基本结束，但还未通过国家验收。
项目成果状态
项目并未进行同类商业化产品的比较，主要目的是通过国家的验收，因此产品仅停留于技术原型状态。项目组选取了一些典型的应用案例，并基于原来在群件系统上的工作经验和WfMC（工作流管理联盟）的标准制定了需求，开发了可运行的基于J2EE平台的模型，其中包括了工作流引擎、建模工具以及一些示例，具备了应用开发包(SDK)的基本内容。
产品化能力
鉴于时间和本身的原因，我们并没有真正进行产品的技术性测试评估，而是根据项目的一些信息来了解它的成果。相对于市面上可使用的主流服务器(如BEA/IBM)厂商产品和第三方产品以及开放源码产品来说，在实用性、成熟度、同其它技术和环境的整合度（如安全）、开发支持产品（文档、指南等）等方面还有较大的差距，毕竟这些产品的开发时间较长，并具有良好的开发基础。总的说来，离产品化还有很大的差距，有些原因不可忽略：
项目组具有群件平台（办公）协作的工作流方面较深厚的背景，但对业务流程协作相关的工作流仍然缺乏对应用场景的了解，公司的项目也没有类似需求提炼出来，项目组缺乏使用场景的引导，难以产生有效、完善的产品需求。
原来的项目目标是通过国家的863验收，而863验收向来比较形式化，公司也没有明确的在产品的实用化价值上的诱导。
有效的开发时间和人力太少，不可能产生商业化或可实用化的产品。通用化产品必须具有相当的成熟度后才可使用，否则大量的问题会是使用者失去信心，并让项目组陷于铺天盖地的维护工作中。这个问题下面会有描述。
项目的主要问题经过交流发现项目存在以下现象：e3CSPAN class=px14> 高层目标模糊
公司在处理863项目没有自己的立?1，为86s项目而作863项目，没有考虑自己的发展方向，带来的结果是公司的高层领导并不关心以863计划为基础的项目，只有项目部才关心，因为他们需要对验收负责。到公司和部门来说，这些项目大多与公司的业务方向和基础背景不同，这带来了两个不利的方面，一是项目的目标不具有实用性，二是缺乏开发的基础。
工作流项目原来的目标据项目组说上级领导的意见是：
完成863项，培养J2EE人员
因此项目并不来自于自身的需求，而这样模糊的高层目标难以指导项目组完成具有真正可用性和市场化的产品。当然这些并不是在《前景》文档中反映出来的，然而是事实上的指导目标。
缺乏需求和应用场景获取渠道
公司在过去企业应用的开发上虽然有一定的业务协作工作流的应用场景和办公协作应用的开发经验和理论基础，开发时对需求的处理也因无法找到好的需求获取渠道显得效果不是特别好，而且用例我觉得在描述这种需求上还很有局限性，无法体现应用价值和应用场景，应当增加其他的需求描述方式，当然需求渠道和应用场景是最主要的。
项目组制定了计划，但计划经常被打断，并造成计划失效。
责任编辑：虫虫
您现在的位置： 