需求发现与现场观察

第3章　需求发现与现场观察

第2章形成了交付章程的骨架：目标和对象已经记录，真实问题、范围和指标口径仍待明确。本章讨论FDE小组如何通过访谈和现场观察，把客户提出的方案设想转化为有证据支持、可以检验的问题。内容依次包括陈述的拆解与追问、访谈与观察的取证方法、利益相关方与决策权限的识别、行业术语与数据流的整理，以及范围说明书的编写。本章完成问题陈述和范围建议，为后续指标定义、基线测量与验收标准的制定提供依据；这些工作共同构成通过界定门所需的准备。

3.1　陈述的问题与真实的问题

客户提出的请求，往往已经包含某种解法：有时是技术，如“用大模型”；有时是产品形态，如“做一个智能助手”；有时是任务，如“预测”“自动分类”；也可能直接给出目标，如“效率提高三成”。前三类说明了打算采用的手段，却没有说明谁在什么环节承受损失；最后一类给出了期望，但缺少现状和衡量依据。功能请求、表面现象和业务问题需要分别记录，不能因为客户提出了功能，就认为问题已经明确。

3.1.1　陈述为什么停留在方案层

需求工程早已讨论过这种情况：客户把请求直接写成实现方式，而真正要解决的问题没有被说清。软件社区把只询问解法、却不说明原始目标的求助方式称为XY问题。对FDE小组而言，这类陈述不是错误答案，而是调查的起点；需要核对的是，从业务目标到方案设想之间的推导是否成立。

方案之所以容易先于问题出现，有三方面原因。第一，方案可以立项、报价、排期和审批，损失却很难直接写进预算表；方案一两个词就能说清，描述损失则要说明谁在什么时候遇到了什么麻烦。第二，提出方案的人通常离实际工作隔着一层，看到的是汇总过的数字、转述的抱怨，以及供应商和媒体已经包装好的解法。第三，方案词汇会带来安全感：说“做故障预测”听起来先进、便于汇报，也不会直接触碰现有流程；而说“值班主管每天要在几个系统之间手工核对”，就意味着某个工作环节需要被审视，在组织中更难开口。陈述者还可能根据自己理解的技术边界筛选问题，只描述自己认为AI能处理的那一部分。后一种解释是本书基于现场经验作出的推论，不能替代具体项目中的取证。

RAND在2024年发布了一项针对资深数据科学家和工程师的访谈研究。研究访谈了65人，其中业界50人，其余为学界人员，均有至少五年构建机器学习模型的经验。受访者归纳出的首要失败根因，是业务方没有正确理解要解决的问题，或没有把问题清楚地传达给工程团队。该研究反映的是从业者感知到的原因，不是对全部失败项目的统计，只能支持较弱的判断：问题没有说清，是一线技术人员反复遇到的困难。

无论成因如何，FDE小组都需要把陈述中的方案、目标和问题分开记录：方案说明打算采用什么手段，目标说明希望改变什么结果，问题则说明谁在什么环节承受了什么损失。三者之间的关系要通过访谈、观察和数据核对来建立，不能把方案名称直接当作需求。

这并不意味着客户的方案一定有误。方案中可能包含对现场的准确判断：Tom提出预测，也许是因为他曾观察到中断前存在征兆。因此，本书把客户提出的方案视为待检验的假设，而不是已经明确的需求。调查可以为它提供支持，也可能发现反例，或限定其适用范围；在取得证据之前，不宜预先接受或否定。

3.1.2　拆解与追问

把客户的一次陈述分成三层，便于说清缺了什么。底层是现象与损失：某些人在某个环节遇到麻烦，造成时间、金钱或风险上的代价。中层是目标：客户希望事情变成什么样，通常用自己的度量来说。上层是方案：打算用什么手段达到目标。Tom的话带着方案（预测基站故障）和目标（减少网络中断），损失一层是空的：句子没有说谁在承受中断，承受的是什么。

拆解的方法是把句子按成分切开，对每个成分问同一个问题：要使这句话为真，必须同时有哪些前提成立。这一步的目的不是挑毛病，而是让每个隐含的前提显形，决定哪些要到现场核实、向谁核实。表3-1是小组对Tom那句话的拆解。

表3-1　“用AI预测基站故障”隐含的前提与核实方式

拆解告诉小组哪些前提要核实，追问则沿固定路径逐层分析陈述，直到碰到可以观察、可以度量的东西。路径分四级，如图3-1所示：方案、用途、损失、目标。方案是客户的原话，原样记录，不当场评价。用途问这个方案会在哪个环节、被谁使用、让他们做出与现在不同的什么动作，答不上来，说明方案还停留在愿望层面。损失问没有这个方案时谁在承受什么代价，现在如何应付。目标问用客户自己的度量，做到什么程度算好转。次序有意定为先用途、再损失、后目标，因为客户对用途最容易说出口，对损失需要想一想，对目标则往往还没有想过。

图3-1　从陈述到事实的四级追问

每一级的问法有共同方向：要求对方回到真实发生过的事情和真实使用的数字，而不是对未来的设想。问损失，把问题落在一次具体事件上，如“上一次因为这件事出麻烦是什么时候，当时怎么处理的”；问目标，请对方指出平时看哪个数字，现在大约是多少。“多久发生一次”这类频次，对方多半只能凭印象回答，应记下估计再用系统记录核对。每一级之后还可以加一个检验：能否不用行话，对一位不在场的同事讲清楚。四级追问也不同于“五个为什么”：后者若只沿单一因果链追问，容易忽略并行原因，停止位置也受提问者判断影响，所以追问只用于从方案还原到损失和目标，不用来认定根因，根因分析需要证据。

在合众通信，小组用这条路径和Tom谈了一次。他重复了原话；问到用途，他说值班人员看到预测后可以通知外场班组提前上站检查，这新增了一个前提，外场班组有余力做预防性上站；问到损失，他说区域分公司按月通报网络可用率，上个月有几次较长的中断需要他向上解释，原因他并不完全清楚，要问值班那边；问到目标，他说平时看网络可用率，具体数字要回去看报表。每条回答都要带来源（谁说的）和状态（是否核实）两个标注：“几次较长的中断”是他向上解释时的说法，真实次数和原因需要结合告警、工单及处置记录核对。追问不到答案是常态，“要问值班那边”本身就是下一步的方向；回答过于概括时，也应继续追问具体事件，不能因为表述完整就省略核实。

3.1.3　可检验的问题陈述

追问的结果落在一份问题陈述上：用客户的语言写一两句，说明谁在哪个环节遇到什么损失、现在怎样应付、怎样才算好转，并由结果责任人认可。本书用“可检验”而不用“正确”作标准，因为最初几天没有人能保证陈述正确，但可以要求它能被现场的事实证实或推翻。

可检验包含四点：有具体的主语，写明是哪些人，而不是“运维部门”；指明环节，说明发生在工作流的哪一步，而不是笼统的“效率低”；能够说明应到哪里寻找损失的证据，哪怕数字暂时是空的；不含方案，把“AI”“预测”“智能”“平台”等词全部删去，句子仍然成立。第四点最容易检查，也最容易暴露问题，“需要一个能预测基站故障的系统”删去方案词后什么也不剩，说明它从头到尾是方案。

措辞上应用客户自己的话写，运维中心的人说“退服”“上站”“开单”，就照他们的叫法写，Tom读到时能认出这是他的问题，这些叫法也自然成为术语表的第一批词条。

按这些要求检查现有材料，小组此时只能写出问题陈述0.1版。它保留了Tom使用的业务度量，没有写入“AI”或“预测”，并如实标出未知项。但它仍不完整：目前只有发起人的视角，对现行处理方式的描述很粗，也缺少实际处置人员的证据。每处空白都应转化为下一步取证任务。如果此时直接写成“值班人员处理告警效率低，导致中断时间长”，就把尚未验证的因果关系写成了事实，后续调查也容易变成替这句话寻找支持。

问题陈述0.1版（阶段结果）

东部区域网络运维中心每月向区域分公司通报网络可用率，较长的网络中断需要由Tom向上解释。哪些中断本来可以提前处理，中断发生后处置时间主要花在哪些环节，哪些人在承担这些环节，目前都不清楚。现在靠值班人员和外场班组在中断发生后处理。怎样才算好转，待损失量化后再定。

可检验不等于数字已经齐全，而是每项陈述都能指出应到哪里寻找证据。发现模式下可以记录受访者估计的耗时、频次和比例，但必须标明来源及“待测”，不把估计当作基线。问题陈述从0.1版起编号，每次修订说明改了什么、依据哪条证据、是否需要结果责任人重新认可。证据可以促成问题陈述的修订，却不自动授权范围变更；凡涉及已批准范围、资源或访问权限的调整，仍须按第2章的章程程序处理。

3.1.4　不继续的正当性

追问可能得到四种结果：原方案得到支持；问题被改写，损失确实存在，但不在陈述的位置，这是最常见的情形；范围缩小或次序调整；不继续，问题不成立、不值得解决，或现阶段不具备条件。第四种最难被接受，因为立项已经批准，预算已经划拨，小组的价值感也与交付挂钩。本书把“不做”写成正当而完整的产出，要求它和其他结论一样有证据、有记录。发现阶段得出“不建这项服务”的结论并非失败，要紧的是已经弄清问题当前造成多少成本。

“不做”需要区分三类情况。问题不存在或收益不足以支持投入，可以记录依据后结束；问题存在，但主要由流程、岗位或制度造成，应把发现交给有权处理的人，不必启动软件建设；问题存在但当前条件不足，例如没有结果责任人或无法取得必要数据，应作出停止本轮或限期补证的决定，并写明重启条件。不能把“暂缓”变成无限期等待，这与第2章阶段门的要求一致。无论采用哪种处理，交付物都应包括问题陈述、证据、判断理由，以及适用的替代建议或重启条件。

反方向的偏差同样要防：现场没有看到某种损失，不等于它不存在；没有人提到预测的用处，不等于预测没有用处。就合众通信而言，“预测”一行至今既无支持也无反驳的证据，Tom的方案设想只能记为待检验的假设，它是否有价值，要由现场证据和后面的方案比较来回答，而不由小组在桌面上预先断定。

3.2　访谈方法与证据收集

本节的访谈，是事先准备、通常一对一进行、围绕具体经历展开的谈话。它用于了解当前工作如何开展、哪里受阻，以及人们如何描述这些经历，不以征集未来系统的功能意见为主要任务。问卷、多人需求会和方案评审各有用途，但不宜直接替代这种访谈：问卷难以即时追问，多人会议可能受到职位关系影响，方案评审则容易把讨论限制在既定解法之内。发现模式下首先要回答的是当前工作如何进行，再讨论怎样改进。

访谈应产出带有来源和核对状态的记录，并据此更新假设台账，而不只是形成需求清单。图3-2表示这一过程：台账确定本轮需要回答的问题，访谈产生线索和证据，整理结果后再调整后续核实计划。如果访谈结束后台账没有变化，需要检查原因：可能已有判断得到进一步支持，也可能是问题设计不当，未取得有用信息。不能只按笔记页数评价访谈成效。

图3-2　访谈证据的流转

3.2.1　从假设到提纲

许多访谈在开始之前就已经做坏了。小组抱着“先了解一下情况”走进会议室，没有一个要回答的问题，于是对方说什么都记，回来得到十页笔记，却说不出哪一页改变了判断。准备的作用，是在开始前写下这场谈话要回答哪几个问题，听到什么会让小组改变看法。

