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

Что мы наблюдаем стабильно последние пару лет.

Иностранные офшорные центры разработки не запускают в первые месяцы работы в Беларуси. Их запускают сильно позже — обычно через 18–36 месяцев после того, как первый инженер вышел через EOR. К этому моменту команда уже выросла до 15–20 человек. Операционное трение стало заметным. Маржа EOR, выставляемая каждый месяц, перестала выглядеть маленькой. Решения, под которыми нужна белорусская сторона, чтобы что-то подписать, всплывают регулярно — и кто-то на иностранной стороне постоянно ждёт.

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

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

ODC vs EOR — вопрос перед вопросом

Большинство иностранных клиентов спрашивают «как открыть ODC в Беларуси». Вопрос, который стоит задать до этого: «а он мне сейчас вообще нужен?»

Запуск — это структурная работа. Она съедает время, внимание и политический капитал внутри иностранной материнской компании. Если размер команды и операционная сложность ещё не оправдывают этот ход, правильный ответ — остаться на EOR-модели ещё на год и вернуться к разговору. Мы видели клиентов, которые переходили на уровне 12 разработчиков и потом жалели. Мы видели клиентов, которые оставались на EOR на 40 разработчиках и тоже жалели. Этот вопрос заслуживает больше места, чем ему обычно дают в линейных how-to-статьях.

EOR — правильный ответ, когда

• Команда меньше 15–20 инженеров и не растёт резко вверх.
• Белорусская команда поддерживает не-белорусский головной офис, и инженерам не нужны прямые контрактные отношения с материнской компанией.
• Простота банкинга важнее налоговой оптимизации на текущем масштабе.
• Иностранный родитель не хочет брать на себя комплаенс, HR и репортинг, который тянет за собой собственное белорусское юрлицо — даже резидент ПВТ.

ODC — правильный ответ, когда

• Команда стабилизировалась выше 20 человек и идёт в сторону 40+.
• Работа в Беларуси нуждается в коммерческой автономии — подписывать локальные контракты с поставщиками, арендовать офис, строить узнаваемость HR-бренда под собственным именем.
• Маржа EOR (обычно 8–15% от полного месячного фонда оплаты труда) ощутимо начинает превышать стоимость содержания локального юрлица. На эту строчку финдиректора возвращаются раз за разом.
• Операционный суверенитет — владение техникой, аренда офиса, отношения с локальными поставщиками — стал важен для бизнеса.
• Структурные льготы ПВТ были бы заметнее в режиме прямого резидента, чем как у клиента EOR-резидента.

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

Формат ПВТ — почему почти каждое серьёзное ODC в нём оказывается

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

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

Существенные льготы ПВТ, кратко:

• 9% подоходный налог с зарплаты инженера — против стандартных 13%.
• Взносы в ФСЗН считаются от средней по стране, а не от фактической полной зарплаты инженера. Эта структурная экономия быстрее всего накапливается на масштабе.
• 0% НДС на большинство экспортируемых IT-услуг.
• 9% налог на прибыль — против стандартных 20%.
• Сниженные ставки на дивиденды и роялти для резидентов.
• Разрешены коммерческие контракты на английском языке.
• В коммерческих отношениях допускаются элементы английского коммерческого права.
• Упрощённые процедуры по виду на жительство для иностранных IT-специалистов.

Квалификация определяется тем, попадает ли основная деятельность компании в разрешённый перечень ПВТ (разработка ПО и ряд смежных категорий — все попадают). У Министерства экономики на странице по ПВТ лежат актуальные детали. На практике иностранные IT-компании, которые соответствуют деятельности, почти всегда проходят. Процесс заявки — процедурный, а не дискреционный. Но не мгновенный. Обычно 30–60 дней с момента подачи, иногда дольше, если бизнес-план вызывает уточняющие вопросы.

Запуск юрлица, по шагам

Подробное описание всех этапов работы, без прикрас. Не контрольный список, а подробное описание последовательности действий и распределения времени. 

Тип юрлица

Большинство иностранных ODC — общества с ограниченной ответственностью (ООО). 100% иностранного владения разрешено. Местного партнёра не требуется. Минимальный уставный капитал — символический. Акционерные общества формально существуют, но под ODC используются редко. ООО — стандартный ответ; берите его, если нет конкретной причины не брать.

Регистрация

Через территориальный регистрирующий орган по району, где будет находиться юрлицо. Сама регистрация — обычно 5–10 рабочих дней с момента подачи, если документы собраны. В пакет входят учредительные документы, идентификация учредителя (апостилированная и переведённая, если учредитель иностранный), подтверждение юридического адреса и устав. Сбор пакета — вот что занимает время. Сама регистрация быстрая, когда вы готовы подавать.

Заявка на резидентство ПВТ

Отдельный процесс, обычно идёт параллельно с регистрацией юрлица или сразу после. Заявка включает бизнес-план в формате, который ожидает администрация, классификацию деятельности, учредительные документы и ряд приложений. Согласование обычно 30–60 дней. Администрация иногда возвращается с уточняющими вопросами — закладывать две недели контингентного времени на эту переписку имеет смысл.

Открытие банковского счёта

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

Налоговый учёт и валютный контроль

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

Найм и онбординг персонала

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

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

Переход с EOR на ODC — путь, на котором большинство читателей

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

Последовательность, которая работает

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

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

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

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

Перепакуйте цепочку передачи ИС. Это тот момент, когда можно починить то, что изначально не было чистым. Новая цепочка идёт инженер → ODC-юрлицо → иностранный родитель, или — если ODC прямая дочка иностранного родителя — просто инженер → ODC, и ИС перетекает наверх через владение. В любом случае получите свежие, чистые формулировки отчуждения. Не переносите слепо язык из предыдущих EOR-контрактов, не пересмотрев его.

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

Типичные ошибки на переходе

• Открыли новое юрлицо, но запустили payroll до получения резидентства ПВТ — и юрлицо первый квартал работает на не-ПВТ-стоимостной структуре, убивая экономику перехода.
• Расторгли EOR-контракты до того, как банковский счёт нового юрлица стал операционным. Так делать не надо.
• Забыли перепаковать цепочку передачи ИС. Старая цепочка (инженер → EOR → иностранный родитель) ломается, когда EOR уходит. Новая должна стоять до того, как переход завершится.
• Не общаться с инженерами заранее. К моменту, когда HR официально объясняет изменение, тревога уже разошлась неформально, и часть инженеров уже разговаривает с рекрутерами.

Операционная структура — то, что фактически использует организация 

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

Офис или удалёнка

В 2026 году белорусская ИТ-индустрия в значительной степени ориентирована на удаленную работу. Для инженеров по умолчанию используется гибридный или полностью удаленный формат работы, и компания может работать в таком режиме без строгих требований к наличию физического офиса. Тем не менее, небольшой офис в Минске свидетельствует о серьезности намерений, создает центр притяжения для команды и обеспечивает надежный адрес для посещения клиентами и партнерами. Большинство центров разработки размещаются в небольших офисах (от 200 до 500 квадратных метров) в центральных районах Минска — Ниамига, Центральный, район вокруг проспекта Победителей — с 30-50 рабочими местами для команды из 60-80 инженеров. Стоимость аренды офиса значительна, но не непомерна — типичная цена составляет от 15 до 30 долларов за квадратный метр в месяц. 

HR и payroll

Либо in-house, с нанятым HR-менеджером (плюс главный бухгалтер, который обязателен по закону), либо на аутсорсе у локального payroll-провайдера. Чаще всего — гибрид: локальный payroll-провайдер закрывает комплаенс и обработку, а senior HR-бизнес-партнёр внутри компании ведёт people-функцию. Чистый аутсорсинг работает на меньшем масштабе. Как только команда переваливает за 40 инженеров, внутренний HR начинает иметь смысл.

Комплаенс и бухгалтерия

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

Техника — закупка и жизненный цикл

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

Текущий рекрутинг

Некоторые центры разработки программного обеспечения создают внутренние команды по подбору персонала, когда численность инженеров превышает 50 человек. Большинство же продолжают сотрудничать с местным кадровым агентством для проведения постоянного поиска кандидатов, особенно на руководящие и специализированные должности. Услуги внутренних рекрутеров в белорусской IT-сфере обходятся в 2500–4500 долларов в месяц (до вычета налогов) на руководящих должностях — это доступно, но аргумент в пользу внутреннего подбора персонала заключается скорее в постоянном объеме работы, чем в снижении затрат.  Внешний IT-рекрутинг идёт по стандартному проценту от годового gross на момент найма, с условиями, которые тянут к предсказуемому объёму.

Налоговая и финансовая механика — как реально выглядит экономия

Цифры, лежащие в основе решения о переходе. Сравнение с резидентом HTP, управляющим той же командой, которая ранее работала через EOR. 

Основные налоговые различия для организации, являющейся резидентом HTP, по сравнению с организацией, не являющейся резидентом HTP (для большинства иностранных клиентов EOR является резидентом HTP, поэтому уместно сравнение HTP-ODC и HTP-EOR): 

• Подоходный налог: 9% (резидент ПВТ) — одинаково и в ODC, и в EOR, когда EOR — резидент ПВТ.
• Взносы в ФСЗН: база — средняя по стране, одинаково в обоих случаях.
• НДС на экспорт IT-услуг: 0% в обоих.
• Налог на прибыль: 9% на прибыль юрлица, применяется в обоих случаях.
• Маржа EOR: 8–15% от полного месячного payroll на устоявшихся отношениях. Это та строка, которая исчезает в ODC-кейсе.

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

Рабочий пример

Команда 25 инженеров, средний gross — $5 000 в месяц. Общий gross payroll — около $125 000 в месяц.

Полная стоимость через EOR (gross payroll + employer-side взносы + соцпакет + маржа EOR): примерно $175 000 – $190 000 в месяц. Точная цифра зависит от насыщенности соцпакета и от тира маржи EOR.

Полная стоимость в режиме ODC-резидента ПВТ под ту же команду (тот же gross, те же employer-side взносы, тот же соцпакет, без маржи EOR, плюс собственные операционные расходы юрлица — офис, бухгалтерия, HR, техника): примерно $145 000 – $160 000 в месяц.

Разница в месяц: примерно $20 000 – $30 000. В год: $240 000 – $360 000.

Стартовые расходы, которые компенсируются в первый год: примерно $30 000 – $50 000 на регистрацию юрлица, банковский онбординг, заявку в ПВТ, юридические гонорары, депозиты по аренде, закупку техники и время фаундерского внимания. Точка пересечения с EOR-моделью — обычно 12–18 месяцев с момента запуска. На больших командах быстрее. Чем крупнее команда, тем круче кривая выхода в плюс.

При численности инженеров менее 15 человек расчеты не сходятся — EOR обходится дешевле в целом. При численности инженеров более 40 человек ODC значительно дешевле. В диапазоне от 20 до 40 инженеров решение зависит от факторов, выходящих за рамки чистой стоимости — оперативного контроля, имиджа работодателя, стратегической важности белорусского подразделения для иностранной материнской компании. 

Где срываются сроки — честный раздел 

Где проекты по запуску идут не так, по наблюдениям с переходов 2024–2026 годов.

Банкинг, каждый раз

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

Апостилирование и легализация документов учредителя

Иностранные фаундеры стабильно недооценивают, сколько в их домашней юрисдикции занимает сбор документов. Нотариально заверенные и апостилированные копии учредительных документов, копии паспортов, подтверждение адреса, иногда корпоративные certificates of good standing — всё это собирается в домашней юрисдикции, потом апостилируется, потом переводится на русский (присяжный перевод признанным переводчиком), и только потом подаётся в Беларуси. Закладывайте на это четыре недели. Уходит шесть.

Уточняющие вопросы по заявке в ПВТ

Администрация ПВТ иногда возвращается с уточнениями по бизнес-плану — особенно по классификации деятельности или по проектируемой выручке. Эти вопросы — не признак проблемы. Это рутина для нестандартных кейсов. Закладывайте две недели контингентного времени на обмен уточнениями. Администрация на практике вменяемая; они просто ждут конкретики.

Валютный контроль при первом входящем платеже

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

Сотрудничество с действующим EOR

Часть EOR сотрудничает с переходом полностью и помогает по-настоящему. Часть выжимает из переходного окна дополнительную маржу. Прочтите контракт с действующим EOR на предмет расторжения, срока уведомления и положений о переходном сотрудничестве — до того, как начнёте. Планируйте соответственно. Мы видели и тот, и другой сценарий.

Коммуникация с инженерами

Разрыв между «мы переводим тебя в новое юрлицо» и «по факту для тебя ничего значимого не меняется» — это тот разрыв, в котором рождается избегаемая текучка. Брифуйте инженеров рано, по возможности индивидуально. Особое внимание — senior-контрибьюторам, чей уход во время перехода создаёт самый большой риск для поставки. Часть из них окажется самой тревожной по поводу изменений именно потому, что им есть что терять, если что-то пойдёт не так.

