近两年在负责公司技术人员晋升相关的工作，所以有了一些思考。去年写了一篇《程序员的成长阶梯和级别定义》定义了程序员的晋升之路，但其中有一点实际并没有想的特别清晰，那就是关于技术晋升级别的评定。评定是一个非常主观的过程，正因为其主观性才带来了一些困惑，关于这些困惑，最近获得了一些新的启发，所以想写下来探讨探讨。
绝对和相对
在公司的早期时候，技术人员的晋升基本就是直属领导说了算，没有一个客观的评价标准，领导的主观判断占据主导因素。后来随着人员规模的扩张，这样的评价体系难以适应，所以开始成立技术委员会来让专业人员评定专业人员的级别。
即使是让专业人员评定专业人员依然存在一个标准的问题，这个标准到底应该怎么定？一开始我们就标准问题进行了大量讨论，也参照了业界标杆公司（腾讯）的一些标准制定方法。制定标准的初衷也是为了给评定过程增加客观性，将人的主观判断约束在一定的客观范围内。
既然有了标准，那么只需判断相应技术人员是否符合某个技术级别的标准，这属于一种按绝对客观标准来评定的过程。这看上去似乎简单可操作，但实际情况下会与公司的另一项限制产生冲突。一般公司每年的晋升人数都会有一个比例限制，这是出于控制与优化人才结构和成本的考虑，因而按照绝对标准去评定的结果可能多于，也可能少于这个比例限制。这是一个一直以来让人很纠结的冲突点。
如果考虑这个比例限制，就会变成按所有参与晋升人员的评定打分排序的一个相对标准，这样就没有一个客观的专业性评定标准。所以真正的评定中，需要同时兼顾二者，既有绝对标准的判定也能相对进行排序。
那么我们怎么做的？在最近的一次评定中采用了投票加评分双因素，多人制评定中（一般 5～7 人），得到绝对多数票（7 过 5，5 过 4）通过，可以认为满足这个级别的绝对客观标准。另外还会根据多个维度对候选人进行评分，评分主要用于得票相同人选的排序，以得到相对优先次序。
通过专业客观标准来约束人的主观评定范围，得到绝对性；通过多人多维度进行打分排序，得到相对性。但在评定过程中还有一些其他特性需要考虑，比如：可操作性，公平性，甚至还有成本。下面我们进一步看看这些方面。
过程与维度
前面说到了多人多维度打分，那么到底该有哪些维度。这一点在网上流出的关于腾讯公司的技术素质模型中，给出了 4 个大维度，16 个小维度，每个小维度又细分 7 个级别。我以其中与我们比较接近的后台研发为例，列一下这些维度：
- 通用能力
- 解决问题
- 项目管理
- 学习能力
- 创新能力
- 专业知识
- IT 服务管理；规范和流程
- 安全（防止入侵、对抗恶意的用户侧行为等）
- 运营运维（比如机型类型等）
- 前后台开发知识：操作系统、网络、开发语言、程序开发、第三方软件/系统
- 业务知识
- 专业技能
- 高性能低成本后台系统设计与实现
- 高可用性系统设计与实现
- 软件架构能力
- 复杂业务系统的设计与开发能力
- 组织影响力
- 方法论建设
- 知识传承
- 人才培养
我们曾经参考了这些维度并结合自身的实际情况做了一些调整，尝试在这 4 个大维度 16 个小维度上分别打分。经过一次实际操作后，发现很难在半小时到一小时的述职评定中判断这么多维度。最近读一本关于大脑工作原理的书时，提到人的大脑一般只能同时记住和判断 4 到 5 个并行的任务。继续细分小维度去判断，会让人感觉大脑负担不过来。所以，后来都调整为只在 4 个大维度上做打分判断了。
晋升过程一般由 HR 部门驱动发起，经过各个部门直属领导提报候选人，再经由技术委员会进行专业线评定，再去到管理层复议，最后又回到 HR 部门最终确定。这个过程中就像一整条过滤器链路。对于候选人 HR 部门发起时，只做必要的资格确认，比如是否满足年限，是否存在公司行政处分导致失去资格等。部门的直属领导提报实际相当于是对候选人过去一个晋升周期内绩效的认可，而技术委员会的绝对标准评定通过后，是对专业能力的认可。最后管理层的复议，是综合考虑整体和局部的利益，还包括经济和成本相关的事宜。
这一节，探讨了多维度评定的过程和可操作性问题，那么还有个问题，就是公平性如何？
博弈与权衡
评定过程的公平性是所有参与方都关心的问题，这个过程咋一看还算公平，里面有绝对客观的资格筛查，而对于主观的人为评定也分散到多人，避免了个别人的好恶影响，并且还由客观标准限定了人为评价范围。但这里面依然存在不公平因素，这个因素就是评定过程本身的形式。
程序员的特点多擅长和机器打交道，编程能力强于表达能力。而评定的过程是靠述职这种形式，它偏重于表达。而一个完全不擅于表达，而编程和解决问题能力很强的人，在这样的形式下就会吃亏，这就有失公平性。但反过来说，如果要追求一个对所有人绝对的公平方式，那么可操作性和成本可能就没法很好的控制。
对于这种擅长编程和解决问题，但不擅长表达的人，自己需要思考下如何体现你的长处？我提一种方式吧，喜欢编程可以通过内部的源码管理工具展现自己的代码贡献、甚至参与外部的开源项目，这些其实都是有记录的，甚至比嘴上表达得更有力量。比如，像章亦春（OpenResty 项目发起人）就不需要靠说来体现自己的编程能力。另外，我也听过他的技术分享，他的表达能力和编程能力同样出色。正如我曾经在文章里多次说过的，编程能力也许是你的最大价值，但也别忽略传递这份价值需要的成本，这份成本最终也会体现在你的市场价值里。
之前读到吴军博士两篇讲关于法律的文章，在传统的理解中法律应该是最在意公平和正义的，但在吴军的文章中提及了几个概念：民意与民义、民力与民利。其中阐述了这些概念代表的内容与法律代表的公平与正义之间地博弈和权衡过程：
在现代社会中，一切都是有成本的，绝对的正义是不存在的。当给予一部分人正义时，可能要以在其他地方付出巨大的成本为代价。如果一个判决伸张了正义，但是让受害的一方更倒霉，这就违背了司法中关于民利的原则。
所以，司法判定要同时考虑这四个概念代表的内容：
- 民意：人民的意图
- 民义：人民最在乎的公平和正义
- 民力：人民让渡给国家政府维护正义必要的力量
- 民利：人民的利益
你会发现司法判定和本文的晋升评定有异曲同工之处，都是需要判定一个事情，也都受这四个因素影响导致的博弈和权衡。评定中的「民意」来自直接参与晋升的个人，其相关的直属领导和所在部门。而「民义」，依然是保证公平。但「民力」来源则不同，评定的权力实际来自于组织，而非群众，所以最后的「民利」实际就应该是组织的整体利益，评定判定实际就是站在授予权力的一方，兼顾公平和利益。
当绝对的公平和利益发生冲突时，法律的判定实际更站在利益一方，符合民利原则，这就是吴军文中给出的一些观点和启发。那么技术评定中的公平会和组织利益会产生冲突吗？什么是更符合组织利益的？也许人员和团队的稳定与良性流动是有利于组织利益的，选出更能代表组织技术实力的技术人员是更符合组织利益的。当把这些因素都考虑进来后，真正的评定实际是所有这些因素的博弈并达到平衡。
…
晋升评定本身就是一个随着人、环境和标准地变化也在不断变化的动态不确定性问题。这样的问题，在一些不同的时刻你总会需要去得到一个确定的答案，即使这个答案不会让所有人满意，事实是它绝对不可能让所有人满意。