从个人英雄到集体智慧

从个人英雄到集体智慧：我的协作观进化与年终总结三月初接下智能客服系统迭代项目的时候，我还抱着“核心模块必须自己攥在手里才放心”的想法。当时项目刚启动，团队里三个新入职的工程师对业务逻辑不熟，产品经理提的需求又三天两头改，我看着密密麻麻的需求文档，下意识就把最复杂的多轮对话逻辑模块划到了自己的工作包里，还和组长拍胸脯说“两周就能出初版，保证不拖进度”。那两周我几乎每天泡在公司，晚上十点的工位上永远亮着我的电脑屏幕。代码写得确实快，第十三天真的拿出了可运行的Demo，测试跑通的时候我甚至在小组会上暗爽，觉得靠自己的效率硬生生把项目节奏拉快了一周。可等到和前端、数据模块联调的时候，问题一下子全冒了出来：我写的对话触发逻辑没和数据组约定的用户标签字段对齐，前端调用接口的时候发现我留的参数少了三个关键的场景标识，最严重的是我为了赶速度写的硬编码规则，在应对业务方新增的售后场景时完全无法扩展。那天联调会开了三个小时，所有人都在等我改代码，我盯着满屏的报错，第一次觉得“一个人扛下所有”的骄傲，其实是在给整个团队拖后腿。最后整个项目上线时间比预期晚了五天，复盘会上我拿着写满问题的清单准备挨骂，组长却没说我半句，只是把一份调整后的分工表推到我面前：“对话模块拆成规则引擎、场景适配、接口对接三个部分，你带两个新人做规则引擎，剩下的分给小周和小李，下周先和产品、数据开对齐会，所有接口定义、字段标准全部形成书面文档再动手。”我当时嘴上应着，心里还犯嘀咕：新人连代码规范都还没摸熟，把核心逻辑拆出去，到时候出问题还不是要我来擦屁股？真正的转变发生在规则引擎开发的第一周。我按之前的经验写了一版规则配置表，觉得逻辑已经覆盖了所有已知场景，结果负责场景适配的小李拿着售后咨询的二十个真实案例来找我，说我写的规则里没有考虑“用户同时投诉物流和商品质量”的叠加场景，要是按这个配置上线，至少15%的售后咨询会被导去错误的人工坐席组。我翻出业务方给的需求文档，发现那部分需求藏在附件的小字里，我赶进度的时候压根没看附件。更让我意外的是，跟着我做规则引擎的新人小杨，看完我的代码之后提了个用配置化替代硬编码的方案，把原来需要改代码才能调整的规则，全部做成了可视化后台的可配置项，后续业务方改规则根本不用动代码，直接在后台操作就行，光是这一个改动，就能让后续的版本迭代效率提升至少40%。那天我坐在工位上翻着两个人提的修改意见，突然意识到：我熬了几个通宵想出来的“完美方案”，其实在视角上天然带着盲区。我习惯了站在技术实现的角度看问题，却忽略了业务场景的复杂性，也忘了团队里其他人对不同模块的理解，其实能补上我没考虑到的缺口。之前总觉得“自己做最快”，但一个人再快，也快不过一群人把坑都提前填上的效率；一个人再周全，也不可能覆盖所有业务场景的细节。从那之后我开始试着把手里的工作往外拆。做用户意图识别模块的时候，我不再自己闷头写算法，而是拉着数据组的分析师一起做标注数据集，他们对用户行为标签的理解，帮我们把模型识别准确率从82%提升到了94%；做后台功能的时候，我主动找客服组的一线坐席开需求调研会，他们提的“一键导出对话记录”“相似问题自动关联推荐”功能，上线之后直接让客服人均处理效率提升了30%；甚至做项目排期的时候，我也不再自己拍板定时间，而是让每个模块的负责人自己报工期，最后汇总出来的时间比我之前定的多了三天，但实际开发过程中几乎没有出现延期，每个节点都按计划顺利完成。到六月份项目正式上线的时候，整个系统的稳定性超出了所有人的预期，首月用户满意度达到了91%，比上一版系统高了12个百分点。项目庆功会上，组长让我上台讲经验，我拿着奖杯看着台下的团队成员，半天说不出话——原来以前我追求的“个人高光”，在整个项目的成功面前根本不值一提。你一个人代码写得再好，也做不出能让全公司业务线都能用的系统；你一个人效率再高，也不可能比整个团队朝着同一个方向发力跑得更快。下半年接用户增长项目的时候，我已经完全习惯了先拉对齐会再动手。项目启动第一天，我就拉着产品、运营、数据、技术四个组的负责人开了整整一下午的会，把整个项目的目标拆解成了12个具体的里程碑，每个里程碑的负责人、交付标准、依赖关系全部写得明明白白。我不再盯着每个成员的代码写得好不好，而是把大部分精力放在协调跨组资源、对齐各模块的需求标准、解决卡点问题上。负责裂变活动的运营同学想做一个邀请得红包的功能，之前需要技术组花两周开发，我记得客服系统里已经有过类似的红包发放模块，就让技术组把那部分功能封装成了通用组件，运营那边只用了三天就完成了配置上线，整个活动的推进速度比预期快了一倍。九月份活动上线的时候，我们碰到了突发情况：第一天参与活动的用户量是预期的三倍，服务器压力瞬间拉满，要是按我以前的习惯，肯定自己坐在工位上吭哧吭哧调参数优化代码，但那天我第一时间拉了运维、架构、数据三个组的同事成立临时应急小组，运维负责扩容服务器，架构组负责调整负载均衡策略，数据组实时监控用户行为数据，我负责协调各模块的优先级，整个团队忙而不乱，只用了两个小时就解决了性能问题，全程没有出现大面积的服务故障，甚至很多用户根本没察觉到系统出过问题。那天凌晨两点多，我们一群人在公司楼下吃夜宵，运营同学举着饮料杯说“要是按以前的效率，这次说不定就得宕机四五个小时，损失至少几十万”，我笑着和大家碰杯，心里清楚：这不是我一个人的功劳，是整个团队的每一个人都在自己的位置上做对了事情，才把危机变成了增长的契机。以前我总觉得“英雄”要一个人解决所有问题，现在才明白，真正厉害的人，是能让整个团队的人都发挥出自己的优势，让1+1大于2。这一年做的两个项目，都拿到了公司的年度优秀项目奖，我带的两个新人，一个已经能独立负责核心模块的开发，另一个年底还评上了公司的优秀新人。翻着今年的工作记录，我看到年初写的个人目标里还写着“今年要成为团队里技术最牛的人”，现在觉得那个目标确实有点幼稚。技术牛当然重要，但比个人技术更重要的，是怎么把自己的技术经验传递给团队里的其他人，怎么和不同岗位的人协作，把每个人的长处都拼在一起，做出靠一个人永远做不成的事情。上周开部门年终总结会，我上台分享的时候说，我以前觉得最好的团队是“一个神队友带一群普通人”，现在才知道，最好的团队里没有神，每个人都是不可或缺的一块拼图。你不用什么都懂，也不用什么都自己扛，你只要知道团队里谁擅长做什么，知道怎么把大家的力量聚在一起，就能做出比你一个人努力十倍还要好的结果。前两天我帮小杨review他写的规则引擎新版本代码，他在代码里加了个自动化测试脚本，能自动检测规则配置的逻辑冲突，比我之前写的人工检测效率高了不止一点