这里接前文，不过，在这里讨论的问题出现了分支，一个是原有问题的深入，另一个是处理手段出现问题时候可能发生的激烈冲突，详细内容看下文的应答过程，应该能感受到。
13
发信人: chaobill (若我离去,后会无期), 信区: SoftEng
标 题: Re: 很棘手的问题，求解。
发信站: 水木社区 (Tue Nov 17 11:05:37 2009), 站内
一个项目里面必须有人全懂
PM 至少要懂一些项目是什么划分的
举个例子，你会让一个 IT PM 去管理一个建筑项目么？
【 在 qingrun (青润) 的大作中提到: 】
: 是的，技术的强弱有时候是有促进作用的，前提是PM头脑清晰，不陷入自己对自己的过度信任中。
: 我这么提也主要是为了反驳国内曾经一度十分盛行的所谓项目经理必须懂技术甚至必须是这一行业技术高手的说法和认识。呵呵
※ 来源:·水木社区 newsmth.net·[FROM: 211.99.222.*]
标 题: Re: 很棘手的问题，求解。
发信站: 水木社区 (Tue Nov 17 11:05:37 2009), 站内
一个项目里面必须有人全懂
PM 至少要懂一些项目是什么划分的
举个例子，你会让一个 IT PM 去管理一个建筑项目么？
【 在 qingrun (青润) 的大作中提到: 】
: 是的，技术的强弱有时候是有促进作用的，前提是PM头脑清晰，不陷入自己对自己的过度信任中。
: 我这么提也主要是为了反驳国内曾经一度十分盛行的所谓项目经理必须懂技术甚至必须是这一行业技术高手的说法和认识。呵呵
※ 来源:·水木社区 newsmth.net·[FROM: 211.99.222.*]
14
发信人: qingrun (青润), 信区: SoftEng
标 题: Re: 很棘手的问题，求解。
发信站: 水木社区 (Tue Nov 17 11:38:01 2009), 站内
这一点你错了，一个项目里面不需要有人全懂，关键在于PM如何做。呵呵
你的那种想法，六七年前我也如此考虑，后来发现，根本是没有必要的。
例子：
我， 本科学材料的，出来做软件开发，05年进入自动化所模式识别实验室做项目经理，软件架构师。后续的项目都在我手里做管理和开发，所有的项目进展都应该算是 很顺利，刚开始的一些对抗三四个月后就被化解了，到现在关系都非常好，06年7月份离开自动化所后，这些弟兄一直在和我合作到现在。
难道说我全懂么？至少两年前我都没有看到过模式识别方面的代码，也不可能懂得动态背景建模和一些高斯算法如何处理的东西，但是，我一样做好了我的角色。呵呵。
管理不是那么弱小的东西，可以这么说，随便给我一个行业的项目，我都有能力做好，因为这是一个项目管理中处理事务的手段，而不是虚夸的一种操作方法。
再 早一些，我02年8月底进入电信某设计院，10月11号就带着一个人一同去中国电信集团进行建设流程调研，四个月后我撰写的技术、业务规范一次评审通过， 得到了很高的评价，就这五个月的两篇文章就是50万。各省公司和集团的那些老大都没有认为我是个刚进入电信行业的人，才进入两个月就敢过来调研他们最核心 的业务之一，进行规范的撰写和定义。呵呵，03年3月电信集团直接打电话要求我去北京负责这个项目的实施，然后就给我办了借调，前期是非正式的，04年1 月给我办了正式借调，这在电信集团是从来没有过的，以前的正式借调都只有省市公司的，三产这类企业的员工根本不可能办理的。
【 在 chaobill (若我离去,后会无期) 的大作中提到: 】
: 一个项目里面必须有人全懂
: PM 至少要懂一些项目是什么划分的
: 举个例子，你会让一个 IT PM 去管理一个建筑项目么？
--
※ 来源:·水木社区 http://newsmth.net·[FROM: 162.105.244.*]
标 题: Re: 很棘手的问题，求解。
发信站: 水木社区 (Tue Nov 17 11:38:01 2009), 站内
这一点你错了，一个项目里面不需要有人全懂，关键在于PM如何做。呵呵
你的那种想法，六七年前我也如此考虑，后来发现，根本是没有必要的。
例子：
我， 本科学材料的，出来做软件开发，05年进入自动化所模式识别实验室做项目经理，软件架构师。后续的项目都在我手里做管理和开发，所有的项目进展都应该算是 很顺利，刚开始的一些对抗三四个月后就被化解了，到现在关系都非常好，06年7月份离开自动化所后，这些弟兄一直在和我合作到现在。
难道说我全懂么？至少两年前我都没有看到过模式识别方面的代码，也不可能懂得动态背景建模和一些高斯算法如何处理的东西，但是，我一样做好了我的角色。呵呵。
管理不是那么弱小的东西，可以这么说，随便给我一个行业的项目，我都有能力做好，因为这是一个项目管理中处理事务的手段，而不是虚夸的一种操作方法。
再 早一些，我02年8月底进入电信某设计院，10月11号就带着一个人一同去中国电信集团进行建设流程调研，四个月后我撰写的技术、业务规范一次评审通过， 得到了很高的评价，就这五个月的两篇文章就是50万。各省公司和集团的那些老大都没有认为我是个刚进入电信行业的人，才进入两个月就敢过来调研他们最核心 的业务之一，进行规范的撰写和定义。呵呵，03年3月电信集团直接打电话要求我去北京负责这个项目的实施，然后就给我办了借调，前期是非正式的，04年1 月给我办了正式借调，这在电信集团是从来没有过的，以前的正式借调都只有省市公司的，三产这类企业的员工根本不可能办理的。
【 在 chaobill (若我离去,后会无期) 的大作中提到: 】
: 一个项目里面必须有人全懂
: PM 至少要懂一些项目是什么划分的
: 举个例子，你会让一个 IT PM 去管理一个建筑项目么？
--
※ 来源:·水木社区 http://newsmth.net·[FROM: 162.105.244.*]
15
发信人: wohutu (什么也没有), 信区: SoftEng
标 题: Re: 很棘手的问题，求解。
发信站: 水木社区 (Tue Nov 17 11:50:20 2009), 站内
同意你的
【 在 qlw (钱五哥) 的大作中提到: 】
: 同意qingrun的说法，我看到这个案例后的第一反应就是将大牛的方案
: 放入下个版本，不影响本次开发，但是在接下来的开发中要考虑到大牛
: 的建议，便于将代码重用到下个版本，同时也让项目组成员逐步熟悉
: ...................
--
※ 来源:·水木社区 newsmth.net·[FROM: 123.116.117.*]
标 题: Re: 很棘手的问题，求解。
发信站: 水木社区 (Tue Nov 17 11:50:20 2009), 站内
同意你的
【 在 qlw (钱五哥) 的大作中提到: 】
: 同意qingrun的说法，我看到这个案例后的第一反应就是将大牛的方案
: 放入下个版本，不影响本次开发，但是在接下来的开发中要考虑到大牛
: 的建议，便于将代码重用到下个版本，同时也让项目组成员逐步熟悉
: ...................
--
※ 来源:·水木社区 newsmth.net·[FROM: 123.116.117.*]
16
发信人: kabbesy (Arthas), 信区: SoftEng
标 题: Re: 很棘手的问题，求解。
发信站: 水木社区 (Wed Nov 18 09:41:46 2009), 站内
zan!
【 在 zhangmike (秦月) 的大作中提到: 】
: 我的建议：
: 1，测试或判断当前关键功能的性能指标，如果能够满足12-31的要求，与大牛沟通，暂停重构。 没有一键编译和冒烟测试，重构的风险过大。
: 2，书面记录重构和技术难点与及大牛兼职工作的风险，与上级交流。
: ...................
※ 来源:·水木社区 newsmth.net·[FROM: 114.243.227.*]
标 题: Re: 很棘手的问题，求解。
发信站: 水木社区 (Wed Nov 18 09:41:46 2009), 站内
zan!
【 在 zhangmike (秦月) 的大作中提到: 】
: 我的建议：
: 1，测试或判断当前关键功能的性能指标，如果能够满足12-31的要求，与大牛沟通，暂停重构。 没有一键编译和冒烟测试，重构的风险过大。
: 2，书面记录重构和技术难点与及大牛兼职工作的风险，与上级交流。
: ...................
※ 来源:·水木社区 newsmth.net·[FROM: 114.243.227.*]
17
发信人: kabbesy (Arthas), 信区: SoftEng
标 题: Re: 很棘手的问题，求解。
发信站: 水木社区 (Wed Nov 18 09:47:29 2009), 站内
牛人！
最起码是牛的管理人员
不过我还是支持：“好的管理者必须专业，最起码尽量专业” 这个论点
“随便给我一个行业的项目，我都有能力做好”有点言过了
【 在 qingrun (青润) 的大作中提到: 】
: 这一点你错了，一个项目里面不需要有人全懂，关键在于PM如何做。呵呵
: 你的那种想法，六七年前我也如此考虑，后来发现，根本是没有必要的。
: 例子：
: ...................
※ 修改:·kabbesy 于 Nov 18 09:48:17 2009 修改本文·[FROM: 114.243.227.*]
※ 来源:·水木社区 newsmth.net·[FROM: 114.243.227.*]
标 题: Re: 很棘手的问题，求解。
发信站: 水木社区 (Wed Nov 18 09:47:29 2009), 站内
牛人！
最起码是牛的管理人员
不过我还是支持：“好的管理者必须专业，最起码尽量专业” 这个论点
“随便给我一个行业的项目，我都有能力做好”有点言过了
【 在 qingrun (青润) 的大作中提到: 】
: 这一点你错了，一个项目里面不需要有人全懂，关键在于PM如何做。呵呵
: 你的那种想法，六七年前我也如此考虑，后来发现，根本是没有必要的。
: 例子：
: ...................
※ 修改:·kabbesy 于 Nov 18 09:48:17 2009 修改本文·[FROM: 114.243.227.*]
※ 来源:·水木社区 newsmth.net·[FROM: 114.243.227.*]
18
发信人: qingrun (青润), 信区: SoftEng
标 题: Re: 很棘手的问题，求解。
发信站: 水木社区 (Wed Nov 18 09:53:38 2009), 站内
最起码尽量专业也代表你已经同意我的观点了。我是一个实践人员不是一个理论推行者，所以，没有那么高的噱头，只有操作过的实例。
至于后面那句，随便大家看待吧。呵呵
【 在 kabbesy (Arthas) 的大作中提到: 】
: 牛人！
: 最起码是牛的管理人员
: 不过我还是支持：“好的管理者必须专业，最起码尽量专业” 这个论点
:
: “随便给我一个行业的项目，我都有能力做好”有点言过了
--
我很傻，但是我很能干
个人blog：blog.csdn.net/qingrun
※ 来源:·水木社区 http://newsmth.net·[FROM: 162.105.244.22]
标 题: Re: 很棘手的问题，求解。
发信站: 水木社区 (Wed Nov 18 09:53:38 2009), 站内
最起码尽量专业也代表你已经同意我的观点了。我是一个实践人员不是一个理论推行者，所以，没有那么高的噱头，只有操作过的实例。
至于后面那句，随便大家看待吧。呵呵
【 在 kabbesy (Arthas) 的大作中提到: 】
: 牛人！
: 最起码是牛的管理人员
: 不过我还是支持：“好的管理者必须专业，最起码尽量专业” 这个论点
:
: “随便给我一个行业的项目，我都有能力做好”有点言过了
--
我很傻，但是我很能干
个人blog：blog.csdn.net/qingrun
※ 来源:·水木社区 http://newsmth.net·[FROM: 162.105.244.22]
19
发信人: kabbesy (Arthas), 信区: SoftEng
标 题: Re: 很棘手的问题，求解。
发信站: 水木社区 (Wed Nov 18 10:15:47 2009), 站内
haha
其实说远了，钱才是王道
技术强弱，技术强势，管理和沟通技巧，这都是放大的手段而已
【 在 qingrun (青润) 的大作中提到: 】
: 最起码尽量专业也代表你已经同意我的观点了。我是一个实践人员不是一个理论推行者，所以，没有那么高的噱头，只有操作过的实例。
: 至于后面那句，随便大家看待吧。呵呵
标 题: Re: 很棘手的问题，求解。
发信站: 水木社区 (Wed Nov 18 10:15:47 2009), 站内
haha
其实说远了，钱才是王道
技术强弱，技术强势，管理和沟通技巧，这都是放大的手段而已
【 在 qingrun (青润) 的大作中提到: 】
: 最起码尽量专业也代表你已经同意我的观点了。我是一个实践人员不是一个理论推行者，所以，没有那么高的噱头，只有操作过的实例。
: 至于后面那句，随便大家看待吧。呵呵
※ 来源:·水木社区 newsmth.net·[FROM: 114.243.227.*]
20
发信人: qingrun (青润), 信区: SoftEng
标 题: Re: 很棘手的问题，求解。
发信站: 水木社区 (Wed Nov 18 10:34:05 2009), 站内
钱才是王道，这句话我不能同意。
真正的王道还是人，做人和做事，不是钱，钱只是衍生的一种资源手段而已。
【 在 kabbesy (Arthas) 的大作中提到: 】
: haha
: 其实说远了，钱才是王道
: 技术强弱，技术强势，管理和沟通技巧，这都是放大的手段而已
※ 来源:·水木社区 http://newsmth.net·[FROM: 162.105.244.22]
21
发信人: lvchunchen (我的2008), 信区: SoftEng
标 题: Re: 很棘手的问题，求解。
发信站: 水木社区 (Wed Nov 18 15:57:05 2009), 站内
劈一个分支,请那个牛自己重构,自己抽时间结对一下.重构效果好慢慢和团队融合.
重点还在团队开发进程上.
【 在 redolence (雷德隆…还有一个斯) 的大作中提到: 】
: 关于项目管理的
: 项目开发了一半，项目组加入一位牛人，于是发生了这些事：
: 1.大牛说原来写的代码效率不高，构架繁冗，不方便后期维护，要求重构代码和数据库。
: ...................
--
※ 来源:·水木社区 newsmth.net·[FROM: 119.108.176.*]
标 题: Re: 很棘手的问题，求解。
发信站: 水木社区 (Wed Nov 18 15:57:05 2009), 站内
劈一个分支,请那个牛自己重构,自己抽时间结对一下.重构效果好慢慢和团队融合.
重点还在团队开发进程上.
【 在 redolence (雷德隆…还有一个斯) 的大作中提到: 】
: 关于项目管理的
: 项目开发了一半，项目组加入一位牛人，于是发生了这些事：
: 1.大牛说原来写的代码效率不高，构架繁冗，不方便后期维护，要求重构代码和数据库。
: ...................
--
※ 来源:·水木社区 newsmth.net·[FROM: 119.108.176.*]
22
发信人: pupop (lient Applications), 信区: SoftEng
标 题: Re: 很棘手的问题，求解。
发信站: 水木社区 (Wed Nov 18 20:52:32 2009), 站内
问题是，人家大牛可以完全不吊你
【 在 qingrun (青润) 的大作中提到: 】
: 五哥，我觉得，项目经理如果不懂得技术，也可以做好项目经理，那就需要更好的态度和更多的配合和询问，更多的增加内部的交流，但是，他必须有足够的逻辑判断能力，而不能糊涂，毕竟项目经理要负责整个项目的成败，失败了，他应该是责任承担者，绝对不能推卸责任。这样的
: 强势项目经理可以在一些判断中，先下结论执行后解释，而若是项目经理永远要以解释和讨论为主导，后下结论或者说后执行。这样的形态，加上好的态度，也一样 可以很好的控制项目的进度——我05年-06年在中科院自动化所模式识别实验室的角色，就是若是项目经理的做法，毕竟
标 题: Re: 很棘手的问题，求解。
发信站: 水木社区 (Wed Nov 18 20:52:32 2009), 站内
问题是，人家大牛可以完全不吊你
【 在 qingrun (青润) 的大作中提到: 】
: 五哥，我觉得，项目经理如果不懂得技术，也可以做好项目经理，那就需要更好的态度和更多的配合和询问，更多的增加内部的交流，但是，他必须有足够的逻辑判断能力，而不能糊涂，毕竟项目经理要负责整个项目的成败，失败了，他应该是责任承担者，绝对不能推卸责任。这样的
: 强势项目经理可以在一些判断中，先下结论执行后解释，而若是项目经理永远要以解释和讨论为主导，后下结论或者说后执行。这样的形态，加上好的态度，也一样 可以很好的控制项目的进度——我05年-06年在中科院自动化所模式识别实验室的角色，就是若是项目经理的做法，毕竟
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/257598/viewspace-620144/ ，如需转载，请注明出处，否则将追究法律责任。
下一篇：
[技术讨论]代码编写能力与管理手段的配合
请登录后发表评论
登录
全部评论
北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-8 北京市公安局海淀分局网监中心备案编号：11010802021510 niuxiaotong@pcpop.com 17352615567 未成年人举报专区
广播电视节目制作经营许可证(京) 字第1234号 中国互联网协会会员
违法和不良信息举报电话:18101376593