提纲只是一页备忘，不是照着念的问卷。一场四十五分钟的访谈大致分四段：开场约五分钟，说明身份与来意，说明这不是考核也不推销方案，征得记录同意；请对方从头讲一次最近发生的事约二十分钟，小组只听，偶尔追问“然后呢”；针对台账的追问约十五分钟，向深处问而不向宽处问；收尾约五分钟，复述听到的经过请对方更正。深入访谈一般一人一场，备有讨论提纲，问题开放而中性，并设专人记录。

开场时最容易出问题的是保密承诺。“汇总时不会署名”在只有一位值班主管的部门里等于署了名，所以承诺要更小、更诚实：未经本人同意，不把原话与姓名或岗位联系起来对外汇总；岗位唯一的地方，事先讲明，由对方决定说多少。访谈也不带演示稿和原型，方案一摆上桌，谈话就从“工作怎样做”变成“这个东西怎样改”。提纲写好后找同事试演一遍，可以暴露复合问题和含糊用词。

3.2.2　提问规则

提问应以已经发生的具体经历为主；未来设想可以另行记录，但不能用来证明实际需求或采用意愿。直接询问“想要什么”或“会不会使用”，通常只能得到对某个设想的态度，不能替代对实际行为的观察。三方面的研究也表明，这类回答不能直接用来预测实际行为。

其一，意向与行为之间有落差：2006年的一项元分析汇总了数十项实验，发现干预能明显改变行为意向，行为却只有较小幅度的改变。其对象主要是个人的健康、环保行为，不能直接当作对运维中心的预测，但提醒“您会用吗”得到的是对一个设想的善意回应，而不是对行为的预报；企业场景里面对发起人委托的外部团队，人们还容易顺着提问方向表态。其二，措辞会推动回答：1974年的一项实验让参与者看交通事故影片，仅把提问动词换成“撞毁”或“碰到”，对车速的估计就明显不同。这是对短影片的回忆，不能照搬到工作访谈，却说明一个无心的词就能把答案推向提问者暗示的方向。其三，回忆的准确性随类型而异：受访者对自己行为的报告与观察到的实际行为出入相当大，事情过去越久出入越大，对自己选择原因的口头报告也常不准确。

合起来的结论是：对最近具体经过的叙述较可信，也可以拿记录核对；对一般情形的概括、久远事情的回忆和对自己动机的解释，要当作待核对的说法。

由此得到几条规则。先从一段已经发生的具体经历问起，通常可以请对方讲最近一次发生的具体事件，避免只听经过事先整理的典型案例。想了解罕见但重要的情形，可改问印象最深、影响较大的一次（关键事件法），不过它容易过度关注极端事件，因此仍需结合日常记录进行核对。一次只问一件事，复合问题、含糊问题和封闭式开场都是常见错误。问题中不应预设答案，也不应夹带解释。不要问假设性问题，应改问已经发生过的类似情形；如果对方说从未遇到过，这本身也是一条有用的信息。对方说“一般”或“通常”时，可以请他具体讲一遍“今天上午”或“最近一次”。对方说“要是有个看板就好了”，不要替他解释，先记入方案设想栏，再追问这个设想要解决哪一次具体麻烦。提问时沿用对方的词，并继续确认词义。表3-2给出了几组改写示例，共同点是：对方回答后，小组至少获得一项可以进一步核对的事实。

表3-2　提问的改写

案例　同一位受访者的两种问法

第四周的第二天，FDE小组第一次约谈值班主管Alice。一位成员备了五个问题，头一个是：“如果系统能提前预测基站故障，您觉得对值班有帮助吗？”Alice想了想：“有总比没有好。”第二个问题是“夜班是不是经常忙不过来”，Alice笑了一下：“哪天不忙。”二十分钟过去，笔记本上是几句客气话，没有一件可以去核对的事。

同行的另一位成员换了问法：“请您回想最近一次自己值班时碰到的、时间比较长的退服，从看到第一条告警讲起。”Alice讲了上周四凌晨的一次。小组只追问三种话：“您当时看的是哪个界面”“然后呢”“这个电话打给谁”。快结束时，成员把经过复述一遍，请Alice更正了两处。两种问法的差别不在对方的态度，Alice在两次谈话里一样友好，差别在于小组最终拿到了什么：前者得到礼貌，后者得到一条带时间顺序的经过，其中有可以核对的细节，还有两处与小组原先设想不一致的地方。

3.2.3　访谈对象与顺序

选对象的出发点不是人数，而是工作链上的每一个位置：一次退服从告警出现，到值班人员发现、开单、联系外场、上站处理、恢复、回单，经过了哪些人，每一类都应当至少有人被问到。漏掉一个位置，就等于假设那个位置上不会出现影响结论的事。可以按与事件的距离把对象分成四层：亲历者（处理过事件的值班人员和外场工程师），管理者（班组长和值班主管），相邻职能（信息技术部、采购部），发起人。距离越近，说的越接近“发生了什么”，越远越接近“希望怎样”。两类都需要，但不能互相替代。

顺序上有几条规则。先近后远：先听亲历者的经过，再与管理者和发起人的说法对照，冲突会自己显露；倒过来，先听了一套完整的概括，后面每一场都会被它带偏。一人一场：几个人同场，资历较低的人往往少说话，说出来的也往往与上级一致。尽早听持不同意见的人，如对新系统持怀疑态度又在班组里有分量的Bob，目的不是说服，而是尽早获得反证。约束方早谈，而且先谈规则：能否录音、笔记放在哪里、核对说法需要读取哪些系统，这些答复决定后面每一场怎样记录，所以信息技术部的David是第一位。发起人守在两头：访谈前授权并确认通知口径，访谈后接受汇总回报，不在现场，也不转述别人的话。对象由小组按岗位和班次从排班表中抽取，经Tom同意，而不是由他指定，因为被推荐的人往往表达得好、态度积极，且与推荐者看法相近。

一共访谈多少人才够？一项方法研究对两个国家的数十位受访者做深入访谈，发现主要主题在前十余次内已基本出现，这提示新增访谈带来新信息的速度会放慢；但其对象相对同质、提纲相同，运维中心各岗位的视角不同，不能把这个数当作定数。

本书采用一条教学设定的经验规则：每类主要角色先谈两三人；第二、第三位还在带来新的事实或反例就继续，连续两位只是重复，该类角色暂时停下。合众通信进场后的第一周（项目第四周）因此安排了David、Alice、Bob，白班夜班各一两位值班人员，外场班组的两三位成员，采购部的Emma，最后回访Tom。一天最多三场，每场之后留出至少一小时整理，夜班人员要在夜班时间谈。

3.2.4　记录的格式与证据的失真

访谈结束后，最重要的产出是可追溯的记录。本书把笔记分成原话、事实陈述和解释三栏。原话尽量逐字记录，未能完整记下的标为“近似”，并保留对方的用词；事实陈述记录谁在何时、通过哪个系统做了什么、耗时多少，并指向可查验的记录或现场；列入事实栏，只表示这项陈述可以核对，不表示已经核实；解释是小组的推断，应单独列出，作为待检验的假设。将三者混在一起，几天后重读时就很难区分哪些是受访者的说法、哪些是小组的推断，未经核实的推断也会被误认为事实。

每条记录还应包含编号、来源、核对状态和对应的台账条目。来源应区分受访者亲历陈述、转述、系统或书面记录、小组直接观察，以及小组推测；亲历陈述仍可能存在回忆误差，系统记录也可能缺失或口径不明，都需要按用途核对。状态沿用待核、单一来源、多源一致、冲突和已推翻，并可补记“已核对”及核对方式。“多源一致”指相互独立的来源支持同一项陈述，不等于已证实；若两人都转述同一位班组长的话，仍只算一个原始来源。这些状态描述核对进展，第1章的“无、自述、文档、实测”则描述证据强度，两者应分别登记。表3-3是Alice访谈I-01的记录。

表3-3　Alice访谈I-01的记录（节选）

表3-3有三处值得注意。其一，事实栏只写可以去查的内容，把原话里的“左右”“一大批”换成时刻和数量（约凌晨2点10分起、十余个基站），推断一律移到解释栏；每条还单独标明来源与状态，第03行的起因是转述、经过是亲历，两者分开标注。其二，第04行与Tom的说法相互冲突，记录没有试图判断谁对，两条说法各自保留，把分歧平滑成一个看上去一致的结论比不知道更糟。其三，方案设想没有混进事实栏。核对所需的数据还要对照数据访问清单，清单之外的字段和告警记录须另向David申请，批准之前不读取，所以“待核”往往意味着一项要排进日程的访问申请。整理要当天完成，隔一晚记忆就开始丢失细节，并倾向于补上“应该是这样”的内容。

访谈不是中立的仪器，从提问到回答再到记录，每一步都可能让事实走样。提问者带来的有诱导性提问和确认偏误，后者表现为笔记里“支持”的条目远多于反例，对策是访谈前写好“若不成立”会听到什么，并由记录者单独标出反例。

受访者带来的有顺从与社会期许，在运维中心它有具体来源：小组是被Tom请来的，对方知道这一点，所以可改问具体经历，例如“最近一次使用它完成了什么任务，哪些地方需要您另行处理”，避免用总体好恶代替使用证据。

还有概括与理想化、回忆误差、事后合理化、把转述说成亲历。特别要防极端事件偏向：记忆可能过度突出极端事件，最严重的一次往往讲得最生动，却不代表日常。Alice讲的那次退服是停电引起的，上个月几次较长退服是否也如此，只有工单和告警的统计才能回答，把生动的单例写成规律是访谈最常见的推理错误。

这些失真决定了访谈不能成为唯一的证据来源。访谈提供线索，系统记录给出次数、时间戳和分布，却看不见电话、口头约定和纸质表格，现场观察补出访谈与记录都看不见的那一部分，但遇不到过去的事件和罕见情形。用多种来源互相对照称为三角互证。有企业尝试用智能体对全员做自主访谈，覆盖面的成本确实降低，但以上规则对它同样适用甚至更紧：模型可能顺着对方附和，也可能在追问里加入预设，看不到对方指着屏幕讲的那一步，这是本书的判断。较稳妥的用法是让它做有边界的事，如访谈前检查提纲里有没有表3-2所列的问题，访谈后把笔记归入各字段。

3.2.5　整理证据并回填台账

整理的目的不是一份漂亮的纪要，而是更新台账：当天把笔记整理成表3-3的格式；按台账条目把各场记录归在一起，先看它们是否相互独立；判定状态；决定下一步核对什么。冲突不折中成一个说法，也不凭职位高低取其一，而是并列保留、写明各自来源，再去找能裁决的记录或观察。下一步核对什么，不按好不好查排序，而按对方案的影响排序：优先核对那些一旦不成立就会推翻整个方案的未知项。

对Alice的访谈（I-01）之后，合众通信的台账有四处变化。“基站故障之前存在可识别的先兆”只多了一个起因为停电的单例，既不支持也不反驳，下一步优先抽取近几个月较长退服的起因构成，因为若多数起因在站点之外，预测方案的适用范围将大幅缩小。“预测之后有人有余力采取预防动作”出现冲突，Alice称夜班外场一次只能出一路，Tom称值班人员可通知外场提前上站，下一步向Bob和排班表核实，因为它直接关系方案能否落地。“基站故障”一词在值班口中比“退服”所指更窄，问题陈述改用“退服”。新增一个待核问题：从首条告警到外场出发，时间花在开单和电话确认之间的哪些环节。问题陈述同步修订为0.2版。

