[观察职场] 遇上不靠谱的领导，是跑还是跑？

论在不靠谱的领导手下干活有多痛苦

本故事纯属虚构，如有巧合纯属一样倒霉。

在山的那边海的那边，有一间不大不小的公司。有个小组负责赶工一个项目。小组领导叫张三。

在整个项目期间，张三自始自终都认为自己设计的方案，绘制的流程图，流程清晰，传达内容简单易懂。但是每当有人在会议上提出一些疑问时，只要三两句没有对张三的意图，还没来得及解释，张三就要开始 diao 人。并认为所讨论的问题及其简单，不应该在会议上来讨论。会议气氛异常压抑，以至于没有人敢在会议上提出发现的问题，只能随声附和。 进度沟通会议直接沦为一个完完全全的进度汇报会议。在实现过程中明明发现了方案上的不合理，对需求或者实施细节有疑问，或者发现组内对某个东西没有形成统一的共识。都无法在会议上解决。会议最终流为形式。并且张三一直认为会议时间过长浪费时间，让组员会下自行沟通。但是能在会议上提出来的问题，就是会下通过互相确认得出结论，或者结果不明确，才会在会议上提出。并且方案由张三一人设计，并且也只是前期在会上，草草过了一遍，讲着讲着有是让组员自行去看资料。

结果就是整个项目组开始 996 ，并且不断的推翻之前的实现。因为临近验收总是发现实现出来的功能不能满足需求。但是组员实现过程中又发现完全按照方案去实现是做不出来的。方案有明显的缺陷，比如要求实现的逻辑，在方案限定的三方开源框架上根本无法实现。又比如一些项目核心的功能，依赖三方开源框架，但是这些功能在方案调研阶段完全没有去验证。直到进行到相应模块了才发现实现不了。并且受限于三方开源框架，完全无法实现。也没有留有时间去研究。整个项目进度非常的赶，排期非常不合理。经常出现卡点，张三也不管组员提出的问题，只是一味的 push 组员。 在数周的 996 之后，项目依然无法上线，只能继续延期。

整个项目过程中，同一个东西，有多少个人就有多少中理解。根本无法确定下来如何实现。询问多个组员仍然无法获取到准确的信息，存在严重的信息没对齐。 在无法询问张三的情况下，只能组员自己想办法实现，但是最终实现出来的功能，但凡不符合变动后的场景又或者压根在方案中就不存在，张三就会指着组员没有按照方案去实现。或者指责一个完全在于方案中的功能怎么没有做。

并且需求完全是不确定的，今天通知出了新的调整，让赶紧实现，然后明天就有调整了。

不规范，等完整的需求文档出来再开发，事半功倍

作为多家公司的打工人，我只能说遇到靠谱的领导概率不算很大，还是看钱吧

帮你整理好了 以下是精简后的列表形式： 员工对领导张三的看法 1. 领导在项目管理中的问题 • 自信过度：对自己设计的方案和流程盲目自信，忽视他人意见。 • 沟通无效：会议气氛压抑，问题得不到有效讨论，变成单向汇报。 • 方案独裁：整个项目方案几乎是他个人的独角戏，未充分讨论和验证可行性。 2. 项目实施中的问题 • 需求模糊：方案细节不清晰，组员对需求理解各异，信息混乱。 • 频繁变动：需求反复无常，导致项目组疲于应对调整。 • 技术不实：方案依赖不切实际的三方框架，导致无法落地。 • 无视反馈：对组员提出的问题漠视，只是一味强行推进进度。 3. 组员面临的困境 • 高强度加班：长期处于高压 “996” 状态。 • 重复返工：实现功能后发现与需求不符，不得不推翻重做。 • 批评随意：功能不符合领导期望就遭指责，忽视方案本身的问题。 4. 项目整体结果 • 进度混乱：排期频繁调整，各种卡点问题突出。 • 延期失败：高强度工作后项目仍无法上线，只能不断延期。 • 团队士气低落：无明确方向，组员相互之间理解不一致，工作效率低下。 5. 员工的感慨 • 深感无奈：在这样的领导下工作，难以有效开展项目，令人身心俱疲。 • 选择困境：逃离还是继续挣扎，成为所有组员的难题。

没事，熬过去就好，都是演戏，比谁能顶

@william807803 我说戾气咋这么大，不能好好说话？看了过往的回复，原来是喷子一枚，block

技术员是拿文档说话的，你说他的文档不行，那你的文档呢？ 建议你把具体的技术问题好好写个文档发给他，看下他在事实面前的反应。

转人工

你在写论文么，应该你的领导赶紧要跑吧，远离你，写的东西繁琐又啰嗦，让人懒得看