Главное

Запуск ODC в Беларуси — это проект, а не одно решение, исполняемое одним рывком. Сделанный аккуратно, он переводит команду в 20–40 человек с EOR-стоимостной структуры на структурно более дешёвую и операционно более контролируемую конструкцию, с экономией, которая накапливается год за годом, и постоянной базой для дальнейшего масштабирования. Сделанный плохо — это четырёхмесячный проект, который становится семимесячным, инженерная когорта, которая теряет доверие к переходу, и цепочка передачи ИС, которую приходится вычищать через полгода после старта.

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

В Recruitment.by мы работаем с иностранными клиентами по обе стороны этого решения — и с командами на EOR, которые приближаются к вопросу перехода, и с уже работающими ODC, которые ведут текущий найм. По структурной стороне ПВТ-настройки наши сервисы поддержки резидентства ПВТ и вхождения в ПВТ закрывают процесс заявки и операционный онбординг. По более широкому организационному и компенсационному дизайну при масштабировании ODC — наш HR-консалтинг ведёт стратегическую сторону. Текущий IT-рекрутинг в новое юрлицо, плюс payroll и PEO-услуги на переходный период, идут параллельно. Если хочется поговорить про ваш конкретный кейс — на пороге перехода вы или ещё раньше и просто моделируете траекторию — напишите нам.

NDA и передача прав на интеллектуальную собственность в Беларуси: защита кода при найме разработчиков дистанционно

Американская концепция «work made for hire», где работодатель владеет кодом в тот момент, когда он написан, не работает в белорусском праве. В Беларуси исключительные права на то, что создаёт ваш разработчик, принадлежат вашей компании, только если вы это четко прописали — в трудовом договоре или в отдельном соглашении о передаче прав на ИС. При пропуске этого шага права могут остаться у разработчика, а не у вас. Таким образом, можно полностью заплатить за код, которым вы на самом деле не владеете.

Добавьте сверху вопрос конфиденциальности — действительно ли ваш исходный код и дорожная карта защищены, если разработчик уйдёт? — и контролируете ли вы свой самый ценный актив или просто на это надеетесь. Эта статья объясняет, как NDA и передача прав на ИС на самом деле работают в Беларуси, ошибку с «work for hire», на которой спотыкаются иностранные компании, и что нужно, чтобы защитить код, когда люди, его пишущие, работают удаленно. Одна заметка сразу: это общая информация от людей, которые работают рекрутерами на этом рынке, а не юридическая консультация по вашим конкретным соглашениям — для них используйте квалифицированного белорусского юриста по ИС.

Ошибка, которая стоит компаниям кода

Иностранные компании — особенно привыкшие к американским правилам — склонны верить, что заплатить разработчику значит владеть тем, что разработчик производит. Деньги переходят из рук в руки, код пишется, код ваш. По американскому «work made for hire» это в целом верно для сотрудников. В Беларуси эта опция не является настройкой по умолчанию.

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

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

Передача прав на ИС — как реально владеть тем, за что платишь

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

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

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

Сотрудник против подрядчика 

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

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

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

NDA и режим коммерческой тайны 

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

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

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

Почему нельзя опираться на условия о неконкуренции

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

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

Практический чек-лист — защита кода при найме сотрудников на удаленную работу в Беларуси

Это стандартная практика, и компании, которые попадают впросак, почти всегда те, что предположили применимость американских правил. Коротко:

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

Два кейса из практики

Кейс А. Подрядчик, которому принадлежал код

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

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

Кейс Б. NDA, который устоял

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

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

Защищайте по-настоящему

Когда вы нанимаете удалённых разработчиков в Беларуси, владение вашим кодом и защита ваших секретов не автоматические — это результат двух правильно сделанных соглашений. Белорусское право не вручает вам владение так, как американское work for hire; вы должны обозначить его явно, и чаще всего — с подрядчиками. NDA, построенный на реальном режиме коммерческой тайны, работает потому что конфиденциальность имеет силу, только когда вы приняли меры, которых требует закон. Условия о неконкуренции вас не спасут. Передача прав и режим — спасут.

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

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

Опционы и долевое участие для белорусских ИТ-сотрудников: что законно возможно

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

Может ли белорусский сотрудник законно получить иностранную долю и пользоваться ей? Что происходит в этот момент с налогами? Усложняет ли дело валютный контроль? Большинство онлайн-гидов по долям написаны для того, кто сидит в Сан-Франциско или Берлине, и они представляют налоговый и правовой фон, которого попросту нет, когда сотрудник в Минске.

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

Механика — опционы против RSU и как вообще работает доля

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

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

Реальность иностранной компании — почему это почти всегда трансграница

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

Налоговая реальность — доход из иностранного источника, самодекларируемый

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

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

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

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

Валютная и бумажная сторона

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

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

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

В чём стоит быть реалистом?

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

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

Для работодателей и рекрутеров — предложение доли белорусским талантам

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

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

Вывод

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

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

Проверка кандидатов в Беларуси: правовые ограничения и практические альтернативы для IT-найма

Этот разговор у нас был раз сорок. Американская или немецкая IT-компания нанимает первого разработчика в Минске. HR-руководитель присылает стандартную форму предварительного скрининга — справка о несудимости, проверка кредитной истории, иногда проверка на полиграфе, спрятанная в приложении для сениоров. Белорусский кандидат читает форму. Вежливо отвечает. Снимает кандидатуру. Рекрутёр звонит нам в недоумении. Мы объясняем, что большую часть из того, что было в этой форме, белорусский работодатель не вправе требовать с кандидата на IT-роль. Не на усмотрение. Не предмет торга. Не то, на чём стоит настаивать сильнее. Эту форму надо убрать. Подставить другую.

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

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

Три закона, которые надо знать до того, как составлять форму скрининга

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

Трудовой кодекс

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

Закон о защите персональных данных

Закон № 99-З от 7 мая 2021 года. По структуре опирается на GDPR. По существу — материально отличается там, где это важнее всего для найма. Главное отличие: «законный интерес» как самостоятельное основание обработки в белорусском законе не работает так, как в GDPR. Тот вариант, на который вы обычно опираетесь в ЕС, чтобы обосновать проверку, здесь просто не существует. Основную работу делает согласие — а это значит, что документ согласия весит больше, чем в практике ЕС, и слабая редакция отваливается раньше и громче.

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

Указ Президента № 422 от 28 октября 2021 года

Административная надстройка. Надзорный орган — Национальный центр защиты персональных данных. Практические обязанности вашего работодателя (оператора данных) включают ведение учёта обработки, документирование согласия, защиту трансграничных передач и способность подтвердить соответствие по запросу. Сам Указ и сопутствующие акты публикуются на Национальном правовом интернет-портале; Центр размещает свои разъяснения и надзорные материалы на cpd.by. Оба адреса стоит сохранить ещё до первого найма — материалы обновляются, рамка двигается.

Что вы реально можете проверять

Операционная карта. Что допустимо — при правильной рамке согласия — на IT-роль в Беларуси. Прочитайте медленно. Поле уже, чем ожидает американский плейбук, и шире, чем кажется при пессимистичном чтении.

Стандартная проверка по статье 26

• Идентификация по паспорту. Стандарт. Часть документного пакета, который смотрит любой белорусский работодатель.
• Документы об образовании и дипломы. Тоже статья 26. Подтверждается напрямую с вузом — большинство учреждений в Беларуси и за рубежом подтверждают факт обучения по простому запросу.
• Трудовая книжка, подтверждающая предыдущую работу в Беларуси. Белорусский документ. Кандидат показывает, вы смотрите. Дополнительный механизм не нужен.

Допустимо при наличии согласия

• Сбор отзывов от предыдущих работодателей. Письменное согласие кандидата. Готовность предыдущего работодателя ответить. На белорусском IT-рынке часто работает — сообщество небольшое, люди поддерживают связи, рекомендации идут через реальные отношения, а не через переписку HR — HR.
• Подтверждение профессиональных сертификаций. AWS. Microsoft. Google Cloud. ISTQB. CKAD. Кандидат указал — сертифицирующий орган подтвердил. Прямо, быстро, без минного поля приватности.
• Обзор публично доступных соцсетей. LinkedIn, публичный GitHub, публичный X. Даже публичный контент — это персональные данные, обработка которых попадает в рамку: нужно согласие и нужна соразмерность роли.
• Технические оценки. Кодинг-задачи. Сессии по системному дизайну. Тестовые проекты. Главный сигнал для IT-найма — и вне минного поля персональных данных полностью.

Требует отдельного правового основания — и для обычных IT-ролей недоступно

• Справка о несудимости. По закону предусмотрена для должностей в системе госбезопасности, правоохранительных органах, образовании, здравоохранении, финансовом секторе, таможне и ряде других регулируемых сфер. IT-разработчик, дизайнер, продакт-менеджер, QA-инженер, дата-инженер, DevOps — не из этого списка.
• Кредитная история. В общем случае для найма не запрашивается без специального регуляторного основания. Узкое исключение — старшие позиции в регулируемых финансовых организациях.
• Медицинский осмотр. Только если роль попадает под законодательно установленное требование о медицинской пригодности. Для общего IT-работодателя — недоступный инструмент.
• Полиграф или психологическое тестирование. Жёстко ограничено. Требует специального законодательного основания для роли. Количество IT-ролей с таким основанием — близко к нулю.

Вопрос со справкой о несудимости (где спотыкается каждый иностранный клиент)

Иностранные IT-работодатели просят это постоянно. Для роли почти всегда неуместно. Отдельный раздел потому, что ошибка распространённая, правовая экспозиция избегаема, а разговор к этому моменту знаком наизусть.

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

Для большинства IT-ролей — нет. Причины ниже.

• В белорусском трудовом праве нет общей модели «мы проверяем всех на несудимость». Проверка законодательно привязана к конкретным категориям должностей. Разработчик ПО — не категория. И продакт-менеджер не категория, и дизайнер, и QA, и большинство стандартных IT-должностей. 
• В любом случае, требование предоставления персональных данных в качестве условия договора создает два уровня риска. Риск, связанный с Законом о защите персональных данных (PDP), в случае сбора персональных данных без законных оснований. Риск, связанный с Трудовым кодексом, в случае требования документов, не включенных в список статей 26, в качестве условия приема на работу. Ни один из этих рисков не является теоретическим. 
• Добровольное предоставление — это другой подход. Кандидат может добровольно получить и предоставить сертификат. Работодатель может добровольно его принять. Разные правила, разные риски. Но подлинное согласие должно быть действительно добровольным — не полученным под угрозой отзыва предложения. 
• К немногочисленным исключениям относятся: должности, связанные с государственной тайной, некоторые должности в сфере финансовых услуг, регулируемые Национальным банком, должности в сфере безопасности критической инфраструктуры, а также ИТ-специалисты, работающие в смежных с здравоохранением областях и обрабатывающие конфиденциальные медицинские данные. Каждая из них требует отдельного анализа. 

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

Соцсети

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

• Публичный контент. LinkedIn, открытый X, открытый GitHub. В принципе можно смотреть — но просмотр обрабатывает персональные данные, а значит, согласие и соразмерность применяются. Пропустить ни одно из этих требований нельзя только потому, что контент был открытым.
• Закрытый контент. Facebook «только для друзей», закрытый Instagram, что угодно за подпиской или за запросом дружбы. Под запретом. Попытка доступа через обман или прикрытие — это явная экспозиция по Закону о персональных данных.
• Кеш, архивы, исторический контент. Те же правила, что и для актуального. Найденность не равна правомерности обработки. То, что Google выдаёт пост с форума 2014 года, не делает этот пост свободным к использованию против кандидата.
• Пропорциональность. Руководители высшего звена, работающие с общественностью, могут оправдать более тщательную проверку. Разработчики бэкенда — нет. Закон о защите персональных данных требует от контролера продемонстрировать правовое обоснование и пропорциональность обработки — и то, и другое, но не что-то одно. 
• Документация. Центр может запросить у оператора подтверждение соответствия. Заявление «Мы проверили их профиль в LinkedIn» должно соответствовать документированной структуре — цель, правовое основание, срок хранения. 

Трансграничная передача данных (ловушка для EOR-конструкций)

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

Данная система требует от юрисдикции назначения обеспечения «адекватного уровня защиты» прав субъектов данных. Белорусские критерии адекватности не идентичны критериям GDPR.  Практические группы:

