Читать книгу Как найти удалённую работу в IT - Александр Александрович Костин - Страница 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-рынке распределён неравномерно: по стеку, по домену, по уровню, по зрелости компаний. Вам нужен не абстрактный спрос, а спрос на вашу связку «роль + уровень + формат удалёнки + тип компании».

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

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

По входной сложности: что именно вы должны уметь через 4–8 недель, чтобы не «учиться на работе» с нуля, а приносить пользу. Если в роли есть критичные знания, которые нельзя заменить общими навыками, это надо признать заранее. Например, в разработке без базы (условно: как устроены данные, как писать и читать код, как отлаживать) вы будете зависеть от команды и проигрывать в конкуренции. В аналитике без умения писать ясный текст и держать логику вы будете тонуть в вопросах. В DevOps без понимания Linux/сетей/процессов вы будете опасны для системы.

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

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

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

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

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

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

2.3. Быстрый аудит своих активов: из чего вы уже можете собрать ценность

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

Аудит активов нужно делать в двух плоскостях: доменная экспертиза и метанавыки.

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

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

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

Дальше сопоставьте эти факты с ролями.

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

Отдельно проверьте, есть ли у вас «инструментальные» зацепки. Это не значит «я знаю программу». Это значит «я уже делал работу, близкую к роли». Например, если вы много работали в Excel и строили отчёты, у вас уже есть базовая модель данных и логика – это может ускорить вход в аналитику. Если вы писали инструкции, регламенты, обучающие материалы, вы уже умеете создавать артефакты – это ускоряет вход в аналитику, QA, техписательство. Если вы вели проекты и умеете формулировать требования и контролировать качество, вы ближе к аналитике и продакт-процессам, чем кажется.

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

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

Ещё один слой аудита – ограничения. Их тоже надо признать заранее, иначе они ударят в момент интервью и сорвут процесс. Ограничения бывают по времени (сколько часов в неделю вы реально можете выделить), по формату (можете ли вы работать по МСК, можете ли вы ездить на редкие встречи), по языку (нужен ли английский), по психологической устойчивости (готовность к неопределённости и постоянным вопросам). Роль должна быть совместима с вашими ограничениями. Например, если у вас мало времени, роль с высоким фундаментом и длинным разогревом будет давать постоянное чувство «я не успеваю». Если вы не готовы к постоянным коммуникациям, некоторые роли будут выматывать больше, чем кажется.

2.4. Ошибки выбора роли: что ломает путь к удалёнке чаще всего

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

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

Вторая ошибка – выбирать роль по списку инструментов. «Выучу популярный стек и меня возьмут». Это самая распространённая иллюзия. Работодатель не покупает знание названий. Он покупает способность делать работу в контексте: читать задачу, уточнять, принимать решения, доводить, проверять, документировать. Инструменты нужны, но они вторичны. Поэтому правильный вопрос не «какой стек учить», а «какие типовые задачи в этой роли я должен уметь выполнять и как это показать».

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

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

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

Шестая ошибка – одновременно пытаться зайти в несколько несоседних ролей, чтобы «увеличить шансы». На практике это снижает шансы. Потому что упаковка расползается, портфолио становится разрозненным, резюме выглядит неуверенно, а работодатель чувствует, что вы не понимаете, куда идёте. Если вы хотите увеличить шансы, выбирайте две роли, которые используют один набор артефактов и один язык результатов. Например, системный аналитик и бизнес-аналитик. Или QA manual и QA auto при условии, что вы честно отделяете уровни. Или разработчик определённого направления и инженер поддержки L2/L3 в похожем домене. Но не «дизайнер + аналитик + QA» одновременно.

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

Восьмая ошибка – выбирать роль, не понимая критериев «хорошо/плохо». Когда вы не знаете критериев качества, вы не можете учиться правильно. Вы учитесь случайно: где-то глубоко, где-то поверхностно, и не понимаете, почему вас не берут. Роль должна иметь ясные критерии, которые вы можете тренировать и демонстрировать. Например, для QA это качество баг-репортов, умение строить тест-стратегию и мыслить рисками. Для аналитика – ясность требований и отсутствие противоречий. Для разработчика – качество кода, умение объяснять решения, способность доводить до результата. Для дизайнера – логика решений, соответствие ограничениям, влияние на метрики (там, где это уместно и доступно).

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

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

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