问题陈述0.2版（阶段结果）

东部区域网络运维中心每月向区域分公司通报网络可用率，较长的退服需要由Tom向上解释。退服发生后，值班人员开单并电话联系外场班组，由外场上站处理；夜间外场只有一个小组值守、一次只能出一路（值班人员陈述，待核）。退服的起因构成、哪些本来可以提前处理、时间主要花在哪些环节、由哪些人承担，目前仍不清楚。怎样才算好转，待损失量化后再定。

0.2版的修订很小：把“网络中断”改为运维中心的叫法“退服”，补入处理方式和一条待核的陈述，依据是对Alice的访谈I-01的第1至5条（表3-3）。这一版没有增加任何结论，只把能标明来源的内容写了进去，其余仍是空白。证据还很薄时，修订应当小，并且每一处都能指回一条记录。

整理好的摘要可以请受访者本人看一遍，范围限于他自己说过的话。一轮访谈是否完成，看三点：最关键的台账条目不再空白，每类主要角色都有人被问过，每个“冲突”条目都有核对计划；不满足就不要以“已经谈了十几个人”为由结束，满足了也不必为凑数继续谈。访谈告诉小组人们怎么说，接下来要去现场看人们怎么做。

3.3　现场观察与正式流程之外的变通

访谈记录的是人们怎么说，说与做之间还需要再对一次：回忆会压缩例外，叙述会趋向理想化，而且人们对自己每天重复的做法，常常已不把它当成问题，一项做法一旦成了习惯，它带来的麻烦就一起退入背景。FDE的实务经验是，这类痛点用户自己说不出来，要靠工程师坐在旁边亲眼看见。

3.3.1　变通的界定与价值

变通（workaround）指人为了完成工作而采取的、正式流程或系统设计没有规定也没有预见的做法。这个界定有三个限定：动机是完成工作而不是偷懒；总是相对于某个参照而言，参照可以是流程文件、系统的设计意图或培训内容；是已经在运行的做法，不是设想，每天都在被使用，就说明有人在为它付出时间。个人习惯、偶发的一次性处理不算，为规避控制、谋取私利的做法属于违规，应按组织的规定处理。不能仅凭“偏离流程”就认定一个做法不合理，也不能因为它有助于完成工作就认定它合规；涉及控制或安全风险时，既要了解它承担的实际功能，也要按组织规定处理风险。一个实用的判断是：这个做法明天消失，会有什么受到影响？答案若不是“没有”，它就值得记录。

在研究文献里，变通在组织与信息系统领域常被提到却研究很少，它可以引出有计划的系统变更，因而是系统分析与设计的输入，而不只是需要纠正的偏差。安全研究区分“设想的工作”与“实际做的工作”：规程常由不在现场的人在时间压力和不完整信息下写成，一线工作面对的需求与资源又不断变化，两者的差距应当被当作改进的信息，而不是要消灭的问题。对复印机外勤维修技术员的长期现场研究给出了具体图景：公司设想技术员对照手册诊断、更换部件，实际观察到的却是技术员、客户和机器之间持续的熟练即兴，技术经验主要靠口头讲述流传。

现场常见的变通大致五类，这是本书为教学做的归纳，用处是看到一个做法时能立刻问出该问的下一个问题，见表3-4。

表3-4　变通的五种类型

同一个做法可以兼属几类。观察者面对变通，第一反应常是“这不规范”，这放在发现阶段是在给证据下判断，此时的任务是记录它存在、做了什么，评价留到后面。

3.3.2　现场观察的做法

现场观察是一组方法，共同点是人到现场，在对象工作的地方、工作的时候看，差别在于观察者介入多少、观察前有没有预先定好的类别、持续多久。发现阶段常用四种，见表3-5。

表3-5　发现阶段常用的四种现场观察方法

选哪一种取决于：对象能不能被打断；小组对这项工作已经知道多少，知道得少用开放做法，知道得多又需要可比较的数才用结构化做法；要回答的是“怎样做”还是“多久、多频繁”。与观察配合的还有实物痕迹分析（artifact analysis），研究人们为绕开系统局限造出的自制表格、速查卡、临时求助频道，它们是变通留下的痕迹，对象不在场时仍在，缺点是只见痕迹不见场景，一张表为什么有这一列仍要问人。现场观察得到的主要是亲历类证据，但并不因此自动可靠：观察者看到的是动作，动作背后的理由仍是推测，所以记录要把所见与解释分开；两位成员同时看到同一件事，仍只算一个来源，因为并不相互独立。

3.3.3　进场的规矩与观察者效应

进入现场前要分清三种许可，不能互相代替：场地的许可，运维中心是7×24小时的生产场所，进入需负责人同意；信息的许可，值班席屏幕上有真实数据，记录方式要符合信息技术部对数据访问的规定；本人的同意，Tom点头不等于Alice同意，被安排的对象可能觉得没有拒绝的余地。知情同意至少讲清五件事：小组为什么来（了解工作，不是考核个人）；记什么；笔记谁能看、放哪里、存多久；对方可随时让小组暂时离开或停止；看到安全隐患怎么处理。现场的规矩是不碰键盘、不替对方操作；不抄录口令、账号和客户联系方式；未经批准不对屏幕拍照录屏；严重告警出现时退后让位，生产优先于观察。

观察难免看到不合规的做法，如账号共用。怎么处理要在进场前约好，因为到时再商量，观察者会陷入两难：上报可能毁掉信任、让之后所有变通都藏起来，不报又可能违背自己的责任。建议三条约定：立即危及人身或系统安全的，当场提醒；其他不合规做法记为“观察到的做法”，不点名，以类别和后果向有权处理的人汇报；记录中不保留与结论无关的个人信息，笔记按约定期限销毁。

人知道自己被观察时行为会变，这一现象叫观察者效应，最著名的叫法是霍桑效应。但它的证据并不牢固：流行说法来自上世纪二十年代美国一家工厂的照明实验，称无论灯调亮还是调暗产量都上升，后来有研究找回当年的原始数据重新分析，发现流行描述中那种引人注目的数据模式并不存在；此后一篇系统综述纳入的专门研究几乎都来自健康领域，多数报告了某种效应，但差异很大、偏差可能显著。结论是克制的：不能把它当成已被证明的定律，也不能当成已被推翻的神话，影响的大小和方向随情形而异。

策略因此不是“消除影响”，而是缩小影响并在解释证据时留出余地。最需要担心的是变通被藏起来，以及对象忽然把每一步解释得头头是道的表演；信号包括对象不停地解释、说“平时不是这样的”。缓解的办法有：坐在侧后方，缩小存在感；把自己放在学习者的位置；多去几次、换时段；用不依赖观察的材料交叉核对，如核对表每天另存的副本、工单时间戳；收尾时问“今天哪些地方和平时不一样”。

3.3.4　合众通信的第一次现场观察

核实夜班外场“一次只能出一路”的说法，是第二场访谈（I-02）的任务。第四周第三天，小组请Bob一起查看班组排班表：夜班安排一个小组，两个人、一辆车，白班安排两个小组。Bob的陈述、Alice的陈述与排班表相互吻合，因此夜班编组情况记为“多源一致”；但实际出勤能力和临时调配情况仍需班组长确认。白班排了两个小组，也不等于有预防性上站的余力。Bob还提到心里有一份“老站”名单，认为其中一些站点的蓄电池续航不足，市电中断后更容易退服。这是需要核实的经验线索，可以提示风险筛查方向，尚不能证明预测模型的可行性。

观察日定在第四周第四天早班，交接之后的三小时。清单上每一项按“若成立、若不成立会看到什么”写好，另留一个开放项不设预期，因为预先给定的预期会限制观察者看到什么。两位成员坐在Alice侧后方一米多处，一人专记时间线，一人专记原话、屏幕内容和疑问，疑问写在页边，不当场问。Alice同意观察，提了两个条件：告警来了她可以立刻不理小组，小组不碰她的键盘。

案例　早上八点的那张表

八点整，夜班同事念完交接簿离开。Alice没有去看大屏，先打开了一个名为“早间核对”的文件。小组看到她在三个窗口之间来回切换：先在告警系统里筛出昨夜至今尚未清除的告警，把站点和起始时刻抄进表里；再切到工单系统，逐个查这些站点的工单；最后切到备件系统，看工单需要的备件是否已到，并在“等备件”或“接近时限”一列打记号，“时限”一列的数是她早先手工填进去的。中间一个站点的退服告警进来，她处理完又回到这张表，前后共用了五十一分钟。“这张表是我自己做的，”她头也没抬，“三个系统各看各的，哪几个在等备件，哪几个快到合同时限，谁也不会告诉你。”

九点四十分，Tom发来消息，要上周四那次退服的复盘材料，月度通报要用。Alice回了一句“这个得两天”，随后打开告警导出、工单记录和一份设备手册，把几段内容一条条贴进一个文档模板。两位成员在笔记本上各记了几页，一直没有开口。

表3-6　第一次现场观察的记录节选（O-01）

图3-3　观察日三小时的活动分布

收尾的十分钟，小组把所见按时间顺序复述，请Alice更正，并问了几个具体问题。这张表是谁要求的？没有人要求，最早是为了不被Tom问住。别的班次呢？别的值班主管各有一张，格式不一样。表每天另存一份，文件名带日期。临走前，Alice说了一句没有人问的话：“要是真能提前知道哪个站要出事，当然好，不过我现在连已经坏了的都对不过来。”

先看看到了什么，三小时的活动分布如图3-3所示，逐段记录见表3-6。三小时里，核对约占51分钟，复盘材料的拼装约占52分钟，合计103分钟，超过观察时段的一半，与告警和电话直接相关的处置只有19分钟。这些数来自一个人、一个早晨，用手表记录，起止由观察者判断，那个早晨只有一个单站退服，算平静的，它们能说明这两件事在这个早晨占了很多时间，不能说明平时也是这样，更不能拿去与任何目标比较。放进五类变通来看，核对表既是补缺（三个系统都不提供“哪些故障在等备件、哪些工单快到时限”的汇总视图），也是搬运（条目由人一条条抄入），“时限”一列是口头知识的书面化；复盘拼装是搬运；先电话后开单是绕行，电话里除站点名和告警内容，还有一句“你们现在谁在附近”，它的答案不在任何系统里，把这一步省掉，原来由电话顺带完成的判断就要有人接手。

再看与访谈的对照。凌晨那次成批退服是先开单后电话，这次单站且外场就在附近，是先电话后开单，两次不是同一类事件，不能证明Alice上次讲错，只说明先后随情形而变。这是说与做不一致的一个具体样子：更常见的不是谁说了假话，而是被问到的是一类情形，看到的是另一类。它还留下一个后果：工单创建时刻不一定等于开始处理的时刻，以后用工单时间戳计算处置时长，要先把起止时刻定义清楚。

