客户递来一份需求书,和一条死线
某电力企业售电事业部发来一份《业务需求说明书——电力基础数据库》。诉求不复杂,但非常典型,几乎是所有数据平台项目的共同起点:
- 六大类业务数据要统一管理:基础结算类、交易实时类(负荷与价格曲线)、市场信息类、辅助数据类、业务知识库,以及和财务风控的衔接数据
- 数据质量要可控:异常能发现、问题能订正、订正必须留痕、历史数据不可删
- 跨部门要能用:财务对账、运维取数、报表分析,都要从同一份数据出发
难点不在需求本身,而在时间:客户希望三个工作日内看到一场可以当面演示的系统——不是概念片,不是效果图,而是能点、能查、能问的真系统。
这类项目我们做过不少,经验是:能不能按期交付一场有说服力的演示,取决于第一天做对了什么,而不是第三天加了多少班。
第一步不是写代码,是把需求拆开
接手当天,我们做的第一件事是把需求书拆成 40 多个需求点,逐条判断它们属于哪一类:
| 需求类型 | 典型内容 | 交付方式 |
|---|---|---|
| 平台开箱即用 | 多源数据接入、元数据管理、数据字典、质量规则引擎、权限体系、报表分析 | 底座直接覆盖,零开发 |
| 配置即可用 | 质量规则(唯一性 / 完整性 / 及时性 / 一致性 / 关联性 / 准确性六类都有配置界面)、数据服务发布、定时调度 | 按客户业务配置,无需写代码 |
| 必须按业务定制 | 业务级订正工作流、业务知识库、曲线对比分析 | 定制开发——也正是客户日常真正会用的部分 |
逐条映射后的结论很清楚:通用底座能力已经覆盖客户需求中约四到五成,剩下要投入人力的是「业务语义层」——也就是客户业务人员每天会点、会看、会问的那些界面和流程。
这个判断决定了三天的资源投放:底座不重复造,把全部精力押在客户真正看得见的业务环节上。如果顺序反过来、先写代码再对需求,三个工作日只够做出一个「看起来像」的东西。
让演示「像真的」:我们故意埋了问题
演示有没有说服力,八成取决于数据像不像真实业务。我们按电力业务的真实结构,梳理出 25 张业务数据表——覆盖零售用户、合同、结算明细、负荷曲线、现货价格、场站、分省月度结算、业务指数,以及订正留痕、财务对账、风控、知识库、跨部门交互等专项数据,一共生产了 31.6 万行业务数据。
但真正让演示活起来的,是接下来的两个「反常规」动作:
- ① 刻意埋入问题数据:248 份合同里埋了 2 条编号重复;现货价格的 33 个月历史里,埋了 232 个时段缺失、约 10.4 万条超期入库。没有这些问题,数据质量模块在演示里就无戏可演——而质量管控恰恰是客户需求书里的重点条款。
- ② 预置业务闭环样例:8 条订正记录(含订正人、订正前后值、订正原因)、67 条对账差异、60 条跨部门交互日志——让「留痕」「对账」「审计」这些需求书关键词,在系统里都有真实可点的数据。
一句话总结这条经验:干净的演示数据没有故事。每一条被刻意设计的问题数据,都对应需求书里的一条管控要求,这样演示时才不是「展示功能」,而是「回应你的关切」。
把平台调成客户的语言
系统跑起来只是及格线。接下来的一系列调整,全部围绕一个问题:客户在演示现场看到的每一眼,是否都在替他自己的业务说话?
① 质量规则讲「电力话」。通用规则引擎配置成三条电力业务规则后,质量概览页从一份技术报表,变成了一份业务体检报告:
| 级别 | 规则 | 客户听得懂的后果 |
|---|---|---|
| 高 | 现货出清价格完整性核查 | 缺失时段无法结算 |
| 中 | 现货价格及时性核查(T+30) | 超期入库,属于流程问题 |
| 低 | 零售合同编号唯一性核查 | 编号重复会导致结算关联到错误合同 |
② 菜单按客户的心智顺序重排。把功能目录调整成客户理解业务的顺序:元数据管理 → 数据标准 → 数据质量 → 数据集成 → 数据加工 → 数据资产 → 数据应用 → 数据市场 → 系统监控 → 运维管理。讲解逻辑和菜单顺序一致,客户才不会「迷路」。
③ 界面净化与细节修补。补齐图标、隐藏与客户无关的页面元素。都是小事,但它们共同决定客户的第一印象:这是一个给企业用的正式系统,还是一个工程师的实验台。
45 分钟演示动线:客户在现场看到什么
45 分钟的演示窗口,客户领导的注意力不会全程在线,动线必须提前设计好——前半程抓注意力,中段放互动,结尾收价值。我们反复推敲后排定的流程是:
| 环节 | 时长 | 客户看到什么 |
|---|---|---|
| 登录与总览 | 3 分钟 | 系统可用、界面干净,不是半成品 |
| 资产盘点 | 10 分钟 | 元数据、数据地图:「我们的数据资产第一次被看清了」 |
| 质量体检 | 8 分钟 | 质量概览:三类异常数字,对应需求书的质量管控条款 |
| 质量闭环 | 8 分钟 | 高潮环节:现场点击执行质量任务,数字当场刷新 |
| 集成与消费 | 8 分钟 | 订正留痕、数据对外服务:「发现问题到解决问题」的完整闭环 |
| 智能问数互动 | 5 分钟 | 客户用大白话自由提问,系统自动取数、直接出图 |
| 价值总结与答疑 | 3 分钟 | 回到需求书,逐条对应今天看到的画面,现场答疑 |
整场演示的高潮,是质量任务的现场执行:点一下「执行」,规则立即跑一遍数据,回到概览页,异常数字按最新一轮刷新。「配置规则 → 自动巡检 → 生成报告」这件事,在 3 分钟内被客户亲眼看到了。没有什么比现场跑通更能说明系统是真的。
另一个记忆点是智能问数:客户可以直接用大白话提问,比如「分省月度结算金额是多少」,系统自动理解、自动取数、直接出图。这一环节在演示现场几乎必然引发提问,也是客户停留最久的地方。
演示当天:数字对上了需求书
演示当天的实际效果,比预期更顺:
- 12 个功能目录全部正常渲染,菜单顺序与讲解逻辑一致,全程没有卡壳
- 质量概览的三类异常(232 个缺失时段 / 2 条重复编号 / 约 10.4 万条超期)直接对应需求书「数据质量管控」条目——客户当场对照自己的需求书在看
- 现场执行质量任务成功,数字按最新一轮刷新
- 智能问数环节自然语言出图,客户的提问在这里最集中
客户最关心的三个问题,也都在演示前备好了答案:
| 客户的问题 | 我们的回答要点 |
|---|---|
| 这个数据规模能撑生产吗? | 演示是演示量级;平台架构支持横向扩容,数据库可替换为企业级方案,性能随规模平滑扩展 |
| 怎么和我们现有的交易、财务系统对接? | 数据集成支持多种数据源接入方式,配置即可用,不改造客户现有系统 |
| 业务模块全部做完还要多久? | 底座已验证;业务模块按每个 3-5 个工作日的节奏叠加,可以按优先级分批上线 |
三条可复用的经验
- ① 需求映射先行,开发放在最后。40 多个需求点逐条判断「用底座、靠配置、还是必须定制」,才敢把三天全部投在业务语义层。先对需求再动手,是快的前提而不是慢的原因。
- ② Demo 的灵魂是「设计过的脏」。合同编号重复、价格时段缺失、超期入库——每一条都对应需求书里的一条管控要求。演示的价值不是「功能很多」,而是「你要的每一条,我都已经替你想到了」。
- ③ 迭代以「客户视角」为单位,不以技术为单位。图标补齐、菜单重排、界面净化,每一件都是小事,但它们共同回答一个问题:客户在 45 分钟里每一眼看到的东西,是否都在替你说话?
这套打法适用于所有「底座能力趋同、业务理解决定成败」的行业——电力、燃气、水务、金融风控、能源集团,都可以直接迁移。
本文要点
- 客户诉求:六大类业务数据统一管理 + 质量可控可留痕 + 跨部门可用,窗口三个工作日
- 第一步是把 40 多个需求点逐条拆解:底座开箱覆盖约四到五成,其余集中投入业务语义层
- 演示数据的秘诀是「设计过的脏」:31.6 万行数据里刻意埋入 2 条重复编号、232 个缺失时段、约 10.4 万条超期
- 质量规则全部翻译成业务语言(编号重复会导致结算关联错合同)
- 45 分钟演示动线,高潮是质量任务现场执行、数字当场刷新
- 智能问数支持自然语言提问直接出图,是现场提问最集中的环节
- 业务模块后续按每个 3-5 个工作日的节奏分批叠加,底座已验证
微信内识别二维码分享此文