1时间管理的过程_案例.pdf

案例 对问题：“俗话说计划赶不上变化，软件需求又总是变化，制定项目进度计 划有意义吗？”；“对于软件项目应制定怎样的进度计划？应细化到何种程度？”； “如果软件外包，怎样控制进度？”；“编制进度计划，重点应该考虑哪些因素 呢？”。 某公司准备开发一个软件产品。在项目开始的第一个月，项目团队给出了一 个非正式的、粗略的进度计划，估计产品开发周期为 12~18 个月。一个月以后， 产品需求已经写完并得到了批准，项目经理制定了一个 12 个月期限的进度表。 因为这个项目与以前的一个项目类似，项目经理为了让技术人员去做一些“真正 的”工作（设计、开发等），在制定计划时就没让技术人员参加，自己编写了详 细进度表并交付审核。每个人都相当乐观，都知道这是公司很重要的一个项目。 然而没有一个人重视这个进度表。公司要求尽早交付客户产品的两个理由是：1） 为下一个财年获得收入；2）有利于确保让主要客户选择这个产品而不是竞争对 手的产品。团队中没有人对尽快交付产品产生怀疑。 在项目开发阶段，许多技术人员认为计划安排的太紧，没考虑节假日，新员 工需要熟悉和学习的时间也没有考虑进去，计划是按最高水平的人员的进度安排 的。除此之外，项目成员也提出了其他一些问题，但基本都没有得到相应的重视。 为了缓解技术人员的抱怨，计划者将进度表中的计划工期延长了两周。虽然 这不能完全满足技术人员的需求，但这还是必要的，在一定程度上减少了技术人 员的工作压力。技术主管经常说：产品总是到非做不可时才做，所以才会有现在 这样一大堆要做的事情。 计划编制者抱怨说：项目中出现的问题都是由于技术主管人员没有更多的商 业头脑造成的，他们没有意识到为了把业务做大，需要承担比较大的风险，技术 人员不懂得做生意，我们不得不促使整个组织去完成这个进度。 在项目实施过程中，这些争论一直很多，几乎没有一次能达成一致意见。商 业目标与技术目标总是不能达成一致。为了项目进度，项目的规格说明书被匆匆 赶写出来。但提交评审时，意见很多，因为很不完善，但为了赶进度，也只好接 受。 在原来的进度表中有对设计进行修改的时间，但因前期分析阶段拖了进度， 即使是加班加点工作，进度也很缓慢。这之后的编码、测试计划和交付物也因为 不断修改规格说明书而不断进行修改和造成返工。 12 个月过去了，测试工作的实际进度比计划进度落后了6 周，为了赶进度， 人们将单元测试与集成测试同步进行。但麻烦接踵而来，由于开发小组与测试小 组同时对代码进行测试两个组都会发现错误，但是对测试人员发现的错误响应很 迟缓，开发人员正忙于完成自己的工作。为了解决这个问题，项目经理命令开发 人员优先解决测试组提出的问题，而项目经理也强调测试的重要性，但最终的代 码中还是问题很多。 现在进度已经拖后 10 周，开发人员加班过度，经过如此长的加班时间，大 家都很疲惫，也很灰心和急躁，工作还没有结束，如果按照目前的进度方式继续 的话，整个项目将比原计划拖延4 个月的时间。 思考题： 1．在本案例中，我们能吸取什么教训吗？ 2．编制计划时，邀请项目组成员参与有哪些好处？ 3．编制进度计划时需要考虑哪些重要因素？ 4．一个成功的项目管理其基础是什么？