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

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

• 罗列工作、项目或者KPI。技术委员会评估一个人的能力时，通常希望寻找论据来支持候选人符合更高级别的Level。但是支持点并不是凭工作量或者项目数的多少来决定。项目按时完成情况是一个辅助因素，但不是全部。因此在所罗列的项目中，寻找那些项目包含了能支撑你胜任高Level去介绍。

• 没有重点及个人贡献。有些候选人介绍了几个形态各异的项目，但需要评委去仔细挖掘到底体现了候选人哪方面能力；另外一方面有些员工虽然参与了重点及有挑战的项目，但如果其中的个人贡献不好辨别则很难加分。评委可能想“嫦娥三号项目很伟大，可是这个家伙究竟是参与开发了玉兔号月球车，还是仅仅坐在监控大厅看显示器……”。仅强调项目成果评委无法判断候选人的能力，突出重点项目及个人的独特贡献，是材料展示的关键。

• 承担过的项目与申请的Level不匹配。有些候选人参与过不少项目，对公司也有贡献。但是TC对不同的Level期望候选人展示的能力及规划能力是不同的，越是高阶Level申请，越是看在领域内的规划能力、影响力与愿景，如果目标仅停留在项目完成与否上，不管在哪个级别都会有所欠缺。

• 可度量及可比性不强。技术行业中，分工越来越细，因此候选人从事一个大家不了解也没参与过的领域的情况越来越多。因此如何将这块的工作的好坏达到一个行业内的可比性也是很重要，帮助TC来理解你的工作。

• 大篇幅罗列非专业领域的能力，比如项目管理、团队管理、跨团队协调成绩、培养新人成果、项目交付状况、创新成绩等。并不是说这些材料不好或不能讲，但是如果60%以上篇幅都是讲这些，TC无法判断你在专业上是否达到了申请的Level。通常TC对专业角度的考察会占到60%以上的权重。直接说出你打了哪几次胜仗，每场由于环境的变化你灵活使用了哪些兵法来克服困难，在某些特别的条件下，你灵活使用了一些没用过的兵法取得了良好效果。如果你发现过去缺少独立打仗的机会，请看下一条。

• 岗位成长性差。这一点无关答辩技巧，更多是路线规划与上级主管的培养问题。由于注重结果导向，大部分主管更多精力会放在项目的交付及进度，对下属的安排主要是工作的分配及是否按时完成的监督，而对员工的技术成长、路线规划等则会偏少。碰到这种情况，更多的跟上级在专业发展方面进行交流。确定你的技术成长路线并寻求上级的资源支持，大部分上级也会很乐意提供资源的配合。

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

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