王明是不是一个好的项目经理?

【软件过程】王明是不是一个好的项目经理

​ 王明在上海软件园的一家公司工作,最近被任命为一个非常重要的生物技术项目的项目经理。这个项目为组合人类基因组的一个DNA排序仪器开发软件。每台仪器售价约20万美金,一些客户都将会购买数台。100台这种仪器每天24小时连续工作的话,人类所有的基因组在不到2年的时间内就可以全部解密。这个项目是该公司最大的项目,并且预测将来会有巨大的增长潜力和潜在收益。不幸的是,这个项目的管理存在许多问题。这个项目已经进行了3年,项目经理也换了3次。在高级管理层任命王明为项目经理之前,他是该项目首席软件开发员。高级管理层指示,无论如何必须要在4个月内推出DNA排序仪软件的第一版,并在9个月内推出正式应用版。他们急于让项目出成果,主要原因是与一个大公司进行收购谈判的需要。
  王明精力充沛,聪明过人,并且具备项目成功必需的专业背景。他深入分析了技术问题,最后找到了导致DNA排序仪无法工作的关键错误。然而,作为项目经理这一新的角色,他正面临困境。虽然王明和他的团队实现了产品的准时推出,但由于王明没有专注于管理工作,高级管理层并不满意。他从来没有为项目要做的事情制定过准确的详细的进度计划。他并没有做一个项目经理该做的事情,而是成了一位软件集成者和问题解决者。然而,王明还是不能理解高级管理层的问题---- 他不是推出了产品吗?他们难道就没有认识到他的价值?
  CEO没有和王明以及他的项目组打招呼就另外雇了一个新的经理李强来负责沟通自已和王明项目组的人员。CEO和其他上级主管对这名新的中间经理李强非常满意,他能经常与他们见面,沟通想法,并且还很幽默,他开始为公司将来管理项目建立标准和文档模板。但李强和王明相处得不很好。一次王明意外地收到李强发来的email,而这个邮件本来是李强想发给CEO的,在信中李强提到了王明工作的不好相处,并且在新生儿子身上占用了太多的时间。
  王明看了信后很恼火,冲进CEO的办公室。CEO建议将王明调到另一个部门,但王明不同意,CEO没有考虑太多后果,就与王明中止了合同,让王明离开了公司。王明在离开前获得了公司承诺的很大一笔认股权。经受了项目经理这一职位的失败后,王明决心致力于软件开发,在附近这种工作机会还很多。王明辞职之后,CEO发现又有其他几个聪明能干的年轻的技术人员提出了辞职书。

讨论:
  问题在哪里?王明是不是一个好的项目经理?为什么?
  要成为一个更好的项目经理,他应怎么做?上级领导应如何支持和帮助他?

软件项目计划-限时开发

限时开发是指软件项目的进度是固定的,不能改变的。这种限时开发项目有什么好处?哪些项目可以采用限时开发?限时开发的风险是什么?如何保证成功的限时开发?

答:
1.好处
1.1它提高进度的优先级别
  进度绝对不变就是强调进度的极端重要性。时间限定的重要性要凌驾与其他任何相关因素之上。如果项目范围与时间限制有冲突,你就要缩小范围,服从时间限制的要求。而时间限制本身是不允许改变的 。
1.2它避免了90-90问题
  很多项目都遇到这样的问题,当他们的项目有90%已经完成的时候,接下来项目就停止不前,这样的状态甚至维持几个月到几年时间。很多项目花费了很多时间,却没有使项目向前发展,而且还消耗了大量的资源。你应该开始是先建造一个小的版本,然后很快完成,接着可以继续建造版本2。不要在第一个版本中规定太多的特性,这样可以很快地得到一个运行的基础版本,从中获取经验,然后建立版本2。
1.3分清性能的优先等级
  项目可能会花费较多的时间去争辩那些对提高产品功效没有什么意思的问题,例如,我们是否需要多花费4周的时间,来实现全色的打印预览,还是黑白的就足够了?按钮上的浮雕是一个像素好,还是两个像素好?不要将时间花费去讨论优先级"非常低"或"相对低"的特性上。