• Страны-члены ЕС. В целом — адекватные. Членство в Конвенции 108 Совета Европы тут играет.
• Страны ЕАЭС — Россия, Казахстан, Армения, Кыргызстан. Прямо признаются адекватными рамкой.
• Соединенные Штаты. Ситуация более сложная. Зависит от конкретной организации, действующих договорных гарантий и типа потока данных. Не делайте предположений — проверяйте. 
• Другие направления, для которых недостаточны меры защиты — требуются конкретные договорные гарантии или явное информированное согласие субъекта данных на передачу. 

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

Что реально работает для IT-найма

В чем суть статьи? В реальных методах, работающих в рамках закона, и обеспечивающих лучшие результаты при найме, чем тот тип проверки документов, к которому по умолчанию прибегают иностранные IT-работодатели. 

Техническая оценка как главный сигнал

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

Сбор рекомендаций, который реально что-то значит

Прямые звонки предыдущим руководителям с письменным согласием кандидата. Готовность предыдущего работодателя говорить. Подтверждение дат работы, роли, объёма, причины ухода. Конкретные поведенческие вопросы вместо общих «нанял бы снова?» — на которые приходят расплывчатые позитивные ответы независимо от реальной картины. Сверка рассказа кандидата с несколькими независимыми точками. Допустимо. Работает. Не используется, потому что занимает время, а рекрутёр в спешке.

Идентификация и подтверждение квалификаций

Проверка документов по статье 26 закрывает идентификацию и предыдущую работу в Беларуси. По квалификациям — напрямую к сертифицирующему органу: Microsoft, AWS, Google Cloud, ISTQB, вендорские центры сертификации. Подтверждение образования через университет. Сверка LinkedIn по датам, ролям, объёму — только публичный контент. Стандартная история.

Испытательный срок — ваша настоящая страховка. 

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

Работа с опытным локальным кадровым партнёром

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

Особенности для резидентов ПВТ

Коротко, но стоит выделить — клиентская база фирмы сильно пересекается с резидентами Парка высоких технологий.

Резидентство в ПВТ упрощает многие HR-процессы и приносит реальные налоговые преимущества. Но рамку Закона о персональных данных оно не меняет. Резиденты ПВТ, обрабатывающие персональные данные, работают по тем же ограничениям, что и все остальные — те же требования к согласию, те же ограничения статьи 26 ТК, та же архитектура трансграничной передачи. Гибкость ПВТ по трудовым условиям (наём иностранных работников, типы договоров, удалённая работа) не распространяется на смягчение правил обработки персональных данных. Некоторые новые резиденты ПВТ считают, что льготы покрывают и это. Не покрывают — и узнавать об этом на собственном опыте удовольствия не доставляет.

Наша поддержка по входу в ПВТ закрывает заявку и процесс входа. HR-процессы внутри рамки ПВТ всё равно следуют стандартной архитектуре Закона о персональных данных.

Согласительный документ — место, где сосредоточена большая часть юридической работы. 

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

Работающее согласие на обработку персональных данных при IT-найме должно:

• Идентифицировать оператора данных — работодателя или кадровое агентство, если у агентства статус оператора.
• Перечислить категории обрабатываемых персональных данных. Идентификационные. Контактные. Профессиональные. Образовательные. Рекомендательные. Конкретные категории, а не общая корзина «всё что угодно».
• Укажите цели обработки данных. Оценка кандидатов. Трудовые отношения. Расчет заработной платы. Соблюдение нормативных требований. Каждая указанная цель должна быть обоснована сама по себе. 
• Указать правовое основание — согласие по Закону о персональных данных плюс законодательное основание для данных по статье 26 ТК, где это применимо.
• Перечислите третьих лиц, которые получат данные. Поставщик услуг EOR. Поставщик услуг по расчету заработной платы. Материнская компания. Кадровое агентство. Поставщик услуг по проверке биографических данных (если используется). Все указанные лица. 
• Указать направления трансграничной передачи и правовое основание каждой. Адекватность, договорные гарантии или явное согласие — на каждое направление.
• Четко определите срок хранения данных. Для кандидатов, не прошедших отбор, — только на тот период, который необходим для процесса найма и в целях защиты интересов — обычно это от шести до двенадцати месяцев. Для успешно принятых на работу сотрудников данные переносятся в рамки трудовых отношений. 
• Проинформируйте кандидата о его правах в соответствии с Законом о защите персональных данных. Доступ. Исправление. Удаление. Отзыв согласия. Каждое из этих действий должно быть подробно описано. 
• Предоставьте кандидату возможность отдельно давать согласие на конкретные виды обработки данных, если это необходимо. Например, проверка публикаций в социальных сетях может быть предоставлена ​​в качестве отдельного варианта согласия. 

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

Два возможных кейса 

Сценарий А. Американская финтех-компания, которая усвоила урок на собственном горьком опыте. 

Американская финтех-компания, раунд финансирования серии B, запускает глобальную программу найма. Стандартная внутренняя политика: проверка на наличие судимости обязательна для каждой должности, в каждой стране, без исключений. Американский рекрутер отправил форму согласия первому кандидату на должность старшего разработчика из Беларуси — кандидат с хорошими техническими навыками, прошедший шестинедельный опыт работы. Кандидат прочитал форму. Вежливо отказался. Отказался от участия в процессе. Рекрутер обратил на это внимание. В течение следующих десяти дней еще пять кандидатов из короткого списка выразили аналогичную обеспокоенность. Нас привлекли для переработки системы отбора для Беларуси. Мы сохранили глубину технической оценки — ту часть, которая действительно дает результат. Сохранили систему критериев. Отменили обязательную проверку на наличие судимости. Переработали документ о согласии в соответствии со стандартами Закона о защите персональных данных. Вакансия была заполнена через шесть недель. Теперь эта система применяется ко всем остальным вакансиям компании в Центральной и Восточной Европе. 

Сценарий B. Берлинский стартап с правильной настройкой EOR (Enterprise Operations Review) 

Берлинский стартап нанимает двенадцать белорусских разработчиков через белорусскую систему EOR. Немецкий подход к найму основывался на рекомендациях предыдущих работодателей как на основном сигнале. Мы помогли структурировать систему согласия в соответствии со стандартами Закона о защите персональных данных. Настроили архитектуру трансграничной передачи данных, чтобы немецкая головная компания могла получать доступ к данным отдела кадров через соответствующие каналы. Встроили трехмесячный испытательный срок в процесс найма в качестве практического фильтра производительности — контрольные точки на 30, 60 и 90 дней, а собеседование на 90-й день стало реальным решением о приеме на работу или отказе. 

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

Разные профили. Один и тот же основной урок. Белорусская система работает, если она правильно разработана с самого начала. Ошибка, которую допускают иностранные IT-работодатели, заключается не в несоблюдении белорусского законодательства, а в предположении, что их собственная стратегия работы будет применима без изменений. Это не так. Но перепроектирование не так уж и сложно, если им всё объяснить. 

Структура принятия решений — на что именно следует обращать внимание при отборе кандидатов 

Практический чек-лист. Распечатайте, отдайте рекрутёру.

Всегда (правовая чистота для любой IT-роли)

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

Для руководящих или ответственных должностей (при наличии надлежащей системы согласования) 

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

Только для специально регулируемых ролей

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

Никогда (без специального законодательного основания)

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

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

Можно ли требовать белорусскую справку о несудимости на senior-разработчика?

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

Наша американская материнская проверяет всех. Почему мы не можем делать так же в Беларуси?

Различная правовая база. В США проверка биографических данных основана на Законе о справедливом кредитном отчёте и практически повсеместной культуре должной осмотрительности при приёме на работу. Белорусское трудовое законодательство ограничивает перечень требований работодателя определённым списком. Закон о защите персональных данных ещё больше ограничивает обработку данных. Американская, британская и немецкая практика не может быть адаптирована без переработки. Эта система работоспособна — просто не путём полного переноса американской версии. 

А если кандидат сам приносит справку?

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

Закон о персональных данных применяется, если мы используем американское рекрутинговое агентство?

Да. Если агентство обрабатывает персональные данные белорусских резидентов, закон до него дотягивается. Экстерриториальное действие, как у GDPR. Агентство должно быть настроено под соответствие, с правильно заключёнными договорами обработки между агентством, EOR (если есть) и материнской компанией. Все три стороны треугольника должны быть выровнены. Пропустить одну — сломать конструкцию.

Сколько можно хранить данные неуспешных кандидатов?

Хранить резюме следует только в течение времени, необходимого для процесса подбора персонала и любых связанных с этим целей защиты. Обычно это от шести до двенадцати месяцев, хотя оптимальное количество зависит от должности и потенциального риска возникновения споров. Срок хранения должен быть четко указан в соглашении. Бессрочное хранение не допускается, а фраза «мы храним резюме вечно» может стать причиной проверки со стороны Центра. 

Что будет, если всё-таки нарушить?

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

Решающая структура, которая действительно работает 

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

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

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

GDPR-комплаенс для белорусских IT-вендоров, работающих с EU-клиентами

Картинка, которую мы наблюдаем последние пару лет.

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

Блокер обычно сидит в разговоре про данные. Иногда формально — GDPR-проверка не проходит по какому-то конкретному пункту. Чаще неформально — внутренний комплаенс-отдел EU-клиента ставить Беларусь в качеств красного флага, как третью страну, прокьюремент тяжелеет, сделка съезжает на квартал и в итоге уходит в Варшаву или Бухарест.

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

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

Стартовый факт, который многие понимают неправильно

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

По GDPR, персональные данные жителей ЕС свободно ходят внутри Европейской экономической зоны, плюс в небольшой список стран, которые Еврокомиссия признала «адекватными» — Великобритания, Швейцария, Япония, Южная Корея, Израиль, ещё несколько. Беларуси в этом списке нет. Поэтому любая передача персональных данных от EU-клиента к белорусскому процессору — это передача в третью страну, и включается Глава V GDPR. Нужно дополнительное правовое основание. Почти всегда это Стандартные договорные условия Еврокомиссии — и со времён решения Schrems II в 2020 году, плюс Transfer Impact Assessment поверх.

Тут белорусские IT-компании иногда возражают: «У нас же есть соответствие белорусскому закону о защите персональных данных. Закон № 99-З от 2021 года. Этого недостаточно?»

Достаточно для того, что белорусское право требует от вас на территории Беларуси. Не заменяет механику со стороны ЕС. Белорусский закон в целом построен на принципах GDPR, но Еврокомиссия его адекватным не признала, и EU-клиенты продолжают трактовать Беларусь как третью страну. Локальный комплаенс необходим — он просто не самодостаточен. Документация по передаче должна быть у EU-клиента независимо от того, что вы там настроили локально.

Это не уникальная для Беларуси ситуация. Большинство стран за пределами ЕЭЗ в той же позиции. Просто стоит понимать, что «у нас есть Privacy Policy с упоминанием GDPR» в европейском прокьюремент-разговоре весит сильно меньше, чем некоторым белорусским вендорам кажется.

Что EU-клиенты реально спрашивают — и о чём на самом деле беспокоятся

По разговорам с клиентами с обеих сторон наших сделок, вопросы, которые мы слышим в прокьюременте чаще всего:

• «Где находятся данные?» — хотят понять, уходят ли персональные данные физически за пределы ЕС.
• «Где находятся ваши инженеры?» — потому что доступ белорусского инженера к данным, лежащим в EU-датацентре, по GDPR сам по себе является передачей, даже если сами данные никуда не двигаются.
• «У вас подписаны Стандартные договорные условия?» — в 2026 году это уже table stakes, а не преимущество.
• «Вы делали Transfer Impact Assessment по Беларуси?» — в 2025–2026 годах спрашивают всё чаще; ещё пару лет назад спрашивали редко.
• «Что белорусское законодательство говорит про доступ государства к персональным данным?» — это Schrems II-вопрос, применённый напрямую к вашей юрисдикции.
• «Вы GDPR-compliant?» — вопрос, который значит не совсем то, как звучит. Имеется в виду: можете ли вы подписать наш DPA, пройти наш security review и не создать проблему нашему комплаенс-отделу.
• «У вас есть Data Protection Officer?» — иногда требуется по закону, чаще ожидается и там, где закон не требует.

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

Проблема Schrems II — на обычном языке

В июле 2020 года Суд ЕС вынес решение по делу Schrems II, которое изменило практический разговор про передачу данных в третьи страны. Громкая часть решения — Privacy Shield между ЕС и США признан недействительным. Более широкая часть, важная для всех остальных — одних SCC недостаточно.

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

Через год Европейский совет по защите данных (EDPB) выпустил рекомендации по этим дополнительным мерам, и эти рекомендации сейчас лежат в центре любого серьёзного прокьюремент-ревью с участием вендора из третьей страны. Для вендора из Беларуси честный TIA включает белорусский закон о защите персональных данных как локальную рамку, операционную реальность государственного доступа к данным белорусских компаний, и конкретные дополнительные меры, которые вендор применяет для митигации рисков.

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

