如何做好工作交接

Home

如何做好工作交接

向过去告别吧混蛋

Directory

本月算是正式提辞,向工作五年的洋葱告别。 五年一晃而过,瞬息而已却也深刻。 很多觉得重要的事情,在作别时却又显得当时太过执着了。

这辞职一大事情就是工作交接问题。 我觉得之前同事离职做得交接都迷迷糊糊的,没有意识到接锅侠后续的问题。 作为一个程序员该如何做好交接,算是在洋葱的最后一课了。

首先复盘以前同事交接的问题。个人层面:

  1. 交接文档表述不清楚
  2. 着急走人,有一了百了的心态

工作层面:

  1. 人的离职却可能也意味着项目的结束(这点我不太理解,项目不应该脱离于变动常存才对)
  2. 公司作为一个大的系统,小规模的崩溃、失败、缺失可以自愈
  3. 潜在细节交接不清,甚至如果不经历生产环境事故就没法表述清楚一些问题

这些年一直参与相对底层的技术基建工作,代码层面的还好说,苦得是业务层面问题都是踩坑换来的,怕是接锅侠不能立即理解。 比如一个参数为什么这么配置、一行未说明逻辑的代码其实是生产环境事故时候留下的、一个TODO为什么一直没有做的,千言万语,此时无语。

交接这事情,我可不敢马虎,想做的不一样点。


交接文档 其实关联到公司知识库是如何做的,我们初期主要使用石墨文档,由于价格问题今年大规模迁移到飞书文档。 我决定还是愉快的用公司自建的gitlab吧,把文档提交成一个git项目。 富文本服务虽然好用,但是存在变更可能。况且使用git的方式管理文档,也有很多诸如方便版本管理和Git Blame等功能。

更重要的是文档结构的设计,其实相当于要抽象不同项目的元数据 = = (数据开发中毒症状)以便于更直观的表述项目信息。抽象以后,项目文档结构如下:

标题 解释
项目地址 项目源码地址,标注说明分支功能(默认git flow)
功能 该项目的作用是啥,干了点啥
相关人员 与该项目的相关人员都写好,互相问问都是有用信息
项目部署 项目部署在哪里,怎么登陆过去看看
上线流程 说明如何做该项目的上线,其实主要是需要在这里写明一些重要的key和config
数据链路 该项目的数据从哪里,数据流往何处去
报警方法 该项目报警是如何设置的,如何触发报警
TODO 该项目后续想做点啥
其它 写点其余信息,比如该项目以往出过什么问题

其中数据链路部分最好画图说明,体现出项目在整个架构中的位置。 文档最底部我留下了自己的紧急联系方式,万一人离职锅还在,出了问题或许还需要帮忙修锅。 不能说是多管闲事吧,算是对自己的过去负责,离职初期还是需要做好支持,后期就要提升自己的咨询成本。

有好的文档,有靠谱的接锅侠,离职自然顺心很多。 但是其实也有背锅潜在风险,比如我的同事们经常吐槽一个已经离职两年同事留下的烂锅,以及有任何问题都可以继续无中生有移花接木为“前辈留下的错”。 需要与领导和同事定义好交接验收标准该项目在怎样的条件下完成交接,可以被认可为完整交接。 我担心的其实是人性的部分,人性的部分最好交给规则去解决。 交接人不要故意留坑,接锅侠不要盲信或后期甩锅。

所以,交接的一个底线是要亲手操作一顿,以实际操作结果为准。

此外,企业本身应该还会再计算一笔用人成本费用, 旧员工离职带来的附加成本,其实可以换算一下成人民币去考量,轻重缓急区分出来,有些将死的、试验性的项目其实可以干脆不交接。一个员工肯定在其岗位有重中之重的工作,需要离职人员、接手人员、项目领导等角色,一起卡死这个重要的事情做为验收标准。

有意思的是,我想了一下,互联网企业,大部分情况下纯粹人肉电池扛,似乎也不用考虑太多。 闭嘴,干就对了,敏捷! 有你写交接文档这日子,老子早就拿下了三个Story Point。