一将无能，累死三军

这篇文章思路来源于我在知乎上看到的话题

📌同样的问题 ———— 公司内部的流程混乱到了让人崩溃的地步。

思绪飘到了面试的时候，在上一家公司有了类似的痛点 ———— 流程不规范，因此我特地就「管理」和「流程」进行了沟通，得到的回复是 YES ，但事与愿违。

一、思想的碰撞与萌芽 🧠

在大学的社团里和出入社会的第一家公司，等级明确，作为一个小喽啰，只能按照「身份」程序般的执行任务。那时候心比天高，总想着你不安排我工作，你不管我，我主观能动性强，我也能成事……

后面在一家很小的公司里，确实享受到了这种自由的感觉，那时还没有意识到是因为“领导”放权了，自己才能「随心所欲」。直到现在才「身在此山中」，当你有了“自由”，却没有“权力”的时候，你才发现你举步难行 ———— 很直观的🌰，让你自己去做，可方案与结果他又不满意。

二、真实的指令vs虚假的指令 ‼️

🧠 是个好东西！

• Example 1

  抓唐僧，张口就来。

  

• Example 2

  打锦州，你记一下，我做如下部署

  

有时候我已经分不清他们是根据不具备这种能力，还是故意装疯卖傻，或者说是给自己兜底，找人背锅。如果明确了命令，结果不对，就是他的问题。如果模糊命令，结果不对，就是你的问题，结果对了，在管理上就是他指导有方。如果从这方面去理解，那这种思想也确实是 Em 将中国传统文化发扬光大了。

三、管理者具备的能力❓❓

企业家冯仑对「管理」具有一种江湖气的见解，他认为管理者应该有这三种气质： 「指道」、「抗事」和「买单」。简单理解就是指明方向，具备解决事情的能力和为决策兜底。

那AI是怎么认为的，我采访了 gemini ，他是这么回答的：

一、 技术决策与战略能力 (Technical Vision)

作为技术领袖，你不需要是团队中敲代码最快的人，但必须是看方向最准的人。

• 技术选型与架构前瞻性： 能够根据公司业务阶段选择合适的系统架构（如单体 vs 微服务），避免为了追求新技术而引入过度设计的风险。

• 技术债务管理： 懂得在“业务交付速度”与“代码质量”之间做权衡。知道什么时候该快速迭代，什么时候该停下来重构。

• 资源评估： 准确判断实现一个功能需要多少人、多少时间，避免盲目承诺导致的团队崩溃。

二、 团队建设与人才管理 (People Management)

互联网行业的核心资产是人，管理者的能力体现在能否激发团队的战斗力。

• 人才梯队建设： 能够识别“技术大牛”和“潜力股”，并根据成员特点分配任务（Mentorship）。

• 文化塑造： 建立崇尚技术、实事求是、敢于承担责任的团队氛围（如：无责备后的复盘文化）。

• 冲突解决： 协调后端与前端、开发与测试、甚至技术与产品之间的矛盾，让大家目标一致。

三、 流程与交付管理 (Execution & Delivery)

项目负责人必须确保“活儿能干完”且“上线不崩”。

• 敏捷开发与落地： 熟练运用 Scrum 或 Kanban 等方法论，确保项目进度透明、可控。

• 工程卓越（Engineering Excellence）： 推动持续集成/持续部署（CI/CD）、自动化测试和代码审查（Code Review），用流程保证质量。

• 风险预判： 在项目初期就能嗅到可能导致延期的因素（如第三方 API 不稳定、需求变更频繁），并准备好 B 计划。

四、 商业敏锐度与沟通能力 (Business Alignment)

这是 CTO 与普通技术经理最大的区别：你能否用老板听得懂的语言说话？

• 跨部门沟通： 将复杂的架构概念转化为业务价值（例如：为什么要花一个月做重构？因为重构后支撑用户并发量能提升 10 倍）。

• 产品思维： 理解业务逻辑和用户需求，不盲目追求技术指标，而是追求“技术如何支撑业务增长”。

• 上下游协作： 向上管理老板的预期，向下传达公司的战略方向。

CTO 与项目负责人的侧重点对比

虽然两者都是管理者，但在实际工作中，其能力权重的侧重点有所不同：

四、管理思维的缺陷与职责的侧重

我没学过企业管理，但「没吃过猪肉，也见过猪跑」，在学校和工作中，也曾做过一些负责人，深知「管理能力」对团队的重大影响。哪个方面体现直接的管理能力？ 运动会安排分组拍照、搬运水、课桌等杂物、拉拉队、运动员报名与训练等；大学班级社团里的安排活动；野炊、义工、团建等活动的安排等等。很多面试中谈论到管理能力，其实管理思维往往决定了管理能力。

