项目开发经验谈

UML软件工程组织

项目开发经验谈

2008-09-10 来源：网络

一、项目过程

根据我们项目出现的问题，我自己的总结的一些经验以及我在培训中学习得知识总结下项目中遇到的问题和解决方案。

1.1　签订合同

我们项目的合同内主要写的很模糊，范围可大可小，致使我们在后期的工作中项目越做越大，但是项目费用是不变的。在国内的合同好像都是在打单时是基本上都承诺，也不会到细节，在合同签订后启动后才发现问题。但合同中可以写明如果需求变更什么级别的怎么样，多少钱等;签订合同也是一个很高的技巧，建议把系统的边界及功能范围和解决方案与合同一起签署，这样客户提出的新功能就可以暂且搁置。

1.2　团队建设

在立项后尽早确定该项目的负责人及项目经理，这个人员非常关键，需要很强的综合能力，尤其的人格魅力方面。尽最大的努力将客户的人员加入到我们的项目团队来，这个人也是我们将来和客户的统一联系人，客户指定一个人和项目组进行沟通，不能是张领导、王领导都来说几句，如果他们意见不一致，那你只有得罪领导的选择了，所以，项目的最初就要定好规矩，项目组只认一个的意见，有什么要求你们内部先统一再和项目组谈，我们不想卷入客户内部业务部门之间的矛盾和政治斗争之中。很多项目经理都没有自己选择组员的权利，那么，就尽量发挥你的影响力去寻找那些你想要的人吧。成员的组成根据项目不同，相差较大，很难有什么具体要求，但是，一定要有精通客户业务的人，很多小项目里，这个人就是项目经理本人，大项目里会配备行业专家（Industry expert），这样和客户沟通起来才不会鸡同鸭讲，双方才可以相互理解。项目经理需要了解每个组员的情况，用就要用每个员工的特长。软件行业是个非常特殊的行业，从项目的管理以及人员的管理都有它的特殊性。

作为项目经理，其实脑子里就是几样东西：做哪些事情、做到什么程度、怎么交货、手上的资源以及各个事情的优先级。所谓多快好省那是人类的梦想，这四个方面都是相互矛盾的，属于典型的又要马儿跑，又要马儿不吃草的类型。考虑问题的轻重缓急方面，往往是把快放在第一位，各方领导都会给你最后期限，所以保进度是第一位的；省是第二位的，企业的根本目的是盈利，如果收入不能增加的话，至少费用要控制住；好是第三位的，没办法，谁都想精益求精，但是，没有强大的资源保障，质量只好先牺牲了；最后是多，客户的要求源源不断，如何降低客户的期望值，让他们从理想回到现实也是项目经理的分内工作。

1.3　需求调研

在需求调研分析阶段，项目组对客户的整体组织结构、有关人员及其关系、工作职责等没有足够了解以致于无法得到完整需求或最终经权威用户代表确认的需求。由于项目经理和需求分析员的工作问题以及调研工作做的不够细，客户参与程度都不高，客户方相关责任人不明确或对范围和需求责任心不强，提出的需求具有随意性，项目前期对需求的确认不够积极；多个用户代表各说各话、昨是今非但同时又希望软件尽早交付；我们的做法主要注重领导的需求，基本上都是领导说什么就是什么，致使开发出来的功能在实际使用中不是真正的使用人所需要的，项目后期需求变化随意，造成项目范围的蔓延，进度的拖延，成本的扩大。同时在我们的认识中是需求调研很关键，很多公司只是概念上认为该阶段重要，需要投入的时间长，但是实际上很多公司做不到这个，总想很快进入编码阶段。而且为了赶进度总想省做某些工作，少写某些文档，使我们无法拿出客户需求以及后来功能变化和原先功能之间的对比度。

造成上述现象的原因是我们没有全面了解所有项目干系人的需求以及对需求调研的重视程度不够。软件开发是没有捷径可以走的，省掉的工作后面会有更高的代价回报。全面的需求来自所有项目干系人，不同的干系人其愿望和追求的目标往往相差甚远，因此对项目干系人的愿望进行平衡可能是相当困难的事情。

