1、论项目进度管理项目进度管理是信息系统开发项目管理的一个重要内容。有效的进度管理是保证信息系统开发项目如期完成的重要环节。根据你实际参与开发的项目经验论述下列三个问题：（1） 简要叙述你参与开发的信息系统的概要和你所担任的工作（2） 具体叙述你参与开发的信息系统项目是怎样进行进度管理了。在进度管理过程中遇到过哪些问题？为了解决这些问题，你采取了什么措施？（3） 简要叙述上述措施的效果如何？你现在认为还有哪些需要改进的地方？以及如何改进？论软件项目进度管理【摘要】我在 2004 年实施的一个采用集中部署方式的办公自动化项目，该项目发起单位是民生银行总行科技部，项目建设周期为五个月，由四家软件开发商
2、同时开发，SUN 公司做系统总集成商。项目建设内容：内网门户（Portal） 、档案管理系统、电子邮件系统、人力资源管理系统、公文管理系统、辅助办公系统、业务审批系统、内容管理系统（CMS）及利用 CMS 建设的集团内网网站，系统之间通过 WEB SERVICE 实现信息交换。我们交付的产品是公文管理系统、辅助办公系统、内容管理系统（CMS）和民生银行集团内部网站。系统采用工作流技术，实现从分行到总行的跨行公文流转及业务审批，利用电子印章实现文件的签章、防篡改和打印控制。我在此项目中担任系统分析、系统设计、业务流程再造工作。本文以该项目为例，讨论项目进度管理的方法与工具，第一，讨论如何根据项目
3、内容和难度估算工作量；第二，讨论如何识别关键任务及对关键任务的管理；第三，对进度计划的跟踪管理及动态调整，借助功能点方法对模块进行细分；最后，对项目进度管理中遇到的问题、吸取的经验和教训进行总结。【正文】本人与 2004 年参与了某商业银行办公自动化系统建设项目，该项目是一个采用总行集中部署方式的办公自动化系统，项目发起单位是某商业银行总行科技部，项目建设周期为五个月。系统采用 B/S 架构，由四家软件开发商同时开发，甲方做系统集成商。我所在的公司承担公文管理系统、辅助办公系统、业务审批系统、内容管理系统（CMS）及利用 CMS 建设的集团内网网站开发工作。我本人担任需求分析、系统设计及业务流
4、程客户化实施工作。项目建设内容：内网门户（Portal） 、档案管理系统、电子邮件系统、人力资源管理系统、公文管理系统、辅助办公系统、业务审批系统、内容管理系统（CMS）及利用 CMS 建设的集团内网网站，系统之间通过 WEB SERVICE 实现信息交换。我们交付的产品由如下几部分组成：（1） 公文管理子系统：利用工作流产品实现收文、发文、签报、督办，支持跨行审批，利用电子印章实现文件的签章、防篡改和打印控制，支持跨行分发和抄送；（2） 部门业务审批：利用工作流产品开发，实现各业务部门的在线审批，支持跨行审批，有办公室审批、人事审批、科技审批、同业审批、稽核审批、其他审批；（3） 辅助办公子
5、系统：个人事务管理：待办事宜、日程安排、网络文件夹、个人通讯录、 1公司通讯录、电子记事本、个人留言簿公共事务管理：在岗管理、会议室及设施管理、会议管理、车辆 2管理、值班管理、办公用品管理、礼品管理、名片管理、护照管理；党团事务管理：党政工团会费收缴管理、党政工团活动管理； 3综合信息管理：知识库管理、调查问卷管理、软件下载； 4（4） 内容管理系统（CMS ）：网站管理（允许各分支机构建设自己的子网） 、频道管理（各网站建设自己的频道） 、信息内容管理（信息采集、审批、发布，支持主、子网站信息互相转发） 。（5） 民生银行集团内部网站：在技术上，通过控件利用 WORD 对公文内容进行控制，
6、根据角色权限控制只读、可修改、不可见等操作；集成第三方电子印章产品；集成第三方全文检索；除了本公司开发的系统之间实现互相调用之外，还要与人力资源管理系统、门户（PORTAL） 、档案管理系统进行相互调用。1、估算工作量及难度由于此类办公自动化项目是我公司核心业务，已经成功实施多个项目，积累了大量的项目经验，并且客户方总行目前正在使用一套基于 DOMINO的办公自动化系统，需求基本确定，决定采用瀑布模型方式进行设计和开发，对于工作量的估算有专家判断、类比估算、基于定额的历时、历时的三点估算、预留时间、最大活动历时等多种方法。对于有历史经验可参考的需求采用类比估算，即用类似的工作完成时间来估算当前
7、工作的完成时间，对于没有有经验可参考的需求，采用专家判断法，在本项目中，将需求分成如下五类，针对不同的类别采取不同的评估方法：第一类，对公司工作流平台产品功能需求，目前工作流产品无法满足客户提出的功能需求，采用专家判断法评估工作量；第二类，基于工作流产品的应用，如公文管理、审批业务等，采用类比估算法评估工作量；第三类，基于内容管理系统的应用，如知识库、论坛、网站等，采用类比估算法评估工作量；第四类，与上述无关的应用，如车辆管理、办公用品管理、会议室及设施管理、党政工团管理等，采用类比估算法评估工作量；第五类，第三方控件和与其他应用子系统的接口，采用专家判断法评估工作量，聘请公司内做过相关接口开
8、发的人员、合作开发商技术人员、第三方控件提供商技术人员对工作量进行评估。2、关键任务的识别和管理在本项目中，关键任务是：第一，工作流平台产品的升级改造，一旦延误将影响基于工作流开发的相关应用。此外，新工作流产品的易用性也是项目的关键，易用性好可以减少后续开发工作量，反之，会增加工作量，造成项目延期。由于工作流产品的升级改造由产品部直接管理，因此，请产品部经理参与本项目进度计划的制定，特别对工作流产品升级改造部分的工作进度的细分由该产品的负责人亲自制定，并经产品部经理确认。经过与产品部经理协商，产品升级改造项目周报要抄送本项目组，并且也按照功能点方式上报。第二，第三方控件和与其他系统的接口也是关
9、键任务，一旦控制不好，会影响项目进度。由于与电子印章供应商是首次合作，对方希望将该控件集成到我公司WEBWORD 控件中，这样可以随我们的项目捆绑销售，利用这一点，我们在该产品供应商处搭建测试环境，提出技术指标，由对方进行技术预研，然后给我们一套 DEMO，我们再做简单整合即可。与其他开发商的接口部分在项目开发初期先制定好技术规范，约定调用方法、参数传递方式等方面内容，比如以 XML 文件方式传递结果集，在设计完成时各自提交 XML 标准模板，各开发商将标准模板当成参数进行开发，在系统联调时容易判断责任方，避免扯皮现象。第三，网站 UI 设计，由甲方聘请专业的平面广告设计公司统一设计，确保各应
10、用开发商的页面风格统一。值得注意的 UI 设计众口难调，甚至10 个评审专家能得出 11 种意见，经常发生谁也不肯做主决策的拖延现象，一旦 UI 无法确定，将严重影响系统开发。3、对开发工作进行排序对开发工作排序的基本原则为：确定首先开发部分工作流产品进行升级改造、网站 UI 设计、第三方控件开发、与工作流和 UI 设计无关模块；其次对基于工作流的公文管理、业务审批等系统进行开发，最后根据 UI 建设内网网站。按照排序原则，利用微软的 Project 软件做为时间进度管理工具，制定项目开发进度计划，根据项目人力资源情况、工作内容、工作量、约束条件画出甘特图。4、确定里程碑第一个里程碑，需求界定
11、通过确认；第二个里程碑，工作流产品升级改造完成；第三个里程碑，网站 UI 通过用户评审；第四个里程碑，开发完成，系统通过公司内部测试。第五个里程碑，联调结束，系统通过集成测试，上线试运行。最后一个里程碑，试运行结束，项目通过验收。5、了解进度在必要的时候进行调整在项目的进度管理过程中，最难的就是对正在开发过程中的工作进度进行评估，如同 NBA 比赛中最后 5 分钟需要半个小时才能比完一样，看上去剩余 25%的工作，可能需要花费与前面 75%同样的时间完成，最终造成项目延期。因此，在需求界定通过确认后，对开发工作的进度计划进行了一次修正，尝试利用功能点方式对开发工作进行测量，由设计组成员共同制定
12、统一的功能点计算规则，在系统设计完成后，按照统一规则对各模块进行计算，得出功能点数，根据功能点数目及代码的可复用程度对项目开发进度做了一次修订，调整了部分模块的工期。在没有引入功能点之前，对一个， ，模块的利用功能点相当于把模块进行了拆分，并且按照统一标准对拆分后的工作进行了量化，在开发过程中，需要对工作进度进行跟踪，本项目的工作进度计算原则是已开发完的功能点按 100%计算，正在开发中的按 0 计算，这样估算工作进度与以模块为单位的估算法又前进了一步，最有意义的地方就是根据已经完成的功能点数和所需要的时间能推算出尚未完成部分所需要的时间，项目经理可以根据这些信息掌握项目的开发进度，提前做出安
13、排。本项目在建设过程中，由于平面设计公司对于软件 UI 设计经验不足，甲方评审人员意见不统一，最终导致 UI 设计一次次延期，虽然甲方承诺项目后续计划随 UI 顺延，但项目组成员一旦释放，再很难收回，因此，决定调整开发计划，把原开发工作拆成两部分，与 UI 关系不大的部分先开发，另一部分等 UI 确定后再开发。由于用功能点把模块的开发工作进行了拆分和计量，虽然开发顺序做了大幅度调整，但团队成员没有因此停工，工作效率受到有限的影响，单元测试超过预期，总的工时投入超出计划。由于是第一次尝试利用功能点对软件进行测量，虽然对功能点数量估算不够准确，但这些功能点数量能够描述出这些模块之间的相对工作量，能
14、够对开发人员做出科学的绩效评价，并且利用已完成工作的数据推算后续工作任务所需要的时间与实际情况相差不大。6、结束语为使各开发商开发的系统在外观上风格一致，甲方特意聘请专业的平面设计公司设计 UI，并要求所有开发商都要按照统一的 UI 进行开发。本项目没有引入系统集成商，由总行科技部承担系统集成商角色，并指派项目经理负责系统集成工作，甲方项目经理制定了如下项目进度计划，发给开发商进行评估：（1）需求调研 2004 年 11 月 1 日2004 年 11 月 30 日 （2）系统分析及设计 2004 年 12 月 1 日2005 年 1 月 31 日（3）用户界面（UI）设计 2004 年 11
15、月 15 日2005 年 1 月 15 日（4）系统开发 2005 年 2 月 1 日2005 年 3 月 31 日（5）功能确认测试 2005 年 4 月 1 日2005 年 5 月 31 日（6）集成测试 2005 年 6 月 1 日2005 年 6 月 31 日（7）部署实施 2005 年 7 月 1 日2005 年 7 月 31 日（8）上线试运行 2005 年 8 月 1 日2005 年 10 月 30 日如何进行进度管理的？为确保评估的准确性，我们对以往类似项目进行分析，从项目管理部调阅以往办公自动化项目的相关文档，对项目内容和实际完成时间进行分析，以此判断甲方制定的项目整体框架是
16、否可行，根据我们以往的项目信息，得出初步结论，该计划是可行的，我们完全可以按照该计划按时提交，同时提出建议：关键路径上的 UI 设计预留的时间只有 15 天，一旦延期，将导致所有开发工作的延期，甲方对选择的平面设计公司非常信任，其他开发商也无异议，因此，项目整体计划得以确定。在制定我们自己开发计划时，考虑了两个关键点：一个是 UI 的设计，由于不是我们委托平面设计公司，因此在提出设计需求时要尽量详细，在对方案评审时要严格把关，这样才能最大限度保证以往项目代码的可复用程度。另外还要密切关注 UI 设计的进度，一旦出现严重的延误，将影响后续开发。另一个关键点是工作流产品的开发，由于产品升级改造由产
17、品部负责，为确保产品的升级改造能够满足项目需求，产品部派两名开发人员参与需求调研、系统分析及设计，然后参与工作流产品的设计和开发工作，当工作流产品升级改造完成后，进入项目组参与基于工作流模块的开发工作。但有一些关键环节需要重点关注，工作流产品部分功能不能满足项目需求，需要进行升级改造，通过与产品部工作流项目组共同讨论分析，最后认为，工作流的升级改造需要六周时间，其中前四周属于基础功能的改造，产品部已经做好了设计，因此可以在本项目的需求分析及设计阶段进行，针对本项目的特定功能改造，要在系统分析设计完成之后进行，工作量大约为两周。由于对工作流部分功能进行了升级改造，降低了以往项目代码的复用率，需要
18、对开发人员进行培训，以熟悉改造后的工作流产品。我们认为部分辅助办公软件代码的可复用比例比较大，因此，对（4）系统开发、 （5）功能确认测试两项工作进度进行了调整，整体项目框架基础上各缩短一周，共节省出两周时间用于集成测试过程中出现的以外情况。根据客户提供的招标文件要求，我们公司的工作流产品需要进行一定的升级改造才能满足客户需求，因此在做 WBS 时，采取先对产品进行升级改造，后对基于工作流的应用模块进行开发，那些与工作流无关的模块开发，与工作流开发同步进行。考虑到工作流产品升级改造是本项目的关键路径，一旦出现问题将严重影响项目的提交，所以，经过与公司领导和产品部经理多次协商，将工作流产品改造项
19、目组纳入本项目组统一管理，便于协调与沟通。采用项目例会制度，在甲方组织的项目例会上，各开发商在例会上通报自己负责项目的进展情况，其余开发商则提出希望该开发商提供的技术支持和帮助等需求，以确保项目按期完成。在公司内部项目例会上，向产品部经理汇报产品改造进展情况，对超前完成任务的工程师提出表扬，并给与奖励，对于没有按期完成任务的工程师给与惩罚，确保保质保量按期交付。需要对公司工作流产品进行升级，以满足业务需求， 那些独立的辅助办公模块与工作流同步开发在进度管理过程中遇到的问题？但在实际过程中由于用户界面（UI）设计工作延期两个月，直到 3 月 15 日才通过评审，原因如下：（1） 招标后合同谈判过
20、程超过预期。（2） 负责设计 UI 的公司在虽然在平面设计方面比较优秀，但软件 UI 设计经验不足，无法满足基本需求，造成多次返工。（3） 甲方对设计方案存在意见分歧，通过多次讨论修改才达成一致意见，致使评审时间大大超过预期。当甲方发现 UI 无法按期完成，会导致整个项目工期延后，提出各开发商先按照各自产品的 UI 进行开发的建议，等甲方确定 UI 后再按照新 UI进行修改，这样可以减少系统延期程度，并承诺因此产生的工期延误与开发商无关。解决的办法由于年初新开工项目比较少，公司人力资源相对富裕，于是我们就接受了甲方的建议按原计划进行开发。直到 3 月 15 日，模块开发快要结束时，只剩后开发完
21、的几个模块在做单元测试时，才拿到最终通过评审的 UI，于是我们重新调整了开发计划，在系统开发之后和功能确认测试之间增加一个 UI 修改环节，时间为一个月。首先停止正在做单元测试的模块的测试工作，按照新的 UI 进行修改后再进行单元测试。一周过去了，从负责 UI 修改的工程师那里了解到：客户提供的 UI 与已完成模块的 UI 存在较大的差异，在修改过程中多次出现页面混乱情况，最后，几乎对前台页面代码全部重写了一遍。于是根据这几个模块的平均修改效率，再次调整了开发计划，增加了 UI 修改时间，同时将功能确认测试的时间增加了一周。最后，工期比原计划延后 2 个月，开发工作量增加了 10 个人月。存在的问题对于修改 UI 带来的工作量估计过于乐观，导致增加开发工作量，并且降低了系统的稳定性
