上周帮朋友的小工作室看他们做的记账小程序，发现一个挺典型的场景：功能做了一半，老板说‘下周五上线’，开发却卡在登录页改了三版，测试还没开始。最后硬着头皮发版，结果安卓端闪退、iOS 日期显示错乱——不是技术不行，是排期没理清楚。
排期不是列个倒计时
很多人一说‘版本迭代排期’，就打开 Excel 拉一条甘特图，从需求评审填到上线日期，中间塞满‘开发中’‘联调中’‘等设计稿’……看起来密密麻麻，实际一碰就散。真正管用的排期，得先回答三个问题：
- 这次迭代到底要解决谁的什么具体问题？（比如：老用户投诉导出报表总卡住，不是‘优化性能’这种虚话）
- 哪些功能必须一起上线才能用？哪些可以灰度、可以砍掉也不影响主流程？
- 团队手头真正在干活的人，每天能稳定输出多少有效工时？（别算‘8小时’，算‘能写代码的4.5小时’）
试试这个轻量排期法
不用学 Scrum 全套，小团队直接用‘三栏纸片法’：
拿一张A4纸横着画三栏，标题分别是【待确认】【本周可推】和【已锁定】。
每项需求写在便利贴上，贴进【待确认】栏。每周一上午15分钟站会：所有人围过来，只问两句话——
‘这功能上线后，用户第一眼能看到变化吗？’
‘如果今天砍掉它，主流程还能跑通吗？’
能答‘是’且不破坏主链路的，挪到【本周可推】；需要依赖其他模块或资源未到位的，留在【待确认】；已经过测试、UI定稿、运营文案齐备的，才放进【已锁定】——这一栏里的内容，才是你敢跟老板说‘周五发版’的底气。
留点‘呼吸缝’比填满更重要
我们给一个5人小队排两周迭代，常会故意空出1.5天不安排任务。不是偷懒，是留给三件事：
- 联调时突然发现安卓和iOS时间戳解析不一致（真实发生过）
- 测试提了个高优Bug，但复现路径绕得像迷宫
- 运营临时加了个分享弹窗，要求今晚配好素材
这些事不会出现在需求文档里，但一定会出现在发版前72小时。空出来的半天，就是用来‘兜底’的缓冲带。
附：一个真实排期片段（简化版）
迭代目标：解决导出超时 & 支持微信分享
【已锁定】
- 导出逻辑重构（含后台分片+前端进度条）
- 微信SDK接入 + 分享卡片模板
【本周可推】
- 历史数据兼容处理（若时间富余则做）
【待确认】
- 新增‘导出记录’页面（需等设计终稿）最后提醒一句：排期表不是用来考核人的考勤表，而是团队共同盯住的路线图。哪天发现连续三次都得把【本周可推】里的东西拖到下周——别急着加班，回头看看是不是需求入口太松、还是测试环节卡得太死。节奏稳了，版本自然顺。