开发经理应该具备怎样的素质

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/kentonwu/article/details/47276485

一个开发经理的素质如何将很大程度决定一个项目组的战斗力。开发经理或者项目组长(team leader)是公司和员工的最主要桥梁,对公司,开发经理要带领小组做好产品,交付客户,实现利益最大化。对员工,开发经理不仅要带领组员完成项目,而且还要帮助组员实现个人在项目中的价值,包括对项目的贡献和获得的成就感,同时还有自身技术能力的提升和经验的积累。只有同时做好两方的诉求才算是个优秀的开发经理。对员工来说,一个企业的文化,最直接的体验就是来自于开发经理领导的小组,因为员工百分之九十的时间是在开发经理领导下的团队当中打交道。由此可见,开发经理扮演的身份是很重要的。那一个优秀的开发经理需要哪些素质呢,个人觉得主要包括以下:


    ​1,善于跟踪和总结

    ​    ​项目进行中,开发经理要能及时跟踪所有组员的情况(通过例会来跟踪,比如敏捷开发的站立会议,每周例会可能无法及时跟踪,个人比较推崇敏捷开发,不过跟项目特点有关。)跟踪组员的任务进度,及时发现问题并协调解决问题。同时定期或不定期总结开发过程中出现的任何问题并在会上分享。


    ​2,对事不对人

    ​    ​项目过程中,组员包括自己难免会犯错,开发经理要能对组员,或者引导组员之间,要对事不对人。在出现问题后要首先找出问题所在,并及时更正,而不是抱怨。最后在校组内一起总结。因为虽然是某个人出现这个错误,但是并不代表其它人不会出现这种错误,所以单独批评犯错的人是没有太大意义。但是通过先找出并解决问题,而后在组内总结分享才是好的解决办法,既解决问题,但又不会针对犯错的组员。做到对事不对人才不会破坏小组的团结和损害战斗力。


    ​3,敢于承担责任,而不是推到组员身上

        ​​在出现问题后,不要轻易指责犯错的人,特别是,当错误是从客户和领导那边发现的情况下,不能把责任推到组员上,而是能自己承担起来,或者以项目组的身份承担起来。因为在自己负责或主导的情况下,出了问题首先就是开发经理管理不善的结果。动不动什么问题都是组员的问题,都推到组员身上会严重破坏小组的战斗力。


    ​4,持续学习和技术能力

    ​    ​开发经理要有比较丰富的技术和经验,做到对项目所有涉及到的技术都比较了解甚至精通,做到能从宏观上把控并给组员提供支持。同时对技术也要有打破砂锅问到底的素质,只有这样才不会在项目当中留下隐患,导致后期问题爆发很难解决。


    ​5,沟通能力

    ​沟通能力无论在哪里都很重要,做研发的沟通能力一般比较弱,不过软件工程师也大多比较简单,所以对开发经理来讲,我个人觉得沟通能力最主要体现在是否在相互尊重的前期下,能肯定组员的工作能力和成果,以及调动组员的工作和学习积极性。


    ​6,营造团队氛围和精神

    ​团队精神很重要,这个大家都知道。大家也会在简历里写上富有团队精神,但是我个人认为,组员富有团队精神不是关键,如果开发经理不营造团队精神,团队氛围,组员再有团队精神也持续不了多久。团队氛围需要开发经理来营造建立,组员更多是合作,一起营造团队的氛围。


    ​7,责任心,完美主义,高要求

    ​在做一个项目或者产品的过程,难免会碰到一些问题,进而出现一些不好解决,有妥协的办法,这时需要开发经理能够支持原则,比较强的责任心,不妥协,严格按要求来做。比如对于代码审查,一开始动力比较足,慢慢的会放松要求,睁只眼睛闭只研究。再比如代码重构,虽然项目的进行,有些代码甚至框架需要重构,如果责任心不够,或者不够严要求,放任下去,最后项目虽然可能可以交付,但是一定不会是个优秀的产品,直接后果是导致后期很难维护,增加维护成本。


    ​8,以身作则

    ​在要求组员的同时自己同样要能做到,而且还需要先行作出榜样,没人喜欢看到一个只会要求别人如何如何而自己却不执行的开发经理。团队规章制度(比如开会时间要准时,比如代码规范,文档规范等等)如果开发经理不执行,不以身作则,那是无法实施下去的。


    ​9,抗高压

    ​就像开头说的,一个优秀的开发经理,要做好公司和员工的桥梁,那需要承受的压力也一定会很大。唯有努力掌握好各个必备素质才能很好的化解各方压力。


    ​当然,除了上面几点,肯定还有其它的素质也会很重要,这里只是挑选几个个人认为比较重要的。总之,只要心里装有为公司谋利益,为组员谋进步,那一定不会是个不好的开发经理。

展开阅读全文

