去年4月30日，我结束了在孟买霍米·巴巴博士州立大学（HBSU）的最后一天工作。原本我以为这只是职业生涯的一次正常转身，没想到接下来的一年，我陷入了一场关于"远程交接算不算交接"的拉锯战。至今，我的工资尾款、离职证明、项目完成证书，一样都没拿到。
这不是一个关于技术难题的故事。这是一个关于技术人如何被行政流程困住的故事。
我在HBSU工作了超过一年。入职时的岗位是IT助理，但实际干的事情远不止这个头衔能概括的：从零搭建AI实验室、部署物联网实验室、开发和维护多个机构门户网站——secondarytrainingcollege.com、elphinstone.ac.in、iscm.ac.in、ifsm.ac.in、psych.hbsu.ac.in，这些平台的日常运维、紧急修复、功能迭代，全是我一个人扛下来的。
和很多热爱自己工作的开发者一样，我把这份工作当成了事业来经营。深夜加班、紧急上线、随时响应支持请求，这些对我来说是常态。不是因为不懂拒绝，而是真心觉得这些基础设施能让学校变得更好，值得投入。
但行政层面的体验完全是另一回事。
审批、签字、文件流转、跨部门沟通——这些本该几分钟搞定的事情，经常能拖上一整天。不是偶尔，是routine（日常性的）。当你习惯了技术问题的即时反馈（改完代码马上能看到结果），这种时间黑洞会让人产生一种强烈的错位感：你的效率在系统面前毫无意义。
离职那天，注册官找我谈话，希望我继续远程支持系统10天。我答应了，并且认真完成了所有交接文档，把各个平台的权限、代码库、运维手册整理清楚，线上移交完毕。
然后被告知：线上交接"不算数"，必须 physically（ physically ）回一趟校园。
问题是，我已经完成了你们要求的工作，文档也交了，系统也稳定运行了。现在卡住我的不是技术债务，而是一个关于"形式"的定义权。更讽刺的是，当初让我远程支持的是同一批人，现在说远程交接无效的也是他们。
这种体验在很多技术人身上并不陌生。我们被雇佣是因为能解决具体问题，但离职时却发现，解决问题的价值远不如"按流程盖章"重要。
过去一年，我尝试过各种沟通渠道。每次得到的回复都是"在走流程"，但流程走到哪一步、卡在谁那里、预计多久能完成，从来没人能说清楚。这不是某个具体人的恶意，而是一种系统性的模糊——当责任被分散在多个环节，就没有人需要为结果负责。
我现在已经开始了新工作，生活进入了下一阶段。写这篇文章不是为了报复，而是想提醒和我处境类似的人：在印度的公立大学体系（以及很多类似的机构环境）里，技术能力和职业保障之间，存在一道巨大的鸿沟。
如果你正在考虑类似的岗位，我的建议只有一条：从第一天开始留痕。工作记录、沟通截图、交接文档、责任边界，全部存档。不是因为你不够信任对方，而是因为当系统失效时，这些是你唯一能依靠的东西。
最后，想对所有经历过类似困境的技术同行说：你们不是一个人。这份工作最难的部分，从来不是debug或者架构设计，而是在糟糕的管理环境中，仍然保持专业主义。
技术债务可以重构，组织债务只能逃离。祝我们都能遇到配得上自己专业度的工作环境。
热门跟贴