Java开发网 - 项目经理与程序大拿的对话.

Topic: 项目经理与程序大拿的对话.

1.项目经理与程序大拿的对话.

Posted by: softtiger
Posted on: 2003-11-21 11:51

人员介绍: 项目经理,某小公司项目负责人,完成W项目的研发工作,并转入X项目约三个月后.工作年限八年
程序员: X项目的维护和修改人员,进入公司后一直做这方面的工作(号称这方面的大拿),工作年限一年,在校期间一直从事项目开发.

背景: X项目某程序一直性能有问题,项目经理看了看代码,上周末出份计划,让程序员本周二先出测试报告,再根据测试报告修改程序.
周四项目经理查看测试报告,于是有了下面的对话. 大家有何感想,请发言.

项目经理:测试数据怎么波动很大啊？而且有两项数据并没包含进去
程序员:本来就是这样，程序这样啊.哪里得数据已经够了，要别的干什么，都知道慢得原因了

项目经理:项目计划中的数据有两项你没给出（我已说过了，我只看报告，不看程序）
测试数据本身有问题。
程序员:这个本来就没有问题，觉得有问题，自己测阿

项目经理:搞笑，你必须提供项目计划中的要求的测试项。当然，你也可以直接向技术总监说，
程序员:是啊，你不是不看程序吗，那干什么指示一些这种东西出来

项目经理:那是我的事，不是你管我，而是我管你。若有意见直接向技术总监提。
你报告的axxxx执行时间有几个波动很大，能告诉我原因吗？
程序员: 算了吧，自己大答不上了，本来我来分析，我自己会慢慢研究瓶颈在哪里，错的东西我干什么听你的，瓶颈我找到了，我也知道怎么改了
程序员:可以阿，和播控的程序有关，他用的轮询方式处理的，所以波动大

项目经理:改程序不是你想改就改了，你以为是你写程序玩啊？公司是支付薪资的，
所以你不能想怎么就怎么。
程序员:那你又不看程序，就这样说，我测的数据又不相信，自己去做罗，我又什么办法

项目经理:我要的是项目计划中说明的数据。你想要其它数据不是不可以，但那是你自己的事
那bbbxxx的波动大原因是啥？
程序员:你要得数据就看表面，有屁用.不是xxx,是信号等待，也是一样的原因，苯

2.Re:项目经理与程序大拿的对话. [Re: softtiger]	Copy to clipboard
Posted by: chenggn Posted on: 2003-11-25 18:23 两个人交往能力都不行

3.Re:项目经理与程序大拿的对话. [Re: softtiger]

Copy to clipboard

Posted by: yj780210
Posted on: 2003-11-26 09:13

交流中最重要的沟通没有做好，同时两人不象是在搞项目，也没有正确的敬业精神。我觉得两个人是在怄气。两个小孩子在打架。

不过我觉得开始还是所谓的“大拿”错的多，毕竟要尊敬项目经理，同时要呈现自己的工作结果，而不是凭所谓的“我以为”。

如果我是高层，我会对项目经理进行教育，改进他的工作态度问题。同时引进新的技术人员，在可以的情况下，第一时间把“大拿”开除。避免这种情绪在程序员中间扩散。

要研究他这种情绪是如何产生的，同时检讨和改进工作。

4.Re:项目经理与程序大拿的对话. [Re: softtiger]

Copy to clipboard

Posted by: collins
Posted on: 2003-11-26 09:35

我觉得是项目经理的问题，项目中沟通不畅，项目经理绝对需要负最大责任，因为他就是做这些项目管理的事情的。
从此事中可以看出，项目经理对系统并不是很熟，最熟悉的是“大拿”，那么在做计划的时候，应该尊重他的技术特长，与之一起讨论测试方案，甚至如果他有时间可以让他来做，自己参与讨论即可。
而且从谈话中，项目经理并没有试图说服大拿，而只是强调自己的权威，说什么什么数据必须测试，大拿的意见得不到尊重，必然造成争吵。就算强迫大拿做了，长此下去，他必然走人，根本不会等到如楼上所说的第一个炒掉他，他能成为大拿，技术上必然有其长处。

5.Re:项目经理与程序大拿的对话. [Re: softtiger]

Copy to clipboard

Posted by: softtiger
Posted on: 2003-11-26 12:45

看到大家的发言很高兴啊.总算有人对管理问题感兴趣了.

