职场中，我们总会遇到各种性格的人，有些人灵活、善于沟通，和他们合作顺畅高效；但也有一类人，极端固执，认定自己的方案天下无敌，谁说服都不听。与他们合作，轻则痛苦不堪，重则项目进展困难、停滞不前。

我自己也曾经亲身经历过这样一位极度固执的同事——当然，每个人都有自己的风格，只是就我的真实体验，分享一下与这类人的合作究竟会有多困难、到底为什么难合作，以及在职场中如何识别并避免这种陷阱。

一、认定自己方法“尽善尽美”，却从未真正实践过

之前我曾短暂和一位所谓的“资深工程师”合作过，他在做技术方案时极端自信，总喜欢挂在嘴边的一句话就是：

“方案一定要规范和严谨，这些方案经过了XX轮深入调研！”

然而，他所说的“深入调研”究竟是什么呢？无非就是不断从各类博客、CSDN、知乎问答、Gitee 和 GitHub 项目里拼拼凑凑，把各种看起来高大上的名词汇总到文档里，来支撑自己的观点。

可是尴尬的是，这个人从来没真正动手写过一行代码，也没真正用数据分析验证过他的方案，完全停留在“文档大师”的层面。刚开始听他说话，或许你还会佩服一两天，觉得这个人研究得真细致。但时间一长，大家就会发现，这些调研根本不落地，毫无应用价值，纯属“纸上谈兵”。

二、非专业人士，却喜欢瞎指挥专业人士

更令人抓狂的是，这种固执的人往往喜欢越俎代庖，对专业领域指手画脚。我遇到的这位同事，既不是 AI 背景出身，也没做过数据分析的工作，也从未真正研究过机器学习算法，甚至连精确率和召回率等基础概念都没搞清楚，却偏偏总是要求我们的算法工程师必须使用“某某特定算法”，其他任何方案他都一律否决。

我们的算法工程师本身经验丰富，尝试了大量实践验证的算法，都能稳定高效地实现业务需求。可每当提出方案时，这位“固执大哥”都要反复质疑：

• “你们这个算法是否具有先进性和高可用性？”
• “最新的 CSDN 博客说，这个算法 XX 公司已经弃用了！”
• “某个知乎大 V 说，算法必须是 XXX 架构才行！”

更让人无语的是，当你和他详细交流算法细节时，你才发现他连“过拟合”、“泛化能力”这样的基础术语都讲不清楚。他所谓的“坚持”，只是盲目地遵从网络上的只言片语，缺乏任何实践经验，却偏偏一口咬定自己才是对的。

三、盲目追求“先进技术”，却忽略团队成本和效率

同样，他也有另一个典型的执拗之处，那就是非要用一些奇怪的编程语言、技术框架来实现功能——只因为这些语言看起来“先进”、“新潮”、“未来导向”，却根本不顾团队真实的技术储备和学习成本。

比如，我们团队原本都是用 Java、Python、C++ 这样主流语言进行开发，可在这位固执同事看来，这些技术都太“普通”了。于是，他非要推广某些小众语言，甚至连听都没听过、社区也不成熟的语言作为项目标准。他给出的理由永远都是：

• “这个语言社区虽然小，但代表未来趋势。”
• “主流语言太普通了，用这个语言才能体现我们的技术先进性。”

但事实上，如果按照他的方案去执行，那么结果就是灾难性的：团队为了适应他所要求的语言和工具，将会耗费大量时间去学习新的技术；项目周期和交付时间大幅延长，原本简单的功能居然被折腾成了“技术难点”。

四、不断重复造轮子，浪费巨大资源

更奇葩的是，这类固执的人通常还热衷于重复造轮子。明明团队中已有其他成员花了大量精力开发了一套工具，并且已经在实际项目中投入使用了。他却非要坚持用自己喜欢的语言、框架、工具重新开发一套功能完全相同的东西。如果真正能够开发出来也算产出，但是他却长期停留在 PPT 上，甚至一两年都没有任何实质性的代码产出。

投入巨大资源，最后得到的东西无非是另一个重复的工具。而这个“新工具”并不会比原有工具好用，唯一的区别可能就是满足了他个人的“技术偏执”。最终导致的结果就是，公司投入了大量的人力成本、时间成本，换来的却是一堆毫无意义的重复性成果，以及团队内部的争吵、质疑与内耗。

五、极端完美主义，却从未真正产出成果

这样的人，往往还非常的完美主义，动不动就开会讨论，甚至为了一个微不足道的细节可以开十几个会议。每次开会，他都会提交一堆厚厚的PPT、详尽的技术文档，看起来仿佛很有产出，但实际上却从未真正产生过任何落地成果。

• 在团队待了两年，调研了无数轮，依然停留在“讨论阶段”；
• 技术方案讨论来讨论去，但就是无法付诸实施；
• 团队成员每次都要花大量时间配合他开会，做出大量的文档，但最终看不到任何实质性成果。

