RQ-01
F旗舰
8.3
多渠道需求归集结构化
同一个「导出」需求，销售微信两条、客服工单两张、客户邮件一封、老板语音一段 —— 六次转世，需求池里还是没有它
共 15 个场景。逐个点「保留 / 待讨论 / 后置」， 结果只保存在本机浏览器，可以复制出来。
建议的判断顺序：先问这件事没做好谁会生气（痛感）→ 再问错了能不能当场看出来并改（能不能交给 Agent）→ 最后问客户手上现有的文件够不够跑（落地难度）。 需要客户先做数据治理的场景，不要放在第一批。
同一个「导出」需求，销售微信两条、客服工单两张、客户邮件一封、老板语音一段 —— 六次转世，需求池里还是没有它
需求池 427 条，最近半年动过的不到三分之一 · 「进来了没人清、历史需求没人敢删」—— 每一条都是不敢碰的存量
老板会上问「华正那个导出功能后来怎么样了」· 没有回溯档案的产品经理，每次提问都是一次翻聊天记录的考古
评审会上研发问「两个状态同时触发怎么办」· 这种问题最好的出现时机是评审前一天，不是评审会上
「本期不做」写在范围声明里，正文却详细描述了它的交互 · 研发按正文实现，范围争议回到产品头上
评审会前一小时还在找「这个需求哪个客户提的」· 证据没带齐的评审，每个问题都是一次减分
项目后期「搞不清哪些需求满足了、哪次变更谁批的」—— 靠人执行的「口头需求禁止生效」制度，从来没有成功过
评审会开完，决议散在三个人各自的记忆里 · 一个月后「当时不是说好挂起吗」—— 没有纪要的会议等于没开
老板周日晚上 60 秒语音：「巡检报告加个导出，最好下周就能用」· 翻译成需求卡需要三件事：原话、结构化、澄清问题
没有专职测试的公司，验收就是产品经理拿自己的手机点一遍 · 「感觉没问题」是唯一的测试报告
「连锁反应式灾难」的复盘第一条：回滚预案没有 · 检查清单的价值不在列出来，在逐项核过并留下痕迹
事故复盘停在「下次注意」—— 三个月后同类事故再来一次 · 复盘的价值在改进项闭环，初稿是闭环的起点
人工质检只能抽检 1%-2% 的会话 · 「报表与导出」168 条工单聚成一个主题 —— 而需求池里这条需求去年被拒了
销售答应客户的「Q3 一定上」，产品侧从没看见过 · 承诺散落销售微信是续约纠纷之源
定制工时占研发 39%、毛利掉到 58% —— 投资人的警戒线是 65% · 这笔账绝大多数中小 SaaS 从来没算过