Как открыть офшорный центр разработки (ODC) в Беларуси: пошаговое руководство

Прежде чем начать: ODC — это действительно то, что вам нужно?

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

Логика, которую мы проясняем на первом звонке, обычно простая. Если вы планируете нанять меньше пяти разработчиков под проект с понятным концом — контракторы или EOR обыграют ODC и по срокам, и по стоимости. Если речь о десяти и более разработчиках, горизонте от трёх лет и желании самостоятельно управлять наймом, интеллектуальной собственностью и командой, тогда ODC начинает оправдывать себя. На практике переломная точка обычно находится где-то между восьмым и двенадцатым наймом. Именно с этого момента издержки на управление контракторами тихо начинают обходиться дороже, чем содержание собственного юрлица.

Эта статья про то, как запуск выглядит на практике в 2026 году. Вы найдете только то, что мы своими глазами видели работающим и не работающим.

Почему именно Беларусь для ODC в 2026 году

С точки зрения выбора Беларуси как ИТ-хаба за последнее десятилетие изменилась мало. Изменилась география вокруг неё.

Страна по-прежнему даёт одних из самых сильных в Восточной Европе разработчиков — особенно в инфраструктурном и продуктовом инжиниринге. Это наследие двадцати лет работы EPAM, Wargaming, IBA, Viber и длинного списка менее заметных продуктовых компаний. Сообщество разработчиков до сих пор огромное, даже несмотря на релокацию людей в Варшаву, Вильнюс, Тбилиси, на Кипр или в Сербию. Для современного ODC это плюс. Компания, зарегистрированная в Беларуси, при грамотно выстроенной контрактной схеме спокойно нанимает разработчиков в нескольких юрисдикциях.

Вторая половина истории — Парк высоких технологий (ПВТ). Это тот самый режим, благодаря которому Беларусь по-настоящему конкурентна по налогам. Подробно разберём чуть ниже, но если кратко: компании-резиденты ПВТ работают с заметно облегчённой налоговой нагрузкой, если попадают в список разрешённых ИТ-видов деятельности. Почти каждая иностранная технологическая компания, открывающая здесь ODC, идёт за резидентством ПВТ — и, честно говоря, нам сложно вспомнить случай, когда это решение себя бы не оправдало.

ПВТ — почему вокруг него всё крутится

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

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

Подвох — в перечне видов деятельности. Компания должна работать строго в рамках утверждённого списка ИТ-направлений. Список широкий: разработка ПО, консалтинг, R&D, финтех, кибербезопасность, ИИ и всё смежное — но не бесконечный. Если бизнес-модель уходит за разрешённые рамки, резидентство можно не получить. 

Официальный сайт ПВТ — park.by — содержит актуальный список видов деятельности и требования к заявке. Информация на сайте всегда обновляется, но саму подачу мы всё-таки советуем готовить с локальным консультантом.

Запуск шаг за шагом

Восемь шагов и реалистичные сроки по каждому.

Шаг 1. Выбираем юридическую форму. Подавляющее большинство ODC в Беларуси оформляются как общества с ограниченной ответственностью (ООО). Это самый простой путь: 100% иностранное владение допустимо, требования к капиталу разумные, форма не конфликтует с резидентством в ПВТ. Открытые акционерные общества и филиалы тоже доступны как опции, но если только структура штаб-квартиры не требует чего-то другого (например, из-за регуляторных особенностей в стране происхождения), ООО — выбор по умолчанию. На принятие этого решения закладывайте примерно неделю — в основном потому, что правильный ответ зависит от того, как устроена ваша материнская компания.

Шаг 2. Решение по ПВТ принимаем на старте. Сначала зарегистрировать юрлицо, а потом подать на резидентство — можно. Но лучше планировать оба процесса параллельно с первого дня. Для заявки в ПВТ нужны бизнес-план, чётко определённый перечень видов деятельности и прозрачная структура собственности. Учредительные документы стоит готовить, отталкиваясь именно от этих требований. Для практически любой иностранной компании путь через ПВТ — правильный.

Шаг 3. Готовим учредительные документы. Устав, учредительный договор, решения учредителей и прочая стандартная бумажная база. Если учредитель — иностранное юрлицо, потребуются нотариально заверенные и апостилированные документы с переводами на русский или белорусский. Минимальный уставной капитал для ООО — небольшой, но большинство ODC закладывают сумму выше, чтобы показать местным контрагентам серьёзность намерений. На этот этап реально уходит две-три недели — и большая часть времени это просто ожидание перевода и апостиля в стране происхождения.

Шаг 4. Регистрируем юрлицо. Подача документов идёт в местный регистрирующий орган в том городе, где будет офис, — обычно в Минске. Сама регистрация занимает несколько рабочих дней. Далее — постановка на налоговый учёт, статистическая отчётность и открытие банковского счёта. Счёт почти всегда самая медленная часть, потому что юрлица с иностранным капиталом проходят дополнительный комплаенс по правилам Национального банка Беларуси. От подачи документов до работающего счёта планируйте три-четыре недели в сумме.

Шаг 5. Подаём заявку на резидентство ПВТ. Бизнес-план и сопроводительные документы направляются в администрацию ПВТ. Наблюдательный совет рассматривает заявки по регулярному графику. Обычно одобрение занимает четыре-шесть недель — иногда быстрее, если заявка чистая, а виды деятельности однозначно ложатся в утверждённый список. Слабый бизнес-план или размытая формулировка деятельности — самые частые причины задержек.

