❝

今天将分析48个软考案例，这些整理反映了项目管理过程中可能出现的一系列问题，包括但不限于人力资源管理、沟通管理、合同管理、需求管理、范围管理、质量保证、进度控制、变更控制等方面的问题。这些问题的存在可能会导致项目延期、成本超支、质量不达标等风险，因此需要项目团队高度重视并采取相应的措施进行改进和优化。

正文内容：

由于此客户为 A 公司 的重要客户, 为维护客户关系, A 公司 同意了建设单位的要求。为了完成项目建设任务, A 公司 将应用软件分成了多个子系统, 并分别组织开发团队突击开发, 为提高效率, 尽量采用并行的工作方式, 在没有全面完成初步设计的情况下, 有些开发组同时开始详细设计与部分编码工作; 同时新招聘了 6 名应届毕业生加入开发团队。

解答：

人力资源安排不合理。新员工加入到项目，项目经历应保证新员工得到足够的培训。
整体管理不到位。应用软件分成了多个子计划，应该编制各子系统计划。
对风险的认识不足。项目工作并行就会带来风险，应做好风险的应对工作。
沟通管理不到位。不能一味的口头答应建设单位的要求，应根据自己组织的实力。

然后参考 项目管理教材 和国外一些大型项目管理经验制定了一系列相关规定以及奖惩措施, 针对正在开发的项目分别指定了技术骨干作为项目的项目经理。

解答：

计划应该结合本组织的项目特点制定，而不仅仅是参考项目管理教材和国外的一些大型项目管理经验。
人力资源安排不合理。项目经历岗位是管理岗位，对技术的要求不高，技术骨干，对项目管理工作不熟悉，不宜承担此工作。

认为“公司规模小没有必要进行项目管理”, 与其花费了大量时间开会、写文档, 不如几个人碰碰头说说就可以了。实际开发工作中总是以开发任务重等原非不按照规定履行项目管理程序。

解答：

沟通管理不到位。
配置管理不到位，没有对文档清晰的编码和存档。
整体管理不妥当。不管项目的大小，都应针对项目制定项目管理计划。

因此决定从公司工作 3 年以上的业务骨干中选拔一批项目经理。张某原是公司的一名技术骨干, 编程水平很高, 在同事中有一定威信, 因此被选中直接担任了某系统集成项目的项目经理。

解答：

人力资源管理不合理。选拔项目流程不正确，应该通过相应的培训考核合格后上岗。
项目管理岗位是管理岗位，对技术的要求不高，张某是技术骨干，对项目管理工作不熟悉。

他领导的小组有 2 个新招聘的高校毕业生, 技术和经验十分欠缺, 一遇到技术难题, 就请张某进行技术指导。有时张某干脆亲自动手编码来解决问题, 因为教这些新手如何解决问题反而更费时间。由于有些组员是张某之前的老同事, 在他们没能按计划完成工作时, 张某为了维护同事关系, 不好意思当面指出, 只好亲自将他们未做完的工作做完或将不合格的地方修改好。该项目的客户方是某政府行政管理部门, 客户代表是该部门的主任, 和公司老总的关系很好。因此对于客户方提出的各种要求, 张某和组内的技术人员基本全盘接受, 生怕得罪了客户, 进而影响公司老总对自己能力的看法。张某在项目中遇到的各种问题和困惑, 也感觉无处倾诉。项目的进度已经严重滞后, 而客户的新需求不断增加, 各种问题纷至沓来, 张某觉得项目上的各种压力都集中在他一个人身上, 而项目组的其他成员没有一个人能帮上。

解答：

新进的大学毕业生没有得到足够的专业知识培训。
沟通管理不到位。
需求蔓延，没有进行详细的评审和确认。
项目经理和项目成员职责不清晰。
没有确定清晰的变更流程应对客户的新的需求。

王某带领原来的项目团队结合以往经验顺利完成了需求分析、项目范围说明书等前期工作，并通过于审查，得到甲方的确认。由进度紧张，王某又从公司申请调来了 2 个开发人员进入项目团队。项目开始实施后，项目团队原成员和新加入的成员之间经常发生争执，对发生的错误相互推诿。项目团队原成员认为新加入的成员效率低下，延误项目进度；新加入成员则认为项目团队原成员不好相处，不能有效沟通。王某认为这是正常的项目团队磨合过程，没有过多的干预。同时，批评新加入的成员效率低下，认为项目团队原成员更有经验，要求新加入成员要多向原成员虚心请教。项目实施 2 个月之后，王某发现大家汇报的进度言过其实，进度没有达到计划目标。

解答：

