01 项目群里翻一翻，同一件事被问过几次
打开项目群，往上翻两个月，搜一个词，比如「首页」。
看同一件事被问过几次。
我们服务过的一个客户，改版群里一共有 4 个人。翻记录发现，「首页放几张产品图」这一件事被问了 3 遍，每次答复都不一样。
这不是谁不负责。
是没有人被指定为那个说了算的人。
项目后来拖了 5 个多月，真正写代码的时间加起来不到 3 周。客户在谷歌上搜自己的产品词，看到的还是半年前那个版本。
02 把拖期算到建站公司头上，多半算错了
项目拖了，头一个反应是建站公司不靠谱。
这个判断有时对，有时不对。
可以换个算法。把项目周期拆成两段：一段是建站方在干活，一段是双方在等。
我们复盘过 30 个拖期项目，等的那一段占了整个周期的一半以上。
等什么？等甲方回话。
等一句「这样可以」，等一个「素材什么时候给」，等一个「到底用蓝色还是绿色」。
谷歌收录一个改版后的页面只要几天，但一个首页定不下来的时候可以卡 3 周。这两件事的时间尺度不在一个量级上。
03 一个能当场量的数：等待天数
判据可以量出来，不用凭感觉，也不用去看谷歌的收录数据。
在排期表里给每个环节标上两种状态：进行中、等待确认。跑完一整轮，数等待确认一共占了多少天。
我们看过 30 个拖期项目，等待确认占总周期的比例中位数在 55% 上下。
这个比例低于 25% 的项目，基本都能按期上线。
数字摆出来，讨论的方向就变了。争论的不再是谁更专业，而是等的时间花在了哪里。
用 Excel 记就够。一行一个环节，字段包括开始日、交付日、等待天数。
04 谁拍板：一个名字，不是一群人
头一件事是定一个拍板人。
拍板人的职责不是提需求，是在两种方案里选一个，然后签字。
常见的错误做法是在群里问「大家觉得怎么样」。4 个人给出 4 个意见，其中 2 个互相冲突，事情就停在那里。
可行的做法是：需求由多人提，决策由一人做。老板、业务、运营都可以提，但都写到同一张表上，由拍板人圈出这一版做什么。
拍板人不必是老板。选那个每天都会看项目进度、并且能代表公司答应事情的人更合适。
如果老板本人既想拍板又没时间看进度，可以把权限下放给一个业务负责人，同时给一条线：5000 元以内的调整不必上报。
有这条线之后，很多小事当天就能定，页面定稿平均能早 2 周，谷歌重新抓取的时间点也跟着提前。
05 需求汇总：一张表，一个入口
第二件事是把需求收进一张表。
不要在三个地方同时收需求：群里说一句、邮件里写一段、当面又提一条。这三条凑到一起一定会打架。
做法是定一个入口。用 Excel 或 Google Sheets 建一张需求表，字段包括提出人、页面、改动内容、优先级、状态。
每提一条就写一行，凑够 5 行再一起发给建站方。
建站方收到的是清单，不是零散消息，能按优先级排期；你这边也能看到这一周提了多少条，改了哪几条。
结构复杂一点的改版，先用 XMind 画一遍页面树，再往需求表里填。画图的过程本身就能发现哪些栏目是重复的。
06 改稿轮次：我们统计过 30 个项目，扯皮都发生在第二轮之后
第三件事是改稿轮次。
我们统计过 30 个改版项目，把「改稿」这件事单独拎出来看。
约定含 2 轮改稿的项目，平均在第 2.3 轮结束设计确认，全程没有出现过一次扯皮。
约定「不限次数修改」的项目，平均走到第 5 轮以上，其中一半在第 3 轮之后就偏离了原来的需求。
原因不难理解。没有边界的修改，会让每次评审都变成重新提需求，改到后面谁也不记得当初定的是什么。
可以写清两条。一条是每个页面含 2 轮改稿，第 3 轮起按工作量单独计费。另一条是区分修改和变更：改文案、改配图算修改，加一个栏目、换一套业务流程算变更，变更另外报价。
改完之后用 Google Search Console 提交一次，看更新有没有被抓到，这一步顺手就做了。
07 顺序：先定人，再定表，收尾定规则
这几件事有先后。
先定拍板人。这是必须当面或开会定下来的那一件事，10 分钟能完。
再定需求表。表建好之后，所有需求都走这一个入口。
然后定改稿轮次和变更边界，写进合同附件。
收尾才是定验收签字人。
顺序反了会怎样？先谈验收标准，双方对着一份还没写的页面清单争论，争论本身就能耗掉 1 个月。
还有一条要加进排期表：每周固定碰一次头，15 分钟就够。时间短，但能把等待天数压下来。碰完顺手看一眼谷歌上有没有新的竞品站出现，注意力不容易跑偏。
08 哪几类项目不必设专职对接人
反过来讲，不是每个项目都需要一个专职对接人。
预算 1 万元以内、页面不超过 8 个的小项目，拍板人和对接人可以是同一个人，需求表也能省掉，一封邮件写清要做什么就够。
只做技术优化的项目，比如速度调整、结构化数据补充，需求本身就窄，甲方确认的点只有 2 个，其中一个是看谷歌收录有没有掉。
还有一种可以简化：公司里只有一个业务负责人会用这个网站的项目，决策链天然只有一环，别硬塞流程。
判断依据是参与决策的人数，不是项目预算。3 个人以上提需求的，就该有那张表。
09 两个容易漏的细节
一个是需求的撤回。提了 10 条，建站方做完了，甲方又说其中 3 条不要了。需求表里要留一个状态栏，撤回的条目别删掉，标成撤回，方便对账。
另一个是素材的提供时间。文案、图片、产品参数由谁提供、什么时候给，常常没人写。我们的经验是把素材交付日排在设计评审之前，不然设计稿会因为没有真实素材而反复改。上线之后用 Chrome 看一眼最终页面，或者用 PageSpeed 测一遍，确认没有因为图片过大而变慢。
10 常见问题
Q1：拍板人会不会变成背锅的？
A：会，所以规则要写清。拍板人只对「这一版做什么」负责，不对项目结果好坏负责。责任说不清，是很多人不愿接这个角色的原因。
Q2：需求表要写到多细？
A：一行一条，写到建站方能照着报价的程度。太细的表没人维护，太粗的表等于没写。
Q3：改到第二轮发现最初的需求错了，怎么办？
A：第 3 轮之后的部分按变更走，另外报价。同时把需求表拉出来对一遍，看是哪一步漏了确认。
Q4：小项目也要每周碰头吗？
A：不用。总周期在 4 周以内的项目，每周发一封进度邮件就够。碰头的意义在于压缩等待天数，等待本来就少的时候不必加会。项目上线后放一个 GA4 的查看权限给对接人，自然流量掉没掉一眼能看到。
11 关于作者与参考来源
张凯文，山东支点网络科技有限公司，长期做外贸网站建设与谷歌 SEO。
官网建设上有拿不准的地方，可以在站内联系我们。
Google Search Central：创建有帮助、可靠、以人为本的内容（developers.google.com/search/docs）
Google Analytics 4 官方文档：转化路径与行为报告（support.google.com/analytics）
百度统计官方帮助：访客与流量来源报告（tongji.baidu.com）