Найм cloud-инженеров (AWS, Azure, GCP) в Беларуси: навыки и зарплатные вилки

Cloud hiring in Western Europe in 2026 is a seller’s market — short candidate pools, two-month notice periods, and salary bands that have outrun most international budgets. Belarus runs on different math. Senior AWS, Azure, and GCP engineers cost 50–70% less than in Berlin or London at comparable seniority. The talent pool is wider than its reputation suggests, and the engagement models have matured into something finance teams can actually sign off on.

This article provides answers to three questions: what abilities are expected at each seniority level, which cloud has the largest local pool, and what constitutes a competitive offer.

1. The numbers first

Since we know that’s what you’re looking for, we’ve placed the pay chart at the top. The gross monthly compensation in USD for direct or outstaffed engagements is shown here, cross-referenced with our 2026 placement statistics and wage surveys from dev.by. A service charge is added to these bands in EOR pricing.

​

​

Three things compress these ranges in real conversations. A professional-level certification pushes a candidate roughly 10–15% above the median for their band. Production Kubernetes experience adds another 15–20%, and cloud security depth — IAM design, threat modeling, real incident response — adds 10–20% on top. Engineers with all three negotiate from the top of the senior band, and they’re worth it. If you’d like a tailored band for your exact role, our team runs a free benchmark against live placements within 48 hours.

2. The three certifications that actually predict performance

Foundational certs are a vibe check.  Engineers with associate-level certifications have shipped something. The certifications that correspond to the seniority you would identify in an interview are those at the professional level. If you’re scanning resumes fast, you’re looking for one of three specific credentials.

AWS Solutions Architect Professional (SAP-C02)

The most common professional-level credential in the Belarusian market. Holders have typically owned multi-account AWS environments and made real cost-versus-resilience trade-offs in production. Cross-check against hands-on work — the cert without a project portfolio behind it is a yellow flag. The AWS Well-Architected Framework is a useful structure to organize the technical interview around, because most SAP-C02 holders will recognize the pillars and have opinions about them.

Azure Solutions Architect Expert (AZ-305)

Smaller pool, but the engineers who hold this credential tend to come from regulated industries — banking, healthcare, government — where Azure dominates. Strong overlap with hybrid cloud and identity work. Microsoft’s Azure architecture documentation maps closely to what these candidates will have shipped, and it’s a fair reference for designing the interview.

Google Professional Cloud Architect

The most concentrated technical depth in Belarus’s narrowest pool. For analytics-focused teams and ML-leaning platforms, GCP-certified engineers are frequently the best fit. A longer search—typically two more weeks—and a smaller shortlist are to be expected. Data platform positions are worth waiting for.

One warning is worth mentioning.  In this market, candidates who possess four credentials across all three clouds but are unable to identify a system they actually developed are engaging in a practice known as «cert-collecting.» A single cert paired with three production war stories is almost always the stronger hire.

3. Reading resumes in this market

Five patterns come up often enough that we filter for them during pre-screen. The clearest warning sign is a resume that’s heavy on certifications and thin on shipped work — four credentials, three companies, and no description of what the candidate actually built. That’s almost always a junior in disguise. Closely related is the engineer who lists Kubernetes as a skill but can’t tell you, without prompting, whether they ran EKS, GKE, AKS, or a self-managed cluster — and how many nodes were in production. Real operators know.

Early detection of two more structural clues is worthwhile. If Terraform or another infrastructure-as-code tool doesn’t appear anywhere on the resume past 2022, you’re probably looking at someone who deploys through the console, which means they haven’t worked at scale recently. And senior candidates who’ve never been paged have never run real production, regardless of title. Either dig harder into what their on-call rotation actually looked like, or adjust the seniority expectation downward. Salary expectations 30%+ above local market are the fifth pattern: usually it’s a sign the candidate is planning to relocate, which is fine if you’re hiring fully remote but worth knowing before the offer goes out.

