带 20 多人的前端团队，我在管什么

2023 年初去听 GMTC，回来写过一篇总结。那时我接手前端监控平台一年多，团队还小，文末记了两个想法：做基建先解决眼前的业务问题，等相同需求多了再抽象；前端要靠技术方案和方法沉淀，减少重复劳动。

两年多过去，职责已经跟当初不一样。那时我还是独立负责模块的开发；后来晋升，逐步负责大前端部门里一个大约八九人的前端小组；今年年初开始负责整个前端组，算上外包有二十多人。人数翻了一倍多，日常要处理的事情也跟着变了。

带八九人小组的时候，我大致知道每个人每天在做什么，推进项目也常常是盯着一条主线往前走。线上问题、联调卡住、方案拿不准，我自己接手处理，团队很快又能转起来。到了二十多人，业务线、平台、探索项目同时在跑，我继续靠自己到处补位，往往这边刚处理完，那边又出问题。那两个早年的想法还在，只是我更常想的问题变成了：这件事值不值得做，该交给谁，怎么少犯同一种错，以及怎么和一个想法不同的人把话说开。

很多地方仍是经验探讨，未必适用于别的团队。

角色切换：从盯一条线，到同时推几件事

带小组时，我的时间大多花在「把一件事做成」。需求怎么拆、方案怎么写、联调卡在哪、提测卡不卡，我都能插一手。结果也相对可控：我多看一点、多补一点，团队通常稳一些。

负责整个前端组之后，并行的事情变多了。数据、算法、业财、内网工具几条业务线各自有节奏；监控、发布、资源治理这些平台要持续维护；AI 相关的探索项目又会阶段性拉人。同一周里，可能一边在谈某条业务线的排期，一边在跟发布系统的故障，一边还要决定探索项目要不要继续投人。我再按「亲自盯到交付」的方式工作，注意力会被分散得很厉害，也很容易变成所有问题的唯一出口。

带小组换成带整个前端组之后，我花过一段时间读技术团队管理的书，也自己整理过一些方法。读的时候觉得清楚，真正有用的是后来对照日常才想明白的四件事：职责边界要随规模变化，管理工作要拆开看，派活要看人的意愿，以及责任范围先于其他能力发生变化。

人少时，架构和接口人可以叠在同一个人身上。人一多，拆需求、跟进度、紧急问题如果还全揽在自己手里，复杂度会堆在一个人头上。职责边界要跟着规模一起改。

把管理工作拆开看，大致有四块：管事是项目推进、技术方案和日常排期；管人是招聘、培养、绩效和分工；定方向是季度里做什么、不做什么、资源往哪投；拿结果是目标有没有完成、问题和复盘有没有闭环。这四块争夺时间的能力并不平等。联调卡住、线上故障、临时插进来的需求都属于管事，而且是管事里最紧急的一层：它们有明确的截止时间，有人在等回复，当天就必须处理。培养谁、下一季度停止哪些项目、绩效怎么谈，属于另外三块，没有人要求当天完成，推迟一周也看不出损失，于是很容易一周一周往后拖。紧急的事会自己排进日历，重要的事只能靠自己排。大部分时间花在四处补位上以后，日历里剩下的往往只有管事里最紧急的那一层，另外三块在持续欠账，而且欠账要过几个月才会显现出来。

分工上也出过问题。有人把平台守得很好，聊起来却想去做业务；有人经验还差一点，但很想试，团队也刚好缺人。我以前按「谁空谁上」派活，对方接了也做，时间长了状态会下去。后来分配任务前我会多问一句对方怎么想，经常能听到我原来不知道的信息。回头看，这和月影说的「能做、想做、需要做」对得上：能力、意愿和团队需要叠在一起，活才派得稳。

从前端小组走到前端组负责人，责任边界先变了。你开始对一串并行结果负责，却对每一行代码失去了绝对把控。这个落差一开始不好适应。有人把技术管理路上的变化概括成责任、业务、战略、沟通几类跃迁；我不敢说自己都过完了，至少责任这一块先碰到了。

几次连续加班之后我发现，组织方式还停留在小组阶段，靠自己多顶几下已经不够用了。

组织形态：先把分片交出去

现在如果把日常工作摊开，大致有四块。一块是工程效能平台，包括前端监控、客户端监控、前端发布、移动端打包、CLI，以及 npm 私有库和线上配置这些零碎系统。一块是 AI 工程化，从企业知识问答 RAG，到告警分析与排障，再到当时还在试的 UI 自动化测试 Agent。占人最多的是业务支撑。剩下的是招聘、绩效、外包管理、新人培养和线上故障，它们很难老老实实待在项目计划里，经常突然冒出来打乱当周安排。

