项目管理

2023 年秋天，我坐在一家智能硬件公司的季度复盘会上，看着三块屏幕同时投出三张"缺陷趋势图"，三条曲线的形状完全不同。测试负责人说他的数据来自测试管理系统，产…

去年第三季度，我帮一家做工业软件的公司复盘一个延期了 47 天的版本。打开他们某项目管理平台的仪表盘，任务完成度是 94%，燃尽图漂亮地贴着计划线收敛；可打开缺陷库，这个版本上线后…

大多数研发团队的状态设计，不是从业务出发，而是从一次会议里的抱怨出发，"这个需求到底在谁手上？"于是有人加了一个状态叫"待联调"，过两周又加…

2023 年 Q3，我参与复盘了一起让团队很尴尬的线上事故：一个改动三家银行对接协议的需求，被研发同学打了「后端」「优化」两个标签，然后顺理成章地进了一个普通迭代。它没有走安全评审…

去年 Q4，我帮一个 180 人规模的研发组织做流程复盘时，翻到一条特别典型的记录：一个只改了 3 行配置的任务，被登记成“需求”，走完了需求评审、技术评审、用例评审三道关卡，前后…

去年第四季度，我参与了一次 200 人规模研发组织的季度复盘。他们在季度初立了 12 个 OKR 级别的交付目标，季度末真正上线的只有 7 个；更值得追问的是，这 7 个里有 3 …

一次版本评审会上，我在大屏上看到迭代看板的完成度是 92%，心里是踏实的。两个小时后，测试负责人把缺陷清单甩过来：真正可以交付验收的功能只有 61%，剩下那些“已完成”的任务，有的…

去年我接手一个效能复盘项目时，遇到了一件很典型的事：一个 130 人的研发团队，在项目管理平台里积累了 380 个任务标签，但当他们想回答“返工主要来自哪里”这个简单问题时，能直接…

如果只能用一个字段判断一个研发团队的任务管理是否可信，我会选“完成度”。不是看它的平均值，而是看它被修改过几次、每次改动的幅度有多大、改完之后有没有人回头验证。我见过一个 320 …

2024 年 3 月，我旁听了一家做企业服务软件的公司的迭代复盘会。会议室大屏上第一页写着一行很漂亮的数字：上个迭代完成度 94%。翻到下一页，5 个承诺交付的需求里只有 3 个真…