Александр Костин – Как найти удалённую работу в IT (страница 3)

Неправильный критерий: «каждый день учиться».Правильные критерии:

«получать N ответов на отклики в неделю»;

«иметь M приглашений на первичные интервью за месяц»;

«дойти до K технических этапов»;

«получить 1–2 оффера или чётко понять, что мешает, и исправить».

И ещё один важный нюанс: данные по занятости показывают, что в России значительная часть удалёнщиков работает в смешанном режиме (в одном из материалов указывался диапазон 55–65% смешанного формата против 35–45% полностью удалённого). (Российская газета) Это значит, что иногда самый рациональный путь – не «всеми силами выбивать fully remote», а войти через гибрид/частичную удалёнку в сильную команду, закрепиться, а затем расширить формат.

Глава 2. Выбор роли: не «кем хочу», а «что продам работодателю»

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

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

Ключевая мысль главы проста: в IT-рынке роли отличаются не названиями, а тем, какой именно риск они снимают у бизнеса. Разработчик снижает риск «мы не успеем поставить изменения и потеряем рынок». Тестировщик снижает риск «мы выпустим дефект и потеряем деньги/репутацию». Аналитик снижает риск «мы сделаем не то и будем переделывать». DevOps/SRE снижает риск «система упадёт, и мы потеряем доступность». Дизайнер снижает риск «пользователь не совершит действие, и мы не конвертируем спрос в выручку». Когда вы выбираете роль, вы выбираете, какой риск бизнеса вы готовы снимать и насколько быстро вы можете доказать, что умеете это делать.

2.1. Карта IT-ролей простым языком – в терминах результата

Проблема начинающих (и не только) в том, что они смотрят на роли как на набор задач или инструментов. «Хочу быть фронтендером – там React», «хочу в аналитику – там SQL», «хочу в DevOps – там Docker». Но инструменты – это не роль. Инструменты – это средства доставки результата. Роль – это обещание результата, которое работодатель может измерить и проверить.

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

Разработчик (backend/frontend/mobile) приносит ценность в том, что превращает требования и идеи в работающий функционал. Хорошая работа разработчика – это не «написал код», а «изменение поставлено, работает, не ломает систему, поддерживаемо, проходит проверку, укладывается в ограничения по безопасности и производительности». В удалёнке разработчика проверяют ещё и по тому, насколько он умеет быть частью процесса: читать требования, уточнять, документировать решения, делать понятные коммиты, проходить ревью без обид, ставить себе и другим ясные вопросы. Провал разработчика – это не «ошибка в строке», а непрозрачность, отсутствие прогресса, постоянные сюрпризы на тестировании и на релизе, а также код, который невозможно сопровождать без автора.

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

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

DevOps/SRE приносит ценность в стабильности и скорости доставки изменений: чтобы релизы происходили регулярно, инциденты решались быстро, а система была наблюдаемой и управляемой. Хорошая работа DevOps/SRE – это не «настроил Jenkins», а «мы можем поставлять изменения безопасно, быстро и повторяемо; мы видим проблему до того, как о ней пишет клиент; восстановление предсказуемо; доступы и секреты управляются; инфраструктура не держится на одном человеке». В удалёнке это роль с высокой ответственностью: цена ошибки бывает дорогой, а значит, вход часто требует зрелости и доказательств. Провал здесь – «магия», отсутствие документации, ручные операции без контроля, инфраструктура, которая падает от любого изменения.

Дизайнер (продуктовый/UX/UI) приносит ценность через поведение пользователя: чтобы человеку было понятно, удобно, быстро, а продукт в итоге конвертировал и удерживал. Хорошая работа дизайнера – это решения, которые объяснимы, проверяемы и встроены в продуктовую систему (гайдлайны, компоненты, согласованный язык интерфейса). В удалёнке дизайнер особенно выигрывает, если умеет защищать решения аргументами и данными, работать с ограничениями разработки, документировать логику. Провал дизайнера – это «красиво, но непригодно», бесконечные итерации без критериев и разрыв между макетами и реальной разработкой.

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

Менеджерские роли (PM/PO/тимлид) в контексте входа в удалёнку обычно сложнее, потому что результат там завязан на влияние, доверие и контекст компании. Это не значит, что нельзя; это значит, что для входа нужны сильные доказательства: проекты, цифры, артефакты, рекомендации, и часто – внутренняя траектория роста из другой роли. Если вы на старте, практичнее выбирать роль, где результат можно показать быстрее и в более «технических» артефактах.

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

2.2. Матрица выбора роли: «входная сложность / доказуемость / спрос / конкуренция»

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

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

Вторая ось – доказуемость. Это ключевая ось для удалёнки. Доказуемость – это насколько легко вам показать работодателю, что вы умеете. Не словами, а артефактами. Разработчику относительно легко показать код и объяснить решения. Аналитику можно показать спецификации и постановки. QA можно показать тестовую документацию и качественные баг-репорты. Дизайнеру – кейсы с логикой решений. Чем выше доказуемость, тем быстрее вы сможете поднять конверсию откликов, потому что вы не просите «поверить», вы показываете.

Третья ось – спрос. Здесь важно не вдаваться в иллюзии «везде нужны айтишники». Спрос на IT-рынке распределён неравномерно: по стеку, по домену, по уровню, по зрелости компаний. Вам нужен не абстрактный спрос, а спрос на вашу связку «роль + уровень + формат удалёнки + тип компании».