[讨论] 请大家帮忙分析一下_IT项目管理，软件开发版_国内最热门的项目管理经验交流论坛_国内PMP聚集社区

项目管理者联盟 | 中国工程管理网 | 中国研发管理网

会员中心

资料库

适合敏捷开发项目
敏捷项目管理最佳实践

重视项目商业分析
商业价值与需求分析能力

产品管理国际认证
全球产品管理最佳实践

单项目管理经典指南
年轻项目经理首选

北京 | 直播 | 录播

大型复杂项目全球标准
定位高级项目管理层

链接战略与项目
实现组织资源投资回报

信息系统项目管理师
系统集成项目管理工程师

计划 | 报名 | 经验

论坛
	价值源于交流与分享

会员区：

功能区：公告建议 | 帖子搜索 | 管理团队 | 荣誉版主 | 帮助手册

论
坛
导
航
区

项目型组织	项目管理	工程项目	科技项目	项目化管理	管理软件	资格认证	职业休闲
EPM体系与流程	综合集成管理	总承包管理	IT软件开发	项目型制造	P3E/P6	PMP \| PgMP	职业发展探讨
组织与人力资源	进度,范围,成本	国际工程	生物制药	专业服务	微软PROJECT	IPMP \| PRINCE2	管理学堂
项目管理信息化	团队建设与沟通	房地产	汽车设计开发	生活项目	PowerOn专版	软考项目管理	英语角\|读书版
多项目与大项目	质量与风险	监理与咨询	手机数码	文体娱乐		注册建造师	房车吃游
PMO建设与管理	采购与合同	工程设计				项目管理硕士	闲聊版\|商务版

俱乐部：北京 | 大连 | 福州 | 广州 | 杭州 | 南京 | 山东 | 上海 | 深圳 | 四川 | 天津 | 武汉 | 西安 | 郑州 | 申请成立

TOP榜：精华 | 最新 | 最热 | 会员

版面信息

说明：失败的IT项目比比皆是，进度延迟，预算超支，客户需求多变，成员加班抱怨...IT项目（软件开发.，信息系统实施等）寻求新生

	精华区		发表帖子
	投票区		发起投票
	资料区		上传资料

本版版主

camer
登录：2013/7/2
次数：867
注册：2003/3/3
发帖：2745

dorothy
登录：2016/12/15
次数：804
注册：2004/9/6
发帖：993

steveli2008
登录：2009/5/26
次数：464
注册：2003/5/12
发帖：1026

zhf_karen
登录：2015/6/2
次数：346
注册：2005/6/13
发帖：469

俱乐部导航

北京	大连	福州	广州	杭州
南京	山东	上海	深圳	四川
天津	武汉	西安	郑州

联盟·近期活动

社区热点

精彩专题

如何做好项目沟通计划

软件项目质量管理

国际工程索赔与反索赔

社区圈子

集团企业生态体.
圈主：ETPPM
行业：综合应用

HG信用盘0出租
圈主：de123
行业：综合应用

生态系统体系下.
圈主：ETPPM
行业：综合应用

西安IT项目管理
圈主：muzud
行业：IT软件

房地产项目管理
圈主：13935823
行业：房地产

联系社区管理员

咨询电话 010-82273401/11
斑竹申请 admin@mypm.net

版权所有 © 2003-2004
京ICP证070584号
BBS业务许可2007第353号
最佳显示模式：1024*768像素

[讨论] 请大家帮忙分析一下 [发表于 2005/6/28]

状态开放帖 浏览量 622

复制该帖链接收藏本帖 [回复] [引用]
我们公司现在在做一个省级的政府项目，现在情况如下：公司一直做该行业软件，现有一套c/s系统，现在客户要求j2ee；项目组预计15人，除了新招的4个外，大部分没做过java；同时公司领导准备搞正规化管理，听从一个顾问的意见，现有人员分为业务组和技术组，业务组负责需求分析、概要设计，完成UC、UI等，技术组在此基础上完成详设及编码；从合同签订到现在快4个月了，还没开始真正进入编码，我现在真的已经感觉很茫然了。大家帮忙看看这个项目这样下去能成功么？
>>> 由论坛统一发布的广告：

楼主

jackyzhou

职务无
军衔二等兵
来自北京
发帖 10篇
注册 2004/2/20
PM币 66
经验 51点

Re:[讨论] 请大家帮忙分析一下 [回复于 2005/6/29] [回复] [引用]
这个项目前途堪忧。风险过于高了： 1、技术风险，你们能够进行Java开发的人员对于业务系统不熟悉，而对业务系统熟悉的人员不熟悉Java。特别是需要J2EE来做，很可能的一个现象就是最后发现项目中犯了很多很低级的错误。 2、一般来说，对于这种15人的团队，我不是特别建议划分业务组和技术组。理由很简单，分工降低成本的先决条件是相互之间的沟通需要得不多。事实上，我们更愿意逐步的人员投入而不是划分业务组和技术组。即使要进行这种分离，我也不希望业务组承担概要设计的工作。让技术组去做好了。如果说你们的技术组实际上是编码组，我更不赞成，对于一个技术风险比较严重的团队来说，再实行这种做法，无异于自寻无趣。可能的一个结果是导致沟通和协调之间出现很多问题； 3、如果这时候还没有进入编码，4个月时间是略微有一些过份。事实上，对于你们这种业务系统来说，是需要尽快进入迭代开发过程，然后把作出来的一个一个版本提交给客户试用，来迅速地反馈意见。而不是坐在家里，一味进行概要设计和需求分析。这种事情作多了，容易导致需求镀金和想当然的现象，最后提交的时候，客户一个不满意，你们的项目就死出去了。当然，如果你们的项目为期在2年左右，那么花4个月时间进行框架设计等等工作，来排解技术风险，和需求风险，我多少还是能够接受的。但是恐怕并非如此。这个项目前途堪忧。如果我来执行这个项目：我会起一个Prestudy项目，一方面通过Demo的开发，来使得团队成员熟悉J2EE框架和后续的一些技术，另外，通过迅速的Demo开发，把客户的想法体现出来。将来这个Demo是放弃还是继续研发，就取决于你们自己了。不过一般来说，这个Demo我是会抛弃的。尽快展开一些实际的工作了。在这种政府项目中，闭门造车，是不可取的。而想通过文档来完成和客户之间的沟通，这一点多少过于理想化了。很多团队这么做，但是效果好的很少。谨慎一些吧。有点恐怖。

