一位入职一年多的开发者兼项目负责人，在向老板提出更换项目负责人之后发现：让他疲惫的不是项目难度，而是责任与权限的不对等。这篇自述记录了一次相当完整的职业方向复盘。
发帖人自述，他手上的项目周期只有约两个月，且跨中秋、国庆等节假日，实际可用工作时间被进一步压缩。项目采用团队此前并不熟悉的新开发工具／低代码平台，甲方采购该平台，需要基于平台做开发和二次开发，团队此前只接受过较短时间培训，实际项目经验不足。
项目已知需要对接约 4 至 5 个外部系统，接口、配合程度和联调效率并不完全由项目组控制；开发人员是他此前面试招聘进来的，能力水平在招聘时基本已知，前期也做过人员协调，但人员仍在不断变化。他认为问题已不是"再多协调一下"，而是核心人员稳定性本身成了项目风险。
长期异地驻场的要求，是在项目启动会议阶段才明确的，启动之前他并未提前获知。而长期异地驻场，恰恰是他明确不喜欢、甚至比较抗拒的工作方式。他把这些风险归结为：短周期 + 新平台 + 人员不稳定 + 多系统集成 + 节假日影响 + 异地长期驻场，因此项目初期就判断按期交付风险较高。
基于此，他曾向老板提出希望能由其他人负责这个项目。他自述原因有四层：一是看到多个风险同时叠加，而非单个技术难题，人员变化影响开发进度、新工具不熟影响效率、外部系统联调又压缩时间；二是对长期异地驻场本身抵触，且不愿把个人工作边界伪装成项目风险；三是对这个新平台没有兴趣，心理动力不足；四是已经比较疲惫。
他描述，过去一年多职责一路增加：最开始管几个人，后来管整体开发人员，后来开始带项目，现在要承担整个项目的综合结果。职责涨得很快，心理状态并没有同步适应。
在他的观察里，普通开发人员的工作方式是领导安排任务、自己负责开发、遇到问题反馈、做完自己的工作，即使完成得不好，承担的也是具体任务层面的责任。而项目负责人要面对的是：项目能不能按时完成、人够不够、人员是否稳定、技术方案是否可行、新平台能否支撑、外部系统能否按时联调、客户是否配合、进度出问题怎么办、最终由谁解释。他的感受不是工作量大，而是别人对自己的任务负责，负责人要对整个项目的不确定性负责，这是一种持续性的结果压力。
他把心累的来源指向所在公司的项目负责人模式：公司希望负责人做到"发现问题、分析问题、提出解决方案，再由老板据此决策"；而他更习惯"发现事实和风险、把问题讲清楚、把需要决策的地方交给老板，再按老板的决定执行"。他不喜欢在信息并不完整的情况下替管理层做大量决策，尤其知道老板情绪变化比较明显，方案不符合想法时可能明显感受到不满，于是容易陷入"我到底该提什么方案才是老板能接受的"这种猜测管理层意图的负担。
他还提到信息与责任的不对称：人员由公司整体资源决定，人员是否稳定不完全由他控制，新工具不是他选的，平台能力不掌握在他手里，外部系统是否配合不由他决定，客户需求变化不由他决定，长期异地驻场甚至是启动时才知道；但项目一旦出问题，负责人天然是首先需要解释的人。结果是责任向负责人集中，而决定结果的条件并没有同步给负责人。
这次项目结束、并提出更换负责人之后，公司的工作安排也发生了变化：原来由他承担的一部分整体开发人员管理和协调工作，开始逐步分给其他人。他自述能理解公司可能有自己的考虑，不想简单理解成"公司是在逼我离开"，但感受比较明显——过去一年多职责一直在增加，现在原有职责开始交出去，他开始重新思考自己的定位，也暂时不想仅凭这次调整判断公司的长期意图。
他承认自己沟通能力不算强，习惯少说、多做。作为技术人员时这种方式问题不大，成为项目负责人后开始出现局限：负责人必须主动同步信息、暴露风险、提前沟通、组织资源、提出方案、推动决策。他认为自己的问题未必是"没有管理能力"，而是过去主要依赖技术执行能力，突然需要大量沟通、协调和向上管理，而这部分能力没有得到充分训练。
让他真正纠结的问题，不是"这个项目能不能做下来"，而是"以后到底愿不愿意一直做这种项目负责人"。他自述更适合对技术结果负责，而不是对整个项目的不确定性负责：系统架构怎么设计、Java/Spring 怎么实现、数据权限怎么设计、数据库怎么设计、微服务怎么拆分、AI 如何进入业务系统、Kubernetes 怎么部署、技术问题怎么定位、方案有什么风险——这些虽然难，但他能靠自己的技术能力直接影响结果。
而负责人面对的大量问题是人员是否到位、是否稳定、客户是否配合、外部系统是否配合、领导是否批资源、是否需要驻场、进度是否受组织因素影响、出问题后如何协调各方——这些并非纯粹的能力问题，而是资源、组织、关系和决策问题。他逐渐发现，自己愿意为能控制的事情承担责任，但不太愿意长期为大量无法控制的不确定性兜底。
他也不认为自己属于"抗压能力差"或"遇到困难就退缩"：入职一年多职责持续增加，说明公司一直在把更大的责任交给他。真正的问题可能是职责涨得太快，而他从未确认过自己是否喜欢这条路线。这次是第一回比较明确地感到：能力上可以做，不代表职业上愿意一直做。
因此他判断自己更适合"高级开发 → 技术负责人 → 架构师／技术专家"这条路径，而不一定适合"开发 → 项目经理 → 多项目管理 → 纯管理"。他并不认为技术负责人不需要沟通，只是沟通内容更偏技术方案、架构设计、技术风险、任务拆解、技术决策和实现质量；而他不太适合长期把主要精力放在人员协调、客户关系、进度催促、资源争取、跨部门协调以及项目综合结果兜底上。
他的结论是：职业发展不应只问"公司愿意让我承担什么"，还要问"我自己愿意长期承担什么"。如果长期处于高责任、高不确定性、资源受限、大量协调而自己又缺乏兴趣的工作模式中，很可能会持续消耗。他现在要做的不是证明能否扛下这个项目，而是想清楚未来五年自己究竟想成为什么样的专业人员。
从"能不能做"到"愿不愿意一直做"，这个转弯本身就值得记录。当责任、资源与决策权长期不对等，及早辨认自己的边界，可能比硬扛完一个项目更重要。