更要紧的是克制。核对表和复盘都可能与Tom的问题有关，但目前只是推测：小组迄今只见过一次较长退服，起因还是停电，Alice早上做的事是否就是较长退服的主要成因，没有任何证据。回程路上一位成员说，我们做了三周预测，可她早上最花时间的事跟预测没有关系；另一位说，先别这么说，这只是一个早晨。前一句是顺理成章的感想，也是危险的感想，它把一个早晨的观察当成了否定原方案的证据。原来的预设被推翻之后，最容易发生的是换上另一个预设，纠正的办法是给新的假设同样写下“若成立会看到什么，若不成立会看到什么”，与旧假设同等对待，并请未参加观察的同事复核解读。

观察还有自身的局限，这第一次观察至少有五点：样本只有一人一班一天，对象和时段由发起人安排，在有第二个独立来源之前一律标为单一来源；时点偏，是一个平静的早晨，较长退服也许一个月才几次，要用记录补；看不到不在场的部分，夜班、外场现场、休息日；只见动作不见思考，看到她在三个窗口间切换，看不到她怎样决定哪几条“接近时限”，要事后追问；记录者疲劳与遗漏，要分工轮换并在离场后半小时内整理。

3.3.5　回填台账与问题陈述0.3版

整理沿用访谈的办法，观察产生的新条目往往在台账里没有旧条目，要新增。I-02与O-01之后，台账的变化是：夜班外场只能出一路，升为多源一致；Tom所说“可以通知外场提前上站”在夜班已被推翻，在白班仍待核，两条陈述不分对错，说的是不同的时段。先兆一行记下了Bob和Alice各自的一句话，一句说明有些先兆凭经验就能识别，一句说明眼下最占时间的不在预防上，二者不矛盾，各自也不足以支撑结论，小组原样保留，没有挑对自己有利的一句。新增两条：值班主管每天早间在三个系统间人工核对，复盘材料靠人工拼出、平均要两天，都是单一来源，“两天”还是陈述、数字待测。

观察中小组还听到三个方案设想：把三个系统间的核对自动做出来，把复盘材料自动拼出来，以及Alice说的“电话那一步能省掉”。它们记入方案设想栏，不进入范围，因为设想不是已证实的需求，设想之间怎样比较、是否包括预测，要在方案选择时处理，此时不排除预测，也不推荐任何一种做法。问题陈述随之修订为0.3版。

问题陈述0.3版（阶段结果）

东部区域网络运维中心每月向区域分公司通报网络可用率，较长的退服需要由Tom向上解释，这类退服的起因构成目前不清楚。退服发生后，值班人员开单并电话联系外场班组，由外场上站处理；夜间外场只有一个小组值守、一次只能出一路（排班表、Alice与Bob的陈述一致），白班的余力待核。

在一次观察到的早班（单次，约三小时）里，值班主管把约51分钟花在告警、工单、备件三个系统之间的人工核对上，用的是她自己维护的一张表；同一个早晨还花约52分钟为一份故障复盘拼材料，她陈述这类复盘平均要两天（待测）。这两项工作与较长退服的关系、损失的大小，目前没有证据。外场有人凭经验判断哪些站点的蓄电池易出问题（单一来源，待核）。

“用AI预测基站故障”仍是方案设想：目前既没有支持它的证据，也没有反对它的证据。怎样才算好转，待损失量化后再定。

这一版改动比0.2版大，是因为新增了两项有观察支撑的事实，而目标、范围和Tom的原话都没有改，预测也没有被删。

让Tom在文件上看到这一版之前，先在谈话里听到它：Tom提出的是预测，现场看到的却是另一类工作，如果这一点第一次出现在正式文件里，他很可能理解为小组不接受他的方案。较稳妥的做法是回访时先讲观察到的事实，再说明哪些是单一来源、哪些还没有证据，并说清预测没有被排除；他的反应也是证据的一部分。

一轮观察是否完成，要看清单上每一项都有“看到”或“没有看到”的记录，新增的关键条目有第二个来源或明确的核对计划，对象和时段至少各有两个。

3.4　利益相关方地图

访谈和观察勾出了与这件事有关的几类人，但这份名单带着取证方式的偏向：它列出了小组已经见到的人，没有列出还没有见到的人，也没有区分哪些人只是在场、哪些人能够决定项目的走向。利益相关方地图把这些人系统地记下来，目的是在界定阶段弄清小组有没有听到该听的人。谁在文件上拍板、谁的认可算数，是下一节的内容，本节只记录人和他们的位置，不分配责任。

3.4.1　利益相关方的界定与分析工具

利益相关方（stakeholder）在本书指能够影响项目结果的人或群体，以及工作、利益或权利会因项目而改变的人或群体。界定里有两个方向，影响项目的，和受项目影响的，二者常常不是同一批人：能否决数据访问的主管，日常工作也许丝毫不因项目而改变；每天抄表的值班主管，对项目却几乎没有决定权。它也不同于对接人，后者由工作安排决定，谁来对接、谁来答复，前者由项目涉及的事情本身决定。于是项目周围的人可以分成三个范围：能影响项目的，会被项目影响的，小组已经听到的。理想情况下前两个范围里的人都落在第三个范围之内，现实中的差，往往就是后来出问题的地方：能影响却没听过的人会在最晚的时候表态，会受影响却没听过的人会在上线之后用沉默表态。

分析利益相关方的方法很多，发现阶段常用的有四类，回答的问题各不相同，见表3-7。

表3-7　利益相关方的四类分析方法

属性识别来自一项被广泛引用的研究，它用权力（能否让别人去做他原本不会做的事）、合法性（诉求是否被认为正当）和紧迫性（诉求是否要求立即关注）三种属性识别利益相关方。三种属性任取一种或多种，共有七类：只有权力的叫潜伏型（dormant），只有合法性的叫自主型（discretionary），只有紧迫性的叫苛求型（demanding）；权力与合法性兼有的叫支配型（dominant），权力与紧迫性兼有的叫危险型（dangerous），合法性与紧迫性兼有的叫依附型（dependent）；三者兼备的叫确定型（definitive），三种属性都没有的不算利益相关方。三种属性不是固定的，它们会随时间改变，也取决于各方的感知，而不是客观事实。这解释了有些人为什么总被晚想起：潜伏型的人有权力却没有现成的诉求，不会主动来找小组，直到某个理由触发他动用权力，合同附件的最终解释者、安全评审的上一级主管往往属于这一类。把他们列入地图不意味着立刻去打扰，而是知道他们存在，并弄清触发条件。

权力—关注度格以关注度为横轴、权力为纵轴，四个象限各配一种对待办法，长处是快。它的局限有三点：静态，一个人只有一个位置，而David对数据访问的权力很大，对问题陈述怎样措辞几乎没有权力；“关注度”含糊，关注目标、方案还是自己的工作被改变，方向常常相反；容易变成单向管理。

本书的用法是：功能分类检查名单是否齐全，属性识别检查有没有被忽略的潜伏者，参与度矩阵记录现状与期望，权力—关注度格只用于排序，哪一种都不能替代对具体的人、具体的事的证据。

3.4.2　地图上记什么，从哪里找人

地图上的每一格本质上是一条假设：这个人有权批准某件事，担心某个后果，对项目持支持的态度。每条都要有来源和状态，因此地图不是人员名册，而是一组带证据的陈述。登记字段包括：人与岗位；相关事项，用事项而不是头衔；正式权限，注明依据；非正式影响，写可观察的现象而不写“很有威望”；得与失，区分当事人自己说的和小组推测的；诉求，尽量保留原话；参与度，现状与期望；来源与状态；下一步。其中有三条写法值得强调。参与度要按对象分开写，Tom支持“减少网络中断”这个目标，同时偏好“用预测达到目标”，只写一个“支持”就看不到真正的难处。立场要用行为判断，“David很谨慎”是评语，“David要求读取生产系统之前先说明身份、对象和期限”是可检验的观察。空白是信息，没有接触过的人写“尚未接触”，不凭职务猜测态度，猜出来的立场一旦写进地图，就会在下一次讨论里被当成已知事实。

找人的办法决定地图会漏掉谁。从发起人开始问“还有谁”是最常见的做法，它有三个偏向：被推荐的人多半与推荐者意见接近；组织结构图画的是汇报关系，不是决策路径和信息路径；使用者就在现场容易找到，握着一枚印章却在项目之外的人需要刻意去找。

较稳妥的办法是从事情本身出发，沿五条线索找：工作流，谁经手、结果交给谁，容易漏掉的是流程下游；决策，谁批准、否决、给例外，容易漏掉批准人的上一级；数据与系统，谁产生、维护、掌管访问，容易漏掉默默维护手工表格的人；约束，哪些合同、制度、安全或财务规则约束这件事、由谁解释；损失，谁承担、向谁解释。

每场访谈结束时固定问三个问题：还有谁应该听一听，谁可能不同意刚才讲的，遇到实际问题一般去找谁，第三个问题找的是职位不高却被大家当作答案来源的人，他们也是将来推广的种子。同时记录每个名字是谁提的，如果地图上所有名字都来自Tom，这本身就是一条应当写进地图的信息。条目控制在能维护的范围，一个约四十人的运维中心，八到十五个条目加几个按角色合并的群体就够。把关方宜早不宜晚，安全、合规、合同的约束在界定阶段被听到可以成为设计输入，拖到上线前就变成推翻设计的理由。

3.4.3　合众通信的地图与发起人的反应

三场谈话和一次观察之后，小组建立了第一版地图，表3-8摘录其中主要的人。

表3-8　合众通信利益相关方登记（节选）

这张表有几处值得注意。发起人与例外批准人不是同一个人：Tom有预算和阶段门的决定权，却不能批准数据访问，这个项目里“能批准例外的人”在信息技术部的链条上，David的上一级主管是一个潜伏的批准人，小组不绕开David去找他，而是在提交访问申请时向David了解升级的条件，让这条路径在需要之前就是公开的。一线用户的声音太窄：已谈过的只有Alice和Bob，外场班组长因观察记录才被补上，印证了流程下游容易漏掉。表中三处依据是转述或推测，都标了状态，地图的可信度不取决于格子填得多满，而取决于每一格的依据是否写明。

第四周第五天，小组回访了Tom（I-03）。事前定了几条原则：先讲事实后讲含义，并说清哪些是单一来源；预测没有被排除也没有被证实，这一点明确讲；不转述Alice的原话，核对表只说成值班主管岗位的早间做法。Tom先问的是复盘，两天的周期他知道，没想过其中有多少是拼材料的时间。听到早间核对，他的第一句话是“这个不该靠个人做的表”，随即问每个班次是不是都这样；小组回答只看了一个班次，没有指名。他问“那预测还做不做”，小组如实说既无支持证据也无反对证据，要先看较长退服的起因构成，这需要告警记录的访问。Tom说：“月度通报上被问到的是为什么中断，不是核对花了多长时间。你们先把起因查清楚，预测的事再说”，并表示可以自己去跟David说一声。对问题陈述0.3版，他说周末看，没有当场表态。

Tom的每个反应都是证据，但每个反应都不止一种解读。说两天的周期他知道，却没想过其中拼材料占多少，可能是习惯使麻烦退入背景，也可能不愿追究；说“不该靠个人做的表”，可能把问题归因于系统而非个人，也可能是预先防御；答应周末阅读而不表态，可能是审慎，也可能是推迟。

区分这些解读靠的是之后的行为：是否提供近几份复盘材料，是否同意观察其他班次，是否真的联系了David，周一是否回复，而不靠对他的揣测。由此，他的态度要分对象写：对目标支持，对现场工作支持，对方案设想仍倾向预测但接受先查起因（单一来源，待验证），对0.3版尚未表态。他最关心的是月度通报上的解释，这是他的损失所在，恰与较长退服的起因构成直接相关。他对“个人的表”的反应也提示，他有可能把现象理解为对值班主管的批评，小组以后的汇报需继续写成流程和系统留下的空缺。

