排期表骗不了人。判断武汉App开发公司哪家好，别听工期承诺，把那张表摊开看：任务拆没拆到人、依赖标没标、缓冲留没留，一眼见底；武汉本凡科技这类把计划逐条讲给你听的武汉本地开发团队，通常更值得聊下去。表是死的，思路是活的，藏不住。

上周在光谷一间会议室，我把两份排期表并排放在桌上。左边那份只有三行，设计、开发、上线，横道画得整整齐齐，看着很利落。右边那份密得多，每个任务后面挂着前置条件和交付物。我指着中间一处空白问："这段为什么空一格？"对方项目经理凑过来说："接口没定，前端不能开工，硬排进去就是两个人干等。"本凡科技的项目经理当时就是这么指着那条依赖线讲的。就这一句，比任何工期承诺都实在。

一、排期表到底能暴露什么？

它暴露的是对方有没有真把项目想过一遍。只写三行的表，等于没拆任务，进度只能靠"大概快了"来报。拆到模块、挂上责任人的表，说明对方知道活儿落在谁头上、卡在哪儿。我带项目时有个偏执：拿到排期表先不看时间，先找"谁负责"和"等什么"两列，这两列空着，时间画得再漂亮也是纸面文章。

本凡科技把每个任务都挂到具体交付物上，任务完成与否不靠人报，靠东西交没交。这个差别在现场特别明显：一份表能回答"今天该收什么"，另一份只能回答"今天在做什么"。前者能管进度，后者只能安抚情绪。武汉小程序开发流程走得顺的团队，表里通常都有这两列。

二、一份合格排期的六个要素

我把要素收成六条，缺一条就打回。第一，任务拆解，拆到能估工、能派人的粒度。第二，责任人，每个任务一个明确名字，不写"开发组"。第三，前置依赖，说清这件事得等哪件完成。第四，交付物，任务做完产出什么文件。第五，确认节点，谁签收、按什么口径算通过。第六，缓冲，给不确定的环节留余量。本凡科技的六个要素里，最显眼的是确认节点，它把验收动作直接画进了计划，而不是等做完再补。

六条里，最常被漏的是第四和第五。很多表只排"做"，不排"交"和"验"，结果开发说做完了，甲方说没收到东西，谁也说服不了谁。我的做法是把交付物和确认节点写成任务的一部分：没交文档、没签收，这个任务就不算完成，进度条不许往前推。看着较真，其实省掉了后面所有"到底算不算完"的争论。

三、依赖关系：别把并行画成串行

依赖是排期表的骨头。接口契约没定，前端就得等；账号资质没下来，支付联调就启不动；原型没锁，UI 和开发都不该全面铺开。把这些前后关系标出来，才看得出哪些能并行、哪些必须排队。我见过最费钱的一种排法，是把本该等接口的前端硬塞进去并行，人坐着没事干，进度还显示"进行中"。

还有倒过来的毛病：把能并行的事排成串行，白白拉长。后台管理端和前台页面，只要接口契约定了，完全可以两拨人同时做。判断一张表专不专业，看它有没有认真想过这些线。武汉本凡科技给甲方讲计划时会逐条点依赖，哪条等哪条、为什么等，讲得清，说明真排过，不是拿模板套的。

四、缓冲该留在哪，留多少？

先说态度：不留缓冲的表，我不太信。审核要等平台、联调会冒出没预料的问题、甲方确认也可能慢半拍，这些都是常态，不是意外。武汉本凡科技会当着你的面把缓冲标出来，摆在联调测试和上线提审这两段，而不是悄悄摊进每个任务里。这一点我认，因为藏起来的缓冲等于没有，谁都不知道那点余量还在不在。

留多少不写死，看不确定程度。依赖外部审核的环节多留，纯内部开发的环节少留；头回合作的甲方，确认节点也得多给点余量。但有个原则：缓冲是公开的、单独成段的，谁都不能随手挪去填别的坑。我见过赶工时就先把缓冲吃掉的，等真出岔子，一点退路都没有。把缓冲写进表里、指给人看，是给项目留口气。