人多了以后，我试过继续当所有业务线的接口人，很快就忙不过来。后来把相对独立的业务线拆成小组，培养小组负责人做分片接口人，角色有点像前端 PM：需求怎么拆、进度怎么跟、平时找谁商量，先由他接住；搞不定的跨团队协调，或者方案拿不准，我再进去一起处理。

脱敏后的组织形态大概是这样：

图上看起来整齐，实际成熟度并不均匀。有的线已经有人能扛，有的线离开我还转不动。平台方向长期只有几个人，有段时间某个系统只有一名核心开发，再接两个系统就忙不过来。团队内部要有 backup：我对业务、对关键技术、对组内负责人都尽量补，但补齐之前，风险一直在。

授权这件事说起来容易。人选错了，负责人和组员都难受；嘴上说授权，出了问题又忍不住把事情收回来，对方也成长不起来。我现在比较能接受的做法是：先给清楚边界和目标，过程中留出检查点，真出问题由我承担责任。能不能信任对方，其实在面试和日常观察里就该先想清楚；到了出事那天再纠结，往往已经晚了。

技术建设上，我也逐渐从「自己把代码写完」改成「参与重点攻坚，同时带人做事」。借事修人这句话说起来好听，实际很难拿捏：给的空间太小，对方学不到；给得太大，项目又可能出大问题。我目前只能靠检查点和阶段性复盘来找中间位置。

工作方式：从个人补位，到机制和共建

小组阶段，质量靠人盯。二十多人看不过来，硬盯只会把自己累垮。后来我把更多精力放在默认流程上：新人用同一套脚手架和规范，提交经过检查，上线前有固定动作。一名正式员工同时带几个外包，需求就拆细一点，方案、联调、自测和冒烟留下检查点。嘴上提醒很多遍，效果通常不如流水线拦一次。

工具本身都很常见：统一脚手架、ESLint、Prettier、Commit 规范、Code Review、监控接入校验和发布流水线。最近团队开始用 AI Coding，我也在整理最基本的使用约定。制度要有用，最好能写进每天都要经过的地方。单独开一场宣讲，过几个星期我自己都未必记得全。

前年 AI 赋能数据平台时出过一次线上白屏，原因是把一个只能内网访问的接口放进了登录流程，外网打开页面整个项目就白屏。复盘时大家很清楚：创新需求如果全部排测试，周期太长，很难快速推进验证结果；不排测试，边界问题就会漏。后来的办法是团队内部梳理一份线上回归列表，每次上线必须回归到，并指定专人负责。数据平台发布前的 Code Review 也一直作为固定动作在执行。前面说的零故障，是回归列表和 CR 一周周跑出来的。

从去年开始，我们每周会提前拉一次研发效能数据，看看冒烟、reopen 和 bug 数。周会上至少能对着事实聊，少说几句「最近质量好像不太行」。内网和业财两条线还试过在提测前拉测试一起过用例，效果有好有坏，至少问题会暴露得早一点。监控和告警同样：扁鹊上的告警接到钉钉，再往后接的是 AI 告警分析和排障，先把无效告警压下去，再让 Agent 按 SOP 取证。值班的人不用盯着几十个群，只处理筛过一遍的东西。

基建我也逐渐改成共建，让所有同学不仅能参与业务开发也能有基建项目的经验。前期做调研、设计方案、搭基础工程、写示例、定规范，让大家都能参与到基建项目的建设，而不是只做执行者。并且通过完善基建能力，降低中后台业务开发成本、统一基础设施、把差异化的认知成本尽量抹平，落到日常就是脚手架、接入文档和默认流水线。

投入产出：先问值不值得做

手上有平台能力和新技术时，很容易先想「我们还能做什么」，再去业务里找场景。我现在更习惯倒过来：先有明确的问题、可核对的成本和结果，再决定投不投人。监控平台的大多数能力是从一次次线上排查里积累出来的；资源治理从账单看不清谁在花钱开始。效率也按结果算：功能数量参考价值有限，更值得看大家少做了多少重复操作；打包和发布有些链路从小时级压到了分钟级，业务方能直接感受到。质量更难量化：今年到现在，数据、算法、业财几条线没有出现前端引起的 P 级故障，这个零很难归因到某一个动作，只能回头看 SDK、告警、发布检查和回归是不是一直在运行。

探索项目尤其容易把「跑通了」当成结果。当时我们和测试团队一起做让 Agent 操作真机的 UI 自动化，设备执行和报告链路已经能跑，但这离有用还远。在立结项时就需要考虑评估 ROI 的情况，如果 ROI 不高就应停止投入或缩小范围，避免无期限地继续试。AI 排障也遇到过维护成本问题：每接一个场景，平台同学都要重新理解一遍业务；场景越多，人越忙，平台看起来却没有轻多少。后面我更倾向让业务 Owner 维护自己的 SOP，平台团队只守通用引擎。