1楼

zhf_karen

职务无
军衔少尉
来自北京市
发帖 469篇
注册 2005/6/13
PM币 1929
经验 639点

Re:[讨论] 请大家帮忙分析一下 [回复于 2005/6/29] [回复] [引用]
非常感谢zhf_karen 的建议。我也觉得风险相当高，说实话，我是不赞成这种作法的，但我不是项目负责人，而且公司领导现在就是听顾问的。我觉得领导只是单一从节约成本的角度来考虑，其余的可能都被忽略了。那个顾问的想法在很多方面很合他的意，比如： 1、他是技术出身（领导称之为J2EE高手）； 2、有一套开发架构； 3、号称他们以前项目都是按照正规化进行的； 4、最关键是他的架构对开发人员要求不高，用他的话说就是随便招几个学生培训一段就行了。我也比较认同zhf_karen 的说法，对目前这种做法存在很大疑问： 1、何谓正规化，UML？RUP？而且做过政府行业系统的人都知道，这种项目受客户的制约相当大，这种所谓的正规化对一个小公司有效么，据我所知，很多大公司做项目都不采用这一套； 2、J2EE架构真那么牛吗？对于从没做过JAVA的人培训一下就可以了？ 3、技术组的人基本都不懂业务，就凭业务组的UC、概要设计和简单的讲解就能进行详设编码了？现在项目已经进行了这么久了，说什么都没用，在目前这种情况下还有什么好的解救办法么？？

2楼

jackyzhou

职务无
军衔二等兵
来自北京
发帖 10篇
注册 2004/2/20
PM币 66
经验 51点

Re:[讨论] 请大家帮忙分析一下 [回复于 2005/6/30] [回复] [引用]
嘿嘿，我基本肯定这是一个伪专家。用几个学生培训一下，然后就开发，结果看起来是节省了目前的成本，但是很多成本实际上没有节省，是被隐藏在长期成本中。如果你们干完一票就算，那么也罢，不然还是实际一些了。 1、正规化是需要的，但是对于类似的项目来说，完全的正规化是一种奢谈，因为正规化无法解决快速需求变更的问题。这不是针对小公司或者大公司，而是说你做得是什么项目！明确说，对于你们这种项目来说，采取RUP或者严格的CMM或者CMMI是不适合的。我在CMM4以下环境下研发4年以上，所以对于他的优势和劣势都相对比较清楚。 2、Java的架构的确可以降低开发人员的水平，比如我们常规使用Structs模式或者使用RO模型都可以。但是，不是完全的。因为，低水平的开发人员会犯下很多低级错误，这些错误成本是使用低水平研发人员所必须付出的。举一个例子，我们曾经做过一个项目，在框架设计阶段，性能为380笔业务每秒，但是在研发完成以后，基本上在80笔业务每秒。而且这个项目是由基本上3-4年研发经验的工程师进行的，对性能考虑也比较多。都是如此的情况，更不用说其他的。这基本是胡扯的说法。 3、这一点，可以明确说：这对於你们类似项目来说，基本上是找死。除非你们有明确的概念，愿意为此付出极其高昂的成本，和能够控制住长时间的需求不发生太大变更。我们一般的项目，还是需要研发人员多少来了解业务的。明确说，这是胡扯。比如BI系统和业务系统的数据库设计和数据库操作，即使完全相同的业务，系统也是完完全全不同的。现在解决方式就是：尽快落实Demo的研发，给客户反馈。让你们的专家少说一些空话，尽快展开工作，如果他懂得RUP，那么应该比较容易说服他进行迭代开发。因为一般来说，这个专家在后期会把项目失败的绝大多数因素，归咎在技术组人员技术能力严重不足上，和项目规范遵守不够。但是这不是根本，根本是强制地划分了太多的层次，而沟通被忽略。

3楼

zhf_karen

职务无
军衔少尉
来自北京市
发帖 469篇
注册 2005/6/13
PM币 1929
经验 639点

Re:[讨论] 请大家帮忙分析一下 [回复于 2005/6/30]

[回复] [引用]

Karen的分析很到位，有时候需要demo来抛砖引玉。

--------------------------------------------------------------------------------------------------------
PM - PoorMan

BLOG:http://steve.mypm.net

=== 有问题，找IT项目管理 ===

4楼

steveli2008

职务无
军衔中尉
来自北京
发帖 1026篇
注册 2003/5/12
PM币 5062
经验 829点

Re:[讨论] 请大家帮忙分析一下 [回复于 2005/6/30] [回复] [引用]
在调研开始前做了一个系统原型，html静态页面实现的，没有任何数据，只是为了给用户一个概念。这个系统也不算小，现在做demo还来得及吗？

5楼

jackyzhou

职务无
军衔二等兵
来自北京
发帖 10篇
注册 2004/2/20
PM币 66
经验 51点

共1页 97 [ 第1页 ] 8:

！您尚未登录，不能回复主题。现在登录注册

建设运营：共创时网络