人才的平台化建设探索

21世纪最贵的是人才

最近各团队缺人的喊声此起彼伏,每当数人头时又面临能力不足的问题,正值大量员工的入职之际,来说说我对能力培养的探索。

现在一个团队的人才培养,一般挑不到最好的来,一个项目非常优秀的人也是屈指可数的。

如何借助现有的最优秀的他们完成人才的建设,是一个非常重要并且很有意思的事情。

人才培养的困境

初做开发技术推广时豪情万丈,团队之初倾其所有的手把手教,然而激情褪去,人员频繁变动,我的动力又在哪里呢?

  • 重复的工作总让人厌烦

    曾经记得一个代码导入培训反复多次培训,面对不同的人群,尽管有培训费,但是这种无法提高自己的重复工作,对于我这种人来说,只会产生厌倦。

  • 人品总是不够用

这项你还别说,人生处处有惊喜,当你有幸分到一个可遇不可求的人才时,你就会发自内心的告诉自己,惊不惊喜?意不意外?太酸爽了!

但是大多数时候你不会得到一个你特别满意的人,尽管你可以想到各种办法提前获取到人员简历,但是没开始干活之前,谁知道呢,这完全拼人品。

  • 欲说还休的培训

做过不少技术类的培训,例如CC培训,有很多心得有很多原则,听培训的人都觉得挺爽,也觉得内容挺好。

后面也有幸看到部分参加人员的代码,这直接让我丧失了做这种培训的信心,因为实际中他们压根就没那么做。

于是我就假装这些培训或者某些技术类的运动能影响到那么几个人吧。

曾一度认为,我们的优秀人员全是招来自己成长的,而不是我们培养出来的。

我们普遍缺人

然而在我们的工作中,缺人的呼声此起彼伏,我们真的是缺人数吗?不是,我们缺的是能干活的人!

在实际中,我们总是会面临这么几个问题:

  • 我们缺很牛的开发人员
  • 我们的业务门槛比较高
  • 我们需要全业务协议栈人才

试想,我们要多牛的开发人员:我们开发的每个需求都要用到所有的设计模式和所有的语言特性吗?会涉及到所有的业务吗?肯定不会是这样的。

其实我们的要求是特别具体化的。甚至如果我们每个团队每个人都达到团队牛人70%的能力,我们团队就不会有人力缺口了!

如何做到团队牛人能力的共享,也即如何把团队牛人做成服务呢?就是能力的平台化建设。

定制化的能力培养平台

人才的缺口和人员能力培养的繁琐促使我们希望能以一种相对简单的方式进行。

能力的培养要解决两个问题:

  • 练什么
  • 怎么练

练什么

每个团队的常用的技能并没那么复杂,根据一般软件开发中的几个方面逐一来说。

  • 被开发对象
    需要了解被开发对象的基本知识,无论是算法还是流程,还是设计原理,其实都有指定书或者文档。

  • 开发工具
    包括开发工具的部署以及IDE的常用快捷键和常用的调试方式

  • 特定语言技能
    基本语言的语法和特性,甚至要求的各种设计原理

  • 其他
    常犯的开发错误,最基本的测试技巧等

怎么练

这个就比较简单了,练什么的问题解决了以后,怎么练就显得没那么重要了,这是基于HR招人基本解决了人员的基本素质问题。但是如何反馈学习效果就显得比较重要。

反馈的方式有考试,也有总结反馈的方式。这里选取了一个更理想的方式,自动化考试,即能力的平台化建设。

平台化

这个其实已经不是一个新鲜的话题,例如我们的招聘有题库,面试也有套路,团队人员能力同样可以有。

当前有很多oj平台可以用,它们可以完成最基本的,例如zte的cc oj等,团队的甚至可以更简陋点,例如wiki也可以解决。

这里主要讨论如何获取培养的进度,因为笔者也曾有让新人很懵逼的看了一个月资料的尴尬,也有就看几天就让去干活的极端情况,当然最终的结果总是不太令人满意。

以开发能力为例,引入“科举制”,每一项能力是否掌握,就使用固定的考题来进行考试,制定人员能力矩阵,来获得能力培养结果。

TIPS:没有自动化平台,小团队内也可以手工阅卷

谁建设

建设的原则:采取谁受益,谁建设。

这里受益的人员主要包括培养师傅,被培养对象。

培养师傅可以以题库建设的方式制定学习计划,徒弟在学习作答完善题目,在得到团队或培养师傅反馈时进一步改善题库。

最后一公里

道理都懂,一到实际中就蒙了,实际碰到的问题比题库更加复杂,可能需要综合这些知识才能解决,需要化解最后公里的问题。

团队如何来做才能完善部分呢?其实《从小工到专家》一书中指导思想,一起工作即可。敏捷实践中就可以直接拿来用:

  • 代码走查

每一次check in代码时都应该走查,此时是发现和解决问题的契机。

  • 结对开发

结对开发也是一个很好的学习方法,这里如果有一定进度要求且需要培养新人时,可以尝试做。

  • 试错

基层管理者需要在培养过程中克制冲动,不要指定某个事情就一定是某个人做,尽管也许在某个阶段他真的合适,但是你可能少了一个可以解决此类问题的人才。

管理者认为的紧急并非真的就一定紧急,这类其实也可以放在试错中。

人才培养的反馈

度量的意义在于比较,比较有同比和环比,固化下来的对比数据才有意义。

人才培养的度量推荐从外在表现上进行对比,笔者常用的几种对比如下:

  • 人均史诗故事数
  • 故障泄露数
  • 人均代码行数

度量的数据不要过分在意这个数据是否百分之百合理,放在一季度,半年,一年的时间中来看,其实这个误差完全可以忽略。

后记

能力的平台化,不仅仅是针对dev,同样可以针对qa,故障定位,BA,管理者。

这个建设犹如滴滴打车一样,先可以打出租车,然后可以快车,最后可以顺风车。。

最后,衷心希望团队没有难做的人员培养!

你可能感兴趣的:(人才的平台化建设探索)