2023 年 1 月 31 日下午，我收到一封 HR 邮件。
标题从"前端高级技术经理"变成"产品质量部副总监"。同时，前端和测试两个组、26 个人，划到了我名下。
说实话，那一刻我是兴奋的。
在这之前，我写了七年多前端------搭过组件库、做过微前端、写过上百篇技术博客、拿过技术社区的领域专家认证。那时候我觉得，能管人、能管项目、能被公司需要，是一件值得骄傲的事。
我以为这是一次升职。
一年多之后，第二封邮件来了。2024 年 11 月 13 日，我调到客户服务部。
这两封邮件，概括起来是两件完全不同的事：
- 第一封 ，让我管公司内部怎么把产品做出来------研发流程、质量规范、测试自动化、平台建设。我对的是研发，管的是"东西怎么做出来"。
- 第二封 ，让我管对客户怎么把东西交出去、把钱收回来------项目上线、验收签字、回款、日常运维。我对的是客户和商务，管的是"东西怎么交出去、钱怎么回来"。
从"内部产研管理"走到"客户交付管理"------听起来是往前走了一大步：离客户更近了，离钱也更近了。
我当时就是这么想的。
三年七个月后，我把这期间的二十多份月度 OKR 全部翻出来，看了一个晚上。
看完之后，我承认了一件事：这两段经历加起来，我做的很多工作，本质上不是管理，是"工作拆分转发"------把公司要的东西拆成任务分下去，再把团队的进度汇总起来报上去。
这句话不是自嘲，是我在这一行摸索三年多之后，目前最真实的一个判断。
一、先说清楚：什么才算"真正的管理"
在讲那两个岗位和四个代价之前，我得先交个底------我现在的判断标准是什么。
我认为管理很难，它要处理的因素非常多：业务型的管理、管理型的管理，节奏完全不一样。但我现在有一个比较固执的看法：
只有当你带的团队，能直接对经济效益负责，而你又握着相应的话语权------管得了人、也管得了钱------这件事才真正叫管理。
为什么是这两条？
第一，管理者必须真的触达业务，对结果有话语权。 如果一件事做得好不好、值不值钱，都不是你能判断、也不是你能拍板的，那你每天早上在指挥的，到底是什么？你只是在帮别人维持秩序。
第二，管理人，前提是有相应的权限。 财权、人权------听着很功利，但没有这两样，"管理"就只剩沟通和协调。你既不能奖励，也不能调整，只能一遍遍地说"再盯一下""辛苦一下"。这不是管理，这是转达。
这么一对照，我尴尬地发现：我这三年做的大部分事情，恰好落在这两条之外。
所以严格来说，我做的很多事是"工作拆分转发"，不是管理。
我也还在摸索，这不是结论。但它是我的坐标，也是后面所有反思的尺子。
二、先摊开来看：两个岗位，我到底做了什么
复盘的时候，我发现自己一直说不清一件事：这三年，我到底干了什么？
因为它太杂了。直到我把这 24 个月的 OKR 和这段时间留下的文档全部列出来，才第一次看清楚------
我不是在同一个岗位上做了三年，我是做了两个完全不同的岗位。
而且这两个岗位的差别，不是"级别变高了"，是站的位置变了 ------它们其实是同一条交付链上的两段：
- 产品质量部：站在公司内部 ，管的是链的前段 ------产品怎么做出来、质量怎么保证。这是一个内部管理岗。
- 客户服务部：站在公司外面 ，管的是链的尾段 ------东西怎么交到客户手上、钱怎么回来。这是一个面向客户和商务的交付岗。
从"内部产研管理"走到"客户交付管理"，中间隔着的是从成本端走到收入端。
这件事我当时没想明白。现在回头看，它几乎解释了后面所有的拧巴。
第一个岗位：产品质量部副总监（2023.01 -- 2024.11）
分管前端 13 人、测试 13 人，一共 26 人。
如果用一个词概括这个岗位，是**"建容器"**------把公司需要、但还没有的标准、流程和平台，一个个建起来。
摊开来看，这段时间我牵头输出的东西是三类：
第一类：制度与规范。
最花力气的一份，是**《项目投入与产出管理规范》**。它规定了公司所有立项项目必须跑两张单据：
- 项目成本控制单据------记录项目的预估人天与实际投入人天；
- 项目产出跟踪单据------跟踪蓝图、产研、UAT、上线四个阶段的基本信息与完成度。
每个阶段都有对应的"健康度"算法。比如产研阶段健康度 = 产品设计完成率×0.2 + 开发任务完成率×0.4 + 测试任务完成率×0.2 + 产品验收完成率×0.2；UAT 阶段健康度 = 验收通过场景数 / 总场景数。
配套的还有一整套运行机制：周一 项目经理更新工时与单据数据 → 周二 部门经理按格式回邮件、项目办处理延期与资源问题 → 周三 发《项目成本与进度更新通报》给经营层 → 月度例会上，偏差项目要做原因说明。项目偏差达到 5%、10%、15%，分别对应三档升级处理，最高一档要启动危机管理、每日跟踪。
这已经不只是一份文档了，它是一套让全公司项目数据可追踪、可追责的机制。
除此之外，还有标准产品研发流程的制度组：发版制度、功能提测流程、bug 提测流程、Gitee 操作规范、标准产品研发流程指标数据。
以及质量体系规范组：《需求设计规范与要求》《研发规范与要求》《测试规范与要求》《发版规范与要求》《质量过程协同机制说明》，后面又补了《AI 开发指导使用规范》。
第二类：平台与工具。
- 系统稳定性监控与可视化平台
- 质量数字化管理平台
- 自动化测试平台------把《自动化脚本-基准版》回迁到平台投入日常迭代，再从单一项目推广到全渠道、零售分销等多条业务线，最后输出一份各项目覆盖度报告
第三类：产品化交付。
- 标准产品的低代码功能替换：出入库通知单结果单、收发货通知单结果单、逻辑仓扩展库存单据、平台库存同步日志、物理仓管理、客商、组织与档案类管理、数据字典......
- 小程序系统基于可视化配置的交付方案
结果是可以量化的：发版引起的问题，从 14 个/月降到 2.5 个/月；自动化测试在各项目的覆盖率做到 90%。
那段时间我其实挺有成就感的。因为这些产出是"能留下来的"------文档谁都能打开，平台谁都能登录，脚本谁都能跑。它不像会议，开完就散。
也正是在这段"做得最顺"的时候，我被调走了。
后来我反复想过这次调动。从管内部产研，到管客户交付，看起来是被推到了更靠前的位置------直接对着客户、对着合同、对着钱。
但我真正该早点意识到的是：交付是一条完整的链，而我接手的，只是其中一段。
第二个岗位：客户服务部副总监（2024.11 -- 今天）
2024 年 11 月 13 日，第二封任命邮件。
分管客户服务与运维，团队 10--17 人，按项目拆成多个小组、同时服务十几个项目，每周以周报统一汇总。
如果用一个词概括这个岗位，是"扛结果"。
我把这 19 个月的 OKR 全部导出来数了一遍：一共 262 条任务条目。 按类型分是这样的：
按项目分，最集中的一个客户占了 93 条，三分之一还多；其余横跨快消、美妆、免税、食品、运动、母婴、零售......
这个岗位没有"作品"。 它只有"状态"：上线了、验收了、回款了、报障处理了。一件事做完就清零，下一件进来。
而且这里面相当一部分，是我根本控制不了的------客户内部流程、对方财务的排期、硬件的到位时间。
这次转变，给了我什么
我不想把这段经历说得一无是处。从内部产研走到客户交付，我确实拿到了在质量部永远拿不到的东西：
- 第一次真正站到收入端。 在质量部，我的产出是内部指标------发版问题降了多少、覆盖率做到多少。到了客服部，每件事最后都要落到一个更硬的结果上：客户签不签字、合同签不签、款回不回来。
- 第一次看懂钱是怎么来的。 一个项目从签约到回款，中间经过多少道手续、卡在谁手上、卡住会损失什么------不站在这个位置上，永远学不到。
- 被逼着学会两种新语言。 把技术问题翻译成客户听得懂的话，把客户的诉求翻译成研发能执行的方案。这是写代码写不出来的能力。
- 第一次看清自己的手感在哪。 在质量部我搭组件库、做微前端、建平台，做起来是"顺手"的；在客服部我追验收、追回款，做起来是"使劲"的。同样是忙，前者给我掌控感，后者常常让我感到无力。这个差别，比任何性格测评都更能说明我的能力长在哪。
但这四条收获，都建立在一个我当时没看清的前提上。
我从来没有管过一条完整的链。
在质量部，我管的是这条链的前段，偏内部------从蓝图到上线，"东西怎么被做出来"的那一段。管的是研发过程、质量标准和交付节奏。前面的商机、报价、签约不在我手上，后面的验收和回款也不在我手上。
在客服部，我管的是这条链的尾段，偏客户------从上线到验收回款，"东西怎么交出去、钱怎么回来"的那一段。可产品做得好不好、排期准不准，不在我手上；客户什么时候点头、对方财务什么时候走完流程，也不在我手上。
合起来看，这就是一条链的两截：一截在公司里面，一截在公司外面。
听起来像是换到了一个更靠前的位置，其实是从链的一段，换到了链的另一段。
而且这两段还有一个共同点：它们的成败，都不完全由我说了算。
把两个岗位并排放在一起
写到这儿，我第一次看清了这张表：
| 产品质量部（2023.01--2024.11） | 客户服务部（2024.11--今） | |
|---|---|---|
| 站的位置 | 公司内部 | 客户现场 |
| 管的链条 | 交付链的前段（偏内部）：东西怎么做出来 | 交付链的尾段（偏客户）：东西怎么交出去、钱怎么回来 |
| 对谁负责 | 研发与质量指标 | 客户、合同、回款 |
| 团队 | 前端 13 + 测试 13 = 26 人 | 10--17 人，多项目并行 |
| 主要产出 | 制度、规范、平台、脚本 | 上线、验收、回款、运维响应 |
| 产出形态 | 能留下来、能复用 | 做完即清零 |
| 我的角色 | 定标准、拆任务、盯进度 | 接需求、推项目、追回款 |
| 年底能拿出什么 | 一套制度 + 两个平台 | 一批回款数字 |
这张表里最刺眼的，其实不是"产出形态"那一行，是**"管的链条"那一行**。
哪一段都不是完整的一条链。 起点和终点都不全在我手上，我能做的，只有把自己那一段推到最好。
我后来所有的拧巴，其实都是从这一行开始的。
这张表摆出来的时候，我心里冒出来的第一个念头，不是"哪一段更好"，而是：
这两个岗位里，我都不是"创作者"，我是"组织者"和"推动者"。
质量部那些规范，我离开之后还在被引用------但那是团队的作品，不是我的；客户服务部那些回款，到账就进了公司的账------也没有一笔属于我。
两种角色都不算失败，可它们有一个共同点：都不能积累"我自己的东西"。
这才是我后来越想越难受的真正原因。
三、代价一：我建了一整套标准，却没有一条是"非我不可"的
接手质量部的第一个月，我在 OKR 上铺了 4 条战线：
- 低代码功能替换------出入库通知单、逻辑仓扩展库存单据、平台库存同步日志
- 自动化测试常态化------从《自动化编写与执行规范》开始，一路推进到基准版回迁、全渠道业务脚本、零售分销业务脚本，最后交出一份各项目覆盖度报告
- 质量体系建设------从确定监控指标范围，到各阶段规范输出与宣讲，再到系统稳定性监控平台、质量数字化管理平台
- 新品类项目组并行------前端体验优化计划
5 个月后，这 4 条战线每一条都往前走了。
我很满意，把这当成"我能扛事"的证据。
后来我把那段时间的 OKR 一条条对着看，才发现一个尴尬的事实：
那 4 条战线里，没有一条是"非我不可"的。
- 规范是几位同事分头写的，我定框架、统稿、宣讲；
- 平台是研发同学搭的，我提需求、验收；
- 脚本是测试同学写的，我排期、催进度。
我在里面做的最主要的工作，是把公司的要求拆成任务、盯进度、汇报结果------正好就是前面说的那件事：工作拆分转发。
我当时以为"管更多的人 + 管更多的事" = "管得更好"。
现在我知道：管更多的人不是管理，管得更深才是。
四、代价二：完成率 77%，和那个只有 55% 的月
从"管研发流程"转到"管客户、管商务、管回款"之后，我一开始是真心觉得赚了的：
既懂技术、又懂客户、还能谈商务，这是别人没有的复合优势。
但数字不会骗人。我把这 19 个月的自评完成率算了一遍：平均 77% ；最低的那个月，只有 55%。
那个 55% 的月，我到现在还记得。
不是因为那个月我干得少。恰恰相反------那个月我们该做的都做了。但很多事就是推不动：团队把活干完了，交付卡在客户那边，签不下来、收不回来。
那是我第一次非常具体地感觉到：这个岗位的产出，很大程度上不由我决定。
我当时在复盘里写下的原话，是六个字："团队工作交付成果很难。"
不是难在技术，是难在------你明明看到问题在哪，却没有任何一个工具能把它拧过来。
五、代价三：我要为"闭环"负责，却管不住它
这是我最想讲的一个。
我的 OKR 里有一个客户，就叫它 A 客户。从 2024 年 12 月开始，连续 5 个月的记录是这样的：
连续 4 个月，我每个月都写"这个月完成验收"，每个月都以为下个月就能收回来。真正到账，是在第 5 个月。
款到账那天，我坐在工位上，看着系统里那行状态变成"已回款"，发现自己没有一点高兴。
第一个念头是：这本来就该三个月前到账的。
第二个念头是：那三个月，我到底在忙什么？
我翻回前面四个月的 OKR，看见自己每个月都写同一句话。然后我想起一个更难受的细节：这四个月里，我没跟任何人发过一次火。
对客户说"理解理解"，对团队说"再盯一下"，对老板说"快了"。
我唯一没问过的，是我自己一句：这件事，到底有谁真的负责？
还有一个 B 客户，一笔 49500 的款项，从 2025 年 9 月开票一直追到第二年 6 月，状态栏永远是三个字：进行中。追了 10 个月。
还有一个 C 客户，某个月我列了 4 项验收任务，那 4 项的结果分别是：客户未验收、客户未验收、客户未验收、客户未验收。
我这才想明白：交付和闭环，是两件完全不同的事。
- 交付在你的团队内部，你能控制------把需求做出来、测完、发版。
- 闭环在团队外面，你控制不了------要客户点头、要跨部门签字、要对方财务走流程。
我一直以为，问题出在我没把"闭环"当成一个需要立项、需要排期、需要盯人的独立项目。
但后来我把这个结论推翻了。
就算我把它当成独立项目，我也管不动。
因为接下来有一个我必须诚实回答的问题：闭环，到底该谁管？
先说结论：职责上，就是该我管。
客户服务部的核心指标里，"验收"和"回款"是最重的两项。翻我自己那 19 个月的 OKR，验收与回款相关的任务有 48 条------这是我的本职工作，不是别人甩过来的锅。
但真正的问题在这里：这件事我能"负责"，却没法"管"。
- 客户什么时候内部评审完，不归我定；
- 采购什么时候签字，不归我定；
- 对方财务什么时候走完付款流程，更不归我定。
我手上有的，只有"推动"------反复问、反复催、反复协调。我没有的，是"决定"------我既不能让客户提前一天签，也不能让对方财务提前一天付。
所以那句话得改一下。不是"没人管闭环"，而是：
闭环这件事，公司里没有任何一个位置真正管得住它------包括我。
我的 OKR 里写着"这个月完成验收"，可现实是，没有任何一样工具，能让客户在那个月的最后一天签字。
管理的终点不是"做完"，是"收回来"。 交付只完成了 60%，剩下 40% 全在闭环上------而大多数人（包括曾经的我）根本没把这 40% 算进工作量。
更要命的是：这 40%，就算你算进了工作量、排进了计划、天天盯着，它也不一定按时回来。因为它每一步的动作，都长在公司外面。
这就回到了我在第一章立下的那把尺子：对经济效益负责 + 手上有话语权，两样都有，才叫管理。
而闭环这件事的真相是------结果记在我账上，可决定结果的那几环，我一环都插不上手。
责任在我，决定权不在我。 这可能是这三年里，我最难受、也最真实的一条体会。
六、代价四：打开博客后台那天，我问了自己一个问题
前一阵子，我打开了很久没登录的掘金后台。
最后一条更新，停在 2021 年。
那天我心里冒出来的第一个念头，不是可惜，是一个特别实在的问题：
我的核心竞争力，到底是管理，还是技术？
如果是管理------那我这三年做到什么程度了？带过 26 人、管过十几个项目、建过一整套制度、回款数字也拿得出手。但按我自己定的那个标准，这些离"真正的管理"，还差得很远。
如果是技术------那我这三年，一行像样的架构代码都没写过。
这个问题我到现在也没能完全回答。
写在最后
三年七个月，我换来的不是"怎么当好一个副总监"的标准答案，是几个更基础的坐标：
- 管理是不是真的，看它有没有直接对经济结果负责；
- 责任和决定权得同时在手上。只有责任、没有决定权，那不叫管理，叫"背结果"------你要为结果做出承诺，却决定不了过程里的任何一环；
- "既懂技术、又懂客户"是乘法，不是加法。会几样不重要，得先有一样是别人替代不了的------几项都只是"懂一点"，乘起来还是接近 0；
- 交付 ≠ 闭环，有 40% 的工作量在团队外面------它常常不在你的计划里，却决定你的结果；
- 组织者和推动者都不是坏角色，但它们不会给你留下任何属于自己的东西。
我现在最难受的一点是：顶着"副总监"这个名字，却觉得自己在退步。
职级在涨，能管的事在变多，但我越来越说不清------我到底比三年前强在哪儿。
还有一个复盘我暂时写不了：手上这个项目的收尾还在发生。等它结束，我会写第五个。
如果让我对三年前那个收到任命邮件的自己说一句话，我会说：
先搞清楚职业方向，然后日拱一卒，不要放弃提升自己的核心竞争力。
这句话我花了三年七个月才想明白。而它本来，可以在我按下"接受"之前就想明白。
32 岁这一年，我重新打开编辑器。
不是为了回去写代码，是想把自己当成一个需要长期经营的项目------就像当年研究浏览器渲染原理那样，一层一层地拆开，找到它真正的运行逻辑。
我重启写作最想解决的，其实不是"写什么"。
是给自己建一个不依赖任何一家公司的资产。
写了七年多技术博客、做了三年多管理之后，我终于想清楚一件事：一家公司能给你的东西------title、团队、权限、漂亮的回款数字------在某一个早上，都可能随着一封邮件消失。
就像三年前，它也随着一封邮件到来。
而写下来的东西不会。
它不归任何公司，不归任何一个老板。它只归我自己。
关于作者
耳东蜗牛，公众号「前端耳东蜗牛」。
写过七年多前端技术博客，拿过技术社区领域专家认证；后来带 26 人的前端 + 测试团队，又转做客户交付与运维。
现在在重新回答一个问题：我的核心竞争力，到底是管理，还是技术？
- 掘金：juejin.cn/user/3438928104021463/posts
- CSDN：blog.csdn.net/It_rod
- 公众号：前端耳东蜗牛
如果你也在技术转管理的路上，欢迎在评论区聊聊：你现在最难受的，是哪一件事？