Шаг 6. Настраиваем HR и расчёт зарплат. Этот этап компании систематически недооценивают. Понадобятся трудовые договоры, соответствующие белорусскому трудовому законодательству, система расчёта зарплат с учётом как местных налогов, так и специфических вычетов по ПВТ, и чистый процесс онбординга разработчиков. Большинство иностранных ODC в первый год отдают расчёт зарплат на аутсорс локальному провайдеру и открывают свой отдел только когда дорастают до соответствующего масштаба. Наш аутстаффинг и HR-поддержка идеально подходят на этом этапе.

Шаг 7. Нанимаем первую команду. Сначала — руководитель локального офиса, в идеале до того, как начинается набор разработчиков. Подбор первых сотрудников через локального рекрутингового партнёра существенно ускоряет процесс: вы пропускаете долгий путь самостоятельного выяснения того, где на самом деле ищут работу белорусские разработчики. Наша услуга ИТ-рекрутинга ведёт этот процесс под ключ. От старта до первого выхода разработчика на работу закладывайте восемь-двенадцать недель.

Шаг 8. Доводим офис до рабочего состояния. Закупка оборудования, безопасность, ИТ-инфраструктура и решение — держать физический офис или работать удалённо. И белорусский Трудовой кодекс, и режим ПВТ удалённую работу прямо поддерживают, и большинство современных ODC сейчас либо гибридные, либо изначально remote-first. Если физическое пространство всё-таки нужно — в Минске развит рынок коворкингов и сервисных офисов по адекватным ценам.

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

Сколько это стоит

Реальные диапазоны цен. Не оценки из глянцевой брошюры. Это то, что наши клиенты действительно платили за запуск белорусских ODC в 2025 и 2026 годах.

Несколько скрытых статей, которых нет в исходных коммерческих предложениях, но которые стабильно появляются в реальных бюджетах: накладные на комплаенс и аудит со второго года, потери на конвертации валют (обычно 0,5–1% на каждом переводе), командировки руководства из штаб-квартиры на ежеквартальные визиты и управленческая нагрузка от наличия локального руководителя. Ни одна из этих статей сделку не сорвёт. Но в сумме они дают примерно $30–$50 тысяч в год, которые компании регулярно забывают заложить.

Для более широкого взгляда на экономику ИТ-сектора Беларуси у Национального статистического комитета публикуются отраслевые данные, по которым удобно сверять собственные допущения.

Когда ODC — это правильно, а когда лучше что-то другое

Многие наши первые звонки заканчиваются тем, что мы отговариваем клиента от полноценного ODC — как минимум на первые 12 месяцев. 

Логика проста.

Для одного-пяти разработчиков на проектной работе прямые B2B-контракты или EOR выигрывают у ODC по всем метрикам. Запуск быстрее, стоимость ниже, и можно беспроблемно сворачиваться без юридических нюансов. Для пяти-пятнадцати разработчиков, если вы не хотите управлять иностранным юрлицом, обычно правильный выбор — PEO. PEO берёт на себя оформление, расчёт зарплат и комплаенс, а вы занимаетесь только инженерной работой.

ODC начинает играть в полную силу, когда вы нанимаете 10 и более разработчиков, планируете работать минимум три года и хотите полностью контролировать найм, ИС и культуру команды. На этой численности экономика меняет свое направление — расходы на одного разработчика в схеме с контракторами или EOR начинают превышать постоянные расходы на собственное юрлицо.

Самый чистый путь для многих компаний — поэтапный. Сначала EOR или PEO, чтобы прощупать рынок и команду. Переход в полноценный ODC — когда долгосрочная ставка ощущается реальной. Мы провели нескольких клиентов ровно по этому маршруту, и обычно результат лучше, чем когда ODC пытаются развернуть с первого дня.

Ошибки, которые мы видим раз за разом

После определённого количества запусков одни и те же ошибки начинают повторяться.

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

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

Считать ODC удалённым офисом, а не настоящей дочерней компанией. У Беларуси своё трудовое законодательство, своя налоговая логика и своя культура комплаенса. Попытка управлять белорусским юрлицом по политикам штаб-квартиры — гарантированный путь к проблемам и с сотрудниками, и с регуляторами.

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

Когда подключать локального партнёра

Честный ответ: на тех участках, где ошибки стоят дороже всего.

Юридическую регистрацию можно сделать с любой приличной минской юрфирмой — так и поступает большинство компаний. Сложнее закрыть внутренними силами связку из заявки в ПВТ, локальной HR-инфраструктуры и первой волны найма. Это три параллельных потока, и все три требуют рабочего понимания местного рынка.

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

Свяжитесь с нами

Мы каждый месяц помогаем международным компаниям запускать работу в Беларуси. Будь то полноценный ODC, поэтапный переход EOR → ODC или просто разговор о том, имеет ли смысл сам шаг, — мы готовы честно всё обсудить.

Свяжитесь с нами на 30-минутный звонок. Расскажем, что реально с учётом ваших сроков, бюджета и целей, без обязательств. Если ODC вам не подходит — так и скажем.

Как нанять сильного PM для ИТ-проекта в Беларуси

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

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