还有三个问题很令人头疼.
1.小公司里,由于资源的限制,组员一般开发经验不足,基本上在代码实现上还过的去,分析设计能力基本不行.这种情况下,做甩手掌管的话,很难保证项目的质量;监管技术的话,又精力不足,容易陷入细节并引发矛盾.
2.项目计划的视角问题: 项目经理着眼的是程序哪块有问题,以此估算资源的分配.而程序员则着眼于具体在哪个语句或算法上有问题,那上面的例子,倒底要出哪个视角的测试计划啊?
3.是工作态度重要,还是项目计划的正确性重要.程序员是否只要认为项目计划有问题,就可以不与项目经理讨论,就按自己的看法做.

6.Re:项目经理与程序大拿的对话. [Re: softtiger]

Copy to clipboard

Posted by: collins
Posted on: 2003-11-26 14:08

很久不理这种话题了，在国内，项目管理职业化程度较低，没有什么意思，今日性之所致，随便聊聊，只是自己的偏见，呵呵
问题一：几乎没有特别好的办法，一个意见是利用集体的力量，发挥大家的积极性，分工设计，集体讨论，当然是挑技术较好的人来设计。适用于对技术要求不太高的项目。
问题二：测试计划？你想说的是计划安排吧？
问题三：我觉得人最重要，管理是辅助，为人服务的，当然和组员素质也有很大关系。

7.Re:项目经理与程序大拿的对话. [Re: softtiger]

Copy to clipboard

Posted by: yj780210
Posted on: 2003-11-27 09:42

一家之言，我也讨论一下。
我觉得该文的上级领导能力不够，一个资深项目经理管理的项目必定是重要的大项目，在这样的项目中，一个大学毕业一年的人当核心程序员“大拿”，我觉得简直是开玩笑。

我觉得主要问题在程序员，同时项目经理也有责任的原因是：
公司指派的项目经理一定是具有项目管理和沟通管理的能力的。但是在这个项目中，很明显，沟通和项目计划上发生了问题。项目经理是必然有责任的。同时在发生问题的时候，他居然说出“和技术总监说”这种话，本身就显示了他的责任心不够或者管理经验不足。（技术“总”监应该比他位置高）。有事情向上推，这个是我们普遍的毛病，应该负担起责任来。
另外这个项目的计划应该也是有问题的，由于信息不足，不做讨论了。

现在说说程序员，一个大学毕业一年的人，有什么资格叫“大拿”？这点我很有点疑问。会一点点东西，就这么骄傲，不把公司的管理和制度放在眼力，这样的人是不应该有生存空间的。同时他的这种情绪，如果扩散开来，会对项目造成致命的影响。他极度不尊重项目经理，一个有多年工作和管理经验的人。如果项目经理的权威在他的这种挑衅下荡然无存，那么这个项目必然会失败，因为别的人也会一样的怀疑他。时间就会在无谓的挑战中浪费。

一个毕业一年的人，找人替代很容易。另外一个好的项目组，人员层次必定是清晰的。内部就应该可以替代。
如果是核心程序员开发模式，那么这样在态度责任和沟通上都有问题的核心，就算是技术再好，这个项目也基本就算失败了。因为凭他这个态度，如果项目成功的话，他一定会以为是他自己的个人功劳。从而失去了一个团队。我觉得——一定要开除！

我的想法和做法历来都比较偏激，呵呵，不过有的时候必须要采用比较激烈的手段，特别是在项目的关键期间。

softtiger wrote:
1.小公司里,由于资源的限制,组员一般开发经验不足,基本上在代码实现上还过的去,分析设计能力基本不行.这种情况下,做甩手掌管的话,很难保证项目的质量;监管技术的话,又精力不足,容易陷入细节并引发矛盾.

我觉得大局和细节之间，项目经理应该主管大局。至于细节，应该发挥大家的能力和智慧，必要的时候可以发挥学习能力，当然，在风险分析的时候就应该想到。

2.项目计划的视角问题: 项目经理着眼的是程序哪块有问题,以此估算资源的分配.而程序员则着眼于具体在哪个语句或算法上有问题,那上面的例子,倒底要出哪个视角的测试计划啊?

测试必须是完美的，单元测试是针对程序员的，模块和系统是针对项目经理的。同时要保证项目进行期间随时测试，随时更改。同时要尽量避免程序员的过度优化，有的程序员喜欢精益求精，但是我觉得，特别是效率上，只要过的去就可以了。

3.是工作态度重要,还是项目计划的正确性重要.程序员是否只要认为项目计划有问题,就可以不与项目经理讨论,就按自己的看法做.

