SCOPE LEDGER / 项目边界账本
用一份持续更新的账本， 守住首期范围
边界账本不是静态需求清单。它把“首期必须完成”“本期明确不做”“依赖谁提供什么”和“仍待确认什么”放在同一处，每次取舍都留下时间、原因与确认人。
SCOPE / 项目范围
先看这类项目通常包含什么。
- 01业务结果
先写完成后哪项业务状态会改变，以及由谁判断结果成立。
- 02首期必须做
只保留无法删除的角色、任务、数据和异常处理。
- 03明确不做
把二期设想和临时想法公开放入后置区，避免悄悄回流。
- 04依赖与未知项
为接口、数据、账号和待定规则指定负责人及最晚确认时间。
DECISIONS / 关键判断
开始开发前，先把这些问题回答清楚。
新增事项先归类
判断它属于首期、后置项、外部依赖还是未知问题。
变化同时写影响
记录对费用、排期、验收和已有设计的连锁影响。
关键结论有人确认
业务范围由能够承担结果的人确认，不用会议默认代替决定。
WORKED EXAMPLE / 填写示例
以预约派单首期为例， 边界账本会怎样写
目标是让客服、师傅和管理人员围绕同一张工单协作。
预约建单、人工派单、到场留痕、异常退回与完工确认。
智能排班、复杂绩效和多品牌结算，先进入后置清单。
短信签名、地图账号和历史客户数据由指定负责人提供。
跨区域改派规则在原型评审前由业务负责人确认。
- 01首次沟通建立四类条目
- 02原型评审补充验收依据
- 03每次变更同步记录影响与确认人
BOUNDARY / 项目说明
账本解决范围追踪问题， 不替代合同与正式变更确认。
FAQ / 常见问题
边界账本怎样开始使用
01
需求还不完整，可以先建账本吗？
可以。先写已知的业务结果和首期主流程，未知内容明确标注负责人和确认日期，不必假装已经确定。
02
账本多久更新一次？
每次范围评审、原型确认或变更讨论后更新；没有变化时不需要为了形式重复维护。
NEXT / 继续了解
从相关服务、案例或资料继续判断。
PROJECT CONTEXT / 项目沟通
问题已明确，直接讨论首期范围。
不用先整理完整需求文档，说明当前做法、使用角色、预算与首期目标即可。