1.4它限制了开发者对产品的镀金
  在指定的范围之内,你通常可以用不同的方法来实现某个特定的性能。也常常存在着两天、两周以及两个月的不同版本。如果不指定时间限制的话,开发者常常会按照他们自己的兴趣或者按照他们对质量、可用性以及易用性的要求来实现特性。而限时开发则向开发者宣布这一点。如果有一个2天的版本的话,那就是所需要的版本,不必考虑别的。
1.5它可以防止目标偏移
  目标的偏移是时间的函数,在大多数项目中大约每月偏移1%(Jones,1994)。限时开发可以通过两种方式来控制目标偏移:首先,如果你缩短开发周期的话,便可减少人们等待新功能出现的时间;其次,由于有些长期项目的目标偏移源于市场状况或操作环境的改变,因此,通过缩短开发时间,你就可以减少市场或操作环境的改变,进而减小软件的变化。
1.6它有助于激励开发者和最终用户
  人们希望别人认为他所做的工作是非常重要的,而紧迫感可以增强这种重要性感受。因此,这种迫切感是一种强有力的激励者。

2.使用限时开发的最低要求
  限时开发并非适用于所有类型的开发。以下是一些指导原则,你可以判断你的项目是否适用这种方法。
2.1各功能的优先等级列表
  在进行限时开发之前,系统的功能和总体设计必须已被确定。最终用户需要把系统的各功能按优先级别进行排序,以便让开发者知道哪些是必须的,哪些是任选的。他们应当定义一个最小的核心功能,你确信可以在限定的时间内完成它。如果系统的优先等级不能被确定的话,它就不适合使用限时开发这种方法。
2.2切合实际的进度估计
  对开发时间的估计应该由开发人员来完成。他们需要估计一下所需的时间(通常是60到120天)以及在这个期限内能够完成多少功能。从激励的角度来看,让他们自己进行估计是非常重要的。限时开发是一种激励型的开发方法,如果只是把进度和目标不切实际地组合在一起告诉开发者的话,很难成功。
2.3适用的项目类型
  限时开发最适于开发内部商业软件的开发(IS软件)。限时开发是一种渐进型方法,应当使用快速开发语言、CASE工具或其他支持快速代码生成的工具。那些需要大量手工代码的高度定制系统通常不适合使用限时开发方法。在开始一个开发项目以前,需要确保你现有的工具和人员能够完成该项目。
2.4最终用户的充分介入
  与其他基于原型的开发方法一样,限时开发的成功取决于最终用户的反馈。如果你不能保证用户的充分介入的话,就不要使用限时开发。

\3. 限时开发小组
  一个限时开发小组可以由1到5个成员组成。对于完成的"限时开发小组"来说,也可以包含最终用户,他们承担建设阶段的辅助工作。最终用户通常要完全参与他们的角色,为开发人员提供支持。
  限时开发小组必须熟练地运用快速开发软件来开发系统。因为在限时开发项目中没有时间让他们学习新的软件。
  限时开发小组需要得到鼓励。时间限制所产生的紧迫感有助于提高这种激励。具有公司内很少人能够达到的生产力水平也是一种激励。

4.控制限时开发的风险
4.1限时开发应用于不合适的产品
  我不主张将限时开发用于上游活动,如项目规划,需求分析或设计等,因为这些行为牵连到下游活动。在需求分析中如果有100美元的错误的话,就有可能以后要花2000美元来更正(Boehm和Papaccio,1998)。在失败的软件产品的墓道中,充满了这类项目的尸骨,他们总是想缩短上游活动的时间,害怕软件产品不能及时交付。而上游的一点小失误就导致了下游大量的损失。因此,在早期阶段中"节省时间"通常是个错误的节省。
  相反,限时开发在下游活动中常常是很有效的,因为单个工作的不合格会被限制在时间范围内,并且不会对其他工作产生影响。
