企业官网建设流程全解析

拿过“title19”这种需求的人，应该都能体会坐在工位前对着任务列表发愣的感觉：孤零零一行字，没有背景文档，没有验收标准，连这个编号从哪个系统里蹦出来的都查不到。我入行这些年，接过不止一次类似的项目，早期也踩过不少坑，后来慢慢摸出一套处理空标题的固定打法。这篇文章就把它完整交代一遍，顺便拿“title19”现场做一次演示，看看怎么从一行占位符拆出需求、里程碑、验收指标这一整套东西。内容适合所有接过模糊需求的人——产品、开发、设计、内容创作，或者在学校里带小组作业，都能用上。不需要任何项目管理基础，跟着步骤走就行，模板我也放在后面，直接抄。

1. 拆字面：title19 不是没有信息，是信息被打包了

很多人拿到“title19”的第一反应是“这玩意儿没有任何信息量”。我恰恰相反，我认为一个空标题不是没有信息，而是信息被压缩了。去掉多余的情绪，先做一次字面解剖。

1.1 “title”这个前缀暴露了什么

命名是有逻辑的。一个人把某样东西命名为“title”，至少说明在他当时的语境里，这东西只需要一个占位，不需要被准确描述。“title”本身是个通用词，不指向任何业务、任何功能、任何领域。

这暴露了什么？暴露了起名的人自己也还没想清楚它具体是什么。真正成型的事项，哪怕随手命名，也会带一点业务痕迹，比如“首页改版”“报销流程优化”“Q3复盘”。而一个不带任何业务痕迹的“title”，说明需求方只是需要“有个东西先挂在这里”。

但注意，这不等于“需求方没认真”。很多空标题来自年度规划会上随口列的候选事项、任务池里批量生成的占位条目、或者某个想法刚冒头还没来得及沉淀。它们代表的不是“不重要”，而是“还没被定义”。理解这一点很重要，因为它决定了你接下来该做什么——不是急着开干，而是帮它完成定义。

1.2 “19”这个序号才是真正的线索

如果说“title”是表面信息，那“19”就是深一层的线索。正常命名习惯里，带序号只有两种常见情况，处理方式完全相反。

第一种是系列编号。“title1”到“title18”都存在，那它就属于某个序列里的第十九项，前面有大量可参照的同类项目。这时候信息量非常大：前面十八个项目的结构、格式、深度、周期、交付物，全都可以拿来当模板。

第二种是流水号。“19”只是录入顺序，跟业务内容毫无关系，后面可能跟着“title20”“title21”。这种情况下，序号本身不提供任何业务信息，但同样有意义——它说明这个项目在某个清单里占据固定位置，你至少能推断出，它是被某个人、在某个时间点、以某种批量方式登记进来的。

所以拆解“19”的正确动作，是去查“这个编号体系在哪”。找到编号体系，就能顺藤摸瓜找到兄弟项目、历史文档、甚至当初立项时的会议纪要。我见过很多人拿到带序号的标题直接开工，做完才发现方向完全跑偏，其实多花十分钟查一下编号来源就能避免。

1.3 开工前10分钟必做的三件事

不管“title19”最终会拆成什么，我建议你开工前先花10分钟做三件事。这三件事成本极低，但能避免大部分返工。

第一，记录上下文。把任务来源、接收时间、附带文档、通知你的人，全部记下来。空标题项目最容易“聊过就忘”，一周后你可能完全不记得当初为什么这么理解，有记录才有追溯。

第二，翻邻居。打开同一个编号体系里“18”和“20”，看看它们是什么状态。如果“title18”已经启动且有一套完整的项目文档，那它就是你最好的模板；如果“title18”“title20”都躺了半年没动过，那你要警惕，这个项目可能同样处于“永远不会启动”的状态。

第三，问一个问题。直接找到把标题甩给你的人，问一句：“这个编号是哪来的？”别小看这一句，它往往能直接定位到某个任务池、某个规划文档、或者某场会议。问清来源，等于拿到了定义权。如果对方也说不清来源，那恭喜你，这条信息本身就是最重要的判断依据——一个连来源都说不清的项目，大概率是需求方的模糊念头，后续要用完全不同的策略。

2. 一套用了很多年的需求拆解方法：三问、假设、收敛

