军衔: PMU初级一星
财产:
经验:
魅力:
来自: 北京市
鉴定: 本功能已经被关闭
发帖: 148篇
注册: 2001-12-17

--------------------------------------------------------------------------------


项目1月10日开工，做一个银行前置机的软件系统。共有5人组成，人员全程加入项目组。2个系统分析员（含项目经理），2个有1年工作经验的程序员，1个技术专家（不太熟悉业务）。
原计划：
2月1日完成需求分析，
2月25日完成系统设计（概设和详设），
4月1日完成编码，
4月28日完成系统测试，
5月1日定版。
但在2月17日检查工作时发现详设刚刚开始，2月25日肯定完不成系统设计，这时作为项目经理的你应该怎么办？
欢迎大家踊跃发言！最好采用头脑风暴法，大家仅发表自己的不同于别人的观点，不对别人进行评价！
如果有意见，可以另行开主题评价！

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 该贴在 2002年1月15日 16:38:49 被 bill 修改过 ]


daiqiang

军衔: 三等兵
财产:
经验:
魅力:
来自: 四川成都市
鉴定: 本功能已经被关闭
发帖: 127篇
注册: 2001-11-26

--------------------------------------------------------------------------------


从需求分析的时间段来看，估计大哥你得从新考虑安排新的进度表，得交领导和客户讨论，另外，如果5月1日定版（客户要求的），在软件架构设计时得采取点不同的开发方法。谢谢！！！

--------------------------------------------------------------------------------

骆驼飞鸟和鱼：
你就象冬天的雪花,我不该接近你,你融化了,悄悄的,消失在我温暖的眼里

--------------------------------------------------------------------------------
[ 本文发表于 2002年1月15日 18:10:58 ]


liujian20

军衔: 一等兵
财产:
经验:
魅力:
来自: 成都
鉴定: 本功能已经被关闭
发帖: 72篇
注册: 2002-1-9

--------------------------------------------------------------------------------


1. 对大家说：“不好意思，大家多辛苦一下吧！”
2.考虑增加人手；
3.借鉴历史资料；
4.将详设部分继续分解，全组共同参与；（可能和第2点有点重复吧？）

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年1月15日 20:49:29 ]


juliett

头衔:
军衔: 二等兵
财产:
经验:
魅力:
来自: 上海市
鉴定: 本功能已经被关闭
发帖: 82篇
注册: 2001-12-24

--------------------------------------------------------------------------------


随便说两句，限产问题根源， 项目内问题， 项目经理自己全兜， 涉及项目外不协调问题等，有必要通知相关人员，修订项目计划。

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年1月16日 13:18:39 ]


marry-099

军衔: 无军衔
财产:
经验:
魅力:
来自: 不告诉你 :)
鉴定: 本功能已经被关闭
发帖: 9篇
注册: 2002-1-10

--------------------------------------------------------------------------------


学习微软的每日构造，将编码和测试并行，压缩二者的时间，从而延长设计时间。

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年1月16日 14:57:47 ]


failwolf

军衔: 无军衔
财产:
经验:
魅力:
来自: 不告诉你 :)
鉴定: 本功能已经被关闭
发帖: 5篇
注册: 2002-1-8

--------------------------------------------------------------------------------


首先你的项目开发计划中就应该安排断点检查的，不是等到你高兴的时候在来检查项目进度计划，应每个计划都可以分成很多的断点检查，以及检查指标，包括KPI考核。
现在这个样子呢，除了加快工作进度（加班或者加人，也可以处罚调整人），还有和客户协商，争取最小的延长期，然后开始严格控制项目，并且评估项目成员的工作，控制他们拖拉。

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年1月16日 16:52:26 ]


兰燕子

军衔: 下士
财产:
经验:
魅力:
来自: 北京市
鉴定: 本功能已经被关闭
发帖: 56篇
注册: 2001-11-25

--------------------------------------------------------------------------------


