第二章 项目启动与需求分析：业务痛点识别、监管合规需求梳理、项目可行性评估
说实话，很多RegTech项目死在第一步。
不是技术不行，不是团队不强。而是需求没搞清楚就开干。我见过太多团队，上来就画架构图、写代码，结果做到一半发现——嗯？业务部门要的根本不是这个？
所以这一章，咱们聊聊项目启动阶段最关键的三个动作：痛点识别、合规需求梳理、可行性评估。这三件事做扎实了，项目就成功了一半。
2.1 业务痛点识别：别被表象骗了
业务部门来找你，通常会说：「我们报表太多，做不完。」或者「监管检查太频繁，应付不过来。」
但你得往深了挖。痛点背后往往藏着更本质的问题。
核心原则：痛点不是「痛」，而是「成本」。
我习惯用三个维度去拆解业务痛点：
- 时间成本：做这件事花了多少人力？多少工时？
- 风险成本：做错了会怎样？罚款？声誉损失？
- 机会成本：如果不用做这件事，团队能干什么更有价值的事？
举个例子。我在某银行做反洗钱项目时，业务部门说「交易监控误报率太高，每天几百条告警，处理不过来。」
表面看是误报问题。但深挖后发现——真正痛的是合规人员流失率高达40%。为什么？因为每天处理大量无效告警，工作枯燥，没人愿意干。
所以我们的解决方案不是单纯降误报，而是重新设计告警处理流程，把人工处理量降下来，同时提升岗位价值感。
我的经验：痛点识别阶段，一定要和业务一线聊。别只跟领导聊。一线人员说的才是真话。
2.2 监管合规需求梳理：别自己瞎猜
这块最容易踩坑。
很多团队拿到监管文件，自己翻译、自己理解、自己设计功能。结果做出来，监管不认。
为什么？因为监管条文和落地执行之间，有巨大的鸿沟。
我建议的做法是三步走：
- 原文拆解：把监管文件逐条拆开，每条对应一个合规要求。
- 映射到业务：每个要求对应到具体的业务流程、数据字段、系统功能。
- 确认优先级：哪些是「必须做」？哪些是「建议做」？哪些是「未来可能做」？
举个例子，银保监会的《银行保险机构数据安全管理办法》里有一条：「应建立数据分类分级制度。」
这条看起来简单。但落地时你会发现——
- 数据怎么分类？按业务线？按数据类型？
- 分级标准是什么？谁定？
- 分类分级后，系统怎么落地？权限怎么控制？
我曾经在一个项目中，光「数据分类分级」这个需求，就和合规部开了六次会。每次都有新发现。
注意：别试图「超越」监管要求。合规项目的第一目标是「达标」，不是「创新」。创新是锦上添花，不是雪中送炭。
2.3 项目可行性评估：别拍脑袋
痛点清楚了，需求也梳理了。接下来就是——这事能不能干？
我一般从四个维度评估：
| 维度 | 关键问题 | 我的判断标准 |
|---|---|---|
| 技术可行性 | 现有系统能支撑吗？需要哪些新技术？ | 80%用现有技术，20%需要攻关 |
| 数据可行性 | 数据在哪？质量如何？能拿到吗？ | 数据可用率低于60%，建议先做数据治理 |
| 组织可行性 | 业务部门配合吗？有专人对接吗？ | 没有业务方全职投入，项目风险极高 |
| 时间可行性 | 监管给了多少时间？内部排期能匹配吗？ | 时间少于预估的70%，建议分阶段交付 |
这里我想多说一句数据可行性。很多RegTech项目死就死在数据上。
你以为数据在A系统，结果在B系统。你以为数据是结构化的，结果是一堆PDF。你以为数据质量还行，结果一查，缺失率30%。
所以我的习惯是——在可行性评估阶段，先做一次数据摸底。哪怕只是抽样，也比完全不知道强。
避坑指南：我曾经做过一个项目，业务方说「数据都有，直接能用」。结果一查，数据在三个不同系统里，字段定义都不一样。光数据对齐就花了两个月。所以，别信「数据都有」这句话。
2.4 核心逻辑：一张图说清楚
说了这么多，其实整个项目启动与需求分析的逻辑，可以用下面这张图概括：
这张图我每次做项目启动时都会画一遍。说白了，就是三个步骤串起来，形成一个闭环。
痛点识别是起点，合规需求是核心，可行性评估是过滤器。三者缺一不可。
2.5 实战中的几个小技巧
最后分享几个我在实战中总结的小技巧：
- 需求文档别写太长：超过50页没人看。核心内容控制在10页以内，附录放详细内容。
- 一定要有「不做什么」清单：明确告诉业务方，哪些需求这次不做。避免后期扯皮。
- 可行性评估要留余量：技术评估说3个月，实际可能要5个月。监管项目容不得延期。
- 合规需求要签字确认：让合规部门在需求文档上签字。这不是推卸责任，而是明确责任边界。
一句话总结：项目启动阶段，花80%的时间把需求搞清楚，花20%的时间写代码。顺序别搞反了。