如何做好工作交接
发布时间:本月算是正式提辞，向工作五年的洋葱告别。 五年一晃而过，瞬息而已却也深刻。 很多觉得重要的事情，在作别时却又显得当时太过执着了。
这辞职一大事情就是工作交接问题。 我觉得之前同事离职做得交接都迷迷糊糊的，没有意识到接锅侠后续的问题。 作为一个程序员该如何做好交接，算是在洋葱的最后一课了。
首先复盘以前同事交接的问题。个人层面：
- 交接文档表述不清楚
- 着急走人，有一了百了的心态
工作层面：
- 人的离职却可能也意味着项目的结束（这点我不太理解，项目不应该脱离于变动常存才对）
- 公司作为一个大的系统，小规模的崩溃、失败、缺失可以自愈
- 潜在细节交接不清，甚至如果不经历生产环境事故就没法表述清楚一些问题
这些年一直参与相对底层的技术基建工作，代码层面的还好说，苦得是业务层面问题都是踩坑换来的，怕是接锅侠不能立即理解。
比如一个参数为什么这么配置、一行未说明逻辑的代码其实是生产环境事故时候留下的、一个TODO为什么一直没有做的，千言万语，此时无语。
交接这事情，我可不敢马虎，想做的不一样点。
交接文档 其实关联到公司知识库是如何做的，我们初期主要使用石墨文档，由于价格问题今年大规模迁移到飞书文档。 我决定还是愉快的用公司自建的gitlab吧，把文档提交成一个git项目。 富文本服务虽然好用，但是存在变更可能。况且使用git的方式管理文档，也有很多诸如方便版本管理和Git Blame等功能。
更重要的是文档结构的设计，其实相当于要抽象不同项目的元数据 = = （数据开发中毒症状）以便于更直观的表述项目信息。抽象以后，项目文档结构如下：
| 标题 | 解释 |
|---|---|
| 项目地址 | 项目源码地址，标注说明分支功能(默认git flow) |
| 功能 | 该项目的作用是啥，干了点啥 |
| 相关人员 | 与该项目的相关人员都写好，互相问问都是有用信息 |
| 项目部署 | 项目部署在哪里，怎么登陆过去看看 |
| 上线流程 | 说明如何做该项目的上线，其实主要是需要在这里写明一些重要的key和config |
| 数据链路 | 该项目的数据从哪里，数据流往何处去 |
| 报警方法 | 该项目报警是如何设置的，如何触发报警 |
| TODO | 该项目后续想做点啥 |
| 其它 | 写点其余信息，比如该项目以往出过什么问题 |
其中数据链路部分最好画图说明，体现出项目在整个架构中的位置。 文档最底部我留下了自己的紧急联系方式，万一人离职锅还在，出了问题或许还需要帮忙修锅。 不能说是多管闲事吧，算是对自己的过去负责，离职初期还是需要做好支持，后期就要提升自己的咨询成本。
有好的文档，有靠谱的接锅侠，离职自然顺心很多。
但是其实也有背锅潜在风险，比如我的同事们经常吐槽一个已经离职两年同事留下的烂锅，以及有任何问题都可以继续无中生有移花接木为“前辈留下的错”。
需要与领导和同事定义好交接验收标准 ：
该项目在怎样的条件下完成交接，可以被认可为完整交接。
我担心的其实是人性的部分，人性的部分最好交给规则去解决。
交接人不要故意留坑，接锅侠不要盲信或后期甩锅。
所以，交接的一个底线是要亲手操作一顿，以实际操作结果为准。
此外，企业本身应该还会再计算一笔用人成本费用, 旧员工离职带来的附加成本，其实可以换算一下成人民币去考量，轻重缓急区分出来，有些将死的、试验性的项目其实可以干脆不交接。一个员工肯定在其岗位有重中之重的工作，需要离职人员、接手人员、项目领导等角色，一起卡死这个重要的事情做为验收标准。
有意思的是，我想了一下，互联网企业，大部分情况下纯粹人肉电池扛，似乎也不用考虑太多。 闭嘴，干就对了，敏捷！ 有你写交接文档这日子，老子早就拿下了三个Story Point。