沟通管理不到位。
人力资源管理不到位，新老成员没有较好的沟通渠道，未能很好的沟通，与项目经理王某也没有有效地沟通。
冲突管理处理不妥，王某未能秉公对待新老成员之间的冲突，对新成员的批评加剧了新老成员之间的矛盾。
王某未对项目成员进行绩效考核，对项目成员的工作进度与绩效缺乏监控与管理。
王某对项目进度控制的力度不够，未能及时发现进度延误。

小方根据在学校学习的项目管理知识，制定并发布了项目章程。因工期紧，小方仅确定了项目负责人、组织结构、概要的里程碑计划和大致的预算，便组织相关人员开始各个网站的开发工作。

解答：

整体管理不到位，组织结构不清晰。
没有对成本预算进行评审，成本预算不够细致。
项目章程应有项目发起人以外的人发布，而不是小方发布。
制定项目章程仅仅根据学校学习的知识，缺乏实践经验。
应制定完善的里程碑计划，概要的里程碑计划不能有效掌控项目当前状态。

项目经理召开项目组内部会议将任务口头布置给了小组成员。会后, 主要由编码人员按照会议备忘录的要求对已完成的模块编码进行修改, 而未完成的模块按照会议备忘录的要求进行编写。

解答：

变更流程不清晰。变更发生后，没有及时的反映到项目管理计划中。
不能按照回忆备忘录开展工作，应该按照正式的评审通过的计划开展工作。
会议结束应该形成正式的会议记录，而备忘录适合在非正式的环境。
口头布置任务是错误的沟通方式，缺乏有效的证据。

需求分析完成后，项目组编写了《需求分析报告》，项目经理小赵召集部分骨干人员召开评审会。为了尽快进入下一阶段工作，评审会从早上 9 点一直开到晚上 9 点，终于把全部的文件都审完了。评审组找到了几处小问题，并当场进行了修改，项目经理宣布可以进入设计阶段了。设计人员根据需求文件编写了《设计说明书》, 并提交给小赵。小赵对设计文件仔细审阅后, 便安排程序员开始编程。

解答：

需求评审应该项目组全体成员共同参与，体现全员参与的思想。
针对评审后的修改，应通过变更流程进行，而不是自行随便的修改。
缺乏监控措施。对修改的问题，没有对其评审就进入下一阶段工作。
开会时间太长，疲劳工作。会议评审走过场，不仔细。

由于该高校是公司重要的客户, A 公司 领导口头答应了客户的要求。

解答：

沟通管理不到位。
客户的需求应通过书面的方式提交给承建方，有了新的需求必须通过变更控制流程。

李某凭借自己项目管理的经验, 认为这些变更在约定的工期内可以完成, 因此直接答应了对方的变更要求, 随后, 李某找到负责变更模块的项目组成员, 要求其完成对业务流程变更的修改。

解答：

变更流程不清晰，缺少了变更审核、变更实施后跟踪检查流程。
任务分发时，应建立一个书面的任务书，而不是口头形式。

临近外包交工时, 对方提出人力资源紧张, 要求延长合同期限, 如果延长外包期限, 将导致无线抄表系统项目进度无法完成, 公司将承受很大的损失。

解答：

沟通管理不到位。对外包工作监控不力。
风险管理不到位。

小王在初步了解了这个项目的基本情况之后, 就按照公司的模板与项目组的几个核心成员共同制订了项目管理计划。

解答：

仅仅了解了项目的基本情况不妥。应该了解了项目详细情况之后制定计划。
项目管理计划不应该由小王和几个核心成员共同制定，应会同项目组全员共同制定项目管理计划。

考虑到刘某第一次管理这种商业性项目, 因此对很多管理细节都进行了细化, 并将计划重点集中在项目执行计划的制订方面, 配置管理计划做得比较简单。

解答：

人力资源管理不到位，刘某经验缺乏。
配置管理和项目执行计划制定的较为草率，应该指定详细的配置管理计划和项目执行计划，以便指导项目经理开展工作。

项目经理经过与项目组及项目管理部协商, 决定去掉详细设计这个环节, 直接进入产品的编码阶段, 安排开发工程师根据总体设计负责各自模块的开发工作。

解答：

整体管理不到位，详细设计不能省略。
接口应该统一协调，不应该分开。

5 名开发工程师组成的开发小组进入非常忙碌的编码阶段后，经常加班加点，开发过程中，由于原来制定的计划已完全被打乱，SQA 无法再根据原来的质量保证计划进行跟踪，项目组其他人员也已无法发挥作用。

解答：

整体管理计划未经过评审，制定时未根据项目实际的特点。
沟通管理没做好。
风险和成本管理不到位。经常加班加点，增加了风险和成本。

这时已有 2 名开发人员因为信心问题而离职, 项目经理除了要考虑项目进度外, 还要考虑项目资源，由于此时其他项目任务也很重，公司资源很紧张，他不得不重新招聘开发人员。

解答：

