[项目管理]弱势项目管理与技术牛人的对抗问题

下面是来自水木社区软工板块上的一个讨论，比较有典型性，所以，重发在这里。

发信人: redolence (雷德隆…还有一个斯), 信区: SoftEng

标 题: 很棘手的问题，求解。

发信站: 水木社区 (Sat Nov 14 15:13:29 2009), 站内

关于项目管理的

项目开发了一半，项目组加入一位牛人，于是发生了这些事：

1.大牛说原来写的代码效率不高，构架繁冗，不方便后期维护，要求重构代码和数据库。

2.老成员认为自己辛苦写的代码被一票否决，心里很不爽，但是也承认自己的代码质量不高。

3.我作为项目负责人，在牛人加入前已经汇报了一次项目开发进度，并已经演示了系统功能。已开发部分的功能已经被用户接受并认可，且用户至少目前没有提出对性能的要求，但是预计将来会提到这个问题。到时候再重构，会更加麻烦。

4.领导认为我们的进度已经落后于计划，急需完成剩余部分功能的开发。在我演示了系统功能之后，已经申请了一次计划调整，基本得到用户的理解。

问题是：

1.如果系统重构，很有可能需要再次调整计划，而用户已经明确表示计划是不可能再调整的了。

2.大牛在技术上没有问题，但是缺乏时间观念，且身兼多个项目，重构速度令人失望。

3.老成员一开始挺配合系统重构，但是随着重构的深入，发现难度很大，基本等于重新开发。对大牛很有意见，开始不怎么配合了。

请问，作为项目负责人，这个怎么办？



发信人: qingrun (青润), 信区: SoftEng

标 题: Re: 很棘手的问题，求解。

发信站: 水木社区 (Sat Nov 14 16:06:46 2009), 站内

似乎算是个典型案例了，一个鲁莽但是经验丰富的技术人员，粗鲁的忽视了开发进度和客户需求，进行单方面技术改进的要求，公司因为项目款项回收速度慢而指责团队开发进度，一个无奈的弱势项目经理缺乏经验几乎无法处理全部问题。呵呵

如果是我，会根据情况进行操作：

1、资源不紧张，则安排牛人的方法进行同步开发推动，原有团队继续原来的进度开发，牛人参与一些审核工作，同时进行他的第二个版本的开发。

2、资源紧张，安排牛人的方法放在二期（第二个版本），他本人必须跟进原来的开发模式参与审核，如果拒绝则进行疏导或者请其本人单独先进性第二版本开发，原有团队进度不变。

【 在 redolence (雷德隆…还有一个斯) 的大作中提到: 】

: 关于项目管理的

: 项目开发了一半，项目组加入一位牛人，于是发生了这些事：

: 1.大牛说原来写的代码效率不高，构架繁冗，不方便后期维护，要求重构代码和数据库。

: ...................

发信人: redolence (雷德隆…还有一个斯), 信区: SoftEng

标 题: Re: 很棘手的问题，求解。

发信站: 水木社区 (Sat Nov 14 16:20:50 2009), 站内

那大牛曾说可以在一周之内重构完毕，且说计划中分配给他的功能模块时间有冗余，肯定不会影响开发进度，但是就同意了大牛的意见，团队停止开发新功能，由他主导负责重构。

但是由于他的另一个项目的计划也很紧张，且另一个项目的负责人也是我的领导，我在争夺资源上处于劣势。所以大牛只有不到50％的精力参与其中。

现在一周已经过去，重构工作完成1/4，大牛坚持说不会影响进度，后面的功能模块用不了那么长的时间。作为项目负责人，我觉得这个风险很大，所以有点灰心了。

【 在 qingrun (青润) 的大作中提到: 】

似乎算是个典型案例了，一个鲁莽但是经验丰富的技术人员，粗鲁的忽视了开发进度和客户需求，进行单方面技术改进的要求，公司因为项目款项回收速度慢而指责团队开发进度，一个无奈的弱势项目经理缺乏经验几乎无法处理全部问题。呵呵

如果是我，会根据情况进行操作：

1、资源不紧张，则安排牛人的方法进行同步开发推动，原有团队继续原来的进度开发，牛人参与一些审核工作，同时进行他的第二个版本的开发。

2、资源紧张，安排牛人的方法放在二期（第二个版本），他本人必须跟进原来的开发模式参与审核，如果拒绝则进行疏导或者请其本人单独先进性第二版本开发，原有团队进度不变。

【 在 redolence (雷德隆…还有一个斯) 的大作中提到: 】

: 关于项目管理的

: 项目开发了一半，项目组加入一位牛人，于是发生了这些事：

: 1.大牛说原来写的代码效率不高，构架繁冗，不方便后期维护，要求重构代码和数据库。