字面拆完，“title19”能提供的信息基本到顶了。接下来要做的，是把标题放到真实工作场景里，用一套固定方法把需求“问”出来。这套方法我用了很多年，核心就六个字：三问、假设、收敛。

2.1 定位三问：给谁用、为什么现在做、怎么算成

拿到任何一个不够清晰的项目，我都会先问三个问题。这三个问题不依赖任何背景知识，但对齐它们的答案，项目方向基本就立住了。

第一问：给谁用？用户决定了复杂度、设计语言和验收口径。给内部工具用，稳定性大于体验；给外部用户用，易用性和包装缺一不可；给自己用，那更简单，怎么顺手怎么来。很多人做模糊项目翻车，不是执行力不行，是自始至终没搞清用户是谁。

第二问：为什么是现在做？这个问题帮我理解优先级和资源。“现在做”一定有一个诱发因素：可能是某个截止日期快到了，可能是某个环节卡住了，也可能只是领导随口拍板。诱发因素决定了项目的紧急程度，也决定了方案是应该走快版本还是完整版本。

第三问：怎么做才算成？这是三个问题里最关键的。正常人聊项目只会聊“做什么”，但聊“什么算成”才能真正锁定边界。比如做一套报表系统，“做完”可以是“页面能跑”，也可以是“业务同学不再手工导数据”。两者工作量差好几倍。没有验收标准，就没有边界；没有边界，项目就会无限膨胀。

把这三问的答案写下来，如果写不满三行，那说明需求还没站住。没关系，这就是项目起点。

2.2 把猜测升级成可验证假设

三问对齐之后，接下来必然要面对一个现实：你掌握的信息仍然不够。这时候一定会有“猜测”。我不反对猜测，我反对的是“把猜测当成事实”。

猜测和假设的区别在哪？猜测是“我觉得应该是这样”，假设是“如果我真的理解对了，那么应该会发生某个可观察的结果”。举例来说，面对“title19”，你心里想“这应该是某内容系列的第19期”，这是猜测。把它升级成假设，你要说：“如果这是某内容系列的第19期，那么在项目库里应该存在前18期的记录，而且它们的格式应该高度一致。”

区别很明显：猜测不可验证，假设可以验证。验证不通过，你就知道自己的理解错了，可以马上换方向。我把这个句式称为“假设模板”：如果[背景成立]，那么[方案]应该在[时间]内满足[指标]，因为[依据]。用这个句子把所有模糊判断都过一遍，能过滤掉大量“拍脑袋”的坑。

2.3 收敛：证据、风险、成本三条标准

假设往往不止一个。拿“title19”来说，你完全可以同时假设它是内容系列、内部模块、外包任务、甚至教学案例。全保留肯定不行，得收敛。

我用的收敛标准有三条，按优先级排序。

第一条，看证据。哪个假设能最快找到实物证据？如果你翻任务池十分钟就找到了前十八期的文档，那“内容系列”这个假设证据最强，直接领先。第二条，看风险。如果某个假设猜错了，代价最小？很多项目在两个方向之间摇摆，选“即使错了损失也小”的那条路，永远不亏。第三条，看成本。哪个假设的验证成本最低？成本包括时间、人力和资源，优先选验证成本最低的，因为验证完你就有了确定性。

三条标准之外，还有一个关键动作：镜像确认。所谓镜像确认，是把你理解到的信息“反着说”给需求方听。别问“我这么理解对不对”——人都有顺着对方点头的毛病；要问“我打算这么干，因为我以为你想要的是X。如果不是，请现在告诉我”。把结论亮出来，让对方有具体的东西可以反驳，比开放式提问有效得多。

3. 现场演示：title19 是怎么变成可执行方案的

方法讲完了，拿“title19”走一遍完整流程。这里我列出最常见的三个分支，看看每个分支下具体做什么、输出什么、花多长时间。

3.1 分支一：内容系列的第19期

第一个分支，也是最友好的情况：“title19”是某内容系列里的第十九期，前十八期都真实存在。

这种情况下，前面十八个作品就是你最好的参照物。第一件事，把前十八期的标题全部拉出来，排成一张表，看它们在主题、结构、篇幅、发布节奏上的规律。比如前十八期都保持每周一篇、每篇有一个核心案例、结尾固定放一组操作清单，那“title19”就应该继承这套格式，而不是另起炉灶。