有人来要资源，我通常先问：做了会有什么变化，是否有更简单的方案可以解决，不做会怎么样。季度规划里最难的也是删东西。价值说不清、以后没人维护、眼下又不着急的项目，我会尽量往后放。团队只有这些人，同时启动太多项目，最后往往每个都做得不够完整，应该集中力量做高收益的事情。

但最终的目标管理上还是一个双向的过程：需要把上面战略拆成目标和任务，再通过与实际业务的沟通和平台的实际情况结合，从下面做具体的规划事项，来承接和推动目标和任务的完成。下面小组长们有空间发起改造是好事，但需要权衡好优先级和 ROI，避免自嗨；而且业务永远是第一优先级，所有的基础建设都是为了服务业务发展。但这两者之间天然会存在一些冲突和对抗，这块还在持续摸索找平衡点。

从做好事，到让别人拿结果

把一件事做好，我相对熟悉。需求先讲清，方案有人过，测试时间留够，过程中盯住风险，最后验收和复盘。这条路虽然累，大多时候知道下一步该做什么。带人没这么直接。同一句反馈，对不同的人说，结果可能完全相反。有人希望你讲得直，有人需要先知道背景；有人给一点空间就能往前跑，有人更需要固定节奏。外部合作也一样，我以前容易急着讲自己的方案，现在会先听对方到底在担心什么。有时换个说法、退半步，事情反倒能继续走。

带人之后，结果越来越依赖别人交付，自己却对代码失去了绝对把控。重点逐渐变成如何让一群人有成长。自己写代码少了以后，有一段时间会不确定项目细节是不是还在自己手里。后来把注意力挪到方案、架构、标准、检查点和人选上。把阻塞清掉，把边界说明白，该由我承担的责任我来承担，这些成了日常里更常做的事。

前面说到「能做、想做、需要做」，资源治理是一次更完整的练习。有些人手上的工作做得很好，心里想走的方向却完全不同；有人经验还差一点，但很想试，团队也刚好需要。硬派一个人长期守着他厌烦的平台，短期能顶住，时间长了多半要出问题。那次我是发起人和项目负责人，技术方案交给另一位同学。我只把目标说清楚，所有的方案和实现都由相关同学来负责，我只做中间过程的检查，定期评估项目进度和风险，给出建议和帮助，最终项目顺利上线也完成了资源的自动化认领，整体认领率达 95% 以上。虽然项目中还有很多不足的地方，但如果当时我又把代码接过去写，项目可能会更完整更高效的完成，那位同学也少了一次完整负责的机会，这位同学也不能成长起来，后面我也只能陷在不同的项目中。

培养核心时，我会尽量让有潜力的同学逐渐接方案、主持讨论、跟产品和测试把需求商量清楚，再做一次分享。只把更多任务塞给他，通常培养不出负责人，反而会让同学增加负担或产生抗拒。

另外绩效是我吃过教训最多的地方：评价要有具体依据，也要放在团队里横向看；反馈时除了给出结论，还要解释为什么这么评，并听他怎么理解。很多时候，我都是说完以后才发现那句话可以说得更好。以及平时的非正式接触我也低估过。偶尔一起吃饭，路上聊几句，得到的信息常常比周会多。有人在会上从来不说困难，吃饭时会提一句最近卡得很难受。二十多个人只靠周会和 CR，很容易只剩下一堆任务状态。

外包同学的要求怎么定、和正式员工怎么配合，我没有找到特别稳定的办法。但有一点是我一直坚持的：“提升外包同学归属感，不区别对待外包和正式同学”。岗位和职级是否匹配、每个人这一年有没有成长，这些我也做的还不够勤。这些都是需要持续关注和提升的，从做好事，到让别人拿结果，真的不是简单的派活就行了。

还在摸索的地方

AI Coding 的推广和实践：有人每天都用，有人偶尔试一下；究竟省了多少时间，代码质量有什么变化，我目前答不上来。现在就说已经做得很好，还太早。小组负责人、核心成员和外包管理也都在半路上。

带八九人小组的时候，我总觉得自己多看一点、多做一点，团队就能拿到结果。到了二十多人，很多问题靠我补已经补不过来了。项目要舍得停，规则要写进流程，重要的事情得有人接得住。至于人，光安排任务远远不够，还要知道他想做什么、最近过得怎么样，平时多聊几句比到了绩效时再谈有用。团队凝聚力也很难靠几次团建带出来。一起扛过紧急上线，为同一个目标加过班并且拿到了结果，大家才会形成默契，遇到问题时才敢放心把事情交给对方。

上面的有些事我仍然还在试错实践。先记到这里，过段时间再回来对账。