On the positive side, the signals that predict strong hires are mostly stories, not credentials. An engineer who can guide you through every step of a production incident—detection, mitigation, postmortem, and fix—has held a senior position at a significant organization. A specific cost-saving project with a real number behind it («reduced our AWS bill by 38% over six months by moving X to Y») beats any cert. Multi-cloud exposure, even if shallow, signals adaptability and durability. Active participation in the local community — meetup talks, contributions to CNCF projects, a maintained GitHub — points to continuous learning. And the seniors who admit uncertainty in an interview are the seniors who admit it in a production incident, which is exactly when you need them to.

4. How a 14-day search actually unfolds

Any cloud engineering search has its best leverage during the first 48 hours. The brief—stack, seniority, must-haves, budget, and engagement model — is locked in on the first day of the kickoff call. Before any candidate gets a job description, the recruiting manager verifies the offer band on day two after we deliver a wage benchmark against actual placements.  Most failed searches die in this window, when the brief is loose and the budget hasn’t been pressure-tested.

Day three through Day six are dedicated to sourcing and pre-screening. The recruiter applies filters based on stack relevance, notice-period flexibility, English fluency, and certification level. The shortlist, which consists of four to six applicants with complete biographies, expected salaries, and start dates, is sent by day seven. Your team runs technical interviews — system design plus a live infrastructure-as-code task — through day ten, with the final round and reference checks landing on days eleven and twelve. By day thirteen the offer goes out, and contracts are signed on day fourteen, with onboarding scheduled for the following week.

Add roughly a week for senior roles and ten to fourteen days for lead and architect searches, where the candidate pool is thinner. The two ways this timeline breaks are predictable. The first is an internal stakeholder who isn’t aligned on the brief at kickoff, which causes the spec to change mid-sprint. The second is interview feedback that takes longer than 24 hours, which loses candidates to faster movers. Both are fixable if you call them out before kickoff, and our recruiters will push back on either pattern when we see it forming.

5. What your monthly budget actually buys you

Salary tables show numbers. Purchasing-power comparisons show what those numbers mean in practice — and they’re the comparison that usually moves a CFO. Here’s what the same monthly budget gets you across Europe’s main hiring markets in 2026.

The structural point is straightforward. A $5,000/month budget that hires a junior in Berlin hires a senior with production Kubernetes and one professional certification in Minsk. The talent pool isn’t smaller. The local cost base is. Cross-referenced against the Stack Overflow Developer Survey, senior cloud engineers in Eastern Europe report similar tooling, similar tenure, and similar self-rated proficiency to their Western peers — the gap is in pay, not in capability.

6. What pushes a candidate to the top of their band

The biggest single driver is production Kubernetes experience. Not «used Kubernetes» or «deployed to GKE for a personal project» — actual operational ownership of a cluster running real workloads, with the war stories to prove it. Engineers with this background routinely negotiate 15–20% above the median for their level, and the premium is justified by how rare the experience actually is. Cloud-native depth, especially familiarity with the broader CNCF ecosystem beyond Kubernetes itself, compounds the effect.

Multi-cloud fluency is the second major driver. Engineers who’ve shipped production work across two clouds — typically AWS and Azure — earn 15–20% more than single-cloud specialists at the same seniority. Professional-level certifications add another 10–15% on top of base when paired with demonstrable hands-on work. Cloud security specialization, including IAM architecture, threat modeling, and incident response, layers 10–20% more for senior roles. The economic logic is straightforward: each of these skills shortens time-to-impact for the employer, and the local market has internalized that pricing. A senior AWS engineer with production Kubernetes, an AZ-305 on the side, and security depth doesn’t negotiate from the senior band — they negotiate from the lead band, regardless of their actual title.

7. Bringing Belarusian cloud engineers onto your team