软件开发项目的目的就是实现项目干系人的需求和愿望。如果对项目所有干系人没有进行足够的沟通和影响，使其尽可能地参与项目，则可能因为项目开始时项目范围和一些具体需求不够完整清晰，也可能因为某个项目干系人后期因为认识的变化而提出新的需求，造成工期的延长，成本的增加，甚至项目的完全失败。因此，应当从项目的启动开始，需求分析员及其项目成员就要分清项目干系人包含哪些人和组织，通过沟通协调对他们施加影响，驱动他们对项目的支持，调查并明确他们的需求和愿望，减小其对项目的阻力，以确保项目获得成功。以下是一些有效的措施

1、尽快熟悉项目干系人全貌

有些项目在做需求调查时，由于受进度要求等客观因素影响，需求分析员与建设单位的技术部门交流较多，向业务管理部门和实际使用者调查不够深入，造成软件试用后不得不再对需求做较大调整，"从头再来"的部分比例很高，大大超过进度要求时间。因此，熟悉项目干系人全貌是进行需求调查的第一步，也是需求调查的基础。在定制开发项目的项目干系人中，最重要的是建设单位中的人事组织、业务关系。最好是能够用组织结构图画出相关单位的组织结构；建立调研对象通讯录以保证调研及分析期间及时的沟通。与此同时要注意项目干系人的主次关系，以便在他们之间的需求出现矛盾时能够进行合理的取舍。

熟悉建设单位内部相关部门的业务划分及它们之间的相互关系,为功能分析准备了必要的资料, 同时可以熟悉用户方的各类人员，并及时进行广泛、有效的沟通与交流。特别要与客户方业务与技术的规划者和实际使用者进行深入探讨，收集必要的原始资料，保证需求调查的完整性、正确性。

建设单位只是项目干系人中的一部分（当然是主要的部分），为了更好地了解项目干系人全貌，还应当在建设单位组织结构图基础上全体项目干系人结构图，以便更好更全面地进行需求调研分析。

2、详细描述各项业务，以利于让所有客户确认

尽可能全面详细地调查并且描述原有系统（这点非常关键，需要调查清楚原有系统的不足以及优点，以及用户在这些系统中的操作习惯）和用户希望将来系统具有的各项业务的流程，并将这些业务流程文档化后与客户进行讨论，对描述错误或不准确不精确的进行修改，最终让客户进行确认。从个人认为，对业务处理过程了解的完整性和准确性非常重要。虽然对数据来说都是查增删改传，但具体业务都是分为若干步骤，每个步骤都有其业务名称，同一步骤可能对多个数据集进行不同操作，需要调查了解清楚才能设计出适合各流程业务节点用户业务特点和习惯的软件，使开发出来的软件更受欢迎。当然在进行软件概要设计时，要尽量排除业务流程的制约，即把流程中的各项业务结点工作作为独立的对象，充分考虑他们与其他各种业务对象的接口，在流程之间通过业务对象的相互调用实现其业务流程，这样，在业务流程发生有限的变化时，就能够比较方便地修改系统程序而实现新的需求。

对于各项业务的调查可以通过对以下资料的收集整理分析，这些资料来自各种各样的项目干系人：遵循的标准、组织发放的工作手册、作业流程、有关业务的上级通知、有关业务的办事指南、办理业务时需要填写的登记表、各种相关的统计报表及通过其他途径收集的类似系统的介绍、技术资料等等。

3、可视化需求调研，引导各种客户挖掘他们的需求

很多客户因为自己缺乏计算机知识，无法提出完整准确、隐含的或潜在的需求。但若这些需求不能满足将导致用户的不满。因此需求调研分析人员应善于想用户所想，不要害怕用户的需求多，不但要确定明确的需求，还要善于用启发的方式与用户探讨隐含的或潜在的需求，并结合各种调研分析技术挖掘超出客户期望的令人兴奋的需求。这就要求需求调研分析员要尽快完整地熟悉相关业务，从而能够站在用户的立场看待软件需求，想用户所想，做好业务与计算机之间的桥梁。利用可视化需求调研的方法可以很好地启发用户深入挖掘潜在的需求。可视化需求调研就是使用图表等工具来启发引导用户清楚地叙述需求，并且使需求更加全面完善。