为什么2月17日才发现需求分析延误了？
既然事情已经发生了，那么首先应该找出原因，再做风险分析。
如果你的计划只是根据以往的经验而定，那么以后的阶段还会发生类似的问题，如果不及时调整计划，以后的风险就比较大。
如果你的计划是经过详细的工作分解结构，进行时间和费用估算而得到的，那么原因可能是范围变更（需求变化）或资源不够（这些人需求分析阶段应该够了，我看好像项目也不大）等等吧。根据现状调整计划，如果项目完成日期是一个dead line，那你得想办法缩短工期。

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年1月16日 23:34:47 ]


CXH

军衔: 无军衔
财产:
经验:
魅力:
来自: 不告诉你 :)
鉴定: 本功能已经被关闭
发帖: 26篇
注册: 2002-1-15

--------------------------------------------------------------------------------


我想作为项目经理，首先应回想一下在项目开始实施时是如何做的计划，估计没有进行详细的工作分析和风险分析，这样的计划必定是会出问题的。建议在这个时间结点，重新进行计划工作和风险分析，如果5月1日的时间不可改变，就应考虑新资源和新技术的应用。

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年1月17日 16:03:07 ]


daiqiang

军衔: 三等兵
财产:
经验:
魅力:
来自: 四川成都市
鉴定: 本功能已经被关闭
发帖: 127篇
注册: 2001-11-26

--------------------------------------------------------------------------------


解决办法一：先完成最基本最重要的功能模块（在5月1日前。这个办法我用过，还可以）。
分析原因一：问题可能出在客户方，不配和。或者系统分析员的沟通技巧和方法有问题，使客户的需求由如黄河之水，滔滔不绝。

--------------------------------------------------------------------------------

骆驼飞鸟和鱼：
你就象冬天的雪花,我不该接近你,你融化了,悄悄的,消失在我温暖的眼里

--------------------------------------------------------------------------------
[ 本文发表于 2002年1月17日 19:00:01 ]


wangmy

军衔: 三等兵
财产:
经验:
魅力:
来自: 广东深圳市
鉴定: 本功能已经被关闭
发帖: 40篇
注册: 2001-11-26

--------------------------------------------------------------------------------


没个阶段的任务都需要检查的，你过了需求分析时间了才来检查肯定不行的啦，并且需求分析后要有个确认时间，另每个阶段任务间要有缓冲时间，建议你重新作计划，包括检查（点）计划。
如果最后时间不变，你需要在资源和进度间想点办法，以资源补进度。

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年1月18日 14:29:35 ]


wangmy

军衔: 三等兵
财产:
经验:
魅力:
来自: 广东深圳市
鉴定: 本功能已经被关闭
发帖: 40篇
注册: 2001-11-26

--------------------------------------------------------------------------------


没个阶段的任务都需要检查的，你过了需求分析时间了才来检查肯定不行的啦，并且需求分析后要有个确认时间，另每个阶段任务间要有缓冲时间，建议你重新作计划，包括检查（点）计划。
如果最后时间不变，你需要在资源和进度间想点办法，以资源补进度。

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年1月18日 14:29:43 ]


沧海浪子

军衔: 二等兵
财产:
经验:
魅力:
来自: 不告诉你 :)
鉴定: 本功能已经被关闭
发帖: 30篇
注册: 2002-1-11

--------------------------------------------------------------------------------


我们这里流行一句话:"后墙不倒"，即无论怎么变化，"5月1日定版"作为DEADLINE是不能变的！我认为这是客户的最终需求，其他的MILSTONE应该可以调节的。好在详设刚开始, 项目经理应重新调整一下计划进度，当然对内加班，对外和客户更好地交流，取得客户的理解是免不了的。
重新调整的计划进度当然是建立在充分详细的工作分析和风险分析的基础上，避免以后再有类似问题出现，同时也应避免无谓的串联作业，尽量缩短时间以达到最终目标- 5月1日订版。

--------------------------------------------------------------------------------

沧海一声笑，滔滔两岸潮

--------------------------------------------------------------------------------
[ 本文发表于 2002年1月19日 13:36:32 ]


icesbear

军衔: 无军衔
财产:
经验:
魅力:
来自: 不告诉你 :)
鉴定: 本功能已经被关闭
发帖: 5篇
注册: 2002-1-20

--------------------------------------------------------------------------------


