研发管理

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

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

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

我们往往在项目复盘时发现一个残酷的事实：所有迭代都按时交付了，燃尽图漂亮得像教科书，但产品上线后无人问津，或者技术架构在三个月后全面崩塌。更让人不安的是，这些问题在开发过程中并非毫无征兆，但它们被“进度正常”的报表完美地掩盖了。 类似的情况我在多个团队中反复观察到。一个团队用堪称模范的 Scrum 流程跑了六个迭代，每个 Sprint 的完成率都在 90% 以上，但业务方突然叫停了项目，因为用户反…

去年，一家营收过亿的 SaaS 公司技术合伙人找到我，满脸困惑：他刚花大价钱上了一套研发效能度量平台，给每个小组定义了十几个 KPI，从人均代码当量到需求流转天数，奖罚直接挂钩。结果一个季度下来，线上缺陷数翻了一倍，两个骨干工程师悄悄提了离职。他的原话是：“数据很好看，但我感觉团队正在失控。” 我只问了他一个问题：“在推行这些 KPI 之前，你们能稳定做到每两周发布一个可用版本吗？” 他沉默了一会…

去年有位创业的朋友找我吐槽：他们公司全员学了 Scrum Guide，考了 CSM，用上了和某大厂一模一样的项目管理工具，结果研发效率反而更低了，，原来一周能上线两个需求，现在光是站会、计划会、评审会、回顾会就占掉工程师接近 40% 的时间，迭代速度还不如以前用在线 Excel 管需求的时候。 这不是个例。过去十年我先后在两家头部互联网公司带过团队，也以联创或技术顾问身份参与过四家从 0 到 1 …

曾经带过一个电商中台团队，当时公司正处于从外包项目向自有产品转型的关键期。一次月度经营会上，CEO 突然抛出一个问题：“研发团队这么多人，为什么一个会员中心做了两个月还没上线？你们到底在忙什么？”我翻开笔记本，上面记满了需求评审、技术债偿还和线上故障处理的事项，但在那个场合，这些解释都显得苍白无力。那一刻我意识到：技术负责人最大的危险，不是技术落后，而是你做的事在老板的认知里“不可见”。 那次之后…

跨部门协作不是沟通问题，是成本分摊问题。这个结论来自我们团队过去两年踩过的十几次坑，，每次复盘“为什么又扯皮了”，最终都指向同一个根因：没有人拒绝协作，但每个人都在潜意识里计算这笔协作对自己的 KPI 到底有没有收益。 做了这么些年研发管理，我用过一个很土但管用的比喻，，跨部门协作就像拼车。如果路线完全顺路、费用均摊合理，大家都愿意上车；一旦有人得多绕路、多出油钱，嘴上还在说“我们配合”，实际上已…

我曾带领过一个只有7个人的产品研发团队，产品经理1人，开发4人，测试1人，UI设计1人。按理说，这种小团队应该像特种兵一样敏捷，但现实却是一版需求传达到开发手里已经变了味，测试拿着三周前的设计稿在测新功能，产品经理和开发因为“需求理解不一致”每天吵架。直到有一天，我摔了显示器，，不是因为愤怒，而是因为它挡住了大家的视线。这个动作让我突然意识到，真正的障碍不是人员能力，而是角色之间那堵无形的墙。下面…

去年秋天，我旁观了一家 SaaS 公司某产品线的需求评审会。会议预定 1 小时，实际开了 2 小时 23 分钟。中途 3 名开发打开笔记本开始处理线上报警，1 名测试全程刷手机，产品经理讲到最后声音已经沙哑，而唯一做决策的技术 VP 在会议第 70 分钟才被临时拉入，他听了几分钟说：“这个需求的原始假设就不成立，前面全白讨论了。” 那天会议室里 11 个人的平均时薪大约是 320 元。一场会下来，…