对于高层领导，可以提供系统总体框架图；对于业务管理人员，可以用业务流程图来描述新旧系统的业务流程；对于客户中的技术人员，可以用数据流图、实体关系图或UML中的各种图形对系统进行各种角度的描述；而对于业务管理人员、客户中的技术人员、以及各层次各流程中的用户，画出用户界面图来进行需求挖掘，是个比较有效的沟通方式。

这里特别说明一下用户界面的重要性。用户界面的设计按理来说是软件设计的责任，当然客户自己对界面有特别提出要求的除外。但是，如果把它提前到需求调研时（紧接着原有系统调研分析和系统模型完成之后）与客户进行讨论，则可以大大改善需求调研的效果。因为这时客户对于将来的系统还没有一个形象上的概念，或者有一个模糊的预想的概念需要表述、验证、明晰化、完善化。从我们后来的项目先做界面和用户交流的经验看（系统原形应该在需求分析的时候开发人员在分析师的指导下完成真实环境中的开发，当然开发只是界面的功能模拟，没有底层代码的实现），画出用户界面草图与客户进行讨论，可以大大激发他们提供更为准确全面的需求，而且这些界面在后期的开发中也可以利用。原来收集资料，描述业务，说明系统模型到了山穷水尽的时候，这种方法可以达到柳暗花明又一村的效果。因此，所谓需求就是“当你按下各种相关按钮（或输入各种相关命令）时系统做什么”，所谓设计就是“当你按下各种相关按钮（或输入各种相关命令）时系统怎么做”。需求的最终目的实际上是完整准确地描述系统需要的各种接口或“界面”，及它们的相互关系或与外部环境的关系，如界面中的某个按钮按下去时，可能产生新的界面、新的按钮、或者调用其他软件硬件完成某些功能。自顶向下，把这些界面及涉及到的数据描述清楚，就是一份不错的需求。

4、与其他项目小组成员共同协作、持续完善系统需求

需求文档完成之后，并不是万事大吉，把它扔给后面的设计人员就了事了。作为项目干系人之内的项目组其他成员，对需求的有效性也起到某种程度的验证作用。虽然软件项目的生命周期按照各种开发模型有不同阶段的划分，但每个阶段的结束不是简单地把阶段工作成果塞给下一阶段的成员就可以了。特别是高科技的软件开发项目，上一阶段的工作成果往往要通过多次的沟通才能更为清晰地被下一阶段成员接受，其有效性、合理性也要被下一阶段的工作所检验，通过检验有时也有必要对上一阶段的工作结果进行相应的调整，需求更是如此。因此，无论是同一阶段不同人员之间，或是不同阶段人员之间都应根据需要相互协作，相互配合，共同完成软件开发任务

5、《功能规格说明书》，这个是我们项目中最大的失误，致使后来客户的改动让我们很被动。《功能规格说明书》反映了客户提出的所有需求功能，我们也是按照《功能规格说明书》来开发的。后期客户的变化都可以和《功能规格说明书》对比，具体怎么变更按照我们的变更流程来做。《功能规格说明书》作为产品需求的最终成果必须具有综合性：必须包括所有的需求。开发者和客户不能作任何假设。如果任何所期望的功能或非功能需求未写入软件需求规格说明那么它将不能作为协议的一部分并且不能在产品中出现。并且注意以下几点：

(1)完整性

每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。不能遗漏任何必要的需求信息。遗漏需求将很难查出。注重用户的任务而不是系统的功能将有助于你避免不完整性。如果知道缺少某项信息，用“待确定” 作为标准标识来标明这项缺漏。在开始开发之前，必须解决需求中所有的“待确定”项。

(2)正确性

每一项需求都必须准确地陈述其要开发的功能。做出正确判断的参考是需求的来源，如用户或高层的系统需求规格说明。若软件需求与对应的系统需求相抵触则是不正确的。只有用户代表才能确定用户需求的正确性，这就是一定要有用户的积极参与的原因。没有用户参与的需求评审将导致此类说法：“那些毫无意义，这些才很可能是他们所要想的。”其实这完全是评审者凭空猜测。

(3)可行性

每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。为避免不可行的需求，最好在获取需求(收集需求)过程中始终有一位软件工程小组的组员与需求分析人员或考虑市场的人员在一起工作，由他负责检查技术可行性。