软件架构师应该具备说明素质?[转]

10-22

rn[b]一、核心竞争力 rn  架构设计的理论、模式与技术[/b]rn  架构师们从试验与挫折中获得架构设计的技能,但其中大量的原理、模式和技巧,都经历了一个重复发现的过程。rnrn  其实,各路神仙在这个领域虽则没有捣鼓出大热的畅销书来,但前篇的架构师书单,也足够为我们作一个系统的知识整理。rnrn  痛苦回首,发现自己的再发现式积累还是太慢、太片面,大多局限于GOF23、Java EE架构模式、RUP4+1视图等方面。rnrn  [b]有序的以方法为驱动源的任务执行 [/b]rn rn  匠级的架构师多有一套自己的方法论、过程论,每回设计都是熟练而有序的执行。rn  其中架构师的小过程可以参考书单反复试验,独家秘制。rn  而与开发团队配合的大过程,以RUP为基础的剪裁被描述得最为详细,可执行度最高的。rnrn [b] 领域知识[/b]rn  技术人员一般抗拒学习软件开发以外的东西,但架构师却非如此不可,因为架构师的职责就是将业务需求转化为系统设计。那又如何快速成为新领域的专家呢?精通快速业务建模吗? BTW.G9写过一篇很有意思的〈商业软件编程很无聊?〉rnrn  [b]大型项目的经验 [/b]rnrn  中国有多少架构师,不在于有多少人通过了什么考试培训,而在于中国大型项目的数量。rn  问:你这个项目的架构是什么?一口回答:Spring+Struts+Hibernate。这位很可能就不是架构师了,因为这仅仅是技术Stack,项目规模不大时Spring+Struts+Hibernate才会成为架构的重点。rnrn  除了亲自担任大型项目的架构师,如果了解这些项目为了满足怎样的功能与非功能需求而把架构设计成这样子也一样的。所以,尽量多读一下公司项目的设计文档,愉快的接受其他项目组架构评审会的邀请。rnrn  [b]二、基本能力rnrn  完整的软件开发生命周期经验 [/b]rnrn  这个不用说了,幸好中国的架构师什么脏活累活都做过,甚至跟着市场人员跑去做演示这些国外架构师不一定有的经验我们都有了,差别只在于一些理论知识--RUP + CMMI3 + 敏捷原则的细节掌握程度。rnrn  [b]精通一两种主流开发语言、保持当下架构的开发体验 [/b]rnrn  国内的架构师到了三十岁以后很多就往理论上跑,而国外的架构师则在往上发展的同时保持下面的编程体验,所以国内多水王,而国外则多大师。rnrn  水王的设计一般会层次过高,与实现之间有断层,与开发人员沟通困难,自己哗啦啦编个验证原型的日子更是一去不返。更痛苦的是,人过三十之后学习能力下降,手艺一旦放下了想重新上手还很难:(rnrn 但是,也不必要挽起袖子每月编码若干行,很可能你的\"亲自出手\"因为时间安排不来反而拖了大家的进度,但一定要保持一个体验。 rn  [b]宏观上的,广度优先的了解当前主流的技术与产品 [/b]rnrn  架构师如果连Tuxedo与IBM MQ都分不清,一句\"这里搞个异步调用的middleware,有commercial support的\",同样是层次太高了。架构师对各大公司的完整产品线和著名的开源项目应该有宏观上的了解,最好在Wiki里编个索引。rnrn   但同时也要抵制成为某项技术专家如Oracle启动参数优化专家的诱惑,技术细节掌握到业务职责需要的程度就刚好了。除非如Spring Framework进一步了解能带来天大好处。rnrn  [b]与业务域开发域人员沟通的能力及其他领导能力 [/b][Page]rn rn  IT 架构师处在客户和开发人员之间,必须能够使用各种媒体(代码、模型、文档、PowerPoint以及谈话和讲座),与技术和非技术的干系人进行沟通。另外,架构师好歹也是个半大不小的官,其他领导必要的能力就不列了。rn rn[b]  参考了IBM DW中国上的两篇文章:[/b]rnrn  《软件构架师的特点》 rn  《观点与展望,第 3 部分: 什么是最有价值的 IT 体系结构技能,如何学习?》 rn rn[b]  三、镜子做好了,自己先照一下[/b]rnrn  要把书单啃完; rn  要熟悉NGOSS、3G、IMS这些业务知识; rn  要把公司几百个项目的设计文档抽好的看一遍; rn  要跟随公司最新一波RUP+CMMI3行情; rn  要重修C++; rn  要完整了解一遍IBM、BEA们的产品线; rn  要从那些写得好的架构PPT中偷师... rnrnrn原文链接:[url=http://www.zxbc.cn/html/20070705/24263.html][/url]rn 论坛

没有更多推荐了,返回首页