Что на самом деле означает «сильный PM»

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

Delivery PM. Классический менеджер сервисной компании, который отвечает за скоуп, сроки, коммуникацию с клиентом и моральный климат в команде. Делает сложные проекты предсказуемыми. Большинство опытных белорусских PM выросли именно из этого архетипа — двадцать лет аутсорсинга были для них школой. Сильный выбор для агентств, клиентских команд и любых проектов с заранее ожидаемым финалом.

Technical PM. Ближе к тех-лиду, но с менеджерскими навыками. Читает код, аргументированно спорит с оценками инженеров, выступает медиатором в технических дискуссиях, не вставая ни на чью сторону. Встречается реже, обходится дороже. Та самая роль, когда команде разработки нужен переводчик, а не диспетчер.

Outcome-Driven PM. Самый сложный найм из трёх. Отвечает за результат, а не только за то, что было поставлено в план. Спокойно работает с неопределённостью. Принимает решения по приоритизации. Спорит, когда спецификация откровенно плохая. Та самая роль для продуктовых компаний, стартапов и любых ситуаций, где задача формулируется по ходу, а не выдаётся в готовом виде.

Ловушка, в которую попадает большинство компаний, выглядит примерно так: пишут вакансию «Senior Project Manager», проводят пять собеседований, нанимают Delivery PM — а нужен-то был Outcome-Driven. Это упущение остаётся незаметным примерно до четвёртого месяца. На то, чтобы потом разобраться, уходит год.

Белорусский рынок предлагает Delivery PM в избытке и Outcome-Driven заметно в меньшем количестве. Соотношение между ними неравномерное — и об этом полезно помнить ещё до того, как вы начали скрининг резюме.

Почему именно Беларусь

Скорее всего, причина читать эту статью у вас уже есть — но для полноты картины:

• Двадцать лет работы с западными клиентами через сервисные компании сформировали широкий рынок PM-кадров: EPAM, IBA, Itransition, Wargaming и десятки небольших студий, каждую из которых в регионе знают по имени.
• Английский в слое PM по-настоящему сильный. Клиенты требовали его годами, и планка с тех пор держится.
• Полное пересечение по часам с европейским рабочим днём, частичное — с американским Восточным побережьем.
• Зарплаты держатся на 40–60% ниже американских и на 30–45% ниже Западной Европы при сопоставимом уровне квалификации.
• Резидентство в Парке высоких технологий по-прежнему даёт ощутимые налоговые преимущества — и работодателю, и самому PM, при том же окладе.

Та часть, которую обычно не вписывают в маркетинговые материалы: значительная доля сеньорных PM переехала в 2022–2024 годах в Польшу, Литву, на Кипр, в Грузию. По образованию, языку и сети контактов они по-прежнему белорусы — просто оформлены теперь в других юрисдикциях. На практике для иностранных команд это, как правило, плюс, а не минус: специалисты стали доступнее, чем три года назад. Просто юридическая модель найма с тех пор поменялась.

За эти годы мы помогли разместить сотни PM и других IT-специалистов по всему миру. С точки зрения географии нанимать стало не сложнее — поменялась только логистика.

Описание вакансии, которое привлечет сильных кандидатов

Описание вакансии — то самое место, где большинство компаний тихо теряют сильных PM, даже не осознавая этого. Три правила:

• Чётко обозначайте, какой тип вы ищете. Не нужно писать «ведёт проекты от идеи до релиза» и надеяться, что нужный кандидат сам себя отфильтрует. Сформулируйте четко, кто вам нужен.
• Конкретизируйте методологию. Фраза «У нас Scrum с двухнедельными спринтами, ретро раз в две недели по пятницам, один прод-релиз за спринт» даёт кандидату конкретный ориентир. А «знакомство с Agile-методологиями» привлекает каждого, кто прошёл четырёхчасовой курс на Udemy.
• Уточняйте масштаб. Размер команды. Количество стейкхолдеров. Владеет ли PM планом действий сам или исполняет чужой. Эти три параметра расскажут кандидату о соответствии роли больше, чем любой список обязанностей.

Типичные ошибки, которые лучше не совершать:

• Требовать одновременно PMP и CSM. Это сигнал того, что вы сами ещё не определились, кого ищете. Оба сертификата сами по себе важны ( PMI и Scrum.org) — но они подтверждают разные вещи, и «оба обязательны» читается как список покупок, а не как требования к роли.
• «Опыт от 5 лет» без уточнения, какой именно опыт нужен. Сеньорный PM в агентстве и сеньорный PM в продуктовом стартапе — это совершенно разные позиции.
• Списки обязанностей в восемнадцать пунктов, половина из которых противоречит другой половине.
• Подход, при котором PM, Scrum Master и Product Manager воспринимаются как взаимозаменяемые роли. Это не так — к этому различию мы ещё вернёмся в разделе Вопрос-ответ.

В первую очередь говорите о задачах, а не о плюшках. Инженеры не меняют работу ради настольного футбола. Сильные PM, к слову, тоже.

Интервью, которое реально помогает выбрать

Именно здесь большинство команд ошибаются, поэтому раздел будет чуть длиннее остальных. 

Три этапа. Задачки на сообразительность — мимо.

Этап 1: глубокий разбор одного проекта (45 минут)