在发起人面前有两种常见错误，迁就，听出偏好就把发现往预测上靠；急于证明他错，把观察当成驳倒预测的证据。地图的作用是帮助小组弄清自己面对什么，不是赢得发起人或争论，更诚实的做法是同时讲出支持和不支持原假设的证据，把决定权留给有权决定的人。

小组自己也是利益相关方，产品厂商、集成商或内部技术部门各有收入、续约或考核方面的利益，一家有现成预测产品的厂商，对“预测”的态度不可能完全中立，写地图时应自问：我们自己想要什么，这会怎样影响对别人的判断。

回访后地图修订为0.2版：Tom一行改为分对象写法并补入诉求；增加区域分公司作为间接利益相关方；David一行补记“Tom表示可以自己联系David”，单一来源待验证。图3-4用位置示意这一版里主要的人。右上角是空的：对项目事项决定力大而日常工作又被深刻改变的人，目前没有。决定力大的Tom、David及其上级日常工作变化不大，工作被改变最多的Alice、其他值班主管、Bob几乎没有决定权。这是许多企业项目的普遍结构：决定由一批人作出，后果由另一批人承担，小组要在两批人之间传递信息，并对两边都诚实。

图3-4　合众通信利益相关方地图0.2版

3.4.4　受损者、不在场的人与地图的保管

项目的代价最终由具体的人承担，这是发现阶段容易忽略的一点。企业AI项目常以“帮助大家节省时间”的形式提出，但收益和负担并不会平均分配。项目可能改变一个人的工作量、工作过程的可见性、原有的控制权，以及专业经验的价值：过去只有本人知道的做法可能被记录下来，过去由本人决定的事项可能交给系统或其他岗位处理，依靠长期经验形成的技能也可能不再稀缺。这些变化不一定都是负面的，但都可能影响相关人员对项目的态度。

MIT NANDA在2025年的一项对52家机构的调查请高管和一线用户按遇到频率给常见障碍打分，“不愿采用新工具”排在最前，但报告说明评分反映的是频率而不是影响大小，并解释为用户不愿使用不能适应其工作的工具。把“抵触”默认读成情绪，项目团队会去做安抚，漏掉它也许是对系统质量的一个正确判断。所以地图上的“抵制”是一条需要解释的信息，先问他抵制什么、有没有道理，而不是先问怎样让他不抵制。变通本身也不是抵制。

遇到会受损的人，首先要问方案能不能改，其次才是怎样管理这个人。若系统让Alice的做法变得可见并可能被用于考核，这个风险来自方案设计和使用规定，应通过改设计、改规定消除，比如限定核对结果只用于流程改进，靠劝说“相信不会被考核”既不可靠也不诚实。有的实务材料建议公开承诺不裁员，并把释放的人力导向更高价值的工作，但这类承诺只有对人事有决定权的人才能作出，FDE小组无权承诺任何岗位、编制或考核方面的事，能做的是请有权的人把承诺说清、写下来。承诺做不到的事，比不承诺更损害信任。对不在场的人，如终端用户和区域分公司，小组把他们登记为地图上的一格并标明“推测”，找到能反映其情况的通道，不说“值班人员都会喜欢”，在没有听过之前，这类话是替别人表态。

一张写着对具体的人的判断的地图是敏感材料，保管方式要在使用前确定。工作版只在小组内部使用，姓名、立场、推测都写在里面，放在受控位置并注明保存期限和销毁方式。共享版可以给Tom或David看，也应假定当事人迟早会读到，只写岗位或功能、相关事项、他们守护或关心什么，以及联系计划，不写立场标签、推测和访谈原话。David一行，工作版写“中立；对数据访问按程序答复”，共享版写“批准数据访问和系统权限；关注生产系统和数据的安全；访问申请提交后三个工作日内答复”。写作上的自检叫当事人读到测试：假定这个人明天读到自己的这一行，是否会觉得被误解或被侮辱。它要求每句话描述可观察的行为和有来源的陈述，而不是性格评价，“David要求先说明身份、对象和期限”通得过，“David爱设卡”通不过。

地图是活的。每次访谈或观察之后更新相关条目，出现新名字加条目并记下是谁提的，说与做不一致时按行为改立场，范围变化时更新受影响的人群，保留旧版本和日期。

使用主要有三种：决定下一步和谁谈，为每次谈话做准备，以及界定门之前做缺口检查。检查问题包括：有没有一个既认这个问题又有权决定的具体的人；谁能批准例外、路径是否清楚；一线使用者里有没有人愿意共同定义“好”；把关方的约束是否已听到；受损者和不在场的人有没有表达通道；其中一个关键人缺席会怎样。合众通信的最后一问有答案：Tom同时是发起人、结果责任人和阶段门的决定者，是单点，他一旦离场，项目的支持就可能落空，把这一点在界定阶段写下来，比到那时补要便宜得多。

最后两点提醒：地图不是操纵清单，读起来像一份对付别人的计划就走偏了；也不要追求精确，五级参与度和位置示意都是粗略判断，能指导下一步行动就够了。

3.5　责任人与决策权限

地图回答了谁在哪里、各自在乎什么。本节回答另外两个问题：对每一件需要决定的事，谁说了算；问题陈述写成之后，谁的认可才算数。前一个关系到小组能不能做事，后一个关系到小组做的事是不是客户要的事。交付章程的骨架版把归属分为结果、实现、决策和访问边界四类，那是针对整个项目、写在小组还不知道真实问题的时候；发现阶段的证据把问题陈述改写了几遍之后，它需要往下落一层：落到每一条发现，落到实际被遵守的权限，落到一份可回溯的认可记录。

3.5.1　发现阶段的三类缺口

发现阶段的责任问题通常以三种形式出现。第一种是无主的发现：大家都觉得有问题，却没有人认为它是自己的。Alice的早间核对没有人要求，也没有人检查，它存在是因为她需要，而不是因为组织分配过。这类发现往往最有价值，因为它们是组织里没被分配却被人默默承担的工作；也最容易在项目中途落空，因为没有人对它的描述负责。

第二种是凭头衔推定权限：多数时候主任可以批准主任管辖的事，但并不总是如此，Tom认为必要并口头说“可以”，读取生产库的账号仍要经过信息技术部的评审，那是另一个人、另一条链路上的权限。头衔给出一个起点，不能代替对具体事项的核实。

第三种是认可缺位：问题陈述写下了，客户也听过，但没有谁明确说过“这就是我们要解决的问题”。RAND访谈研究的受访者把领导者没有向工程团队说清要解决什么问题、优化什么指标，以及过快改变优先级列为失败的根本原因之一。认可记录不能保证领导者不改主意，但让改变成为一次看得见的、有版本的事件，而不是一场没有人承认发生过的漂移。

一个外部情形：某仓库经理在启动会上说要缩短拣货时间，团队三周后交出路线优化方案，验收会上调度主管说真正的损失是错发，不是慢，仓库经理只说“这个我也听说过”。启动会上没有写下问题陈述，也没有谁表示认可，三周的工作并没有错，只是回答了一个没有人明确提出的问题。

3.5.2　逐条发现的归属

针对问题陈述中的每一条发现，需要回答四个问题：谁承受它造成的损失，谁有权改变这项工作，谁掌管与它有关的数据，谁来认可对它的描述。它们对应承受者、变更权人、数据掌管者和认可人，与项目层面的四类归属相关却不相同：一个项目只有一位结果责任人，而不同的发现可以有不同的承受者和变更权人。

回答这些问题常有几点发现。四栏里的人经常不是同一个：早间核对的承受者是Alice，能够改变值班流程的是Tom，小组如果只和承受者谈，会得到许多生动的抱怨却找不到可以拍板的人，只和有权者谈，则会得到一个干净的、与现场有距离的描述，两类都要听。有的发现没有变更权人：“较长退服的起因构成不清”是一个待回答的问题，不是一项要改的工作，填上“Tom”很容易，也是错的，它会让人以为问题已有行动方案，留空并写明原因更准确。还有些空白是小组的未知而非对方的缺失：追问“谁有权改变外场的出勤”，小组才发现自己并不清楚，那位在观察记录里出现过两次的外场班组长，也因此从“尚未接触的下游”升为必须单独谈的关键人。最后要区分认可与事实核对：认可人认可的是对发现的描述，不是解决办法，Alice每天做什么的细节要由她本人核对，而这条发现是不是要解决的问题的一部分，要由Tom认可，让Tom核对他不在场的早晨，或让Alice决定优先级，都是错位。

3.5.3　正式权限与实际权限

正式权限是制度、授权文件和岗位说明所写的，实际权限是做决定时真正被遵守的。差距来自口头授权形成的惯例、长期未修订的制度、一人兼任数职，以及没有正式权限却足以使决定作废的人，即事实上的否决权。对小组来说实际权限更重要，但它难以验证，也随人事变动而改变，所以要用证据。

证据有四种：书面制度，名义上谁能批准什么，可能已过期，用来提出问题而不用来下结论；过往案例，最近一次类似的事谁批的、几步、几天，可用于核对实际路径，但仍需确认授权是否有效；当事人自己的陈述，可能高估或低估，要向链条上的下一个人核对；他人的陈述，只作线索。

三种问法适用于每个涉及决定的人：“上一次有人要……，是谁批的？经过几步？用了几天？”“这件事你能批准到哪一步？哪一步需要别人？”“如果你不同意，这件事还能不能做？谁能让它继续？”。把同一个问题问给链条上相邻的两个人，比较他们讲的链条是否衔接，A说“我批完交给B”而B说“从没收到过”，问题不在谁说谎，而在链条上有一段没有被写下来。

合众通信的小组核实了两件事。外场出勤，Tom和Alice讲的是同一条链：外场班组归中心管，每天的出勤由班组长按人手和路程安排，值班人员通知班组长，去不去、几点去由班组长定。小组记为“值班人员对外场有建议权，没有指令权，实际安排权在外场班组长”，两人说法一致，来源独立性及具体权限待班组长本人核实，它的含义是：将来任何系统的输出若需要外场采取行动，它要说服的是班组长。告警记录的访问，David说它不在已批的访问清单之内，须重新申请，写明用途、字段、时间范围、使用人和有效期，三个工作日内答复；Tom说会跟David说一声，小组把它记作输入而不是批准，业务必要性由Tom认定，访问本身由David批准。两件事说明权限是按事项和路径分开的，把一个人概括为“主任”或“信息技术部负责人”会掩盖这些区分。

3.5.4　发现阶段的决策清单

发现阶段每天都有一些更细的决定：谁同意小组进入某个班次，谁同意占用受访者的工作时间，谁批准读取某张表，谁确认观察所得不会被拿去考核个人。每件都不大，却是延误最容易累积、“我以为他批过了”这类误会最容易发生的地方。把它们写成清单，每项有拍板人、答复期限和依据，口头同意就变成可回溯的决定。表3-9摘录合众通信的清单，它是对章程中决策清单的追加，不放宽任何访问，不扩大范围。

表3-9　发现阶段的决策清单（节选）

3.5.5　问题陈述的认可