: ...................

发信人: qingrun (青润), 信区: SoftEng

标 题: Re: 很棘手的问题，求解。

发信站: 水木社区 (Sat Nov 14 17:50:59 2009), 站内

我
上面这样说就是因为我很清楚大牛为什么会如此提出他的考虑，即使他一个星期可以重构完毕，重构结束后的新架构其他技术人员是否能够适应，是否能够尽快上手
进行开发和补充修订，这都是问题。不是说，他认为一个星期完毕，就如何如何，一个项目的风险不能依靠一个人来解决，那样，他个人就成了整个项目最大的风
险，一旦他生病，住院，出车祸，难道说，他就可以保证自己100%不会发生意外么？这些生活中的意外都不可避免，项目中也可能会有他没有评估到的地方。

从你的回答中看出来，你的经验实在太少了，你应该去看看人月神话，人件，人件集，死亡之旅这几本书，就能明白我为什么会有上面的两种建议。

即使对于微软这种大公司，他们的新产品核心架构的推出都是需要分阶段的，也不是一次性完成的。

你们这位大牛的做法其实是集中了风险应力点，一旦这个风险发生，项目就会直接终止，他的建议最多适用于第二版本开发或者公司资金资源剩余情况下的产品化开发。项目，尤其是工程项目，应该考虑的是分散风险，降低风险，而不是风险集中。

【 在 redolence (雷德隆…还有一个斯) 的大作中提到: 】

: 那大牛曾说可以在一周之内重构完毕，且说计划中分配给他的功能模块时间有冗余，肯定不会影响开发进度，但是就同意了大牛的意见，团队停止开发新功能，由他主导负责重构。

: 但是由于他的另一个项目的计划也很紧张，且另一个项目的负责人也是我的领导，我在争夺资源上处于劣势。所以大牛只有不到50％的精力参与其中。

: 现在一周已经过去，重构工作完成1/4，大牛坚持说不会影响进度，后面的功能模块用不了那么长的时间。作为项目负责人，我觉得这个风险很大，所以有点灰心了。

: ...................

发信人: redolence (雷德隆…还有一个斯), 信区: SoftEng

标 题: Re: 很棘手的问题，求解。

发信站: 水木社区 (Sat Nov 14 19:46:33 2009), 站内

确实没有经验，第一个负责的项目

谢谢回复，学习了。

【 在 qingrun (青润) 的大作中提到: 】

我
上面这样说就是因为我很清楚大牛为什么会如此提出他的考虑，即使他一个星期可以重构完毕，重构结束后的新架构其他技术人员是否能够适应，是否能够尽快上手
进行开发和补充修订，这都是问题。不是说，他认为一个星期完毕，就如何如何，一个项目的风险不能依靠一个人来解决，那样，他个人就成了整个项目最大的风
险，一旦他生病，住院，出车祸，难道说，他就可以保证自己100%不会发生意外么？这些生活中的意外都不可避免，项目中也可能会有他没有评估到的地方。

从你的回答中看出来，你的经验实在太少了，你应该去看看人月神话，人件，人件集，死亡之旅这几本书，就能明白我为什么会有上面的两种建议。

即使对于微软这种大公司，他们的新产品核心架构的推出都是需要分阶段的，也不是一次性完成的。

你们这位大牛的做法其实是集中了风险应力点，一旦这个风险发生，项目就会直接终止，他的建议最多适用于第二版本开发或者公司资金资源剩余情况下的产品化开发。项目，尤其是工程项目，应该考虑的是分散风险，降低风险，而不是风险集中。

【 在 redolence (雷德隆…还有一个斯) 的大作中提到: 】

: 那大牛曾说可以在一周之内重构完毕，且说计划中分配给他的功能模块时间有冗余，肯定不会影响开发进度，但是就同意了大牛的意见，团队停止开发新功能，由他主导负责重构。

: 但是由于他的另一个项目的计划也很紧张，且另一个项目的负责人也是我的领导，我在争夺资源上处于劣势。所以大牛只有不到50％的精力参与其中。

: 现在一周已经过去，重构工作完成1/4，大牛坚持说不会影响进度，后面的功能模块用不了那么长的时间。作为项目负责人，我觉得这个风险很大，所以有点灰心了。

: ...................

发信人: qlw (钱五哥), 信区: SoftEng

标 题: Re: 很棘手的问题，求解。

发信站: 水木社区 (Sat Nov 14 20:49:19 2009), 站内

同意qingrun的说法，我看到这个案例后的第一反应就是将大牛的方案

放入下个版本，不影响本次开发，但是在接下来的开发中要考虑到大牛

