企业官网建设流程全解析

FDE岗位实务指南 · 第24篇

澄川制造的资料核验项目进入收尾，FDE 按 F3 服务范围研究里的交付物登记表把七项交付一一备齐：问题与范围记录、数据说明、应用版本、评测记录、操作说明、运行手册、价值报告。文档发出去的那天，他在交付清单上勾掉了最后一栏，感觉这个项目可以画句号了。

三天后，接手的运行专员打来电话：核验任务显示"结果待查"，这个状态以前没见过，是重新发起一次，还是等等？说明里没写。FDE 口头讲了五分钟——去执行记录里按业务请求标识查一下，如果已经成功就直接取结果，查不到就找运行负责人。专员听懂了，事情过去了。

挂掉电话，FDE 在自己的记录本上写下一行字：交接还没完成。文档发出去了，但"结果待查"这个状态怎么办，只存在于他的脑子里。这篇文章讨论的就是这件事：怎样判断你写的说明真的够别人接手，而不是只在文件层面完成了一次转移。

一、文档发出以后，为什么仍然离不开作者

"文档发出即交接完成"，是交付里最常见的一个错觉。它错在把信息转移和能力的转移混为一谈：文档转移的是作者已知并且记得写下来的部分；接手方需要的，是完成任务的全部——包括作者知道但没意识到需要写的部分。

这部分内容有个专门的名字：隐性知识。哪类任务容易卡住、某个报错最常见的原因是什么、哪一步可以跳过而哪一步绝对不能——这些东西作者天天在做所以觉得不值一提，接收者却是第一次遇到。写说明时的最大盲区，恰恰是作者最熟练的那些环节。

第二个原因是文档写作者的视角错位。多数技术说明按系统结构组织：这是登录页，这是任务列表，这是核验详情页。这种写法对作者自然，因为系统就是他搭的；对接收者却是错的，因为接收者不是要"了解系统"，是要"完成任务"。BABOK 里有一条沟通原则讲的就是这个：应根据每个相关方的角色提交适当广度与详细程度的信息，而不是向所有人提交相同的信息。接收者需要的文档组织方式，是他会在真实工作里遇到的顺序：正常的一天怎么走，遇到异常怎么办，办不了找谁。

第三个原因最诚实：有些知识确实写不进文档，只能在处理真实问题的过程里显现。这决定了交接的验证方式不能只看文档——后面第五节展开。

文档截图是这类错觉的重灾区。说明里嵌着二十张界面截图，看着详尽，实际是定时炸弹：系统一升级，截图和界面对不上，接收者按图找不到按钮，反而比没有图更慌。截图能少用就少用，必须用的地方配文字描述"这一步在哪个区域、找什么字样"，让文字扛主要信息，图只做辅助。

判断交接是否真的完成，有一个朴素的标准可以自问：从明天起我休假两周，手机关机，这个系统会不会出事？如果答案里出现"应该不会"，交接就没完成。"应该"这两个字，就是隐性知识还没交出去的部分。

二、围绕接收者的实际任务写说明

重写澄川的操作说明，起点不是打开旧文档改，是列一张接收者任务清单。

运行专员接手后要承担哪些任务？至少四类：日常查看核验任务列表并处理新任务；处理"结果待查"等异常状态；每周导出运行数据给业务主管；遇到解释不了的情况向上求助。这四类任务对应的说明深度完全不同：

• 第一类是高频低险，写清楚入口和步骤即可；

• 第二类是低频高险，是说明的重点；

• 第三类涉及口径，要写清导出条件避免数字歧义；

• 第四类看似不用写，恰恰最要写——求助有路径，才不会变成"出了事直接找原作者"。

任务清单怎么来？不是 FDE 想象，是照着第 19 篇的运行条件表翻译：运行条件表里写了谁值守、看什么指标、异常谁处理，那些"谁"就是接收者，那些事项就是任务清单。运行手册和交接说明其实是同一份工作的两个视图：一个是系统的运行视角，一个是人的任务视角。

