在写这个题目之前,光纠结就整整花了我近一周的时间,因为无论是谈论系统规划也好,畅谈技术精髓也罢,都会让 IT 人精神抖擞,一发而不可收拾,唯独提起人为视角的各种事件,却让我们左思右想,难以启齿。
问:为什么左思右想?难以启齿?
答:可能是怕得罪人,也有可能是怕丢了面子,或者是更为深奥的利益链趋势,站队效应……等等……等等……
不得不承认,除去由硬技能不过关而导致的原因之外,大部分技术人都不愿意主动转型至技术管理岗,“人心难测” 也许是主要原因吧。
记得就在一个月前的某次聚会中,与某位老友的对话片段:
…………
老友:如果再给我一次选择的机会,我还是继续想做程序员,我觉得我还是很喜欢做技术的
我:为什么这么说?做管理不好吗?人人都叫你老大,多风光啊,哈哈
老友:表面的风光有个屁用,其他不说,每年光离职这件事就可以把你搞残半年……
老友:人心难测,还是和冷冰冰的机器打交道来的干脆,‘他们’ 从来不会骗你……
我:哥,你究竟发生了什么……
…………
看着他把手里的黑咖啡像干掉啤酒一样一饮而尽,我也多少理解一点他的苦衷,就团队离职率这件事情的确叫人头痛。
对于技术管理者来说,员工离职会造成哪些影响?
问:啥叫技术管理者?是干嘛的?
答:通过别人(或一群人)完成某项(或一堆)技术目标的工作者(或岗位)
这是我自己总结的问答句,一般别人问我,我都这么回答。
无论你是 TeamLead,还是 VP,甚至是中国式 CTO,作为技术管理者,‘别人(或一群人)’ 的离开,对于技术目标的完成,或是经验传承,必然会受到直接或间接的影响。
用这些标尺来说明一下影响:
培训成本增高:人员流动,导致技术管理者的大量精力投入在招聘与新人培训上;
技术风险加大:客观点讲,无论注释或文档写得如何,由于接手别人代码而导致出现几次技术事故,应该是较为常见的事;
影响团队成员:“没有无缘无辜的爱和恨”,无论是对方福利好,还是原有领导不够有魅力,或者故意挖墙脚,某某人一走,某某人跟风也是很正常的;
继续重复踩坑:在技术领域,经验与踩坑永远是对立的,现在离职带走了经验,踩上重复的坑也就不稀奇了;
重复骚扰他人:前人问过的问题,后人继续问,不断地问,在某些技术领域或业务领域,可能只能盯着某人问,不被问的跳起来才奇怪呢;
该如何做,才能将经验留在公司并传承下来?
在瀑布式大行其道的时代,应该没人会怀疑,用堆积成山的文档作为传承的手段是最好的解决方案。
可随着迭代与敏捷的突起,“反人性” 的文档论被打了个半死,最后被拖到房间的一角,无人理睬。在大部分情况下,除了应付检查时出来亮个相之外,其余时间均被拿来当做调侃的对象。
可能有人会说:这叫什么话?你们公司不写文档吗?这话说的绝对了吧
文档只是一种经验传承的表达形式,而不是唯一途径,就算是写,也该分辨下写法。
每位技术管理者的风格都不同,履历与经验也存在着差异,所以基于这几点,我只能简单的谈谈自己所采取的方法:
轮岗制度——负责人(或核心人员)之间进行必要的轮岗,比如某系统在某个大版本升级之后,下一个版本必须由另一个系统的负责人负责,这样做,不但能够通过实战缓解当出现离职时,由于草率交接所引起的 “技术风险增大”,还能激发不同组之间的技术交流、技术学习;
学习手游的新人教程——玩过手游的都知道,新人都有一个向导带你走一圈(比如做任务),对于操作类的内容不写文档,在设计中就将操作手册结合到新人向导中去,今后无论多少新人来也不用再教一遍了;
CodeReview——老生常谈的话题了,除了做,除了 DevOps 的代码扫描之外,还加入了审计的环节,要求录音和录像;
强制要求核心代码输出类图——在研发环节,除了有专人负责之外,每一次改动都需要输出 UML 类图,并与代码版本保持一致(UML 文件与版本号一一对应);
对知识进行管理——引入知识管理 KM,通过制度来规避技术断层的风险,通过搭建知识管理体系是现今许多企业的一个应对措施;
提升个人魅力——这点就不多说了,青菜萝卜各有所好,对症下药,让大家认可你,以在你的团队工作为荣;
最后多说几句
来自某某咨询公司的权威统计,互联网+企业的 IT 相关职业的离职率每年均在 20%-25%
可能有人问:有那么高吗?是你们自己管理上出了问题吧?
首先,我们不去追究这个数字准确与否,但自从我踏入 IT 圈的那天起,这个工种的离职率高并不是什么稀罕事。
假如团队规模在 100 人,那么按离职率 20%-25%来计算,20-25 人/每年的人员更替是客观存在的。
我觉得,作为技术管理者,应当采取一些方法,尽可能的将他们的经验留在公司,并且传承下来,您说呢?
本文转载自头哥侃码公众号。
原文链接:https://mp.weixin.qq.com/s/d9Yvu3nhH4aGmyVQL7ZPYg
评论