Тут отделяется полезный TIA от бесполезного. TIA, который пишет «по Беларуси никаких рисков, дополнительные меры не нужны» — это документ, который провалит ревью у любого серьёзного комплаенс-офицера на EU-стороне. TIA, который пишет «вот реальные риски в части государственного доступа, вот конкретные меры, которые мы применяем, вот почему именно эти данные можно передавать именно с этими ограждениями» — это документ, который EU-комплаенс реально примет. Честность в оценке — то, что её утверждает.

Контрактный слой — SCC, DPA и чего ждёт иностранный юрист

Контрактный стек, который белорусский вендор должен иметь под EU-работу, в 2026 году довольно стандартный. Три документа делают основную работу.

Стандартные договорные условия (2021)

Обновлённая редакция SCC от Еврокомиссии принята в июне 2021 года и с тех пор работает как практический инструмент передачи. Сделаны модульно — controller-to-controller, controller-to-processor, processor-to-processor — и белорусский вендор подписывает тот модуль, который соответствует его роли. Чаще всего это processor или sub-processor. Официальный текст и руководство — на странице SCC у Еврокомиссии.

Data Processing Agreement (статья 28 GDPR)

EU-клиент как controller хочет DPA, который описывает scope обработки, цели, категории данных, меры безопасности, правила по sub-процессорам, механику уведомлений об инцидентах и аудиторские права. Иногда DPA — отдельный документ; иногда оформляется как приложение к основному соглашению об услугах. Задача белорусского вендора — внимательно прочитать его до подписания, а не после.

Документация по цепочке sub-процессоров

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

Одна ошибка, которую мы регулярно видим. EU-прокьюремент кладёт перед белорусским вендором свой стандартный DPA, и вендор подписывает его, не вчитываясь в операционные обязательства. Через год что-то происходит — небольшой инцидент с данными, смена sub-процессора, запрос на аудит — и в фокус попадают обязательства, которые вендор по факту не может выполнить. Сроки уведомления, привязанные к нереалистичным цифрам. Аудиторские права, требующие раскрытия того, что по локальному законодательству раскрыть нельзя. Договаривайтесь на стадии подписания. Не бойтесь править DPA. EU-клиенты уважают вендора, который читает то, что подписывает, сильнее, чем того, кто просто подписывает.

Технический и организационный стек, который реально работает

Помимо бумаг есть операционный стек, который захочет увидеть security-команда EU-клиента. Практические дефолты для белорусского IT-вендора, работающего с EU-заказчиками в 2026 году:

• EU-хостинг по умолчанию. AWS Frankfurt, Azure West Europe, Google Cloud Belgium. Одно это решение снимает существенную часть разговора про передачу — данные физически остаются в ЕС, а трансграничной становится только сторона доступа.
• Контроль доступа и логирование аудита. Кто к каким данным обращался, когда, с какой целью. Хранится столько, сколько требует контракт и ваша юрисдикция. Доступно EU-клиенту по запросу во время аудита.
• Шифрование в передаче (TLS) и в покое, с ключами в ЕС там, где сценарий позволяет. Шифрование — одна из ключевых дополнительных мер, на которые ссылается EDPB.
• Псевдонимизация и минимизация данных. Инженеры, работающие с реальными клиентскими данными, должны иметь доступ к минимально необходимому срезу, по возможности псевдонимизированному. «Продакшн-данные на ноутбуке разработчика» — один из самых быстрых способов провалить security review.
• Назначенный DPO, где требуется по статье 37 GDPR — крупномасштабный систематический мониторинг, крупномасштабная обработка специальных категорий данных. Даже там, где формально не требуется, наличие назначенного DPO с контактами сигналит серьёзность.
• Документированная процедура уведомления об инциденте с часами в 72 часа. Процедура должна быть написана, протестирована и известна команде. Не придумываться в момент, когда что-то реально произошло.
• Поддерживаемый список sub-процессоров, раскрытый клиенту, с согласованной механикой уведомления об изменениях.

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

То, о чём не принято говорить открыто: санкционная надстройка

Вот раздел, который отделяет честную статью от маркетингового материала. У части EU-клиентов есть внутренние прокьюремент-политики, которые идут шире, чем требует GDPR. Они не работают с вендорами из стран в определённых санкционных списках — независимо от того, насколько чисто настроена GDPR-сторона. Это не вопрос по GDPR. Это вопрос корпоративной политики. И это всё чаще становится реальной причиной, по которой белорусские IT-вендоры теряют европейские сделки.

Формальный GDPR-разговор можно пройти. Внутренний политический фильтр пройти сложнее, потому что это не правовой тест — это тест на risk appetite, который ставит руководство комплаенс-функции у EU-клиента. Иногда планка из Беларуси недосягаема, независимо от того, насколько хорошая у вендора документация. Иногда это управляемо, но требует от вендора думать о структуре, а не только о комплаенсе.

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

Только Беларусь, с сильной документацией

Вендор заключает контракты напрямую из Беларуси, с SCC, DPA, TIA и полным операционным стеком. Работает с небольшими EU-клиентами без ограничивающих прокьюремент-политик; работает и там, где отношения сложились до того, как политика затянулась. Дёшево по setup. Не пройдёт у энтерпрайзов с жёсткими политиками по третьим странам.

Беларусь плюс EU-юрлицо

Вендор открывает дочернюю компанию или филиал в одной из EU-юрисдикций — Польша, Литва, Кипр — встречаются чаще всего. Это юрлицо заключает контракт с EU-клиентами напрямую. Белорусская компания становится внутриенним со-процессором под основным контрактом EU-дочки. Заметно проще проходит прокьюремент. Дороже в открытии и поддержании. Не убирает базовую GDPR-механику — внутригрупповая передача всё равно требует SCC и TIA — но меняет коммерческий фасад на тот, который EU-прокьюременту принять проще.

Белорусский вендор как субподрядчик под EU-генподрядчиком

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

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

Типичные ошибки белорусских IT-вендоров

Закономерности, которые мы видим стабильно.

Принимать комплаенс за Privacy Policy на сайте

«У нас на сайте есть GDPR-compliant Privacy Policy». Это нужно, но это не то, что спрашивает прокьюремент-ревью у EU-клиента. Они спрашивают про операционную систему — задокументированную, проверяемую, защитную под нагрузкой. Privacy Policy — это обложка. Содержание — это операционный стек за ней.

Подписать DPA EU-клиента, не вчитываясь в операционные обязательства

В DPA от EU-прокьюремента иногда лежат обязательства, которые белорусский вендор по факту не может исполнить как написано. Сроки уведомления, привязанные к конкретным локальным нормам. Аудиторские права, конфликтующие с белорусскими нормами о конфиденциальности. Требования прямого уведомления субъектов данных, не подходящие под операционную реальность. Подпись без чтения создаёт проблемы, которые всплывают через год во время аудита. Прочитать. Поправить. Подписать — в таком порядке.

Нет задокументированного Transfer Impact Assessment

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

Инженеры работают с реальными данными клиента без контролей

Продакшн-данные на личных ноутбуках. Дампы баз, отправленные через мессенджеры. Реальные записи EU-клиентов, использованные в dev-окружениях, потому что генерировать seed data — морока. Какая-то версия этого всплывает на каждом аудите. Лечится технически и организационно — контролируемые окружения, псевдонимизированные dev-данные, реальное логирование доступа.

Нераскрытые sub-процессоры

Облачный провайдер, почтовый сервис, мониторинг, аналитика. Каждый из них может обрабатывать персональные данные ЕС от вашего имени, и каждый должен быть в задокументированном списке sub-процессоров, раскрытом EU-клиенту. Нераскрытый sub-процессор — один из самых быстрых способов провалить аудит.

Считать локальный комплаенс заменой механике GDPR

Уже говорили выше, повторим, потому что это фундамент. Соответствие белорусскому закону о защите персональных данных нужно для ваших локальных обязательств. Не заменяет SCC, TIA и Article 28 DPA на EU-стороне. Два режима живут параллельно.

Короткий setup-чеклист

Сделан так, чтобы можно было сохранить и переслать внутрь команды.

• Стандартные договорные условия (модульная версия 2021) подготовлены и подписаны с EU-клиентами.
• Шаблон DPA вычитан юристом, с обозначением жёстко закрытых для торга пунктов.
• Задокументированный Transfer Impact Assessment по Беларуси, доступный по запросу, обновляется ежегодно.
• EU-хостинг как дефолт там, где сценарий позволяет.
• Контроль доступа и логирование аудита, со сроками хранения, согласованными с контрактом.
• Шифрование расписано — алгоритмы, управление ключами, охват.
• Псевдонимизация и минимизация данных в dev- и test-окружениях.
• DPO назначен там, где требует статья 37, с открытыми контактами.
• Процедура уведомления об инциденте задокументирована, протестирована и известна команде.
• Список sub-процессоров поддерживается, раскрыт клиентам, с механикой уведомления об изменениях.
• Вся клиентская документация — на английском, структурирована под прокьюремент-ревью, а не под внутреннее использование.

FAQ

Нам обязательно открывать EU-юрлицо, чтобы работать с EU-клиентами?

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

Белорусский закон о защите персональных данных эквивалентен GDPR?

Он построен на принципах GDPR в общих чертах, но Еврокомиссия его адекватным не признала. EU-клиенты трактуют Беларусь как третью страну для целей передачи. Локальное соответствие нужно для ваших локальных обязательств — оно не заменяет механику со стороны ЕС. Две рамки работают параллельно.

Как выглядит Transfer Impact Assessment по Беларуси на практике?

Документ — обычно 8–15 страниц у типового вендора — который описывает, какие персональные данные передаются, оценивает риски по белорусскому законодательству и практике (включая вопросы государственного доступа) и документирует дополнительные меры, которые применяются для митигации этих рисков. Шифрование, псевдонимизация, контроли доступа, контрактные ограждения. Честный TIA признаёт риски — он не делает вид, что их нет. EU-комплаенс-команды больше доверяют честным оценкам, чем успокаивающим.

Можно ли просто подписать DPA EU-клиента без правок?

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

Нужен ли нам DPO?

Статья 37 GDPR описывает, когда DPO обязателен. Грубо: государственные органы; компании, чья основная деятельность включает крупномасштабный систематический мониторинг субъектов данных; компании, чья основная деятельность включает крупномасштабную обработку специальных категорий данных. Для большинства белорусских IT-сервисных вендоров формальное назначение по закону не требуется. Но многие EU-клиенты его ждут, и наличие назначенного DPO с подготовкой и опубликованными контактами сигналит серьёзность независимо от строгой правовой позиции.

А EU AI Act — к нам применяется?

AI Act, в силе с 2024 года с поэтапным применением до 2027-го, применяется к провайдерам и пользователям AI-систем, чей результат используется в ЕС, независимо от того, где находится провайдер. Если вы делаете AI-фичи, которые используют EU-клиенты, вы скорее всего попадаете под часть обязательств. Эта работа отдельна от GDPR, но всё чаще всплывает в том же прокьюремент-разговоре. С юристом стоит обсуждать как отдельный поток.

Меняет ли резидентство ПВТ наш GDPR-разговор?

Само по себе резидентство ПВТ позицию по GDPR не меняет — Беларусь всё равно остаётся третьей страной. Но режим ПВТ поддерживает англоязычные контракты, элементы английского коммерческого права в коммерческих отношениях и безбумажный контрактинг — всё это делает EU-контрактный разговор глаже. Большинство белорусских IT-компаний, которые успешно работают с EU-клиентами, — резиденты ПВТ. Это не совпадение.

Мы теряем EU-сделки из-за GDPR или из-за санкций?

Честно — часто из-за и того, и другого, и эти две темы запутываются в одном прокьюремент-разговоре. Формальный GDPR-ревью можно пройти с правильной документацией. Внутренний политический фильтр — у части EU-клиентов есть прописанные политики, исключающие вендоров из Беларуси независимо от GDPR-документации — пройти труднее. Если пайплайн стабильно подвисает на комплаенс-шаге, структурные ответы (EU-дочка, отношения через EU-генподрядчика) иногда полезнее, чем дополнительная документация. Диагностируйте, что именно у вас, до того как тратиться на лечение.

Главное

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

Большая часть этого решаема. SCC и шаблон DPA собираются за квартал. Честно написанный TIA — за пару недель. Операционный стек — EU-хостинг, контроли доступа, шифрование, псевдонимизированные dev-данные — стандартная энтерпрайз-работа, хорошо понимаемая инженерными командами в ПВТ. Структурная часть более масштабная и дорогая, но именно там часто и расчищаются самые упрямые блокировки пайплайна.

В Recruitment.by мы работаем с белорусскими IT-компаниями на стороне команд — собираем команды под EU-контракты, поддерживаем работу в режиме ПВТ для вендоров, строящих правильную структуру, помогаем войти в ПВТ тем, кто ещё снаружи, и закрываем HR-консалтинг по организационной части комплаенс-настройки. 