根据最常见的一个公司架构，分析下存在的管理缺陷和对应的职责不清晰导致的流程混乱问题。三个部分层级，包括【技术总监】—— 【项目负责人】—— 【组长】

现在的公司是做ai玩伴，以前的公司是金融相关的，简单做一下对比。

技术总监

TD 侧重于具体技术环节的指导和管理。我认知里的总监是可以指导技术的，是把握技术的前进方向，是技术是否能应用于市场进行评估的。

🤷 NOW

目前，我并没有发现任何亮点，真的是吃了某一时间带来的「红利」。

经常说的是「可以了吗」、「这个你看一下有没有问题」、「跟进一下」、「这个你去评估一下」，这种毫无营养的指示我仍不敢相信是从一个cto嘴里听到的。方案评审、需求评审从不出席，不分析技术的可行性，不提建设性意见。对直播的技术能力、ai语音聊天的技术难点没有提供技术支持，能说的就是 “你去查一下”而已。不出差，不做市场调研，在产品线下发布时不出场，在观众提问关于产品的技术点时，没人回答，全靠运营人员在转移话题。

没有任何的理由，就说这个时间能不能提前一点，不按照约定的时间节点执行。

上班打卡度日，在这个 level 上，有充裕的时间，却不去学习如何管理、如何使用ai、如何将ai应用于产品（公司是做ai相关的产品）等知识。

🙋🏻 BEFORE

会尽量出席每一场需求评审，对该需求进行市场分析，对技术是否支持进行分析，并拍板方案，讲解需求的重点等。平常不直接与开发对接，完全根据项目节点验收产品。平常出差，对接客户，讲解产品功能，促进合作等。

项目负责人

这个是最直接的领导了，在办公软件上的审批，这个就是「直接领导」。

🤷 NOW

也作为后端开发，不仅是在「管理」还是类似「技术架构」方面，都和我认知里、见过的形象差别甚大。没有层级上的管理，底下人“自由”，那种没有统一目标的自由。

• 没有明确工作流程

  一个需求出现，直接指定谁谁开发，然后送测，最后产品验收。看似有工作流，但是实际出入很大，没有各个阶段的任务，各自做各自的，然后在合适的时候交给运营。线上有问题，不管三七二十一，全找开发解决。没有技术评审、测试用例评审、验收总结，只有一个“领导”头衔。

  给前端定的时间是5天，但是测试和产品并不知道该节点，也没有所谓的要求说结束后要送测。事后诸葛亮，以「过来人」的身份说教———— 应该这样，应该有这种意识。 特别爱说你们是一个团队，应该怎样怎样，但又不明确团队成员的身份与职责。

• 没有开发规范

  没有任何开发规范，就是拿到需求后，各自开工，按照自己的风格来。没有统筹前后端的设计，比如一个对象随便返回 null ，前端的提示随便取，上线出问题了，才说前端要取接口的提示。后端迭代更新一套代码，没有任何的预警与安排，全靠前后端按照认知进行一点点的对接，更新上线后多处崩溃。

• 没有项目说明

  根本不知道项目是什么，项目在哪里，可以查阅哪些文档，是完全没有文档，无迹可寻，真真正正做到了一个人就是一个项目，所有的项目信息全在他的脑子里和电脑里。

• 粗糙的项目管理

  还在用 svn 管理，没有明确的版本管理，更新内容混乱。前端可以直推代码到灰度和生产环境。项目代码在哪里，没人知道，全靠问。

🙋🏻 BEFORE

也是后端开发，但是工作内容上，将中心从「开发」转向了「管理」，只是偶尔做数据库建表等工作。

以上三点全部有，甚至还超出了。明确了整个开发流程，需求评审后，他将根据需求输出技术文档（有时也是组长写），然后评估各个流程的时间，前后端开始开发，测试进行测试用例评审等。后端需要将接口文档等信息以邮件的形式发给前端，前端提测时也要发送邮件。测试流程结束后，也要发送邮件等。完全是根据时间节点进行，不会出现以上的情况。前后端都要明确开发规范，他亲自建数据表，明确各种字段的类型、该使用哪种方法等等，不会出现以上对象是null、更新内容不完全、消息提示不统一的情况。亲自撰写项目说明，包括项目介绍、背景、使用的技术、各个功能的业务介绍、每一个迭代的技术更新等。推进项目管理，使用git管理，项目代码位置清晰，各个环节把控，自动化构建测试环境，只有测试人员才能更新灰度。

组长

这个身份最容易理解了，就是接收任务和安排工作任务的人。需求一出来，大家都是什么，但是负责哪些内容，应该是由组长安排的。

🤷 NOW

如果非得参与技术的话，按照管理和写代码的比例来看，我认为技术负责人是 7:3 ，写一下最核心的配置。 组长是 3:7，做项目基建和解决疑难杂症。

但是目前组长是 0:10，完全投入与开发中，「组长」只是一个头衔。