There are three practical engagement models for international employers. Outstaffing is the fastest — the engineer works as part of your team day to day, while the staffing partner handles employment, payroll, and compliance. Time-to-signed-offer is typically two to four weeks for mid-level roles. Employer of Record (EOR) is the cleanest structure for engineers you intend to retain long-term: the partner becomes the legal employer, but the engineer integrates fully into your team and reports to you. EOR adds a service margin but eliminates the operational overhead of cross-border employment. Direct hire is technically possible but requires a registered Belarusian entity, which only makes sense if you’re building a hub of fifteen people or more.

The recruitment.by team handles all three models, including the legal, payroll, and compliance scaffolding behind each. For most international employers hiring their first one to five cloud engineers in Belarus, EOR is the right structure — it’s compliant, predictable, and avoids tying up legal and finance bandwidth that’s better spent on the actual hire.

Next steps

If you’re scoping a cloud engineering hire in Belarus, the right starting point is a benchmark against live placements for your exact role, stack, and seniority. Send us the brief, and we’ll come back with a realistic salary band, a candidate availability read, and a sample shortlist within two business days. No commitment required, and the data is yours to use however you’d like.

Найм блокчейн и Web3-разработчиков в Беларуси: стек, навыки и тревожные сигналы

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

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

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

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

Беларусь больше двадцати лет работает как серьёзный экспортёр ПО. Парк высоких технологий (ПВТ) в Минске — специальная экономическая зона для ИТ — дал отрасли налоговые льготы, а в 2018 году Декрет №8 прямо легализовал операции с криптовалютой. Компании, получившие резидентство в ПВТ, могут выпускать токены и управлять биржами.

Для основателей, которые выводят бизнес на глобальный рынок, это означает три вещи:

• Пул разработчиков с реальным production-опытом в EVM-сетях, Solana, Cosmos и zero-knowledge-стеках.
• Гибкие выплаты. Белорусские разработчики привыкли работать на иностранных работодателей и получать зарплату в USD или EUR.
• Более низкая нагрузка на бюджет. Зарплаты senior-специалистов Web3 в Беларуси обычно на 30–45% ниже западноевропейских, хотя разрыв уже не такой большой, как три года назад.

Рынок не идеален. После 2022 года заметная часть senior-специалистов переехала в Польшу, на Кипр, в Грузию и ОАЭ. Те, кто остался, — это в том числе сильные middle- и senior-специалисты, которые хотят стабильно работать на иностранного работодателя, не уезжая из страны. При правильно выстроенной схеме это отлично закрывает потребности распределённых команд.

По данным Electric Capital Developer Report, Восточная Европа — один из крупнейших по числу активных крипто-разработчиков регионов за пределами США, и Беларусь вносит в эту цифру заметный вклад.

Какой стек искать в 2026 году

«Блокчейн-разработчик» — слишком широкая формулировка, чтобы быть полезной в вакансии. То, что вам реально нужно, зависит от сети, продукта и стека, на который вы нанимаете.

Разработчики смарт-контрактов (EVM). Solidity, глубокое понимание документации для разработчиков Ethereum и теми EIP, которые касаются вашего протокола. Опыт использования Foundry или Hardhat для тестирования и разработки. Знание типовых решений и паттернов OpenZeppelin. Практический опыт работы с решениями второго уровня (Layer 2) — Arbitrum, Optimism, Base, zkSync — а также с механизмами межсетевого взаимодействия и мостами. Навыки написания кода, готового к аудиту безопасности: документирование с использованием NatSpec, fuzz-тестирование и инвариантное тестирование.

Разработчики смарт-контрактов (не-EVM). Rust — для Solana, NEAR или паллетов Polkadot. Move — для Aptos и Sui (пул меньше, закладывайте это в бюджет). Solana-разработчики должны уверенно владеть фреймворком Anchor и документацией для разработчиков Solana, разбираться в моделях аккаунтов, отличающихся от EVM (rent, PDA, sealevel runtime).

Фуллстек Web3-разработчики. TypeScript, React или Next.js в связке с wagmi, viem, ethers.js или web3.js. Интеграции с кошельками: MetaMask, WalletConnect, а также embedded-wallet SDK вроде Privy или Dynamic. The Graph для индексации или собственные индексеры на Ponder и Subsquid.

