工作总结
时间:2026-03-24 作者:工作计划之家保险试用期工作总结[参考]。
干技术经理这摊活儿，试用期这三个月，说白了就是把自己从一个“写代码的”硬生生掰成一个“管事的”。我管的是保险核心业务系统的几个项目组，车险承保、理赔流程再造、还有跟第三方平台的数据对接。这一百来天，踩过的坑、填过的土，比过去三年加起来都多。今天不谈虚的，就说说那些让我半夜爬起来的事儿，和怎么带着兄弟们从“出事了慌”变成“出事了知道该往哪儿摸”。
第一个让我后背发凉的，是入职第三周的那个周五下午。车险承保系统突然大面积超时，业务那边电话直接打到我这，说前线出单员已经排了四十多分钟，客户在柜台上拍桌子。我冲进机房，运维指着监控面板说：“数据库连接池爆了，但连接数没到上限，奇怪就奇怪在这儿。”我调出过去一个小时的慢查询日志，发现有一条新上线的核保规则查询，走了全表扫描，单次执行时间从平时的30毫秒飙到了4秒。但这条规则上线前压测过，当时数据量没那么大，上线后保单数据累积，索引失效，问题才暴露出来。
我让团队先把那条规则的查询临时切到备库，再把慢查询里关联的几张表重建索引，十五分钟后系统恢复。业务那边松了口气，我没松。当晚我拉着DBA和开发组长，把近一个月的慢查询日志全翻了一遍，找出另外三条有隐患的SQL，提前优化了。第二天复盘会上，我问开发组：“压测环境的数据量是线上的十分之一，你们是怎么通过验收的？”没人吭声。后来我定了一条规矩：所有涉及核心交易链路的SQL变更，必须在模拟线上数据量级的压测环境里跑满24小时，才能上线。这条规矩后来被部门老大拿去当了整个技术中心的红线。
另一个让我重新思考“技术经理”这三个字的，是理赔流程再造项目的数据对接。第三方公估公司要实时推送查勘数据到我们系统，接口文档写得明明白白，但上线第二天就出岔子——对方传过来的JSON报文里，有些字段名的大小写跟文档不一致，我们的解析程序直接报错，导致两百多笔查勘任务卡在队列里。开发跟我说：“是他们不按规范来，我们没错。”我当时没忍住，说了句不太好听的：“你跟我争对错，业务那边等得起吗？”
那天下午我没干别的，就坐在开发旁边，看着他写了一个兼容大小写的字段映射层，又把所有外部接口的异常处理从“抛异常”改成了“记录原始报文+告警+跳过”。搞完这些，我把他叫到茶水间，跟他说：“技术人的成就感，不应该是‘我没错’，而是‘系统没崩’。第三方永远会有幺蛾子，我们要做的，是让幺蛾子影响不到业务。”后来这个小伙子主动牵头做了一个“外部接口巡检工具”，每天跑一遍所有第三方接口的连通性、响应时间和数据格式一致性，现在已经是组里处理外部对接问题最快的人。
团队成长这块，我有个不算办法的办法——故障复盘不许说漂亮话。有一次，一个批处理任务半夜挂了，导致第二天早上的报表延迟了两个小时。原因很简单：开发改了代码里一个公共类的静态变量，没通知其他组，另一个批处理调用时发生了线程安全问题。复盘会上，那个开发支支吾吾说“以后注意”。我打断他：“别说以后注意，你告诉我，你改代码的时候有没有想过这个类被多少地方调用？有没有跑过全量回归测试？有没有在群里喊一嗓子？”他摇头。我说：“那你不是粗心，你是没把系统当自己的。”
这话说重了，但管用。后来我带着他们把核心系统的公共模块梳理了一遍，画了依赖关系图，定了“公共代码变更必须走评审、必须知会所有关联组”的流程。更重要的是，我让每个开发轮流当“值班架构师”，谁值班谁就要在群里同步当天的变更信息、回答其他组的疑问。两个月下来，那种“各扫门前雪”的劲儿淡了很多。
再说说跟业务撕扯的事儿。上周理赔部门提了一个需求，要在查勘任务分配规则里加十几个判断条件，说是“要精细化运营”。我拉着产品、开发一起过了三遍，发现这个需求逻辑上有冲突——条件A和条件B在某种场景下会互斥，但业务没写清楚优先级。如果按他们给的规则直接开发，上线后至少20%的任务会匹配不到人，落到人工池里。
我跟业务负责人坐下来，没跟他吵需求，而是让他给我讲了一遍一线查勘员怎么接单、怎么抢单、什么情况下会抱怨。聊了一个小时，我发现他们真正要解决的不是“规则更细”，而是“高峰期任务没人接”和“偏远地区分配不均”这两个痛点。最后我们把十几个条件压缩成四个核心因子，加了一个动态权重的算法，开发量少了三分之一，上线后高峰期无人接单的比例降了百分之四十。临走业务负责人跟我说：“早知道你这么聊，我早来了。”我心想，早知道我该更早去问他们“到底为什么”。
试用期这三个月，要说最大的收获，不是什么技术方案、什么流程规范，而是学会了一件事：技术经理不是技术最好的那个人，是那个让技术能真正解决问题的人。代码写得再好，系统崩了就是崩了；方案设计得再漂亮，业务不认就是白干。我现在每天到办公室第一件事，不是开电脑看代码，而是去业务那边转一圈，问问他们昨天系统有没有卡、哪个功能用得最窝火。
以后的路，活儿肯定更杂。我给自己定了三条死规矩：一是核心系统的每一次故障，必须有完整的根因分析和防范措施，不能糊弄；二是每个开发必须轮岗做一次“值班架构师”，不轮岗不算转正；三是每个月至少跟业务部门的人吃一顿饭，不带电脑，只聊他们怎么干活。
干这行，系统是冷的，但解决问题的人是活的。让系统稳一点，让团队硬一点，让业务顺一点——这三件事够我忙活很久了。
-
更多精彩工作总结内容，请访问我们为您准备的专题：工作总结