4.2牺牲质量换取功能
  如果你的客户不能牢记先质量后功能的原则的话,就不要使用限时开发。开发者很难同时满足多个相互矛盾的目标,如果客户坚持要求工期紧、质量高和数量多的功能的话,开发者根本不可能同时满足所有的要求,在这种情况下,质量必然会受到影响。
  一旦质量遭受影响,进度也将不可避免地遭受影响。开发小组为了在有限的时间内完成所有要求的功能,必然会影响工程质量,质量一旦出现问题,就需要花费好几个星期来完善产品以使它们的质量满足要求。
  对于一个真正的限时开发者而言,在到达最后期限时,软件产品要么被接受要么被丢弃。这意味着在开发的任何过程,必须首先保证产品的质量。成功的限时开发取决于能否同意限制产品的广度,而不是降低产品的质量来满足紧张的时间要求。

\5. 成功使用限时开发的关键
● 只对可以规定期限内(通常是60-120天)完成的项目使用限时开发。
● 确保最终用户和管理层对系统核心功能已达成一致,而开发小组相信能够在规定时间内完成。确保所有的功能都已排定了优先级,当需要赶上进度时,可以剔除其中的部分功能。
● 确保限时开发小组的成员为项目进行签约,并采取各种措施激励士气。
● 在限时开发的全过程中保证质量。
● 如果需要的话,宁可减少功能也要保证进度,决不延长工期。

软件项目计划-自愿加班

加班已成为软件开发的常见现象,那么加班是好还是坏?请列出它的好处和坏处。

答:
  过多的超时工作和进度压力能影响开发进度,但是少量的加班能增加每周完成的工作量,并且提高员工的积极性。一周4~8小时的额外工作时间能增加10%到20%的产出,甚至更多。
1.加班多少时间?
  微软的资深专家Steve Maguire 认为,每周要求员工工作这么多小时的话,他们会在工作时间料理个人私事。他们花很多时间来吃饭、锻炼、外出、付帐单、读计算机杂志等,换句话说,如果每天仅工作8个小时的话,他们就能够在他们自己的时间里做这些事情。Maguire得出这样的结论:那些一天在办公室工作12小时的员工,实际工作时间很少有超过8小时的 ,尽管他感谢那些能自我激励的员工会工作得更多。

如果你要求开发人员自愿加班,就要先观察一下他们实际工作了多少时间。
  不论要求加班的压力是来自内部的还是外部的,过分加班或者过分的进度压力都会导致以下问题:
● 增加缺陷的数量。
● 容易诱发思想不集中的危机。
● 降低创造性。
● 减少了自我教育和组织改进的时间。
● 减少了生产力,影响了进度。
● 降低了响应需要紧急加班的应变能力。

2.自愿加班的底线
  自愿加班的底线是稍微地增加每周员工正常工作时间,大概增加10%~20%,就可以导致更大比例的产出。 在美国,平均每个开发人员每周工作的时间是48到50个小时。在加拿大和日本也存在同样的情况。这种情况导致了一个有趣的现象,即通过减少目前加班的水平,平均每个公司实际上能增加他们的产出。

3.成功应用自愿加班的关键
● 采用开发人员自愿加班方法而不要领导者强迫的方法。
● 激励开发人员的积极性,如成就感、成长的机会、工作本身的意义、个人生活受到尊重和技术领导的机会等,使得喜欢工作的开发人员会自愿增加工作时间。
● 根据他们实际可能确定加班小时数。
● 不论什么理由,不让开发人员过多地加班。

需求管理-错误的需求管理

“喂,是Phil吗?我是人力资源部的Maria,我们在使用你编写的职员系统时遇到一个问题,一个职员想把她的名字改成Sparkle Starlight,而系统不允许,你能帮帮忙吗?”
  “她嫁给了一个姓Starlight 的人吗?” Phil问道。
  "不,她没有结婚,而仅仅是要更改她的名字,"Maria回答。“就是这问题,好像我们只能在婚姻状况改变时才能更改姓名。”
  "当然是这样,我从没想过谁会莫名其妙地更改自己的姓名。我不记得你曾告诉我系统需要处理这样的事情,这就是为什么你们只能在改变婚姻状况对话框中才能进入更改姓名的对话框。"Phil 说。
  Maria说:“我想你当然知道每个人只要愿意都可以随时合法更改他(她)们的姓名。但不管怎样,我们希望在下周五之前解决这个问题,否则, Sparkle将不能支付她的账单。你能在此前修改好这个错误吗?”
  “这并不是我的错!我从来不知道你需要处理这种情况。我现在正忙着做一个新的性能检测系统,并且还要处理职员系统的一些需求变更请求”(传来翻阅稿纸的声音)。“我还有别的事。我只可能在月底前修改好,一周内不行,很抱歉。下次若有类似情况,请早一些告诉我并把它们写下来。”
  “那我怎么跟Sparkle说呢?” Maria追问道,“如果她不能支付账单,那她只能挂帐了。”
  "Maria,你要明白,这不是我的过错。"Phil坚持道,“如果你一开始就告诉我,你要能随时改变某个人的名字,那这些都不会发生。因此你不能因我未猜出你的想法(需求)就责备我。”
  Maria不得不愤怒地屈从:“好吧,好吧,这种烦人的事使我恨死计算机系统了。等你修改好了,马上打电话告诉我,行吧?”