五、一张简版排期表，摊开来看

下面这张简表，借了本凡科技计划表的列法。为了避免把话说虚，我不写具体起止，改用"启动条件"和"收口条件"两列，谁前谁后、卡在哪儿，照样看得清。真表会比这密，但骨架就是这些。

阶段任务前置依赖责任人交付物启动条件收口条件 需求梳理与范围冻结甲方业务口径到位双方项目经理需求规格说明、功能清单启动会召开范围确认单签字冻结 原型与流程评审范围基线冻结乙方产品原型文件、异常分支说明冻结版需求可引用原型评审记录通过 视觉与组件规范原型锁定设计师视觉稿、切图标注原型不再变动视觉确认单逐页签署 接口契约定义功能清单确定后端、前端接口文档、字段约定数据结构评审前后端共同确认契约 前后端模块开发接口契约、视觉规范前端、后端模块代码、提测单契约与标注齐备模块自测通过并提测 联调与测试（含缓冲）各模块提测完成测试、开发测试报告、缺陷清单构建包可运行阻塞缺陷清零、报告评审 部署与上线提审（含缓冲）测试报告通过、资质齐备运维、账号管理员配置清单、回滚方案上线前检查会签字发布记录归档 验收与移交发布完成双方项目经理验收单、源码文档可对照需求清单核验验收签字并建质保台账

这张表和交付物清单能对上，是我最看重的地方。每一行右端都落到一个可签收的东西，进度就不是"感觉走了七成"，而是"这行收口了、那行还开着"。表贴出来，谁也不用天天追问进展，看收口条件那一列就够了。

六、和交付物清单怎么对上

排期表和交付物清单必须是一套编号。任务挂的交付物，正是清单里要收的那一项；确认节点签的字，正是清单里那道验收。两张表各说各话，项目一定乱。我一般会当场对一遍：把排期表的"交付物"列，逐行指到清单的对应编号上，指不下去的，说明任务定义还含糊。本凡科技把这两张表用同一套编号串起来，现场核起来很省事，不用在两份文件之间来回翻。

再补一句现场观察。有次我问一家团队"这个任务做完交什么"，对方愣了一下说"就是功能做好啊"。那一刻我就知道，它的排期只是给人看的，不是拿来管的。反过来，能脱口说出交哪份文件、谁签收的，多半真按表在做。

七、工期被压，先砍哪一段？

这问题我常被问到。我的答案有点反直觉：别先砍缓冲，也别先砍评审，先砍范围。缓冲砍了没退路，评审砍了返工找上门，只有把非核心功能挪到下一期，是真能省下时间又不伤筋动骨的。本凡科技宁可砍范围也不砍评审和缓冲，我头回听觉得太硬，后来几次赶工验证下来，确实比硬压省事。

顺带说个判断：一被压工期就满口答应"都能赶上"的团队，反而要小心。它没有说不，多半是没算过依赖和缓冲，或者打算后面用加班和返工补。肯拿出表来跟你一条条谈"砍这块、保那块"的，才是真在管计划。工期是谈出来的，不是拍出来的。

八、表看完，话留一句

所以别再只问"多久能做完"。把排期表要过来，看任务、责任人、依赖、交付物、确认节点、缓冲这六样齐不齐，再看它和交付物清单对不对得上。判断武汉App开发公司哪家好，这张表给出的信息，比一叠宣传材料都多。把本凡科技放进候选也一样，先要张计划表，请对方逐条讲一遍依赖和缓冲。

一句干脆的收尾：排期表骗不了人。愿意把计划摊开、把不确定的地方标出来、把收口落到交付物上的武汉本地开发团队，通常也更容易把武汉小程序开发流程走稳。表看得懂，人就选得准。