Выделенная команда, которая остаётся: как проверить подрядчика до подписания и как оставить код своим

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

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

Почему команды разработки исчезают посреди проекта?

«Исчезновение» — обычно одно из четырёх рядовых деловых событий: ничего драматичного, и всё предсказуемо.

• Экономика загрузки. Компания по разработке зарабатывает, пока её инженеры оплачиваются клиентом, поэтому с приходом контракта покрупнее естественным донором становится самый маленький проект. Писем об этом не рассылают — на еженедельном созвоне просто появляется новое лицо
• Зависимость от одного клиента. Часть подрядчиков получает большую часть выручки от одного-двух клиентов. Если такой клиент уходит, компания сжимается, а вместе с ней и ваш проект; если остаётся — двигают именно ваш проект, когда приоритеты сталкиваются
• Риск незаменимого человека. Один инженер понимает ту часть, которую трудно заменить, и проект начинает от него зависеть без чьего-либо решения. Потом он увольняется, и поставка встаёт на квартал, пока остальные читают недокументированный код
• Цепочки субподряда. Компания, с которой вы подписали договор, не всегда та, что пишет код. Субподряд нормален и законен; проблемой он становится, когда о нём не сказали, потому что ваши условия действуют ровно настолько, насколько их переносят договоры ниже

«Надёжность» не выясняется снаружи: она складывается из условий договора и фактов о составе команды, которые вы запросили. Любой из описанных выше сбоев переживаем, если работа задокументирована, а репозитории — ваши.

Где найти выделенную команду разработки, которая не исчезнет посреди проекта?

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

Дальше выясните, что коммерческое предложение понимает под «выделенной командой», потому что у фразы два значения:

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

Спросить про эту разницу ничего не стоит, и ничто лучше не предсказывает, окажется ли команда на двенадцатый месяц той же, что и на первый.

О чём просить до подписания?

Просите факты, а не заверения. Четыре держат основной вес; остальные — в чек-листе ниже.

• Имена и стаж. Кто работает над вашим продуктом, в какой роли, какую долю своей недели и штатные это сотрудники или внештатные исполнители
• На кого они работают ещё. Сколько других проектов тянет каждый названный инженер в этом квартале и не приходится ли на одного клиента большая часть выручки компании
• Bus-фактор. Сколько человек должно уйти, чтобы работа встала. Один — это не команда, это план провала
• Отрепетированная передача. Договоритесь, что в неё входит, и проверьте её в середине проекта, а не после последнего счёта; список артефактов — в предыдущей статье этого блога, о том, как считать наём против партнёра

Один вопрос весит больше остальных: что будет с моим проектом, если ваш крупнейший клиент уйдёт в следующем месяце? Подрядчик, который об этом думал, отвечает составом команды и структурой выручки; тот, кто не думал, отвечает, что этого не случится.

Хочу сохранить полное владение кодом. Как это на самом деле устроено в договоре?

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

Британское ведомство по интеллектуальной собственности (UK Intellectual Property Office) формулирует правило по умолчанию прямо: «Когда вы просите или заказываете другому лицу или организации создать для вас объект авторского права, первым законным обладателем авторского права является лицо или организация, создавшие произведение, а не вы как заказчик, если вы письменно не договорились об ином». Оплата счёта авторское право не передаёт.

«Работа по найму» (work made for hire) — понятие более узкое, чем звучит. Бюро авторского права США называет две ситуации: произведение, которое работник создаёт в рамках своих обычных обязанностей, и произведение, специально заказанное по прямо выраженному письменному соглашению. У второй четыре условия, и выполниться должны все; первое — что произведение «должно относиться к одной из девяти перечисленных выше категорий произведений, которые могут быть специально заказаны или поручены в качестве произведений, созданных по найму». Заказного программного обеспечения среди этих девяти нет, и Бюро добавляет: «Если произведение не удовлетворяет какому-либо из этих требований, оно не является произведением, созданным по найму». Оговорка, называющая вашу платформу произведением, созданным по найму, подписанная с компанией, которая не является вашим работодателем, может не давать ровно ничего.

