(原创)[请教] 一公公, 及各位开发团队管理的高人,请给个意见.

上一篇 / 下一篇  2008-01-31 08:50:38

查看( 264 ) / 评论( 29 )
请说说你们的意见,遇到了困难.
这个破项目不接也不行. 公司已经花了很多资源,做好了是应该的也没有什么功劳,做差了,肯定要受批了


如果您遇到这样的半路的糟糕项目, 你会如何处理?

主要从哪几方面入手?

多谢


在这里, 花一点点时间去说说你的宝贵意见吧.

http://www.itpub.net/showthread. ... 300&pagenumber=

论坛模式 推荐 收藏 分享给好友 推荐到圈子 管理

TAG:

虎窝 tigerfish 发布于2007-07-21 22:58:34
先为善后找个台阶
yining的个人空间 yining 发布于2007-07-21 23:04:06
1、开发团队水平如何？人员安排是怎样的？
2、需求分析是否完善？
3、工期还有多少时间？
4、原项目是什么语言什么环境下开发的？
5、是否有擅长设计与开发的人才？
亭华龙哥 亭华龙哥 发布于2007-07-21 23:17:55

QUOTE:

最初由 yining 发布
[B]1、开发团队水平如何？人员安排是怎样的？
2、需求分析是否完善？
3、工期还有多少时间？
4、原项目是什么语言什么环境下开发的？
5、是否有擅长设计与开发的人才？ [/B]
周五中午在左右才接到通知,这个破项目估计要我来接手.

具体情况还没有了解清楚.简单的情况是:

1.单从项目进度表看,已经占用了3/5的时间.

2.从需求功能表看,完成(第一期)不足一半,或更少..并测试结果表明,这一半也BUG比较多,还存在影响系统级的BUG

3.原项目经理负责与客户需求分析的主持, 听说前几天,还和客户就需求上发生分岐. 我简单看了看需求表,开发文档,测试报告等都不是很完善.

4. 各种项目的原因现在让开发团队成员都非常大的压力,原项目经理负荷过重,从心理和身体都受很大压力. 提出退出开发团队.

5.此原项目经理在短时期内可协助向新团队说明情况.

6.原团队好的人员,有一些,但不多.系统观念的人员应该还欠缺一些.估计需要补充一点.但也担心人月神话所说,新加入人经验不足的员人反而会拖累进度.

7. 语言开发环境应该没有什么问题.我还没有深入了解.毕竟我才收到通过几小时后就下斑了, 下周一会估计会更清楚.


ccbzzp的个人空间 ccbzzp 发布于2007-07-21 23:21:06
把破项目做好,
那才能显示你的才能,
一马平川的路谁都会走,

是你的挑战,也是机遇!
小辉发布于2007-07-21 23:24:05
1.分析问题先
2.找应对方法
3.人是处理问题和执行的关键

应用系统，无非是两个方面，功能（需求）和开发（架构和代码）

BUG一堆，有两种，一种是底层架构代码BUG，一种是功能需求BUG。

前者需要精通的开发的人员，后者需要需求分析人员，既然原项目经理是肩负这个，那么这个就应有自己挑起。而前者，由于原团队的人还在，应该可以挑起，如果不能，那则，尽快找到合适的人原。

时间是另外的关键，在纠正底层架构的问题的同时，只能自己加快步伐，搞清楚功能要点和需求，进行需求功能的消化和纠正。
搞好客户关系，适当的要到时间，应该是必须的。

善后，目前如果就开始考虑，可能项目就没得做了
小辉发布于2007-07-21 23:26:31

QUOTE:

最初由 亭华龙哥 发布
[B]

周五中午在左右才接到通知,这个破项目估计要我来接手.

具体情况还没有了解清楚.简单的情况是:

1.单从项目进度表看,已经占用了3/5的时间.

2.从需求功能表看,完成(第一期)不足一半,或更少..并测试结果表明,这一半也BUG比较多,还存在影响系统级的BUG

3.原项目经理负责与客户需求分析的主持, 听说前几天,还和客户就需求上发生分岐. 我简单看了看需求表,开发文档,测试报告等都不是很完善.

4. 各种项目的原因现在让开发团队成员都非常大的压力,原项目经理负荷过重,从心理和身体都受很大压力. 提出退出开发团队.

5.此原项目经理在短时期内可协助向新团队说明情况.

