项目管理

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

我见过最失败的一次“敏捷转型”，是在一家当时估值已经超过 10 亿美金的 SaaS 公司里发生的。那一年他们刚把 Jira 从 Server 版迁移到 Cloud，又花了一个季度在插件市场上挑了七款“最好用”的敏捷看板插件，还给每个团队都配了专职 Scrum Master，甚至把 Atlassian 的官方顾问请进办公室做了一整个月的落地培训。 结果呢？研发效能不升反降。最典型的症状不是工程师写不…

去年的这时候，我飞过去给一个团队“救火”，，起因只不过是一次迭代规划会上常规的故事点估算。产品负责人指着客户刚刚确认过的“用户自助报表”史诗说：“你们估下来 34 个点，过去三次迭代咱们平均速度是每周 18 点，那两周应该稳了吧？我先回复客户了。”开发组面面相觑，没人当场拦下这句话，因为此前每次试图解释“点不是时间”，都被简单粗暴地理解成“你们不想承诺”。结果并不意外：那个功能“按时上线”后，验收…

如果说过去五年做研发管理，我学到最重要的一课是什么，那一定不是某个流程框架，也不是某款神兵利器，而是，，高质量的复盘，远比完美的计划更能决定团队的稳态。 这个结论，来自两次险些把团队拖垮的混乱期，以及两次硬着头皮、不得不做的深度复盘。一次在2021年秋天，我们刚刚“强行”上了Scrum；另一次在2023年初，我们明明度量数据很漂亮，交付却仍然频繁翻车。现在回头看，第一次复盘让我意识到流程形态不等于…

一个让我至今记忆犹新的项目是：团队连续三周平均工时超过 10 小时，但交付速率反而比正常排期慢了 40%。当时如果只看工时填报系统，所有人都像劳模，但当我们把工时的帘子掀开，发现 65% 的额外时间花在了“等测试环境”、“修跨模块的接口兼容性”和“需求确认”上。 这不叫工作，这叫空转。研发管理的刀刃从来不该对着人卷了多久，而该对着“工作在哪个环节卡住了”。 一、盯工时的管理，往往在掩盖系统的无能 …

那个功能还要多久？” “快了，这周应该可以。” “到底多久？给我个准话。客户已经催我三次了。” 这是开发工程师小陈今天第4次被问到进度。第一次是晨会上，第二次是午餐时技术主管的微信，第三次是下午3点项目经理在工位旁的“路过”询问。当他第5次从代码的思路中被拉回现实，他发现自己甚至忘记了刚才写到哪一行。而在项目的整体时间线上，这一天，功能模块的进度不出意外地又延期了2小时，，不是写代码的时间不够，而…

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

如果你还在要求甚至考核产品经理（PM）的需求文档必须写到多详细、多厚、多像技术设计文档，那你团队的研发效能大概率正在被一种“虚假的安全感”反噬。 一、核心结论：详细需求文档，是研发效能的第一道鬼门关 先把最反常识的结论放在最前面：要求 PM 写出面面俱到、边界清晰、逻辑闭环的详细需求文档，不仅不能提升研发效率，反而是导致交付延期、产品货不对板、研发积极性下降的根源之一。 我们过去服务过一家从 Ji…

研发管理实战：我们如何砍掉30%无效需求 去年四季度复盘时，我们对着产品 Backlog 列了一张表，把过去一年所有上线功能的使用数据跑了出来。结果让整个团队沉默了：36% 的需求在上线后月活跃用户触达率不到 5%，其中将近一半的功能从未被深度使用过，，也就是说，我们每写 10 行代码，就有 3 行在给产品“增肥”而不是“增肌”。更让人后背发凉的是，这些功能的开发工时，占到了全年总交付工时的 28…

一年前，我旁听了一家电商公司的迭代复盘会。数据很漂亮：交付率 97%，需求吞吐量环比提升 20%，燃尽图像教科书一样平滑。但轮到业务方发言时，运营总监甩出一句话：“你们做出来的优惠券叠加逻辑，和我们想的完全不一样，这个迭代白干了。”会议室突然安静，，所有人都在盯着看板上的绿色进度条，却没人发现团队对“满减叠加”的理解从一开始就岔开了道。 这件事让我意识到一个被大量研发组织系统性忽视的事实：进度管理…