敏捷研发

一、先把结论摆在这里：需求澄清不是产品经理的事 我干了将近十年产品，前五年我特别怕听到“需求澄清”这四个字。因为一旦有人说“我们来澄清一下需求”，潜台词往往是：产品经理又要被架在火上烤了。业务方觉得你理解能力差，研发觉得你传话都传不明白，你自己觉得两头受气。后来我花了很长时间才想明白一件事，不是因为…

一、Sprint不是信仰，而是一个需要被审视的管理工具 2018年，我带的一个团队在Sprint Review上演示了一个完全没人用的功能。产品负责人面色铁青，开发团队垂头丧气，Scrum Master试图打圆场说“至少我们按时交付了”。那一刻我意识到：我们不是在敏捷，我们只是在完成Sprint。 …

一、我们做了一个决定：把Scrum里最“硬”的东西先扔掉 2022年秋天，我所在的产品线出了一次严重事故。一块已经走到EVT阶段的核心板，因为固件团队和硬件团队对“一个传感器采样频率”的理解完全不同，两边各做各的，直到联调时才发现方案级的不兼容。损失不是几行代码的事，而是3周时间和将近17万元的PC…

线上Bug频出，敏捷测试怎么补 上个月一个周三的凌晨，我被一条告警短信震醒：核心支付接口的调用成功率在30秒内从99.98%跌到了83%。团队拉了紧急会议，开发、测试、运维、产品全在线上。回滚、止损、查日志，最终定位到一个订单状态机的并发竞争问题，一个在PRD里写了“并发场景不做处理”的需求，在开发…

一、先说核心结论：跨部门敏捷失败，不是流程错了，是KPI打起来了 过去七年，我跟踪过47个声称要“全面推进敏捷转型”的企业团队。实话讲，其中真正实现跨部门高效协作的，不超过9个。 跨部门敏捷最常见的死法，不是站会开得不好，不是Scrum Master不称职，而是两个部门的KPI在互殴。开发部背的是“…

一、先说一个反常识的核心结论 我在过去六年里，亲眼见过至少四支团队从传统瀑布模式转向 Scrum 敏捷开发。其中两支团队在转型后的第二个季度，线上故障率反而上升了将近 40%。这个数字不是我从哪份报告里摘的，是团队自己复盘时拿出来的真实数据。更让人不安的是，故障的类型变了，不是新功能逻辑错误，而是老…

2024年秋天，我在深圳给一家200人规模的SaaS公司做研发管理咨询。CTO把我拉到会议室，白板上写着一行字：“Q4目标：版本周期从3个月缩短到2周。”他转过身问我：“你觉得能实现吗？” 我盯着那行字看了十秒，然后反问了一句话：“你们愿意为了这个目标，把整个团队的协作方式、考核机制、甚至组织架构都…

一、先给结论：看板贴满墙不是敏捷，是集体焦虑的物理投影 做了十五年研发管理，我见过最荒诞的一幕，是在某家中型科技公司的会议室里。三面墙贴满了彩色便利贴，粉的是需求，黄的是开发中，蓝的是测试，绿的是已完成。产品负责人骄傲地跟我说：“你看，我们敏捷做得多彻底。”我问他一个问题：“上个月贴上去的这37张粉…

一、站会没死，是你的团队先“演”了起来 2019年我在一家中型SaaS公司带产品团队，每天早上9点15分，12个人围成一圈，对着墙上的看板开始站会。整整四个月，我以为我们在做敏捷。直到有一天，CTO突然站到我身后听完一整场站会，散会后把我叫到会议室说了一句话：“你不觉得他们每个人说话的时候，眼睛都在…

别再忍让：敏捷不是“可以随便改”，而是“让变更付出合理代价” 做产品十五年，我带过的团队超过一百个。有一个现象反复出现：很多团队把 Scrum 玩成了“需求自助餐”，业务方随时点菜，开发团队被迫接单，产品经理成了传菜员。 上个月和一家金融科技公司的产品负责人聊，他给我看了一组他们内部的数据：一个双周…