讨论:错在哪儿?

质量管理-微软的测试案例

在80年代初期,Microsoft公司的许多软件产品出现了"Bug"。比如,在1981年与IBM PC机一起推出的BASIC软件,用户在用".1"(或者其他数字)除以10时,就会出错。在FORTRAN软件中也存在破坏数据的"Bug"。由此激起了许多采用Microsoft操作系统的PC厂商的极大不满,而且很多个人用户也纷纷投诉。
  Microsoft公司的经理们发觉很有必要引进更好的内部测试与质量控制方法。但是遭到很多程序设计师甚至一些高级经理的坚决反对,他们固执地认为在高校学生、秘书或者外界合作人士的协助下,开发人员可以自己测试产品。在1984年推出Mac机的Multiplan(电子表格软件)之前,Microsoft曾特地请Arthur Anderson咨询公司进行测试。但是外界公司一般没有能力执行全面的软件测试。结果,一种相当厉害的破环数据的"Bug"迫使Microsoft公司为它的2万多名用户免费提供更新版本,代价是每个版本10美元,一共化了20万美元,可谓损失惨重。
  痛定思痛后,Microsoft公司的经理们得出一个结论:如果再不成立独立的测试部门,软件产品就不可能达到更高的质量标准。IBM和其它有着成功的软件开发历史的公司便是效法的榜样。但Microsoft公司并不照搬IBM的经验,而是有选择地采用了一些看起来比较先进的方法,如独立的测试小组,自动测试以及为关键性的构件进行代码复查等。Microsoft公司的一位开发部门主管戴夫·穆尔回忆说:“我们清楚不能再让开发部门自己测试了。我们需要有一个单独的小组来设计测试,运行测试,并把测试信息反馈给开发部门。这是一个伟大的转折点。”
  但是有了独立的测试小组后,并不等于万事大吉了。自从Microsoft公司在1984年与1986年之间扩大了测试小组后,开发人员开始"变懒"了。他们把代码扔在一边等着测试,忘了唯有开发人员自己才能阻止错误的发生、防患于未来。此时,Microsoft公司历史上第二次大灾难降临了。原定于1986年7月发行的Mac机的Word 3.0,千呼万唤方于1987年2月问世。这套软件竟然有700多处错误,有的错误可以破坏数据甚至摧毁程序。一下子就使Microsoft名声扫地。公司不得不为用户免费提供升级版本,费用超过了100万美元。

分析:从Microsoft公司的教训中可知,公司内部对产品的测试(称为α测试),需要开发人员与独立的测试小组共同参与。开发人员应该执行"白盒"测试,即测试源程序的逻辑结构以及实现细节("白盒"是指看得见程序的内部结构)。而独立测试小组应该执行"黑盒"测试,即按照规格说明来测试程序是否符合要求("黑盒"是指看不见程序的内部结构)。比如在测试一个模块时,"白盒"测试方法要对模块的所有代码进行单步跟踪测试。而"黑盒"测试方法只需测试模块的接口是否符合要求,它关心程序的外部表现而不是内部的实现细节。对于没有条件设立独立的测试小组的小公司,可以让开发小组的成员相互测试对方的程序。外部测试则交与专门的、权威的测试机构以及现场用户进行测试。

风险管理-慈善活动的风险管理计划