“认可”在口语里含义很宽，至少混着三层：知晓，他听过了；认定，他同意这段描述的事实属实，或同意把它作为待核条目；认领，他承认这是项目要先解决的问题，归他负责。只有后两层才算数，而且要逐段说清。认可的对象是对问题的描述，不是解决办法、数字、预算，也不是项目是否继续，混在一起，会让一个人在“同意描述”时被理解为“同意方案”，也会让他因担心被这样理解而拒绝同意描述。

为什么要有记录：沉默、点头、说“我看看”都不是认可，不同的人事后理解不同；口头认可会随时间变形，三个月后没人说得清当时同意的是哪个版本；继任者读到的只有文件；门上的决定需要证据。

记录不必复杂，一封回复邮件加一页表格即可，要写明版本、认可人、逐段结果、保留的内容及用认可人自己的话写的原文、小组的处理，以及哪类修订必须重新认可，凡改变了谁受损失、哪个环节、“好转”的含义的，必须重新认可，文字润色不必。涉及某位一线人员工作的段落，先请当事人核对事实再交结果责任人，书面版本发出之前先当面讲一遍，书面文件是谈话的确认，不是谈话的开始。在约定期限内无答复，不视为认可；逾期按决策清单升级。

结果责任人的回复可以是认可、有保留的认可或不认可，其中最需要小心的是保留，因为性质不同，处理不同。对事实的保留，决定它的是证据而不是职位，小组不争论，记入台账、写明核实办法；对解释的保留，把两种解释并列记下，等证据来区分；对优先级的保留，是结果责任人的决定，小组应当采纳，因为优先次序正是他的权力。事实问题不能用权力来决定，优先级决定应由有权者结合证据作出，这条分界是整个认可流程里最要紧的原则。

小组在回访Tom当天把问题陈述0.3版和认可记录草稿一起发给他，第五周第一天他回复了，表3-10是据此整理的记录。

表3-10　问题陈述0.3版的认可记录

这份记录表示结果责任人有条件地认可了问题陈述，而不是项目失败：三段中两段得到认可，一段保留，同时明确了下一步优先级。Tom保留的是关于事实的判断，小组没有用“没有数据”直接否定，而是将其记录为待核实的台账条目。这一意见也说明0.3版的表述还不够准确：与预测有关的材料其实是两条个人记忆——Bob提到一份蓄电池续航不足的“老站”名单，Tom记得去年有两次较长退服与蓄电池有关。两者都没有数据支撑，来源是否独立也无法确定，因为Tom的印象可能来自外场人员的口头汇报。因此，既不能写成“没有证据”，也不能写成“已有证据”，更准确的表述是“有两条个人记忆，尚无数据，待进一步核对”。Tom接受优先查明较长退服的起因，只说明调查先后顺序，并不代表他已经接受预测方案。

问题陈述0.4版（阶段结果；第一、二段Tom已认可，第三段待其再看）

东部区域网络运维中心每月向区域分公司通报网络可用率，较长的退服需要由Tom向上解释，这类退服的起因构成目前不清楚。退服发生后，值班人员开单并电话联系外场班组，由外场班组长安排上站；值班人员对外场有建议权，没有指令权（两人的转述，待班组长本人核实）。夜间外场只有一个小组值守、一次只能出一路（排班表、Alice与Bob的陈述一致），白班的余力待核。

在一次观察到的早班（单次，约三小时）里，值班主管把约51分钟花在告警、工单、备件三个系统之间的人工核对上，用的是她自己维护的一张表；同一个早晨还花约52分钟为一份故障复盘拼材料，她陈述这类复盘平均要两天（待测）。这两项工作与较长退服的关系、损失的大小，目前没有数据。

“用AI预测基站故障”仍是方案设想，尚未得到证实，也没有被排除。目前与它有关的材料有两条个人记忆：Bob提到一份蓄电池续航不足的“老站”名单，Tom记得去年有两次较长退服与蓄电池有关。两者没有数据支撑，是否相互独立仍待核实。Alice则指出，当前连已经发生的故障都还难以对照清楚。怎样才算改善，仍需在损失量化后确定。

结果责任人的优先次序：先查较长退服的起因构成。

3.5.6　责任冲突与升级

把责任和权限写清楚，并不保证没有冲突。常见的有四类：事实冲突，Tom说值班人员可通知外场提前上站，Alice说夜班一次只能出一路，按证据而不按职位判断，两条陈述都留在台账，不让职位高的说法自动胜出；业务认可与访问批准，Tom认为读取告警记录必要，David要求先评审，两件事各有拍板人，一方的批准不能代替另一方；拍板人缺席或不答复，先催，按清单升级，升级材料写明需要的决定、可选方案、证据、责任人和期限，它是一份请求决定的文件，不是对别人的评价；小组与结果责任人对范围看法不同。

最后一类直接考验小组的诚实：现有观察提示退服后的处理环节可能存在较大负担，而Tom仍希望把预测放在第一位。小组要做的是把证据按来源与状态摆出来，说明自己的判断，请他决定，优先级归他，包括把预测放在前面；不可当面同意、回去另做一套，也不可为免他不快而淡化不支持他的证据。如果证据确实不足以支持继续，说出这一点是小组的责任。

升级只走清单上写明的路径，不越级：David的答复迟迟不来，不去向Tom的上级申诉；Tom的优先级与小组判断不一致，不去找David的上级说话，这些做法既绕开约定，也破坏小组在两个人面前的可信度。

假设台账中每条的“负责人”一栏，至此可拆成两个不同的责任：谁来核实，由小组承担并具体到人；谁能回答或批准，在客户一侧。例如外场出勤的安排权，小组核实，外场班组长回答；去年两次中断与蓄电池的关系，小组核实，Tom提供日期、David批准告警记录的访问；“老站”名单与历史退服的关系，Bob回答，是否写出名单由他决定。分开写，可以避免“这件事归谁”这类含糊说法。

3.6　进入陌生行业的第一周

访谈和观察都要借助语言。从小组进入网络运维中心的第一天起，耳边就不断有半懂不懂的词，眼前也不断出现没有注解的数：“上站”“开单”“较长退服”“老站”。这些词和数散落在各份记录里，没有一个地方回答过：这个词在这里到底指什么，这个数是谁、怎样算出来的，信息实际上怎样走到下一个人手里。

进入陌生行业，常见的应对有两种，各有代价。一种是用通用词替换，把“退服”当作“故障”，把“网络可用率”当作教科书里的公式，很快，但“基站故障”在不同岗位上指的并不是同一类事件。另一种是先把自己学成半个行业专家，稳妥但耗时，而且书本里的行业知识未必是这家公司的做法。

RAND访谈研究的50位业界受访者中，有10位提到缺乏领域理解会导致项目失败，指出数据科学家很少是所建模型所在领域的专家，需要领域专家解释数据里每个元素的含义；同一研究还提到，有的领域专家因担心被取代而消极抵制。陌生行业带来的困难因此有两层：一层是不懂，一层是懂的人未必愿意教。

本书对第一周的要求比两种应对都低，也更具体：不要求小组懂，要求小组留下三份可以被对方纠正的文件。术语表记录对方说的词指什么；指标口径登记表记录对方说的数是怎样算出来的；数据流图记录信息实际上怎样流动，并附记相关工作步骤、哪些步骤靠人。

这里的“第一周”指进入业务现场、开始系统取证的第一周；合众通信已在前三周进行过模型试验，因此本章对应项目第四周。检查它们的指标也很简单：有多少条目已被使用这个词的人当面核对过，多少仍待核，多少存在分歧。一份没有被任何人纠正过的术语表，要么没有人读过，要么错得没人愿意改；一份第一周就被改满批注的文件，说明小组把没把握的地方写了出来，对方也愿意改。

第一周不急于形成定论，暂定判断须注明证据和限制；不产出“理想的”流程，数据流图画的是现在怎样走；不替分歧选一个统一的词。本节登记的口径只是“别人怎么算”，指标应如何定义、基线怎样测，属于指标设计；画的数据流只标明谁在手工搬运，不判断数据质量，那是数据治理的内容。

3.6.1　术语表与通用语言

术语表最容易被低估，困难在于“谁的解释”。同一个词在一家组织里常有几种含义，各部门也会用各自的词指同一个东西，销售叫客户，运营叫委托方，财务叫结算主体；谁来调解这类分歧，未经核对的释义一旦进入项目文件，便容易被当作统一口径。词典的编纂者会获得影响，也会形成依赖，所以本书的规则是：术语表里的词是客户的词，小组自己的技术词，如“切片”“评估集”，另作一栏，只用于内部和技术文件，对外文件附上与客户用词的对照。软件工程里有个成熟的说法叫统一语言（ubiquitous language，亦译通用语言）：开发者与使用者共同建立一套词汇，既用于交谈，也对应领域模型，随理解加深一起演化。第一周的用法比它窄，小组是在收集词，不是制定词，起点是先把别人怎么说记准。

表3-11　术语表0.1版（节选）

这张表有几处值得留意。“未清除告警”来自一次更正：小组把Alice讲的东西记成“昨夜的告警”，她指出是“昨夜至今尚未清除的告警”，两个说法一个按产生时间划，一个按当前状态划，错记进字段定义，查出来的东西会差很多。“时限”“等备件”两条说到哪里就写到哪里，没有补一个看起来合理的含义，一条写着“待核”的词条，比一条写错的更有用，因为它告诉人们还有一个问题没有答案。分歧不抹平：假如另一个班次的值班主管说“开单”是指定处理人之后的那一步，术语表应拆成“开单（甲）”和“开单（乙）”，各标使用者与出处，在易混词里互相指向，哪条是中心的正式说法，由有权解释的人回答。

小组不必从零开始。行业标准组织为故障工单管理定义了统一的接口规范，给出一组基本的工单状态，可以当作参照，知道“行业里一般有哪些状态”，但它给出的是一般性的状态，这家公司实际用哪些、每个状态由谁在什么时刻设置，只有系统和使用它的人才能回答，把标准当作合众通信的术语表，是用“应当是这样”代替“实际是这样”。

模型可以帮忙列出笔记中的专门词汇，指出同一个词出现的位置，但不应补写释义：模型会用词的常见含义去填补空白，而客户的专用含义往往正是与常见含义不同的那一部分，一条补出来的释义看起来比“待核”更完整，实际抹掉了最需要保留的区别。这是本书的判断，小组可以用已核对的词条检验：看模型在不看释义的情况下补出的解释有多少与之一致。

3.6.2　指标口径登记

数比词更容易误导人。词含糊时人们通常能感觉到，而“约51”“92%”看上去很精确，就很少有人问它怎么来的。现场里的数多数不是为这个项目算的，而是各人为各自的用途算的，来自不同的数据、窗口和判断者，所以第一周听到的每个数，都应先当作“某个人在某个场合报出的数”。

登记时对每个数问五件事：范围，分母是什么；窗口，统计哪段时间，跨窗口的事件算在哪一段；起止时刻，从哪个时刻算到哪个时刻，工单的创建时刻并不总是开始处理的时刻；判定者，一件事算不算数谁说了算；来源与取数人，数从哪个系统取出、谁取。

客服行业的“一次解决率”就是例子：分母是全部来电还是只含已关闭的工单，窗口按来电日期还是关闭日期，“解决”由客服标记还是客户确认，答案不同，同一批数据能算出差别很大的数。这些问题在第一周问代价很低，等指标写进验收条款之后再发现口径不一致，代价就高得多。

