FDE岗位实务指南 · 第24篇澄川制造的资料核验项目进入收尾FDE 按 F3 服务范围研究里的交付物登记表把七项交付一一备齐问题与范围记录、数据说明、应用版本、评测记录、操作说明、运行手册、价值报告。文档发出去的那天他在交付清单上勾掉了最后一栏感觉这个项目可以画句号了。三天后接手的运行专员打来电话核验任务显示结果待查这个状态以前没见过是重新发起一次还是等等说明里没写。FDE 口头讲了五分钟——去执行记录里按业务请求标识查一下如果已经成功就直接取结果查不到就找运行负责人。专员听懂了事情过去了。挂掉电话FDE 在自己的记录本上写下一行字交接还没完成。文档发出去了但结果待查这个状态怎么办只存在于他的脑子里。这篇文章讨论的就是这件事怎样判断你写的说明真的够别人接手而不是只在文件层面完成了一次转移。一、文档发出以后为什么仍然离不开作者文档发出即交接完成是交付里最常见的一个错觉。它错在把信息转移和能力的转移混为一谈文档转移的是作者已知并且记得写下来的部分接手方需要的是完成任务的全部——包括作者知道但没意识到需要写的部分。这部分内容有个专门的名字隐性知识。哪类任务容易卡住、某个报错最常见的原因是什么、哪一步可以跳过而哪一步绝对不能——这些东西作者天天在做所以觉得不值一提接收者却是第一次遇到。写说明时的最大盲区恰恰是作者最熟练的那些环节。第二个原因是文档写作者的视角错位。多数技术说明按系统结构组织这是登录页这是任务列表这是核验详情页。这种写法对作者自然因为系统就是他搭的对接收者却是错的因为接收者不是要了解系统是要完成任务。BABOK 里有一条沟通原则讲的就是这个应根据每个相关方的角色提交适当广度与详细程度的信息而不是向所有人提交相同的信息。接收者需要的文档组织方式是他会在真实工作里遇到的顺序正常的一天怎么走遇到异常怎么办办不了找谁。第三个原因最诚实有些知识确实写不进文档只能在处理真实问题的过程里显现。这决定了交接的验证方式不能只看文档——后面第五节展开。文档截图是这类错觉的重灾区。说明里嵌着二十张界面截图看着详尽实际是定时炸弹系统一升级截图和界面对不上接收者按图找不到按钮反而比没有图更慌。截图能少用就少用必须用的地方配文字描述这一步在哪个区域、找什么字样让文字扛主要信息图只做辅助。判断交接是否真的完成有一个朴素的标准可以自问从明天起我休假两周手机关机这个系统会不会出事如果答案里出现应该不会交接就没完成。应该这两个字就是隐性知识还没交出去的部分。二、围绕接收者的实际任务写说明重写澄川的操作说明起点不是打开旧文档改是列一张接收者任务清单。运行专员接手后要承担哪些任务至少四类日常查看核验任务列表并处理新任务处理结果待查等异常状态每周导出运行数据给业务主管遇到解释不了的情况向上求助。这四类任务对应的说明深度完全不同第一类是高频低险写清楚入口和步骤即可第二类是低频高险是说明的重点第三类涉及口径要写清导出条件避免数字歧义第四类看似不用写恰恰最要写——求助有路径才不会变成出了事直接找原作者。任务清单怎么来不是 FDE 想象是照着第 19 篇的运行条件表翻译运行条件表里写了谁值守、看什么指标、异常谁处理那些谁就是接收者那些事项就是任务清单。运行手册和交接说明其实是同一份工作的两个视图一个是系统的运行视角一个是人的任务视角。有了任务清单说明按一条任务一份指引来组织。每份指引控制在接收者一次能读完的长度结构固定三段这个任务为什么存在它防止什么、产出什么、正常怎么做含入口和身份、做不了怎么办。 BABOK 的抽象程度概念在这里很实用对高频任务说明可以细到每个按钮对异常任务说明要细到看到什么现象、先查什么、依据什么判断、然后做什么。写每份指引前过两个问题。第一问接收者拿着这份指引需要的背景知识我写全了吗检验办法是假想一个完全没参加过这个项目的人来读——他读不懂的地方就是默认了背景的地方。第二问这份指引里的每个名词接收者的世界里叫这个名字吗工程师写提交核验请求业务嘴里说发核验同一样东西两个名字说明就成了需要翻译的外语。术语表放在说明第一页不是装饰。说明的组织方式变了厚薄分布也跟着变。按系统结构写的文档每章均衡按任务写的指引应该头轻脚重——日常任务的指引薄异常和维护的指引厚。一份异常部分比操作部分还厚的交接说明不是写得啰嗦是写得诚实。环境信息单独立一页实际环境的入口地址、用什么身份登录、版本号、依赖的外部系统采购系统接口、数据源。这页看似琐碎价值在于它是全部指引的公用地基——入口变了只改这一页不用逐篇翻修。也要注意保密边界入口和身份信息按第 17 篇的权限原则按需提供访问凭据绝不写进任何会被转发出去的说明文档。三、把正常、异常和恢复都走一遍说明写完作者自己先走一遍这是第一道检验。但作者走自己的说明永远走不出自己的盲区——他知道全部背景任何模糊的表述他都能自动补全。真正的检验是第二道教学交接演练让接收者在作者不代操作的前提下把三类场景各走一遍。第一遍走正常流程。接收者领一个真实任务从登录到完成全程自己来作者只在旁边记录他在哪里停顿、翻回说明哪一段、问了一句什么。停顿点就是说明的缺口。澄川的演练里专员在导出周数据这一步停了很久——说明里写了导出按钮的位置没写默认时间范围是本周还是最近七天这个口径差别让专员不敢确认数字对不对。第二遍走异常。这是演练的核心也是澄川电话那通问题的正式补课。接收者面对结果待查状态说明里那条异常指引这样写状态结果待查先按业务请求标识查询执行记录。若记录显示已成功直接取既有结果使用不要重新发起若记录显示未知结果或查询不到交给当值运行负责人按运行手册第 3 节处置不要自行重试处置完成后在任务备注里记录现象和动作。这三句话的每一段都对应一个曾经的坑。不要重新发起对应第 18 篇的教训——超时之后盲目重试可能造成重复的外部动作交给当值运行负责人对应反例联系开发——如果指引只写联系开发接收者既不知道找谁也会把问题默认塞回原作者。记录现象和动作对应第 16 篇异常记录是下一次排障的证据。一条合格的异常指引应让接收者在紧张的三分钟里依次知道查什么、找谁、不能做什么而不是先理解系统原理。第三遍走恢复。作者报一个预设的故障比如上周的核验任务全部显示失败让接收者按运行手册走回退或修复验证恢复路径真的能被一个非作者的人执行。F3 研究里的交接演练标准说得很硬由运行人员完成查看失败任务、定位数据问题、暂停异常流程和恢复上一版本若只能由原开发者排障说明交接尚未完成。演练的安排有两个实务细节。一是别在交付当天演练接收者刚拿到材料就被考考砸的多半是紧张而不是说明缺口给两三天消化期演练结果才反映说明的真实水平。二是缺口当场记不当场修作者看到接收者卡住本能是立刻讲解——一讲解缺口就被讲明白了这个动作盖住说明本身还是没改。记下来回去改文档第二轮演练看的是文档不是作者。三遍走完缺口清单出来说明补一轮演练再走一遍。澄川的第二轮演练里专员处理结果待查用时从第一轮的求助电话变成了四分钟的独立操作——这个用时变化本身就是交接质量的量化证据。四、补齐版本、依赖与维护责任任务层面的说明之外还有一层交接常被漏掉这个系统以后怎么办。版本当前运行的版本号、这一版包含哪些行为、历史版本存放在哪。没有版本信息的说明半年后接手的人连自己面对的是哪个系统都说不清。依赖系统依赖哪些外部条件——采购接口的地址和约定、数据源的刷新时间、运行所需的环境配置。依赖要写到如果它停了会怎样的程度数据源晚两小时刷新核验任务会怎样这个问题的答案接收者应该能从说明里查到。维护责任这是交接里最容易被默认毁掉的一项。核验规则以后要改找谁接口方变更谁去谈判据要按第 15 篇的方法迭代谁负责这些问题的答案不能是找原作者——交接的定义就是这些责任换人。澄川的说明里落了一张维护责任表规则变更归业务主管确认、接口对接归系统负责人、日常值守归运行专员、判据迭代每季度评审一次。维护责任表还有一行容易被漏责任人变动时怎么办。表里写着接口对接归系统负责人半年后这位负责人调岗了表没人更新责任落空——交接完成的那天就是这张表开始过期的那天。对策是在表的末尾加一条元规则负责人变更时交接双方按本文同样的方式做一次小规模操作演练并更新此表。让规则自己带着维护机制。第 19 篇组织分工里那句提醒在这里再次应验一个逻辑能力没有 owner就会逐渐过期。还有一项容易被忽略的交付已知问题清单。系统当前有什么已知缺陷、什么情况下会触发、有什么临时绕行办法。把已知问题诚实列出接收者遇到时就不是事故而是预期藏着不说接收者会在同一个坑里再摔一次而且摔得更慌——因为他以为是自己操作错了。五、用独立操作验收交接所有材料齐备之后验收标准只剩一条接收者能不能在受限范围内独立操作。受限范围要事先定义哪些任务接收者必须能独立完成澄川日常处理、异常处置、数据导出、按手册恢复哪些超出范围可以求助新需求评估、规则变更——那是维护责任表里别人的职责。范围划清验收才有边界不至于演变成什么都得会的无限考试。验收的方法就是第三节的演练加上一个变化作者不在场。接收者独立处理一个预设的正常任务和一个预设异常全程录像或留操作记录事后对照检查清单复盘。F1 组织研究里那条阶段三的标准在这里收口交接采用实际操作验证仅提交培训录像不足以证明已经接手——录像证明的是播放发生了不是接收发生了。验收通过后建议再留一个观察期一到两周内接收者遇到问题可以求助但每个求助都要记录——不是考核他是继续收集说明缺口。观察期结束时数一下求助次数和类型如果求助集中在同一类问题说明那一节的说明还是没写透如果求助五花八门说明验收演练覆盖的场景太窄。这份观察期数据是下一次交接的输入。验收通过后留三样东西接收者签字的交接确认含日期和范围、演练记录含两轮用时对比、遗留问题清单谁跟、何时清零。这三样进项目档案和第 19 篇的运行说明、第 22 篇的决定记录、第 23 篇的变更卡放在一起。档案齐了FDE 才算真的可以从这个项目上挪开视线——不是不留恋是不再被需要。回头看这篇的路列接收者任务清单按任务而非按系统写说明异常指引写到紧张三分钟可照做补齐版本依赖和责任最后用一次不代操作的演练收口。全部动作围绕一个判断标准接收者能独立完成任务、独立处理一个异常。页数、发送记录、签收单都只是这件事的影子。迁移练习留给你检查你手边任何一份系统说明找到异常怎么办那一节——如果没有这一节说明的作者还没准备好离开如果有看它写的是联系开发还是具名的接手人。然后问最后一个问题写这份说明的人休假两周你敢不敢替他值班。下一篇把视角拉高一层一个项目做完了哪些经验应该沉淀成组织可以复用的能力哪些应该诚实地留在原地——这是 FDE 的产品判断。 
长河君 · 2026/10/27 1:53:03 · 阅读 1.2k 怎样写出别人能接手的说明：FDE的交接能力
FDE岗位实务指南 · 第24篇澄川制造的资料核验项目进入收尾FDE 按 F3 服务范围研究里的交付物登记表把七项交付一一备齐问题与范围记录、数据说明、应用版本、评测记录、操作说明、运行手册、价值报告。文档发出去的那天他在交付清单上勾掉了最后一栏感觉这个项目可以画句号了。三天后接手的运行专员打来电话核验任务显示结果待查这个状态以前没见过是重新发起一次还是等等说明里没写。FDE 口头讲了五分钟——去执行记录里按业务请求标识查一下如果已经成功就直接取结果查不到就找运行负责人。专员听懂了事情过去了。挂掉电话FDE 在自己的记录本上写下一行字交接还没完成。文档发出去了但结果待查这个状态怎么办只存在于他的脑子里。这篇文章讨论的就是这件事怎样判断你写的说明真的够别人接手而不是只在文件层面完成了一次转移。一、文档发出以后为什么仍然离不开作者文档发出即交接完成是交付里最常见的一个错觉。它错在把信息转移和能力的转移混为一谈文档转移的是作者已知并且记得写下来的部分接手方需要的是完成任务的全部——包括作者知道但没意识到需要写的部分。这部分内容有个专门的名字隐性知识。哪类任务容易卡住、某个报错最常见的原因是什么、哪一步可以跳过而哪一步绝对不能——这些东西作者天天在做所以觉得不值一提接收者却是第一次遇到。写说明时的最大盲区恰恰是作者最熟练的那些环节。第二个原因是文档写作者的视角错位。多数技术说明按系统结构组织这是登录页这是任务列表这是核验详情页。这种写法对作者自然因为系统就是他搭的对接收者却是错的因为接收者不是要了解系统是要完成任务。BABOK 里有一条沟通原则讲的就是这个应根据每个相关方的角色提交适当广度与详细程度的信息而不是向所有人提交相同的信息。接收者需要的文档组织方式是他会在真实工作里遇到的顺序正常的一天怎么走遇到异常怎么办办不了找谁。第三个原因最诚实有些知识确实写不进文档只能在处理真实问题的过程里显现。这决定了交接的验证方式不能只看文档——后面第五节展开。文档截图是这类错觉的重灾区。说明里嵌着二十张界面截图看着详尽实际是定时炸弹系统一升级截图和界面对不上接收者按图找不到按钮反而比没有图更慌。截图能少用就少用必须用的地方配文字描述这一步在哪个区域、找什么字样让文字扛主要信息图只做辅助。判断交接是否真的完成有一个朴素的标准可以自问从明天起我休假两周手机关机这个系统会不会出事如果答案里出现应该不会交接就没完成。应该这两个字就是隐性知识还没交出去的部分。二、围绕接收者的实际任务写说明重写澄川的操作说明起点不是打开旧文档改是列一张接收者任务清单。运行专员接手后要承担哪些任务至少四类日常查看核验任务列表并处理新任务处理结果待查等异常状态每周导出运行数据给业务主管遇到解释不了的情况向上求助。这四类任务对应的说明深度完全不同第一类是高频低险写清楚入口和步骤即可第二类是低频高险是说明的重点第三类涉及口径要写清导出条件避免数字歧义第四类看似不用写恰恰最要写——求助有路径才不会变成出了事直接找原作者。任务清单怎么来不是 FDE 想象是照着第 19 篇的运行条件表翻译运行条件表里写了谁值守、看什么指标、异常谁处理那些谁就是接收者那些事项就是任务清单。运行手册和交接说明其实是同一份工作的两个视图一个是系统的运行视角一个是人的任务视角。有了任务清单说明按一条任务一份指引来组织。每份指引控制在接收者一次能读完的长度结构固定三段这个任务为什么存在它防止什么、产出什么、正常怎么做含入口和身份、做不了怎么办。 BABOK 的抽象程度概念在这里很实用对高频任务说明可以细到每个按钮对异常任务说明要细到看到什么现象、先查什么、依据什么判断、然后做什么。写每份指引前过两个问题。第一问接收者拿着这份指引需要的背景知识我写全了吗检验办法是假想一个完全没参加过这个项目的人来读——他读不懂的地方就是默认了背景的地方。第二问这份指引里的每个名词接收者的世界里叫这个名字吗工程师写提交核验请求业务嘴里说发核验同一样东西两个名字说明就成了需要翻译的外语。术语表放在说明第一页不是装饰。说明的组织方式变了厚薄分布也跟着变。按系统结构写的文档每章均衡按任务写的指引应该头轻脚重——日常任务的指引薄异常和维护的指引厚。一份异常部分比操作部分还厚的交接说明不是写得啰嗦是写得诚实。环境信息单独立一页实际环境的入口地址、用什么身份登录、版本号、依赖的外部系统采购系统接口、数据源。这页看似琐碎价值在于它是全部指引的公用地基——入口变了只改这一页不用逐篇翻修。也要注意保密边界入口和身份信息按第 17 篇的权限原则按需提供访问凭据绝不写进任何会被转发出去的说明文档。三、把正常、异常和恢复都走一遍说明写完作者自己先走一遍这是第一道检验。但作者走自己的说明永远走不出自己的盲区——他知道全部背景任何模糊的表述他都能自动补全。真正的检验是第二道教学交接演练让接收者在作者不代操作的前提下把三类场景各走一遍。第一遍走正常流程。接收者领一个真实任务从登录到完成全程自己来作者只在旁边记录他在哪里停顿、翻回说明哪一段、问了一句什么。停顿点就是说明的缺口。澄川的演练里专员在导出周数据这一步停了很久——说明里写了导出按钮的位置没写默认时间范围是本周还是最近七天这个口径差别让专员不敢确认数字对不对。第二遍走异常。这是演练的核心也是澄川电话那通问题的正式补课。接收者面对结果待查状态说明里那条异常指引这样写状态结果待查先按业务请求标识查询执行记录。若记录显示已成功直接取既有结果使用不要重新发起若记录显示未知结果或查询不到交给当值运行负责人按运行手册第 3 节处置不要自行重试处置完成后在任务备注里记录现象和动作。这三句话的每一段都对应一个曾经的坑。不要重新发起对应第 18 篇的教训——超时之后盲目重试可能造成重复的外部动作交给当值运行负责人对应反例联系开发——如果指引只写联系开发接收者既不知道找谁也会把问题默认塞回原作者。记录现象和动作对应第 16 篇异常记录是下一次排障的证据。一条合格的异常指引应让接收者在紧张的三分钟里依次知道查什么、找谁、不能做什么而不是先理解系统原理。第三遍走恢复。作者报一个预设的故障比如上周的核验任务全部显示失败让接收者按运行手册走回退或修复验证恢复路径真的能被一个非作者的人执行。F3 研究里的交接演练标准说得很硬由运行人员完成查看失败任务、定位数据问题、暂停异常流程和恢复上一版本若只能由原开发者排障说明交接尚未完成。演练的安排有两个实务细节。一是别在交付当天演练接收者刚拿到材料就被考考砸的多半是紧张而不是说明缺口给两三天消化期演练结果才反映说明的真实水平。二是缺口当场记不当场修作者看到接收者卡住本能是立刻讲解——一讲解缺口就被讲明白了这个动作盖住说明本身还是没改。记下来回去改文档第二轮演练看的是文档不是作者。三遍走完缺口清单出来说明补一轮演练再走一遍。澄川的第二轮演练里专员处理结果待查用时从第一轮的求助电话变成了四分钟的独立操作——这个用时变化本身就是交接质量的量化证据。四、补齐版本、依赖与维护责任任务层面的说明之外还有一层交接常被漏掉这个系统以后怎么办。版本当前运行的版本号、这一版包含哪些行为、历史版本存放在哪。没有版本信息的说明半年后接手的人连自己面对的是哪个系统都说不清。依赖系统依赖哪些外部条件——采购接口的地址和约定、数据源的刷新时间、运行所需的环境配置。依赖要写到如果它停了会怎样的程度数据源晚两小时刷新核验任务会怎样这个问题的答案接收者应该能从说明里查到。维护责任这是交接里最容易被默认毁掉的一项。核验规则以后要改找谁接口方变更谁去谈判据要按第 15 篇的方法迭代谁负责这些问题的答案不能是找原作者——交接的定义就是这些责任换人。澄川的说明里落了一张维护责任表规则变更归业务主管确认、接口对接归系统负责人、日常值守归运行专员、判据迭代每季度评审一次。维护责任表还有一行容易被漏责任人变动时怎么办。表里写着接口对接归系统负责人半年后这位负责人调岗了表没人更新责任落空——交接完成的那天就是这张表开始过期的那天。对策是在表的末尾加一条元规则负责人变更时交接双方按本文同样的方式做一次小规模操作演练并更新此表。让规则自己带着维护机制。第 19 篇组织分工里那句提醒在这里再次应验一个逻辑能力没有 owner就会逐渐过期。还有一项容易被忽略的交付已知问题清单。系统当前有什么已知缺陷、什么情况下会触发、有什么临时绕行办法。把已知问题诚实列出接收者遇到时就不是事故而是预期藏着不说接收者会在同一个坑里再摔一次而且摔得更慌——因为他以为是自己操作错了。五、用独立操作验收交接所有材料齐备之后验收标准只剩一条接收者能不能在受限范围内独立操作。受限范围要事先定义哪些任务接收者必须能独立完成澄川日常处理、异常处置、数据导出、按手册恢复哪些超出范围可以求助新需求评估、规则变更——那是维护责任表里别人的职责。范围划清验收才有边界不至于演变成什么都得会的无限考试。验收的方法就是第三节的演练加上一个变化作者不在场。接收者独立处理一个预设的正常任务和一个预设异常全程录像或留操作记录事后对照检查清单复盘。F1 组织研究里那条阶段三的标准在这里收口交接采用实际操作验证仅提交培训录像不足以证明已经接手——录像证明的是播放发生了不是接收发生了。验收通过后建议再留一个观察期一到两周内接收者遇到问题可以求助但每个求助都要记录——不是考核他是继续收集说明缺口。观察期结束时数一下求助次数和类型如果求助集中在同一类问题说明那一节的说明还是没写透如果求助五花八门说明验收演练覆盖的场景太窄。这份观察期数据是下一次交接的输入。验收通过后留三样东西接收者签字的交接确认含日期和范围、演练记录含两轮用时对比、遗留问题清单谁跟、何时清零。这三样进项目档案和第 19 篇的运行说明、第 22 篇的决定记录、第 23 篇的变更卡放在一起。档案齐了FDE 才算真的可以从这个项目上挪开视线——不是不留恋是不再被需要。回头看这篇的路列接收者任务清单按任务而非按系统写说明异常指引写到紧张三分钟可照做补齐版本依赖和责任最后用一次不代操作的演练收口。全部动作围绕一个判断标准接收者能独立完成任务、独立处理一个异常。页数、发送记录、签收单都只是这件事的影子。迁移练习留给你检查你手边任何一份系统说明找到异常怎么办那一节——如果没有这一节说明的作者还没准备好离开如果有看它写的是联系开发还是具名的接手人。然后问最后一个问题写这份说明的人休假两周你敢不敢替他值班。下一篇把视角拉高一层一个项目做完了哪些经验应该沉淀成组织可以复用的能力哪些应该诚实地留在原地——这是 FDE 的产品判断。