​ 你公司志愿为当地的一项体育活动提供站台人员,该活动将在两周内举行。活动的所有盈利都将捐给当地的慈善机构,该机构的下一个项目需要10万元。你公司的目标是从活动中赚得这10万元。你所在的小组被指定来设计这个货厅。
  这个货厅有一份菜单,包括汉堡包、热狗、炸薯条和软饮料。
  这个12英尺*12英尺的货厅有电力、准备食物用的遮阳棚和桌子。当地一家公司向你们提供一台软饮料自动售货机和一台冰箱。所捐赠的设备的容量未知,但销售商保证,对于你们的用途足够了。
  参加这个为期两天活动的观众,估计第一天有800人,第二天有1200人。你们计划每天从上午9点到下午4点销售自己的商品。另外还有一个货厅将在此次活动中进行销售。
  你公司的高层管理人员将参加这次活动看作是一次大的公关机会,并将提供摄影师参加此次公开活动。这些高层管理人员中,可能会有一些人帮助当职员。
1、 列出5个风险,讨论分析每个风险的各种变数
2、 分析风险的影响和概率,确定风险的次序
3、 从中确定前3个风险
4、 为这3个风险中的每个风险制定缓解计划
5、 为这3个风险中的每个风险制定应急计划

软件度量-度量设计

请采用GQM模型为一家软件企业设计度量指标。

沟通管理-秘书门风波

2006年4月7日晚,EMC大中华区总裁陆纯初回办公室取东西,到门口才发现自己没带钥匙。此时他的私人秘书瑞贝卡已经下班。陆试图联系后者未果。数小时后,陆纯初还是难抑怒火,于是在凌晨1时13分通过内部电子邮件系统给瑞贝卡发了一封措辞严厉且语气生硬的"谴责信"。信的全文如下(原文为英文):
  瑞贝卡(秘书的英文名),这个礼拜二我刚告诉你,想东西、做事情不要想当然,今天晚上你就把我锁在门外,我要的东西都还在办公室里。问题就在于你以为我随身带了钥匙。从现在起,无论是午餐时段还是晚上下班后,你要跟你服务的每一名经理都确认无事后才能离开办公室,明白了吗?
  这位总裁并不只把这封信发给了秘书一人,还同时抄送给了公司的4位同事。
  面对大中华区总裁的责备,一个小秘书应该怎样应对呢?一位曾在GE和甲骨文服务多年的资深人士告诉记者,正确的做法应该是,同样用英文写一封回信,解释当天的原委并接受总裁的要求,语气注意要温婉有礼。同时给自己的顶头上司和人力资源部的高管另外去信说明,坦承自己的错误并道歉。 但是瑞贝卡的做法大相径庭,并最终为她在网络上赢得了"史上最牛女秘书"的称号。两天后,她在邮件中回复说,“首先,我做这件事是完全正确的,我锁门是从安全角度上考虑的,如果一旦丢了东西,我无法承担这个责任。其次,你有钥匙,你自己忘了带,还要说别人不对。造成这件事的主要原因都是你自己,不要把自己的错误转移到别人的身上。第三,你无权干涉和控制我的私人时间,我一天就8小时工作时间,请你记住中午和晚上下班的时间都是我的私人时间。第四,从到EMC的第一天到现在为止,我工作尽职尽责,也加过很多次的班,我也没有任何怨言,但是如果你们要求我加班是为了工作以外的事情,我无法做到。第五,虽然咱们是上下级的关系,也请你注重一下你说话的语气,这是做人最基本的礼貌问题。第六,我要在这强调一下,我并没有猜想或者假定什么,因为我没有这个时间也没有这个必要。”
  本来,这封咄咄逼人的回信已经够令人吃惊了,但是瑞贝卡选择了更加过火的做法。她回信的对象选择了"EMC(北京)、EMC(成都)、EMC(广州)、EMC(上海)“。这样一来,EMC中国公司的所有人都收到了这封邮件。
  这件事在网上吵得沸沸扬扬。形成几千人转发的局面。一些网友称瑞贝卡为"史上最强女秘书”。
  据新浪科技的一份调查,在7000多名参加调查的网友中,约72%对女秘书的做法表示支持。在"秘书门"事件发生不久后,瑞贝卡及陆纯初先后离职。