沟通管理不到位。
资源分配不合理。没有根据组织自身的实力安排项目工作。
风险管理不到位。缺乏安排核心成员的 A、B 角色的意识。

小赵被任命为某软件开发项目的专职质量管理人员, 他此前只有过三个月的软件开发经历。

解答：

人力资源安排不合理。小赵缺乏相应工作岗位的经验。
质量管理工作岗位是一个特殊的工作，应该由经验丰富的质量管理专职人员担任。

项目经理李工决定调整计划, 不划分测试阶段, 将所有模块一次集成后统一开始测试。

解答：

测试计划调整的不合理。
测试应根据项目的特点制定一个测试周期，周期不能太长，以便及时的发现问题和改进问题。过程控制胜过事后控制。

由于模块由不同人员开发, 需要不同的人来修改, 常常是已修复的 BUG, 在修复其他的 BUG 之后又再次出现, 开发人员不停修改。

解答：

人力资源安排不妥当，项目成员岗位职责模糊不清。
沟通管理不到位。
配置管理不到位，模块编码模糊，不清晰。

质量部便借鉴了其它公司的体系文件, 对其简单修改后形成了 A 公司 的质量管理体系文件。

解答：

质量管理体系计划编制不妥当。不能借鉴别人的公司，应该根据自己公司的实际特点制定。
质量管理工作不妥当。质量管理体系文件应该详细的评审而不是简单的修改。

鉴于项目已经完成了试运行，李工就组织大家召开了项目总结会。在总结会上李工表示了对大家的感谢，然后就宣布项目已经结束，项目团队成员可以各自按照原先的人力资源计划进入新的项目。

解答：

项目收尾管理没做好。项目总结仅以完成了试运行为代表是不妥当的，缺乏项目的正式验收。
项目收尾应有完整的步骤，缺少项目总结环节，不能只召开项目总结会。
缺少项目评估和审计环节。

项目小组在 2009 年 1 月 20 日前完成任务，1 月 21 日至 28 日各模块联调，1 月 29 日至 31 日机动。

解答：

进度计划不合理，计划太紧，没有冗余的思想。没有充分考虑节假日等等因素。
风险管理不到位。

小李随后在原道路监控项目解决方案的基础上组织制定了智能交通管理系统项目的技术方案。

解答：

制定技术方案选取的组织过程资产不合适。应该根据本项目的特点制定一个适合本项目的计划。
编制计划时应该由项目全员参与，而不是由小李一个人制定。

为了赶工期项目组省掉了一些环节和工作，虽然最后通过验收，但却给后续的售后服务带来很大的麻烦：为了解决项目网络出现的问题，售后服务部的技术人员要到现场逐个环节查遍网络，绘出网络的实际连接图才能找到问题的所在。售后服务部感到对系统进行支持有帮助的资料就只有政府网站的网页 HTML 文档及其内嵌代码。

解答：

该项目没有根据要求生成中间交付物，文档不齐。
中间控制环节缺乏缺乏必要的测试和评审。
配置管理有问题。文档编码不清晰。

H 公司同甲方关系比较密切，但也正因为如此，合同签的较为简单，项目执行较为随意。

解答：

合同管理没做好。合同条款中应明确约定进度、质量、成本、违约责任等重要条款。
执行合同较为草率，应严格按照合同约定的事项执行。

小赵是一位优秀的软件设计师，负责过多项系统集成项目的应用开发，现在公司因人手紧张，让他作为项目经理独自管理一个类似的项目。

解答：

人力资源管理不妥当。项目经理岗位是一个管理岗位而不是技术岗位，小赵具有丰富的系统集成项目的应用开发经验，但缺乏项目经理岗位的管理经验。

李工按照 4 个月的工期重新制定了项目计划，向公司申请尽量多增派开发人员，并要求所有的开发人员加班加点工作以便向前赶进度。由于公司有多个项目并行实施，给李工增派的开发人员都是刚招进公司的新人。为节省时间，李工还决定项目组取消每日例会，改为每周例会。同时，李工还允许需求调研和方案设计部分重叠进行，允许需求未经确认即可进行方案设计。

解答：

沟通管理没做好。
项目进度计划制定不切合实际。
在制定项目进度计划时，没有考虑冗余的思想，对风险认识不清晰。
需求必须经过确认后，才能进入下一阶段的工作。

张工在担任此新项目的项目经理同时，所负责的原项目尚处在收尾阶段。张工在进行了认真分析后，认为新项目刚刚开始，处于需求分析阶段，而原项目尚有某些重要工作需要完成，因此张工将新项目需求分析阶段的质量控制工作全权委托给了软件质量保证（SQA）人员李工。李工制定了本项目的质量计划，包括收集资料、编制分质量计划、并通过相应的工具和技术，形成了项目质量计划书，并按照质量计划书开展相关需求调研和分析阶段的质量控制工作。