“多长才算长”这类门槛尤其需要问。监管规则对中断的判断，往往同时涉及持续时间、影响规模、业务类型和设施类型：例如美国联邦通信委员会的规则要求无线业务提供者在发现一次持续至少30分钟并满足一定规模条件的中断后，限期向监管机构报告。它不是“较长退服”的答案，只说明两点：中断的门槛通常同时涉及持续时间和受影响规模；门槛由制定规则的一方决定，不由受约束的一方决定。Tom所说的“较长”若来自区域分公司的月度通报，它的口径就是区域分公司的，不是中心的，也不是小组可以自己设想的。

登记有三条规则：不确定就写不确定，不补一个看上去合理的口径；被人报出的数与小组自己观察到的数分开，前者记谁说的，后者记样本量、条件和起止的判断方法；第一周不自己从系统里算数，小组算出的平均值一旦被引用，而口径尚未定下，就成了新的误导，必要的探索性计算须保留样本、算法和限制，未经口径确认不得用作业务基线或验收依据。表3-12是合众通信的节选。

表3-12　指标口径登记表0.1版（节选）

小组自己的数同样要登记口径。“约51分钟”不是读秒表读出来的，而是08:12至08:41与08:50至09:12两段之和，其间约9分钟的告警处理已经扣除，不能再次扣除；“约52分钟”是09:48至10:50共62分钟减去约10分钟的中断所得，且仅覆盖本次观察。扣与不扣、怎么扣都是观察者的判断，把推算过程写在表里，别人才能复算，换一种扣法时才知道哪里变了。

“两天”与“52分钟”既不矛盾，也不一致，前者的起止口径待核，后者是本次观察到的动手时间，二者的差额是排队、等待、被别的事打断，还是别的原因，在测量之前谁也说不准，小组要做的是把差额登记为一个问题，而不是急于解释。表里“怎么算”一栏大半是“待核”，这就是下周的工作清单。如果同一个指标有两个口径，并列两行，不替对方选一个，选哪个是指标设计时与结果责任人共同决定的事。

3.6.3　数据流与人工步骤

前言已经列出了合众通信的主要系统和数据，但这份清单只说明“有什么”，没有说明“怎样使用”。同一份告警数据，可能在一个流程中由值班人员直接查看，在另一个流程中被导出后复制，在第三个流程中通过电话口头传递。数据流图要描述的正是这些实际流转方式。绘图时应跟踪一项具体工作，而不是先罗列系统再连线；后者得到的是系统设计图，不是工作路径。小组选择早间核对和复盘材料整理两项已观察到的工作，分别跟踪每一步，并记录六个问题：谁在做、在哪里做、信息如何取得、多久做一次、耗时多少、产出是什么。图3-5展示了这两项工作的数据流。

数据流不能只靠问，人们记不清自己每天复制了几次、切换了几个窗口。主要证据来自现场观察，和人们留下的工作痕迹：为了绕开系统缺口造出的对照表、打印的速查表、专为互相求助而设的群，本身就标出了哪里没有统一的视图。Alice每天另存、文件名带日期的核对表就是这样一件东西。但它是当事人的个人文件，借看之前要征得她同意，并说清看来做什么、看哪些部分、会不会拿给别人；Tom书面确认的观察所得不用于个人考核，覆盖的是观察，不自动覆盖小组对她文件的使用。小组在第五周把这个问题单独提给Alice，她同意后，约定先只看文件的结构和文件名上的日期。

图3-5　早间核对与复盘材料的数据流

3.6.4　学习纪律与常见偏差

第一周的纪律多是前几节规则的延伸：先记对方的话再记自己的话；不懂就问，对方用哪个词就用哪个词追问；分歧不抹平；不确定写“待核”；每天收工前留三十分钟，把新词、新数、新步骤各自写进三份文件，再写一页学习日志，记今天弄懂了什么、仍不懂什么、被谁纠正了什么、明天问谁，第三项把被纠正当作学习的信号，而不是丢脸的事。

不下结论有三条理由：材料太少，到第四周末小组对早间核对和复盘各只有一次观察；写下的结论会被引用，而原来的预设被推翻后最容易发生的是换上另一个预设；对方对事实会补充纠正，对结论只会表态，第一周需要的是前者。

回答基础问题的人最好有时间有耐心，且不处在最敏感的位置，不要把Alice变成全天候的词典，问题攒起来在交接班前后集中问，行业通用的词先自己查。

第一周结束时，小组手里有三份0.1版文件：十四条词条，八条经过当事人核对；七行口径，“怎么算”一栏大半仍是“待核”；八条数据流的边，五条只有一次观察。这些并不多，也谈不上正确，但每一条都有人可以纠正，每一处空白都有人知道要去问谁。术语表将决定下一步范围说明书的措辞，凡业务词在表中都要有一条；口径登记表限定说明书可以引用哪些数，登记为“待核”的口径只能当作待核事项写；数据流图则划出本轮工作触及的对象和步骤。

3.7　范围说明书

到这里，小组手里已有问题陈述0.4版和Tom的认可记录、利益相关方地图、决策清单、假设台账，以及术语表、指标口径登记表和数据流图的0.1版。这些材料各自回答一个问题，没有一份回答“那么这一轮到底做什么”。这是范围说明书（scope statement）要回答的。它不是问题陈述的续篇：问题陈述说明损失在哪里，范围说明书决定其中哪些损失在这一轮里去处理、哪些不处理，并把理由写下来。写下理由不是形式要求：没有理由的“不做”，日后容易被当作疏漏重新塞回需求；没有证据的“要做”，日后容易在验收时被问倒。问题陈述的修订与范围蔓延的区别在于有没有证据，范围说明书就是把这条区别固定在纸面上的地方。证据支持调查和取舍，但不自动产生授权；只有按章程完成认可和批准，建议才成为正式范围。

3.7.1　范围说明书是什么，不是什么

范围说明书写明本轮做什么、不做什么、凭什么、假设什么、在什么条件下重新考虑，由结果责任人认可。它与相邻文件分工明确：交付章程回答谁负责什么、谁拍板、能碰哪些数据，项目开始时就有骨架，只能经变更请求修改；问题陈述回答谁在哪个环节遇到什么损失，随证据修订；指标定义与基线回答“好转”用什么量，在后续章节确定；范围说明书介于其间，在界定阶段定稿，之后经变更。

项目管理里对“范围说明”的常见写法包含产品范围描述、交付物、验收标准、排除项、约束和假设六项，前线部署的一页纸模板更短，只要求有用客户的话写的问题陈述、成功指标、首个切片的范围及一份“不做”清单、例外怎样批准，以及签署。本书的版本有两处调整：每个范围项必须连到证据，每个排除项必须写明理由和重启条件，这是把范围说明书同一份愿望清单区分开的地方；验收标准和成功指标不在这里定，说明书只引用，不预先写数。

有三类内容，说明书不应自己去定或去写。方案细节，如“用大模型做摘要”“建一个检索库”，写进来等于在证据齐全之前替架构做决定，也让范围与方案捆在一起，方案一变范围就要跟着改。技术指标，如准确率、延迟，可以引用，但不在这里定数：评估条件与验收要求应另行定义，待评估与验收标准形成后，再通过文件名和版本引用。对人的评价，说明书会传给不同的人看，里面只能写事、系统和流程。篇幅上，正文一到两页，让Tom能在十分钟里读完并作出反应，证据和细节放进附件；一份十几页的说明书往往把证据和结论混在一起，结果责任人读不完，只好点头，而点头不等于认可。

3.7.2　从证据到范围

整理证据的做法有三条：每一项主张要么连到一条具体的记录，要么明确标成假设；证据有分歧时保留分歧，不为结论整齐而抹平；尚不清楚的事项按“一旦不成立会不会推翻整个计划”排序，先解决推翻力最强的。经过前几节，合众通信有四个候选范围，来历不同，证据的分量也不同。表3-13把它们并排放出，并且特意放入不利和含混的证据，因为一份只讨论支持项的证据表实际上是一份辩护词。

表3-13　从证据到范围的证据链

读这张表有四点要提醒。C1与C2有现场观察支持，但支持得很薄，一个早晨、一个班次、一个人，足以列为本轮候选，不足以声称损失有多大。C3的证据全部来自记忆，且可能不独立，小组把它放进来，是因为Tom把它放在优先次序第一位，这是需要尊重的决定，但记忆不因此成为事实。

C4最容易被误读：“不利”栏里没有一条说明预测做不出来，它们说明的是预测之后由谁行动、误报由谁承担、数据能不能取得这三个问题现在没有答案，没有答案不等于被否定，只等于现在没有依据去做。Alice那句话要原样保留，不替她解释，它可能表示她对预测没兴趣，也可能表示她对眼下的负担有些无奈，一句话分辨不了。

写范围时同样的冲动会换一个形式出现：既然C1、C2有观察支持而C4没有，就写“预测不做”。这与“预测一定要做”是同一种错误，都是用不够的证据下结论。范围说明书要做的是把预测放在它应当在的位置：本轮不做，说明为什么，什么时候可以重新考虑。

3.7.3　范围内与范围外

范围内的项，每一条都要回答五个问题：对应问题陈述里的哪一条，使用者是谁，证据是什么，本轮产出的形态是什么，边界在哪里。产出的形态只写到“使用者能拿到什么”的程度，不写怎样实现。表3-14是合众通信的范围内项。

表3-14　范围内的项（范围说明书0.1版）

S3是条件项：它列在本轮范围内，但只有条件满足后才启动，访问和口径分别由David与Tom按章程批准。条件项处于范围内与范围外之间：它不是承诺，也不是排除，而是“条件满足则实施，条件不满足则暂不实施”。如果告警记录无法取得，小组不能自行改用口径不同的数据拼出替代结果；如需替代数据，应重新论证口径并提交变更。

排除项需要更多纪律。软件设计文档里关于“非目标”的经验很有用：非目标不是目标的否定，“系统不应当出错”不是非目标，因为没有人会把出错当目标；“本轮不做事务一致性”才是，因为一致性本来可以作为目标，只是明确决定不做。所以排除项应当是本来有理由被当作目标、但本轮明确决定不做的事，每项写明为什么可能被当作目标、为什么不做、证据状态和重启条件。排除的理由有三类，对应三种重启方式：证据不足，补上依据可重新考虑；权限不在，这件事不归小组、有时也不归Tom，取得有权者授权才能重新考虑；成本超出本轮，应做但本轮资源不够，排到下一轮。读者一看就知道这个“不做”在等什么：等数据、等授权，还是等排期。表3-15是合众通信的排除项。

表3-15　范围外的项（范围说明书0.1版）

排除不等于否定。表3-13里C4的状态写的是“未验证”，这个词是有意选的。图3-6把从候选到处理结果的过程画在一起，包括重启的回路。排除项里写的重启条件，实际上就是日后变更请求的触发条件：条件一旦满足，小组可以提交变更请求，请Tom重新决定。

图3-6　从候选范围到三种处理结果

3.7.4　假设台账、版本与附件

每个范围项、排除项背后都有尚未验证的前提，假设台账把它们一条一行列出，写明不成立会怎样、怎样核实、由谁负责，并按“不成立时对范围的冲击有多大”排序，推翻力最强的排前面先核实。表3-16是合众通信与范围相关的几条。

表3-16　与范围相关的假设（节选）

“责任人”是核实的责任人，不是被怀疑的人。