6.原团队好的人员,有一些,但不多.系统观念的人员应该还欠缺一些.估计需要补充一点.但也担心人月神话所说,新加入人经验不足的员人反而会拖累进度.

7. 语言开发环境应该没有什么问题.我还没有深入了解.毕竟我才收到通过几小时后就下斑了, 下周一会估计会更清楚.

[/B]
重点好像还是在需求

为什么需求没有搞好呢？！业务背景深度不够？
亭华龙哥 亭华龙哥 发布于2007-07-21 23:27:39

QUOTE:

最初由 小辉 发布
[B]


重点好像还是在需求

为什么需求没有搞好呢？！业务背景深度不够？ [/B]
具体重点在哪里,下周一具体了解一下才清楚.

我想先向大家请教些经验和做法,好方便下周开展讨论和制定新的方案
yining的个人空间 yining 发布于2007-07-22 00:09:50
1、问开发语言和环境的原因，在于让你了解是否存在切换环境可以提高工作效率的可能。
2、开发延期的原因有很多，不过我觉得你目前最需要了解的有以下几个方面：

a、需求是否符合用户要求
b、是否做过需求紧急程度排序
c、架构是否适合需求
d、采用技术是否适合团队，即采用技术是否团队所熟悉并掌握的
e、开发语言及环境是否适合团队
f、团队成员之间是否存在配合问题

建议你尽快做到两件事情：
1、确定用户需求并确定需求顺序
2、尽快找到技术领军人物，即使需要空降兵，并在其协助下确定当前架构是否适合团队及项目，如果不适合，尽快确定设计方案

不要因为工期短而不去更改需求，有必要的话一定要有壮士断腕的勇气，要敢于放弃一切。
亭华龙哥 亭华龙哥 发布于2007-07-22 00:15:31

QUOTE:

最初由 yining 发布
[B]1、问开发语言和环境的原因，在于让你了解是否存在切换环境可以提高工作效率的可能。
2、开发延期的原因有很多，不过我觉得你目前最需要了解的有以下几个方面：

a、需求是否符合用户要求
b、是否做过需求紧急程度排序
c、架构是否适合需求
d、采用技术是否适合团队，即采用技术是否团队所熟悉并掌握的
e、开发语言及环境是否适合团队
f、团队成员之间是否存在配合问题

建议你尽快做到两件事情：
1、确定用户需求并确定需求顺序
2、尽快找到技术领军人物，即使需要空降兵，并在其协助下确定当前架构是否适合团队及项目，如果不适合，尽快确定设计方案

不要因为工期短而不去更改需求，有必要的话一定要有壮士断腕的勇气，要敢于放弃一切。 [/B]
多谢
yining的个人空间 yining 发布于2007-07-22 00:23:02
笔误，不是“不要因为工期短而不去更改需求”，而是不要因为工期短而不敢去做更改。
小青蛙的个人空间 dearmeiw 发布于2007-07-22 00:51:28
YI公公，没有PLMM的照片千万别说啊，呵呵……
lodge发布于2007-07-22 09:03:55
先弄清楚现状是非常重要的.

QUOTE:

最初由 亭华龙哥 发布
[B]
2.从需求功能表看,完成(第一期)不足一半,或更少..并测试结果表明,这一半也BUG比较多,还存在影响系统级的BUG
[/B]
- 对完成的一半所进行的测试是什么级别的测试?(单体还是结合)
- 测试的覆盖率有多少, 也就是说1000代码行测试多少项目?
从上述问题的回答可以分析出, 以完成部分的残留作业有多少.
另外, 还需要知道现在团队的生产性, 也就是单位时间内代码制作行数和文档资料的做成页数. 知道了这些, 对于未对应的一半就能够基本估算出所要的时间勒.

QUOTE:

最初由 亭华龙哥 发布
[B]
3.原项目经理负责与客户需求分析的主持, 听说前几天,还和客户就需求上发生分岐. 我简单看了看需求表,开发文档,测试报告等都不是很完善.
[/B]
这个好像除了明确需求式样以外木有啥高招, 只有确定的勒需求, 才能针对用户的变更要求, 提出预算和计划的修改. 另外, 需求尚未明确也不完全是坏事, 因为还有去掉一些不重要的需求以保证工期的可能性. 至于如何同客户进行交涉, 那是谈判艺术的问题, 可以求助于营业人员或者公关人员. 可以先为各项需求做出优先次序, 然后表示会尽力完成所有的要求. 最后, 诚恳地表示如果实在不能完成, 则会考虑把一些优先度低的要求放到下次开发完成, 或者在交付之后, 在考虑对应. 这种做法一般都可以得到客户的理解.