我觉得编码的时间有点长，系统设计时间太短。
另外，不知在做需求分析、系统设计的时候对于程序员和技术
专家的工作是怎样分配的？
因为我想对于小项目，充分利用所有的资源特别重要。5个人的
团队也不是太小。
如果已经充分利用了这5个人的资源，我想这个可以完成。

否则，只能加人，一定程度上的加班。
要不购买第三方产品或别人的解决方案算了。：）

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年1月20日 18:11:12 ]


rabing

军衔: PMU初级一星
财产:
经验:
魅力:
来自: 山东济南市
鉴定: 本功能已经被关闭
发帖: 152篇
注册: 2001-11-29

--------------------------------------------------------------------------------


5个人（资源）应是项目计划时设定的资源了。那么现在出了问题，说明不是计划时缩水了，就是项目经理管理上的问题。

现在一方面外部要和客户充分沟通，尽量为项目延期（5.1不能完成）作准备。另内部加强管理，和上级联系要求增加人员或适当加班。

但项目目标（5.1完成）尽量不要变。

--------------------------------------------------------------------------------

求之不得，不求或与

http://www.jn-cyberport.com

--------------------------------------------------------------------------------
[ 本文发表于 2002年1月22日 10:20:29 ]


pmp

军衔: 三等兵
财产:
经验:
魅力:
来自: 黑龙江哈尔滨
鉴定: 本功能已经被关闭
发帖: 17篇
注册: 2002-1-19

--------------------------------------------------------------------------------


原因：
阶段性可交付成果提交计划没有做好！
对策：
1。 分析原因，做好更详细的工作分解，跟客商量调整计划，增加人手，或者加班。
2。 制定阶段性可交付成果提交计划，防止类似问题发生。

--------------------------------------------------------------------------------

想考pmp

--------------------------------------------------------------------------------
[ 本文发表于 2002年1月22日 14:28:37 ]


小小

军衔: PMU初级三星
财产:
经验:
魅力:
来自: 湖北武汉市
鉴定: 本功能已经被关闭
发帖: 519篇
注册: 2001-12-28

--------------------------------------------------------------------------------


上面各位大侠谈到的已经很多了，这里只谈两点：
1，将详设进行分解，让更多的人参与，并让部分详设于2月25日前通过。
2，将编码工作进行分解，有部分编码工作（基础工作）不依赖于详设的通过，在资源不冲突的情况下可以提前启动，有部分编码工作可在部分已通过的详述基础上展开。

--------------------------------------------------------------------------------

小小依然在大家身邊!

--------------------------------------------------------------------------------
[ 本文发表于 2002年1月25日 12:25:08 ]


juanlizi

军衔: 无军衔
财产:
经验:
魅力:
来自: 不告诉你 :)
鉴定: 本功能已经被关闭
发帖: 4篇
注册: 2002-1-25

--------------------------------------------------------------------------------


首先，我们先分析是什么原因造成这种延期的呢？
其次，为什么我们到现在才发现延期那？

对于软件死期一定的情况，我们只能压缩其他的时间，甚至不惜压缩测试时间，没有办法；要么，你就加人吧！可是有些问题并不是加人就可以解决的，也许人越多越忙越乱。

--------------------------------------------------------------------------------

juanzi

--------------------------------------------------------------------------------
[ 本文发表于 2002年1月28日 17:44:11 ]


yukf

军衔: 二等兵
财产:
经验:
魅力:
来自: 广东顺德市
鉴定: 本功能已经被关闭
发帖: 33篇
注册: 2002-1-22

--------------------------------------------------------------------------------


一：先搞清楚导致项目逾期的原因是什么？计划不周详？高估小组成员的能力？小组沟通有问题？需求经常变动？
二：对症下药，制定解决方案，审批方案。
三：执行解决方案。

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年2月3日 17:19:29 ]


fzb

军衔: 三等兵
财产:
经验:
魅力:
来自: 不告诉你 :)
鉴定: 本功能已经被关闭
发帖: 8篇
注册: 2002-2-3

--------------------------------------------------------------------------------