第二件事，做选题定位。系列做到第19期，说明受众已经基本固定，你要做的是在既有主题矩阵里找一块还没被覆盖的空白。把前十八期的主题画成一张二维坐标图，横轴是内容类型、纵轴是难度等级，就看哪个格子还空着。迷宫解题法，核心就是别重复自己。

第三件事，输出物固定为三样：选题大纲、关键词地图、素材清单。大纲定结构，关键词地图定内容覆盖面，素材清单定资料缺口。三者齐了，内容系列的“title19”就从一个空标题变成了一张可以立刻执行的任务卡。这整个过程，半天时间足够。

3.2 分支二：任务池里的第19个模块

第二个分支：“title19”出现在某个系统的任务池里，前面大概率还有“title1”到“title18”，它们是同一个体系下的模块或子项目。

这种分支的拆法跟内容系列不一样，重点不在“参照格式”，而在“定位上下游”。你要做的第一件事，是找到这个任务池所属的系统或项目，把它们整体画一遍。十九个模块之间的关系通常只有几种：并列、依赖、或者先后顺序。标出“title19”之前是谁、之后是谁，你的工作边界就露出来了。

第二件事，查接口和协议。模块类项目最怕信息孤岛。即使“title19”的描述栏里什么都没写，它作为系统的第十九个模块，必然要跟周围模块发生数据交换。把相邻模块的接口文档调出来，哪怕只读懂一半，“title19”到底要做什么也能猜个大概。

第三件事，输出模块需求说明书、接口清单、排期表三件套。模块需求说明书描述“它是什么”，接口清单描述“它跟谁说话”，排期表描述“什么时候做完”。到这一步，“title19”就已经具备开发条件了。说句实在话，这类分支的完成质量，取决于你愿不愿意把前十八个模块都翻一遍——翻完，思路全通；不翻，百分之百踩坑。

3.3 分支三：需求方随口提的模糊念头

第三个分支是最磨人的：“title19”问遍了所有能问的人，没人说得清编号来源，需求方自己也支支吾吾。这种情况在真实工作中出现的频率，比很多人想的高得多。

这时候切忌硬做，而是要主动约一个10分钟的短会，用第二章的三问定位法把需求方“问透”。注意，约的是“访谈”，不是“评审”。访谈的目的是让需求方把脑子里那个模糊念头讲出来，而不是让他审阅你的方案。

访谈结束之后，你要产出的不是方案，而是三样东西：问题陈述、可选项、推荐项。问题陈述用一段话讲清楚“对方到底想解决什么”；可选项给两到三个不同风格、不同规模的做法；推荐项则是你基于成本收益给出的倾向性建议。把这三样东西发给需求方，你会发现一个很有趣的现象：对方之前说不清想要什么，但当你给出选项之后，他立刻就能说“我不要这个，我要那个”。人都是先看见选项，才知道自己要什么。模糊需求的破解之道，在于你自己先把球踢出去。

3.4 十分钟判断走哪个分支

三个分支都列出来了，问题来了：真拿到“title19”，十分钟内怎么判断该走哪条？

我给一张极简判断表：

有一说一，最常见的卡点是第二个和第三个分支同时成立：有任务池，但池子里全是空壳，没人知道每个编号对应什么。遇到这种情况，我建议直接走第三个分支，因为它最快、成本最低。一个10分钟访谈，最多浪费你半小时，但能不能赌对一个方向，这半小时就是分水岭。

3.5 收敛之后的一页纸定义

假设“title19”最终被确认是某内容系列的第19期，那收敛之后的定义长什么样？我直接给你一页纸的样例，这也是我每次启动项目必写的第一份文档。

项目代号：title19
一句话定位：面向固定读者群的系列选题第19期，延续既有格式，覆盖主题矩阵空白格
目标用户：该系列已有读者，以一线从业者为主
核心场景：读者搜索某主题时，能获得一套可执行的操作清单
成功指标：发布后48小时阅读量达到前18期平均水平的80%以上；文末操作清单的收藏率不低于系列均值
范围：单篇图文内容，不做视频版，不做配套社群运营
非目标：不追热点，不改变系列固定栏目结构
里程碑：第1天定大纲，第3天交初稿，第5天完成评审，第7天发布
负责人：内容作者本人
风险：选题与第7期、第13期有重叠；已列入选题排查清单

别小看这点字数，它解决的是全项目最大的不确定性。写完之后发给需求方，对方十分钟就能确认“这就是我要的”或者“不对，我要的不是这个”。一旦确认，后面的事就是老老实实执行。