AI 优化之后的版本： [职场困境：逃离 “不靠谱领导” 的漩涡？] 在职场这片江湖中，遇到不靠谱的领导，那滋味可谓是 “如人饮水，冷暖自知”，个中痛苦，只有亲身经历过的人才懂。今天，就来聊聊在这样的领导手下干活是怎样一番 “酸爽” 体验。 在那遥远而又熟悉的城市角落，有一家规模适中的公司。其中一个小组正紧锣密鼓地赶工一个项目，而这个小组的领导，便是大名鼎鼎（此处应是 “臭名昭著”）的张三。 从项目启动之初，张三就对自己精心设计的方案和绘制的流程图自信满满，觉得那流程清晰得就像阳光大道，传达的内容简单易懂到如同幼儿识字卡片。然而，每次项目进度沟通会上，只要有人对他的方案提出疑问，还没等人家把意图说明白，张三就立刻开启 “暴走” 模式，对提问者一顿数落。在他眼里，那些被提出来讨论的问题简直简单得可笑，根本不配占用会议时间。久而久之，会议气氛压抑得如同暴风雨前的低气压，让人窒息。组员们被张三的 “威严” 震慑，即便心中有诸多疑惑，也只能默默咽下，选择随声附和。于是，原本应该是集思广益、解决问题的进度沟通会，硬生生地沦为了单纯的进度汇报会，毫无实际价值可言。 在项目的实际推进过程中，组员们明明发现了方案存在不合理之处，对需求的理解模糊不清，或者在实施细节上存在争议，甚至连组内对某些关键内容都未达成统一共识，可这些问题在会议上根本得不到解决。张三总是固执地认为会议时间过长是在浪费大家的生命，大手一挥，让组员们自行在会下沟通解决。但实际上，能在会议上被提出来的问题，往往都是经过会下反复确认仍无定论的难题，或者是结果尚不明确、急需集体讨论的关键事项。而且，整个方案从头到尾几乎就是张三一个人的 “独角戏”，前期在会上也只是草草过了一遍，讲着讲着就不耐烦地让组员自己去看资料，仿佛那些复杂的方案细节都应该是组员们与生俱来就该明白的常识。 如此这般，直接导致整个项目组陷入了 “996” 的无尽深渊，而且还在不断地推翻之前的劳动成果。为啥呢？因为临近验收时，总是发现实现出来的功能与实际需求相差甚远。组员们在实现过程中更是苦不堪言，明明严格按照方案去做，却发现根本行不通。这方案就像是一座摇摇欲坠的危楼，到处都是明显的缺陷。比如说，要求实现的某些关键逻辑，在方案限定的三方开源框架上根本就是 “天方夜谭”，无法实现。再比如，一些项目核心功能严重依赖三方开源框架，可在方案调研阶段，张三竟然完全没有去验证其可行性。直到项目推进到相应模块，才惊觉此路不通，而此时受限于紧张的项目进度和三方开源框架的固有特性，根本没有时间去深入研究解决方案。整个项目进度就像一辆失控的马车，在崎岖的道路上疯狂颠簸，排期混乱得一塌糊涂，各种卡点频繁出现。可张三呢？他对组员们提出的问题视而不见，只是一味地挥舞着 “鞭子”，拼命地 push 组员们往前冲，仿佛只要大家足够努力，就能用汗水填平这些方案本身带来的巨大鸿沟。 就这样，在数周高强度的 “996” 之后，项目依然未能上线，无奈只能继续延期，就像一艘在狂风巨浪中迷失方向的破船，看不到靠岸的希望。 在整个项目过程中，信息混乱的程度令人咋舌。同一个功能模块，不同的组员有着不同的理解，仿佛每个人都拿着不同版本的 “剧本” 在独自表演，根本无法确定到底应该如何实现。组员们相互询问，得到的也是五花八门的答案，信息严重不对齐。在无法从张三那里获取准确指导的情况下，组员们只能凭借自己的智慧和经验想办法解决问题。但悲催的是，好不容易实现出来的功能，只要稍微不符合那不断变动的业务场景，或者在张三那模糊不清的方案中压根就没提到过，张三就会不分青红皂白地指责组员没有按照方案执行，或者质问为什么方案中明确有的功能却没有实现，全然不顾方案本身的混乱和不合理之处。 更让人崩溃的是，项目需求就像六月的天气，变幻莫测。今天刚接到通知说要进行某项新的调整，要求组员们赶紧实现，可还没等大家缓过神来，明天又有了新的变动，组员们只能在这反复无常的需求浪潮中疲于奔命，被折腾得晕头转向。 遇上这样不靠谱的领导，到底是该果断逃离，还是继续在这 “水深火热” 中苦苦挣扎？这恐怕是每一个身处其中的职场人都不得不面对的灵魂拷问。