Выбираете один проект из резюме. Ровно один. И идёте в глубину:

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

Один этот этап, по нашему опыту, отсеивает примерно 60% слабых кандидатов. Паттерн повторяется из раза в раз. Они не могут рассказать о конкретных решениях, потому что попросту их не принимали. Они не могут сформулировать, что пошло не так, потому что не анализируют собственную работу. И уходят в защиту через язык процессов и JIRA — туда, где им безопасно.

Этап 2: живой сценарий (45 минут)

Реальная ситуация, а не задача на смекалку. Например:

«На стендапе в среду команда разработки сообщает вам, что не успеет выкатить фичу X к дедлайну через две недели. Клиент эту фичу ждёт и под её запуск уже построил маркетинговую кампанию. CEO пока ничего не знает. Расскажите, как у вас пройдут следующие 48 часов.»

На что стоит обращать внимание:

• Идут ли они сначала за данными — или сразу прыгают в готовые решения?
• Эскалируют наверх (CEO должен знать) — или прячут проблему до последнего?
• Аргументированно спорят с командой разработки по оценке — или принимают её на веру?
• Переформулируют задачу: можно ли сократить скоуп, разбить на фазы, увеличить время? — или просто сообщают об опоздании?
• Как они ведут разговор с клиентом: уходя в защиту или уверенно?

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

Этап 3: ролевая игра со стейкхолдером (30 минут)

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

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

Бонусный вопрос, который стоит вставить где-то по ходу: «А что вы читаете или за кем следите по теме PM?» У сильных PM есть мнения о конкретных людях — Марти Каган в SVPG, рассылка Lenny Rachitsky, что-то в таком духе. Слабые отвечают «я много читаю статей». Распознавание по конкретным именам работает; по общим формулировкам — нет.

Красные и зеленые флаги

Две колонки. Самая полезная для выводов часть всей статьи.

Зарплаты (кратко)

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

• Outcome-Driven PM стоят на 15–25% дороже Delivery PM того же грейда. И найти их при этом сложнее.
• Релоцированные PM (Варшава, Вильнюс, Лимассол) обходятся на 20–35% дороже эквивалента в Минске. Это привязка к стоимости жизни — с этим ничего не поделать.
• Technical PM держатся на 10–15% выше обычных PM того же уровня.

Резидентство в ПВТ даёт PM ту же налоговую ситуацию, что и инженерам. А это значит, что компании-резиденты ПВТ фактически предлагают кандидату больше «на руки» при том же окладе — стоит держать в голове, когда вы конкурируете с локальными игроками.

Где сильные PM живут онлайн

Микс каналов для сорсинга PM заметно отличается от инженерного. PM поддерживают онлайн-жизнь, которую разработчики обычно не ведут.

• LinkedIn. Главный канал. PM активно ведут профили, пишут о своей работе, отвечают на прямые сообщения от рекрутеров. Сеньорные PM заметно отзывчивее сеньорных инженеров — для них выстраивание отношений всё-таки часть профессиональной идентичности.
• Telegram-каналы (PM-сообщества СНГ). Менее «забитые», чем LinkedIn. Сеньоры и выше их читают. Знать, какие именно каналы работают, — отдельный навык, и именно тут экспертиза агентства даёт фору.
• Рекомендации от сеньорных инженерных хайров. Сильные инженеры знают, кого из PM они уважают. И, как правило, не ошибаются.
• Alumni-сети крупных белорусских IT-работодателей. EPAM, IBA, Itransition, Wargaming. Любой, кто проработал в этих компаниях больше пяти лет, прошёл настоящую школу. Опыт действительно глубокий.
• Кадровые агентства. Максимально полезны, когда вам нужен конкретный тип, вы нанимаете на уровень сеньора и выше, или когда хочется, чтобы кто-то сделал фильтрацию первого этапа до того, как ваша команда начнёт жечь часы на интервью. Наша команда IT-рекрутмента обычно показывает первых отскринированных PM-кандидатов в течение 5–7 рабочих дней. Да, это самореклама — но и реальный механизм, который сокращает месяцы поиска в недели.

Если же удобнее начать с гибкой модели и решить вопрос со штатом позже, второй вариант — IT-аутстафф. Полезно, когда хочется попробовать сеньорного PM на конкретном проекте, прежде чем брать его в штат.

Если кратко

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

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

Как построить реферальную программу, которая реально работает для найма IT-специалистов в Беларуси

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

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

Эта статья написана под белорусский IT-рынок: с учётом резидентства в ПВТ, выплат в BYN и того, как здесь работает найм. И она про то, что работает на практике, а не про теорию.

Почему рекомендации особенно хорошо работают в IT-найме в Беларуси

Белорусский IT-рынок по мировым меркам крошечный. Большая часть сеньорского пула вышла из БГУИР или БГУ, поработала в EPAM, Itransition или паре средних продуктовых компаний — и осталась примерно в той же орбите. Люди знают друг друга. Люди общаются.

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

Первый — плотность. Senior Java-разработчик в Минске, не задумываясь, назовёт десяток коллег своего уровня по именам. Один хороший запрос внутри этой группы за неделю доходит до всего локального рынка по конкретному стеку.

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

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

Шаг 1 — Определите, для чего вообще нужна программа

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

Поэтому, прежде чем что-либо публиковать, сядьте с head of engineering и финансовым директором и выберите реальный результат, которого хотите добиться за ближайшие два квартала.

