排期不是画一张表那么简单
很多企业拿到网站建设需求后，第一反应是问“多久能上线”。但作为干了十年的项目经理，我通常先反问一句：“您想清楚要做什么了吗？”因为网站建设的工期，从来不是从签合同那天算起，而是从需求明确那天才算数。排期表如果只是把“设计、开发、测试”几个词填进日历里，那叫应付，不叫排期。
第一步：先把“范围”钉死，再谈时间
排期最大的坑，不是时间不够，而是范围失控。我见过太多项目，页面数量从最初报的10个，做到中途变成25个；功能从“展示型官网”变成“带会员系统+在线支付”。所以排期表的第一栏，一定是《需求确认书》的签字日期。没有这个日期，后面所有节点都是空中楼阁。
具体操作上，我会把需求拆成三级：
- 必须做：没有这个功能网站就立不住，比如企业介绍、产品展示、联系方式。
- 应该做：提升体验但非致命，比如站内搜索、表单提交。
- 可以不做：锦上添花，比如多语言版本、在线客服弹窗。
排期表里只给“必须做”和“应该做”分配硬性时间，“可以不做”的部分单独列一栏，标注“视进度决定是否纳入”。这样即使客户临时加需求，你也能拿出排期表说：“加这个，上线时间推迟两周，您确认吗？”
第二步：按“交付物”倒排，不是按“天数”正排
新手排期喜欢从第1天开始往后数，比如“第1-3天首页设计，第4-6天内页设计”。但老手会反过来，先定上线日，再倒推每个环节的截止日。因为上线日往往受域名备案、服务器部署、客户验收等外部因素制约，这些不可控，必须留足缓冲。
我的标准倒排逻辑是这样的：
- 上线日（T日）：预留2天给服务器部署和最终测试。
- T-3天：客户验收完成，所有修改意见反馈完毕。
- T-7天：全部页面开发完成，进入内部测试。
- T-12天：设计稿全部定稿，前端开始切图。
- T-15天：需求确认书签字，文案资料收齐。
这里有个关键点：文案资料如果客户迟迟不给，千万不要干等。排期表上要写“资料提供截止日”，并备注“逾期未提供，工期顺延”。这不是推卸责任，而是让客户明白，网站建设是协作项目，不是单方面交付。
第三步：给“沟通”和“修改”单独留时间
很多排期表只写“设计5天”“开发10天”，但实际执行中，最耗时的往往是“等客户回复”和“改稿”。我通常会在每个大阶段之间插入“缓冲日”：
- 首页设计完成后，留1天等客户反馈，不排新任务。
- 整体开发完成后，留2天做跨浏览器测试和细节打磨。
- 上线前留1天做备份和应急回滚方案。
这些缓冲日不是浪费，而是给突发情况留的呼吸空间。比如客户突然说“logo要换”，或者服务器商那边备案审核延迟了，你至少不用把所有环节都推倒重来。
第四步：用“里程碑”管理，别用“每日任务”管理
给客户看的排期表，越粗越好，只写四个里程碑：需求确认、首页设计定稿、全站开发完成、上线。但内部执行表，越细越好，要精确到每个页面、每个接口的完成时间。对外粗，是为了减少客户焦虑；对内细，是为了自己心里有数。
我习惯做双版本排期：一份是给客户看的“简化甘特图”，用颜色区分阶段；另一份是内部用的“任务分解表”，每项任务后面跟着负责人、预计工时、依赖关系。比如“产品列表页开发”依赖“产品数据库字段确认”，而后者又依赖客户提供的产品参数表。这样一旦延期，我能立刻定位是哪个环节卡住了。
第五步：排期表要写“风险预案”
十年经验告诉我，最靠谱的排期表，末尾一定有一页“风险登记册”。常见风险包括：
- 客户方负责人出差，审批流程停滞——预案：提前一周预约评审会议。
- 设计风格被否，需要重做——预案：在排期表里预留“第二版设计”的1/3时间。
- 第三方接口（如支付、地图）审核周期长——预案：开发前先申请测试账号。
把这些写进排期表，不是诅咒项目出问题，而是让客户看到你的专业度。当客户问“为什么这里留了3天空档”，你可以解释“这是给接口联调预留的，如果顺利，我们提前上线”。
最后说两句实在话
排期表不是合同附件，而是沟通工具。它最大的价值不是“准时”，而是“透明”。让客户随时知道项目走到哪一步，下一步需要他做什么。如果一份排期表能让客户主动配合你的节奏，那它就已经成功了一半。至于剩下那一半，靠的是你每天更新进度、提前预警问题的执行力。记住，排期表是死的，人是活的——但前提是，你得先有一张“活”的排期表。