点评:72%支持秘书,是因为做为上司的陆纯初的行为首先就非常地不职业化。所谓"职业化"就是"训练有素"。所谓"训练有素"就是在事情来临之时,能够采取正确的意识、心态、道德和行为、技能来应对所发生的事情。陆最大的错误是把邮件同时传给几位高管,有破坏秘书声誉的嫌疑。
  而秘书失去28%的支持,也是因为其以牙还牙的手段不高明,以至于使事态无法控制,不但损害了陆还损害了公司的声誉。
  管理的关键最终要落实到人,而人的关键最终要落实到职业化。全员职业化塑造必将是人力资源工作者们未来非常关注的重要培训内容。除了职业能力,职业素养也应成为人力资源工作者们招聘时要关注的要素。

综合管理-无清晰策略的快速开发

张辉准备领导他在公司的第2个项目。他的前一个项目进行得并不如人意。原计划要求他的项目小组12个月内交付CRM 2.0版,但实际花上了18个月。项目组在项目开始时就已经认识到项目计划进度的紧迫性,因而项目一开始就处于"死亡进程"(Death March)之中。经过整整18个月每天12小时,每周6~7天的艰苦挣扎,到项目结束时,6个小组成员中有2个退出,小组中最具实力的开发人员文志从上海骑自行车出走,目的不明。他从北京 的长城脚下发给张辉一张他骑着自行车的照片,文志说他不是退出,但没人知道他什么时候能回来。
  CRM 3.0版要在CRM 2.0 版上市的12个月后发布,项目收尾、总结、休假已经2个月了。张辉准备开始新的尝试。离交付CRM 3.0版还有10个月的时间。他约了上司陈键与他讨论项目计划,陈键可以帮助他为开发人员提供尽可能的工作条件。用户文档负责人和测试负责人也一同参加了讨论。
  陈键说:“3.0版必须超过竞争对手,所以我们在这个项目上需要投入更大的力量。我想你们可能还没意识到。从上个版本开始我们公司就已经落后了,这次公司准备全力以赴支持这个项目。我已经批准为项目组每个成员提供私人办公室,最新型的计算机以及免费的咖啡。你觉得怎样?”
  张辉回答:“听起来很有吸引力,不过 除此之外,由于所有开发人员都是有经验的,我想主要应该多一些激励和支持措施,并使之从中获益。我不想事无巨细地管理他们,我想让每个开发人员都对系统的某一部分负责。上次,我们已经碰到许多接口问题,所以,这次我想花一些时间设计不同模块之间的接口,然后放手让他们自己去干。”
  用户文档负责人说:“如果这是一个10个月的项目,我们需要在第8个月的时候锁定软件,及时准备用户文档。上次,直到项目结束,开发人员还在进行修改,令人尴尬的readme文件有20页长。用户手册在审查的时候总是被枪毙,如果你能做到可视化锁定,你的开发方法听起来就有道理了。”
  测试负责人补充说:“我们也需要在可视化锁定的同时写出自动测试脚本。”
  张辉赞同可视化锁定方法。陈键随即批准了张辉的总体步骤,并告诉他要保持大家步调一致。
  当项目开始时,开发人员对他们的私人办公室,新的计算机及咖啡很满意,他们干劲十足地开始了工作,并主动工作到深夜。
  时间一个月一个月地过去,项目进展平稳,他们已经完成了早期的软件原型,继续进行编码设计。管理层也一直在监视项目的进展,每件事情似乎都在顺利进行。
  项目进行到了第4个月的时候,文志结束了他的自行车旅行,重新回到了项目组,并带回了一些骑车旅行时产生的新想法。张辉担心文志能否在允许的时间内完成那么多任务,但文志承诺,无论有多大的工作量,一定按时完成任务。
  项目组成员各自独立做着自己的工作,而随着可视化锁定日期的来临,他们开始进行代码集成。他们在可视化锁定最终截止日期前一天的下午2点开始工作,但很快发现程序不能链接(link),更不用说运行了。代码在链接时有十个语法错误,而且每处理一个错误就会产生10个以上的新错误。他们直到午夜也没结果,只好决定第2天再说。
  第二天早晨,陈键约见项目组成员:“程序移交给文档和测试人员了吗?”
  张辉说:"还不行,我们还有些集成问题,可能今天下午就可以移交了。"项目组又工作了整个下午和晚上,但还是没能解决已经发现的所有问题,最后,他们只得承认无法预知集成需要多长时间。
  他们整整化了2周时间处理这些语法错误,才得以使系统能够运行,当项目组比计划推迟了2周将阶段定版的系统移交时,测试和文档人员迅速做出反应,拒绝接收这样的版本。文档负责人说:“系统太不稳定,没隔几分钟就会崩溃,同时,有太多的系统漏洞,不能编写文档。”
  测试负责人也赞同道:“系统太不稳定,你每次选择一次菜单,系统就会瘫掉,测试人员根本无法完成测试报告。”
  张辉同意他们的说法,并表示他的项目成员会全力解决这些问题。陈键提醒他们注意10个月的最后截止日期,并说这个产品不能再像上个产品那样延期了。
  他们又花了一个月的时间解决产品稳定性的问题,以使文档和测试工作能够进行,那时,距离10个月的最后截止日期只有2周时间了,他们只能更加拼命地工作。
  但测试发现问题的速度远比开发人员解决问题的速度快,处理系统这部分的错误经常会导致系统其他部分的问题。已经无法按预计的10个月交付产品了。陈键召开了一个紧急会议,他说:“我看各位工作都很辛苦,但结果不够好,我已经为你们提供了各种尽可能的支持,但我并没有看到最终的软件,如果你们不能迅速完成产品,公司将会倒闭。”
  伴随着巨大的压力,士气渐落。数月过去了,产品开始稳定了,但陈键仍对项目组施加压力,有些工作的效率极其低下。
  尽管文志也在不停地工作,但他还是比项目中的其他人交付软件的时间晚。他的代码没有错误,但他对用户界面的控件做了些修改,导致测试脚本和用户文档与之不匹配。
  张辉约见了测试和文档负责人:"你们可能不高兴,但我们只能有两种选择,要么保持文志的代码不变,重新进行测试并重新编写用户文档,要么仍掉文志的代码,将其彻底重写。文志不愿意重写他的代码,这个项目组也没人能做这件事了。这样看来只能请你们修改用户文档和测试用例了。"经过一翻争执,测试和文档负责人勉强同意了张辉的要求。
  到项目结束时,开发这个软件整整花了15个月的时间,由于以上的变化,用户文档的印刷错过了计划安排的最佳时间点,公司在开发人员完成刻盘工作后,不得不又为印刷用户文档等候了2周,才将产品运出公司,投向市场。产品发布后,用户对CRM 3.0版反映冷淡,几个月时间,其市场分额就从第2位降到了第4位。张辉意识到他的第2个项目像第1个项目一样,又失败了。

