程序员的工作、学习与绩效

工作中,碰到一些这样的例子,总有人提出疑问,为什么一个同事工作勤勉,完成了很多事情,季度绩效评定很高,但晋升却碰壁了。之前已经写过一篇《技术晋升的评定与博弈》,基本就能解答这个问题。但隐藏在背后的更深层次的本质却是:工作、学习与绩效的关系。

工作

程序员的主要工作是:编程,产出代码,完成需求,交付软件系统。

程序员按其工作技能和经验,大体又分为三个阶段:初、中、高级。三个级别的程序员的主要工作都是编程与产出代码,产出代码的数量也许相差不大,但产出代码的属性可能有明显差别。

在曾经的文章中提出过一个代码属性:资产与负债。由大量初级程序员产出的代码并以此构建的软件系统,如果最终能完成交付,那么很可能资产和负债性基本持平。这是很多早期创业公司的特点,因为缺乏资金和足够的知名度,难以吸引到又多又好的中高级程序员加入。这样的系统多属于勉强满足业务需要,看不出明显的 bug,但一遇到特殊情况就容易宕机。整个系统虽然勉强能支撑公司运营,但其中欠下了大量的技术债,先活下来,未来再来慢慢还。

若是完成了一个债务比资产还大的系统,会是个什么样的情况呢?那这就是一个还存在明显 bug 的系统,是基本无法完成交付和上线的。因此,现在主流都是先完成一个资产和负债刚好过平衡点的系统,发布上线,接受反馈,再快速迭代,在迭代中不断地提升其资产性,降低其负债性。在 Facebook 的著名标语激励下,奋力前行:Done is better than perfect(比完美更重要的是先完成)。

而中高级相比初级程序员,就不仅仅是交付代码,完成工作,还有后续的两条:达成品质、优化效率。从初级向后两级跨越的门槛就在于此,比较容易被卡在不断地在完成工作,但却没有去反思,沉淀,迭代并改进,导致一直停留在了不断的重复中。

程序员的工作,以产出代码为主,从初级到高级,代码的负债属性逐步降低,资产属性不断提升,并成为高品质的个人贡献者。在这个层面上,还是 Facebook 的另一条标语足以说明问题:Code wins arguments(代码赢得争论)。

学习

学习,是唯一能让你突破不断循环怪圈的不二法门。

程序员在攀登职场阶梯的道路上,走过了高级,后面会有好些分叉路线。比如,转到脱离技术的纯管理岗或者技术管理岗。我以前写过,技术主管或架构师某种意义上都属于技术管理岗,不懂技术是做不了这两个角色的。或者继续沿着深度领域走,成为细分领域专家。

这后面哪条路适合你呢?你是随大流,还是自己真得认真思考过?这是做选择题。如果一生要工作三十多年,前十年你多在做解答题,解决一个又一个问题。那么在大约走过三分之一后,你就会开始做越来越多的选择题。为什么呢?因为一开始可能都没有太多选择的机会。而做好选择题,就需要大量的学习,还需要不断的试错。

面对怎么选路的问题,我近年学习的收获是这样的:选择走最适合实现个人价值的路。这就是我的基础选择价值观。程序员的个人价值该怎么实现?该如何最大化?程序员作为个人贡献者,产出的增长随时间和经验实际上连线性都不是,而是呈对数曲线的(《两种增长曲线》)。到了一定时间必然面临瓶颈,这就需要找到一个价值贡献放大器。有人很幸运的编写服务于数千万或数亿人的软件服务,这是产品自带的价值放大器。这样同样写一份代码,你的价值就是要比别人大很多。而转管理者、主管或架构师,这些角色无非都是自带杠杆因子的,所以也有价值放大作用。但个人能否适应得了这样的角色转换,又是另一回事了。

现在稍具规模的中大型公司内部的职场阶梯模型,我看基本都源自拉姆·查兰的那本书《领导梯队》。书里把人才潜能分成三种:熟练潜能、成长潜能、转型潜能。原书文中对这三点做了详细的特征描述(比较长),我简单提炼下主要特点:

  • 熟练潜能:关注当前专业领域且十分熟练,但没有显示出在开发新能力上的努力,竭力维持现有技能。
  • 成长潜能:按需开发新能力,显示出高于当前层级要求的其他技能(专业、管理、领导)。
  • 转型潜能:持续有规律的开发新能力,追求跨层级的挑战和机会,展现雄心壮志。

人力资源管理中的高潜人才盘点,基本就来自这套模型,主要就是识别出这三类潜能人才。「熟练潜能」就是对学习的最低要求,在程序员这个技术日新月异的行业里,维持现有技能确实已经让不少人感觉很竭力了。

攀登的这条阶梯,它从来不是笔直的。在每一个拐弯处,都应减速、思考、学习、进步。学习也常与错误相伴,查理·芒格说过:

世界上不存在不犯错误的学习或行事方式,只是我们可以通过学习,比其他人少犯一些错误 —— 也能够在犯了错误之后,更快地纠正错误。但既要过上富足的生活又不犯很多错误是不可能的。实际上,生活之所以如此,是为了让你们能够处理错误。

绩效

绩效,特别是程序员的绩效,从来都是个谜(《程序员的绩效之谜》)。

一谈绩效,管理者就会说谁谁绩效很好,你看加了很多班,做了很多事。之前说了程序员交付的软件系统,如果说代码的资产和负债属性相当,大家可能会没有直观感觉。做个大家熟悉的类比,如果只是相当,这就像我们刷信用卡购买了一项产品或服务,满足了当下的需求,赢得了时间,但将来这笔欠款是要还的,不还就会付出代价。但如果是资产远大于负债,那就是刷了卡,后面却不用还了的感觉,那应该是种暗爽的感觉。后者才叫绩效好,但如何评估?谜。

最近看刘润的文章讲到 KPI 管理,提到了一个考核微软技术支持的办法。感觉挺有意思,如果把它换成程序员的场景可能就是这样一些关键指标:

  • A:需求难度系数,需求评审时架构师和程序员共同分析确定,达成共识
  • B:需求花费时间,越短越好,由程序员自己记录
  • C:完成需求提交的代码行数,越少也好,需要定制工具支持代码和需求关联的统计
  • D:完成需求数,越多越好
  • E:E = A x B x C x D 表示有效工作产出

其中 A 难度系数基于团队共识达成,因为大量的业务需求,其实很多难度近似。B 和 D 实际是两个互相制衡的因素,本来用 1 小时完成的,你自己记录成 10 分钟,那么完成的总的数量就会变少。C 展现了代码技术能力,完成同样功能的代码,资产性不变,越少的代码行数越少负债。这样当衡量有效工作产出(E)时,同样的 E,A 和 D 大的技术能力更好。

当然,这是一个简化的理想模型,但现实中程序员的考核恐怕比这个模型更简单粗暴。但它也指出了一个事实:晋升技术能力更好的人,他们解决更难的问题因而创造壁垒,产出更多的资产和更少的负债。而对于仅仅单一高绩效的人,不适合用晋升来激励,而应该用奖金来奖励。

...

为什么业界喜欢三到五年的程序员?按一万小时理论,三到五年接近或满足了这个量的编程训练,这个阶段就是产出代码的黄金时段,量大质优,而且各公司的“坑”(职位)也多。


写点文字,画点画儿,记录成长瞬间。
微信公众号「瞬息之间」,既然遇见,不如一起成长。

posted @ 2017-03-27 00:00 mindwind 阅读(...) 评论(...) 编辑 收藏