QUOTE:

最初由 亭华龙哥 发布
[B]
4. 各种项目的原因现在让开发团队成员都非常大的压力,原项目经理负荷过重,从心理和身体都受很大压力. 提出退出开发团队.
[/B]
这个可能跟他的工作方法有关. 需要确认的是团队成员的心理现状, 如果和他们的PL一样, 就需要设法调节勒.

QUOTE:

最初由 亭华龙哥 发布
[B]
5.此原项目经理在短时期内可协助向新团队说明情况.

6.原团队好的人员,有一些,但不多.系统观念的人员应该还欠缺一些.估计需要补充一点.但也担心人月神话所说,新加入人经验不足的员人反而会拖累进度.
[/B]
新人员加入是会影响进度, 但是不加入进度同样无法保证. 只要做好人力投入的预算和计划还是有希望保证的.

最近您老人家估计会很累, 保重身体哦
bodyguard发布于2007-07-22 10:01:10
1：中途接管接管半死不活的软件项目，通常没有好果子吃。
2：主要看你的人脉，按重要性高低如下排序
  A：能不能摸清或揣摩公司的底线，     ======> 心中有数
  B：能不能摸清客户最优先的&最小的需求 =====》实现他
  C：项目本身的问题
  做好A，B一般来说这个项目场面上甲方、乙方都能过得去。你不仅能自保、还有成绩。
3：其他的都是扯淡或低优先级的。你陷进去的结果可能是连自保都难。
厚积薄发 husthxd 发布于2007-08-01 22:04:10
不知道LZ目前进展如何了？
这种情况下该考虑：
1.追加资源：加入系统分析员和技术N人，增加人手初期的时候可能会有点混乱，但慢慢的就会有序起来，这个，就得靠LZ的努力了
2.裁减范围：与客户协商上线的功能模块，迭代开发，分段上线。
厚积薄发 husthxd 发布于2007-08-01 22:16:27

QUOTE:

最初由 lodge 发布
[B]先弄清楚现状是非常重要的.


测试的覆盖率有多少, 也就是说1000代码行测试多少项目?
从上述问题的回答可以分析出, 以完成部分的残留作业有多少.
另外, 还需要知道现在团队的生产性, 也就是单位时间内代码制作行数和文档资料的做成页数. 知道了这些, 对于未对应的一半就能够基本估算出所要的时间勒.


[/B]
这种测试方式有点太教科书了点把？统计“单位时间内代码制作行数和文档资料的做成页数”，感觉有点浪费时间和精力。其实，文档如果要求不是特别严格的话，个人认为，有STR和SRS这两份文档，配合一系列的Demo和Guide就已经足够了。
btw:
开发团队中，QA实在是太重要了，但找一个既会点技术，又精通测试，熟悉需求的测试人员实在是太难了。有时候只能又精通需求的SA去做测试工作。
lodge发布于2007-08-01 22:33:31

QUOTE:

最初由 husthxd 发布
[B]

这种测试方式有点太教科书了点把？统计“单位时间内代码制作行数和文档资料的做成页数”，感觉有点浪费时间和精力。其实，文档如果要求不是特别严格的话，个人认为，有STR和SRS这两份文档，配合一系列的Demo和Guide就已经足够了。
btw:
开发团队中，QA实在是太重要了，但找一个既会点技术，又精通测试，熟悉需求的测试人员实在是太难了。有时候只能又精通需求的SA去做测试工作。 [/B]
统计生产性很容易呀, 偶们有一个生产管理系统, 可以持续地统计生产性, 每个人只需要每周做一次周报, 数据就被录到系统上去勒, 随时可以查到.

BTW, 偶们木有使用QA. 而是培养了一只测试队伍, 他们是偶们公司产品质量的保障.

另外, 文档资料也并非只是一个项目的技术资料, 它是一个公司开发经验的积累, 虽然对一个项目来说, 没有大量的文档资料也可能完成, 但是下一个项目的开发就难以百尺杆头更进一步, 特别是在木有足够文档资料的条件下, 项目的经验就成了个人的财富, 对公司来说则损失掉了一大笔无形的资产.

厚积薄发 husthxd 发布于2007-08-01 22:40:06

QUOTE:

最初由 lodge 发布
[B]

统计生产性很容易呀, 偶们有一个生产管理系统, 可以持续地统计生产性, 每个人只需要每周做一次周报, 数据就被录到系统上去勒, 随时可以查到.

BTW, 偶们木有使用QA. 而是培养了一只测试队伍, 他们是偶们公司产品质量的保障.
[/B]
你们做产品？幸福。

做软件开发的，就该做做产品，可以静下心来思考一些方向性和很技术性的问题。tmd，做项目时间紧，任务重，需求变化太快，人也变得浮躁，自然就不想钻研了。
lodge发布于2007-08-01 22:42:34

QUOTE:

最初由 husthxd 发布
[B]

你们做产品？幸福。

做软件开发的，就该做做产品，可以静下心来思考一些方向性和很技术性的问题。tmd，做项目时间紧，任务重，需求变化太快，人也变得浮躁，自然就不想钻研了。 [/B]
做产品很枯燥的, 开始还挺新鲜的, 到了后来, 就成了在原来的代码上小打小闹的, 没啥意思啦.
厚积薄发 husthxd 发布于2007-08-02 12:09:08

QUOTE:

最初由 lodge 发布
[B]

做产品很枯燥的, 开始还挺新鲜的, 到了后来, 就成了在原来的代码上小打小闹的, 没啥意思啦. [/B]
呵呵，那说明产品已经做完了
lodge发布于2007-08-02 12:50:40
新品开发一般都要大量继承已有产品的设计和工艺，真正要开发的部分少得可怜。
flaming_tower的个人空间 flaming_tower 发布于2007-08-02 12:54:13
如果是人的原因
赶紧找台阶
准备跑路
flaming_tower的个人空间 flaming_tower 发布于2007-08-02 13:05:07
如果楼主还没有接手这个项目的话
千万不要接
要是你接了，基本上死定了
厚积薄发 husthxd 发布于2007-08-02 14:25:17

QUOTE:

最初由 flaming_tower 发布
[B]如果楼主还没有接手这个项目的话
千万不要接
要是你接了，基本上死定了 [/B]
危难处，才显英雄本色。
结论不要下得太早了。
厚积薄发 husthxd 发布于2007-08-02 14:26:06

QUOTE:

最初由 lodge 发布
[B]新品开发一般都要大量继承已有产品的设计和工艺，真正要开发的部分少得可怜。 [/B]
二次开发？创造性不足，那，还是算了吧。
flaming_tower的个人空间 flaming_tower 发布于2007-08-02 14:29:54

QUOTE:

最初由 husthxd 发布
[B]

危难处，才显英雄本色。
结论不要下得太早了。 [/B]
英雄是那么好当的！！！

英雄没见过几个
死鬼和炮灰倒是见过一堆
厚积薄发 husthxd 发布于2007-08-02 15:49:20

QUOTE:

最初由 flaming_tower 发布
[B]

英雄是那么好当的！！！

英雄没见过几个
死鬼和炮灰倒是见过一堆 [/B]
风险与机遇并存。
引用鲁迅先生的一句话：真正的勇士，敢于直面惨淡的人生。
bodyguard发布于2007-08-02 19:11:43
捧场的都当了着急的太监，LZ当了次皇帝。
LZ该站出来说句话。
lodge发布于2007-08-02 22:52:02

QUOTE:

最初由 husthxd 发布
[B]

二次开发？创造性不足，那，还是算了吧。 [/B]
如果继承的部分不能达到95%, 就达不到CMM5的质量标准.
厚积薄发 husthxd 发布于2007-08-03 09:52:13

QUOTE:

最初由 lodge 发布
[B]

如果继承的部分不能达到95%, 就达不到CMM5的质量标准. [/B]
说起这个CMM，有本书上倒是说得很对：
CMM把“人”这个最为关键的因素撇开，只是告诉你流程中何时做什么，不做什么，解决了WHAT，但它根本不会告诉你该如何做（HOW），尤其是其中对人（WHO）的要求只字不提。不过，这其实也是一个很好的切入点，把软件开发简单抽象化。
我来说两句

(可选)

日历

« 2008-07-24  
日 一 二 三 四 五 六
  12345
6789101112
13141516171819
20212223242526
2728293031  

数据统计

  • 访问量: 1695
  • 日志数: 77
  • 建立时间: 2007-12-29
  • 更新时间: 2008-07-22

RSS订阅

Open Toolbar