银行的需求文档,为什么总在返工

我带项目那会儿，有过这样一个晚上。

屏幕上一条流程跑不通，改一版，跑一遍，再改一版。抬头看时间，过了两点。

那天夜里我挺忙的。可回家路上越想越不对劲：这一晚上到底解决了什么？走不通的地方还搁在那儿，我只是把它从报错的样子，改成了不报错的样子。

说出来挺难为情——那会儿我还觉得自己挺能扛。

后来我一直在想：那些夜里补的窟窿，是不是白天就该问清楚？

🌙 我以为的加班：多干一会儿，问题就少一个

🌙 实际的加班：白天没问清的事，夜里一个一个冒出来

📄 以为写清楚了：需求文档签了字

📄 实际写着：「按业务规则处理」——谁都不知道该怎么处理

❌ 以前我的顺序：拿到需求 → 直接写功能 → 评审签字 → 测试追着问 → 夜里返工

✅ 后来我的顺序：划系统边界 → 看系统分层 → 拆需求对象 → 落成清单

接一个项目，我先不谈功能，先划边界：这次到底动了哪几个系统。可能一个，可能五六个。划出来，逐个问。

它在架构里站什么位置。 是直接面对客户的渠道，还是对接外部的中间业务前置，还是跨行清算的支付，还是最底下记账的核心。位置不同，能干的事完全不同。

当年建它是为了解决什么问题。 有的银行把交易和核算拆开，有的把核心做瘦、客户信息和账户信息单独管。看着虚，却决定了需求能做到哪一步。

跟谁说话，怎么说。 综合柜面、网银、手机银行这些渠道在前头接客户，后头都调核心系统；实时交易一问一答，不着急的攒成一批走文件。

里头分几块，每块管到哪为止。 核心里有存款、贷款，支付里有大额、小额、清算。

这一条最容易被跳过。举个例子：核心的贷款业务只管贷后，还是连贷前审批一起管？没问清楚，开发就按自己的理解做，测试跑起来才发现流程对不上，返工的是一整条线。

系统不是铁疙瘩，它自己也分层。

应用这一层，是干业务的地方。 拿核心来说，存款、贷款这些模块，加上一堆不上台面的活：批量走文件作业，日切、跑批前后的任务，给下游系统供数。平时没人提，上线前一天全冒出来。

业务这一层是人打交道的地方。 拿柜面来说，装着运营管理、客户管理、存款、贷后、支付、中间业务。它看得见，最容易被业务方盯上。

参数这一层，最容易被低估。 柜面有运营参数，核心有产品、计价、费用，支付有转账限额、行名行号、手续费、运营时间。我见过需求做得漂亮、上线前参数没配、业务跑不起来的。参数不是配置，它是业务规则落到系统里的那一层。

这一步才是大家理解里的「需求分析」，但它其实有六个对象，功能只是其中一个。

应用功能。 模块拆清楚了，针对每个功能单元往下细。

交互接口。 绑在第三方上，人家给什么格式你才能设计什么，顺手把涉及的功能单元列出来。

日终批量。 银行项目最容易翻车的一块。计提、结息有日期依赖——该付的利息得按日子算出来挂在账上，不能提前也不能拖；批量划账、批量还款得避开高峰。哪些能夜里跑、谁先谁后，排错了第二天开门就是事故。

交互文件。 大批量异步作业基本走文件，代发工资就是典型，得梳清跟谁换、换什么格式。

数据同步。 有些数据多个系统都要用，就在本系统存一份，原系统一变这边跟着变。同步哪些表、实时还是异步、日间还是夜间，先定下来。

数据迁移。 上新系统就得接住老系统的功能。业务差在哪，数据就差在哪。

前面三步得落成能传下去、能验收的单子。六类对象一人一张，功能那块分交易和功能两张，一共七张：

《XX系统交易清单》——面向客户、前端能操作的所有交易。

《XX系统业务功能清单》——每个功能模块该具备哪些功能。

《XX系统对外接口清单》——提供给各个交互系统的接口。

《XX系统日终批量任务清单》——日终批处理要跑的任务。

《XX系统对外交互文件清单》——跟相关系统交换的文件内容。

《XX系统同步外部系统数据清单》——需要同步、或者提供给别人同步的数据表。

《XX系统数据迁移业务差异清单》——新系统比老系统多了什么、少了什么。

七张单子出来，评审会上「按业务规则处理」这句话基本不会再出现了。不是文字功夫变好了，是该回答的问题前面都回答过了。

现在我拿到一个需求，第一件事不是问「怎么做」，是问「它在哪」。这个习惯是被那些两点钟的晚上改出来的。

至于那些夜算不算解决问题，我到现在也说不好。只知道同样的坑，不想再掉第二次。

各项目实施情况不同，请结合自身项目参考。

扫码交个朋友

加群管微信 银行业知识交流群

用香沁智语 银行业知识问答

— END —