Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1047713
  • 博文数量: 288
  • 博客积分: 10306
  • 博客等级: 上将
  • 技术积分: 3182
  • 用 户 组: 普通用户
  • 注册时间: 2008-08-12 17:00
文章分类

全部博文(288)

文章存档

2011年(19)

2010年(38)

2009年(135)

2008年(96)

我的朋友

分类: 项目管理

2009-08-03 11:31:18

中国人与欧美人的思维习惯存在较大的差异。当一件事情做砸了后,中国人一般倾向于去反思个人犯了什么错误,并往往得出结论,如果换另外一个水平高一点的人,应该就不会搞砸了;而换作是欧美人的话,则会去反思做事情的方法存在什么问题和不足,他们的结论正好相反,如果做事情的步骤不对,换其他水平再高的人,同样很有可能搞砸。欧美人总是希望找到一种方法,能够让普通智力的人就可以将事情做好。

分析上述这个在国内很常见的典型案例,我们可以发现,案例中的项目经理首先想到的是依靠能人或高手来成功完成这个项目,这应当出自于其以往的项目经验,这种心理本身并没有错;然而,项目经理显然缺乏足够的工程素养,他没有认真地去分析项目的性质、并思考项目到底该如何去做,而这家软件企业也没有建立相应的机制,将以往成功项目的经验传递给项目经理;于是这个项目完全是凭借项目组成员自发的想象来推进。

项目经理的开发思路是:大家从学校所学到的软件工程知识,能够记得的好像就是需求、设计、测试什么的,而设计从来就没做过,大部分人最拿手的还是编码;而项目的工作量摆在那儿,肯定要靠大伙儿共同来分担,这样就必须划分任务;架构设计虽然做不了,需求中的功能模块还是能分出来的,于是按模块分配任务就是自然而然的事儿了。纯粹依据功能模块来划分开发任务,在业界早已被证明是种不好的开发模式,经过这么多年的努力,业界已诞生了更为合理与有效的开发过程。另外,案例中后期出现的需求变更直接导致了项目的失败,这完全是可以避免的;当代企业应用的软件开发过程规定,在做需求之前还有业务建模的环节,如果开发组与客户先认真地就业务达成一直认识的话,遗漏一些对业务非常重要的功能是不大可能发生的。不幸的是,项目组没有采用这些正确的软件过程与方法,或者他们压根就不知道应当这样去做项目。

总而言之,这个案例中的项目执行与书中所列的软件项目执行步骤是背道而驰的。

阅读(710) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~