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