Инфраструктурные и протокольные инженеры. Инженеры по инфраструктуре и протоколам. Владение Go для разработки узловой инфраструктуры, инструментов MEV или компонентов уровня секвенсоров. Глубокое понимание libp2p, gossip-протоколов и механизмов консенсуса. Практический опыт запуска валидаторов или работы с RPC-провайдерами.

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

Навыки помимо стека

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

Приоритет безопасности. Опытный Web3-разработчик воспринимает безопасность как основу архитектуры, а не как этап после разработки. Он должен уверенно разбираться в типовых векторах атак — от reentrancy и манипуляции оракулами до MEV, signature replay и ошибок контроля доступа. Если обсуждение этих тем вызывает затруднения, это серьёзный сигнал о том, что заявленный senior-уровень может не соответствовать реальной практике.

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

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

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

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

Пять моделей найма — и когда какая подходит

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

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

Employer of Record (EOR). Местная компания формально оформляет разработчика к себе, ведёт зарплату, налоги и трудовую отчётность и раз в месяц выставляет вам счёт. Вы руководите разработчиком в работе, всё остальное берёт на себя EOR. Это самый быстрый способ — сильный кандидат стартует за несколько дней — и самый юридически чистый вариант для первого найма. Основной недостаток — фиксированная ежемесячная комиссия сверх заработной платы, которая по мере роста команды становится менее экономически эффективной по сравнению с собственным юридическим лицом.

Professional Employer Organization (PEO). PEO — это модель совместного найма. Вам всё равно нужно локальное присутствие (или близкая к нему структура), а PEO становится сонанимателем и берёт на себя HR, расчёт зарплаты и администрирование социальных гарантий. Эта модель даёт больше контроля над условиями занятости по сравнению с EOR, но требует большей вовлечённости с вашей стороны в вопросы регуляторного соответствия и операционного сопровождения. Она подходит компаниям, у которых уже есть определённая локальная опора и которые хотят передать HR-операции внешнему провайдеру.

Аутстаффинг. При IT-аутстаффинге белорусский провайдер нанимает разработчика и закрепляет его за вашим проектом на полной занятости. Вы управляете задачами и приоритетами, а провайдер берёт на себя трудоустройство, расчёт заработной платы и административное сопровождение. Грань между аутстаффингом и EOR тонкая: аутстаффинг чаще заточен под ИТ, обычно идёт от вендора с резидентством ПВТ (что даёт налоговые льготы, отражающиеся в стоимости услуги), и в большинстве случаев предполагает, что инженера тоже находит сам вендор, а не только оформляет. Хороший вариант для быстрого технического найма, когда у вас ещё нет конкретного кандидата на руках.

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

Простое правило: для одного-двух senior-специалистов — EOR или аутстаффинг. От пяти и больше — резидентство ПВТ или прямой найм. Для проекта с конечным сроком — аутсорсинг. Юридическая схема должна соответствовать плану команды, а не наоборот. Если хочется подробнее разобраться в самой механике PEO применительно к Беларуси, мы составили отдельный материал.

Тревожные сигналы на интервью

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

Стаж, который не сходится с таймлайном. «Шесть лет на Solana» — невозможно: мейннет Solana запустился в 2020 году. То же касается Aptos (2022) и Sui (2023). Сопоставляйте даты.

Никаких публичных on-chain следов. Не каждый сильный инженер всё публикует, но сеньор Web3-разработчик без единого проверяемого on-chain артефакта — это тревожный сигнал. Речь идёт о таких следах, как деплой-адреса смарт-контрактов, репозитории на GitHub с историей коммитов, обсуждения на Ethereum Magicians или EthResearch. В норме у опытного специалиста хотя бы часть этих элементов должна быть доступна и верифицируема.