Обычно это попадает в одну из четырёх сфер. Вы хотите снизить cost-per-hire по senior IC-ролям, потому что счета от агентств начали казаться абсурдными. Или закрыть стеки, которые игнорируют ваши вакансии в принципе — Go, Rust, Solidity, ML, senior DevOps, мобильные тимлиды и прочие сложные вакансии. Или улучшить удержание в первый год работы — и для этого есть хорошие данные: рекомендованные сотрудники задерживаются дольше. Или вы просто хотите перестать зависеть от одного рекрутера или одного джоб-борда — потому что эта зависимость делает строку расходов нестабильной каждый раз, когда поставщик поднимает прайс.

Выберите один пункт. Максимум два. Зафиксируйте его там, где его увидят и нанимающий менеджер, и финансист.

Затем переведите это в реальный план найма. Шесть senior backend-вакансий открыто на год, средний счёт от агентства — около 9 000 долларов за позицию, две из них вы закрываете через реферальную систему — программа уже окупила свои бонусы в несколько раз.

Шаг 2 — Спроектируйте бонус (здесь ломается большинство программ)

Белорусские инженеры не наивны в вопросах денег. Они знают, сколько платят Middle Java в Варшаве и сколько в Минске, и считают бонус за рекомендацию в уме за секунды. Две ошибки, которых стоит избегать:

Бонусы, слишком маленькие, чтобы напрягаться. 500 BYN за приведённого Senior DevOps — это, честно говоря, оскорбительно, если посмотреть на то, сколько вы сэкономите.

Бонусы по единой ставке. Одинаковая сумма за QA Manual и за Senior ML Engineer прямо показывает, что программа несерьёзная.

Структура, которая действительно мотивирует

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

Уровень 1 — Стандартные роли: Junior–Middle разработчики на массовых стеках, QA, поддержка. Бонус: примерно один месячный оклад нанятого сотрудника, разбитый на части (про разбивку — ниже).

Уровень 2 — Сложные роли: Senior-разработчики, тимлиды, DevOps, лиды iOS/Android. Бонус: 1,5–2 месячных оклада.

Уровень 3 — Критические роли: CTO, Engineering Manager, специалисты по блокчейну и Web3, ML-лиды, узкие стеки. Бонус: 2–3 месячных оклада, иногда выше — при подтверждённом найме сильного сеньора.

Выплачивайте вознаграждение через структуру, которая защищает ваши интересы

Самая оптимальная структура, которую используют большинство белорусских IT-работодателей, — это разбивка выплаты. Например: 30% в день выхода нового сотрудника на работу и 70% после прохождения испытательного срока (белорусский Трудовой кодекс допускает до трёх месяцев). Некоторые компании растягивают вторую часть до шести месяцев. Оба варианта разумны — задача в том, чтобы интересы рекомендателя совпадали не с фактом подписания оффера, а с тем, что человек реально приживётся.

Если вы резидент ПВТ, обсудите суммы бонусов с бухгалтером или провайдером расчёта зарплаты до публикации правил. Реферальные бонусы обычно квалифицируются как часть оплаты труда и облагаются по стандартным правилам — заранее выстроенная схема избавит от неловких разговоров через полгода.

Шаг 3 — Сделайте процесс рекомендации почти неощутимым

Самая частая ошибка в проектировании системы — её переусложнение. Делается красивая форма с обязательной загрузкой CV и выпадающим списком «предпочтительный способ связи», интегрируется с ATS, заворачивается за SSO — а через полгода никто не понимает, почему этим никто не пользуется.

Сеньоры, которых вы хотите видеть в качестве рекомендателей, заняты. Они в середине спринта. У них открыт code review в соседней вкладке. Окно внимания — полторы минуты. Если процесс в это окно не помещается, мысль уходит, и рекомендация теряется.

Поэтому максимально упростите всё. Должно быть одно место, куда выкладывают актуальные вакансии и где сумма бонуса по каждому уровню видна без отдельного запроса. Notion, внутренняя вики, портал ATS — неважно, что именно, важно, чтобы это было актуальным. Должен быть один способ подать рекомендацию. Не форма плюс Slack-канал плюс email. Один. Тот, который ваша команда будет реально поддерживать. Форма заявки должна спрашивать две вещи: имя кандидата и контакт, всё остальное — приятный бонус.

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

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

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

Шаг 4 — Ведите программу как продукт

Запустить программу — легко. Сложное — удержать её живой после второго квартала. Относитесь к ней как к внутреннему продукту с небольшим набором ритуалов:

Ежемесячный hot list. Раз в месяц рассылайте по почте или в Slack короткий список из трёх вакансий, которые горят сильнее всего, с конкретным стеком и тиром бонуса. Сообщения в духе «мы всегда ищем инженеров» игнорируются.

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

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

Привязка к календарю. Небольшой «летний реферальный спринт» с месячным повышением бонуса по конкретной роли почти всегда работает лучше плоской программы. Люди реагируют на дедлайны.

Шаг 5 — Замеряйте четыре показателя, остальное игнорируйте

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

Уровень участия — какой процент сотрудников, привёл хотя бы одного кандидата за квартал. Работающая программа в инженерной команде на 50 человек попадает в диапазон 20–35%.

