职场中，我们总会遇到各种性格的人，有些人灵活、善于沟通，和他们合作顺畅高效；但也有一类人，极端固执，认定自己的方案天下无敌，谁说服都不听。与他们合作，轻则痛苦不堪，重则项目进展困难、停滞不前。 我自己也曾经亲身经历过这样一位极度固执的同事——当然，每个人都有自己的风格，只是就我的真实体验，分享一下与这类人的合作究竟会有多困难、到底为什么难合作，以及在职场中如何识别并避免这种陷阱。 一、认定自己方法“尽善尽美”，却从未真正实践过 之前我曾短暂和一位所谓的“资深工程师”合作过，他在做技术方案时极端自信，总喜欢挂在嘴边的一句话就是： “方案一定要规范和严谨，这些方案经过了XX轮深入调研！” 然而，他所说的“深入调研”究竟是什么呢？无非就是不断从各类博客、CSDN、知乎问答、Gitee 和 GitHub 项目里拼拼凑凑，把各种看起来高大上的名词汇总到文档里，来支撑自己的观点。 可是尴尬的是，这个人从来没真正动手写过一行代码，也没真正用数据分析验证过他的方案，完全停留在“文档大师”的层面。刚开始听他说话，或许你还会佩服一两天，觉得这个人研究得真细致。但时间一长，大家就会发现，这些调研根本不落地，毫无应用价值，纯属“纸上谈兵”。 二、非专业人士，却喜欢瞎指挥专业人士 更令人抓狂的是，这种固执的人往往喜欢越俎代庖，对专业领域指手画脚。我遇到的这位同事，既不是 AI 背景出身，也没做过数据分析的工作，也从未真正研究过机器学习算法，甚至连精确率和召回率等基础概念都没搞清楚，却偏偏总是要求我们的算法工程师必须使用“某某特定算法”，其他任何方案他都一律否决。 我们的算法工程师本身经验丰富，尝试了大量实践验证的算法，都能稳定高效地实现业务需求。可每当提出方案时，这位“固执大哥”都要反复质疑： 更让人无语的是，当你和他详细交流算法细节时，你才发现他连“过拟合”、“泛化能力”这样的基础术语都讲不清楚。他所谓的“坚持”，只是盲目地遵从网络上的只言片语，缺乏任何实践经验，却偏偏一口咬定自己才是对的。 三、盲目追求“先进技术”，却忽略团队成本和效率 同样，他也有另一个典型的执拗之处，那就是非要用一些奇怪的编程语言、技术框架来实现功能——只因为这些语言看起来“先进”、“新潮”、“未来导向”，却根本不顾团队真实的技术储备和学习成本。 比如，我们团队原本都是用 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脚本之间的集成测试过程、测试用例、结果及问题修复情况。 … Continue reading 职场生存记：远离那些执拗到让人绝望的人