Бонусы и структура компенсации в IT-компаниях Беларуси: что реально мотивирует разработчиков

Вот что мы клиентам говорим годами.

Две компании. Одинаковая работа. Обе платят senior backend разработчику примерно одно и то же — расхождение пять, может десять процентов на gross. Одна удерживает этого разработчика четыре года. Вторая теряет его через четырнадцать месяцев. Та же роль, те же деньги, совершенно разный исход.

Зарплата была не тем фактором. По отдельности она почти никогда не тот фактор.

После десяти с лишним лет закрывания разработчиков в белорусских IT-компаниях — и довольно часто наблюдая, как те же разработчики возвращаются к нам через полтора года — мы можем сказать, в чём дело обычно. Дело в том, как собрана структура бонусов и компенсации. Насколько предсказуемо ощущается разговор в конце года. Привязан ли performance-бонус к вещам, на которые инженер реально может повлиять. Реальная долгосрочная часть — или просто строка в оффер-леттере. Выдерживает ли вся конструкция, когда разработчик объясняет её жене за кухонным столом.

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

Почему одной зарплаты больше не хватает

В 2023 и 2024 годах зарплатная картина в IT-Беларуси была нестабильной. Цифры двигались быстро в обе стороны. К 2026 году всё устаканилось. Большинство компаний, которые конкурируют за senior-кадры, плотно стоят вокруг одних и тех же базовых вилок, а сами вилки не сильно гуляют от квартала к кварталу.

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

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

Когда мы видим, что senior-разработчик уходит из компании в 2026 году, дело почти никогда не в базе. Почти всегда — в том, что структура выше базы ощущается непрозрачной, произвольной или просто заброшенной. И неудобный момент в том, что починить это в основном бесплатно по деньгам. Это стоит внимания.

Четыре уровня — и почему большинство компаний нормально собирают только один

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

• Уровень 1 — базовая зарплата. Фиксированная, предсказуемая. Платит счета. Не мотивирует, но её отсутствие демотивирует мгновенно.
• Уровень 2 — годовой денежный бонус. 13-я зарплата, performance-бонус или их комбинация. Та часть разговора в декабре, которую все запоминают.
• Уровень 3 — долгосрочная мотивация. Equity, phantom stock, retention-бонусы. Причина, по которой senior-разработчики остаются дольше трёх лет, а не проверяют рынок каждую весну.
• Уровень 4 — неденежные мотиваторы со структурным весом. Карьерный трек, бюджет на обучение, признание, качество команды. То, чего нет в расчётке, но что объясняет большую часть истории ретеншна.

Практически каждая компания, с которой мы работаем, практически всегда предоставляет  Уровень 1. Дальше переходит на Уровень 2 и дает что-то типовое — обычно 13-ю зарплату, скопированную с того, как делают остальные. Про Уровень 3 забывают, пока не приходит этап, на котором инвесторы про это спрашивают. А Уровень 4 тихо становится тем, до чего у HR-а дойдут руки в этом квартале.

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

Уровень 1: как реально выглядит базовая зарплата в 2026 году

Честные рыночные вилки заработных плат на середину 2026 года, gross в месяц в долларовом эквиваленте, без бенефитов и накопления бонуса. Цифры двигаются квартал к кварталу, но форма устойчивая.

• Senior backend (5+ лет): $3 500 – $5 500
• Middle frontend: $2 200 – $3 500
• Senior DevOps / SRE: $3 800 – $5 800
• Senior QA / SDET: $2 800 – $4 200
• Tech Lead: $5 500 – $8 000 и выше
• Staff Engineer или Principal: $7 000 – $10 000+

Это внутренние цифры, на основе вакансий, которые мы реально закрыли за Q1 2026. Если нужен корректный разрез по стекам, грейдам и типам компаний — это покрывает наше исследование зарплат в IT.

Два структурных момента по базе, которые значат больше, чем сама цифра.

Частота пересмотров. Дефолт в IT-Беларуси раньше был раз в год. У более серьёзных работодателей в 2026-м это раз в полгода, с квартальными разговорами для высоких перформеров. Но важна тут не столько частота, сколько последовательность. Запланированный пересмотр, который стабильно съезжает — «сделаем в четвёртом квартале», который становится вторым кварталом следующего года, который становится «давайте после закрытия раунда», — это один из самых надёжных способов столкнуть senior-разработчика в режим поиска. К моменту, когда пересмотр наконец случается, у них обычно уже было два разговора с нашими консультантами.

И отдельно — про ПВТ. Компании, работающие в режиме Парка высоких технологий, считают взносы в ФСЗН со средней по стране, а не с фактической зарплаты разработчика. На senior-уровне это экономит работодателю где-то $300–$500 в месяц по сравнению с не-ПВТ-компанией при той же gross. Компании, которые удерживают лучше всех, эти деньги перекладывают в верхние слои структуры компенсации. Те, что удерживают хуже, дают им тихо растворяться в общей марже. Механика подробно — на странице Министерства экономики по ПВТ.

Уровень 2: годовой бонус — три схемы и три разных подхода

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

Чистая 13-я зарплата

Один месячный оклад, выплата в декабре, без вариации по перформансу. Получают все, кто числится 31 декабря.

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

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

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

Чистый performance-бонус

Переменный, считается от индивидуальных или командных KPI. В плохой год может быть ноль, в хороший — 200% от цели. Считается по прописанной формуле или score card, в идеале — в оффер-леттере.

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

Когда не работает — наносит реальный вред. В тот момент, когда разработчики приходят к выводу, что KPI награждают вещи, на которые они повлиять не могут, — выручка отдела продаж, к которому они не прикасались; метрики, зависящие от стратегического слоя и не зависящие от инженерного — бонус превращается из мотивации в раздражитель. Хуже того: когда KPI начинают подкручивать те, кто ближе к руководству, остальная команда это замечает быстро, и доверие проседает так, что восстановить тяжело. Мы своими глазами видели, как performance-бонусные системы убивают мораль в командах ровно в тех компаниях, которые думали, что инвестируют в performance-культуру.

Где работает хорошо: компании от 150 человек, где индивидуальный вклад измерим; sales-смежные инженерные функции; инженерные организации с реально зрелой OKR- или scorecard-практикой. Если у вас этой зрелости пока нет, схема скорее навредит, чем поможет.

Гибрид — половина гарантирована, половина за перформанс

Схема, которую мы чаще всего видим в зрелых ПВТ-компаниях в 2026 году. Годовой бонусный пул делится — обычно пополам, иногда 60/40 — между гарантированной 13-й зарплатой и оплатой за показатели.

Гарантированная выплаты предоставляются, и разработчик может планировать финансовый год. Оплата за показатели предоставляется по итогу выполнения задач. Люди знают, что им гарантировано; и понимают, за что может быть еще.

Все это требует больше административной работы и сильно больше коммуникации. Деление должно быть указано в оффере при приеме на работу. Критерии должны быть прописаны и пересматриваться раз в квартал, а не собираться наспех в ноябре. Выплата должна происходить по графику — и в обещанном объёме, а не на 60%, потому что в Q4 не хватает средств.

Где работает хорошо: большинство растущих белорусских IT-компаний, особенно продуктовые компании и резиденты ПВТ с международными клиентами.

Уровень 3: долгосрочная часть, которая удерживает сотрудника после трёх лет

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

Equity-гранты

RSU и опционы в Беларуси администрируются — особенно у резидентов ПВТ, чей режим прямо предусматривает такие инструменты. Механика не такая чистая, как в Берлине или Лондоне, но при правильной настройке рабочая.

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

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

Phantom stock

Отслеживает стоимость доли, но без реальных прав акционера. Выплачивается деньгами в обозначенные моменты — продажа, IPO, плановые vesting-этапы.

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

Retention-бонусы

В белорусской HR-практике их иногда называют loyalty bonus. Фиксированная сумма, которая открывается на разных этапах — обычно на 12, 24 и 36 месяцах. Всё чаще используются на senior+ как прямой ответ на внешнее рекрутинговое давление.

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

Уровень 4: неденежное, на котором решается большая часть ретеншна

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

Видимый карьерный трек

Описанная дорога от senior к staff и к principal — с критериями, со сроками, которые совпадают с тем, что реально происходит. Большинство белорусских IT-компаний говорит, что у них это есть. У большинства этого нет в форме, по которой разработчик может ориентироваться. Те, у кого есть — опубликованные грейды, реальные критерии, повышения, которые случаются по графику, — удерживают лучше тех, у кого нет. С большим отрывом.

Бюджет на обучение, который реально можно потратить

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

Признание не разовое, а структурное

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

Конкретные условия работы, а не размытые

Чёткая удалёнка или чёткий гибрид. Качественная техника на senior-уровне. Реальная автономия по времени. Компании, которые на этом играют — «мы в основном удалённо», без конкретики, что это значит на практике, — тихо теряют кандидатов в пользу тех, кто конкретен.

Команда, в которую вас зовут

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

Ошибки, которые тихо влияют на текучку кадров

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

Непрозрачный расчёт бонуса

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

Ретроактивные изменения правил

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

KPI, на которые разработчик повлиять не может

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

Equity без документации

«У тебя есть опционы» в оффере без vesting schedule, без strike price, без описания dilution. Через полгода разработчик просит документацию и выясняет, что её нет. Этот разговор делает долгосрочный урон доверию ко всему остальному, что говорит компания, — включая следующий разговор про бонус.

Циклы пересмотра зарплаты, которые съезжают

Уже упоминали в начале, но повторим, потому что видим часто. Годовой пересмотр тихо превращается в «давайте после закрытия раунда», потом — в следующий год. К моменту, когда пересмотр наконец случается, разработчик уже разговаривал с парой рекрутеров и в основном смирился с идеей перехода.

Бонусы, которые задерживают или урезают

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

FAQ

Стоит ли платить 13-ю зарплату, если у нас маленькая компания?

Если у вас меньше 30 человек и кеш узкий, гибрид с меньшей гарантированной частью и performance-надбавкой обычно работает лучше, чем полная 13-я. Возможно, стоит платить. Полное отсутствие любой годовой денежной компоненты читается белорусскими разработчиками как «компания неопытная» или «у компании проблемы», и ни то, ни другое не помогает в найме.

Как сделать performance-бонусы такими, чтобы они не ощущались произвольными?

Три вещи, все три обязательны, не на выбор. Опишите критерии заранее — идеально в оффере. Пересматривайте выплаты поквартально, чтобы у разработчиков было время корректироваться до конца года. Убедитесь, что критерии зависят от результатов, на которые разработчик реально может повлиять своей работой, — а не от метрик компании, на которые у него нет рычагов. 

Можно ли вообще администрировать опционы или phantom stock для белорусских разработчиков?

Да, при правильной структуре. Режим ПВТ прямо предусматривает equity-инструменты, что упрощает жизнь резидентам. Механику нужно настроить до того, как грант ушёл, а не патчить потом. Для разработчиков вне ПВТ phantom stock или кеш-ориентированные долгосрочные программы обычно проще административно. Получите консультацию по конкретной структуре до того, как что-то обещаете в письменной форме — «equity заглушкой» — одна из самых частых ошибок в оффер-леттерах, которые мы видим.

Как часто нужно делать пересмотр зарплаты?

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

Какой адекватный уровень заработной платы у senior-разработчика в 2026 году?

База в коридоре $3 500–$5 500 в месяц, плюс годовой бонус примерно один–полтора месячных оклада в эквиваленте, плюс L&D и бенефиты $200–$400 в месячном эквиваленте, плюс долгосрочная компонента в верхней части senior. Обшая сумма где-то $4 500–$7 500 в месячном эквиваленте у крепкого senior-разработчика, с заметным разбросом по стеку, типу компании и уровню. Конкретные цифры зависят от сотрудника.

Главное

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

В Recruitment.by мы работаем с белорусскими IT-компаниями и по найму сотрудников и с помошью HR-консалтиинга. Если необходимо получить информацию о выплатах зарплат или найме и удержании сотрудников, мы сможем вам помочь с помощью проведения исследование зарплат в IT что дает полную картину того, что разработчики в вашем конкретном сегменте сейчас реально получают. 

Как построить бренд работодателя в LinkedIn, на который реально отвечают сеньорные IT-специалисты из Беларуси

A foreign CTO got on a call with us last month and asked why his InMails to senior Belarusian engineers were getting a 4% response rate when LinkedIn’s global benchmark for tech roles sits closer to 18–25%. The honest answer: because his message read like every other InMail those engineers had received that week. The seniors he was reaching out to — the ones with 7–12 years on the bench, fluent English, and EPAM or Wargaming or Apalon on their CV — get five to fifteen cold messages a month. Most of them are template trash. The good engineers stopped responding to anything that doesn’t show specific knowledge of who they are.

