把模糊需求翻译成可判断、可拆解、可验收的问题

一句话提醒

接需求不是把一句功能愿望转给研发，而是先问清背景、目标、场景、范围、规则、验收和风险。

为什么今天看它

• 越早把目标、边界、规则和风险问清楚，后面越少返工、扯皮和责任不清。
• 把需求翻译成可判断的问题，才能为优先级、方案和验收提供依据。

留一个问题

这个需求为什么现在做？谁会变好？具体场景和范围是什么？规则、数据、技术影响、验收标准和风险是否已经说清？

参考思路

1. 1.先问需求从哪里来、当前出了什么问题，以及为什么现在必须做。
2. 2.确认业务价值、用户价值和希望改善的结果或指标。
3. 3.明确使用者、具体场景、前后流程，以及本期做什么和不做什么。
4. 4.继续追问规则、权限、数据口径、异常处理和系统影响。
5. 5.提前对齐交付物、验收方式和风险承担者，避免上线后才发现口径不一致。

03_知识库/综合/接需求十问：把模糊需求翻译成可判断问题.md