# 项目规格写好了，这周你要完成什么？

Canonical: https://specscore.md/zh-cn/articles/weekly-delivery/

规格可以十分完整，项目却仍然停滞。需求清楚，代理有计划，待办事项还在增长。缺少的可能只是一个更小的决定：这周你到底要完成哪个有用的结果，又要停下什么，才能为它腾出时间？这套复盘可以和同事、导师一起做，也可以只用一本笔记本。

## 选择用户结果，而不是一堆任务

从一条验收标准出发，把它变成简短的演示。对于CSV导入，“实现解析器”描述的是工作；“用户能导入合法文件、查看记录，并在某行不合法时得到有用的错误提示”才是可以检查的结果。别丢掉错误路径：为了赶时间删掉它，就改变了原来的承诺。

SpecScore把需求与验收标准组织成团队和代理都能读取的文件。在每周笔记中引用这些标准即可。规格仍然定义正确行为，笔记只负责选出能够承担的一部分。你不需要再复制一份规格，也不需要新增项目管理系统。

## 按真实日程安排容量

写下实际可用的专注工作时段，包括评审和集成。两个晚上不是五个工作日。给完整用户流程的测试和一个意外问题留出时间。如果结果放不进去，就在开工前选一个更小但完整的流程。

列出你无法控制的依赖。“等待生产环境权限”需要负责人和决策时间。周三仍然没有权限时，要决定本地演示是否有价值。准确标注结果：本地演示不能证明生产环境已经就绪。不要等到周五再悄悄改写成功的定义。

## 限定代理的工作，自己承担决定

当你还在决定哪个问题重要时，代理就能生成几个实现。因此，完成更多子任务也可能没有推进最初的目标。给每项任务明确的标准、允许的范围，以及必须交回的证据。整个用户流程的验收，仍然要由一个人负责。

出现新想法时，先记下来，不要自动开工。问问它将替换当前哪个承诺。可以尝试只让一个结果等待你的最终评审。这是聚焦注意力的实验，不是放之四海而皆准的效率规则；如果证据表明它拖慢了有用的工作，就调整它。

## 先看证据，再听故事

复盘时先打开真实产物：运行中的导入功能、非法输入测试，或已经发布的文档。按用户的操作顺序走一遍，再和选定标准比较。提交数量、投入小时数、代理信心十足的总结都只是背景，不能代替验收证据。

区分已经实现、已经测试，以及用户在目标环境真正能够使用的内容。请评审者找出一种可能失败的方式。只分享对方需要的信息：合成样例或去掉敏感内容的演示通常就够了。对承诺负责，不意味着必须分享客户数据、密钥或私有代码仓库。

## 没有兑现的承诺，需要新的决定

如果演示失败，写下最简短而有用的解释：未知依赖、范围过大、工作时间被打断，或假设错误。不要把估算失误变成对自己品格的评判。选择一个明确回应：缩小下一步、解决依赖、更换方法，或者主动停止项目。

不要习惯性地把同一个承诺原封不动地顺延。约定下一个可观察的结果和复盘日期。经过几个周期后，对比估算和实际完成的内容。记录的价值在于改善决策，而不是维护一条不能中断的成功纪录。

## 可以直接复制的五行每周复盘

- 结果：到复盘日期，用户能够做什么？
- 证据：用哪条标准和哪个演示证明？
- 时间：何时实现、测试和评审？
- 限制：推迟什么，哪个依赖需要决定？
- 复盘：谁在什么时候查看结果，接下来做什么决定？

## 让你的决定多一双人的眼睛

找一个会追问发生了什么、并帮助你分析下一步选择的人，一起使用这份笔记。CommittedMe关注真人导师指导与承诺跟进。开发者和创始人页面介绍了这种方式。把规格留在代码仓库里，带来一个无需泄露保密工作就能讨论的目标。

[了解CommittedMe（英文）](https://committedme.com/en/for/builders/?utm_source=specscore&utm_medium=ecosystem_referral&utm_campaign=committedme_cross_promotion&utm_content=article_footer)

你已经在YouTube、TikTok、Instagram或博客上教开发者了吗？向别人解释取舍与测试，可能暴露你自己的假设；他们的问题能让你在帮助对方进步的同时继续学习。如果你喜欢这样的交流，可以了解导师这个角色。

[了解如何成为导师（英文）](https://committedme.com/en/become-a-mentor/?utm_source=specscore&utm_medium=ecosystem_referral&utm_campaign=committedme_cross_promotion&utm_content=article_mentor)

CommittedMe是我们生态中的另一款产品。本文介绍一种复盘方法，并不意味着它与SpecScore存在技术集成。

## 让结果可以验证

[如何编写可验证的验收标准](https://specscore.md/zh-cn/articles/acceptance-criteria/)