Generic LinkedIn employer-branding advice doesn’t fix this. «Post employee stories» and «showcase your culture» are fine for entry-level pipelines and not even close to enough for the Belarusian senior market. So below is the playbook we actually run for foreign clients hiring senior Belarusian engineers — eight tactics, in order of how much they move the needle, plus a 30-day starter plan if you’d rather act than read.

Why generic LinkedIn advice doesn’t translate to senior Belarusian engineers

Three reasons before the playbook starts.

The market is small and the seniors know each other

Roughly 100,000 IT professionals in Belarus, of whom perhaps 8,000–12,000 are genuine seniors with 7+ years of experience. They’re in the same Telegram groups. They’ve worked at the same companies. They share notes about employers — including which one is spamming generic InMails this month. Whatever you send today, somebody else is reading by Thursday. Pick a tone you’d want spread.

English is good, but not native

Senior Belarusian engineers operate at B2–C1 — most of the leading software companies mandate English for client communications and many provide internal training. That’s strong, but it’s not the same as native fluency. Generic American marketing copy lands strangely. «We’re a fast-paced team building the future of [generic vertical]» reads as exactly the kind of vapor that pushes them away.

Trust currency is different

What senior Belarusian engineers value, in this order: technical credibility, salary transparency, and predictability. They’re skeptical of performative culture content — ping-pong tables and «we’re like a family» close doors here, not open them. A LinkedIn brand built on the three things above outperforms one built on aesthetics. This is also where the geopolitical context lives, which we’ll come back to in tactic #5.

The 8-tactic playbook

Tactic #1 — Build a Company Page that signals technical seriousness, not corporate polish

Senior engineers don’t read your Company Page like a brochure. They scan it for signals. Who’s the CTO? What stack are you running? When did anyone post anything last? Do your job posts list real salary ranges or hide behind «competitive compensation»? LinkedIn’s own data shows pages with complete, regularly-updated profiles get 2x more applicants per posting — but for senior talent, that 2x is mostly noise unless the page also carries technical credibility.

What to actually do. Pin a post about something you’ve engineered that’s interesting. Link to your engineering blog (or build one). Make sure your CTO’s profile is connected and active. Use real photos of the team rather than stock imagery. Show recent product or technical wins.

What to avoid. Vague mission statements, listicle-style «five reasons we’re a great place to work» posts, anything that reads like it was written by a marketing team that has never spoken to your engineers. Senior readers can spot the difference in three lines and they’ll click away. Our work on targeted IT recruitment depends on this kind of credibility being already in place.

Tactic #2 — Have your engineers post, not your recruiter

Content from individual employees outperforms branded content by roughly 8x in engagement, and most professionals trust content from individuals more than from brands. For senior Belarusian engineers — many of whom are on LinkedIn primarily to follow other engineers, not companies — that gap is even wider.

What to do. Identify three or four of your existing engineers who already post (or would, with light encouragement). Help them write about real technical decisions: «why we picked Postgres over MongoDB for this thing,» «how we cut our API latency in half,» «what went wrong when we migrated to Kubernetes.» Don’t script them. Don’t make them post on a schedule. Let it be real.

What to avoid. Forcing employee advocacy through a content tool, ghostwriting engineer posts in marketing voice, asking engineers to repost corporate announcements verbatim. Ghostwritten content is detected within two lines, and once it’s been spotted, the engineer who posted it loses credibility with their network. That’s a worse outcome than no post at all.

Tactic #3 — Show salary ranges in EUR or USD, with a specific number

This is the single highest-leverage thing most foreign companies still don’t do. Senior Belarusian engineers receive InMails daily. The ones that name a salary range get answered first. The ones that say «competitive compensation» don’t get answered at all.

What to do. In your job posts and your InMail templates, include a number. «EUR 5,500–7,500 gross/month for senior backend, depending on experience» beats anything else you can write. If you’re hiring through HTP-resident outstaffing, be transparent about the model: «EUR 5,500–7,500 gross/month, paid through HTP-resident outstaffing structure, no relocation needed.» That sentence converts because it answers the three questions every senior is asking before they decide whether to reply.

What to avoid. «Competitive,» «market rate,» «DOE,» «based on experience» — every one of these reads as «we don’t want to commit, so neither will I.» Salary anchoring isn’t tacky in this market; it’s table stakes. The contract structure also matters — see our overview of IT outstaffing arrangements for the variations clients ask about most.

Tactic #4 — Optimize for InMail response rate, not volume

Most foreign companies treating LinkedIn as a sourcing channel make the same fundamental error. They send hundreds of generic InMails and watch their response rate collapse. Senior Belarusian engineers are over-sourced. The math has flipped — sending five carefully personalized InMails outperforms sending a hundred templated ones, by a wide margin.

What to do. Read the engineer’s profile. Find one specific thing — a project they shipped, a stack choice, a talk they gave, a GitHub repo, the company they’re at — and reference it in the first line. Mention the salary range in the second line. State your role-specific task in the third. Done. Most senior engineers won’t read past three sentences and will reply faster to short, specific messages than to long, polished ones.

What to avoid. Subject lines like «Exciting opportunity at [Company]»; opening lines that praise generic skills they didn’t put on their profile; multi-paragraph InMails that try to sell the company before establishing relevance. Companies with strong talent brands on LinkedIn see 31% higher InMail acceptance rates on average — but that’s an average across all roles. For Belarusian seniors, the gap between strong-brand and weak-brand InMails is wider than that.

Tactic #5 — Acknowledge the geopolitical and sanctions context, briefly

This is the tactic most global recruitment guides skip and most Belarus-aware foreign companies handle badly. Since 2022, senior Belarusian engineers have heard a lot of vague language from Western recruiters about «the situation.» The good ones have learned to read avoidance as either ignorance or bad faith — and either is disqualifying.

What to do. In your employer-brand content, be specific about how you handle the practical questions. Payment in EUR or USD. Working through HTP-resident structures or Belarusian EOR providers. Tax and contract structure. Sanctions exposure on either side. Don’t moralize. Senior Belarusian engineers don’t need your political opinion; they need to know whether the contract works in 2026 and whether they’ll get paid on time. The recruiting.by piece on hiring blockchain developers in Belarus is a useful template for how to address structural questions without melodrama.

What to avoid. Statements like «we believe in our Belarusian colleagues during this difficult time.» That language reads as condescending and makes senior readers click away. The cleanest tone is matter-of-fact: here’s the structure, here’s the payment, here’s what we expect.

Tactic #6 — Use video, but only with engineers as the talent

Video content is an increasingly strong differentiator on LinkedIn — but the wrong kind of video destroys trust faster than no video at all. A polished marketing-team-produced «life at our company» video performs worse than no video, because it triggers the bullshit filter every senior engineer has running by default.

What to do. Five-to-ten-minute LinkedIn Lives where your CTO walks through a technical decision the team made. Short videos where an engineer talks through an actual project — unscripted, with the rough edges left in. Conference talks recorded by your team. Internal lightning talks made public. Production quality matters less than authenticity; phone-camera footage of a real engineer beats a polished promo every time.

What to avoid. Any video that feels like a recruitment commercial. Anything with a corporate music bed under it. Anything where someone is reading from a teleprompter. The whole appeal of video for this audience is that it’s harder to fake than text — leaning into production removes the only advantage video has over a written post.

Tactic #7 — Build a Careers page that pre-answers the questions seniors actually ask

Your LinkedIn Careers Page and your careers site should pre-answer the five questions every senior Belarusian engineer asks before responding to outreach: (1) what’s the salary range, (2) what’s the contract structure — entity, EOR, HTP outstaffing, (3) is the role remote, hybrid, or on-site, (4) what’s the actual tech stack, and (5) who else is on the engineering team. If those five answers aren’t on the page they reach, the senior doesn’t reply.

What to do. Build a one-page careers site that answers all five clearly and link it in every InMail. Update the engineering team listing every quarter. If you don’t have a careers site, make sure your LinkedIn Careers Page covers the same five with the same specificity.

What to avoid. Marketing-led careers content that’s heavy on culture and light on substance. Senior engineers don’t apply to vibe; they apply to specifics. A careers page full of «join our journey» content with no salary band, no stack, and no team listing is worse than no careers page — it actively signals that you’re hiding something.

Tactic #8 — Partner with someone in Belarus who already has the network

The honest one. The senior Belarusian engineering market is heavily relationship-driven. Recruiting.by’s overview of Belarusian IT job-search platforms confirms what every recruiter in the country already knows: «senior specialists and team leads often find opportunities through networking, LinkedIn, and professional communities rather than through mass job applications.» A foreign company building a LinkedIn employer brand from scratch is starting cold. A Belarus-based recruiter is starting from a network of relationships built over years.

What to do. Use a local recruiter — us, or someone like us — to amplify your LinkedIn brand into the Belarusian senior engineering network. A good local partner does three things you can’t easily do yourself: warm intros to passive candidates, pre-vetting on technical and cultural fit, and translation of your value proposition into something that lands locally. We do this through our IT recruitment service; there are other firms doing it well too.

What to avoid. Assuming a globally-branded recruitment agency knows the Belarus market because they have a Belarus page on their website. They almost certainly don’t. Local market knowledge is built over years and shows up in details — which company is actually a good place to work, who’s been laying off quietly, which compensation expectations are realistic right now.

A 30-day starter plan

If you’re going to act on any of this, the order matters. Below is the rollout we suggest for clients who want to do this themselves.

Most clients who run this 30-day program see InMail response rates move from low single digits to the 12–18% range by the end of week four. Past that, returns flatten — the next gain comes from getting to the engineers who don’t accept InMails at all, which is where the local-network advantage in tactic #8 kicks in.

If your InMail response rate isn’t where it should be

Everything above is what we run for clients hiring senior Belarusian engineers through LinkedIn. The 30-day plan works if you have time and bandwidth to execute it; if you don’t, that’s most of what we do. Tell us the role — stack, seniority, salary band, contract structure — and we’ll tell you what’s realistic and how fast. Get in touch, or browse the rest of our news section while you’re deciding.

IT-аутсорсинг vs IT-аутстаффинг в Беларуси: как иностранной компании выбрать модель и не промахнуться

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

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

Две модели — по абзацу на каждую

IT-аутсорсинг

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

IT-аутстаффинг

Вы выбираете конкретных разработчиков — собеседуете, утверждаете — и они работают исключительно на вас, встроены в вашу команду, получают задачи напрямую от вас. Юридически они трудоустроены в белорусском агентстве (в нашем случае — в нашей собственной компании-резиденте ПВТ), поэтому ни расчётом зарплаты, ни налогами, ни договорами, ни инспекцией труда вы не занимаетесь. Работу ведёте вы; трудоустройство — мы. Самая близкая ментальная модель: «они в вашей команде, но в чужом штате».

Откуда берётся путаница — не загадка. И то и другое выглядит как «IT-услуги из Беларуси», в обоих случаях вы не нанимаете разработчиков напрямую, а маркетинг глобальных вендоров целенаправленно стирает грань — потому что аутсорсинг продаётся с большей маржой. Хорошая разборка той же темы есть в этом гайде Recruiting.by, если хочется второй взгляд.

Бок о бок: где модели расходятся

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

Когда аутсорсинг действительно лучший выбор

Начнём отсюда — иначе если будем хвалить только аутстаффинг, статья сдохнет на втором абзаце. Аутсорсинг выигрывает в трёх сценариях.

1. Реально фиксированный скоуп

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

2. Узкоспециальная задача вне вашей экспертизы

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

3. У вас нет управленческого ресурса

Если у вас в принципе некому управлять разработчиками — нет тимлида, нет менеджера, нет product owner’а, который проводит стэндапы — аутстаффинг не сработает. Модель предполагает, что управление вы приносите с собой. Аутсорсинг этот слой берёт на себя. Лучше скажем заранее, чем будем смотреть, как через два месяца модель развалится.

Когда аутстаффинг — правильный ответ (а это чаще, чем кажется)

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

1. Продуктовая разработка вдолгую

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

2. Вы хотите контролировать найм и культуру

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

3. Скоуп будет меняться

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

4. Льготы ПВТ должны быть видны в вашем счёте

Это белорусская специфика, и в большинстве глобальных сравнений её пропускают. Когда агентство-аутстаффер — резидент ПВТ, база для социальных взносов считается от средней зарплаты по стране, а не от фактического оклада разработчика. Для сеньора с зарплатой 4 000 долларов это ощутимый кусок стоимости, и он попадает в ваш месячный счёт. У нас это идёт через нашу собственную компанию-резидента ПВТ по плоскому сервисному сбору €350/мес. на разработчика поверх ФОТ. Аутсорсинг ту же экономику прячет в маржу подрядчика; аутстаффинг её показывает. Для контекста: аутстаффинг входит в утверждённый перечень видов деятельности ПВТ — собственно, это и делает структуру рабочей.

