水电厂信息化访谈提纲设计：从结构化编写到现场执行

简介：《紧水滩水利发电厂访谈提纲》是一份面向电力生产企业管理咨询场景的标准化访谈提纲，适合管理咨询顾问、信息化规划人员及水电企业管理人员参考。提纲围绕企业业务运作与信息化现状设计，按信息部门主管、业务部门经理、业务副总及厂长等关键角色设置差异化提问，覆盖企业基本信息、业务特点、信息化系统应用、业务流程瓶颈、资产管理系统需求、IT基础设施现状、领导层态度等维度，同时包含访谈记录表头与资料收集注意事项，有助于系统梳理企业BPR与IT规划需求。文件共1个doc，压缩包仅67KB，内容结构完整，可直接用于现场访谈，帮助使用者在咨询调研中快速锁定发电厂运营、信息系统整合、资产管理、数据共享等核心议题，避免遗漏关键问题。已有74人学习下载，适合在电力行业管理咨询或企业信息化前期调研中作为提问框架使用。

1. 紧水滩水利发电厂访谈提纲，是先于架构图的关键交付物

接到水电厂信息化项目，尤其是紧水滩这种投运多年的老厂改造，需求分析阶段的第一份交付物往往不是架构图，而是《紧水滩水利发电厂访谈提纲.doc》。很多项目组把它当成"要问的问题列表"，实际它同时承担数据地图和需求边界两项职责：你问什么，业务方就讲什么；你记录什么，后续设计文档就有什么依据。对做智能水电、生产管理系统、设备资产管理或数据平台的工程师来说，把这份提纲当技术文档设计，是现场调研能否产出可用结论的分水岭。下面按一套可复现的方法拆解它怎么搭、怎么写、怎么在现场用。

2. 水电厂访谈提纲的条线拆解：先分清访谈对象，再写问题

2.1 运行、检修、水工、调度四类对象的访谈目标差异

水电厂与火电、风电最大的不同，是生产环节由多条专业线共同支撑，而不是一条简单流程。紧水滩这类常规水电站通常涉及运行、检修、水工和调度四条主线，加上后端的综合管理部门。访谈提纲如果按"领导、中层、员工"这种级别组织，你会发现三拨人聊的是完全不同的系统和界面，素材零散到没法归并。

运行人员的核心关切是监盘、操作票和交接班记录。他们日常面对计算机监控系统（上位机）、五防系统和操作票系统，访谈应聚焦画面调用频率、报警处理流程、交接班信息流转，以及哪些数据至今靠人工抄录。检修人员的核心关切是设备台账、缺陷单和检修计划，日常使用设备管理（EAM/CMMS）系统，访谈围绕设备编码规则、缺陷流转路径、备件领用流程展开。水工人员关注水情测报、大坝安全监测和防汛调度，访谈重点在监测点布置、采集频度、上报口径。调度人员关注发电计划、闸门操作和通信通道，要挖清楚调度指令的接收与执行链路。四个条线的业务语言完全不同，问题库不能共用一套模板，这是提纲设计的第一原则。

2.2 从组织机构图推导提纲章节与责任人清单

访谈提纲按系统分章，但执行层面必须按"人"组织。我的做法是先把电厂组织机构图拿到手，把每个科室对应到业务系统，再把系统映射为提纲章节。组织机构图可以在第一次对接会上请信息中心提供，也可以让对方在访谈邀请函里附一张。

拿到组织图后的第一件事是列一张清单，写清每位访谈对象的岗位、分管系统、建议时长和可能的敏感话题。敏感话题有两类：一类是报表重复录入这类现状痛点，业务方通常愿意讲；另一类涉及岗位考核和个人绩效，访谈对象会回避，这类信息要靠系统日志验证，而不是写进提纲正面提问。

老厂还有一层特殊性：大量老师傅掌握着不在任何文档里的隐性经验，例如某台机组在特定水位下的操作习惯、某段轴瓦温度在特定季节会偏高。提纲里要为这类对象设计两条"非正式问题"，放在章节末尾，不占正式提问时间。章节结构建议按系统切：监控与自动化、生产管理、设备资产管理、水情与大坝安全、调度通信、网络与信息安全。每个章节下的问题标注"此问题问哪个科室"，避免一场访谈被临时调短就打乱整体计划。

