首页 > 程序人生 > 关于软件开发人员技术等级晋升的几个误区
2014
11-11

关于软件开发人员技术等级晋升的几个误区

每到年底,业内不少工程师又需面对晋升答辩的流程,如何让自己在最短的时间完成职级提升是大家关注的话题。在一个规范运作的公司里,基础的晋升通常由部门的经理或者技术负责人定夺,更高级别的评估通常由一个跨部门或公司范围的技术专业委员会(Technical Committee简称TC)来负责。本人有幸参与了几年TC的工作,很高兴看到不少人员的快速成长,但同时看到的一些成长认识误区如下。大家可以通过这些误区的了解,来合理的规划自己的职业生涯,获得更好的职业成长。

  • 罗列工作、项目或者KPI。技术委员会评估一个人的能力时,通常希望寻找论据来支持候选人符合更高级别的Level。但是支持点并不是凭工作量或者项目数的多少来决定。项目按时完成情况是一个辅助因素,但不是全部。因此在所罗列的项目中,寻找那些项目包含了能支撑你胜任高Level去介绍。
  • 没有重点及个人贡献。有些候选人介绍了几个形态各异的项目,但需要评委去仔细挖掘到底体现了候选人哪方面能力;另外一方面有些员工虽然参与了重点及有挑战的项目,但如果其中的个人贡献不好辨别则很难加分。评委可能想“嫦娥三号项目很伟大,可是这个家伙究竟是参与开发了玉兔号月球车,还是仅仅坐在监控大厅看显示器……”。仅强调项目成果评委无法判断候选人的能力,突出重点项目及个人的独特贡献,是材料展示的关键。
  • 承担过的项目与申请的Level不匹配。有些候选人参与过不少项目,对公司也有贡献。但是TC对不同的Level期望候选人展示的能力及规划能力是不同的,越是高阶Level申请,越是看在领域内的规划能力、影响力与愿景,如果目标仅停留在项目完成与否上,不管在哪个级别都会有所欠缺。
  • 可度量及可比性不强。技术行业中,分工越来越细,因此候选人从事一个大家不了解也没参与过的领域的情况越来越多。因此如何将这块的工作的好坏达到一个行业内的可比性也是很重要,帮助TC来理解你的工作。
  • 大篇幅罗列非专业领域的能力,比如项目管理、团队管理、跨团队协调成绩、培养新人成果、项目交付状况、创新成绩等。并不是说这些材料不好或不能讲,但是如果60%以上篇幅都是讲这些,TC无法判断你在专业上是否达到了申请的Level。通常TC对专业角度的考察会占到60%以上的权重。直接说出你打了哪几次胜仗,每场由于环境的变化你灵活使用了哪些兵法来克服困难,在某些特别的条件下,你灵活使用了一些没用过的兵法取得了良好效果。如果你发现过去缺少独立打仗的机会,请看下一条。
  • 岗位成长性差。这一点无关答辩技巧,更多是路线规划与上级主管的培养问题。由于注重结果导向,大部分主管更多精力会放在项目的交付及进度,对下属的安排主要是工作的分配及是否按时完成的监督,而对员工的技术成长、路线规划等则会偏少。碰到这种情况,更多的跟上级在专业发展方面进行交流。确定你的技术成长路线并寻求上级的资源支持,大部分上级也会很乐意提供资源的配合。

(PS:曾打算写一篇晋升攻略,但考虑到每个人的目标及成长路线的多元化,很难给出公式化的建议,因此仅罗列一些误区供读者思考。)

作者:新浪微博技术总监@TimYang 

编程技巧