转：项目经理眼中优秀开发人员的标准

项目经理眼中优秀开发人员的标准 

版权声明：如有转载请求，请注明出处：http://blog.csdn.net/yzhz  杨争  

      作为项目经理，我希望我们项目的开发人员做到以下几点：
1、主动性
        在项目中积极思考，主动提出自己的意见和看法。
        遇到问题主动寻求相关人员协助，主动沟通。
 
2、Bug修复及时
        项目经理在项目计划中通常会安排了bug的修复时间,以及在此基础上的后续工作（比如集成测试、回归测试等），特别是到了项目后期，Bug修复是否及时将直接影响后续工作的进行。所以项目经理希望开发人员能按时完成bug修复任务。开发人员往往没有认识这一点的重要性，在bug修复的问题上不是很积极。 
 
3、按时完成任务
         通常，我们会要求开发人员根据任务的复杂程度和自己的能力评估所承担任务的开发时间，项目经理也会评估这些时间的合理性，然后结合项目的整体情况给出项目计划。一旦某个开发人员没能按时完成自己分配的任务将直接影响整个项目的进度。
         当然由于需求变更以及某些不可预计的原因造成任务推迟，要及时和项目经理沟通，以便项目经理根据实际情况作出action，确保项目的顺利进行。

4、创新
        创新不是口号，创新其实就是我们对平时工作的思考，如果你是个有心之人，那么创新的idea会源源不断从头脑中显现，而我们的项目就是创新思想实施的最好机会。流程、规范、技术方案等等地方都是你创新的舞台。

5、责任心
        对自己的代码负责，尽量做到完美。
        一个优秀开发人员的标志就是写出来的代码总是让人赏心悦目。好的代码体现 在良好的可维护性，易读性，性能优良。功能的实现只是代码的最基本要求，只有严格要求自己，我们的编程水平才能提高。
 
       我也是从以上几点考核我们的开发人员。

作为程序员，我们希望的项目经理应该是：
1。主动性
你不可能指望同级别的同事抛开自己的事情不做跑过来帮你解决问题，这时候项目经理起到的就是协调作用，应该经常向程序员询问情况，有什么困难需要什么帮助，尽最大的努力利用自己手上的权利去帮助程序员。
2。Bug修复及时
项目经理要能把握bug的轻重缓急，特别是和业务相关和程序无关的部分，在异常困难的情况下要和程序员一起研究出折中的办法来尽快解决问题。
3。按时完成任务
他应该对手下的程序员的水平有一个比较详尽的了解，谁在什么方向上比较熟练，兴趣在哪里，目前水平如何，还能提高到一个什么层次，以前不能按时完成任务是什么原因，通常不能按时完成任务是因为1，程序员水平不行，如果是这个原因的话项目经理就没有很好的对程序员有一个了解，这样制定出来的计划当然不能怪程序员，2。程序员理解有误，这是因为项目经理没有和程序员做很好的沟通，没有达成共识，这当然是项目经理的责任。3，项目经理理解有误，那就没话说了
4。创新
在正常的流程中不应该有创新，并不是不需要创新，新出现的方法和思路应该被精确的认证后再用到工作中，盲目的创新只会导致项目完不成，好思路也没有被认证，混在一起出了问题的话也搞不清楚是创新的问题还是原来就有问题，就算没问题也不能证明就是因为创新带来的好处。
5。责任心
程序员不需要责任心，责任心是由制度规定的，他只要按计划完成任务就可以了，他不需要负这么大的责任，责任的重担应该落在项目经理的身上。好看的代码是靠项目经理指定的格式才会出现的，所谓好看，就是明确的命名规则，同样风格的缩进，同样风格的注释，程序员又不是同胞兄弟，怎么会知道别人的风格和习惯呢，如果项目经理没有规定，那就会出现五花八门的风格，够看的
格式不需要先进，仅仅是让大家都统一，统一的风格对于发现bug，对程序进行修改都能起到很好的作用也能节省时间。

我回复一下。
主动性：
在我的文章中在主动性上没有一句话说：“要求开发人员抛开自己的事情不做跑过来帮项目经理解决问题”，相反我的意思是开发人员遇到问题，可以主动
寻求帮助，我本人做开发也将近5年，非常了解开发人员的心里，开发人员通常不愿意寻求帮助，他们希望自己寻找解决方法，这样做当然好，但是对于一个
项目有时间的要求，寻求周围人的帮助往往能迅速解决问题。
作为项目经理我们也是每天抽时间询问开发人员目前遇到哪些困难，是否需要帮助。

bug及时修复。
这个问题是一个认识上的问题，开发人员对bug修复的及时性没有项目经理看得重，原因是项目经理需要从全局的角度考虑问题。
我们的bug都有一个统一的处理流程和统一的处理时间，我们在项目中都会有安排，包括bug的轻重缓急都是要考虑的。flyback你说的应该是这个。

按时完成任务。
不知道flyback公司任务的分配是如何进行的。我们公司的任务划分是我们和程序员协商，由他们根据自己的能力和任务的复杂程度把开发的时间反馈给我。
我这边再做评估，通常我们会尊重开发人员的看法，当然对于那些评估的时间和我预计大的任务，我们会协商找出其中的原因，解决它。