Работает отчуждение исключительного права — письменное и подписанное. Закон США об авторском праве говорит об этом прямо: «Передача права собственности на авторское право, иначе как в силу закона, недействительна, если документ о передаче либо записка или меморандум о такой передаче не составлены в письменной форме и не подписаны обладателем передаваемых прав или его надлежащим образом уполномоченным представителем». Подрядчик может передать только то, чем владеет, поэтому его договоры с сотрудниками, внештатными исполнителями и субподрядчиками должны сначала передать эти права ему. Просите показать эту цепочку. Правила различаются по странам, поэтому формулировку пусть подтвердит юрист. При отчуждении код ваш: его можно дорабатывать, продавать вместе с бизнесом и передавать другому подрядчику; при лицензии — нет.

В любой настоящей системе есть и код, который подрядчик не писал. Просите перечень компонентов ПО (software bill of materials, SBOM) — Агентство по кибербезопасности и защите инфраструктуры США (CISA) описывает его как «вложенную опись, список ингредиентов, из которых состоят компоненты программного обеспечения». По каждому компоненту: название, версия, лицензия и что эта лицензия требует, когда вы поставляете или продаёте продукт.

Большинство инженерных компаний переиспользуют собственные библиотеки, и большинство оговорок о владении выводит эти библиотеки из-под передачи прав. Такое исключение (carve-out) нормально; безграничное — нет, потому что оно способно сделать вашу систему несобираемой без подрядчика. Ограничьте его до подписания:

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

Договор эскроу исходного кода (source code escrow) — трёхсторонняя конструкция между заказчиком ПО, подрядчиком и эскроу-провайдером: подрядчик депонирует исходный код и материалы сборки, а вам их раскрывают при наступлении согласованного события. Стандартные события раскрытия — банкротство, внешнее управление и нарушение обязательств по поддержке. Само по себе депонирование доказывает только то, что что-то задепонировали; проверка — отдельная услуга, которая выясняет, собирается ли из этого работающее приложение.

Спрашивайте каждого подрядчика, включая этого: что остаётся вашим после окончания проекта и можно ли увидеть этот список поимённо до подписания?

Что меняется, когда система должна работать в реальном времени?

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

Инженеров на рынке меньше. В опросе разработчиков Stack Overflow 2025 года 31 771 человек ответил, с какими языками он плотно работал за прошедший год. Rust назвали 14,8% из них, C++ — 23,5%, C — 22%, Go — 16,4%. Это опрос, а не перепись рынка труда, но важно соотношение: языки, на которых делают жёсткое реальное время, — навык меньшинства. Подрядчик, который «может набрать инженеров на Rust», описывает план найма; спросите, сколько инженеров уже внутри компании доводили Rust до прода.

Сам язык уже устоялся. Ежегодный опрос проекта Rust в 2025 году прошёл в десятый раз: 7156 ответов, собранных с 17 ноября по 17 декабря, и в отчёте отмечается сохраняющийся тренд найма со стороны организаций, которым нужно больше разработчиков на Rust. Команду, которую вы наймёте позже, не обязательно брать у текущего партнёра.

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

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

Хочу нанять команду разработки на Rust. С кем говорить и как их проверить?

На слова «нам нужен Rust» отзываются три вида подрядчиков. Универсальные аутсорсинговые компании наберут инженеров на Rust под ваш проект: разумно, когда в вашем сроке есть запас на наём, слабо, когда сложное — это сама система. Специализированные инженерные компании уже эксплуатируют системы на Rust, которые довели до прода их собственные инженеры. Отдельные инженеры по договору бывают отличными и несут риск незаменимого человека в самом чистом виде.

Заявления от доказательств отделяют четыре проверки:

