Loading...
Loading...
Compare original and translation side by side
1. VALIDATE THE PROBLEM
□ Does this solve a real, validated user pain point?
□ Have we talked to actual users about this need?
□ What evidence supports building this?
2. CHECK ALIGNMENT
□ Does this support the core product vision?
□ Would this delay our current release?
□ What are we NOT building if we build this?
3. MEASURE IMPACT
□ How will we know if this feature succeeds?
□ What KPIs will change?
□ Can we quantify the value (time saved, revenue, retention)?
4. ASSESS COMPLEXITY
□ What's the true cost (build + test + maintain + document)?
□ Does this add dependencies or technical debt?
□ Can we ship a simpler version first?
5. FINAL GUT CHECK
□ Would we delay launch by a month for this feature?
□ Is this a differentiator or just table stakes?
□ Would removing this harm the core experience?1. 验证问题真实性
□ 该功能是否解决真实且经过验证的用户痛点？
□ 我们是否与真实用户沟通过此需求？
□ 有哪些证据支持开发此功能？
2. 检查对齐性
□ 该功能是否符合核心产品愿景？
□ 它会延迟当前版本的发布吗？
□ 如果开发此功能，我们将放弃开发哪些其他功能？
3. 衡量影响
□ 我们如何判断该功能是否成功？
□ 哪些关键指标（KPI）会发生变化？
□ 能否量化其价值（如节省时间、增加收入、提升留存）？
4. 评估复杂度
□ 真实成本是多少（开发+测试+维护+文档）？
□ 会增加依赖或技术债务吗？
□ 能否先发布一个更简化的版本？
5. 最终直觉检查
□ 我们是否愿意为该功能延迟一个月发布？
□ 这是差异化功能还是行业标配？
□ 如果去掉此功能，会影响核心用户体验吗？undefinedundefined
**Rule 2: Use Version Control for Scope**
Treat scope like code. Track changes. Require approval for additions.
```bash
**规则2：用版本控制管理范围**
像对待代码一样对待范围。跟踪变更，添加功能需要经过审批。
```bash
**Rule 3: The 48-Hour Rule**
When someone requests a new feature, wait 48 hours before adding it to the backlog. Most "urgent" requests feel less urgent after reflection.
**Rule 4: Budget-Based Scoping**
Every feature has a cost. When something new comes in, something else must go out.
"Yes, we can add that. Which of these three features should we cut to make room?"
**规则3：48小时规则**
当有人提出新功能需求时，等待48小时再将其加入待办事项。大多数“紧急”需求经过思考后会变得不再紧急。
**规则4：基于预算的范围规划**
每个功能都有成本。当有新需求加入时，必须移除其他功能来腾出空间。
“是的，我们可以添加这个功能。那我们应该砍掉以下三个功能中的哪一个来腾出资源？”"That's an interesting idea. Based on our user research, it doesn't solve our core user's top three problems. Let's add it to the v2 consideration list and revisit after we validate the MVP."
"I understand the value this could bring. If we add this, we'll delay launch by [X weeks] and deprioritize [Y feature]. Here are the trade-offs - which path should we take?"
"Thanks for the feedback. We're focused on [core problem] right now. I've logged this for future consideration. Can you tell me more about why this would be valuable?"
"Is this scratching my own itch or solving a real user problem? Would I bet the release date on this?"
"Stop. Before we add this feature, answer: Does this solve the core user problem we defined at the start of this session? If not, add it to a DEFERRED.md file and stay focused on the current scope."
“这是个有趣的想法。根据我们的用户研究，它并未解决核心用户的三大痛点。我们将其加入v2版本的考虑清单，在验证MVP后再重新评估。”
“我理解这个功能的价值。如果添加它，我们将延迟发布[X周]，并优先放弃[Y功能]。这是相关的权衡方案，我们应该选择哪条路径？”
“感谢你的反馈。我们目前专注于解决[核心问题]。我已将此需求记录在未来版本的考虑清单中。能否详细说明这个功能对你的价值？”
“这是在满足我自己的需求，还是解决真实的用户问题？我是否愿意用发布日期来赌这个功能？”
“停。在添加此功能前，请回答：它是否解决了我们在会话开始时定义的核心用户问题？如果没有，将其加入DEFERRED.md文件，继续专注于当前范围。”
For each item older than 30 days:
1. Has anyone asked about this since it was added?
2. Does it still align with current product vision?
3. If we never built this, would anyone notice?
If the answer to all three is "no" → Delete it.对于所有超过30天的待办项：
1. 自添加以来，有人询问过这个需求吗？
2. 它仍然符合当前的产品愿景吗？
3. 如果我们永远不开发它，有人会注意到吗？
如果三个问题的答案都是“否” → 删除该待办项。1. Features completed today: [list]
2. Scope additions today: [list]
3. Was each addition validated? [yes/no]
4. Tomorrow's focus: [single item]undefined1. 今日完成的功能：[列表]
2. 今日新增的范围：[列表]
3. 每个新增范围是否经过验证？[是/否]
4. 明日重点：[单一任务]undefined| Date | Request | Source | Decision | Rationale | Trade-off |
|---|---|---|---|---|---|
| 2025-01-15 | Add export to PDF | PM | Deferred v2 | Not core to MVP | Would delay launch 2 weeks |
| 2025-01-16 | Dark mode | User feedback | Approved | User research shows demand | Removed social sharing |
| 2025-01-17 | Add caching layer | Claude | Deferred | Premature optimization | Stay focused on core feature |
| 2025-01-17 | Refactor to hooks | Cursor | Rejected | Works fine as is | Technical scope creep |
**Agents as Stakeholders:**
AI coding agents are now stakeholders in your project. They have opinions. They make suggestions. Treat them like any other stakeholder:
- **Log agent suggestions** in your scope decision log with the agent name as source
- **Apply the same rigor** you would to a PM or executive request
- **Agents optimize for different things** (code quality, patterns, completeness) than you might need right now
- **"The agent suggested it" is not a valid reason** to add a feature
Common agent-driven scope creep patterns:
- "Let me also add error handling for edge cases you haven't hit yet"
- "This would be cleaner with a refactor"
- "You should probably add tests for this"
- "Let me add TypeScript types for these additional scenarios"
Each of these might be good ideas. None of them are your current scope unless you decide they are.| 日期 | 需求内容 | 提出方 | 决策结果 | 决策依据 | 权衡方案 |
|---|---|---|---|---|---|
| 2025-01-15 | 添加PDF导出功能 | 产品经理 | 推迟至v2版本 | 非MVP核心需求 | 会延迟发布2周 |
| 2025-01-16 | 深色模式 | 用户反馈 | 批准 | 用户研究显示有需求 | 移除社交分享功能 |
| 2025-01-17 | 添加缓存层 | Claude | 推迟 | 过早优化 | 继续专注核心功能 |
| 2025-01-17 | 重构为Hooks | Cursor | 拒绝 | 当前实现正常可用 | 属于技术范围蔓延 |
**将AI Agent视为利益相关者：**
AI编码Agent现在是项目的利益相关者。它们有自己的观点，会提出建议。像对待其他利益相关者一样对待它们：
- **记录Agent的建议**：在范围决策日志中记录，来源标注为Agent名称
- **应用相同的审核标准**：与对待产品经理或高管的需求一致
- **Agent的优化目标不同**：它们可能更关注代码质量、模式完整性，而非当前的发布需求
- **“Agent建议的”不是添加功能的合理理由**
常见的Agent驱动的范围蔓延模式：
- “我还可以为你尚未遇到的边缘情况添加错误处理”
- “重构会让代码更简洁”
- “你可能需要为这个功能添加测试”
- “我来为这些额外场景添加TypeScript类型”
这些可能都是好主意，但除非你明确决定，否则它们都不属于当前范围。1. "What user problem does this solve?"
2. "What's the smallest version we could ship?"
3. "What are we NOT building to make room for this?"
4. "How will we measure success?"
5. "What happens if we never build this?"1. “这个功能解决了什么用户问题？”
2. “我们可以发布的最小版本是什么？”
3. “为了开发这个功能，我们将放弃开发哪些功能？”
4. “我们如何衡量成功？”
5. “如果永远不开发这个功能，会发生什么？”