我的一个字节朋友：用100次离别领悟的职场厚黑学

Posted 2023-03-04 测试萌萌

大家经历过最崩溃的瞬间是什么？

通知加班？周末取消？项目延期？甲方BB？

“不，你这些对于一个合格的职场人来说，心里是泛不起一点波澜的。”

朋友说：

“你应该没怎么经历过离职交接，还是年底突然的那种。”

“那你今天想聊什么？”我问他

“聊心态、聊离职交接、聊职场哲学。”

他抚摸着头上并不茂盛的头发说：

“早明白这些，或许它们应该会陪我更久一点的。”

实在是没想到，都到年底快收尾的时候，还要突然接手离职人员的项目；

不断拉扯和管理内心情绪，避免原地裂开；

年度中再次经历突发的交接事宜，并且团队要在极短的时间内完成所有事项的交接流程；

毫无征兆的变动必然会引起一系列问题，最直接的就是影响团队现有节奏进度，需要重新调整和规划；

人员的小规模变动，对部门甚至公司产生的影响是显而易见的，道理都懂；

但是从理性上思考，这个问题并非是无解的，是可以在各个团队中，进行内部消化的；

而人力减少带来的成本降低，以及确保公司的可持续，这是极具确定性的，也是核心目的；

所以感性上说，这个梦幻的职场，可能真的是"爱了"；

如果是常规情况下的离职流程，交接并不是一件复杂的事情，因为有时间有心情来处理这事，好聚好散；

然而最骚的是，奇袭一般的裁员手段，几分钟谈话结束直接走人；

丝毫不顾及由此带来的影响，认定留下的人应该兜底相应的责任，实现无缝接坑；

当然并不是什么公司都有底气这么做的，大部分还是在裁员通知后，留有一定的时间处理交接事项；

对于交的过程是否有质量，完全看接的一方是否聪明；

从感性上分析，都已经被裁了自然要牢牢把握摸鱼的机会，根本不会在意交出的事项谁来维护，不反越防线就不错了；

而压力会直接传送后闪现到接的人正上方；

面对被动离职的交接，确实很难妥善处理，情绪化容易导致事情变质，能真正理性对待的并不多；

交接涉及到三方的核心利益：公司、交出人、接手人，不同角度对待这件事件，态度完全不同；

公司，并不关心交接的质量，只要项目有人兜底即可；

交出方，感性上说直接敷衍交接单上的流程即可，并不在意后续的影响；

接手方，项目交接完成后的第一责任人，可能会关心项目的质量状况；

至于说接手的人能否有时间，有能力，有心情接下这种天降大任，可能除了自己以外，不到出问题的时候关注的很少；

因为项目交接过程没有处理好，从而导致后续的事故与甩锅，情绪化的现象并不少见；

如果是在内部矛盾突出的团队中，由此引发的离职效应也并不少见；

人的情绪真的是很奇怪，能让复杂的事情变的简单，也能让简单的事情变的离谱；

情绪上头的时候，事情本身是否真的复杂就已经不太重要了；

接手方最大的问题在于吃力不讨好，如果接了一个质量奇差的项目，意味之后很长一段时间内，工作状态都会陷入混乱的节奏中；

对于大部分研发团队来说，都是存在排期规划的，如果被交接的项目横插一脚，重新调规划影响面又偏大；

向上反馈，多半是回答一句：自行消化；

何谓自行消化，就是占用空闲时间处理，比如下班后，比如周末，比如摸鱼，这些都是对工作情绪的持续伤害；

最终兜底的个人或者团队，可能需要带着夜宵去公司搬砖；

吐槽归吐槽，裂开归裂开，成熟的搬砖人不该表现出明显的情绪化；

先捋一捋在面对离职交接时的注意事项，虽然说离职后有一个过渡期，但是真正涉及交接的时间通常一周左右；

作为接手一方，自然期待的是各种文档齐全，对于坑坑洼洼的描述足够清楚；

然而对于被离职的交出方，会带着若隐若现的情绪化状态，很难用心处理交接事项，能不挖坑就已经是良心队友了；

接手方作为后续的兜底人员，兜不住就是一地鸡毛；

如果兜住了呢？那是职责所在、理所应当、不要多想、安心搬砖；

面对项目交接，这种隔三差五个月就会突发的事，完全可以用一套固定的模式和节奏去执行；

强烈建议：不排斥、不积极、不情绪化；

但是在处理的过程中要理性且严谨，这样可以规避掉许多可能出现的麻烦，毕竟签了交接单，从此该项目问题根本甩不开；

职场几年，在多次"交"与"接"的角色转换过程中，总结以下几点是需要注意的；

文档，信息的核心载体；

不管项目涉及多少文档，照单全收；

如果文档严重缺失甚至没有，直接在交接单上写明情况，并且得加粗划重点展示；

文档和项目的维护极有可能是线性不相关，但是手有文档心里不慌，因为方便后续再把项目交接给其他人；

所以，敷衍一时爽，出事火葬场；

代码工程，坑与不坑全看此间；

接到手里的项目，是否会导致情绪崩塌，全看项目代码工程的质量，遇上一堆烂摊子，心情会持续的跌跌跌，然后裂开；

直接把人打包送走的情况也并不少见；

如果代码工程质量极高，架构设计稳定，组件集成比较常规，分包井然有序，悬着的情绪可以适当下落；

库表设计，就怕没注释；

对于数据库层面的设计，与代码工程和业务文档三者相辅相成，把握其中的主线逻辑即可；

但前提是表的设计得有清晰的注释，如果是纯中式英文混搭拼音，且缺乏注释，必然会成为解决问题的最佳卡点；

核心接口，应当关注细节；

从项目的核心业务中选出2-3个复杂的接口读一读；需要将注意点放在细节逻辑上，给内心积蓄一丢丢解决问题的底气；

熟悉接口的基本思路：请求从客户端发出，业务服务的处理逻辑，对数据层面的影响，最终响应的主体；

遗留问题，考验职场关系的时候到了；

公司一片祥和的时候，员工之间还可以做做样子；

但是已经走到了一别两宽的地步，从感性上来说只要不藏着掖着就行，还想窥探别人安稳摸鱼的秘密，确实想的不错；

老练的开发常干的事，为了解决某个问题临时上线一段代码，处理好后关闭触发的入口，但是会保留代码主体；

这还算常规操作，最骚的是在本地写一段脚本工具解决线上的问题；

这些隐藏的接口和脚本只有开发的人自己清楚，如果不给个说明文档，这不单是挖坑，还顺手倒了一定比例的水进行混合；

结尾事项，寒暄几句还是要的；

安全意识好的公司，会对员工的账号权限做好备份，以便离职时快速处理，不会留下风险隐患；

在所有权限关闭之后，接手人就可以在交接单上完成签字仪式；

交接完成后还是得适当的寒暄几句，万一接了个坑，转头就得再联系也不稀奇，所以职场留一线方便语音再连线；

年度收到的离职交接，已经累计好几份，对这种事情彻底麻了；

事来了先兜着，等兜不住的时候自然会有解决办法；

抗拒与烦躁都不会影响流程的持续推进，这种心态需要自己用清醒的意识不断的说服自己；

最后：下方这份完整的软件测试视频学习教程已经整理上传完成，朋友们如果需要可以自行免费领取【保证100%免费】

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！