2.3 用对象-问题-产出物映射表控制访谈范围

控制访谈范围最有效的手段是设计一张三角映射表，把访谈对象、提纲章节、期望产出物三者绑定。表格形式如下，也可以直接用 python-docx 生成：

这张表单独放在提纲第一页，作用是让电厂信息中心一看就明白"你找这些人只问这些事"，避免临时换人或把范围扩到周边系统。配合这张表，我用 Python 维护一份结构化映射，便于后续需求追踪时直接复用：

# 访谈章节元数据：对象、问题、产出物三者绑定 interview_sections = { "monitor_auto": { "title": "监控与自动化", "audience": ["运行值长", "自动化班", "保护班"], "questions": ["常用画面清单", "报警分级规则", "遥控遥调操作链路"], "deliverables": ["画面清单", "报警分级表", "断面接线图"], # 访谈结束逐项打勾 "verify_method": "现场录屏抽查" }, "asset_mgmt": { "title": "设备资产管理", "audience": ["检修专工", "物资管理员"], "questions": ["设备编码规则", "缺陷流转路径", "备件编码与库存"], "deliverables": ["编码规则说明", "缺陷单样例", "备件清单"], "verify_method": "抽样导出比对" } }

代码的意图不是实现某个系统，而是把提纲元数据变成结构化数据，方便增删改并自动生成文档。audience对应 2.2 节的组织条线，deliverables在访谈结束时逐项打勾。如果一个访谈单元的交付物连续三项拿不到，说明问题设计或对象选择有偏差，要当场调整，而不是等全部访谈结束再补救。

注意：verify_method字段必须保留。水电行业的业务现状和系统配置往往有半年到两年的滞后期，口头承诺的流程和系统实际配置不一致很常见；没有验证方式的产出物，写进需求文档后必然返工。

3. 访谈提纲的问题设计：把提纲写成可复用的数据采集蓝图

3.1 封闭题与开放题的配比：漏斗式问题树

访谈提纲最常见的失败形态是通篇开放题。开放题适合探索未知领域，但水电厂信息化调研要采集的是确定的信息结构：测点、设备、告警、报表、权限、接口。全开放题的记录会变成散文，信息密度低，整理成本高；全封闭题则会让问题表膨胀到几十页，访谈对象失去耐心。

我一般用漏斗式问题树：每个主题先放一两个开放题，用于发现计划外内容；再进入一组结构化问题，把答案落到对象、字段、频次、数量级；最后用确认型问题复述结论。三者的比例约 2:6:2。比如监控系统主题的第一个问题设计成"打开上位机画面，哪些页面是你每班必看的"，比直接问"你们系统里有多少画面"更能触发真实信息。开放题控制在每个主题两个以内，任务是触发场景而不是记录完整答案，完整答案由结构化问题部分负责。

3.2 围绕测点、设备树、告警逻辑的三类核心问题模板

水电厂信息化项目的数据基础落在三张结构上：测点清单、设备树、告警规则。提纲里的核心问题围绕这三张结构设计，因为后续的数据采集方案、接口设计、告警收敛策略都由此决定。

测点类问题先确认数量级，再确认编码和链路：

设备树问题面向检修条线，重点问设备编码规则、功能位置码、台账字段和变更流程。对紧水滩这类老厂，设备编码很可能沿用了早期投运时的习惯，在手工台账和电子台账之间反复迁移过，编码前缀混乱、重码、报废设备残留都很常见。访谈时不要只听规则描述，当场让检修专工导出 100 条台账记录做抽样，判断离散程度，再请他解释离散原因。

告警类问题要区分告警产生、分级、处置三个环节。水电厂告警来源包括监控系统光字牌上送、在线监测越限告警、水情防汛告警和安防入侵告警。对每个来源都要问清谁负责确认、确认时限、哪些告警联动启停机、哪些只记录。这些信息直接决定告警平台的数据接入优先级，是最容易被忽略的部分。