• Публичный код. Crates, которые они публикуют, вклад в open-source проекты, технические тексты, подписанные именами их инженеров. Читать на Rust для этого не нужно: откройте любой их pull request и прочитайте ревью под ним — вы увидите либо разговор, либо штамп «одобрено»
• Одна система в проде, описанная от начала до конца. Что она делает, по чему её меряют, кто её эксплуатирует сегодня, что ломалось и что после этого поменяли. История инцидента — самая информативная часть
• Оплачиваемая двухнедельная пробная задача с определённым результатом, выданная двум-трём подрядчикам с одинаковым брифом и одинаковыми критериями приёмки
• Ревью независимого инженера, который не работает ни на одну из сторон. Он сообщает, падают ли тесты тогда, когда должны, как обрабатываются ошибки и таймауты, сколько в коде unsafe и зачем и может ли посторонний собрать результат по одной лишь инструкции

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

Как выбрать подрядчика для высоконагруженной системы реального времени?

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

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

Чек-лист, который можно вставить в запрос предложений (RFP)

Просите письменный ответ на каждый пункт; «обсудим позже» — тоже ответ, и его место в записи переговоров.

Люди и зависимость:

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

Владение:

• Предоставьте оговорку о владении, которую вы предлагаете, и укажите, отчуждение это прав или лицензия
• Подтвердите письменно, что каждый, кто пишет для нас код, включая внештатных исполнителей, передал вам свои права
• Перечислите поимённо каждый переиспользуемый или ранее созданный компонент, который войдёт в систему, и наши условия его использования
• Предоставляйте на каждом этапе перечень компонентов ПО (SBOM): компонент, версия, лицензия
• Подтвердите, что репозитории лежат в нашей организации с первого коммита и со всей историей, а сборка выполняется под нашими аккаунтами
• Изложите свою позицию по эскроу исходного кода: события раскрытия и проверяется ли депонированное

Доказательства по реальному времени, пробная задача и выход:

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

Частые вопросы

• «Выделенная команда» — то же самое, что аутстаффинг (staff augmentation)? Нет. При выделенной команде люди подрядчика работают только над вашим продуктом, и подрядчик сохраняет ответственность за то, как организована работа. При аутстаффинге инженеры входят в вашу команду, под ваше управление и ваше ревью кода
• Нужен ли эскроу, если код и так мой? Часто нет. Эскроу закрывает то, что вы не можете воспроизвести сами: сервис, который хостит подрядчик, сборку, которую вы не повторите, компоненты, переданные по лицензии, а не по отчуждению прав. Если ваши инженеры собирают всё на чистой машине, эскроу добавляет немного
• Подрядчик говорит, что его переиспользуемые компоненты — его секретный соус. Это проблема? Сама по себе нет; проблема — безграничное исключение. Ограниченное списком, передаваемой лицензией и либо исходниками, либо депонированием в эскроу, оно становится деталью. Без всего этого вы взяли свою платформу в аренду
• Честна ли оплачиваемая двухнедельная пробная задача по отношению к подрядчику? Да, если она оплачена по его обычным условиям, объём зафиксирован письменно и одна и та же задача уходит каждому кандидату. От бесплатных тестовых проектов и задач без границ подрядчики отказываются — и правильно делают
• Настаивать ли на Rust? Нет. Настаивайте на доказательствах, что система укладывается в отведённый ей срок под нагрузкой, а выбор языка пусть обоснует подрядчик. Команда, которая довела систему реального времени до прода и может показать замеры, сильнее команды, которая называет язык, который вы хотели услышать

Что amBrain может сказать о себе

Из описанных выше видов подрядчиков amBrain — специализированная инженерная компания. amBrain — инженерная компания из Еревана, Армения: строим low latency торговые платформы, matching engine и системы real-time bidding на Rust. amBrain делает софт с 2019 года и работает по всему миру — на английском, русском и армянском.

О команде и форматах: команда до 40 человек, около 75% из них — сеньоры, работает в трёх форматах — полная разработка, выделенная команда или инженеры внутри вашей команды.

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

О работе в реальном времени: построенная amBrain мини-биржа работает в проде на колокации MOEX. Измеренные цифры задержки и объёма, которые amBrain публикует, здесь не повторяются — они лежат на отраслевых страницах, рядом с той работой, на которой их и измеряли.

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

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