转载

技术述职的一些经验总结

每个发展的大一些的「科技」公司，在对于职员的晋升上，都有相应的流程和规范。一般都是公司的技术委员会组织，参与述职的同学现场通过PPT的形式来讲述近一段时间自己的工作。

虽然被网友诟病为「PPT大赛」，但这多少也算一个展现的机会，如果没有述职可能依然每天不停的Coding，从不回头看。而述职，做为一个半年或一年省一次身的机会吧。

我在百度参加了六、七次晋升述职，成功和失败的都有，趁着这次述职的余热，整理下我的一些「 个人体会 」。

我没做过评委，不清楚和评委的思想是否一致，不一定适用，有些许启发就好，欢迎留言交流。

指哪打哪

首先，每个公司对于特定的技术晋升层级都有对应的标准。比如以下的例子:

X-1 层级对应要求是在导师指导下可以完成 模块开发 。可以独立自主的完成一般难度的模块开发和调研工作
X-2 层级对应要求在于在技术上 独立开发 。比如在一个低难度的项目中可以完成独立开发，甚至可以指导新人或者负责大项目中的子系统
X-3 层级对应要求工程师可以 负责项目 ，有一个或者几个方面比较深入，同时保证高质量的产出
X-4 层级要完全把握一个 技术方向

准备述职的时候，就要根据自己对应的目标层级进行准备。比如你要述职晋升的目标对应的是上面的 X-3, 但是在准备的时候却罗列了一些 细碎的功能点 ，就不足以说服评委。「指哪打哪」是说要瞄准方向，按照要求进行说明的准备。比如 X-3，要体现出自己对于负责系统的整体思考，自己在系统中的贡献以及未来的规划等。

关于这块容易出现的

问题

是：

「着眼点」太小，「站的不够高」。

比如在X-3述职的时候，列举了一堆把页面上功能做了修改，SQL语句简单优化这类的。而对于具体参与的项目，如果仅仅是功能点、使用框架及中间件的罗列，并没有多大意义。需要展开描述具体的场景，为什么要这样用。
多用「技术语言」

比如使用微服务架构进行了服务拆分，就需要表述为什么要微服务，使用这样的架构带来了哪些好处。
有「对比数据」

如果是新旧项目，或者优化工作，最好将前后的数据用「柱状图」来直观展现，比文字更形象。切忌满PPT的文字，现场照着去读。

预则立

古人说「预则立，不预则废」，对于晋升述职也是同理，一定要早做准备。我有几次因为项目忙一直拖着，直到述职前一周才开始准备，结果各种匆忙。而有些同学，早早做了规划，述职的 PPT 经过了好多版的打磨，重点会更突出。而且由于有规划，平时工作中的内容都会进行提炼总结，也更便于结果的呈现。

对比匆忙上阵，一些数据支撑等可能不容易总结。另外，述职PPT也来不及打磨。

此外，以下几点供参考：

多参考其他优秀的述职PPT，可以找些模板，但不必过分花哨和动画。因为PPT在评委那是静态看的，不会播放，如果多个动画叠在一起，影响阅读效果。
多让其他有经验的同学帮忙 review 一下。闷在自己的思路里，会一直觉得当前的思路和表述很牛X，但你给几个人讲过之后会听取到不同的意见。特别是有经验的「老司机」把把关。这样在早做准备后可以有更充足的时间修改。
多练习。讲的时候能发现内容上的不足。和我们在程序开发中的「橡皮鸭调试法」类似，通过讲来改进。而练的越熟练，正式讲的时候也就越自信，可以发挥的好。

总之，早准备早见效。