(4)要性

每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。“必要性”也可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如使用实例或别的来源。

(5)划分优先级

给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。如果把所有的需求都看作同样重要，那么项目管理者在开发或节省预算或调度中就丧失控制。

(6)无二义性

对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。避免二义性的有效方法包括对需求文档的正规审查，编写测试用例，开发原型以及设计特定的方案脚本。

(7)可验证性

检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确定产品是否确实按需求实现了。如果需求不可验证，则确定其实施是否正确就成为主观臆断，而非客观分析了。一份前后矛盾，不可行或有二义性的需求也是不可验证的。

(8)一致性

一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。在开发前必须解决所有需求间的不一致部分。只有进行一番调查研究，才能知道某一项需求是否确实正确。

(9)可修改性

在必要时或为维护每一需求变更历史记录时，应该修订文档。这就要求每项需求要独立标出，并与别的需求区别开来，从而无二义性。每项需求只应在文档中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明更容易修改。

(10)可跟踪性

应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好的方式编写并单独标明，而不是大段大段的叙述。

6、需求变化

项目的需要变化是肯定有的，而且变化一般都很频繁，我们怎么应对客户的这种需求变化呢，以不变应万变。首先在前期的需求调研要做好，尽可能的替用户考虑，达到功能质量满足最大化。需求调研前期的《目标与范围》和需求调研末期的《功能规格说明书》都要跟客户签字确认，这样既能保证我们所理解的需求就是客户所要的，也使得项目末期跟客户验收时有据可依。在项目中期是发生需求变更是很常见的，这时要做好需求变更管理流程。需求变更表，小的变更自己掌握，客户要求的变更有开发人员和设计人员共同商讨后提交项目经理，项目经理预估变更损耗工程时间，在一定阶段一起提交给客户，大的变更直接提交客户，并且要把需求变更对项目产生的影响让客户知道，把球尽可能的踢给客户，让客户在进度、功能、资源三者中取舍出一个平衡来。对需求进行分类评级，关键部分不能改动的做特别确认（如系统架构等，如果改变等于从头再来）。同时完成客户签字确认，当然如果能将这部分写成合同细节中去是最好。以下是我认为变更的步骤：

第一步：客户提出变更内容

客户提交的变更必须基于书面形式
客户提交的变更必须有充分理由
如果变更被拒绝，对业务的负面影响
如果变更被接受，对业务的正面帮助

第二步：为能否实现变更作评估

从实现方式上考虑新的变更可否实现
对于较复杂的情形，辅以简单的说明。欲详述，可作附件处理
对于简单情形，例如页面布局更改，则无须说明

第三步：可以实现看进度

进度几乎是绝大部分项目关注的第一要素
对于活动级别的进度影响
对于项目整体工期的影响

第四步：变更成本

人力相关的变更成本
- 是否需要额外的项目组成员
- 项目组需要增加的工时数

是否正常工时（工作日加班、节假日加班）

项目工数报价

非人力成本

软硬件费用
资料费用等

第五步：质量和风险

变更对质量的多方面影响

分阶段影响（需求、设计、编码、测试、维护）
可靠性、安全性、可维护性、可用性等

可能对团队士气的负面影响

可能引发的间接任务对工期的负面冲击
开发方的成本负担可能超出力所能及的范围

第六步：需求变化的确定

6.2 架构设计

撰写详细设计是一个逐步细化、深入的过程。没有人能一次就设计出完美的东西，需要及时的沟通，包括与客户的反馈，与其他项目组成员的讨论，这样有助于降低开发时偏离需求的风险。也就是说，在开发之前题，是建立在设计者的想法有客户的确认和开发人员的理解的基础之上设计撰写人必须与系统分析员反复讨论，以透彻理解用户需求；

