用明确的做与不做控制需求范围，让核心问题先闭环

一句话提醒

需求边界不是否定扩展价值，而是明确当前阶段解决到哪里、哪些内容暂不解决。

为什么今天看它

• 没有边界，团队很容易在顺手加功能的过程中把一个小问题膨胀成大系统。
• 把暂不做的内容写清楚，才能保护核心问题先完成，并为后续迭代留下判断依据。

留一个问题

这期最核心要解决的问题是什么？哪些功能直接支撑它，哪些虽然有价值但应该明确放到后续？

参考思路

1. 1.先写清本期要解决的核心问题和目标结果。
2. 2.列出本期必须支持的最小场景、资料类型和核心流程。
3. 3.主动写出当前不覆盖的格式、下载、编辑、分类或协同等扩展项。
4. 4.判断每个新增想法是否影响核心闭环，避免用顺手做一下扩大范围。
5. 5.记录后续扩展的重新评估条件，按真实使用习惯逐步放开边界。

03_知识库/问题/什么是需求边界，为什么边界不清需求就会失控.md