讨论:错在哪里?

综合管理-具有清晰策略的快速开发

仍是CRM3.0项目,现在由张莉承担项目经理。
  在项目组的第一次会议上,她介绍了项目组的成员,而后切入主题,"我在整个公司范围内收集了其他项目的总结报告。"她说:“我已经列出足有1英里长的公司其他项目在运作中发生的所有错误,我将把这个单子贴到会议室里,我想在我们开始犯其中某个错误时,就在上面画一个标记,如果你们还知道上面没有列出的其他错误或我们可能会犯的任何潜在的错误,请加在上面,我们不想重蹈覆辙。”
  “选择你们参与本项目是因为你们每位都有开发技术基础,我想你们一定知道做好需求分析和设计以使我们能够不必返工而浪费时间意味着什么,所以,我要求项目组的每位员工要用心工作,而不是辛苦工作,工作太辛苦会导致出现更多的错误,我们没有时间处理这些错误。”
  “我也同时制定了配套的风险管理计划,我们面对的是一个具有挑战性的进度计划,所以我们不能让能够防止的风险发生。我们现在面对的最大风险是计划的进度无法实现,我想我们应该在本周末在对进度计划进行一次评估,如果认为进度计划无法实现,我们将讨论提出一份更现实的计划。”
  每位项目成员都点头,对经过"死亡进程"项目的人员来说,张莉的讲话让他们长出了一口气。
  1周后,张莉约见了她的上司陈键:“项目组已经很仔细地审视了项目计划,陈健,得出的结论是,我们只有5%的机会在项目截止日期完成当前定义的功能,这是假设没有任何改变的情况下,当然,有些事情总是要改变的。”
  “真是糟透了。” 陈健说。“我们至少需要有50%的机会按时交付软件,并且我们还要能够针对今后10个月市场的变化随时修改项目要求,对此,你有什么建议?”
  "我们还没有完成对产品定型,所以,我们还是有一定灵活度的。"张莉说。“但我认为即使根据目前的需求分析,我们也需要花8~30个月时间,我知道这个时间跨度是比较大,但这也对我们在产品完全定型之前的工作很有利。我们需要10个月后提供产品,对吗?我认为,可以考虑再加入一些开发人员,然后建立一个渐进式的交付计划,今后我们每2个月推出一个交付版本,第一个交付版本决定在第6个月末完成。”
  “听起来不错。” 陈健说:“除此之外,我想对这个项目而言,功能比进度更重要,我会在找一些人员谈谈,然后我们再定。”
  当陈健再找张莉时,他告诉她公司愿意将软件计划时间延长到12个月,并还是希望实现所要求的功能,另外,为安全起见,可以采用渐进式软件交付计划。张莉轻松了许多,并说她认为这是一个很现实的目标。
  项目经过初期的几周后,她的项目组已经建立了详细的用户界面原型,并与潜在客户进行交流,根据客户回馈对原型进行了几次修正。
  张莉继续维护她的风险列表,并确定了这个项目的3个主要风险:1)可能导致大量重复工作和进度延期的质量低下风险;2)具有挑战性的进度本身的风险;3)因市场竞争,要求软件功能不断增加而导致的竞争功能风险。张莉感到质量低下风险可以通过渐进交付计划来消除。他们将在第6个月时将第1个交付版本送交到测试部门,他们会对软件按用例进行测试。
  进度计划风险可以通过产品功能的优先级次序由项目组自己来消除。他们在12个月内会尽可能开发更多的功能,而通过每2个月交付1个版本,他们可以确保在需要的时候有东西可以交付。
  项目组采用两种方式来消除竞争功能风险。他们花了大约3个月的时间开发设计方案,该方案包含了所有已定义原型的功能和其他一些他们认为应该包含在3.0版中的功能的框架。这种设计使系统更容易适应可能产生的各种改变,同时他们还分配出时间在第10个月分析竞争对手的产品,修改原型,并在最后的2个月中实现必要的竞争功能。
  在第4个月时,随着设计方案的完成,项目组制定了一组细化的里程标志,制定了到第6个月时,发布第1个可交付测试版本所遵循的原则与途径。第6个月交付的版本并不完善,但应该保证质量,这可以为下一步工作打下坚实的基础。在项目组顺利交付第6个月的版本后,项目组又为第8个月交付制定细化的里程标志,并使用同样的方法到达了第10个月的里程标志处。
  在第10个月结束时,项目组按计划对竞争对手产品进行研究。竞争对手已经在第8个月发布了一个好产品,它已经包含了一些CRM3.0出于竞争目的而需要包含的功能。项目组立刻将这些新功能加入到优先队列中,重新分配优先次序,并制定了最后2个月的细化的里程标志。
  几乎同时,蒋华,一个初级开发人员发现了一种可以将产品对话框进行更好的组织的方法,并建议提交到项目组成员碰头会上。会上,高级开发人员唐国刚对此做出的反应是:“这是一个非常好的想法,我认为我们应该采用这一方法修改我们的设计,但不是现在,蒋华,对你来讲,进行这样的改变只是一天的工作量,但会影响文档编制进度达一周或更多时间,将其放到4.0版本中如何?”
  蒋华说:“我没想到对文档进度有这么大的影响。这是个好的方法,我想请求在未来修改设计时采用。”
  在达到第12个月的里程标志时,项目组按计划交付了终版软件。由于从第6个月开始测试时CRM的质量就是优秀的,所以,文档在等待正式版软件交付期间,已经可以基于详细的用户界面进行编写了。文档与软件同步准备就绪。开发人员没有实现一些低优先级的功能,但他们实现了所有的重要功能,CRM3.0是成功的。