一项需求可能有多种方式实现，设计者必须与系统分析员确定该需求将采用何种方式实现，将达到何种效果，以消除将需求映射为设计的歧义；讨论过程中还可能会发现需求有不完备甚至错误的地方，在需求重新确定后设计者需修正设计。设计文档必须写清楚各个模块/接口/公共对象的定义，列明程序的各种执行条件与期望的运行效果，还要正确处理各种可能的异常。此外设计文档应该遵循一定的写作模式与版面风格，使用统一的术语或惯用语，使得小组成员很容易理解。以上这些活动综合起来将是一个很细致、很耗时的工作过程。就个人所知，一些公司的详细设计通常是由程序主管或少数核心的程序员撰写的，他们通常也是系统架构的主要作者或维护者。因为他们在开发团队中技术最为精湛，对架构最为熟悉，他们最有资格评价现有架构是否能适应新的用户需求，采用何种方式实现需求对架构的冲击最小。但是由少数人来负责所有的详细设计可能造成开发过程中的瓶颈甚至是设计的错误。当任务比较集中的时候，设计者可能忙得透不过气，而负责实现的同事反而在等米下锅，比较清闲。于是为了让自己不成为拖累进度的“罪人”，某些设计者就会采用一种快捷方式来交付设计：他们会与系统分析员进行初步的讨论，然后撰写一份粗糙的但仍然叫做详细设计的文档，把它交付给负责实现的同事，再通过讨论、即时通工具、电子邮件等方式解答对方提出的疑问。但由于详细设计本身不完备，他们不得不花费更多的时间和精力与负责实现的同事沟通；而且他们却很可能忘了把这些交流的成果更新到详细设计中去！（或许是他们太忙，没有足够的时间，又或许是他们认为既然产品已经实现，那么详细设计也就不必维护了。）其结果很可能是当产品开发出来后，我们才发现它跟用户要求的完全两样！原本在详细设计阶段就应该发现的需求漏洞与在那时应该确定的技术方案在实现阶段甚至测试阶段才暴露出来，而这时大家往往有木已成舟的感觉，改动的难度比设计阶段高数倍甚至十倍以上，毕竟任何再牛的人都有自己的局限。

对于以上问题我提出全员设计，全员设计的含义就是把详细设计的工作进行适当地分解，把它们分摊到小组内其它同事身上，让大家都参与设计。这可以说明如下：

当一组用户需求基本确定下来后，程序主管需要估计需求的相关性、需求的优先级、设计的难易程度、设计的工作量等，将该组需求分解为一或多项设计任务，并指定给适当的同事。参与设计的每个人必须负责至少一项设计的撰写任务。设计者从系统分析员处获得详细的用户需求，并与系统分析员反复沟通以透彻理解用户需求。他还要分析系统架构及产品的已实现与/或已规划部分，理解架构的设计理念，理解产品不同模块之间的协作关系，理解架构与产品之间的约束和依赖。当然对系统架构和产品的分析不可能穷尽每一个细节，只要分析与即将开发的模块相关的内容即可。

一项设计任务，它可能需要多个程序员完成。比如用户界面或网页由某位或某组同事负责，而业务逻辑组件则由另一位或另一组负责，数据库部分则又由其它同事负责。设计者必须考虑他们的立场，以各方面都相对容易理解的方式写清楚主要的模块/接口/对象定义，明确相应的调用规则与主要逻辑处理。如果某项设计任务所涉及的内容太专业化，设计者并不熟悉相关的内容（比如某位C#程序员并不熟悉如何编写一个存储过程），他可以用描述性的文字说明该部分的设计要求，并知会相关的同事补充。其它同事在补充时可以对这些描述性的文字重新整理，以更加确切地表达设计内容，更符合文档的书写惯例。在设计文档完成后，设计者必须把他提交给程序主管或由程序主管指定的程序员审阅。个人推荐由其它程序员而不仅仅是程序主管来审阅。不用担心等待多个人的审阅意见是否可能导致一份设计滞留很久。大家可以并行地工作，不必是A审阅后才能B审阅。可以交叉审阅，即A的设计由B、C审阅，B的设计由A、C审阅等。审阅意见可以用多种方式（如讨论、即时通工具、电子邮件）反馈给设计者，设计者负责汇总这些意见并修正设计。以个人的经验而言，通常设计交付审阅后半天内就可以收到反馈意见了。设计经过反复地修正直至没有人再提出修正意见，这时就可以由程序员实现了。以个人的经验而言，一份设计通常两、三轮反馈后就可以定稿了。如果多次反馈后仍不能定稿，极有可能是：

a)需求尚未明确，各个方面（包括客户、系统分析员或设计者）对需求的看法不统一
　b)技术或系统架构存在严重的限制，无法用较方便的方式实现