首先考虑怎么办？
1、要不要将以后几个没有相关性的工作并行，以争取时间。
2、内部沟通，加班？、外部沟通，调整计划或争取一定的时间？
3、考虑人员的数量、能力与进度的协调。
4、有一些工作可与客户沟通，让其来做。
........
再考虑原计划为什么会延迟。
组成评审小组，讨论总结经验。以指导下一步工作。

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年2月3日 19:38:01 ]


Vileefy

军衔: 无军衔
财产:
经验:
魅力:
来自: 北京
鉴定: 本功能已经被关闭
发帖: 5篇
注册: 2002-3-1

--------------------------------------------------------------------------------


你的计划是如何制定的？有更详细的WBS之类的东西吗？为什么不能把你的发现再提前一些，如果的你延误有正当理由，老板也不能说什么。如果你到了已经延误后再报告说延误了，那么.......

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年3月1日 14:01:07 ]


ralph

军衔: 三等兵
财产:
经验:
魅力:
来自: 深圳
鉴定: 本功能已经被关闭
发帖: 305篇
注册: 2002-3-5

--------------------------------------------------------------------------------


设立小型里程碑，最好是1至2天一个，并把它和日创建的方法结合起来。另外，全组成员召开紧急会议，讨论一个确实可行、详细的进度计划，并提交客户和上级批准。

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年3月5日 15:11:40 ]


ralph

军衔: 三等兵
财产:
经验:
魅力:
来自: 深圳
鉴定: 本功能已经被关闭
发帖: 305篇
注册: 2002-3-5

--------------------------------------------------------------------------------


（接上）补充一点，要调动所有成员的积极性，加强自我控制

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年3月5日 15:13:58 ]


weapon

军衔: 三等兵
财产:
经验:
魅力:
来自: 不告诉你 :)
鉴定: 本功能已经被关闭
发帖: 11篇
注册: 2002-3-20

--------------------------------------------------------------------------------


这种情况是不是可以考虑以下方法：
1、降低质量，缩减编码和测试的时间
2、增加资源，包括工作时间延长和人员的调整、增加等
3、将详设分解，甚至考虑详设和编码同时进行（风险很大）

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年3月25日 17:14:35 ]


projectm

军衔: 三等兵
财产:
经验:
魅力:
来自: 北京
鉴定: 本功能已经被关闭
发帖: 8篇
注册: 2002-3-27

--------------------------------------------------------------------------------


增加人手!

--------------------------------------------------------------------------------

学习、学习、再学习!

--------------------------------------------------------------------------------
[ 本文发表于 2002年3月27日 18:21:47 ]


Tiggler

军衔: 一等兵
财产:
经验:
魅力:
来自: 不告诉你 :)
鉴定: 本功能已经被关闭
发帖: 46篇
注册: 2002-3-18

--------------------------------------------------------------------------------


还有个方法：
充分和客户沟通，签订质量变更协议，在保证DL的前提后，再慢慢修改。
我们经常遇到这种问题，发生的原因有很多很多，不是你的计划做得多好能解决的，关键是怎样和客户沟通，怎样弥补损失。

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年3月28日 18:54:08 ]


billzhu

军衔: 无军衔
财产:
经验:
魅力:
来自: 不告诉你 :)
鉴定: 本功能已经被关闭
发帖: 2篇
注册: 2002-4-3

--------------------------------------------------------------------------------


项目在2.1完成需求分析，在设置检查点的时候，在此是否应该考虑有个点；在项目计划中应该对项目的关键路径进行设置，并依据此路径设置必要检查点。
问题既然已经发生，5.1已成为必定的时间，那么，首先必须对原因进行分析，在之基础之上再进行重新构建，我会考虑对项目范围作些调整，也会作些相应的加班。

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年4月4日 9:21:04 ]


SlowBull

军衔: 三等兵
财产:
经验:
魅力:
来自: 不告诉你 :)
鉴定: 本功能已经被关闭
发帖: 9篇
注册: 2002-4-25

--------------------------------------------------------------------------------


如果延期是因为需求的原因，就必须要求更改计划。当然，在设计进行了一段时间才发现是由于需求导致延期，那么，项目经理就有不可推卸的责任。
如果，延期是因为设计本身的原因，那么，大家就只好加班了。

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年5月22日 13:42:45 ]


stone

