面谈记录表 被面谈人姓名：张三 面谈对象：李四（技术部主管） 面谈日期：2023 年 10 月 24 日 14:30 面谈地点：公司第三会议室 记录人：王五 背景与切入 李四是个子在 2020 年刚入职，我带他三年，也帮他把产品从 0 做成了目前这个样子。最近他的线下汇报比平时少得多，我每次找他，他都尽量提前半小时到，这是大雷区。昨天下午他来了，说最近手头有个大项目要开工，但我一问，他常跟我说的那个“核心业务逻辑”仿佛又变了。 核心难题：业务逻辑的“漂移” 我直接问了一个他平时都不爱答不应的标准难题：“要是目前的死磕方向是‘极致降本’，但为了上线采用了新的中间件架构，害得核心交易链路延迟了 300ms，与此同时一线员工的操作手册被简化了，这种取舍，你们公司的北极星指标里到底看哪个？” 他愣了一下，眼神有点飘，说：“这个……按目前的 KPI 算，上线就是快。

可是……要是按财务合规的落地执行，这块亏损如何算？” 他的语速放慢了，手指头在键盘上敲了两下，又停住了。我接着问：“那你认定，目前那个上线方案，能不能改回原来的旧架构来保那个 300ms？

要么，我们能不能接纳新架构，但把变动期的那三个月的亏损算作合规的‘战略性支出’？” 他沉默了三秒，终于抬起头，有点累得慌的样子：“王经理，我实际上一直在心里纠结这个。

那会儿 KPI 导向大家拼命压成本，结局害得性能不中，目前老板换了一拨人，强调合规，又要快速上线，这俩方向卡得死死的。我本来想推那个新架构的，怕用户体验忒差，但这次……这次老板仿佛更想听我汇报那个新架构带来的‘数据治理’成果，而不是运维成本了。我是不是该回去把那个旧方案再死磕一遍，确保性能数据好看，把数据治理的局部当次要的？” 数据透视：表象下的数据真相 我让他把那个“数据治理”项目标具体数据拿出来了。我一看，发现他的眉头皱得更紧了。

原来，他之前的汇报里，那个新架构在“数据一致性”上确实做得比旧架构好，就连做到了 99.99% 的实时对账。但这个 99.99% 是如何换来的？他当时只含糊其辞说是“系统优化”，但我一查后台日志和监控大屏，发现这 99.99% 的背后，是他为了避开旧系统的瓶颈，临时牺牲了 10 分钟的旧系统维护窗口期，并且用旧系统里的冗余数据做了一次全量清洗，害得旧系统原有的 slack（弹性空间）被压缩了 40%。 “原来是这样啊，”我忍不住开口打断他，语气略微缓和了一些，“李四，你刚刚还说那个新架构延迟了 300ms，但你看我查了监控，核心交易链路实际上只慢了 120ms，剩下的 180ms，是出于你为了赶工期，硬是把旧系统的资源抢走了，把数据清洗工作强行推给了旧系统，结局旧系统扛不住，才慢慢跑出来的。之前我让你压成本，不是让你牺牲数据质量，而是让你用旧系统先把数据跑稳，再上那个新架构。你这次为了数据好看，把整个运维模式都改成了‘数据驱动型’，结局旧系统崩了，数据对不上，用户体验反而差了。” 他猛地一拍桌子，声音都大了，“王经理，你别瞎说！我之前那 10 分钟窗口期，确实是彻底够用的！我特意调整了数据库配置，把查询复杂度下降了，延迟本来就在可接纳范围内，我昨天早会还专门把那个‘新架构下数据治理的 ROI'算了一遍，比旧架构省下来的钱，起码是成本的 2 倍！你如何就只看到延迟，不看收益？之前的 KPI 考核我也没疏忽，我就是想找个新机会，把这个‘数据治理’做成新的亮点，想着能拿那个新架构的奖励。可执行起来，我发现那个旧系统别看结构老，但数据质量管住比新系统稳，故此我把旧系统那边的‘稳定性’指标往新系统那边塞，结局新系统立马崩了。” 冲突点：考核导向的错位 他持续嘟囔：“王经理，我理解你的意思，但我心里苦啊。我带着团队，大家天天对着报错信息发呆，改代码、调参数、写文档，把旧系统搞崩了，最终还得负责把旧系统的遗留难题修复好，这活儿哪位自愿干？我把新架构的优势摆出来，说数据治理能省两千多万成本，帮我争取到了新项目，我还能升职，还拿到了奖金。可目前旧系统崩了，数据对不上，我看不到任何收益，反而在嘟囔。我目前还在纠结，是该承认我‘数据认知’有难题，还是该承认你‘考核导向’有难题？要是连数据治理都这样，赶明儿上了新架构，数据如何管？