有了任务清单，说明按"一条任务一份指引"来组织。每份指引控制在接收者一次能读完的长度，结构固定三段：这个任务为什么存在（它防止什么、产出什么）、正常怎么做（含入口和身份）、做不了怎么办。 BABOK 的抽象程度概念在这里很实用：对高频任务，说明可以细到每个按钮；对异常任务，说明要细到"看到什么现象、先查什么、依据什么判断、然后做什么"。

写每份指引前过两个问题。

第一问：接收者拿着这份指引，需要的背景知识我写全了吗？检验办法是假想一个完全没参加过这个项目的人来读——他读不懂的地方，就是默认了背景的地方。

第二问：这份指引里的每个名词，接收者的世界里叫这个名字吗？工程师写"提交核验请求"，业务嘴里说"发核验"，同一样东西两个名字，说明就成了需要翻译的外语。术语表放在说明第一页，不是装饰。

说明的组织方式变了，厚薄分布也跟着变。按系统结构写的文档每章均衡；按任务写的指引应该头轻脚重——日常任务的指引薄，异常和维护的指引厚。一份异常部分比操作部分还厚的交接说明，不是写得啰嗦，是写得诚实。

环境信息单独立一页：实际环境的入口地址、用什么身份登录、版本号、依赖的外部系统（采购系统接口、数据源）。这页看似琐碎，价值在于它是全部指引的公用地基——入口变了只改这一页，不用逐篇翻修。也要注意保密边界：入口和身份信息按第 17 篇的权限原则按需提供，访问凭据绝不写进任何会被转发出去的说明文档。

三、把正常、异常和恢复都走一遍

说明写完，作者自己先走一遍，这是第一道检验。但作者走自己的说明，永远走不出自己的盲区——他知道全部背景，任何模糊的表述他都能自动补全。真正的检验是第二道：教学交接演练，让接收者在作者不代操作的前提下，把三类场景各走一遍。

第一遍走正常流程。接收者领一个真实任务，从登录到完成全程自己来，作者只在旁边记录他在哪里停顿、翻回说明哪一段、问了一句什么。停顿点就是说明的缺口。澄川的演练里，专员在"导出周数据"这一步停了很久——说明里写了导出按钮的位置，没写默认时间范围是本周还是最近七天，这个口径差别让专员不敢确认数字对不对。

第二遍走异常。这是演练的核心，也是澄川电话那通问题的正式补课。接收者面对"结果待查"状态，说明里那条异常指引这样写：

状态"结果待查"：先按业务请求标识查询执行记录。若记录显示已成功，直接取既有结果使用，不要重新发起；若记录显示未知结果或查询不到，交给当值运行负责人按运行手册第 3 节处置，不要自行重试；处置完成后在任务备注里记录现象和动作。

这三句话的每一段都对应一个曾经的坑。"不要重新发起"对应第 18 篇的教训——超时之后盲目重试，可能造成重复的外部动作；"交给当值运行负责人"对应反例"联系开发"——如果指引只写"联系开发"，接收者既不知道找谁，也会把问题默认塞回原作者。

"记录现象和动作"对应第 16 篇：异常记录是下一次排障的证据。一条合格的异常指引，应让接收者在紧张的三分钟里依次知道查什么、找谁、不能做什么，而不是先理解系统原理。

第三遍走恢复。作者报一个预设的故障（比如"上周的核验任务全部显示失败"），让接收者按运行手册走回退或修复，验证恢复路径真的能被一个非作者的人执行。F3 研究里的交接演练标准说得很硬：由运行人员完成查看失败任务、定位数据问题、暂停异常流程和恢复上一版本，若只能由原开发者排障，说明交接尚未完成。

演练的安排有两个实务细节。一是别在交付当天演练：接收者刚拿到材料就被考，考砸的多半是紧张而不是说明缺口；给两三天消化期，演练结果才反映说明的真实水平。二是缺口当场记，不当场修：作者看到接收者卡住，本能是立刻讲解——一讲解，缺口就被"讲明白了"这个动作盖住，说明本身还是没改。记下来，回去改文档，第二轮演练看的是文档不是作者。

三遍走完，缺口清单出来，说明补一轮，演练再走一遍。澄川的第二轮演练里，专员处理"结果待查"用时从第一轮的求助电话变成了四分钟的独立操作——这个用时变化本身，就是交接质量的量化证据。

四、补齐版本、依赖与维护责任