Расплывчатые ответы о production-контрактах. Формулировки вроде «я работал над DeFi-протоколом» без указания названия, сети или адреса контракта редко соответствуют реальному production-опыту. Практикующие инженеры обычно могут конкретизировать: «я разрабатывал модуль стейкинга в таком-то протоколе — вот ссылка на Etherscan». Если кандидат ссылается на NDA, разумно попросить обезличенный пример: архитектуру, фрагмент кода или описание модуля без раскрытия деталей проекта. Когда же вся работа полностью закрыта соглашениями о конфиденциальности, это само по себе также является значимым сигналом, который стоит учитывать при оценке опыта.

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

Опыт только в сомнительных токен-лаунчах. CV, собранное из fair-launch мемкоинов, анонимных проектов и недолгих форков DeFi 2.0, — довольно узнаваемый паттерн. Это не всегда признак слабого инженера, но качество такого опыта сильно разнится. Сильные кандидаты обычно могут спокойно разобрать, что в этих проектах получилось, а что нет, и что бы они сделали иначе.

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

Зарплатные ожидания сильно ниже рынка. Звучит контринтуитивно, но senior-Solidity разработчик, готовый работать за деньги джуна, обычно оказывается джуном, который себя переоценил. До переговоров стоит посмотреть актуальные данные по зарплатам.

Где искать сильных кандидатов

Лучшие белорусские Web3-инженеры редко находятся в активном поиске. Они работают у резидентов ПВТ, в свободное время контрибьютят в open source или фрилансят на тех протоколах, которые им интересны. Найти их можно через GitHub-контрибуции с фильтром по часовым поясам СНГ, локальные митапы, рекомендации от команд-резидентов ПВТ и профильных рекрутеров, которые работают именно по этому рынку.

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

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

Заключение

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

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

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

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

ИИ в рекрутинге 2026: как белорусские рекрутеры используют ChatGPT, инструменты сорсинга и автоматизацию

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

Для белорусских рекрутеров, работающих с заказчиками из ЕС, США и СНГ, это давно не теория. Сроки найма сократились вдвое. Воронки сорсинга, на наполнение которых раньше уходили недели, сегодня формируются за несколько дней. ChatGPT, ещё пару лет назад казавшийся диковинкой, прочно вошёл в повседневную работу практически каждого IT-рекрутера в Минске.

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

Белорусский рынок рекрутмента в 2026 году

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

Изменилось то, как именно компании находят и нанимают специалистов. Рынок 2026 года определяется несколькими ключевыми тенденциями:

• спрос на senior-инженеров, специалистов по AI/ML и DevOps по-прежнему превышает предложение;
• удалённый и гибридный форматы работы стали стандартом для международного найма;
• после турбулентности 2022–2024 годов зарплатные ожидания стабилизировались;
• вопросы соответствия законодательству, расчёта заработной платы и налогообложения превратились в реальный фактор при выборе модели найма.

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

ChatGPT в повседневной работе рекрутера

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

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

Подготовка первичных сообщений кандидатам. Шаблонные InMail в LinkedIn получают отклик в 3–5% случаев. Персонализированные — в 25–30%. ChatGPT помогает массово создавать индивидуальные обращения на основе профиля кандидата, его активности на GitHub или недавних публикаций.

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

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

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

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

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

Инструменты сорсинга на базе ИИ: то, что реально работает

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

• LinkedIn Recruiter с AI-Assisted Search. Базовая отправная точка. Запросы на естественном языке возвращают ранжированный по релевантности список — без сложных Boolean-запросов.
• hireEZ и SeekOut. Для глубокого технического сорсинга по GitHub, Stack Overflow, докладам с конференций и патентным базам.
• Fetcher и Gem. Для я автоматизации верхней части воронки с возможностью персонализации сообщений.
• Talentprise и Findem. Для поиска в формате «people aggregator»: подтягивают данные о кандидатах из открытых источников и сводят их в один структурированный профиль.
• Otter, Fireflies и Read.ai. Транскрибация интервью и аналитика после звонков.