军衔: PMU初级二星
财产:
经验:
魅力:
来自: 重庆市
鉴定: 本功能已经被关闭
发帖: 211篇
注册: 2002-1-31

--------------------------------------------------------------------------------


两种可能，一个是计划的问题
另一种是计划的实施的问题

计划要做到前紧后松，我的经验是在100的时间里完成80%的任务。记住一点，任何在完成100%之前，怎个项目就没有完工.

项目太大，离Dead Line的时间太长，一定要恰当的把项目分成几个里程碑(Milestone]，两个里程碑之间留大约30%的缓冲时间。每一个里程碑要对应一个工件，这个工件就是可Check的产品。如期完成每一里程碑的时候，可以给工作人员一些激励。任何人都喜欢有成就感！！ 如果delay了，一定要找出原因和补救的方法，同时要给出相应的警告信息！

最后一点，项目delay不是开发人员的错，是项目经理的错！

--------------------------------------------------------------------------------

欢迎造访问我的网站，有UML，软件工程，项目管理
http://www.mooyee.com
ICQ# 58556674:QQ,别加我

--------------------------------------------------------------------------------
[ 本文发表于 2002年5月22日 17:43:56 ]


acai

军衔: 无军衔
财产:
经验:
魅力:
来自: 不告诉你 :)
鉴定: 本功能已经被关闭
发帖: 10篇
注册: 2002-5-24

--------------------------------------------------------------------------------


Plan problem:
RUP has given you a good sample how to make a plan to avoid this kind of delay. Your plan mistake is you don't know it will delay until it delaied.

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年5月24日 12:45:15 ]


jason_scm

军衔: 无军衔
财产:
经验:
魅力:
来自: 不告诉你 :)
鉴定: 本功能已经被关闭
发帖: 2篇
注册: 2002-11-8

--------------------------------------------------------------------------------


是否在项目计划中考虑到管理预留的问题，银行业务一般是到时必须投产，无法延期。建议加人和加班

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年11月8日 10:07:05 ]


jason_scm

军衔: 无军衔
财产:
经验:
魅力:
来自: 不告诉你 :)
鉴定: 本功能已经被关闭
发帖: 2篇
注册: 2002-11-8

--------------------------------------------------------------------------------


另外，不行的话详设、编码并行，完成一部分详设就有人开始这部分的编码

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年11月8日 10:16:24 ]


Jennie

军衔: PMU初级一星
财产:
经验:
魅力:
来自: 北京市
鉴定: 本功能已经被关闭
发帖: 64篇
注册: 2002-1-22

--------------------------------------------------------------------------------


如果程序员是有经验的，那么，跳过详细设计，从个人的经验来看，详细设计对整个系统的帮助不大，而且相当消耗资源，所以，是在不行，在做完概要设计以后直接由程序员介入开发

--------------------------------------------------------------------------------

菜鸟展翅

--------------------------------------------------------------------------------
[ 本文发表于 2002年11月11日 14:56:44 ]


felics_lu

军衔: 无军衔
财产:
经验:
魅力:
来自: 江苏南京市
鉴定: 本功能已经被关闭
发帖: 10篇
注册: 2002-10-18

--------------------------------------------------------------------------------


1.加人
2.报延期
3.删功能

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年11月18日 17:38:20 ]


seamoon

军衔: 无军衔
财产:
经验:
魅力:
来自: 不告诉你 :)
鉴定: 本功能已经被关闭
发帖: 2篇
注册: 2002-11-23

--------------------------------------------------------------------------------


以5月1日定版为最后期限，以当前完成情况为基础重新调整设计，编码，测试时期。设计时间不能压缩，建议压缩
编码时间，即可以增派人手进行编码。还可以与客户讨论
运行测试时间，欢迎交流！！

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年11月23日 21:35:48 ]


jie_rui

军衔: 无军衔
财产:
经验:
魅力:
来自: 不告诉你 :)
鉴定: 本功能已经被关闭
发帖: 5篇
注册: 2003-2-12

--------------------------------------------------------------------------------


1、前期做好项目分解设立里程碑
2、改用别的设计方案（中间件或实现主要功能）
3、由于需求引起的展期，可与客户商量延长工期。

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2003年2月14日 10:13:34 ]