15、结构化产品做市团队建设：交易员、量化研究员、开发工程师、风控人员的协作模式
做结构化产品，说白了不是一个人的战斗。
我见过太多团队，交易员觉得自己是老大，研究员觉得模型最牛，开发觉得代码就是一切，风控觉得所有人都在瞎搞。结果呢？产品上线第一天就出问题，或者明明能赚钱的策略，因为沟通不畅错过了窗口期。
今天我就聊聊，一个成熟的结构化产品做市团队，到底该怎么搭。我自己的经验是，团队里这四类人——交易员、量化研究员、开发工程师、风控人员——必须像齿轮一样咬合，而不是各自为政。
15.1 团队角色与核心职责
先明确每个人是干嘛的。别觉得这步多余，我见过不少团队，干了半年才发现，原来大家理解的“做市”根本不是一回事。
| 角色 | 核心职责 | 典型产出 |
|---|---|---|
| 交易员 | 管理做市簿、执行对冲、监控实时风险敞口 | 报价单、对冲指令、日内PnL报告 |
| 量化研究员 | 设计定价模型、开发对冲策略、回测验证 | 定价公式、参数校准脚本、回测报告 |
| 开发工程师 | 搭建交易系统、实现自动化报价、维护数据管道 | 做市引擎、API接口、实时监控面板 |
| 风控人员 | 设定风险限额、监控异常、压力测试 | 风控规则、限额表、压力测试报告 |
嗯，这里要注意：交易员和研究员之间，最容易打架。交易员觉得研究员给的模型太理论化，研究员觉得交易员不按模型来。我自己的经验是，让研究员每周跟交易员一起盯盘半天，很多矛盾自然就化解了。
15.2 协作模式：从“串联”到“并联”
很多团队是串联模式：交易员提需求 → 研究员建模 → 开发写代码 → 风控审核。这种模式效率极低，一个环节卡住，全队停工。
我建议改成并联模式。说白了，就是所有角色从项目第一天就一起参与。
关键原则：任何决策，至少涉及两个角色。交易员不能单独改报价参数，研究员不能单独上线新模型，开发不能单独改系统逻辑。必须有人复核。
举个例子。我们团队要上线一个新结构产品——比如一个挂钩中证500的雪球产品。流程是这样的：
- 立项会（全员参与）：交易员讲市场环境，研究员讲定价逻辑，开发评估系统改动量，风控提限额要求。半小时内，大家对齐目标。
- 并行开发：研究员写定价模型，开发搭报价接口，交易员准备对冲工具，风控同步设定监控指标。每天下午4点，站会15分钟。
- 集成测试：研究员把模型给开发，开发嵌入系统。交易员用历史数据跑模拟报价，风控盯着风险指标。发现问题，当场改。
- 上线监控：交易员盯盘，研究员看模型表现，开发保障系统稳定，风控实时报警。前三天，全员在岗。
这种模式，我试过很多次。最大的好处是：问题在早期就暴露了，而不是等到上线前才发现。
15.3 沟通机制：别让信息死在邮件里
我最怕一种情况：交易员在邮件里写了个需求，研究员三天后才看到，回复说“这个做不了”。一来一回，一周过去了。
所以，我团队里强制要求：
- 每日站会：15分钟，每人说三件事——昨天做了什么、今天要做什么、有什么卡点。不解决具体问题，只同步信息。
- 共享看板：用Jira或者Trello，所有任务公开。交易员可以看到研究员在做什么，开发也能看到风控的审核进度。
- 即时通讯群：建一个全员群，但只发关键信息。比如“模型参数已更新，请交易员确认”、“风控限额已调整，请开发更新系统”。
我的一个小技巧：每周五下午，搞一个“复盘会”。不聊具体项目，就聊协作中哪里不爽。比如“开发觉得交易员需求变太快”、“风控觉得研究员模型文档写太烂”。这种会，刚开始大家不好意思说，但坚持几周后，效率提升非常明显。
15.4 冲突处理：谁说了算？
团队里一定有冲突。最常见的是：交易员想扩大报价价差，风控不同意。研究员想上线新模型，开发说系统不支持。
我的原则是：谁承担后果，谁有最终决定权。
比如报价价差的问题，最终亏钱的是交易员，所以交易员有决定权。但风控可以设置硬性上限——比如最大敞口不能超过500万。研究员想上线新模型，开发说需要两周，那交易员来决定：是等两周，还是先用旧模型顶着。
我曾经遇到过一个情况：研究员开发了一个非常复杂的波动率曲面模型，理论上能提高定价精度。但开发评估后说，系统改造需要一个月。交易员当时面临一个马上要报价的大单，直接说：“先用手动调整参数顶着，模型慢慢改。” 你看，这就是典型的“谁承担后果，谁说了算”。
注意：这种模式的前提是，每个人都清楚自己的职责边界。如果交易员越权去改风控参数，或者研究员绕过开发直接在生产环境跑代码，那就不是冲突，是事故了。
15.5 知识共享：别让经验只存在一个人脑子里
结构化产品做市，很多经验是隐性的。比如某个交易员知道，在特定市场环境下，某个对冲参数要手动调整。但万一他请假了呢？
我要求团队做三件事：
- 文档化：所有模型、策略、操作流程，必须有文档。不要求多精美，但必须能让人看懂。我自己的习惯是，每次上线新功能，写一个“傻瓜式操作指南”。
- 轮岗：每季度，交易员和研究员互换角色一周。交易员去跑模型，研究员去盯盘。虽然效率会下降，但长期看，团队整体能力提升很大。
- 代码评审：开发工程师的代码，必须经过至少一个人评审。研究员写的模型脚本也一样。我曾经因为一个研究员在代码里写死了某个参数，导致回测结果全错。从那以后，代码评审就成了硬性要求。
15.6 工具与系统：协作的“硬基础设施”
光有流程和沟通还不够，得有工具支撑。我团队目前用的工具链是这样的：
| 用途 | 工具 | 说明 |
|---|---|---|
| 代码管理 | Git + GitLab | 所有模型代码、交易脚本、风控规则，都放在同一个仓库里。分支管理，上线前必须合并到主分支。 |
| 数据共享 | 共享数据库 + API | 行情数据、交易数据、风控数据，统一存储。研究员通过API取数据，开发直接读库，交易员看面板。 |
| 监控面板 | Grafana + 自研 | 实时显示报价、敞口、PnL、风险指标。交易员和风控各有一个定制面板。 |
| 沟通协作 | Slack + Jira | Slack用于日常沟通，Jira用于任务跟踪。所有决策，必须在Jira上留下记录。 |
嗯，这里要特别说一下监控面板。我见过很多团队，交易员看一个系统，风控看另一个系统，研究员自己写脚本看数据。信息不同步，很容易出问题。我建议，至少核心指标——比如当前敞口、希腊值、盈亏——必须所有人看到的是同一个数字。
15.7 知识体系框架图
下面这张图，是我自己总结的团队协作核心逻辑。你可以把它当成一个“协作地图”，看看你们团队现在处于哪个阶段。
这张图的核心思想是：四个角色通过协作机制（站会、看板、评审等）连接在一起，最终输出稳定的报价和可控的风险。没有哪个角色是孤岛。
15.8 避坑指南
最后，分享几个我踩过的坑：
- 别让交易员直接改代码：我曾经有个交易员，觉得自己懂Python，直接在生产环境改了报价参数。结果改错了一个小数点，亏了十几万。从那以后，生产环境只有开发能碰。
- 风控不能形同虚设：有些团队，风控就是走个过场。我见过最离谱的，风控限额设了1000万，但交易员实际敞口到了3000万，风控居然没发现。风控系统必须自动化，人工盯是盯不住的。
- 研究员别活在象牙塔里：我有个研究员，模型做得特别漂亮，但完全没考虑交易成本。结果回测年化20%，实盘一跑，手续费吃掉一半。从那以后，我要求所有回测必须包含交易成本、滑点、冲击成本。
- 开发别只关注技术：开发工程师最容易犯的错，就是追求代码优雅，忽略了业务需求。我经常跟开发说：“你写的每一行代码，最终都是为了帮交易员赚钱或者帮风控控制风险。如果做不到，代码再漂亮也没用。”
好了，关于团队协作，我就说这么多。说白了，结构化产品做市，拼的不是某一个人的能力，而是整个团队能不能像一台精密的机器一样运转。交易员、研究员、开发、风控，缺一不可。每个人都要清楚自己的位置，也要理解别人的难处。
嗯，希望这些经验对你有用。