Типичный процесс сорсинга в белорусском агентстве сегодня выглядит так: ИИ-инструмент формирует выборку из 200 кандидатов, ChatGPT помогает написать три варианта сообщений, платформа автоматизации рассылает их с разнесением по времени — а рекрутер сосредотачивается на 30–40 кандидатах, ответивших на письма. 

Если интересно понять, где в этом процессе всё ещё доминирует — и, вероятно, всегда будет доминировать — человек, рекомендуем материал о том, как нанять IT-специалистов в Беларуси.

Автоматизация на всех этапах воронки найма

ИИ-сорсинг — это видимая часть. Автоматизация заметна меньше, но именно в ней сосредоточена основная экономия времени.

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

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

Модели найма в 2026 году: прямой наём, EOR, PEO, аутстаффинг и аутсорсинг

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

Прямой найм

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

EOR (Employer of Record)

Юридическим работодателем выступает сторонний провайдер. Он ведёт расчёт заработной платы, налоги, бонусы и обеспечивает соответствие требованиям законодательства. Заказчик отвечает за содержание работы. Юридическое лицо не требуется, запуск занимает несколько дней. EOR стал моделью по умолчанию для иностранных компаний, нанимающих 1–10 специалистов в Беларуси, особенно для бизнеса из США и ЕС. Если вы пытаетесь понять, чем эта модель отличается от PEO, в нашем разборе EOR vs PEO для Беларуси подробно описаны компромиссы обеих схем.

PEO (Professional Employer Organization)

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

ИТ-аутстаффинг

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

ИТ-аутсорсинг

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

Краткий ориентир:

• нужен один senior-разработчик быстро, без открытия юрлица → EOR
• юрлицо в Беларуси уже есть, требуется HR-поддержка → PEO
• формируется выделенная команда под прямое управление заказчика → аутстаффинг
• нужен готовый продукт или функция → аутсорсинг
• долгосрочные планы и крупный масштаб → прямой найм, как правило, в составе ПВТ

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

Где ИИ всё ещё не справляется

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

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

Опыт кандидата. Чрезмерно автоматизированная коммуникация воспринимается как спам. Кандидаты теряют интерес тем быстрее, чем раньше распознают переписку с ботом. Команды, выигрывающие в 2026 году, используют ИИ для подготовки персонализированного человеческого контакта — а не для его замены.

Защита данных. GDPR, белорусское законодательство о персональных данных и клиентские NDA в совокупности ограничивают, какие данные допустимо передавать тем или иным ИИ-вендорам. В исследованиях Gartner по ИИ в HR, вопросы управления данными стабильно занимают первое место среди опасений руководителей.

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

Культурное соответствие и мотивация. Эти задачи не решила ни одна модель. Они по-прежнему остаются работой рекрутера.

Пошаговый алгоритм внедрения на 2026 год

Если вы — нанимающий менеджер или HR-руководитель, работающий с белорусским рынком, последовательность внедрения выглядит так:

1. Начинайте с одного процесса, а не с десяти. Выберите самую объёмную задачу — обычно это подготовка описаний вакансий или первичные сообщения кандидатам — и автоматизируйте её первой.
2. Сначала определитесь с моделью найма, затем с инструментами. EOR, аутстаффинг или прямой найм? От ответа на этот вопрос зависит, какие инструменты вам в принципе нужны.
3. Первый месяц внимательно проверяйте, что генерирует ИИ. Сравнивайте результат с тем, что вы делали вручную, и постепенно дорабатывайте настройки.
4. Последние 20% работы оставляйте за человеком. Финальный скрининг, обсуждение оффера и проверка рекомендаций — это зона ответственности рекрутера.
5. Развивайте у рекрутеров навык работы с промптами. Разрыв между специалистом, который умеет эффективно работать с ChatGPT, и тем, кто не умеет, сегодня сопоставим с двумя годами профессионального опыта.

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если кратко

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сроки

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

Где искать

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кратко

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

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

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-работодателей получают существенную выгоду от такого разговора до того, как первый кандидат попадет в список кандидатов. После того, как первый кандидат уйдет, это уже слишком поздно.