排序的含义在于：A1到A3小组自己一两周内就能核实，成本低而不成立的后果大，应最先做；A4和A6要靠别人，等待时间不由小组控制，要尽早提交、尽早约，使等待与前面的核实并行；A5不影响S1、S2，只影响S3的优先理由，但它是Tom的优先次序所依赖的事实，与他的关系最敏感，宜早核对、认真对待。此外还有两条已取得的承诺留在台账里：合同响应时限的文本与解释人可从Emma处取得，观察所得不用于个人考核（Tom书面确认，限中心内部），后者保留不是不信任，而是提醒它的边界不覆盖岗位与编制。每次台账更新，都要同时更新说明书里引用它的地方，否则说明书里的“待核”会比台账里的更陈旧。

说明书的结构有九个条款：版本与状态；问题陈述；范围内的项；范围外的项；约束；假设与待核；成功判据；变更与重启；签署。其中问题陈述、假设和成功判据是对其他文件的引用而不是重写，这样说明书不会与它们不一致。

附件决定说明书能否被核实：问题陈述及认可记录，证据记录清单，假设台账，利益相关方地图（共享版，工作版留在小组内部），决策清单，术语表，指标口径登记表，数据流图。

版本规则：草稿从0.1版起，Tom签署后为1.0版；签署后措辞澄清、把“待核”改成核对结果，末位加1；增加或删除范围项、改变边界、改变排除理由，首位加1并经变更请求。这是本书为教学设计的约定，不是通行规范，读者可按所在组织的惯例调整，只要每次改动都能看出来、大改与小改有区别。

3.7.5　认可、签署与变更

说明书的认可与问题陈述的认可是同一类事，顺序相同：先请当事人核对涉及自己的事实，再当面向结果责任人讲，然后发出书面版本，最后取得答复。不同的是，问题陈述说的是已发生的事，说明书把Tom偏好的预测放在了范围之外，他有理由有不同看法，面谈的准备因此更重要。面谈讲三件事：先讲证据，哪些是看到的，哪些是听说的，哪些没有；再讲小组的建议及依据，为什么把核对和复盘列为本轮范围，为什么把预测放在范围之外；最后讲预测没有被否定，它的重启条件是什么，哪一条取决于Tom自己提供的东西，如去年两次中断的日期，哪一条取决于David的批准。让他先看到证据而不是先看到结论，也看到小组没有绕开他的优先次序，而是把它排成了S3。

Tom可能的答复有三种：接受则签署；接受一部分，如同意S1、S2而要求放宽S3的条件，则按他的意见修订，并把小组的保留意见记入变更记录；不接受，坚持预测放在第一位，则优先级归结果责任人，小组把证据与建议完整留下，说明书按他的决定修订，同时在“假设与待核”里写明小组认为风险最大的几条及核实时间，不表面同意而另有安排，也不淡化已有证据。

签署的含义要写清楚：Tom认可范围内外的项及理由、约束和本轮优先处理的问题，不代表认可具体方案、时间表和指标数值；David认可涉及数据访问与权限的条款，不代表认可业务范围是否合适；小组技术负责人认可范围内的项在本轮可行，不承诺条件项一定启动；Alice、外场班组长、Emma不是签署人，只核对涉及自己工作的事实，不是赞成。签署针对一份有版本号的文件，口头同意不算。

签署之后范围会变，这是正常的：另一个班次观察完，A2成立或不成立；告警记录的访问批下来或没批；班组长谈过，X1、X3的判断要改。变更用变更请求写明改什么、依据什么，以及对目标、周期、成本、风险和访问边界的影响，由章程指定的批准人决定。第2章所说的“收紧可先做”，只适用于为控制风险而紧急暂停或收缩访问，并须按时补记；一般业务范围的缩减仍要按变更分级取得决定，不能由小组自行取消承诺；扩大范围、放宽访问或增加投入，必须先获批准。每个新增的范围项都要有一行证据，没有证据的，不论谁提出，先进入假设台账，不进入范围。

3.7.6　界定门之前的自检与常见缺陷

界定门并非只检查范围说明书。按第2章，问题陈述、范围说明书、指标与现状基线、评估集方案与验收门槛、方案选型与架构决策记录都应齐备，并落实结果责任人的认可、必要的数据入口和访问责任。提交前，应检查范围是否对应问题和证据，证据表是否保留不利或含混材料，排除项是否写明理由与重启条件，关键假设是否有核实安排和责任人，术语和数字是否可追溯，约束是否与章程一致。合众通信目前的说明书仍是未签署的0.1版，尚不能视为已经满足界定门要求。

自检通过不等于没有缺陷，常见的有八类。把方案设想当范围，如“范围：用AI预测基站故障”，应改写为问题陈述中的损失；范围项没有证据，如“提升值班效率”，补证据或降为假设；排除项是目标的反面，如“不做不准确的系统”，应只写本来可以作为目标而本轮决定不做的事；排除项没有重启条件，没有条件的“不做”是一个永远的否定；范围里藏着方案，如“用大模型对工单做摘要”，方案细节应移出；范围太宽，把条件项和排除项都写成“第一期”；假设写成事实，如“外场由中心调度”而无出处；把口头同意当签署。前三类最常见，也最容易被评审忽视，因为文字上读起来都很合理。

到这里，小组把“预测基站故障”收窄成“每日待处理工单与备件、时限核对，加上故障复盘材料提速”，把较长退服的起因构成列为条件项，把预测放在范围之外，并附上理由与重启条件。这个收窄是建议，要经Tom认可，要等另一个班次的观察，要等David对告警记录的答复，但它已是一份可以被检验、被反驳、被修订的文件。后续的指标与基线、评估集与验收门槛、方案选择，都从这些文件出发：每一条都有出处，每一处空白都有人知道要去问谁。

思考

（1）陈述的问题与方案设想

下面三则请求来自虚构的客户。（a）某物流公司的仓库经理说：“用AI预测爆仓日，好提前加人。”（b）某高校教务部门的负责人说：“做一个智能问答机器人，回答学生选课的问题。”（c）某医院的门诊办公室说：“用AI缩短挂号的等待时间。”请分别写出请求里的方案设想；至少三个可以在现场检验的问题，说明各用访谈还是观察来回答；三个问题里应当先检验哪一个，为什么。

（2）访谈提问

下面是一份对账流程访谈提纲中的六个问题：①“您是不是觉得对账太慢了？”②“您希望系统有哪些功能？”③“您平时怎么做对账？”④“上一次对账出错是什么时候？当时怎么发现的？”⑤“如果有一个自动对账的工具，您会用吗？”⑥“是不是所有人都按流程图做？”请分别判断问法类型，指出哪一个最适合作为事件访谈的起点，哪一个可用于了解总体流程但需要继续追问；将其余四个改写为围绕具体经历、措辞中性的问句。

（3）观察记录

一段现场笔记写道：“14:05　前台人员很不耐烦地在三个窗口之间来回切换，显然是系统太难用。14:10　她拿出一本手写的小本子查编号，这说明系统里的编号不可信。14:20　来了一位患者，她先给药房打电话，再录入。”请把这段笔记拆成“所见”和“解释”两栏；为每一条解释写出一个可以用后续观察来反驳它的所见；指出哪些话在这个阶段不应当写进任何结论；再说明在这样的观察中，可以怎样减轻观察者效应，至少两条。

（4）利益相关方地图

某连锁药店计划上线一个库存补货的辅助系统。请列出至少六类相关方，按“会影响项目”“会受项目影响”“与流程直接相关”三种范围标注，指出最容易被漏掉的一类并说明原因；再举一个例子，说明同一个人在不同事项上可以分别是支持者、阻碍者或旁观者，所以地图不能给人只贴一个标签。

（5）责任人与决策权限

FDE小组需要读取客户的一张生产表。项目负责人在会上口头说“可以”，信息部门的负责人第二天回复，涉及生产系统的账号要经过评审，需要先知道身份、对象和期限。请写出发现阶段决策清单中与此相关的两行（决策、拍板人、须咨询、答复期限、说明）；用三句话写出问题陈述认可记录的骨架；并说明为什么项目负责人的“可以”不能代替信息部门的批准。

（6）术语表

对物流公司的访谈中，调度员说“异常件就是丢了和破损的”，客服说“异常件是被客户投诉的件”，财务说“在途是揽收之后、签收之前”，仓管说“在途是离开我们仓库、还没到下一个仓”。请为这四个说法建立词条，标出两处分歧，说明为什么不应在第一周把它们合并，并写出两个可向有权解释的人提出的问题。小组自己常用的技术词“事件”应当怎样处理，才不会让客户的词典被小组的词取代？

（7）指标口径

一份简报写道：“智能客服上线后，工单解决率由71%升至88%，平均处理时长缩短40%。”请按范围、窗口、起止时刻、判定者、来源五类追问，至少写出八个问题，并说明每个问题的答案会怎样改变你对简报的判断；再指出哪些问题第一周就可以问，哪些要到测量基线时才能回答。

（8）数据流

某保险公司的理赔专员每天上午：从理赔系统导出昨日的新案件；把案件号逐个复制到核保系统查保单状态；在自己的一张表里标出“资料不全”的案件；下午给客户打电话补材料；周五把这张表发给主管。观察者看到的上午工作约两小时（一次观察），主管说“这样的统计一周才能出一次”。请画出数据流并标出人工步骤；区分其中的动手时间与经过时间；指出两处在第一周不能下结论的地方；登记两条口径。

（9）范围说明书

某药店补货项目的范围说明书摘录如下。范围：“用AI预测门店缺货，提升顾客满意度。”排除：“不做不准确的预测；不做影响现有系统稳定性的事。”假设：“门店店长都愿意使用。”证据：总部的一份期望文件。签署：“区域经理在会上表示同意”。请对照常见缺陷找出所有问题；把范围项和排除项各改写一条，使之既有证据又有重启条件；再为台账补一条假设，写出它不成立时的影响与核实办法。

（10）综合作业

设本章结束后的第六周，小组获得以下新的记录，仅用于本题，不改变后文。①小组观察了中班：值班主管的核对表只含告警与工单两个系统，不含备件，单次约25分钟，表是按主任要求的模板填的。②David批准了告警记录的访问，范围限于去年六个月，只读，有效期到界定门。③Tom提供了去年两次较长退服的日期，与告警记录核对后，其中一次的起因是传输中断，不是蓄电池。④外场班组长确认夜班只有一路，白班通常有两路。请把范围说明书0.1版修订为下一版，并写出变更记录（改什么，依据什么，影响什么，由谁决定）；逐条判断假设台账中A1至A6的状态变化；判断X1的重启条件离满足更近还是更远，并说明理由。另附不超过800字的说明：哪些改动小组可以先做、哪些必须先经批准，哪一项让小组最为难，为什么。

本章交付物

《范围说明书》模板和合众通信范围说明书0.1版（表3-17），附问题陈述、证据记录、假设台账、利益相关方地图、决策清单、术语表、指标口径登记表、数据流图八类附件。

表3-17是合众通信范围说明书的0.1版，条款对应模板的九个条款。它只记录小组已经取得的证据和已经提出的建议；Tom和David尚未答复的地方留空，不替他们填写；签署栏暂为空。术语表、指标口径登记表和数据流图的节选见前文表3-11、表3-12和图3-5。

表3-17　合众通信范围说明书0.1版（阶段结果）