绝对不可以，首先，计划的制定不是项目经理一个人说的算。要大家一起来，这样制定出来的计划才比较合理也比较容易被大家接受。程序员按照自己的想法做是大忌，团队里是没有个人英雄主义的。从团队的角度和产品的角度来看，一个核心程序员和文档编写人员的作用和功劳是一样的。有很多时候，好的文档比优秀的程序更重要。
有了好的计划，就要坚决的执行。同时需要良好的工作态度。由于一般项目是一个短期的工作，所以没有时间去培养一个人的涵养和态度。如果是短时间的问题，可以通过沟通来解决。如果根本就是本性难移，对不起，走！这个也和开始项目的选人有关。
当然我知道，我说的都是比较理想的情况，资源，上级的支持，往往都不足，不能在人力上做调换。这个时候，我的看法是，为了保证项目的进度和成功，要适当加大压力，采取高压政策。管他，俗话说就是“收拾他”。：）有这种人，不收拾服了不行。呵呵。

一家之言，略带偏激，当然，在实际工作的时候是要审时度势的。

8.Re:项目经理与程序大拿的对话. [Re: softtiger]

Copy to clipboard

Posted by: softtiger
Posted on: 2003-11-27 11:01

嗯,说的都挺有道理的.现在的情况是:经技术总兼做了工作,程序员道了谦,项目经理也谦虚了几句,事后项目经理请项目组眯西了眯西,希望就此化干戈为玉帛.
另有两点考虑:
1.争取引入一资深分析设计人员,来协助项目经理,让项目经理把经历放到计划与控制及协调工作上.
2.大家都提到方案的集体讨论,实际工作中常会出现下面两种情况,不知大家是如何处理的.
a.分析设计人员水平都还可以(相互间水平有差距,但还不到差好几个等级的程度),结果各拿一套,你不服我,我不服你.
b.有一个资深的人员,其他是程序员,结果前者的方案得不到大多数人的支持.(有些好的设计方案,程序员并不一定能理解,认为多此一举,而且解释也不一定能解释的明明白白,分析设计多少要靠个人的悟,不是翻翻书就ok的),此时若力排众议,项目计划执行时,会不会仍然产生矛盾.

9.Re:项目经理与程序大拿的对话. [Re: softtiger]	Copy to clipboard
Posted by: yj780210 Posted on: 2003-11-27 13:25 项目经理的工作了。管理，不是让大家用技术比武。

10.Re:项目经理与程序大拿的对话. [Re: softtiger]

Copy to clipboard

Posted by: frankjin
Posted on: 2003-12-06 06:48

案例不够具体.不好妄加评论. 不过我觉的communication非常重要,这个问题的出现原因主要不是技术,而是项目开发中的沟通问题.这也是很多公司做项目考虑最弱的地方.而往往最大的风险就源自与此.沟通不是吃顿饭,互相拍马屁就ok,是个很复杂的学问(这里我不想深谈).不过无论是PM还是大拿如果都先替别人考虑一下的话问题可能会最小化.

11.Re:项目经理与程序大拿的对话. [Re: frankjin]

Copy to clipboard

Posted by: taogang
Posted on: 2003-12-12 09:16

frankjin wrote:
案例不够具体.不好妄加评论. 不过我觉的communication非常重要,这个问题的出现原因主要不是技术,而是项目开发中的沟通问题.这也是很多公司做项目考虑最弱的地方.而往往最大的风险就源自与此.沟通不是吃顿饭,互相拍马屁就ok,是个很复杂的学问(这里我不想深谈).不过无论是PM还是大拿如果都先替别人考虑一下的话问题可能会最小化.

的确是个复杂的问题，不过我倒是不认为吃饭或者拍马屁不能解决这个问题，PM的方式方法最主要是要适应团队的水平或者说结构，因为最终目的不是仅仅为了提高管理水平去管理，而是为了提高团队的生产效率，最终带来经济效益。有的时候能够产生明确结果的简单手段，比理论来的更加有效。

12.Re:项目经理与程序大拿的对话. [Re: softtiger]

Copy to clipboard

Posted by: wood
Posted on: 2003-12-12 13:21

这样的项目经理，这样的公司，有什么前途，赶紧走人，别把自己给耽误啦。这个程序员还算是给项目经理操心，如果就按他的计划做，对谁有好处？
项目经理到底应该负责什么，应该有多大的局需要他把握？程序员应该负责什么？一个项目的价值体现在什么地方？

13.Re:项目经理与程序大拿的对话. [Re: wood]

Copy to clipboard

Posted by: taogang
Posted on: 2003-12-12 16:08

wood wrote:
这样的项目经理，这样的公司，有什么前途，赶紧走人，别把自己给耽误啦。这个程序员还算是给项目经理操心，如果就按他的计划做，对谁有好处？
项目经理到底应该负责什么，应该有多大的局需要他把握？程序员应该负责什么？一个项目的价值体现在什么地方？

大家都会往有前途的公司挤，可是没前途的公司依然存在。呵呵，没办法