用当前范围和暂不解决项保护需求聚焦与最小版本交付

一句话提醒

需求边界不是否定其他价值，而是明确这次解决到哪里、哪些内容当前不做，避免“顺手加一下”把核心问题膨胀成大系统。

为什么今天看它

• 边界没有写清时，扩展能力会不断挤占核心问题的资源；先锁定最常用场景和最小流程，才能让版本真正落地。

留一个问题

本期要完成的核心问题和最小流程是什么？哪些功能当前明确不做，它们的重开条件是什么？

参考思路

1. 1.先明确当前版本要解决的核心问题与目标用户场景。
2. 2.写出本期必须完成的最小流程和最常用的支持范围。
3. 3.列出容易被“顺手加入”的扩展能力，并明确它们当前不在范围内。
4. 4.说明后置能力不是没有价值，而是应在核心流程验证后再进入迭代。
5. 5.为暂不做项保留重开条件，例如真实使用频率、业务风险或闭环验证结果。

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