Конверсия рекомендация → найм — какая доля рекомендованных кандидатов в итоге была нанята. Целевой диапазон по важным ролям — 15–25%; меньше 10% означает, что вы спрашиваете не у тех людей или бонус слишком низкий, чтобы фильтровать качество.

Cost-per-hire — сумма выплаченных бонусов, делённая на количество наймов. Сравнивайте честно: с агентскими комиссиями, стоимостью джоб-бордов и временем внутренних рекрутеров.

Удержание рекомендованных сотрудников через 12 месяцев — почти всегда выше, чем по другим каналам. Если у вас не так — что-то сломано в онбординге или ваши инженеры приводят не тех людей.

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

Типичные ошибки (и как их обойти)

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

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

Бонусы, которые приходят с опозданием на месяцы. Первая выплата — самый заметный момент в жизни программы. Если она медленная, мутная или плохо коммуницируется, программа теряет кредит доверия, который потом не вернуть.

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

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

Как встроить рекомендации в остальной стек найма

Рекомендации — мощный канал, но не цельная стратегия. Самые устойчивые инженерные команды в Беларуси сочетают три слоя:

Рекомендации — самый качественный и самый дешёвый канал. Оптимизирован под senior- и trust-critical роли.

Целевой аутрич — выделенный сорсер или внешний партнёр, ведущий хедхантинг по тем ролям, которые ваша сеть не закрывает. Здесь зарабатывает свои деньги опытное IT-рекрутинговое агентство.

Работа над брендом работодателя — инженерный блог, выступления на конференциях, присутствие на GitHub. Медленная инвестиция с накопительным эффектом, которая со временем делает и рекомендации, и аутрич проще.

Если вы — иностранная компания, которая нанимает в Беларуси без локального юрлица, операционная сторона процесса (контракты, расчёт зарплаты, отчисления в ФСЗН, позиционирование в ПВТ) часто тихо тормозит найм даже тогда, когда кандидат уже готов подписать оффер. Услуги EOR и локальное HR-консультирование обычно окупаются на первом же найме — просто за счёт сокращения времени от оффера до первого рабочего дня.

План запуска за 30 дней

Если вы хотите запустить программу уже в этом месяце, вот самый короткий путь:

Дни 1–5: Определите цель, уровни бонусов и схему выплат. Согласуйте всё с финансовым отделом и провайдером расчёта зарплаты.

Дни 6–10: Подготовьте одностраничный список ролей и выберите единственный канал подачи рекомендаций. Напишите FAQ.

Дни 11–15: Проведите 30-минутный all-hands с запуском. Покажите роли, бонусы, процесс. Оперативно отвечайте на вопросы.

Дни 16–30: Лично обойдите топ-10 ваших senior-инженеров. Личные просьбы работают; массовые рассылки — нет. Фиксируйте каждую входящую рекомендацию.

Итог

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

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

От ручного QA к автоматизации: как нанимать и как растить своих

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

От того рынка не осталось и следа.

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

Параллельно складывается другая картина: каждый второй CTO, с которым нам приходилось общаться за последние полгода, рано или поздно задаёт один и тот же вопрос — «У нас в команде есть отличные QA, которые сами рвутся в автоматизацию. Может, просто обучим их и не будем никого нанимать со стороны?».

Иногда это оказывается самым умным решением за весь год. А иногда — после восьми месяцев попыток, разочаровавшихся людей и подорванного доверия — вы всё равно идёте искать специалиста извне.

Главное — научиться отличать одну ситуацию от другой ещё до того, как вы успели потратить на ошибку полгода.

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

Почему всё стало сложнее

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

Во-первых, сама роль заметно преобразилась. То, что когда-то называлось «человек, который пишет Selenium-скрипты», постепенно превратилось в инженера, отвечающего за CI-пайплайны, разбирающегося с API-контрактами и периодически залезающего даже в инфраструктурный код. Одни компании, понимая это, называют такую роль SDET и платят соответственно. Другие предпочитают писать вакансию на «Automation QA Engineer» и при этом рассчитывают платить на 30% меньше за тот же объём ответственности, — после чего удивляются, почему их вакансии висят без откликов месяцами.

Во-вторых, рынок стал глобальным, а вместе с тем — гораздо более разнообразным. По данным Stack Overflow Developer Survey, QA-позиции из года в год входят в число самых трудных для закрытия, а удалёнка добавила к этому процессу свою специфику: ваш кандидат, сидя в Минске или Тбилиси, может спокойно принять оффер из Берлина или Сан-Франциско, не складывая при этом ни одной вещи.

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

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

Что вообще скрывается за словами «QA-автоматизатор» в 2026 году

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

1. SDET. По своей сути это разработчик, который занимается тестами: строит фреймворки, контрибьютит в продуктовый код, живёт в пул-реквестах. Зарплатная вилка у него стоит рядом с бэкендером сопоставимого грейда.
2. QA Automation Engineer. Силён в коде, однако фокус его внимания — тест-дизайн и прогон тестов, а не продуктовая разработка. Отвечает за тестовый код, а не за код приложения. По факту большинству команд нужен именно такой специалист — а вакансию по привычке пишут на SDET, и этот нюанс обходится компании ровно в годовую зарплату, переплаченную впустую.
3. QA-лид с гибридным бэкграундом. Тот самый человек, который вырос из ручного тестирования, со временем освоил автоматизацию, а теперь ведёт небольшую команду. Кадр редкий и ценный и почти всегда не нанятый со стороны, а развитый внутри.