的建议，便于将代码重用到下个版本，同时也让项目组成员逐步熟悉

并思考新方案。

另外，软件项目的PM是需要明白技术的，至少能够估计到工作量，大牛

再牛，也有估计不到的地方，更何况还有时间问题。

【 在 qingrun (青润) 的大作中提到: 】

: 我上面这样说就是因为我很清楚大牛为什么会如此提出他的考虑，即使他一个星期可以重构完毕，重构结束后的新架构其他技术人员是否能够适应，是否能够尽快上手进行开发和补充修订，这都是问题。不是说，他认为一个星期完毕，就如何如何，一个项目的风险不能依靠一个人来解

: 从你的回答中看出来，你的经验实在太少了，你应该去看看人月神话，人件，人件集，死亡之旅这几本书，就能明白我为什么会有上面的两种建议。

: 即使对于微软这种大公司，他们的新产品核心架构的推出都是需要分阶段的，也不是一次性完成的。

: ...................

发信人: qingrun (青润), 信区: SoftEng

标 题: Re: 很棘手的问题，求解。

发信站: 水木社区 (Sat Nov 14 21:33:02 2009), 站内

五
哥，我觉得，项目经理如果不懂得技术，也可以做好项目经理，那就需要更好的态度和更多的配合和询问，更多的增加内部的交流，但是，他必须有足够的逻辑判断
能力，而不能糊涂，毕竟项目经理要负责整个项目的成败，失败了，他应该是责任承担者，绝对不能推卸责任。这样的项目经理我定义为弱势项目经理，和强势项目
经理相对，也就是非技术主导形态的项目经理存在方式。

强势项目经理可以在一些判断中，先下结论执行后解释，而若是项目经理永远要以解释和讨论为主
导，后下结论或者说后执行。这样的形态，加上好的态度，也一样可以很好的控制项目的进度——我05年-06年在中科院自动化所模式识别实验室的角色，就是弱势项目经理的做法，毕竟不是我所长的传统工程软件的开发技术，最后的效果还是很不错的，呵呵。

【 在 qlw (钱五哥) 的大作中提到: 】

: 同意qingrun的说法，我看到这个案例后的第一反应就是将大牛的方案

: 放入下个版本，不影响本次开发，但是在接下来的开发中要考虑到大牛

: 的建议，便于将代码重用到下个版本，同时也让项目组成员逐步熟悉

: ...................

: 另外，软件项目的PM是需要明白技术的，至少能够估计到工作量，大牛

: 再牛，也有估计不到的地方，更何况还有时间问题。

发信人: qlw (钱五哥), 信区: SoftEng

标 题: Re: 很棘手的问题，求解。

发信站: 水木社区 (Sun Nov 15 02:55:55 2009), 站内

不反对你的提法，是有各种类型的软件项目经理。能管理好一个

软件项目，有两大要求，一是要思路清晰，善于交流沟通，二是要明白

具体技术要求，从技术性较弱的开发流程技术到技术性较强的开发

技术。我见过各种PM，思路清晰和善于交流是最为重要的，明白技术

并非最为重要，但是在项目时间紧、风险高的项目中，技术能力

强的PM更能把控项目的进度、人员安排和风险。

【 在 qingrun (青润) 的大作中提到: 】

: 五哥，我觉得，项目经理如果不懂得技术，也可以做好项目经理，那就需要更好的态度和更多的配合和询问，更多的增加内部的交流，但是，他必须有足够的逻辑判断能力，而不能糊涂，毕竟项目经理要负责整个项目的成败，失败了，他应该是责任承担者，绝对不能推卸责任。这样的

:
强势项目经理可以在一些判断中，先下结论执行后解释，而若是项目经理永远要以解释和讨论为主导，后下结论或者说后执行。这样的形态，加上好的态度，也一样
可以很好的控制项目的进度——我05年-06年在中科院自动化所模式识别实验室的角色，就是若是项目经理的做法，毕竟�

发信人: qingrun (青润), 信区: SoftEng

标 题: Re: 很棘手的问题，求解。

发信站: 水木社区 (Sun Nov 15 11:39:28 2009), 站内

是的，技术的强弱有时候是有促进作用的，前提是PM头脑清晰，不陷入自己对自己的过度信任中。

我这么提也主要是为了反驳国内曾经一度十分盛行的所谓项目经理必须懂技术甚至必须是这一行业技术高手的说法和认识。呵呵

【 在 qlw (钱五哥) 的大作中提到: 】

: 不反对你的提法，是有各种类型的软件项目经理。能管理好一个

: 软件项目，有两大要求，一是要思路清晰，善于交流沟通，二是要明白

: 具体技术要求，从技术性较弱的开发流程技术到技术性较强的开发

: ...................