这是一篇我最不想写的博客了。不过，随着部门里面一个可爱的小姑娘为了爱情不得不去上海工作同时也成功的拿到了SAP的offer，我不得不思考如何作好工作上的交接，毕竟法律规定的期限只有一个月的时间。

先说下背景。我们这个团队是公司最早的.net团队，也成为了很多.net路线产品的孵化基地。也就是说我们从国外接了很多.net产品的开发任务，然后再转给别人。这就意味着，我们团队里的人涉及到的产品很多，目前重点是两个，其中一个A是新模块的开发，另一个B的重点是升级维护。 A产品的开发是我们和另一个团队共同完成；而B是由我们单独完成，应该说全公司只有我们了解里面的所有细节，而且该产品是基于别人产品的二次开发，有很多的历史遗留问题还未完全解决，也有很多想法因为时间和成本的压力已经完成构思和设计，但是没有付出实践。而这些零零种种很琐碎的东西完全没有正式的文档去记录。

先说一下我对人员离职交接的态度。首先，团队里的萝卜不在了，我们需要填空，我们是按照这个坑来找个一样的萝卜还是跳出这个坑的框框找个其他模样的呢？以我的性格来说，我选择后者。第一点来说人和人是无法复制的，找一个类似的难度是很难的，毕竟国内做过长线产品掌握产品开发模式的人很少，同时又具备.net开发背景且熟练掌握.net 3.5各项技术的人又有良好英语能力的人还是很少的，如果再要求经历过敏捷实践那简直就是难上加难了。就像准备走人的MM说的，在面试中都可以体会到她的敏捷的能力绝对比那些面试她的人强。所以，我觉得应该跳出框框打开思路。人员离职是一个大的风险，但也是一个大的机遇。找到一个素质更好的人去补充到团队，对团队的长远发展是有利的，尤其是对别的团队成员也是一种冲击，可以汲取到新鲜的营养，互相补充。所以，对于招聘的新人的要求应该是根据团队剩余人员的知识结构分析出短板，然后尽量挖掘出那些基本功扎实同时又可以弥补短板的人才。应该忽略掉那些需要放到团队中自然成长的能力要求，比如产品化开发的思路，敏捷实践等，这不是一天两天的事情，而且也是教不来的，但是只要这个人本身注意观察善于学习，再加上本身拥有的成熟团队的潜移默化，给点阳光应该就可以灿烂的。

那么接下来说说交接如何开始吧？ 我觉得交接应该分为几个环节，离职者vs团队；离职者vs接替者；团队vs接替者。

离职者vs团队。这个应该比较重要。既然大家无法再续前缘，那么应该好聚好散。而且长期泡在一起，默契已达天成，交接起来无论是效率还是效果应该都是最佳的。首先应该梳理一下离职者在职期间从事的主要工作。从这点上来说，应用管理工具的团队会比较现实，比如我们用的敏捷商业软件，可以很轻松的过滤出某个人的任务列表，这样可以明确离职者大体上工作的侧重，虽说我们强调敏捷团队避免出现“专家” ，但是在一定时期内，任务还是有很强的相似性和连续性的。搞清楚大概的范围，就可以理清楚一个交接的思路。按照紧急程度来安排交接的顺序，最重要的肯定是还在手头上进行的任务，那些比较难的点，如果暂时还看不到改动的需求可以先往后放，毕竟要保证整个团队还是平稳的向前滚。如果团队资源允许尽量采取多人分摊的方式，这样可以缩短时间也可以利用这个机会把鸡蛋平均的放到多个篮子里面，如果全部堆到一个人身上，那么等到他离职的时候就又出现更麻烦的局面。既然是交接，而且又是在敏捷的框架下，很多时候的文档是缺乏的。所以尽量不要一下子就扎到代码层面，而是从业务上进行梳理，说清楚故事的来龙去脉，对于之前经历过反复讨论变更的更是要尽量了解变更的原因以便后续的讨论可以照常开展。通过梳理业务，也可以了解一个上下文，对于日后处理接口，出现代码与实现不匹配的时候也可以倒推回去。有些当时只是一个想法的地方，最好也可以用文档的方式予以记录，后续者如果要做的话可以借鉴参考。有些团队作的好的话，有比较完善的单元测试代码，这些代码也很有用，必须确保这些测试代码还是与源码匹配的，这样可以在后期作修改的时候有一个质量的保证，避免衰退的严重。如何验证交接的效果呢？以我个人来说，比较难去说采取考试的方式，因为比较是团队里的老人，又是在自身工作之外去承接的额外任务，考试显得合理不合情，但是可以通过一些简单的面谈的方式，比如可以抽样一些关键的任务，交接者可以说明基本的需求和上下文中所处的位置，与其他模块直接的关系或者接口等。对于代码逻辑有个大概认识，知道一个大概的逻辑，不需要去深究细节，细节可以等到真正去碰的时候再研究，因为代码这个东西真的是不作不知道，一作真奇妙，别说这是交接的人了，就是原作者隔个一段时间说不定自己想的和实际运行的逻辑都不匹配了。

离职者vs接替者。 如果这两者之间可以形成时间上的重叠，那自然再好不过了。但是因为接替者毕竟是全新的人，对所有任务都是两眼一抹黑。讲的太深不太现实，而且对信心的打击太大。所以，我觉得重点更应该侧重在点上面，就类似于导师那样。多讲解一些项目中用到的组件，一些常用的方法，业务上的基本知识，常用操作等，通过解决这些点，来缓解之后融入团队的困难。因为，未必后面的萝卜就是去填前面的坑的，更大的可能是从事一些新模块的开发。那么验证交接的效果就比较重要了。通常来说还是以基于演示的验证。比如让接替者写一个小的项目尽量多的覆盖知识点，在这个过程中也需要定期的进行团队的代码评审，以让团队中的人去了解这个新人的代码水平，也可以让新人尽可能的多去了解团队已有的风格，很多时候就是风格问题，并不是绝对的好坏，因为你个人的加入让团队修正不太现实，不仅成本太高而且感觉不好。

团队vs接替者。这个时候的团队就不仅仅是开发人员了。而是QA和BA都需要参与。BA需要给接替者进行业务上的培训，使其迅速的了解并掌握整个产品；QA则需要讲解一下基本的测试流程和与开发相关的一些规范，而且QA整理出来的系统用例通常也是作为新手上路的指路明灯。应该来说团队和接替者之间更应该侧重技术外的事情，比如业务，规范，流程等等。因为敏捷是按照产品线划分的逻辑小组，并非单一的功能团队。

这些都是我个人的基本想法，并没有什么特别之处。不过交接是一件很难的事情，不可能期望效果有多好，很多人在这个时候都想到如果有很多很多的文档就好了，其实文档多了，第一个未必符合现在的系统了，另一个看多了也会晕的，最直接的还是手把手的交接，虽然这样成本高，但是既然事实已经存在了，不妨一次性的做到位。免得留下潜在的隐患给团队，不知道啥时候就炸开了。。。