创新
是否需要把创新的点子（包括流程，解决方案）运用到项目中，最终的结果需要项目经理来评估。因为这种创新有可能会带来风险。而项目经理对项目的成功
负有最大的责任。
我提出这个标准是希望开发人员做事情是有创新的理念，让创新融入我们的平常工作中，尽管有时候这个创新的idea由于各种原因在项目中并不能实现。
但是只有一个积极思考的人才能是成长最快的人。

责任心

flyback 网友只提到了一个格式问题，这只是很小的方面，有些问题不是制度就能避免的。
比如代码的重用性问题，代码的高性能问题，代码的易维护问题(并不仅仅是注释)，这些是制度无法实现的，这个很大程度上需要开发人员的责任心，对自己的严格要求，如果他希望成为一个优秀的开发人员的话。
格式，注释问题当然很容易通过规范和工具来处理。


正如有的网友说的其中大部分的标准是通用的，不光光适用于开发人员，对于这点我非常的赞同。
写这个标准的项目是做了这多项目，觉得有些想法，就写了下来。
当写完这篇文章的时候我发现实际上优秀的程序员的标准和其他行业的人员一样。
一个主动的人，工作中积极思考的人，对自己的工作非常负责的人 都会在自己的行业中成功。

最后一句话：团队非常重要，项目的成员离不开每个人的努力，团队的每个人员都是平等的关系。flyback网友好像对项目经理很排斥。^_^
我觉得我自己是一个非常能理解开发人员的项目经理，我们在规划项目流程的其中一个标准就是：
在保证项目质量的情况下最大程度的降低开发人员的压力，任何流程和要求影响了开发人员的开发，分散了他们的精力，我们都会认真评估。
让每个开发人员快乐的开发，让每个开发人员在项目中成长是每个项目经理的最重要职责。

凑凑热闹，给点反馈 :-)

人无完人，还是从PM的角度想想如何帮助开发人员吧 :-) 管理者就是帮助别人成长的。

1、主动性

--> 项目中积极思考（请问估计大概占用项目过程的多少时间来思考呢？还是加班来思考？思考后干嘛呢？）
--> 遇到问题主动寻求相关人员协助，主动沟通。（应该先自己思考如何解决再沟通吧？要不请恐怕这个开发人员就不合格了，除非是不属于他解决的问题，这个应该占少数，否则组织结构有问题）

我的建议，一般来讲，项目结束后可以给出一定的总结和讨论时间，这个时候大家来一起思考如何改进，一方面给开发人员时间思考，一方面又是提供了一个正规的途径，使得思考能够反馈到PM和管理者，并且对好的反馈和建议应用的工作实践中（或者流程改进）

2、Bug修复及时

--> BUG修复一般都是项目经理需要在项目计划中预留实现并且每天都跟踪的，如果PM比较重视BUG修复，开发人员没有什么理由不优先解决BUG的。同时改BUG和开发新程序是比较痛苦/烦的一件事情，项目经理必须注意做出平衡，这种阶段尽可能短，并且人员安排要合理。（可能有些开发人员就是专门修复BUG的）

3、按时完成任务

--> ”一旦某个开发人员没能按时完成自己分配的任务将直接影响整个项目的进度。“这个说法不对，看他的任务是否在关键路径上了。
--> "当然由于需求变更以及某些不可预计的原因造成任务推迟"，需求变更都应该有需求变更控制和评估，PM应该很清楚需求变更对项目的影响，而不是等待开发人员的报告
--> 项目的进度需要靠项目经理主动的和项目组员以及TEAM LEADER沟通以及项目例行报告/例会来保证，而不是依赖于开发人员的"主动沟通“，这种属于有则更好，没有也不应该是开发人员的问题。
--> 反过来讲，PM如何去及时了解和把握项目进度，降低风险，这才是考验PM的能力。

4、创新

--> 创新其实就是我们对平时工作的思考（请问估计每个开发人员大概占用平时工作的多少时间来创新和思考呢？还是加班来创新和思考？）
--> 创新是要PM或者公司管理者有意识的安排的，不是无序的鼓吹"创新"，有很多"创新"在项目中是不合时宜的，甚至是有风险的，对于PM或者管理者来讲，如何把握具有”创新“能力的技术人员，同时寻找机会安排时间让他去做具体的创新工作，然后付诸项目实现，比说一些鼓励创新的空话效果会好很多。

5、责任心

--> ”对自己的代码负责，尽量做到完美。“（天啊，尽量完美，普天之下，有几个项目有足够成本让系统做到完美？如果一个PM要求他的开发人员把代码写到完美，那么他就不是一个好的PM，项目管理是在质量、时间和成本之间取得平衡，完美的代码就是完美的质量，那要花多少时间，多少钱啊？）
--> 责任心是对的，对自己的代码要负起责任，达到一定的质量标准，但远远不是完美。这点上，PM和系统架构师需要一起做出把握和平衡。

坦白来讲，一个开发人员，如果上面的这几项都做的很好的话，他已经是有资格成为一个TECHNICAL TEAM LEADER了，不是一个开发人员那么简单。。。<