Каркас принятия решения: шесть вопросов

Идите по списку сверху вниз. Каждый вопрос сужает ответ. К последнему станет ясно, какая модель ваша.

1. Скоуп работы конечный и зафиксированный — или непрерывный? Конечный → аутсорсинг в игре. Непрерывный → аутстаффинг.
2. Хотите ли вы собеседовать конкретных разработчиков и отбирать их сами? Да → аутстаффинг. Нет, без разницы → аутсорсинг подходит.
3. Есть у вас тимлид или менеджер, который тащит команду день за днём? Есть → аутстаффинг работает. Нет → или аутсорсинг, или нанимать тимлида до того, как двигаться дальше.
4. Насколько чувствительная у вас ИС? Высокая → аутстаффинг через ПВТ-резидента даёт чистую цепочку прав и стабильную команду. Аутсорсинг тоже работает, но только при идеально написанном договоре.
5. Сколько раз сменится скоуп в ближайшие полгода? Часто → аутстаффинг впитает это бесплатно. Почти не будет → аутсорсинг норм.
6. Какой вам нужен горизонт по бюджету? «Фикс на проект» → аутсорсинг. «Предсказуемая месячная стоимость на разработчика» → аутстаффинг.

Если четыре из шести ответов смотрят в одну сторону — это и есть ваш ответ. Если расклад три-три, это сигнал: работа на самом деле состоит из двух разных работ. Делите.

Почему в Беларуси этот выбор весомее, чем в других юрисдикциях

Здесь как раз заходит белорусская специфика. Три пункта, которые в других странах СНГ не работают (или работают слабее).

ПВТ меняет математику аутстаффинга

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

Трудовой кодекс защищает работника, не работодателя

Уволить можно только по основаниям из статьи 42. Выходное пособие при увольнении без виновных оснований — обычно три оклада. Защищённые категории — беременные, в декрете, в отпуске по уходу — в большинстве случаев уволить нельзя вообще. Обе модели снимают этот риск с вас, но аутстаффинг делает его прозрачным (агентство — юридический работодатель; стоимость видна в месячном счёте). Аутсорсинг прячет тот же риск в фикс, который вы не можете аудировать.

С английским в IT всё сильно, но управление никто не отменял

Обе модели работают на английском — большинство сеньоров уверенно живут на B2 и выше. Но аутстаффинг от этого выигрывает больше: вы управляете разработчиком напрямую, без переводчика-PM. Текущая рыночная картина: средние зарплаты в IT в Беларуси держатся в районе 1 600–1 900 долларов на мидловом уровне, сеньоры — заметно выше. Беларусь по-прежнему в топ-30 мировых направлений IT-аутсорсинга — глубокая скамейка, особенно по бэкенду, мобильной разработке и геймдеву. Контекст по рынку: по данным обзора TechBehemoths по Беларуси IT-сектор стабильно держится около 6,1% ВВП.

Числовой пример

Абстрактный каркас встречается с конкретными числами. Кейс ниже — собирательный, на основе того типа запросов, которые мы получаем еженедельно. Цифры реалистичны для мая 2026.

SaaS-компания из Берлина хочет добавить трёх инженеров — сеньор-бэкенд, мидл-фронтенд и QA — для развития продукта. Команда нужна как минимум на 18 месяцев, и дорожная карта по продукту будет несколько раз перетряхиваться по пути.

Вариант 1. Аутсорсинг через белорусский дев-шоп. Примерно €8 000–12 000 в месяц на инженера с учётом наценки за PM и маржи подрядчика, плюс 2–3 недели на скоуп и договор на старте, плюс PM, сидящий между вами и разработчиками, плюс допсоглашение каждый раз, когда дорожная карта дрогнула. Допсоглашения не бесплатные — обычно 5–10% юридических и переторговочных накладных на каждое изменение.

Вариант 2. Аутстаффинг через ПВТ-резидента. Зарплаты разработчиков по рынку — сеньор-бэкенд гросс ~3 500–5 000 долларов, мидл-фронтенд ~2 500–3 500, QA ~2 000–2 800 — плюс плоский сервисный сбор €350/мес. на инженера. Онбординг — 1–2 недели от первого собеседования до первого рабочего дня. Управление прямое. PM-наценки нет. Маржи поверх — нет.

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

Если всё ещё не уверены, какая модель ваша

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

Как успешно адаптировать удалённых IT-сотрудников в Беларуси: практический чеклист для компаний

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

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

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

Если вы ещё не выбрали между EOR и PEO — этот вопрос разобран в нашей статье EOR vs PEO для найма в Беларуси. Здесь мы начинаем там, где тот выбор заканчивается.

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

EOR занимается трудоустройством. Трудовой адаптацией занимаетесь вы. Это не одно и то же.

Когда вы нанимаете через EOR или аутстаффинг, трудовой договор заключается между сотрудником и EOR-провайдером. Провайдер занимается соблюдением Трудового кодекса: договор, начисление зарплаты, взносы в ФСЗН (34% от фонда оплаты труда), налоги, регистрация в соцстраховании. Всё.

Чего EOR не делает: не знакомит разработчика с командой, не объясняет кодовую базу, не проводит звонок в первый день и не выставляет ожидания на первые 30 дней. Со всем этим работаете вы. Компании, которые считают, что EOR «введёт онбординг», к началу второй недели получают разработчика, который формально трудоустроен, имеет все доступы — и не понимает, что ему делать.

Испытательный срок — это правовая конструкция, а не формальность

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

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

Беларусские IT-разработчики работают с зарубежными работодателями больше 20 лет. У них есть ожидания.

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

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

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

Ещё одно, что застаёт врасплох: Минск — UTC+3, круглогодично, без перевода часов. Митинг в 9:00 по тихоокеанскому времени — это 19:00 в Минске. Другой Митинг в 16:00 по восточному времени США — 23:00 в Минске. «Разберёмся с часовыми поясами потом» — это обычно становится последней каплей где-то к второму месяцу.

До первого рабочего дня: чеклист подготовки

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

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

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

Частая ошибка: компания подписывает договор с EOR, считает, что всё закрыто, и узнаёт на третий день, что трудовой договор так и не подписан сотрудником, или счёт для зарплаты не открыт. Договор с EOR-провайдером и трудовой договор с сотрудником — это два разных документа. Оба нужно подтвердить до старта. Спросите прямо. Не предполагайте.

Настройте доступы заранее и проверьте их — за два дня, не утром в первый день

Почта, Slack, Jira, GitHub, Confluence — всё это должно быть активно и протестировано минимум за два рабочих дня до первого утра разработчика. Назначьте конкретного человека, ответственного за эту проверку. Не «команду» в общем, а одного с именем.

Для сотрудников в Беларуси: проверьте VPN, если инструменты применяют географические ограничения. Настройте часовые пояса в общих календарях. Если компания обрабатывает персональные данные в рамках GDPR или аналогичных регуляций, убедитесь, что в договоре об удалённой работе есть нужные формулировки по обработке данных.

Решите вопрос с оборудованием до старта, а не после

Одни EOR-провайдеры закупают технику локально в Минске. Другие ждут, что клиент перечислит деньги. Некоторые отправляют международной доставкой — а это таможня, которую вы не контролируете. Суть одна: этот вопрос нужно закрыть минимум за три недели, не за неделю.

Если даёте деньги, вы должны проверить, покрывает ли она текущие цены на технику в Минске. Они подросли вместе с инфляцией и не должны рассчитываться по данным двухлетней давности. Если техникой занимается EOR компания, возьмите подтверждение даты доставки письменно. Разработчик, который в первый день работает за чужим ноутбуком, начинает не лучшим образом.

Составьте программу первой недели и отправьте её заранее

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

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

Назначьте помощника для адаптации

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

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

Скажите им, когда придёт первая зарплата, до того как они выйдут на работу

По белорусскому законодательству зарплата выплачивается не реже двух раз в месяц. На практике это обычно аванс в середине месяца — около 40% от оклада — и расчёт в конце. EOR занимается этим процессом. Ваша задача — сообщить сотруднику расписание до выхода на работу.

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

Дни 1–5: что должна закрыть первая неделя

У каждого из этих шагов есть временное окно. Откладывайте или объединяйте их — и большая часть эффекта теряется.

День 1: настоящий приветственный звонок, а не презентация продукта

Тридцать-сорок пять минут. Видео. Прямой руководитель. Утром, с поправкой на часовой пояс. Цель — разговор, а не презентация: взаимное знакомство, честный взгляд руководителя на то, как на самом деле работает команда (не версия для инвесторов), обсуждение предпочтений в коммуникации (какие каналы Slack, ожидаемое время ответа, удобный формат), и чёткое обозначение того, как выглядит успех в первые 30 дней.

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

День 1: письменное представление команде — не пропускайте, даже если неловко

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

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

День 2: звонок с командой — не про работу

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

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

День 2: проверьте, что они вообще всё нашли

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

День 3: зафиксируйте ожидания на испытательный срок и запишите их

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

Отправьте краткий follow-up email с резюме. Две причины: подтверждает, что обе стороны поняли одно и то же, и создаёт письменную фиксацию с самого начала испытательного срока. Если что-то пойдёт не так позже, этот документ будет полезен и для работодателя, и для EOR, ведущего правовую сторону.

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

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

День 5: короткий звонок, где говорят в основном они

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

Дни 6–30: как сделать хорошую первую неделю устойчивой

Зафиксируйте еженедельные 1:1 и защищайте их

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

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

Дайте реальную задачу — не учебный проект

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

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

Выделите тридцать минут на второй неделе для объяснения бизнес-контекста

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

Разработчики, которые понимают контекст своей работы, стабильно работают лучше. Замечают проблемы раньше. Задают более точные вопросы. Тридцатиминутный разговор на второй неделе имеет накопительный эффект на качество работы на несколько месяцев вперёд. Большинство компаний пропускают его, потому что он «несрочный». Именно поэтому его и пропускают раз за разом.

День 21: проведите разговор с обратной связью до того, как станет очевидно, что он нужен

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

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

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

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

Изменение, которое стабильно улучшает удалённые рабочие отношения здесь, — это не более частые проверки, а более точные. «Есть что-то заблокированное?» — нормальный вопрос. «Вы упомянули во вторник, что API-спецификация непонятна — разобрались, или это до сих пор тормозит?» — лучше.

Дни 31–90: правильное управление испытательным сроком

Фиксируйте всё на протяжении, а не только в конце

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

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

День 60: проведите промежуточную проверку, даже если всё кажется нормальным

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

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

Проверьте, работает ли их рабочее место нормально

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

Отметьте окончание испытательного срока намеренно

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

Маленькие моменты с чётким смыслом запоминаются лучше, чем большие с размытым. Этот — один из самых чётких.

Сводный чеклист — все четыре этапа

Полный процесс по фазам, сформулированный как действия компании-клиента (не EOR).

Этап 1 — Подготовка: за 2–3 недели до Дня 1

1. Подтвердите трудовой договор: подписан, корректен, условия удалённой работы прописаны
2. Протестируйте все доступы (почта, Slack/Teams, Jira, GitHub, VPN) — за два рабочих дня до старта, один ответственный человек
3. Закройте вопрос с оборудованием
4. Составьте программу первой недели и отправьте её минимум за два рабочих дня до Дня 1
5. Познакомьте с помощником письменно до Дня 1
6. Сообщите сотруднику, когда придёт зарплата — схема аванса или аналогичная

Этап 2 — Первая неделя: Дни 1–5

1. Утро Дня 1: приветственный звонок — 30–45 мин, ведёт руководитель, разговор, а не презентация
2. День 1: письменное представление команде в основном канале
3. День 2: командный звонок-знакомство — 20–30 мин, неформально
4. День 2: убедитесь, что всё нашли — спросите напрямую, закройте пробелы в тот же день
5. День 3: 1:1 по ожиданиям на испытательный срок — критерии, первое задание, формат обратной связи, follow-up письмо
6. День 3: подтвердите закрытие кадровых документов у EOR
7. День 5: чекин конца недели — 15–20 мин, сотрудник говорит, вы слушаете

Этап 3 — Первый месяц: Дни 6–30

1. Еженедельные 1:1 в календаре к концу первой недели — защищайте от переноса
2. Первое реальное задание — с масштабом, полезное, выполнимое за две недели
3. Сессия бизнес-контекста на второй неделе — продукт, пользователи, роадмап
4. День 21: структурированный разговор с обратной связью — что работает, где развиваться, что компания сделает иначе
5. Стиль проверок адаптирован под конкретного человека к третьей неделе

Этап 4 — Испытательный срок: Дни 31–90