• ❌ 工作安排

  当有需求时，直接是「技术负责人」安排某个开发进行，组长完全不知道。真的实现了这种 1 1 1 1 的独立开发。当要进行统计员工的工作内容时，组长并不知道组员进行了什么工作，还是组员们把各自的工作内容发给组长。

• ❌ 技术架构

  如果用某个身份来说，就是「架构师」，但并没有所谓的这个技术依据，比如在前端，为什么使用 vue，为什么使用 ts ，为什么要使用这种方案等等。完全就是这项目是他负责，他想用什么就用什么。

  另外在项目参与上来看，并没有做到 主次 这样的区别，而是和组员一起开发，并不会事先做好项目基建，如公共组件库、方法库等这些的配置，而是各自人员开发到的时候再去写。

• ❌ 项目规范

  没有所谓的项目规范，对于新项目，脚手架一用，直接开干。没有任何的编码规范，三个人有三种代码格式化风格，乱注释、乱命名的经常出现，没有所谓的「函数命名规范」、「样式命名规范」、「组件封装规范」等。

  文档也没有，不知道项目在哪，不知道项目名是什么，没有项目介绍。代码拉下来了，不知道如何启动，是用 npm 还是 pnpm，启动频繁报错，node 版本不是太高就是太低。有的项目要模拟登陆，用什么插件、怎么用，也完全不知道。怎么打包到测试环境，不同环境之间怎么切换，有什么区别，都找不到任何说明。 总之，拿到一个项目，完全不知道如何入手。

• ❌ 项目对接

  在组员切换项目时，没有起到领头和指导作用。需求是没有指出上下两版需求的差异的，那组员开发时，并不明白某些变量某些配置的作用，而组长并没有组织讲解与指导，导致组员到处摸索，一是浪费时间，二是容易遗漏或者配置错误。

🙋🏻 BEFORE

之前碰到一个组长，真的是「神仙」，虽然不是大厂，但就像老师一样，指导你进步。

举个🌰，那是一个官网&&商城平台，在收到需求后，组织开会，评估技术方案，如框架、包管理、组件库、编码规范等等，然后安排工作，各自根据自己的工作内容，初步确定实现思路和可能的难点，然后有问题找他沟通。编码规范定的详细，「生命周期」写在最后面，函数命名语意化，动词+名词，如获取用户列表 getUserList 等等。他会对整个项目进行架构处理，如项目搭建、组件库引用、环境变量配置、打包配置、状态管理等都是他处理，编写项目说明文档和技术文档。后续还会对项目配置给我们进行讲解培训。

在跨项目时，因为项目已经有了项目说明和技术文档，所以容易理解，组长也会对新需求进行分析，说明需求对应的地方和改动时需要注意的点等等，开发结束后由组长把关，不会出现漏掉功能和改错配置等问题。

五、反思 🙇‍♂️

现在就是 「一将无能，累死三军」。从上到下没有执行好自己的管理职责，开放式命令，「你去办」而不是 「你要这么办」。

一个草台班子，全靠各自领域的经验开干，最后拼接在一次。上面要求生产一辆车，下面做车架、做轮胎、做中控的各自开干，过程中问一下，最后拼接在一起，车子能跑了直接生产投入市场。

从公司规模看，现在的比之前的要大，人数也更多，我很难理解为什么管理和流程都那么不规范。

我曾经提出过流程中关于测试的问题。我说需求不明确，到测试这边他直接提需求，变成了我的问题。测试最基本的复现bug的能力都没有，只告诉你这个功能没实现或者这个页面空白了。技术负责人的回应是，测试不一定知道是谁的问题，他们不一定懂操作这个接口。

我很难认同这个观点。需求明确是产品的任务；bug定位与复现是测试的任务。现在变成了全是前端的任务，自己去沟通完善需求，自己去发现并修复bug，自己去和运营对接解决线上问题。

六、细分到技术负责人和组长

说多了都是泪，AI 发展到今天了，真建议不懂的就查，去问问 gemini 。另外，还涉及到一个核心点————「权力」，光知道要做什么还不行，还得有文件说明你具备某种权力，负责xxx事物。

刚入职的时候，参与了某个项目，跟我说让我负责这个项目（就跟我说而已）。然后我跟后端明确了数据格式，他不听。还是产品经理在沟通开会等等，这是个毛的负责。有人说你要主动去开会沟通，看过电视吧，人事调用时，组织部的人命还没下达，有人屁颠屁颠的去开会吗？ 职场文也看过吧，任命谁谁当经理，是不是在董事会上提出。哪怕是各自部门里升任组长了，是不是要开会通知。见过哪个人主动说我负责这个项目的吗？

行了，gemini 的回答挺好的，可以问问，下面贴个组长的时间分配表

• Previous
  swiper的控制！！！