全员参与设计好处、风险与不适用的团队如下：

6.2.1 全员设计可以带来以下明显的好处

1.有助于平衡工作量，加快开发进度。详细设计的任务分解后，程序主管或核心程序员可以有更多的时间处理其它的事务，比如关注软件的开发质量或改善系统架构。详细设计的撰写任务分解后它们可以并行地撰写，这将极大地提高设计撰写的进度，节约时间。

2.有助于培养程序员的大局观。每位撰写设计的程序员不再仅仅只关心自己负责实现的模块，他必须从更高的层次考虑和理解设计。

3.有助于加强同事之间的交流与协作。设计者需要与系统分析员、其它程序员、审阅者进行反复的交流和沟通，实际上每份设计都是多人协作的成果。更多的沟通有助于集思广益，有助于避免一、两个人的倾向性意见导致错误的设计。每位设计者都需要对自己撰写的设计负责，他还要向其它同事的设计提供审阅意见或技术建议，彼此的工作是互相支持和依赖的，这有助于减少“只扫自家门前雪，不管他人瓦上霜”的想法。

6.2.2 推行全员设计的潜在风险

1.在某种意义上，全员设计可能增加交流的成本。两个人之间有一条交流途径，三个人之间最多有三条，四个人之间最多有六条。途径越多，信息量就越大，而这些信息不见得都是有用的信息。详细设计的任务分解后，不可避免地有更多的人参与交流和沟通，大家要花更多的时间来理解他人的想法，也可能要花更多的时间向他人阐述自己的观点。特别是在并行撰写详细设计的过程中，系统分析员反而可能成为另一个瓶颈了。但从总体上来看，在设计阶段花费适当的代价发现更多的问题，比在实现阶段或测试阶段再发现问题，仍然是划算的。

2.分解后的详细设计可能引入冲突的设计内容。由于设计由不同的程序员撰写，他们考虑问题的角度和思维的方式不可能完全一致，这增大了不同的设计内容之间的计算口径或交互方式不一致的可能性。这需要设计者们尽可能遵循一致的设计原则，也需要审阅者们尽可能找到这些不一致的地方。

3.并不是所有的程序员都适合参与设计。很明显，例如刚入职的同事就不适合参与设计，他们对系统架构还缺乏足够的认识。另外兼职的同事也不适合参与设计，他们的工作方式可能无法保证及时提交设计文档与参与讨论等。

6.3 沟通

在项目的开发过程中，在团队中的成员之间以及和客户之间是一个不断的交流和沟通的过程。我们的开发过程最好是一个迭代式的开发过程（尤其是国内的项目）。这样我们可以尽早发现开发出来的功能是不是符合客户的需求，以免开发完了，客户说这个不是我们需要的后果。

6.4 计划执行控制

制定系统得整个计划，任务的划分以及分配工作，跟踪任务的进度，使我们的项目进度在控制范围之内。

6.5 风险管理

风险是随着项目的不同阶段变化的，不同的阶段风险是不同的，我们必须分析我们当前面临的风险的数量、影响程度等，以及怎么去解决这些风险。

6.6 测试

测试工作目前在国内的中小公司做的都不太好，但是从我们做项目或者产品必须重视测试工作，把握好质量关。

6.7 验收为目的的思想

在开发过程中，内部管理还要注意的一点是时刻强调以验收为目的的思想，每个任务的最终可交付成果一定要是可以被检查的，比如，【界面要求：美观大方、简洁明快】，这个要求我就不知道如何检查。所以，给开发小组布置任务的时候就要考虑如何检查结果，比如我见过一个计划，里面有一个任务【开发人员熟悉EJB编程】，这个任务，除了让这些人去参加一些专业认证考试，否则，结果很难被检查。所以，时刻考虑如何检查结果、如何向客户交付是项目经理一直要注意的事情，我听说有些老项目经理拿到项目是倒排计划的，即首先看如何验收和验收标准，然后决定工作计划。很多项目开始了很久，还不知道如何验收，那么这个项目出问题的可能性就很大了。做项目就是为了验收，我们的角色不是研究机构，我们的目的就是在付出那么多劳动后得到结果。