А теперь — реалистичный чек-лист по навыкам, которые действительно требуются:

• Один язык программирования, на котором кандидат реально писал продакшен-код, — Python, JavaScript, Java или C#. Не «знакомство», не «понимание основ», не «изучал на курсах», а живой код, который где-то работал и который вы при желании можете проверить.
• Современный фреймворк автоматизации — Selenium, Playwright или Cypress: в новых проектах сейчас доминирует Playwright, тогда как legacy по-прежнему держится на Selenium.
• Тестирование API — обычно Postman для ручной части и REST-assured (либо аналог) на уровне кода.
• Git, основы CI/CD и базовый SQL — без компромиссов.
• Понимание теории тестирования — достаточное для того, чтобы аргументированно объяснить, что стоит автоматизировать, а что нет. 

Сертификат ISTQB Foundation служит неплохим косвенным признаком, что человек подучил теорию. Однако многие сильные автоматизаторы его никогда не сдавали — поэтому делать этот сертификат обязательным требованием не стоит ни при каких обстоятельствах.

Путь А: найм со стороны

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

Сроки

На рынке найм сеньора-автоматизатора занимает 6–9 недель с момента открытия вакансии до подписанного оффера. Мидл вакансия закрывается за 4–6 недель. Если же вам нужно, чтобы человек писал тесты уже через три недели, то это уже не классический найм, а аутстафф, либо работа с рекрутером, у которого уже есть готовая база проверенных кандидатов. Третьего варианта здесь не существует, и тот, кто его вам обещает, либо переоценивает свои силы, либо просто врёт.

Где искать

Если речь идёт о найме в команду на территории СНГ или Восточной Европы, картина рынка достаточно прозрачная. Беларусь, Польша, Украина, Россия, Казахстан давно сложились в кадровый резерв для западных продуктовых команд: сильная техническая база (значительная часть автоматизаторов приходит из физмата или из смежных инженерных специальностей), хороший рабочий английский и зарплаты, которые при сопоставимом уровне навыков остаются на 30–50% ниже западноевропейских. За годы работы мы закрыли сотни QA-вакансий в этом регионе под команды в США и ЕС, а в нашем зарплатном исследовании можно посмотреть реальные цифры с фильтрацией по грейдам и стекам.

Описание вакансии, которое не отпугнёт сильных кандидатов

• Сократите список обязательных требований ровно вдвое. Когда в вакансии 14 пунктов «должен знать», сильный кандидат делает простой вывод — вам нужен единорог, — и проходит мимо, не читая описание до конца.
• Будьте максимально конкретны со стеком. Формулировка «опыт работы с различными фреймворками тестирования» не несёт ровным счётом никакой информации. А вот «у нас Playwright + TypeScript, тесты гоняем в GitHub Actions, ищем человека, который сможет расширить наш текущий Page Object» — это всё, что нужно знать кандидату, указанное в одном предложении.
• Начинайте с задач, а не с перечня плюшек. Инженеры, а особенно сильные, не меняют работу ради компенсации за спорт.

Собеседования, которые реально помогают

Про задачи на логику можно смело забыть, так как работает совершенно другое:

• Этап 1. Совместное код-ревью реального (или максимально близкого к реальному) тестового сьюта. Попросите кандидата рассказать, что бы он переделал и почему, — за двадцать минут такого разговора о его мышлении станет понятно больше, чем за всё остальное собеседование, вместе взятое.
• Этап 2. Небольшое live-задание — расширить фреймворк, починить флакующий тест или написать тест на конкретный user story. От 60 до 90 минут, не больше, и обязательно в формате парного программирования, а не «вот вам доска, решайте».
• Этап 3. Поведенческое интервью. Спросите про релиз, который по-хорошему должны были заблокировать, но не заблокировали. Про флакующий тест, с которым приходилось воевать неделями. Про то, как кандидат объясняет разработчику, что код пора писать более тестируемым, — желательно без перехода на личности.

Если же ваш процесс растягивается на пять и более этапов, то кандидат, который вам в действительности нужен, успеет за это время принять оффер где-то ещё, а вы об этом, скорее всего, даже не узнаете. Никто, разумеется, не пришлёт вам письмо с объяснением причин.

Красные флаги, которые лучше замечать пораньше

• Уверенно перечисляет инструменты и фреймворки, но затрудняется объяснить, почему для конкретной задачи он выбрал бы именно Playwright, а не Selenium (или наоборот).
• Нет ни публичного кода, ни активного GitHub, ни одного готового примера. А обезличить хотя бы небольшой фрагмент рабочего кода — «не может». У сильного инженера всегда находится, чем поделиться, даже если основной проект под NDA.
• Относится к ручным тестировщикам с лёгким презрением, как ко второму сорту. Такой настрой — это яд, который отравляет команду быстрее любого сорванного дедлайна.

Если возиться с сорсингом самостоятельно у вас нет ни ресурса, ни желания, то наша команда по найму QA-автоматизаторов обычно показывает первых кандидатов уже в течение пяти рабочих дней. 

Путь Б: развитие своих

Путь сложнее. И, как правило, гораздо результативнее. Просто почти никто не делает его правильно с первого раза.

