项目管理

最近两年我参与了不少研发团队的效能诊断，发现一个特别反直觉的现象：代码写得最漂亮的团队，往往不是交付最快的团队。有一个团队，架构文档整洁得像教科书，Code Review 认真到连变量命名都要推敲半小时，但一个中等复杂度的需求从提出到上线，平均周期是 42 天。另一个团队，代码质量不算顶尖，但相同规模的需求平均 11 天上线。拉开差距的并不是代码能力，而是需求在团队里的流转方式，，产品经理写完 P…

这是一篇我在多次参与研发团队辅导后，越来越确信的判断：很多团队不是能力不足，而是把有限的精力和注意力错配在了“画图”上，而不是“清障”上。 如果你参加过任何软件项目的启动会，大概率见过这样的场景：墙上贴满了架构图、路线图、依赖关系网络，精致得如同城市地铁规划图。但会议一散，一个开发同学对着一个因为权限问题阻塞了三天的测试环境，一筹莫展。而那张宏伟蓝图里，并没有为“今天谁来解决这个阻塞”预留任何接口…

一、我们先把话挑明：日报站会是管理上的“大号创可贴” 如果你参加过这样的每日站会，，每个人对着项目经理或技术主管，像报流水账一样说“昨天做了什么、今天打算做什么”，全程无人打断、无人讨论、也无人关心其他人说了什么，，那你很可能已经掉进了“汇报式站会”的陷阱。更糟糕的是，有些团队甚至让成员在站会上直接朗读 JIRA、PingCode 或看板上已经写明的任务状态。 我们见过最夸张的一个团队，15个人的…

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

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

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

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

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

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

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