2008-05-03
工期逼近,释放压力
关键字: 控制进度 释放压力 现在我们几乎天天加班(星期天休息),为了赶时间,为了能够顺利的完成项目,交付给客户使用.我们都在尽心尽力的把项目往前赶.可是到现在我们发现项目的进度变缓慢了,工期也延长了.现在的情况是,前期整体的需求基本到位,有些还得决策层来决定业务流程;细节上的东西开发员要和业务需求的同事反复的沟通,开发员才能够明白流程,清楚业务逻辑;开发员只对DAO和业务层进行了单元测试,ACTION就没有进行模拟测试了,表示层一般用firedug来测试;开发员觉得没有问题了,然后移交给测试人员进行功能测试.
现在问题来了,测试人员测试发现BUG太多,然后就开始说:"做是做的挺快的,可是质量不怎么好!和开发员解释他还很难接收和理解为什么?" 开发人员说:"我都是按照你们的需求做的,怎么需求又变了,又要改呀; 哦,那个BUG由于业务太复杂,我忘了." 开发员抱怨:"到现在了,需求还没有定下来,我们都不怎么好动手,做一点似乎又被卡住了,又要问分析员了." 开发员的压力还是比较大的,他们一边要修复做过模块的BUG,又要完成新的模块.现在大家都又这种感觉,每天晚上一躺下,脑袋里还是在想着那些业务,那些代码,怎么才能实现这样或那样的功能. 现在经理已经下了军令状了,一定要在某某时间正式上线,不然,,,,
面对工期,面对压力,面对项目,我们只能相互理解原谅,减少抱怨,静下心来,抛弃浮躁,耐心的解决问题,分析问题才能够共同的把项目做好.
- 23:27
- 浏览 (220)
- 评论 (42)
- 分类: SoftwareEngineering
- 进入论坛
- 相关推荐
评论
sword721
2008-07-23
没想到有比我更惨的人.
hyhongyong
2008-07-23
hgq0011 写道
kele8boy 写道
这种项目,肯定是失败的,典型的垃圾。我以前一家公司就是这样,还没做完,改了又改,逻辑,需求全变,页面套了一遍又一遍.加班加到晚上3点,干
失不失败取决于很多因素,我们的项目和你们的有很多的差别,并不是延期了就是定义为失败那也不合理。我们的项目虽然延期了,但是老板支持,用户支持,熟悉业务的分析人员,我们也有信心把它做好,那么这个项目我们说它不会失败的。
对,关键失败是如何定义的!
延期只是针对最初的估计而言的,整个项目发展了,计划也要变化了。
hgq0011
2008-07-20
kele8boy 写道
这种项目,肯定是失败的,典型的垃圾。我以前一家公司就是这样,还没做完,改了又改,逻辑,需求全变,页面套了一遍又一遍.加班加到晚上3点,干
失不失败取决于很多因素,我们的项目和你们的有很多的差别,并不是延期了就是定义为失败那也不合理。我们的项目虽然延期了,但是老板支持,用户支持,熟悉业务的分析人员,我们也有信心把它做好,那么这个项目我们说它不会失败的。
kele8boy
2008-06-25
这种项目,肯定是失败的,典型的垃圾。我以前一家公司就是这样,还没做完,改了又改,逻辑,需求全变,页面套了一遍又一遍.加班加到晚上3点,干
smhx
2008-06-23
我觉得加班的效果对长期来说不会很明显的解决问题,但是迫于领导的压力还是要加班的。
还有用户需求的不断变化是正常的,这就需要设计人员、代码人员不断提高自己的业务水平,使设计和代码具有一定的灵活性才能适应项目不断变化的需要。
我觉得压力的问题可以自己缓解的,经历过一些项目的洗礼抗压力的能力自然会增强了。
还有我觉得工作不是我们的全部,所以上班的时候努力工作下班以后就应该享受生活做我们喜欢的事情了,这样人生才有价值。
还有用户需求的不断变化是正常的,这就需要设计人员、代码人员不断提高自己的业务水平,使设计和代码具有一定的灵活性才能适应项目不断变化的需要。
我觉得压力的问题可以自己缓解的,经历过一些项目的洗礼抗压力的能力自然会增强了。
还有我觉得工作不是我们的全部,所以上班的时候努力工作下班以后就应该享受生活做我们喜欢的事情了,这样人生才有价值。
wxb_love
2008-06-19
其实我觉得分工细,可以提高效率,要看你的项目经理了,现在做的都是模块化的,每个人代码其实可以独立存在的.
leton2008
2008-06-18
banner 写道
这个现象跟我去年参与的项目有些像,不过那时我们是在现场开发,在领导的强大压力下,没有休息日,晚上加班到深夜、通宵。
现在想起来,管理上有待提升;日构建成了折磨开发人员的恶魔....
现在想起来,管理上有待提升;日构建成了折磨开发人员的恶魔....
哈哈。这个我去年也经历过了。
hgq0011
2008-06-14
在次延期了,:(
我们还得继续加班
我们还得继续加班
elice
2008-06-03
hgq0011 写道
抛出异常的爱 写道
1.所有的bug当作新的工作交给程序员
2.减少加班时间。
2.减少加班时间。
1)所有程序员自己负责的东西,就要负责到底,有些业务比较复杂,有时是程序员没有理解透,或遗漏了,有时是需求没有分析好,在程序实现上有问题.这样压在程序员的肩上太多工作.
2)不加班肯定搞不定.加班也没有把握.因为有些业务不是很复杂,也就是做一些CRUD.
当然,加班实在是辛苦,思维都产生便秘了.
中国程序员可不是美国程序员
maoone2003
2008-05-27
hgq0011 写道
dennis_zane 写道
那个某某时间,我敢肯定也上线不了
你看的太准了,但愿不要被你言中.
现在每做一个计划都在推迟(目前推迟10天左右).
现在还有一些东西都没有定下来,讨论来讨论去,没有结果.即使在分析人员决得没有有问题了,可和开发人员一起讨论沟通的时候问题,又冒出来了.这样让我决得好恐怖,似乎陷入了沼泽地.
现在开发人员一个个熬的熊猫眼,我很担心他们是否能够承受得住这样的压力.所以我都不会老是去问他们手头的工作怎么样了.只会说没有问题,慢慢做,有问题及时提出来,大家一起解决,宽宽他们的心.
不知道万一不能搞定,老大怎么和老板交代,这之前已经延期了一次了.当然这不是我考虑的问题.
我觉得经验重要,业务重要,团队重要,技术重要,也就是要天时地利人和.(屁话,:()
(1)项目经理在做什么?整个项目管理混乱,没有条理,项目经理的责任首当其冲;
(2)现在大多数项目需求、设计做不到很细致,但是我们必需保证需求和设计做的尽量细致、符合客户的要求、适应现有的业务流程及技术体系架构,更重要的是需求分析人员要精通业务,具备良好的沟通能力;设计人员能够很好的理解需求,具备相应的设计能力,如果人的因素满足不了,那么会直接导致项目中后期需求、设计、开发的失控;
(3)如果人员能力不具备,则需要不断的、适时的进行项目组人员内部培训(比如周会的时候等),使人员技能迅速提升;
(4)为了降低人员流动的风险,则需要在开发过程中需求人员不断的向开发人员讲解需求、设计人员、开发人员之间不断的沟通,使大家能够充分了解正在做的系统的整体业务处理流程,整体的技术走向,解决的是客户的哪些业务问题,甚至要实现的是客户的哪些商业目标等,这些工作其实都需要项目经理充分协调,统一组织安排。。
(5)至于开发人员开发的东西不能满足要求,一边改代码一边又在开发新的模块,这个问题相信大多数人都遇到过,我们的解决方法就是专门抽出一个人进行集成测试及代码修改;如果觉得单调可以在合理调配工作的基础上让开发人员轮换去做,比如一个人做一周等,毕竟很多项目没有单独的测试人员;
(6)综上,个人认为你的项目是因为没有一个合理的项目计划,项目经理的资源调配意识、风险识别分析意识不够充分造成的,其实我们都知道标准的项目开发实施流程,但是不能够很好的适应项目的实际现状进行具体分析,以灵活的调配资源、任务分配是造成最终项目整体质量下降的主要原因;
太多了,先说到这里,呵呵
rainchen
2008-05-24
“哦,那个BUG由于业务太复杂,我忘了”
很明显,需要引入一套项目管理工具,至少具备任务分配及BUG提交功能,需要阶段性测试:某需求完成后应自动分配给测试人员进行测试,测试通过勾选通过测试,有BUG则由测试人员提交,开发人员则每天根据BUG及需求的优先度进行开发。
很明显,需要引入一套项目管理工具,至少具备任务分配及BUG提交功能,需要阶段性测试:某需求完成后应自动分配给测试人员进行测试,测试通过勾选通过测试,有BUG则由测试人员提交,开发人员则每天根据BUG及需求的优先度进行开发。
xqstation
2008-05-23
不要口头。。。口头太危险了。。。
公司没项目管理相关的软件就用邮件,主送责任人,抄送直接领导和相关人员。
公司没项目管理相关的软件就用邮件,主送责任人,抄送直接领导和相关人员。
小小龙猫
2008-05-22
xidaboy 写道
项目的管理上面存在重大失误
测试和开发人员沟通不足,测试人员的测试CASE应该是和开发人员,分析人员沟通过的,否则就会出现,开发人员不了解测试人员为什么要测这个的问题
另外,开发人员应该提高对自身的要求,代码都写完了,自己难道对自己所做模块的业务还有糊涂的地方,说不过去...
测试和开发人员沟通不足,测试人员的测试CASE应该是和开发人员,分析人员沟通过的,否则就会出现,开发人员不了解测试人员为什么要测这个的问题
另外,开发人员应该提高对自身的要求,代码都写完了,自己难道对自己所做模块的业务还有糊涂的地方,说不过去...
这位大哥,敢问你的头像上的人是谁?大家也帮忙看看。
http://xidaboy.javaeye.com/
gaizaozhe
2008-05-21
还有一点.根本不知道自己的需求要做到那种程度,于是经常和测试的争论做的到底对不对....无限郁闷
gaizaozhe
2008-05-21
这个问题和我们现在一个项目情况很象
1.基本没有项目管理.需求到分析从头到尾都是项目经理一个人做,沟通基本靠口头,
需求还没确定之前就一直赶著做,做完了才发现和需求完全不一样.只能改,重新再来
2.程序员技术方面.一开始做的时候人手不够.把一些完全没做过JAVA,没怎么接触编程
的拉过来做,导致后期维护成本直线上升.BUG排除不易.
3. 没日没夜的加班,员工情绪低落.
这些问题.老实说,很多都是项目管理经验不够导致的..
1.基本没有项目管理.需求到分析从头到尾都是项目经理一个人做,沟通基本靠口头,
需求还没确定之前就一直赶著做,做完了才发现和需求完全不一样.只能改,重新再来
2.程序员技术方面.一开始做的时候人手不够.把一些完全没做过JAVA,没怎么接触编程
的拉过来做,导致后期维护成本直线上升.BUG排除不易.
3. 没日没夜的加班,员工情绪低落.
这些问题.老实说,很多都是项目管理经验不够导致的..
zengjinliang
2008-05-21
曾经有个项目与LZ有同感,有些客户是BT死的.
guoshiguan
2008-05-19
lyhapple 写道
深有感触..
这两天就是被业务困扰着.一个问题改了四次.每次测试组返回的BUG,都得再次跟业务组的确认需求.可笑的是每次问到需求不是完全一样的...很劳神.,也许是修改别人的代码的缘故..大家也许都能知道改别人代码的痛苦.尤其是没有任务注释的代码...如果是自己开发的话,也许就不会这样艰难了...
而且已经开始加班了...555555555555...
这两天就是被业务困扰着.一个问题改了四次.每次测试组返回的BUG,都得再次跟业务组的确认需求.可笑的是每次问到需求不是完全一样的...很劳神.,也许是修改别人的代码的缘故..大家也许都能知道改别人代码的痛苦.尤其是没有任务注释的代码...如果是自己开发的话,也许就不会这样艰难了...
而且已经开始加班了...555555555555...
需求用mail确认吧,总不能让开发人员把所有的责任都担下来,业务组没有个定性吧,
dayang2001911
2008-05-18
我的感觉是:项目经理肯定有问题!
lyhapple
2008-05-17
深有感触..
这两天就是被业务困扰着.一个问题改了四次.每次测试组返回的BUG,都得再次跟业务组的确认需求.可笑的是每次问到需求不是完全一样的...很劳神.,也许是修改别人的代码的缘故..大家也许都能知道改别人代码的痛苦.尤其是没有任务注释的代码...如果是自己开发的话,也许就不会这样艰难了...
而且已经开始加班了...555555555555...
这两天就是被业务困扰着.一个问题改了四次.每次测试组返回的BUG,都得再次跟业务组的确认需求.可笑的是每次问到需求不是完全一样的...很劳神.,也许是修改别人的代码的缘故..大家也许都能知道改别人代码的痛苦.尤其是没有任务注释的代码...如果是自己开发的话,也许就不会这样艰难了...
而且已经开始加班了...555555555555...
lelong
2008-05-15
是否与客户沟通太少了?,可以采取迭代开发模式,先交一个相对稳定版本给客户暂时使用,交流想法。
发表评论
提醒: 该博客已发表在公共论坛,博客所有留言会成为论坛回贴,留言请注意遵守论坛发贴规则
- 浏览: 194328 次
- 性别:

- 来自: 广州

- 详细资料
搜索本博客
我的相册
P1010057
共 4 张
共 4 张
最新评论
-
工期逼近,释放压力
没想到有比我更惨的人.
-- by sword721 -
工期逼近,释放压力
hgq0011 写道kele8boy 写道这种项目,肯定是失败的,典型的垃圾。我 ...
-- by hyhongyong -
工期逼近,释放压力
kele8boy 写道这种项目,肯定是失败的,典型的垃圾。我以前一家公司就是这样 ...
-- by hgq0011 -
[转载]制作从屏幕右下方 ...
在firefox下有点问题,ie下完美
-- by zhngling -
工期逼近,释放压力
这种项目,肯定是失败的,典型的垃圾。我以前一家公司就是这样,还没做完,改了又改, ...
-- by kele8boy






评论排行榜