在他眼里，也许“会议纪要”、“技术文档”和“漂亮的PPT”就是最有价值的东西，但在真正的业务需求面前，这些产出可以说是毫无价值。可悲的是，这类固执的人往往在领导眼里显得“很努力”、“很专业”，甚至他们的文档和会议纪要往往能获得领导赏识，甚至超过真正辛苦敲代码、解决实际问题的同事。

例如，使用几个 python 脚本实现的功能，就可以在他的眼里用 aspice 的标准实现几十个文档，并且这位“文档大师”还会要求同事们按要求完成所有文档。但在开发工期十分短的前提下，花费大量的时间撰写这些文档实在是没有必要，而且这些文档并不会提交给公司，只是提交到“文档大师”那里。文档的内容大概如下所示：

文档名称	介绍	模块
软件需求规格说明（SRS）	明确说明功能脚本所实现的需求、输入输出条件、功能性和非功能性要求。	需求分析（SYS.2）
软件架构设计说明（SAD）	描述Python脚本的整体架构，包括模块划分、交互接口、关键算法和架构决策。	软件设计（SWE.2）
软件详细设计说明（SDD）	针对每个Python脚本具体功能模块进行更详细的设计说明，包括算法逻辑、数据结构、接口参数。	软件详细设计（SWE.3）
软件单元实现文档（源代码）	Python脚本的源代码，包含必要的注释、变量命名规范、函数规范和实现细节。	软件实现（SWE.3/SWE.4）
单元测试计划与报告（UTR）	记录Python脚本中各个模块的单元测试方案，包括测试用例、预期结果与实际测试结果对比。	软件单元测试（SWE.4）
集成测试计划与报告（ITR）	记录多个Python脚本之间的集成测试过程、测试用例、结果及问题修复情况。	软件集成测试（SWE.5）
系统测试计划与报告（STR）	针对整体功能进行系统测试，验证脚本是否整体满足需求，并记录测试情况和问题修复状态。	软件系统测试（SWE.6）
配置管理计划（CMP）	定义Python脚本源代码版本控制方案、分支管理策略、变更管理流程和代码发布方式。	配置管理（SUP.8）
变更管理记录（CR）	记录脚本功能变更的原因、决策过程、变更内容、影响分析及实施后的验证。	变更管理（SUP.10）
软件缺陷管理记录（DR）	跟踪Python脚本测试过程中发现的缺陷、缺陷的解决方案和验证情况。	问题管理（SUP.9）
软件质量保证计划（SQAP）	描述针对Python脚本实现功能的质量保证活动、审查机制及保证流程符合ASPICE要求。	质量保证（SUP.1）
风险管理计划（RMP）	针对Python脚本实现功能中可能出现的风险进行识别、分析、管理和缓解措施的描述。	风险管理（MAN.5）
用户手册（UM）	为Python脚本使用人员提供的操作指南，包括脚本功能、操作步骤、异常处理及注意事项。	软件使用支持（SUP.11）
软件维护计划（SMP）	定义Python脚本后续更新、维护、问题修复和升级迭代的计划和流程。	软件维护（SUP.12）
需求追踪矩阵（RTM）	明确Python脚本功能模块和需求之间的对应关系，确保需求覆盖和测试覆盖的全面性。	需求管理（SYS.2/SWE.1）
软件发布说明（RN）	每个版本发布的Python脚本的新功能、修改内容、已知问题和版本适用范围的说明。	软件发布（SWE.6/SUP.8）
项目状态报告（PSR）	定期记录和报告Python脚本开发的进度、资源消耗、问题解决状态和下一步计划。	项目管理（MAN.3）
审核检查单（Review Checklist）	针对Python脚本设计和代码的审查检查单，明确审查内容及问题点的记录和处理。	质量审查（SUP.1/SWE.3）

于是，这种“执拗+文档至上”的人往往在职场中占据了一席之地，他们看似高产，其实却严重拖累了项目的效率和团队的健康发展。如果想要一个软件团队正常且健康的发展，这种只有文档产出的程序员是一定要踢出团队的。

六、如何识别并避免和这样的人合作？

那么，我们普通职场人该如何识别和避免这种过于固执、不尊重专业、不懂成本控制的人呢？以下几点建议可以作为参考：

• 提前考察沟通：尽可能地提前与合作对象进行沟通，确认其真实的技术背景和实际工作经历，避免陷入无意义的争论和浪费中。
• 适时提出反对意见：勇敢表达你的看法，提前指出风险。如果对方仍固执己见，可以果断拒绝合作或要求上级介入。
• 保存记录，避免背锅：在合作过程中，如果发现问题，务必保存证据，避免最终因为这种合作导致项目失败而背锅。
• 寻求团队支持，避免个人对抗：不要独自与固执的人对抗，而是寻求更多团队成员的支持，以更有效的方式让领导发现问题所在。

七、结语：道不同，不相为谋

职场合作最重要的是效率和效果，而不是固执地坚持己见。面对那些执拗到让人绝望的人，有时候保持距离、不合作才是最好的方式。毕竟人生短暂，职场中的精力和热情更是有限，与其在无意义的执拗中浪费时间，不如将自己的才华和精力，放在真正能创造价值的地方。

道不同，不相为谋，愿职场的我们都能与那些真正值得合作的人并肩前行！