任务层面的说明之外，还有一层交接常被漏掉：这个系统以后怎么办。

版本：当前运行的版本号、这一版包含哪些行为、历史版本存放在哪。没有版本信息的说明，半年后接手的人连自己面对的是哪个系统都说不清。

依赖：系统依赖哪些外部条件——采购接口的地址和约定、数据源的刷新时间、运行所需的环境配置。依赖要写到"如果它停了会怎样"的程度：数据源晚两小时刷新，核验任务会怎样？这个问题的答案接收者应该能从说明里查到。

维护责任：这是交接里最容易被"默认"毁掉的一项。核验规则以后要改，找谁？接口方变更，谁去谈？判据要按第 15 篇的方法迭代，谁负责？这些问题的答案不能是"找原作者"——交接的定义就是这些责任换人。

澄川的说明里落了一张维护责任表：规则变更归业务主管确认、接口对接归系统负责人、日常值守归运行专员、判据迭代每季度评审一次。维护责任表还有一行容易被漏：责任人变动时怎么办。表里写着"接口对接归系统负责人"，半年后这位负责人调岗了，表没人更新，责任落空——交接完成的那天，就是这张表开始过期的那天。对策是在表的末尾加一条元规则：负责人变更时，交接双方按本文同样的方式做一次小规模操作演练，并更新此表。让规则自己带着维护机制。

第 19 篇组织分工里那句提醒在这里再次应验：一个逻辑能力没有 owner，就会逐渐过期。

还有一项容易被忽略的交付：已知问题清单。系统当前有什么已知缺陷、什么情况下会触发、有什么临时绕行办法。把已知问题诚实列出，接收者遇到时就不是事故而是预期；藏着不说，接收者会在同一个坑里再摔一次，而且摔得更慌——因为他以为是自己操作错了。

五、用独立操作验收交接

所有材料齐备之后，验收标准只剩一条：接收者能不能在受限范围内独立操作。

"受限范围"要事先定义：哪些任务接收者必须能独立完成（澄川：日常处理、异常处置、数据导出、按手册恢复），哪些超出范围可以求助（新需求评估、规则变更——那是维护责任表里别人的职责）。范围划清，验收才有边界，不至于演变成"什么都得会"的无限考试。

验收的方法就是第三节的演练，加上一个变化：作者不在场。接收者独立处理一个预设的正常任务和一个预设异常，全程录像或留操作记录，事后对照检查清单复盘。F1 组织研究里那条阶段三的标准在这里收口：交接采用实际操作验证，仅提交培训录像不足以证明已经接手——录像证明的是"播放"发生了，不是"接收"发生了。

验收通过后，建议再留一个观察期：一到两周内，接收者遇到问题可以求助，但每个求助都要记录——不是考核他，是继续收集说明缺口。观察期结束时数一下求助次数和类型：如果求助集中在同一类问题，说明那一节的说明还是没写透；如果求助五花八门，说明验收演练覆盖的场景太窄。这份观察期数据，是下一次交接的输入。

验收通过后留三样东西：接收者签字的交接确认（含日期和范围）、演练记录（含两轮用时对比）、遗留问题清单（谁跟、何时清零）。这三样进项目档案，和第 19 篇的运行说明、第 22 篇的决定记录、第 23 篇的变更卡放在一起。档案齐了，FDE 才算真的可以从这个项目上挪开视线——不是不留恋，是不再被需要。

回头看这篇的路：列接收者任务清单，按任务而非按系统写说明，异常指引写到"紧张三分钟可照做"，补齐版本依赖和责任，最后用一次不代操作的演练收口。全部动作围绕一个判断标准：接收者能独立完成任务、独立处理一个异常。页数、发送记录、签收单，都只是这件事的影子。

迁移练习留给你：检查你手边任何一份系统说明，找到"异常怎么办"那一节——如果没有这一节，说明的作者还没准备好离开；如果有，看它写的是"联系开发"还是具名的接手人。然后问最后一个问题：写这份说明的人休假两周，你敢不敢替他值班。

下一篇把视角拉高一层：一个项目做完了，哪些经验应该沉淀成组织可以复用的能力，哪些应该诚实地留在原地——这是 FDE 的产品判断。