研发管理

一、版本延期不是“管理事故”，而是“技术债务的利息结算” 我见过最离谱的一次延期，是一个本该 4 周交付的版本，最终拖了 14 周。复盘会上所有人都很痛苦。产品经理说需求写得很清楚，开发说接口联调被阻塞了三天，测试说提测质量太差根本不敢放行，项目经理说每个节点的甘特图都标红了但没人真正在意。最后老板问了一句：“那到底是哪个环节出了问题？”会议室安静了十几秒。没有人能回答，因为问题根本不发生在任何一…

一、先说结论：研发管理的价值，不需要“翻译”，需要“定价” 2018年我在一家SaaS公司做技术总监，年底述职时我用了一页PPT展示团队成果：全年上线47个功能、修复329个缺陷、代码提交量同比增长62%。汇报结束，CEO问了我一个问题：“你这些数据跟我有什么关系？”当时我愣住了。事后复盘，我才意识到，研发管理者最容易掉进的坑，就是用量化过程来替代量化价值。 功能上线数、代码提交量、加班时长，这些…

今年年初，我旁听了一个 200 人研发团队的代码评审会。会议室里坐了 12 个人，投屏上滚动着几百行 Java 代码，没人说话。三分钟后，一位高级工程师打了个哈欠，说了句“看着没问题，过了吧”，全员举手通过。会后我问技术经理：你们一周有多少这样的评审？他翻了翻日历告诉我，12 场。我再问：最近一次评审拦住一个线上事故是什么时候？他想了很久，没有回答。 这不是个别现象。大多数团队的问题不是没做代码评…

研发管理如何激励老员工带新人？ 去年秋天，我旁听了一场研发团队的项目复盘会。CTO 在会上问：“小王入职快半年了，现在能独立接手模块吗？”小王的导师老周沉默了几秒，说：“还在熟悉系统，再给点时间。”会议室里几个人交换了一下眼神，大家都知道，小王这半年主要在做边缘任务，核心技术文档没人给他看，关键的代码评审老周总是自己做完再丢给他结果。不是小王笨，是没人真正在“带”。 会后我找老周聊，他点了一根烟，…

2024 年，我帮一家 B 轮 SaaS 公司做研发诊断。CTO 打开 Jira 给我看，过去 90 天，P0 级别线上事故 23 起，平均每周接近两次。他每天醒来第一件事不是看规划，而是查告警短信。自己亲自下场排查过数据库死锁、改过 nginx 配置、深夜远程帮前端改过打包脚本。

做了十五年研发管理，我见过最危险的信号，不是技术债务本身，而是团队对技术债务只有两种态度：要么视而不见拼命堆功能，要么隔三差五喊“还债”要求停下手头一切来重构。 这两种极端都不对。

今年年初我做了一个项目复盘，把一个已经烂尾三个月、花掉将近160万人天成本的中台项目从头拆解了一遍。结论让人很难受： 技术上没有任何一个单点问题是解决不了的，但整个项目最后是被“协作链路”拖死的。

一、当KPI成为研发的第一生产力，你离灾难只差一个季度 2019年，我接手了一个SaaS产品的研发团队。当时公司的研发VP对董事会承诺了一个“极具挑战性”的产品Roadmap ， 他拍胸脯说六个月后要上线一套行业领先的自动化营销引擎。为了确保进度，他引入了一套严密的KPI体系：每个迭代代码提交量必须达到1500行以上，功能模块完成率不能低于85%，测试通过率要高于90%。数据看板很好看，红的绿的柱…

十年前，我刚接手一个电商中台项目时，最怕听到产品经理说“有个小调整”。那个“小调整”最终让订单中心重构了三回，团队加班超过400小时，两个核心开发离职。我当时把责任归结为“产品不专业”、“老板拍脑袋”。直到我自己开始带研发团队、做架构决策、甚至参与业务战略讨论，才逐渐意识到： 需求频繁变更本身不是问题，问题是我们把“变更”当成了意外，而不是研发系统的常态输入 。

一、核心结论：改变决策方式的不是报表本身，而是你“用”它的方式 过去八年我以研发负责人身份主导过三个产品线从零到一的构建，同时作为顾问接触过超过四十家企业的软件选型和流程改造。在这个过程中我反复遇到一个场景：管理者和团队坐在会议室里，投影仪上打开两张报表，一张来自传统Excel导出，一张来自研发管理软件自动生成的可交互图表。数据完全一样，团队构成完全一样，但决策速度能差出三倍，决策质量更不在一个量…