4. 空标题项目的五张工作模板，照着填就行

“title19”这种空标题项目，最大的特点不是难，而是“没抓手”。为了让自己不慌，我习惯用五张固定的纸把整个项目包住。模板都在下面，直接抄。

4.1 一页纸项目定义

第一张纸就是上一节展示的项目定义表。不要小看它，它是我所有项目的第一份交付物，甚至在需求方还没有明确反馈之前，它就已经是有效的交付了。

一页纸项目定义必须控制在两百字以内。超过两百字，说明你还没想清楚。字段固定为：项目代号、一句话定位、目标用户、核心场景、成功指标、范围、非目标、里程碑、负责人、风险。每个字段都要求“短到没法再短”，因为短的东西才容易被确认。写得越长，对方越不想看，确认效率就越低。

我见过很多人一上来写几百字的立项报告，结果需求方看完只回了一句“先做吧”。一年之后项目复盘，大家都说不清当初到底要做成什么样。一页纸的意义不在于“好看”，在于强制你用最少的文字锁死核心共识。

4.2 范围清单与排除清单

第二张纸，是范围清单和排除清单，我通常把它放在一页纸定义的正下方，一页纸搞定。

范围清单写“做什么”，排除清单写“不做什么”。很多空标题项目到头来失控，缺的不是范围清单，而是排除清单。因为“范围”是需求方主动给的，“排除”是你主动划的——划排除线这件事本身就冒着争议。

举个例子，“title19”如果被定义为内容系列的第19期，范围清单就是“写一篇图文、配三张图、包含一个操作清单”；排除清单就要写清楚“不做视频版、不做矩阵运营、不追临时热点、不修改栏目结构”。这四条排除线一划，等于提前告诉需求方：想加戏，请先来找我谈。

有了排除清单，一旦项目途中有人追加需求，你就有明确的依据去判断“这是在原范围加内容，还是新的项目”。这个判断本身，能省下后面无数加班。

4.3 里程碑绑定产出物

第三张纸是里程碑表。我对里程碑只有一个要求：必须绑定产出物，不能绑定时间感。

“第5天评审”“第7天发布”，这种写法是对的；“尽快完成”“看情况推进”，这种写法等于没写。里程碑的真正作用不是提醒你时间，而是让项目在任何一个时点上都有“可验收的中间成果”。

“title19”这种空标题项目的里程碑，我一向切成四个阶段：定义确认、初稿产出、评审修订、发布归档。每个阶段都对应一个实体文件：定义确认对应一页纸，初稿产出对应完整内容，评审修订对应修订记录，发布归档对应最终版本和发布数据。走到哪一步，拿得出哪样东西，项目进度一目了然。这样做还有一个隐藏好处：需求方随时可以进来检查，不需要你汇报。

4.4 风险登记表

第四张纸是风险登记表。做空标题项目，风险不是“会不会发生”的问题，而是“什么时候发生”的问题。我统计过自己经手的模糊需求项目，最常见的风险永远是那四个：需求方自己没想好、项目中途换对接人、范围悄悄蔓延、目标暗中漂移。

这张表不需要写得多漂亮，但必须每周看一次。空标题项目最怕的不是风险，而是风险发生了你才想起来有这回事。提前写下来，至少你在风险发生的那一刻能说出“我两周前就标过这个问题”。

4.5 复盘记录表

第五张纸是复盘记录表。项目收尾后，花半小时填完。比别人多出的半小时，是拉开差距的地方。

我的复盘表只有三行，不加戏。第一行：我做对了哪一步？第二行：我在哪一步浪费了最多时间？第三行：下一次拿到空标题，我会先做什么？

拿“title19”举例，按我的经验，做得对的一步通常是“先问编号来源，没急着动手”；浪费最多时间的一步通常是“等需求方回复，等了三天”；下一次会先做的事情，大概率是“对方没回复之前，先把假设模板填了”。三条答案加起来，就是一个人的改进清单。不要写长篇大论，写多了就懒得看，只有三行才愿意填。

5. 踩过的坑，列给你看

方法说了一堆，接下来聊点更直接的：我踩过的坑。这些坑每一个都真实付出过时间成本，写出来给你当路标。

5.1 把“没有信息”当成“没有约束”