解答：

张工一人身兼多职，导致其工作精力分散，不能专注与某一工作上。
项目质量计划书不应该有李工一人负责编制，应该有项目成员共同参与制定。
分工不明确，质量控制工作交给质量保证人员。

某网络建设项目在商务谈判阶段，建设方和承建方鉴于以前有过合作经历，并且在合同谈判阶段双方都认为理解了对方的意图，因此签订的合同只简单规定了项目建设内容、项目金额、付款方式和交工时间。

解答：

需求管理未做好，客户提出的需求未经过评审和确认。
合同签订不完善。应包括：项目建设内容、成本、进度、质量、验收标准、违约责任等条款。

王某是某管理平台开发项目的项目经理。王某在项目启动阶段确定了项目组的成员，并任命程序员李工兼任质量保证人员。李工认为项目工期较长，因此将项目的质量检查时间定为每月 1 次。

解答：

人力资源管理不到位。李工身兼数值，导致其工作精力分散，不能专注与某一项工作。
质量检查的周期太长，监控不力。质量检查的周期应根据项目实际特点，制定有效的能管控质量的周期。

李工对这个开发人员开具了不符合项报告，但开发人员认为并不是自己的问题，而且修改代码会影响项目进度，双方一直未达成一致，因此代码也没有修改。

解答：

沟通管理不到位。
针对不合格项，应及时修改，杜绝不良品流入下一阶段，必要时申请变更控制流程。

老陆是某系统集成公司资深项目经理，在项目建设初期带领项目团队确定了项目范围。后因工作安排太忙，无瑕顾及本项目，于是他要求：(1) 本项目各小组组长分别制定组成项目管理计划的子计划；(2) 本项目各小组组长各自监督其团队成员在整个项目建设过程中子计划的执行情况；(3) 项目组成员坚决执行子计划，且原则上不允许修改。

解答：

项目中缺少整体管理计划。
本案例中只做了子计划，而项目经历没有参与制定子计划，也没有形成整体管理计划。项目缺少整体的报告和监控机制，各项目小组各自为政。

在编码阶段，赵工发现需求文件还在不断修改，形成了多个版本，设计文件不知道该与哪一版本的需求文件对应，而代码更不知道对应哪一版本的需求和设计文件。同时，客户仍在不断提出新的需求，有些很细微的修改，开发人员随手就改掉了。

解答：

需求评审和确认没有做好。
文档管理不妥。编码不清晰，混乱。
没有详细的变更控制流程。

小刘经过详细的需求调研，开始着手制定项目计划，在此后过程中，他仔细考虑了项目中可能遇到的风险，整理出一张风险列表。

解答：

项目计划时不应由小刘一个人制定，应该让项目组全体成员共同参与制定。

项目管理计划制定完成后，小刘通知了项目组成员，召开了第一次项目会议，将任务布置给大家。随后，大家按分配给自己的任务开展了工作。

解答：

项目管理计划未经过评审和确认。
分配的任务需要确认。

某公司的质量管理体系中的配置管理程序文件中有如下规定：

由变更控制委员会(CCB）制定项目的配置管理计划；
由配置管理员（CMO）创建配置管理环境；
由 CCB 审核变更计划；
项目中配置基线的变更经过变更申请、变更评估、变更实施后便可发布；
CCB 组成人员不少于一人，主席由项目经理担任。

解答：

配置管理工作不妥当。配置管理计划应该由配置管理员制定。
变更控制流程不清晰，缺少了变更确认和变更跟踪过程。
CCB 的组成不应有人数上的限定，而是以能否代表项目干系人利益为前提。

为了节约时间小陈根据自己在沟通会议上记录的结果当晚组织相关人员撰写了软件需求规格说明书，次日便要求设计人员开始进行系统设计，并指出项目组成员必须严格按照进度计划执行以不辜负领导的期望与嘱托。

解答：

软件需求规格说明书应有详细的评审过程。
应该有清晰的变更控制流程。并不是严格按照进度计划来执行。

项目进行了 2 个月后，校方主管此业务的新领导到任，并提出了新的信息化管理要求。小陈进行变更代价分析，认为成本超支严重，于是小陈准备不进行范围变更，并将结果通知客户，引起客户不满。

解答：

没有清晰的变更控制流程，变更发布后，未及时实施。

近期该公司承担了某自然灾害预警系统项目。由于项目时间紧张上线任务迫切，经过管理层讨论决定临时简化流程，在开发阶段集中对质量进行把关。由于以前做过类似的项目为了节约时间项目经理带领团队套用原有成功项目的需求和设计思路，对历史上类似项目的相关文档进行修改后立即进入编码阶段。编码完成后为争取系统提前交付匆忙进行测试并上线试运行。

解答：