Кто реально подходит на роль автоматизатора

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

• Они уже начали учиться самостоятельно — без напоминаний и без поручений сверху. Написали пару скриптов, прошли половину какого-нибудь курса, задают на код-ревью те вопросы, которых от мануальщика обычно никто не ждёт. 
• Они спокойно работают в командной строке и пишут базовый SQL. Если же человек до сих пор тушуется при виде терминала, то ваша «взлётная полоса» окажется в разы длиннее запаса времени, которым вы реально располагаете.
• Они понимают, почему ломается, — а не только фиксируют сам факт, что сломалось. Грамотный тест-дизайн вырастает именно из этой интуиции, а её, увы, нельзя развить за полгода.

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

Шестимесячный план обучения — честная версия

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

Это не обучение. Это плановое выгорание, расписанное на полгода вперёд.

Сколько такой переход стоит на самом деле

• Время обучающегося — примерно 10–15 часов в неделю на протяжении шести месяцев.
• Время сеньора-ментора — 3–5 часов в неделю, которые уходят на код-ревью, парную работу и ответы на вечный вопрос «почему этот тест опять флакует».
• Бюджет на обучение — $500–1500 на человека: Test Automation University бесплатный и при этом действительно хороший, тогда как профильные курсы по Playwright или Selenium обойдутся в $50–200 каждый.
• Полная стоимость со всеми накладными расходами выходит примерно в $8 000–15 000 на человека.

Для сравнения — полная стоимость найма сеньора-автоматизатора со стороны, с учётом всех расходов и времени, потраченного на сорсинг, доходит до $80 000–150 000. Так что арифметика тут получается, мягко говоря, однобокая.

Почему внутренний переход всё равно чаще всего проваливается

• У человека нет свободного времени — это причина номер один с большим отрывом от всех остальных.
• За ним не закрепили ментора. Формулировка «спроси у любого из ребят-разработчиков» — это не менторство, а изящное перекладывание ответственности.
• У него нет своего боевого проекта. Учебные задачи просто не дают возможности почувствовать, как реальное тестирование устроено в продакшене.
• Нет критериев «готово». В какой именно момент переход считается завершённым? Если ответа нет, переход не заканчивается никогда — он тихо угасает где-то между четвёртым и пятым месяцем.

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

Так какой путь в итоге выбирать?

Короткая шпаргалка, в которой вы найдете строчку, которая точнее всего описывает вашу текущую ситуацию.

• Если автоматизация должна заработать в течение трёх месяцев — нанимайте. И не уговаривайте себя, что обучение пойдёт быстрее: не пойдёт.
• Если у вас есть полгода в запасе и пара ручников с нужными навыками — растите своих. Когда такой подход срабатывает, экономия перекрывает всё остальное с большим запасом.
• Если нужны три и больше автоматизаторов — комбинируйте оба пути. Один сильный сеньор, нанятый со стороны, плюс двое внутренних ручников в роли его подопечных. Этот сеньор одновременно становится и архитектором, и ментором, что даёт самый высокий ROI среди всех вариантов QA-найма.
• Если в команде нет ни одного сеньора-автоматизатора, который мог бы менторить новичков — сначала наймите. Растить начинайте уже после, опираясь именно на этого сеньора. Без ментора внутри попытка вырастить своих автоматизаторов проваливается практически гарантированно.

Если же вы нанимаете отдел QA с нуля — начните с готовой команды или аутстаффа на первое время. Пока вы сами окончательно не поймёте, какая именно функция нужна вашей компании в долгую.

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

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

Самый ценный QA-найм — это вовсе не сеньор, который пишет больше всех тестов. Это сеньор, который пишет хорошие тесты и при этом параллельно ведёт двух-трёх внутренних «переходящих». Один правильно структурированный найм за год вырастает в команду из четырёх автоматизаторов — и обходится компании примерно вдвое дешевле, чем если бы вы наняли этих четверых по отдельности.

Работает такая модель только в одном случае, если вы заложили её в план с самого первого дня. Менторство прописано в описании вакансии. Менторство учитывается в KPI. На него отведено время. И зарплата у этого сеньора рассчитана как у мультипликатора, которым он по факту и является.

Однако, когда вы наняли сеньора и про себя надеетесь, что он будет менторить «в свободное время», это не сработает. Не будет. Он сделает ровно то, на что его формально нанимали, после чего уйдёт на ближайший Staff-оффер — как только осознает, что обещанного лидерского роста ему здесь не видать.

Кратко

Универсально правильного ответа на вопрос «нанимать или растить» попросту не существует. Есть только ответ, правильный для вашей конкретной ситуации, — с учётом сроков, состава команды на сегодняшний день и того, как именно должен выглядеть ваша QA через год.

Если вы дочитали до этой строчки, у вас, скорее всего, в голове уже есть конкретная ситуация. Хотите получить второе мнение — какой из путей подходит именно вам? Уже больше десяти лет мы помогаем компаниям нанимать QA-автоматизаторов и ручных тестировщиков, выстраивать внутренние программы обучения и находить баланс между этими двумя подходами. В худшем случае вы потратите тридцать минут на разговор с теми, кто видел эту картину уже сотни раз. В лучшем — сэкономите месяцы движения наугад. Напишите нам — поможем нанять нужных.