是不是连老板信任都不给？” 后续指引：从“技术执行”转向“业务结局” 听完他这段描述，我意识到，咱们之前三年的磨合，实际上就是我在用“技术逻辑”去套他的“业务逻辑”，结局适得其反。

那会儿他总当作我是帮他找新技术，目前我才明白，我这是在帮他梳理“如何用新技术解决旧系统的难题”。 我问他：“李四，咱们今天来谈，是不是想听听你如何把‘数据治理’这个项目，从单纯的‘技术升级’变成‘业务增量’？” 他愣了一下，思索了待会儿，终于点了点头：“是。

那会儿我认定我是为了技术要升级，结局目前发现，数据治理才是确实能带来利润的那个增量。但难题是，旧系统崩了，我没法去算账，没法去证明数据治理的 ROI，出于连基础数据都保不住。

故此我目前卡住了，不知道该不该去修旧系统，还是该持续推新架构，但新架构的数据又管不好，我怕到时候数据还是对不上，到时候……" “行了，”我打断他，“先别在那自我感伤了。我认定你这次最大的难题，不在于技术选型，而在于‘交付结局’的定义。

那会儿你告诉我，只要上线快就行，结局出了难题你就怪我没教好技术。但目前你告诉我，数据治理要形成效益，可你连数据治理前的‘地基’都没打稳。” “地基”就是旧系统的数据质量。“地基”不稳，再好的新架构也是空中楼阁。我问他：“那在这个节点，你是打算停下来，彻底把旧系统修好，再慢慢推新架构，还是说，既然新架构上线后数据管不好，那就先上线一个‘中间态’的混合架构，先用旧系统的数据治理，等数据稳了，再上全量？哪怕只有半年，先把地基打好。” 他盯着我看了待会儿，似乎陷入了某种计算，最终说：“我要先上‘中间态’。但这半年，旧系统务必保命，数据质量务必达标，不能丢。到时候，我再慢慢把旧系统迁移过来。你作为我的主管，你得负责盯这半年的工夫，确保数据不崩，我负责写代码，确保数据治理跑通。行不中？” 总结与下一步 我点头认可：“好，就如此定。你持续推进，王经理全程盯，确保旧系统数据不丢，数据质量达标。半年后，我们再复盘整个迁移过程，看那个‘数据驱动型’是哪位主导的，要是数据质量不达标，一切归零，重新来。” 他还想问问那个“技术奖励”的事，被我按住了：“先别谈奖励。你的核心任务就是把这半年用下来，把数据治理的成果做实，把旧系统的数据质量修到 99% 以上。到时候，你拿着数据产出的 ROI 报告去找老板，你就不是那个‘选择新架构’的决策者，而是那个‘成功落地数据治理’的执行者。

这才是你目前能拿到的最大筹码。” 他有点不好意思地笑了：“行，明白。

那我先去写那个中间态的测试盘算，确保数据不崩。王经理，谢谢你今天给我指出的方向，那会儿我就没忒想明白，赶明儿还得多跟着你干活，你是个好人。” 这次面谈，我算是真正理清了思路。

不再是用技术术语去包装业务，而是直接面对数据背后的成本与收益。未来，我不再只是他的“技术顾问”，他要成为他业务的“数据负责人”。