1. Follow-up письма после ключевых разговоров с обратной связью — оставьте свидетельства на бумажных носителях
2. День 60: промежуточная структурированная встреча — достижения, опыт сотрудника, обязательства компании, путь к финишу
3. Проверка рабочего места и техники — инвестируйте сейчас, если есть проблемы
4. День 90: признание окончания испытательного срока намеренно, письменно или на звонке

Ошибки, которые иностранные компании делают стабильно

Не теоретические. Появляются систематически среди компаний, нанимающих в Беларуси впервые — вне зависимости от отрасли и размера.

Думать, что EOR занимается онбордингом

EOR ведёт трудовые отношения: договор, зарплата, налоги, взносы, compliance. Он не проводит приветственный звонок, не объясняет, что делает продукт, не знакомит новичка с командой и не управляет 90-дневной беседой о результатах. Компании, которые путают «мы наняли через EOR» и «онбординг закрыт», к началу третьей недели получают разработчика, который трудоустроен, имеет все доступы — и понятия не имеет, что ему делать.

Использовать испытательный срок как пассивное ожидание

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

Не планировать вокруг UTC+3, пока кто-то не пожалуется

Беларусь не переходит на летнее время. UTC+3 круглый год. Встреча в 9:00 по тихоокеанскому времени — 19:00 в Минске. Синхронизация в 16:00 по восточному времени США — 23:00 в Минске. Это не крайние случаи — это ежедневная реальность команд, которые не выстраивают расписание осознанно. Цена не только в неудобстве — это сигнал, что рабочее время сотрудника не в приоритете.

Платить конкурентно, но коммуницировать плохо

Белорусские IT-специалисты уходят из-за качества коммуникации так же часто, как уходят за более высокой зарплатой. Разработчик с конкурентной зарплатой, но без структурированной обратной связи, с отменёнными 1:1, размытыми ТЗ и хаосом в управлении проектами — к четвёртому месяцу начнёт пассивно смотреть предложения. Зарплата купила время. Коммуникация должна была удержать.

Пропускать 60-дневный ревью, потому что «всё нормально»

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

Когда стоит привлечь внешнюю HR-поддержку

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

• Найм пяти и более человек одновременно — онбординговые ресурсы становятся настоящим ограничением
• Управление испытательным сроком, который развивается не по плану — документация и юридическая корректность становятся критичными
• Работа в режиме резидента ПВТ (Парка высоких технологий), где применяются специальные налоговые и трудовые требования, меняющие стандартные схемы оформления
• Планирование перехода от EOR к прямому найму по мере роста команды — построение IT-команды через собственное юрлицо требует правовой и HR-работы, которая выигрывает от местного опыта
• Проблемы с удержанием сотрудников в первые шесть месяцев — они почти всегда уходят корнями к чему-то конкретному в первые 30 дней

Итого

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

Правовая база здесь — а именно механика испытательного срока и требования Трудового кодекса к договорам об удалённой работе — означает, что первые три месяца несут последствия не только в HR-смысле. А культурный контекст означает, что управленческие подходы, работающие в офисе в одном часовом поясе, без осознанной адаптации не переносятся на Минск напрямую.Наша команда занимается подбором IT-специалистов в Беларуси и поддержкой нанимающих компаний больше десяти лет. Независимо от того, ищете ли вы первого фронтенд-разработчика, выстраиваете команду с нуля или пытаетесь понять, почему цифры удержания хуже цифр найма — мы доступны в течение двух рабочих часов в любой рабочий день. Форма ниже.

Топ-5 ошибок иностранных компаний при найме в Беларуси

Белорусский рынок IT-найма в 2026 году выглядит ощутимо иначе, чем три года назад. Кадровая база консолидировалась вокруг меньшего числа более сильных инженеров. Зарплатные ожидания подросли. Постсобытийный макроконтекст 2022 года изменил то, как иностранные компании заходят на этот рынок, — и то, как рынок отвечает на их подход.

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

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

Тем, кому нужен более глубокий структурный разбор правовых моделей, стоящих за этим выбором, наш сопутствующий материал EOR vs PEO для найма в Беларуси разбирает эту территорию подробно.

Ошибка 1: воспринимать Беларусь как «Вильнюс подешевле»

Это самая частая фрейминговая ошибка из тех, что мы видим. Иностранная компания за последние 18 месяцев уже наняла кого-то в Литве или Польше, опыт прошёл хорошо, и команда исходит из того, что тот же подход можно перенести с поправкой на меньшие зарплаты. А вот не получится.

Заголовочные цифры действительно поддерживают тезис об арбитраже по стоимости. Senior-роли в IT в Беларуси в 2026 году находятся примерно в коридоре $3 000 — $6 000 в месяц гросс, специалисты по Golang, Web3 и блокчейну часто выше. Для сравнения: эквивалентные роли в Вильнюсе бывают на 50–80 процентов дороже. На бумаге аргумент в пользу найма из Беларуси выглядит убедительно.

Аргумент становится менее однозначным, как только компания смотрит на полную структуру издержек. Отчисления работодателя в Фонд социальной защиты населения (ФСЗН) — 34 процента от gross-зарплаты. Белгосстрах — ещё 3,5 процента обязательного страхования. Несколько мелких обязательных платежей дотягивают совокупную нагрузку работодателя до примерно 38 процентов от gross-зарплаты — до любой маржи провайдера. Актуальные ставки публикуются на портале правовой информации pravo.by и через Министерство труда и социальной защиты.

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

Сама кадровая база здесь устроена не так, как в среднем по региону. Белорусские senior-инженеры, как правило, имеют более сильную формальную базу по computer science — наследие технических вузов, которые продолжали выпускать сильных специалистов и в 2000-е, и в 2010-е. Зато у них чаще тоньше прослойка опыта в некоторых западных продуктовых культурах и в современных тулчейнах, ставших стандартом в венчурно финансируемых продуктовых компаниях в Лондоне или Берлине. Ни одна из этих характеристик не универсальна, но это закономерности. Hiring-спека, написанная под Вильнюс, на белорусском рынке даст промахи.

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

Ошибка 2: позволять зарплате тихо отставать от рынка

Вторая ошибка — скорее структурная, чем стратегическая. Иностранная компания делает зарплатный бенчмарк в момент найма, фиксирует оффер, подписывает договор — и потом не пересматривает компенсацию 18–24 месяца. За это время белорусский senior-IT-рынок продолжает двигаться, и зарплата сотрудника постепенно сползает с «выше рынка» на «ниже рынка», и никто этого не замечает.

Белорусские IT-зарплаты двигались на 8–12 процентов в год в 2024 и 2025 годах. Зарплата, которая на момент подписания была на 10 процентов выше рынка, через двенадцать месяцев может оказаться примерно на 5 процентов ниже. Через два года инженер уже существенно недоплачен относительно того, что он мог бы получать, сменив работодателя, — даже если его номинальная зарплата не изменилась.

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

Операционное последствие — добровольная текучка, которая кучкуется в окне 18–24 месяцев стажа. Это глобальный паттерн в разработке ПО, который в Беларуси заостряется именно за счёт местной видимости. Реактивная корректировка в момент, когда инженер уже думает уходить, обходится примерно вдвое дороже, чем проактивная, и даже тогда вероятность удержать его — ниже 50 процентов. Исследование McKinsey по европейской текучке последовательно ставит недостаточную компенсацию в топ-3 причин ухода европейских работников. SHRM оценивает стоимость замены IT-сотрудника в 50–60 процентов годовой зарплаты как нижний порог; другие индустриальные оценки заметно выше, если учитывать потерю знаний.

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

Ошибка 3: выбрать не ту модель занятости (и не заметить этого год)

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

Четыре сценария, которые повторяются:

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

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

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

Ловушка PEO без юрлица. Иностранной компании продают «PEO», не объяснив, что белорусская модель PEO предполагает наличие у клиента (или процесс создания) локального юрлица. Без него структура либо тихо превращается в нечто, больше похожее на EOR, либо просто не даёт ожидаемых выгод от со-работодательства. Американским читателям особенно стоит запомнить, что белорусское PEO — это не то же самое, что PEO в США; американский юрист, читающий этот термин в белорусском договоре, может ошибиться в распределении рисков.

Что работает вместо этого. Делайте структурный выбор осознанно, на старте, исходя из проекции по численности и операционным намерениям на 12–24 месяца — а не из того, что быстрее всего запустить на этой неделе. Закладывайте в исходный договор условия миграции, чтобы смена модели в будущем — а её рано или поздно проходит большинство иностранных компаний — не требовала дестабилизации команды. Пересматривайте структуру на отметке двенадцать месяцев, понимая, что правильный ответ на 12-м месяце может отличаться от правильного ответа на 1-м.

Наш сопутствующий материал по EOR vs PEO для найма в Беларуси разбирает структурное сравнение подробно. Описание сервисов — на наших страницах услуг PEO и IT-аутстаффинга.

Ошибка 4: гонять скрининг в режиме спринта на рынке, который этого не любит

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

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

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

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

Что работает вместо этого. Многоступенчатый процесс скрининга на 2–4 недели: первичный разговор, технический раунд, структурированное взаимодействие с командой (чтобы кандидат увидел тех, с кем будет реально работать), и финальный коммерческий разговор. Совокупный временной вклад примерно тот же, что и у поспешного процесса, — если учесть провальные наймы, которые поспешный процесс производит. Просто это время тратится в правильном месте: до оффера, а не после. Дайте инженеру возможность задать свои вопросы про компанию, команду и долгосрочный план. Данные Stack Overflow Developer Survey последовательно показывают, что удовлетворённость инженера на этапе найма коррелирует с воспринимаемой серьёзностью процесса. В Беларуси эта связь работает так же.

Ошибка 5: недоинвестировать в онбординг и интеграцию

Пятая ошибка — та, которую компании часто не воспринимают как ошибку, пока всё уже не случилось. Они хорошо нанимают, корректно оформляют договор, а потом «бросают» нового инженера в команду с приглашением в Slack, ссылкой на Notion и расплывчатым «пингуй любого, если будут вопросы».

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

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

Что работает вместо этого. Структурированная программа онбординга с именованными вехами на одной неделе, одном месяце, трёх месяцах и шести месяцах. Назначенный «онбординг-партнёр» — более senior-инженер или руководитель, который явно отвечает за интеграцию нового сотрудника в первые 90 дней. Запланированное синхронное время с расширенной командой, продакт-овнерами и (где возможно) с теми, кто работает с клиентами, в первые 30 дней. Документация, написанная для нового сотрудника, а не для существующей команды, — особенно по продуктовому контексту, рыночному контексту и принципам принятия решений.

Клиентам, которым нужна помощь не только в рекрутинге, но и в выстраивании онбординг-инфраструктуры, наша услуга HR-консалтинга покрывает дизайн программы и её внедрение.

Короткий диагностический чек-лист

Прогоните эти вопросы по своей текущей или планируемой настройке. Где ответ «нет» — там и точка с самым высоким рычагом, на которой стоит сосредоточиться до следующего найма.

Вы строили hiring-спецификацию специально под белорусский кадровый рынок — или перенесли с другого регионального рынка?

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

Вы выбирали модель занятости — собственное юрлицо, EOR, PEO, аутстаффинг — исходя из проекции по численности и намерениям на 12–24 месяца, или исходя из того, что было быстрее всего запустить?

Ваш скрининг-процесс структурирован в несколько этапов — со встроенным временем для того, чтобы кандидат тоже мог оценить вас?

У вас есть задокументированная программа онбординга для новых белорусских сотрудников, которая идёт не меньше 90 дней?

Вы оценивали резидентство ПВТ как опцию по налоговому рычагу — через собственное юрлицо или через партнёра по найму?

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

Заключение

Хорошо нанимать в Беларуси в 2026 году — задача вполне выполнимая. Иностранные компании, у которых это получается, разделяют узнаваемый паттерн. Они относятся к рынку на его собственных условиях, а не как к универсальному «восточноевропейскому направлению дешёвых талантов». Они делают структурные выборы осознанно, а не реактивно. И они инвестируют в удержание и интеграцию как в часть процесса найма, а не относятся к рекрутингу как к одной завершённой транзакции.

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

Recruitment.by работает с иностранными компаниями, заходящими на белорусский рынок, больше десяти лет — IT, финтех, форекс, крипта, регулируемые отрасли. Наш набор услуг покрывает IT-рекрутинг, оформление резидентства ПВТ, EOR, PEO, расчёт зарплаты, HR-консалтинг и IT-аутсорсинг с аутстаффингом. Если что-то из описанного в статье совпадает с тем, что вы видите у себя, — или если вы оцениваете первый наём в Беларуси и предпочли бы избежать этих ошибок с самого начала, — свяжитесь с нашей командой на 30-минутный скоупинг-звонок. Мы пойдём от вашей ситуации, а не от каталога услуг.