需求评审

«本文从一个 11 人产研小组的真实迭代复盘出发，把"验收标准怎么写才能不被扯皮"这件事拆成可复现的步骤与模板。» 一、现象与背景：验收会上一句"我觉得不够流畅"，能烧掉多少人天 先上数字。我们小组 5 后端、4 前端、2 测试，2024

背景 我做了 15 年技术 PM，最擅长把复杂原理讲成大白话，但有一个场景我至今没有一套稳定可复用的方法：向非技术背景的业务负责人（VP / 客户方）解释"看起来很小、其实代价很大"的需求。 典型场景：业务方拍桌子说"就在订单页加个备注字段

先说背景。 做了 10 年技术 PM，带过 3 个 6~15 人的后端团队。我越来越注意到一个趋势：需求评审会越开越短、越开越"形式化"。 过去我主持的评审会动辄 1 小时，每个需求都要过"为什么做 → 用户场景 → 不做的代价 → 技术方