3.3 用 python-docx 批量生成格式统一的 .doc 提纲

问题模板确定后，剩下的工作是把它变成一份格式规范的 Word 文档。手工复制粘贴几十页内容，效率低且格式易失控，改版时更是灾难。常见做法是用 python-docx 写生成脚本，问题库放独立数据文件，改版只动数据，重新跑脚本即可。下面是一段可用的生成脚本：

# -*- coding: utf-8 -*- from docx import Document from docx.shared import Pt from docx.oxml.ns import qn DOC_TITLE = "紧水滩水利发电厂访谈提纲" SETTINGS = { "chapter_font": 16, # 一级标题字号 "body_font": 12, # 正文字号 "table_style": "Table Grid", # 表格必须显式加边框 "east_asia_font": "仿宋_GB2312", # 中文字体，适配电厂办公环境 } def set_font(run, size, bold=False): run.font.size = Pt(size) run.bold = bold run.font.name = "Times New Roman" run._element.rPr.rFonts.set(qn('w:eastAsia'), SETTINGS["east_asia_font"]) def build_outline(doc, data): doc.add_heading(DOC_TITLE, level=0) for chapter in data["chapters"]: doc.add_heading(chapter["title"], level=1) for section in chapter["sections"]: doc.add_heading(section["title"], level=2) para = doc.add_paragraph() set_font(para.add_run(section["question_text"]), SETTINGS["body_font"]) if section.get("table"): tbl = doc.add_table(rows=1, cols=len(section["table"]["headers"])) tbl.style = SETTINGS["table_style"] for i, h in enumerate(section["table"]["headers"]): tbl.rows[0].cells[i].text = h for row in section["table"]["rows"]: cells = tbl.add_row().cells for j, val in enumerate(row): cells[j].text = str(val) doc.save(f"{DOC_TITLE} v1.0.doc")

脚本里set_font单独封装字号与字体的设置，其中w:eastAsia的用途是显式指定中文字体。水电厂办公环境普遍使用旧版本 Word 或 WPS，只设置run.font.name会造成中文行距异常，所以我通常用仿宋_GB2312 配 Times New Roman 的英文字体方案，与电厂公文环境一致。doc.add_table生成的是无边框表格，必须显式指定table_style为Table Grid，否则打印出来看不出边界。建议把保存文件名里的版本号抽成变量，访谈提纲至少会经历初稿、评审稿、现场版三轮修改，每次都覆盖原文件会丢失修订痕迹。

提示：python-docx 写出的文件本质是 OOXML 格式，保存为 .doc 后缀在 Word 中可正常打开，但个别 WPS 旧版本会提示兼容性检查，可在交付说明里注明"请用 Word 或新版本 WPS 打开"。

4. 水电厂访谈提纲的现场执行：时间盒、追问与附表核对

4.1 时间盒与访谈记录的结构化

提纲发出去之后的第二个失控点是现场。预定的 90 分钟访谈被拉长到 3 小时，或开场后被对方运维故障带偏，核心问题只覆盖一半，这是最常见的两种现场事故。我的处理是给每个访谈单元设置时间盒，并把时间盒直接写进提纲页眉，让访谈对象进场前就知道总时长。

时间盒不按问题数量平均分配，而按期望产出物的价值分配。以监控系统单元为例，总时长 90 分钟时：前 15 分钟破冰与开放题，中间 50 分钟处理测点、告警、权限三组结构化问题，接着 20 分钟请对方打开上位机实机演示画面和报警处置流程，最后 5 分钟复盘确认。演示环节必须录屏，因为口头描述的界面与真实界面往往有差异，录屏是还原真实业务链路最可靠的证据。

访谈记录不要现场写流水账，而是预先在提纲里给每个问题留一个四行表格，行字段为"对方原话引用""我的理解""数据佐证来源""待验证事项"。这要求访谈前就把表格画好，回到驻地整理纪要时只需逐格誊抄，不需要重听录音。

4.2 追问的四个方向：数据流向、异常场景、组织边界、历史包袱