第一个坑，是把模糊当自由。拿到“title19”这种标题，我早期会觉得“挺好，没人管我，随便发挥”。结果发挥完，需求方说“这不是我要的”。

后来我想明白一件事：信息模糊不代表约束不存在，只代表约束你还没看见。需求方心里可能早就有一条隐形的验收线，只是他没写下来，也没说出口。空标题项目最危险的地方就在这——你以为在做一张白纸创作，实际上对方脑子里有一张成图。正确心态是反向的：标题越空，越要主动问，越要把看不见的约束挖出来。自由创作是留给已定义项目的，模糊项目需要的是先定义，再创作。

5.2 第一版就追求大而全

第二个坑，是给自己加码。信息不全的时候，人的本能是用“做更多”来对冲焦虑——标题只有一个，那就把架构想全、把功能做满、把文档写厚。

这个坑我踩过不止一次，代价是前两周全在造“可能用不上”的东西。后来我给自己立了一条规矩：模糊项目的第一版交付物，永远是最小可验收单元。对“title19”，最小可验收单元就是一页纸定义；对任何项目，最小可验收单元就是“能让需求方点头说我看到的这个东西方向对了”的最小产出。方向没被确认之前，写代码、写长文、画高保真图，全都有白做的风险。

5.3 不回去确认，凭脑补推进

第三个坑，是“以为确认过了”。很多人不是没做确认，而是确认方式太软。你拿着大纲跟需求方说“您看这样行吗”，对方回了个“行”，你就以为万事大吉。等做完，对方说“我说的行是这个大纲的行，不代表内容行”。

我现在要求的确认方式是“亮观点”。不问“行不行”，而是说“我打算这么干，理由是什么，如果你心里的预期不一样，现在说”。两种问法效果天差地别：开放式确认得到的是敷衍，亮出观点的确认得到的是真正的碰撞。每次确认完，留一句文字记录，发到群里，“根据刚刚的确认，项目定义为以下内容，如有异议请明天中午前提出”。这一句话，能挡掉90%的“我没说过”。

5.4 验收时聊“功能”而不是聊“结果”

第四个坑，是验收的时候问错了话。我早期验收项目习惯问“这个功能可以吗”，需求方碍于面子通常说“可以可以”。然后就没有然后了——没有一个验收问题真正触达“这解决了你的问题吗”。

后来我把验收问题全部改成“结果导向”：你最初想解决的问题，现在解决了吗？如果用一句话总结这次交付的价值，你会说什么？下次遇到同类问题，你还愿意用这套东西吗？这类问题不好糊弄，因为回答需要真实思考。空标题项目尤其要用这种问题验收，因为它的需求从始至终都是模糊的，只有回到最初的问题上，才能检验项目到底有没有价值。

5.5 复盘时把锅全甩给标题

第五个坑，是归因错误。项目翻车了，写复盘的时候一肚子怨气，“都怪需求方只丢了个标题过来”。这句话我写过，写完第二天发现什么问题也解决不了。

空标题是客观条件，不是失败原因。真正的原因几乎永远是“我在哪一步没有追问”“我在哪一步凭感觉推进”“我在哪一步没有把结论亮出来给对方反驳”。把锅甩给标题，等于放弃复盘的意义。后来我给自己改了句话，遇到空标题项目失败，问自己：如果让我重来一次，我在拿到标题的第一天做什么，可以让后面的失败不发生？答案往往是“多问十分钟”或者“先把假设写下来”。就这十分钟，就是成长的全部。

5.6 常见问题速查表

最后贴一张速查表，给遇到具体场景的读者做即时参考。

这六条基本覆盖了空标题项目从接手到收尾的各种卡点，真正遇到时回来查就行。

最后说点个人体会。处理空标题项目多了，我反而不觉得烦了。“title19”这种标题不是需求方偷懒，它是一个模糊的想法被用最省力的方式交到了你手上，真正的定义权其实在你这边。能把一个空标题变成一页纸定义、变成里程碑、变成交付物，这是一种在混乱里建立秩序的能力，它不依赖任何天赋，只依赖一个习惯：拿到任何模糊的东西，先问，再写，别急着做。我现在手里常备一张纸，上面只有五个问题——给谁用、为什么现在做、怎么做算成、找谁确认、最迟什么时候要。每次拿到“title19”式的项目，先花十分钟过一遍。这十分钟换回来的，通常是后面几周的命。