第二章：团队架构设计

做市团队的架构，说白了就是把人、钱、系统这三样东西拧在一起。我见过不少团队，技术牛人一堆，交易员也个个是高手，但就是赚不到钱。为什么？因为架构没搭好，各干各的，互相扯皮。

这一章，我就把做市团队的组织结构、关键岗位、规模层级这些事，掰开了讲清楚。

2.1 核心组织结构：三线并行的铁三角

我个人习惯把做市团队分成三条线：交易线、风控线、技术线。这三条线互相独立，又必须紧密配合。运营线则作为支撑，贯穿其中。

你想想看，交易员负责赚钱，风控负责踩刹车，技术负责造车。如果让交易员管风控，那等于让司机自己踩油门又踩刹车，早晚出事。我在项目中遇到过一家小团队，交易总监兼着风控总监，结果一次行情剧烈波动，他为了追回亏损，硬是让系统继续开单，最后爆仓了。嗯，这就是架构设计的问题。

下面这张图，是我常用的团队架构模型：

2.2 关键岗位设置

每个岗位都有它的核心职责。我挑几个重点说说。

2.2.1 交易员：做市的核心引擎

交易员不是简单的下单员。一个好的做市交易员，要懂市场微观结构，懂订单簿的博弈，还要懂自己的策略在什么情况下会失效。

• 做市交易员：负责日常报价、管理库存、执行策略。我见过最优秀的交易员，能在盘口看到别人看不到的流动性暗流。
• 量化研究员：负责策略研发、回测、因子挖掘。注意，研究员和交易员之间要有沟通机制，否则策略再好，落地也是一团糟。

2.2.2 风控：团队的刹车系统

风控不是来阻碍交易的，是来保护团队的。一个没有风控的做市团队，就像没有刹车的跑车，跑得快，死得也快。

• 风控经理：制定风控规则、设置限额、监控实时风险敞口。我建议风控经理要有独立向CEO汇报的权限。
• 合规专员：负责交易所规则合规、监管报送、反洗钱等。这块容易被忽视，但一旦出事就是大事。

2.2.3 技术团队：造车的人

做市系统对延迟和稳定性要求极高。技术团队的水平，直接决定了你的策略能不能跑在别人前面。

• 系统架构师：负责整体系统设计、技术选型、性能优化。这个人要懂交易，不能只懂技术。
• 开发工程师：负责策略实现、API对接、数据管道。我建议至少要有C++和Python两套技能栈的人。
• 运维/DevOps：负责服务器部署、监控告警、灾备演练。做市系统7x24小时运行，运维是最后一道防线。

2.2.4 运营团队：后勤保障

运营团队负责资金管理、对账、结算、交易所关系维护等。虽然不直接参与交易，但少了他们，团队转不起来。

2.3 团队规模与层级规划

团队规模不是越大越好。我见过5个人的小团队，一年赚了3000万；也见过50人的大团队，还在亏钱。关键是匹配你的业务规模。

团队阶段	规模	关键岗位	月交易量参考
初创期	3-5人	交易员（兼研究员）、开发（兼运维）、风控（兼运营）	< 1亿美元
成长期	8-15人	交易员2-3人、研究员1-2人、开发3-5人、风控1人、运营1人	1-10亿美元
成熟期	20-40人	各岗位独立，增加量化平台组、算法交易组、高级风控	10-100亿美元

层级方面，我建议扁平化。做市团队不需要太多管理层级，否则决策太慢。一般就三层：

• 执行层：交易员、开发、风控专员，负责具体工作。
• 管理层：各线负责人，负责策略方向、资源协调。
• 决策层：CEO或管理合伙人，负责战略、资金分配、重大风控决策。

2.4 团队协作机制

架构搭好了，还得有协作机制。否则各干各的，还是白搭。

• 每日晨会：15分钟，交易员汇报市场情况，风控通报风险事件，技术同步系统状态。
• 每周策略评审：研究员和交易员一起复盘策略表现，讨论优化方向。
• 月度风控审计：风控线独立出具报告，直接提交给决策层。

嗯，这里要注意一点：晨会不要开成批斗会。我见过一个团队，晨会上交易员和风控互相指责，最后变成了吵架会。后来我建议他们改成「数据驱动」的会议形式——只看数据，不针对人，效果好了很多。

团队架构这件事，没有标准答案。但有一条铁律：交易、风控、技术三条线必须独立，互相制衡。你想想看，如果让交易员自己管风控，那跟让小偷管钥匙有什么区别？

好了，这一章就讲到这里。记住，架构设计是为业务服务的，别为了架构而架构。小团队就简单点，大团队再细化，别一开始就搞得太复杂。

---