现场提问容易停留在"描述现状"层面，这对需求分析帮助有限。我一般把追问固定到四个方向。数据流向追问，是问完"告警怎么产生"之后紧接着问"确认后信息往哪去"，把对话从功能延伸到数据终点；异常场景追问，是请对方描述最近一次缺陷处理的全过程，而不是让对方总结流程；组织边界追问，是问清楚这个数据谁维护、那个操作哪个岗位执行、出现争议谁拍板；历史包袱追问，是针对老厂遗留系统，问旧系统为什么停用、数据迁没迁、还有谁依赖旧系统的某个功能。

这四个方向不是四个独立问题，而是穿插在每条结构化问题之后的追问策略。我会在打印版提纲的问题旁用铅笔标注"追数据""追异常""追边界""追历史"四个词，现场按实际回答选路线。

4.3 现场核对：提纲附录里必须预留的三张核对表

提纲附录要预留三类核对表，这是把访谈内容从"业务描述"变成"可设计参数"的关键动作。第一张是设备台账抽样表：请对方引导进入设备管理界面，随机抽五台主设备，核对铭牌参数、安装位置、投运日期、关联备件编号的完整度。第二张是测点核对表：进监控系统数据库浏览功能，抽查二十个测点的描述、单位、量程上下限，重点找量程为零或配置明显错误的测点。第三张是告警清单抽样表：请对方导出最近一个月的告警历史，按类型统计数量，识别高频告警源。

这三张表必须在访谈现场完成并签字确认。访谈对象在场时确认过的数据，比事后邮件补充的可信度高一个等级，因为矛盾点可以当场复核。

5. 访谈提纲的后半程：产出物校验与需求追踪闭环

5.1 把访谈记录翻译成需求追踪矩阵

访谈结束后的第一件事，是把映射表里的 deliverables 逐项归档，再把访谈记录按问题树拆成独立的"需求事实单元"。每个事实单元至少包含四个字段：数据来源（哪场访谈、谁说的）、业务规则原文、可验证的证据、对应需求编号。追踪矩阵用表格维护即可，列设置为"访谈对象 / 原始记录位置 / 需求描述 / 对应设计章节 / 验证手段 / 状态"，每行绑定一个可独立交付的设计点。矩阵的价值在于把问题库、访谈记录、需求文档三层的对应关系显式化，任何一条需求都能回溯到现场谈话。

# 追踪矩阵行：一条需求事实单元 trace_rows = [ { "interview_ref": "R2_值长_14:20", # 精确到对象和时段 "raw_note": "监盘画面共27个，12个每班必看", "requirement": "监控画面按岗位定制，默认加载必看画面", "design_ref": "画面配置模块 3.2", "verify": "上线后按岗位抽查默认画面", "status": "已确认" }, { "interview_ref": "R4_检修专工_16:05", "raw_note": "设备编码前缀三套并存，新系统需统一", "requirement": "设备编码迁移支持多前缀映射", "design_ref": "编码映射表 4.1", "verify": "迁移脚本比对抽样10条", "status": "待验证" } ]

interview_ref必须精确到对象和时段。需求评审出现争议时，设计人员凭这个字段能翻回原始记录核对原话，而不是反复争论。矩阵状态从"待验证"到"已确认"的过程，本身就是需求质量的检查清单。

5.2 提纲版本演进与遗留验证项的处理

访谈提纲不会只出一版。初稿发信息中心确认对象与范围，评审稿根据反馈补主题，现场版按实际进度覆盖未答问题。每一版保留版本号和修订说明，不在原文件上覆盖修改。后续做需求追踪时要能回答"这个问题是哪一版提纲提出的，为什么当初没问"，这需要版本记录支撑。遗留验证项的处理方式只有三种：补一次远程视频访谈、转成接口联调时的验证用例、明确标注为线下无法验证的风险项。不要默认删掉遗留项，老厂改造项目的接口边界往往靠这些遗留问题定义。闭环最后一步是把矩阵状态全部置为"已确认"或"已关闭"，附一页纸的未决事项与风险清单回发给电厂信息中心确认。到这个节点，最初那份访谈提纲文件才完成了需求分析阶段的全部职责，系统设计文档按矩阵里的设计章节索引展开即可。

本文还有配套的精品资源，点击获取