自招工程师还是找技术伙伴：两条路各自怎么算账

你有一个交易终端的想法，有预算，没有工程团队。接下来的问题几乎总是被摆成一次价格比较：招工程师要花多少，找一家公司把东西做出来再交付过来又要花多少。

这样提问，反而把真正的决定藏了起来。两条路最后都会得到能跑的代码。区别在于：第一个可用版本什么时候出现、一年之后谁懂这套系统、关键的人离开时会发生什么，以及工作停下时你手里握着什么。

两条路都产出代码，区别在于知识住在哪里

交易终端不是一个系统。它是一条行情路径、一条下单路径、交易前风控检查、到交易场所或经纪商的连接、持仓与账户状态、一块在账本变动时必须持续重绘的界面，以及收盘后把这一切对上账的后台。

当你选择招人，你买的并不是那套系统。你是在建造将来生产它的那个组织，而关于它如何运作的知识从零开始，积累在你雇来的人的脑袋里。人在，这是资产；人不在，这就是全部风险。

当你签下一家伙伴，你买的是一套系统，外加一份已经存在于别处的决策历史。知识的起点更高，但第一天它坐在你公司之外。它会不会挪到公司里来，取决于合同条款和日常做法，不会自己发生。

这里说的「系统的知识」具体指什么，值得讲清楚，因为它不是源代码：

• 序号方案为什么是现在这个样子，以及它挡住了哪种更简单方案会放过的故障
• 连接层绕开了交易场所的哪些行为，以及每个绕法是从哪一次故障里长出来的
• 各项风控检查的执行顺序，以及其中一项没能及时给出答复时系统怎么做
• 行情源出现缺口、账本必须在交易时段中途重建时的恢复流程
• 哪些测试是承重的，哪些只是看起来像覆盖率
• 行情剧烈的早晨，部署路径是什么样的，以及谁有权执行它

这些东西默认都不住在代码仓库里。在某个流程逼着它落到纸面之前，它住在一个人身上——不管这个人是你的员工，还是伙伴那边的工程师。

第一个可用版本，在第一次提交之前就已经被决定了

自招这条路前面排着一条队，预算并不能把它消掉。你要写出一份自己在技术上站得住的岗位描述，在交易工程师稀缺的市场里找人，面试一些公司内部还没人能评估的技能，熬过离职通知期，然后在最初一段时间里看着一支新团队争论架构，而不是搭建架构。

伙伴这条路的起点是定范围而不是找人，时间上的差别就是从这里来的。它消不掉的，是只有你才能做的工作：决定这个终端是干什么用的、哪些合约和交易场所要先做，以及第一批用户是谁。

还有一部分工期不属于任何一条路。不管代码由谁来写，下面这些事都按自己的节奏走：

• 经纪商或交易场所的接入手续，以及压在它背后的那些文书
• 在交易场所的测试环境里做一致性测试，窗口由交易场所来排，不由你排
• 行情数据的授权，它决定你被允许展示什么，以及可以转发给谁
• 时钟同步、审计留痕，以及你的监管方要求的各种记录保存
• 第一批用户愿不愿意把真实订单交给一套全新的系统去路由
• 你自己的产品决策，尤其是互相矛盾的那两个

所以诚实的比较不是两个交付日期之间的赛跑。它要问的是：哪条路在工作前面摆的、你无法左右的事情更少，以及哪条路更早开始你能左右的那部分。

关键的人离开时，两条路各自会怎样

对两条路问同一个问题。写行情处理器的那个工程师周一不干了，周二会怎样，之后的那个季度又会怎样。

在你自己招来的小团队里，答案通常取决于某一个人的名字。早期团队天然会把知识集中：一个人负责热路径，另一个人负责连接，路线图则悄悄围着还在的人重新排列。在与伙伴合作的安排里，答案取决于那边是不是不止一个工程师读过代码，以及你的合同里有没有这么写。

两种结构本身都不安全。伙伴那边只安排一个工程师负责你的项目，风险敞口与一个两人内部团队完全一样，而两种情况下的防御手段也完全相同：知识在产生的当下就写下来，而不是事后再拼回去。

• 每个子系统一份设计说明，写清它做什么、它刻意不做什么、什么会让它崩
• 决策记录要写上当时考虑过的其他方案，并放在仓库里，紧挨着它所解释的代码
• 能回放录制会话的测试，让故障被精确复现，而不是被拿来争论
• 每条关键路径上，至少有两个人合并过变更——这是人员配置的规则，不是文档的规则
• 每一次真实发生过的故障都有一份处置手册，在它发生的那一周就写好
• 任何值班工程师都能自己跑通的部署与回滚路径，不必为了一个密码把人叫醒

交接是一件带验收测试的交付物，不是最后发的一封邮件

「交接」这个词盖住了两件很不一样的事。一件是文件的转移。另一件是能力的转移——在没有原班人马的情况下继续走下去的能力，而只有第二件值得花钱买。

