Нанимать инженеров или взять технического партнёра: как посчитать оба пути

У вас есть идея торгового терминала, бюджет под неё и нет инженерной команды. Следующий вопрос почти всегда ставится как сравнение цен: сколько стоит нанять инженеров и сколько стоит, чтобы компания построила это и передала вам.

Такая постановка прячет само решение. Оба пути заканчиваются работающим кодом. Различаются они тем, когда появится первая пригодная версия, кто понимает систему через год, что произойдёт при уходе ключевого человека и что у вас в руках, если работа остановится.

Оба пути дают код; различаются они тем, где живёт знание

Торговый терминал — не одна система. Это путь рыночных данных, путь ввода заявок, предторговые риск-проверки, подключение к площадкам или брокерам, состояние позиций и счёта, экран, который обязан перерисовываться, пока движется стакан, и бэк-офис, сверяющий всё это после закрытия.

Когда вы нанимаете, вы покупаете не систему. Вы строите организацию, которая её произведёт, и знание о том, как она работает, стартует с нуля и копится в головах ваших сотрудников. Это актив, пока они остаются, и это весь риск целиком, когда они уходят.

Нанимая партнёра, вы покупаете систему плюс историю решений, которая уже существует в другом месте. Знание стартует выше и в первый же день находится вне вашей компании. Переедет ли оно внутрь — это пункт договора и рабочая практика, а не то, что случается само.

Полезно уточнить, что здесь значит знание о системе, потому что это не исходный код:

• Почему схема нумерации именно такая и какой отказ она отсекает из тех, что простая схема пропускает
• Какие особенности поведения площадки обходит слой подключения и из какого инцидента вырос каждый обход
• В каком порядке идут риск-проверки и что делает система, когда одна из них не отвечает вовремя
• Процедура восстановления, когда в фиде рыночных данных возник пропуск и стакан приходится пересобирать посреди сессии
• Какие тесты несущие, а какие только выглядят как покрытие
• Как выглядит путь выкатки волатильным утром и кому разрешено его запускать

Ничего из этого не лежит в репозитории по умолчанию. Оно живёт в человеке, пока процесс не вынудит записать это, — и неважно, ваш это сотрудник или инженер партнёра.

Срок первой пригодной версии решается до первого коммита

Перед путём найма стоит очередь, которую бюджет не убирает. Вы пишете вакансию, которую сможете защитить технически, ищете на рынке, где торговых инженеров мало, собеседуете по навыкам, которые внутри компании оценить пока некому, ждёте отработки на прежних местах, а потом первое время смотрите, как новая команда спорит об архитектуре, вместо того чтобы её строить.

Путь партнёра начинается с объёма работ, а не с поиска людей, — отсюда и разница во времени. Чего он не убирает, так это работы, которую можете сделать только вы: решить, для чего терминал, какие инструменты и площадки важны первыми и кто первые пользователи.

А часть сроков не принадлежит ни одному из путей. Эти пункты идут своим темпом, кто бы ни писал код:

• Подключение к брокеру или площадке и бумаги, которые за ним стоят
• Сертификационное тестирование в тестовой среде площадки, в окнах, которые назначает площадка, а не вы
• Лицензирование рыночных данных: оно решает, что вам разрешено показывать и кому вы вправе это перераспределять
• Синхронизация часов, аудиторские журналы и тот учёт, которого ждёт ваш регулятор
• Готовность первых пользователей пускать реальные заявки через новую систему
• Ваши собственные продуктовые решения, особенно те два, что противоречат друг другу

Поэтому честное сравнение — не гонка двух дат сдачи. Вопрос в том, какой путь ставит перед работой меньше того, на что вы не влияете, и какой раньше начинает то, на что влияете.

Что делает каждый путь, когда уходит ключевой человек

Задайте обоим путям один и тот же вопрос. Если инженер, написавший обработчик рыночных данных, в понедельник перестанет работать, что будет во вторник и что будет в следующем квартале.

В маленькой нанятой команде ответ обычно упирается в одно имя. Ранние команды концентрируют знание по устройству: один держит горячий путь, другой — подключения, и дорожная карта тихо перестраивается вокруг того, кто ещё на месте. В работе с партнёром всё зависит от того, читал ли там код больше одного инженера и записано ли это в вашем договоре.

Ни одна из конструкций сама по себе не безопасна. Партнёр с единственным инженером на вашем проекте уязвим ровно так же, как внутренняя команда из двух человек, и защита в обоих случаях одна: знание записывается по ходу того, как оно появляется, а не восстанавливается задним числом.

• Проектная записка на каждую подсистему: что она делает, что сознательно отказывается делать и что её ломает
• Записи решений с рассмотренными альтернативами, лежащие в репозитории рядом с кодом, который они объясняют
• Тесты, проигрывающие записанную сессию, чтобы отказ воспроизводился точно, а не обсуждался
• Минимум два человека, влившие изменения в каждый критичный путь, — это правило о составе команды, а не о документации
• Runbook на каждый реально случившийся инцидент, написанный на той же неделе
• Путь выкатки и отката, который любой дежурный инженер проходит сам, не поднимая никого ради пароля

Передача — результат с приёмочным тестом, а не письмо в конце

Слово «передача» покрывает два совершенно разных события. Одно — передача файлов. Другое — передача способности продолжать без тех, кто это построил, и платить стоит только за второе.

Впишите второе в объём работ списком артефактов, к каждому из которых приложен приёмочный тест. Разумный список выглядит так:

• Репозитории со всей историей, а не архив финального состояния: рассуждения живут в истории
• Сборка, которую новый инженер повторяет на чистой машине по написанным шагам, без недокументированной локальной настройки
• Инфраструктура, описанная кодом, вместе со средами, которые из неё получаются, и их отличиями друг от друга
• Секреты держите вы, и процедура их ротации хотя бы раз выполнена, а не описана
• Runbook'и выкатки и отката, которые прогоняет ваша сторона, пока партнёр смотрит и молчит
• Мониторинг, пороги алертов и по одной строке на алерт: что он значит и что с ним делать
• Спецификации протоколов и сообщений на каждое внешнее подключение, включая поля, которые вы используете, и те, что игнорируете
• Набор тестов и демонстрация того, как они специально падают, чтобы вы видели, что именно они ловят
• Названный срок, в который изменения вносят ваши инженеры, а партнёр только ревьюит их

Передача, которую ни разу не репетировали, — это план, а не результат. Репетируйте её в середине разработки, а не после последнего счёта, и репетиция проста: ваши инженеры выкатывают изменение и откатывают его, а те, кто писал систему, смотрят.

Владение — вопрос, отдельный от передачи, и решается он в договоре до начала работы, а не выясняется в конце. Наш собственный ответ — одно предложение, и мы не сокращаем его ни в одной версии ни одного документа.

Между двумя ответами стоят три формата

Вопрос обычно ставится как выбор из двух: нанять команду или отдать всё целиком на сторону. На практике большинство проектов стоит между этими полюсами, и позиции разрешено меняться по мере взросления системы.

Три формата: полная разработка, выделенная команда или инженеры внутри вашей команды. Так мы описываем свою сторону, и разница между тремя не в счёте, а в том, кто держит план, кто держит приоритеты и кто отвечает за результат.

• Полная разработка: партнёр держит план, порядок работ и результат; вы держите продуктовые решения и приёмку. Подходит первой версии с объёмом, который вы можете описать, когда команды для управления ещё нет
• Выделенная команда: ваш бэклог и ваши приоритеты, их люди работают над вашим продуктом и ничем больше. Подходит стадии, где объём работ меняется быстрее, чем терпит фиксированный план
• Инженеры внутри вашей команды: ваш процесс, ваше код-ревью, их специалисты на путях, где ошибка дорога, — путь заявки, подключение к площадке, процедура восстановления
• Эти три — скорее ступени, чем взаимоисключающие варианты. Проект может начаться как полная разработка и закончиться двумя инженерами внутри команды, которую вы наняли, пока систему писали

Этот последний пункт снимает большую часть исходного вопроса. Сильная версия партнёрского пути с самого начала планирует вашу собственную команду: вы нанимаете под уже существующую систему, ваши собеседования опираются на код, который кандидат будет поддерживать, а первое, что читает новый сотрудник, — запись решения, а не пустой репозиторий.

Посчитайте оба пути, включая то, что не попадает в счёт

Сравнение ставок — наименее полезная цифра в этом решении: два пути выставляют счёт в разных единицах. Положите оба списка рядом и посчитайте честно.

Путь найма берёт с вас:

• Время на подбор и цену одного неверного найма на узком рынке, где неверный наём обнаруживается поздно
• Расходы работодателя, оборудование, лицензии и подписки на рыночные данные, которые нужны среде разработки ещё до того, как она что-то произведёт
• Внимание руководителя: командой кто-то должен управлять, и в начале этот кто-то обычно вы
• Первое архитектурное решение, принятое дважды, один раз неверно, — обычная цена того, что команда осваивает предметную область на вашей стройке
• Мощность, которая переживает саму разработку: команда, набранная под стройку, больше, чем требует поддержка
• Постоянное обязательство, которое действует независимо от того, ясна ли дорожная карта в этом квартале

Путь партнёра берёт с вас:

• Ставку, в которую заложены специалисты, которых вы сами никогда не загрузили бы на полный день, — например, инженер, уже отлаживавший протокол уровня сессии
• Координацию через границу — это реальная работа, и платят за неё написанными спецификациями, а не разговорами в коридоре
• Зависимость, которая длится ровно столько, сколько передача остаётся непроверенной
• Риск того, что переиспользуемые компоненты несут нагрузку так, как никто не записал, — поэтому пункт о владении читается до подписи
• Стоимость постановки задач: партнёр точен ровно настолько, насколько точны решения, которые вы ему передали

Затем посчитайте выходы: они есть у обоих путей. Путь найма заканчивается сокращением команды, которую вы собрали, и знание уходит в этих головах. Путь партнёра заканчивается передачей, которую вы либо репетировали, либо нет, и расстояние между этими двумя финалами и есть риск пути.

Прежде чем что-то подписывать, прогоните оба варианта через один вопрос: если это остановится в пятницу, что у нас останется в руках в понедельник. Отвечайте артефактами — репозитории, воспроизводимые среды, документация и люди, способные собрать систему заново по ним, — потому что намерения ухода человека не переживают, а артефакты переживают.

Что amBrain может подтвердить публично: мы пишем софт с 2019 года из Еревана, Армения, горячие пути — на Rust; мы построили торговый терминал Spectre Trade, а построенная нами мини-биржа работает в проде на колокации MOEX. Если вы взвешиваете наём против партнёра ради собственного терминала, возьмите список передачи выше в первый же разговор и попросите того, кто сидит напротив, нас в том числе, ответить по нему построчно.