简介《紧水滩水利发电厂访谈提纲》是一份面向电力生产企业管理咨询场景的标准化访谈提纲适合管理咨询顾问、信息化规划人员及水电企业管理人员参考。提纲围绕企业业务运作与信息化现状设计按信息部门主管、业务部门经理、业务副总及厂长等关键角色设置差异化提问覆盖企业基本信息、业务特点、信息化系统应用、业务流程瓶颈、资产管理系统需求、IT基础设施现状、领导层态度等维度同时包含访谈记录表头与资料收集注意事项有助于系统梳理企业BPR与IT规划需求。文件共1个doc压缩包仅67KB内容结构完整可直接用于现场访谈帮助使用者在咨询调研中快速锁定发电厂运营、信息系统整合、资产管理、数据共享等核心议题避免遗漏关键问题。已有74人学习下载适合在电力行业管理咨询或企业信息化前期调研中作为提问框架使用。1. 紧水滩水利发电厂访谈提纲是先于架构图的关键交付物接到水电厂信息化项目尤其是紧水滩这种投运多年的老厂改造需求分析阶段的第一份交付物往往不是架构图而是《紧水滩水利发电厂访谈提纲.doc》。很多项目组把它当成要问的问题列表实际它同时承担数据地图和需求边界两项职责你问什么业务方就讲什么你记录什么后续设计文档就有什么依据。对做智能水电、生产管理系统、设备资产管理或数据平台的工程师来说把这份提纲当技术文档设计是现场调研能否产出可用结论的分水岭。下面按一套可复现的方法拆解它怎么搭、怎么写、怎么在现场用。2. 水电厂访谈提纲的条线拆解先分清访谈对象再写问题2.1 运行、检修、水工、调度四类对象的访谈目标差异水电厂与火电、风电最大的不同是生产环节由多条专业线共同支撑而不是一条简单流程。紧水滩这类常规水电站通常涉及运行、检修、水工和调度四条主线加上后端的综合管理部门。访谈提纲如果按领导、中层、员工这种级别组织你会发现三拨人聊的是完全不同的系统和界面素材零散到没法归并。运行人员的核心关切是监盘、操作票和交接班记录。他们日常面对计算机监控系统上位机、五防系统和操作票系统访谈应聚焦画面调用频率、报警处理流程、交接班信息流转以及哪些数据至今靠人工抄录。检修人员的核心关切是设备台账、缺陷单和检修计划日常使用设备管理EAM/CMMS系统访谈围绕设备编码规则、缺陷流转路径、备件领用流程展开。水工人员关注水情测报、大坝安全监测和防汛调度访谈重点在监测点布置、采集频度、上报口径。调度人员关注发电计划、闸门操作和通信通道要挖清楚调度指令的接收与执行链路。四个条线的业务语言完全不同问题库不能共用一套模板这是提纲设计的第一原则。2.2 从组织机构图推导提纲章节与责任人清单访谈提纲按系统分章但执行层面必须按人组织。我的做法是先把电厂组织机构图拿到手把每个科室对应到业务系统再把系统映射为提纲章节。组织机构图可以在第一次对接会上请信息中心提供也可以让对方在访谈邀请函里附一张。拿到组织图后的第一件事是列一张清单写清每位访谈对象的岗位、分管系统、建议时长和可能的敏感话题。敏感话题有两类一类是报表重复录入这类现状痛点业务方通常愿意讲另一类涉及岗位考核和个人绩效访谈对象会回避这类信息要靠系统日志验证而不是写进提纲正面提问。老厂还有一层特殊性大量老师傅掌握着不在任何文档里的隐性经验例如某台机组在特定水位下的操作习惯、某段轴瓦温度在特定季节会偏高。提纲里要为这类对象设计两条非正式问题放在章节末尾不占正式提问时间。章节结构建议按系统切监控与自动化、生产管理、设备资产管理、水情与大坝安全、调度通信、网络与信息安全。每个章节下的问题标注此问题问哪个科室避免一场访谈被临时调短就打乱整体计划。2.3 用对象-问题-产出物映射表控制访谈范围控制访谈范围最有效的手段是设计一张三角映射表把访谈对象、提纲章节、期望产出物三者绑定。表格形式如下也可以直接用 python-docx 生成访谈对象涉及系统提纲章节期望产出物验证方式运行值长监控系统、操作票系统监控与自动化常用画面清单、报警分级说明现场录屏抽查检修专工设备管理系统设备资产管理设备编码规则样例、缺陷单样例抽样导出10条缺陷比对水工观测人员大坝监测系统水情与大坝安全测点清单、监测频次表核对监测软件测点树值班主任调度通信调度通信指令收发记录格式打印3份历史记录核对这张表单独放在提纲第一页作用是让电厂信息中心一看就明白你找这些人只问这些事避免临时换人或把范围扩到周边系统。配合这张表我用 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 围绕测点、设备树、告警逻辑的三类核心问题模板水电厂信息化项目的数据基础落在三张结构上测点清单、设备树、告警规则。提纲里的核心问题围绕这三张结构设计因为后续的数据采集方案、接口设计、告警收敛策略都由此决定。测点类问题先确认数量级再确认编码和链路问题维度问题示例期望答案形态测点来源监控系统多少模拟量、多少开关量分开统计过吗数量级即可测点编码测点描述是否带机组号如 1F_上导_瓦温_1有无统一规则编码样例3到5条存储链路数据直接入历史库还是先过预处理有无中间计算量链路描述采集频次不同测点采样周期分别是多少有无秒级数据频次分段表设备树问题面向检修条线重点问设备编码规则、功能位置码、台账字段和变更流程。对紧水滩这类老厂设备编码很可能沿用了早期投运时的习惯在手工台账和电子台账之间反复迁移过编码前缀混乱、重码、报废设备残留都很常见。访谈时不要只听规则描述当场让检修专工导出 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, boldFalse): 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, level0) for chapter in data[chapters]: doc.add_heading(chapter[title], level1) for section in chapter[sections]: doc.add_heading(section[title], level2) para doc.add_paragraph() set_font(para.add_run(section[question_text]), SETTINGS[body_font]) if section.get(table): tbl doc.add_table(rows1, colslen(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台主设备逐字段核对台账完整度统计完整率标注典型缺失字段测点核对表20个测点核对描述、单位、量程找出量程异常点核查修正流程告警清单抽样表近30天告警按类型统计数量占比识别高频告警源评估收敛必要性这三张表必须在访谈现场完成并签字确认。访谈对象在场时确认过的数据比事后邮件补充的可信度高一个等级因为矛盾点可以当场复核。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 提纲版本演进与遗留验证项的处理访谈提纲不会只出一版。初稿发信息中心确认对象与范围评审稿根据反馈补主题现场版按实际进度覆盖未答问题。每一版保留版本号和修订说明不在原文件上覆盖修改。后续做需求追踪时要能回答这个问题是哪一版提纲提出的为什么当初没问这需要版本记录支撑。遗留验证项的处理方式只有三种补一次远程视频访谈、转成接口联调时的验证用例、明确标注为线下无法验证的风险项。不要默认删掉遗留项老厂改造项目的接口边界往往靠这些遗留问题定义。闭环最后一步是把矩阵状态全部置为已确认或已关闭附一页纸的未决事项与风险清单回发给电厂信息中心确认。到这个节点最初那份访谈提纲文件才完成了需求分析阶段的全部职责系统设计文档按矩阵里的设计章节索引展开即可。本文还有配套的精品资源点击获取