把第二件事写进项目范围，写成一份实物清单，每一项都附一个验收测试。一份合理的清单大致是这样：

• 带完整历史的代码仓库，而不是最终状态的一份打包——理由都在历史里
• 新来的工程师照着写下来的步骤，就能在一台干净机器上复现出来的构建，不含任何未写进文档的本地配置
• 以代码描述的基础设施，连同它生成的各个环境，以及这些环境之间的差异
• 密钥由你保管，并配一套至少真正执行过一次的轮换流程，而不是只写在纸上
• 部署与回滚的处置手册，由你这边来执行，伙伴在旁边看着、一句话不说
• 监控、告警阈值，以及每条告警一行说明：它意味着什么、该怎么处理
• 每一条对外连接的协议与报文规格，包括你用到的字段和你忽略的字段
• 测试套件，外加一次故意让测试失败的演示，好让你看清它们能抓住什么
• 一段写明起止的时期：由你的工程师来改，伙伴只做评审

从未演练过的交接是一份计划，不是一件交付物。演练要放在开发中途，而不是最后一张发票之后；演练本身很简单：让你的工程师部署一次变更再回滚，写这套系统的人在旁边看着。

所有权和交接是两个问题，它在开工之前就写进合同定下来，而不是到最后才发现。我们自己的答案就是一句话，而且在任何文档的任何版本里，我们都不把它缩短。

两个答案之间还夹着三种形式

这个问题通常被提成非此即彼——要么自己招一支团队，要么把整件事交给别人。实际上多数项目都落在两极之间，而且随着系统成熟，位置是允许移动的。

三种形式：全包交付、专属团队，或把工程师嵌入你的团队。我们自己这一侧就是这么描述的，而三者之间的区别不在发票——在于计划由谁握着、优先级由谁握着、结果由谁负责。

• 全包交付：计划、先后次序和结果由伙伴握着；产品决策和验收由你握着。它适合范围能定清楚、又还没有团队可管的第一个版本
• 专属团队：你的待办、你的优先级，他们的人只做你的产品，不做别的。它适合范围变动快过固定计划所能承受的那个阶段
• 把工程师嵌入你的团队：你的流程、你的代码评审，他们的专才放在出错代价高的路径上——下单路径、场所连接、恢复流程
• 这三种是台阶，而不是互斥的选项。一个项目可以以全包交付起步，最后落成两名工程师待在你于开发期间招起来的团队里

最后这一点，把最初的问题化掉了大半。伙伴这条路最好的走法，是从一开始就为你自己的团队做打算：你是对着一套已经存在的系统去招人，面试问什么由候选人将来要维护的代码来决定，而新人读到的第一份东西是决策记录，不是一个空仓库。

两条路都要算账，包括永远不会出现在发票上的部分

在这个决定里，费率对比是最没用的数字，因为两条路的计价单位根本不同。把两份清单并排放好，老老实实各算一遍账。

自招这条路向你收取的是：

• 招聘所花的时间，以及在一个专才市场里招错一个人的代价——招错这件事往往很晚才被发现
• 雇主成本、设备、许可证，以及开发环境在产出任何东西之前就需要的行情订阅
• 管理精力——总得有人带这个团队，而一开始那个人通常是你
• 第一个架构决定要做两次，其中一次是错的——这是一个团队拿你的项目学习这个领域的正常代价
• 比开发期活得更久的人力：按建设规模配的团队，比维护所需要的更大
• 一项长期义务：不管这个季度的路线图清不清楚，它都在继续

伙伴这条路向你收取的是：

• 费率里含着你自己养不满工时的专才，比如调试过会话层协议的工程师
• 跨边界的协同，这是实打实的工作，付出的形式是书面规格，而不是走廊里的对话
• 一种依赖：交接一天没被验证过，它就持续一天
• 可复用组件以没人写下来的方式承重的风险——这正是所有权条款必须在签字前读一遍的原因
• 写规格的成本：伙伴做得多准，取决于你交出去的决定有多准

然后把退出也算进账，因为两条路都有退出。自招这条路的收尾是裁减你亲手建起来的团队，知识装在那些脑袋里一起走掉。伙伴这条路的收尾是一次交接，演练过或者没演练过，而这两种结局之间的距离，就是这条路的风险。

签字之前，把两个选项都放进同一个问题里过一遍：如果这件事周五停了，周一我们手里还剩什么。答案要用实物来回答——代码仓库、可复现的环境、文档，以及能凭这些把系统重建起来的人——因为意愿撑不过一次离职，实物可以。

amBrain 可以公开证实的内容：我们自 2019 年起在亚美尼亚埃里温做软件，热路径用 Rust 编写；我们构建了 Spectre Trade 交易终端；我们构建的一个迷你交易所在 MOEX 托管机房的生产环境中运行。如果你正在为自己的终端权衡自招还是找伙伴，把上面那份交接清单带进第一次谈话，让坐在对面的人——也包括我们——逐条回答。