Помоги проекту - поделись книгой:
Конечно, это очень примитивная скоринговая модель, которая тем не менее может быть полезной для нас. Она на практике помогла мне осознать, кто же именно мне нужен.
Я сделал себе таблицу, в которой было 4 столбца с предполагаемыми профилями нужных мне кандидатов (рекрутер, аккаунт из IT, просто аккаунт, деврел). В строчки я вписывал отдельно задачи, которые этим людям нужно будет выполнять. Дальше для каждой задачи я выделял удельный вес параметра, который мне казался подходящим (абсолютно субъективный). И для каждой обязанности и каждого профиля ставил оценку. В итоге оценка умножалась на удельный вес параметра, а потом все эти показатели суммировались.
Теперь по-человечески. Допустим, я не могу понять, кто мне нужен — менеджер по продажам или менеджер по поддержке клиентов. Я создаю таблицу.
Под обязанностями я составил список рисков, у каждого из которых также был удельный вес и проставлялись оценки. Вес умножался на оценку, показатели рисков суммировались и вычитались из верхней суммы.
Конечно, какой-нибудь аналитик сказал бы мне, что я чего-то не учел, но даже для моего первичного понимания такая табличка оказалась спасительной. Точно так же можно эту табличку переложить на вакансию и предложить заказчику проставить эти оценки и риски, чтобы ему было легче понять, на каком профиле ему лучше остановиться.
Глава 4
Составление описания вакансии
Создание вакансии — один из ключевых процессов в рекрутменте. Хотя, поверьте, я так буду говорить о каждом следующем шаге. Но давайте мыслить логически. Размещение вакансии на работных сайтах и прочих ресурсах — одно из простейших и обязательных действий, которые нам с вами необходимо совершить для того, чтобы закрыть вакансию. Не всегда именно размещенная вакансия приводит к ее закрытию, но все равно именно ваше описание становится базовым КП (коммерческим предложением), которое вы, подобно менеджеру по продажам, будете отправлять своим кандидатам. Ваша вакансия — это продукт, который вы будете предлагать рынку кандидатов. И чем лучше ваш продукт будет описан, чем четче будет структурирована вся информация о его функциях и особенностях, тем больше пользователей заинтересуются вашим продуктом.
Представьте, что вы ищете фильм, который хотите посмотреть сегодня вечером. Есть полноценная масштабная двухчасовая работа, но таких работ очень много. Вам, чтобы принять решение о том, какой именно фильм смотреть, нужно обратить внимание на несколько характеристик. Возможно, при выборе кино приоритетным для вас будет имя режиссера. Возможно, вы будете обращать внимание на актерский состав. Также есть вероятность, что вы посмотрите на рейтинг этого фильма или на наличие у него наград. Наверняка в первую очередь вы прочитаете краткую аннотацию или посмотрите трейлер. И если эта информация будет скучной или абсолютно пустой, неинформативной (уж простите за тавтологию), то есть вероятность, что фильм вы так и не захотите смотреть. Вам придется искать косвенные признаки, которые замотивируют вас выбрать именно это кино: может быть, это будут отзывы либо рекомендации друзей или тот самый актерский состав. В общем, вам понадобится дополнительная мотивация. В случае с вакансией ситуация аналогичная: она может быть распрекрасным, глубоким, чувственным и проникновенным «фильмом», который не оставит равнодушным никого, кто его посмотрит, но если трейлер и аннотация к «фильму» унылые, то людям придется искать дополнительные мотиваторы, чтобы принять решение в пользу именно вашего «кино».
Одна из распространенных ошибок рекрутеров — не работать над описанием вакансии, никак его не редактировать и размещать то, что «прилетело» от заказчика. А прилетает порой очень разное. Но прежде чем понять,
Кстати, если вы испытываете трудности с внедрением HR-изменений в работу команды, попробуйте найти единомышленника из бизнеса, с которым вы сможете что-то внедрить. Он станет «засланным казачком» и будет нативно продвигать идеи. Знаю, что даже в больших IT-компаниях успешным HR-бизнес-партнерам зачастую удается внедрить изменения именно так. Возможно, вы найдете хорошего, заинтересованного представителя бизнеса, который будет активно вовлечен в процесс найма и готов к экспериментам. Вот как раз с него и стоит начать внедрение такого анкетирования, если изначально многие этому сопротивлялись. А после успешной реализации кейса вы сможете «раскатать» это решение на всю компанию. Так что вернемся к табличке.
Любопытно, что на одни и те же вопросы вы и нанимающий менеджер можете ответить по-разному. В процессе ответов на эти вопросы очень важно прийти к общему знаменателю, показать результаты тимлиду, чтобы в очередной раз «сверить часы» и понять, правильно ли вы движетесь в своей работе.
Интересно, кстати, что в этой таблице есть вопрос про то, почему люди работают в компании и почему выбирают оффер. И это — два важных, но разных пункта. Например, человек может работать в команде, потому что тут крутые ребята, а оффер принимает, потому что компания быстрее всех с ним коммуницировала. И это реальный кейс. Одна компания, имея абсолютно среднестатистическую вакансию, в ходе подобного опроса узнала, что ее офферы принимаются за оперативную обратную связь и предложение о работе. Узнав, что их скорость — весомый аргумент для кандидатов, ребята вынесли эту информацию прямо в вакансию! Так что подобные анкетирования, при всей своей кажущейся примитивности, могут открыть какие-то новые идеи для вас и в итоге повлиять на результаты найма.
После того как вы проанализировали аудиторию, у вас складывается более правильный профиль кандидата и вы уже можете
Помните, мы уже предлагали вначале разделить профиль кандидата на три уровня: идеальный; не идеальный, но подходящий; подходящий. После определения ЦА сделать это будет еще проще, а главное — эффективнее. Все три профиля, разумеется, нужно согласовать с заказчиком. И под каждый составить отдельное описание вакансии.
Теперь же давайте вкратце обсудим, что обязательно должно быть в описании вакансии, а чего быть не должно.
Сейчас описания вакансий выглядят преимущественно одинаково. Происходит это по разным причинам, но во многом на это повлияли стандартные форматы вакансий на работных сайтах. В результате и рекрутер, и заказчик часто не думают о своем описании как о «продающем тексте», который должен привлекать аудиторию.
Тема копирайтинга вакансий, как я и говорил, заслуживает отдельной книги, но, на мой взгляд, важно уловить несколько основных моментов.
Прежде всего стоит отказаться от стандартного шаблона «обязанности — требования — условия». Если вы откроете hh.ru и посмотрите на все вакансии, через пять минут вы уже не будете вчитываться в них, потому что большая их часть сделана по этому формату и ваш мозг начнет автоматически «отсеивать лишнее».
Чаще всего описание вакансии начинается с информации о том, кого мы ищем и кто же эти «мы». Первый блок, посвященный компании и профилю человека, очень важен, но не стоит формулировать его так же, как это записано в Уставе организации. Исходите из ценностей компании, вашего продукта и тех вещей, о которых вы узнали на предыдущих этапах.
Откажитесь от «мыканий»: «мы — такие-то…», «мы ждем от вас, что…», «нам бы хотелось, чтобы вы…». Это все очень здорово, что есть эти «мы» и им чего-то хочется. Просто распрекрасно. А чего хочется кандидату? Что важно для него? Какой человек «впишется»? С кем ему придется работать? Если попробовать составить описание вакансии с этой точки зрения, получится совсем другой текст. Он будет настоящим и живым. И скорее всего, именно он привлечет больше кандидатов.
О чем еще стоит упомянуть. Обязательно расскажите о технологическом стеке. Расскажите, с какими технологиями придется работать каждый день. Приведите примеры задач, которые команда решает каждый день, и парочку важных задач и целей, к которым она стремится. Но не общее «мы хотим сделать самый лучший сервис», бла-бла-бла. «Ближайшая задача — построить интеграции с …», «В этом году мы планируем зарелизить новый аналитический модуль, который будет …» — согласитесь, это гораздо конкретнее, чем «создать лучший сервис» и «захватить мир чего-нибудь». Конечно, описать задачи сложнее всего: не всегда разработчики вдаются в детали. Да и рекрутерам их понять бывает непросто: мы ведь не «технари». Но чего точно делать не стоит — так это писать задачи в формате «разработка ПО». Ох, сколько же такого… разнообразия… вы найдете на job-бордах. Но не впадайте в искушение. Это всё от лукавого.
Стек, задачи расписали, а дальше будет круто рассказать о том, как строится процесс распределения задач у вас в компании, откуда они прилетают, насколько большая команда, как часто происходят релизы и каким вообще будет процесс найма — сколько этапов и какие. Кандидату зачастую очень важно знать эти моменты, и, если их в вакансии нет, он все равно о них спросит. Обозначив их в тексте, вы не только «сыграете на опережение», но и заинтересуете кандидата детальным и осмысленным, уважительным подходом к составлению описания вакансии.
И, разумеется, в тексте должна быть информация об условиях, но попробуйте обойтись без зыбких и общих формулировок в стиле «гибкий рабочий график». Гибкий — это с какого времени и по какое? А могу я начать работать в 5 утра? А в 5 вечера? Или то самое пресловутое «оформление по ТК». Это, конечно, важно, но, во-первых, по закону возможно либо так, либо через ГПХ, но это уже несколько другое. Зачем про это писать? Но как же, Егор: ты же сам писал, что у нас в стране есть серые и черные компании? Да, писал. Но это не значит, что надо таким образом обращать внимание на свою «белизну». В последнее время белых компаний все больше. Когда-нибудь мы придем к тому, что даже вопрос такой не будет подниматься (ха-ха). Но клише «оформление по ТК» пишется всеми и не значит ничего: по ТК можно оформить минимальный оклад в 18 тысяч — и с радостью убежать в закат. Серый. В общем, тут нужна конкретика, если уж решили писать: «полностью белый фикс (200–300 к) и квартальные бонусы (до 1 оклада)» — не правда ли, понятнее, чем «оформление по ТК»? Хотя и длиннее, согласен.
И еще один важный нюанс — оформление. К сожалению, большинство вакансий сейчас выглядят как набор списков: вот 8 пунктов обязанностей, вот 10 пунктов требований, вот 15 пунктов условий. Проблема в том, что однообразное оформление текста приводит к тому, что люди его не читают. Они пытаются глазами выцепить самую основную информацию, чтобы сократить время. Старайтесь миксовать небольшие абзацы текста со списками, смотрите за тем, чтобы требования по смыслу не дублировали обязанности (чаще всего требования вообще можно убрать), и обращайте внимание не только на текст, но и на оформление. Тексту тоже нужен воздух!
Вы, наверно, уже все извелись, читая этот раздел, и кричите на книгу: ГДЕ ПРИМЕРЫ?! Понимаю вас, вот они.
Это вакансия от Тани Пичёвой, ex-HRD в Rocket Science. Чувствуется дружелюбный тон общения, указаны основные нюансы, стек, информация о компании, рассказано, почему и за что эту компанию выбирают. Есть акцент на кандидата: «Если в тебе это откликается, пиши». Согласитесь, такая подача гораздо интереснее, ярче и живее, чем стандартно-монотонное бубнение про «мы такие-то и такие-то, ищем программиста, задачи: разработка ПО». И даже условия у Тани прописаны с юмором и жизнью.
Привет, у нас открыта вакансия Java-разработчика уровня middle +/- (вообще всегда, но сейчас — в особенности). Даже если нет открытой вакансии, мы всегда рады backend-разработчикам. Даже если просто познакомиться на будущее. Даже если просто поговорить!
Пиши нам, приходи на кофе, всё обсудим.
Наш основной стек:
Java 8+;
Spring Boot;
PostgreSQL;
JUnit;
Maven, Gradle;
Git;
Docker и Kubemetes.
Из фронтенда сейчас в основном Vue и Angular. Еще есть проекты на Kotim, Spring WebFIux, React, можно поиграться с нейросетями, если хочется.
Rocket Science — команда опытных Java back-end разработчиков. Специализируемся на создании сложных программных продуктов, back-end, кастомные ERP и CRM-системы (в основном для финансовой сферы, но не только). Партнеры ценят нас за стабильные команды, выполнение обещаний и человеческое отношение: СДЭК, Совкомбанк, СМС-Финанс, крупные российские банки под NDA. Это работает не только на партнеров, но и внутри: мы стабильны, проводим регулярные фидбэки 1on1, выполняем обещания и олицетворяем человеческое отношение друг к другу:)
5 аутсорс-проектов (API, backend), на каждом проекте 2–5 человек.
Команда 26 классных ребят (21 разработчик, 2 PM, HR, маркетолог, офис-менеджер), половина из них несколько лет работает вместе.
Команда фигачит с 2011 года, до ребрендинга мы были в составе Improve Group и назывались Improve Intelligence.
API покрываем Е2Е тестами, пробуем новое, шарим знания на техсредах (внутренний технический митап).
Технически мы ищем Java-разработчиков middle, тут всё понятно. Но хотелось бы найти своего человека, потому что именно люди делают компанию такой, какая она есть.
Если в тебе это откликается, пиши! Было бы здорово, если бы вместе с откликом ты прислал нам ссылку на Git с примерами твоего кода, чтобы мы смогли подготовиться к встрече.
Да, кстати:
Принимаем условия игры в суровом мире и готовы на удаленное сотрудничество.
Оформляем официально с первого дня работы.
После испытательного — ДМС со стоматологией (Новосибирск, Академ, Бердск).
Окна на северо-запад, летом не жарко (третья башня Технопарка в Академгородке). Да и мы не душные:))
Но есть и другой подход к написанию текста вакансии. Но тоже крутой, живой и настоящий. Это подход глубокого погружения в вакансию, чтобы кандидаты узнали максимальное количество информации из самого описания. Это пример, который используют в компании «Хантфлоу».
Хантфлоу — главный инструмент работы рекрутеров в СНГ. Здесь они ведут базу резюме, историю работы, обсуждают резюме с коллегами, переписываются с кандидатами и делают отчеты. В Хантфлоу ведут подбор крупнейшие компании — Mail.Ru Group, Avito, Leroy Merlin, Selectel и многие другие.
Это, возможно, самый сложный сервис, над которым вам придется работать. У нас 400 b2b-клиентов и более 10 000 пользователей — и при этом всего 2 суппорт-инженера. Мы смогли добиться этого благодаря высоким требованиям к качеству кода.
Уже сейчас в Хантфлоу больше 400 rps. Каждую задачу мы решаем, ориентируясь на производительность: любой запрос на бэкенд должен выполняться менее чем за секунду, поэтому запросы к базе необходимо максимально оптимизировать.
Мы не строим систему на «костылях» — Хантфлоу сделан так, чтобы его справочники, формы и другие возможности было легко кастомизировать под клиента на уровне конфигурации.
Уровень сложности повышает и большое число внешних интеграций: с джоб-сайтами, соцсетями, СМС-операторами, телефонией, почтой, календарями и многим другим.
Мы вкладываем много ресурсов в разработку публичного API и webhooks. Благодаря ему клиенты могут делать любые интеграции на базе Хантфлоу — например, с Телеграмом и Слаком. Мы мечтаем, чтобы со временем Хантфлоу стал использовать наше API в качестве бэкенда.
______
ПРОЦЕСС РАБОТЫ В ХАНТФЛОУ
Оба сооснователя Хантфлоу из разработки (дизайнер и программист), поэтому ежедневная работа, от которой не тошно, — наша высшая ценность.
Наш процесс разработки такой: дизайнеры проектируют и описывают функциональность → разработчики декомпозируют и оценивают задачу → начинают разработку → код-ревью → тестирование на отдельном тест-стенде → мердж → релиз.
Мы делаем 3–5 релизов в неделю: не дожидаемся окончания спринта, а мерджим и релизим клиентам фичи сразу же после разработки, ревью и тестирования.
Мы ведем разработку на Гитхабе, а задачи трекаем в Джире. У нас внедрен Cl (TeamCity/Jenkins), который позволяет прогонять независимые тесты для каждой ветки и поднимать тестовый стенд для каждой фичи, не блокируя тестирование соседних фич.
______
С КАКОЙ АРХИТЕКТУРОЙ ПРЕДСТОИТ РАБОТАТЬ?
Хантфлоу — это SAAS. Но для крупных клиентов мы разворачиваем отдельные инстансы — на выделенных серверах в нашем дата-центре или на серверах клиента (on-premise). При этом кодовая база Хантфлоу — общая, а релизы на все инстансы мы делаем практически день в день.
В Хантфлоу микросервисная архитектура: это позволяет нам экспериментировать и использовать тот язык программирования, который лучше всего подходит для задачи. Например, наш сервис нотификаций в браузер написан на Erlang.
______
ИЗ КОГО СОСТОИТ ОТДЕЛ РАЗРАБОТКИ ХАНТФЛОУ
Дизайнеры интерфейсов
Бэкенд-разработчики
Фронтенд-разработчики
Тестировщики
Девопс
Проджект-менеджер
______
КОГО МЫ ИЩЕМ
Опытного в асинхронном программировании питониста, который работал с микросервисами, ORM (pewee), проектировал HTTP REST API.
Того, кто хочет выбирать, как ему работать: в офисе или удаленно из любой точки мира.
Того, кому надоели компромиссы между тем, чтобы сделать хорошо или сделать быстро, — мы всегда делаем хорошо, а сроки обсуждаем совместно с командой.
______
ЧЕМ ПРЕДСТОИТ ЗАНИМАТЬСЯ В ХАНТФЛОУ
Улучшать имеющийся функционал и разрабатывать новый.
Участвовать в принятии архитектурных решений.
Быть инициативным и предлагать свои идеи, в том числе если это касается использования новых технологий.
Проводить code review.
______
ТЕХНОЛОГИЧЕСКИЙ СТЕК
Python 2.7, 3.5+ (сейчас переезжаем с 2.7 на 3.7), Tornado, Aiohttp, PostgreSQL, Elasticsearch, redis, pewee, docker.
ЧТО МЫ ПРЕДЛАГАЕМ
Формат работы — офис в Москве или удаленно. Каждые полгода мы собираем всех в Москве, чтобы вместе потусить.
Полностью белую зарплату.
Свободу влияния на продукт — мы готовы обсуждать любые ваши идеи.
Основатели — дизайнер и разработчик, так что идиотских требований от «бизнеса» и бессмысленных совещаний не будет. Вместо этого — неформальность общения, уважение и открытость.
Оплачиваем сотрудникам конференции и профессиональную литературу.
______
КАК ПРОХОДИТ СОБЕСЕДОВАНИЕ
Мы не верим в тестовые задания, так что вам не нужно будет тратить вечер на решение задач.
20-минутное собеседование с HR Анастасией Василевской.
Собеседование с техническим директором Виталием Глибиным.
Присылайте ваши резюме на почту или в Телеграм.
К такой вакансии практически не остается вопросов, ведь в ней, по сути, перечислено все, что нужно кандидату.
Напоследок хочу попросить вас о том, о чем всегда прошу рекрутеров на своих тренингах. Когда пишете вакансию, обязательно смотрите на нее глазами человека, которому вы ее адресуете. Просто представьте себе вакансию рекрутера, которая выглядит вот так:
Ну как вам? Не правда ли, исчерпывающее описание? Прямо-таки захотелось откликнуться. Встать и пойти. И еще раз откликнуться. А потом трудоустроиться. И жить долго и счастливо.
Приблизительно так выглядят наши вакансии для разработчиков, когда в них нет никакой конкретики. Давайте не будем сами себя подставлять.
Самое важное, о чем мы должны помнить, — на той стороне такие же люди. Да, это айтишники, да, они чуть лучше разбираются в технической части, и большинство из них — не гуманитарии. Им легче читать простой и понятный, не перегруженный текст. А если он еще и конкретный, то вообще роскошь.
Раздел 2
Сфера IT. Основные языки программирования, понятия и термины
Чтобы быть успешным IT-рекрутером, далеко не обязательно быть программистом, но, как я уже писал раньше, важно обладать базовыми знаниями в IT-сфере. Для этого, по моему мнению, необходимо иметь представление о системе разработки ПО: какие этапы она включает в себя, на каких языках осуществляется программирование и чем языки отличаются друг от друга, что такое тестирование, системное администрирование и другие направления деятельности.
В этом разделе мы рассмотрим основы — базис, на который вы сможете опереться в своей работе. Остальные же знания, я уверен, вы приобретете в процессе поиска кандидатов через общение с работодателем, самими кандидатами и с помощью более специфических справочных пособий (много актуального и полезного, например, можно найти на habr.com), которые будут вам необходимы для закрытия той или иной вакансии.
Важное уточнение! Этот раздел написан рекрутером для рекрутеров, поэтому информация упрощена, и если ее будет читать гик, он непременно найдет неточности. Но наша цель — дать базовое понимание основных процессов и терминов.
Глава 5
Компании на рынке IT
Для начала давайте кратко разберем, какие типы компаний существуют на рынке IT, то есть каким именно организациям необходимы хорошие IT-специалисты (которых вы, по результатам прочтения этой книги, будете подбирать еще быстрее, увереннее и качественнее).
IT-компании условно можно разделить по следующим типам деятельности:
● продуктовая разработка;
● заказная разработка.
Также существуют компании-вендоры, IT-консалтинг и IT-отделы в организациях, напрямую не связанных с разработкой ПО.
Мы рассмотрим их деятельность с акцентом на то, как их воспринимают кандидаты: какие плюсы и минусы они видят в трудоустройстве в организацию того или иного типа и вида.
Продуктовая/собственная разработка. Компании, занимающиеся этим видом деятельности, разрабатывают и продают свой продукт. Среди классических примеров — всем известные Microsoft, «Лаборатория Касперского», Google, «Яндекс», Cian, Avito и др. Такие организации или развивают один продукт, или реализуют сразу несколько проектов — главное, что все задачи по разработке, маркетингу, исследованию рынков и ценообразованию фирма решает сама.
Можно выделить два подтипа продуктовых компаний:
● создание главного продукта;
● создание продукта, обеспечивающего жизнедеятельность офлайн-бизнеса.
В первом случае компания производит собственный IT-продукт — некий софт, который продается и является основным источником прибыли: операционные системы, онлайн-бухгалтерия, антивирусы и т. д.
Во втором — компания изначально занимается офлайн-бизнесом, например розничными продажами, доставкой товаров, финансовыми операциями, строительством. Ее программные продукты идут не на продажу, а обеспечивают собственные нужды организации: для розничной продажи, например, нужен интернет-магазин, и т. д.
Какие преимущества видят кандидаты в продуктовых компаниях? В первую очередь стабильность и перспективы роста (пусть не быстрого, но планомерного). Однажды устроившись в «Яндекс», можно провести там всю жизнь, постепенно развиваясь в своей специализации или осваивая смежные профессии.
В крупных продуктовых компаниях есть время и средства, чтобы отлаживать бизнес-процессы, повышать квалификацию персонала, обучать и мотивировать сотрудников. Отсюда — комфорт и устойчивое ощущение, что «в Багдаде все спокойно». Но давайте не будем идеализировать большие продуктовые команды: у них достаточно времени, чтобы выстроить процессы, но вы же не думаете, что все компании реально выстраивают процессы? Нет, разумеется. И среди больших продуктовых компаний есть те, которые так и не внедрили изменения, уже считающиеся условной нормой на рынке. Так что тут все всегда зависит от конкретной компании.
С психологической точки зрения для разработчиков такие компании привлекательны тем, что они видят результат своих трудов, а значит, есть чувство моральной удовлетворенности. Часто программисты уходят из заказной разработки в продуктовые фирмы именно по этой причине: «Я хочу гордиться тем, что делаю».
Кроме того, в продуктовых компаниях у сотрудников часто есть больше возможностей влиять на этот продукт, то есть над ними нет заказчика, который просто диктует условия, а сотрудник становится тупым исполнителем.
Но, бесспорно, есть и весомые минусы. Самый главный из них — скука. Порой работа внутри продуктовой компании не отличается разнообразием: программист может несколько лет заниматься одним и тем же продуктом или модулем. Или работать в поддержке старых продуктов: бесконечно «фиксить баги» — исправлять ошибки, разрабатывать дополнительные внутренние инструменты. Такая монотонная деятельность без дополнительных интересных задач может деморализовывать. Ну и в конце концов, если компания крупная, то она может обрасти бюрократией, от которой будут мухи дохнуть.
Заказная разработка — это аутсорсинговые или сервисные организации, которые, как и следует из их названия, разрабатывают программное обеспечение под заказ для других фирм. Компании передают определенные бизнес-процессы или производственные функции на аутсорс, а фирмы-аутсорсеры «продают» им собственных специалистов в качестве рабочей силы. Примеры таких компаний: ICL, SimbirSoft, «ЛАНИТ», «Ай-Теко» и др.
В каких случаях для бизнеса актуален именно такой вид сотрудничества? Есть несколько характерных ситуаций, при которых, как правило, обращаются к аутсорсерам:
● Проверка бизнес-гипотезы. Когда разработчики ПО не уверены, стоит ли вкладываться в новый проект, его минимальную версию (так называемую MVP[14]) заказывают сторонней организации. Это отлично экономит и бюджет, и время. Если по результатам работ идея оказывается актуальной, компания берется за ее реализацию самостоятельно: нанимает продуктовую команду, выстраивает бизнес-процессы, планирует маркетинговую составляющую.
● Разработка уникального решения. Бывают ситуации, когда коробочные (то есть уже существующие) программные продукты не покрывают все потребности компании. Например, порой компании заказывают разработку ERP-системы, потому что существующий коробочный функционал той же 1С их не устраивает, SAP — это очень дорого, а компания считает, что их процессы уникальны. Тогда она решает обратиться к аутсорсеру.
● Разовые или регулярные доработки и усовершенствования существующего продукта, например «затачивание» 1С под нужды того или иного производства. В таком случае зачастую выгоднее обратиться в специализированную фирму, чем нанимать своих разработчиков, так как собственный штат обойдется существенно дороже.
Какие плюсы существуют в аутсорсинговых компаниях? Здесь потенциального сотрудника ждет большое разнообразие проектов, что позволяет быстро повысить свою квалификацию и стать многопрофильным специалистом. У разработчиков нет необходимости думать о конечном пользователе: они ориентируются на ТЗ заказчика, а не на переменчивые вкусы потенциальных покупателей софта.
В этот вид компаний легче войти при наличии небольшого опыта, и, как уже было сказано выше, есть возможность быстро расти по мере увеличения клиентов компании.
Однако большое количество различных задач имеет обратную сторону: нередко разработчики отзываются об аутсорс-компаниях как о конвейерах. Ты меняешь несколько проектов за год, делаешь какую-то «свою» часть работ — и не видишь конечного результата. Это негативно влияет на мотивацию, и многие решаются по этой причине менять работу.
Кроме того, в аутсорсе очень сложно общаться с заказчиком. Далеко не всегда от лица компании с разработчиками коммуницирует технически грамотный специалист, и тогда общение происходит в прямом смысле слова на разных языках — с соответствующими печальными результатами работ. Или же заказчик бывает таким упертым и негибким (или чересчур гибким), что подрядчикам приходится пилить уже неактуальный, но согласованный в ТЗ функционал или регулярно менять курс, не понимая, с чем это связано.
Плюс к этому есть аутсорсинговые компании, которые работают по ТЗ заказчика, поддерживая legacy-код — то есть систему, которая была написана кем-то раньше (возможно, на устаревшем языке программирования). В обиходе программистов такой вид деятельности называется «работой на галерах». Представьте, вы сталкиваетесь с некоей программной сущностью, которую написал кто-то — возможно, не очень талантливый и одаренный — много лет назад. Это своеобразный программный лабиринт, в котором даже сориентироваться не всегда возможно, не говоря уже о том, чтобы поддерживать его в порядке. Поэтому есть компании, которые полностью отказываются от такой деятельности и берутся за разработку только с нуля. В таком случае уровень «страдания на галерах» можно значительно снизить.
Кстати, по-хорошему разработчики должны покрывать свой код документацией, которая объясняет, что делает тот или иной кусок кода. Тогда новому сотруднику будет понятно, что для чего нужно. Но в случае с legacy такой документации зачастую нет. Вместо нее — костыли, то есть временные решения каких-то проблем: изначально хотели сделать всё хорошо и грамотно, но разработка требовала слишком много времени — и от глобальной переделки отказались. Что-то вроде заклеенного изолентой шлема живущего на Марсе Мэтта Деймона в фильме «Марсианин».
Вендор — это компания, разрабатывающая технологии под собственным брендом. На базе их разработок другие организации могут создавать свои продукты. К такому виду компаний относятся Intel, IBM, Oracle, а наиболее известный российский вендор — фирма «1С».
С точки зрения трудоустройства вендоры очень похожи на продуктовые компании: здесь так же стабильно и спокойно, но иногда скучновато.
IT-консалтинг — эти компании занимаются внедрением уже готового программного обеспечения. Организации, не связанные с разработкой ПО, но нуждающиеся в нем для обеспечения своих нужд, нанимают консалтинговые компании, чтобы те выбрали, предоставили и внедрили им коробочные решения для сопровождения бизнес-процессов.
Работа консалтинговой компании состоит из следующих этапов:
● Консультант собирает информацию о том, какие процессы происходят в организации, анализирует их и предлагает то или иное коробочное решение.
● Если в ходе анализа выясняется, что одного типа софта недостаточно, а нужно, например, объединить несколько систем в одну, то к задаче подключаются разработчики.
● И наконец, новая система внедряется: специалисты проверяют ее работоспособность и обучают сотрудников компании пользоваться новым софтом.
Примеры организаций, которые успешно занимаются консалтингом на российском рынке: «ЛАНИТ», «Ай-Теко», «Компьюлинк», «Террасофт», «ЭкоСофт».
В IT-консалтинге есть несколько неоспоримых преимуществ. В частности, финансовая мотивация в этом секторе порой выше среднего. А удовлетворенность работой высокая: вы чувствуете свою сопричастность к развитию крупных, известных компаний — это настоящая помощь, которая не просто оплачивается. За нее искренне благодарят! При хорошем развитии событий, конечно же.
Что же может пойти не так? Консалтинг — это работа с людьми: представители заказчика могут быть некомпетентны в технологических вопросах. Из-за этого возникают разногласия, требования в процессе работы могут многократно меняться, сроки внедрения — откладываться. Это важный стрессообразующий фактор, который не всегда окупается даже самыми высокими зарплатами.
Наверно, важно также отметить, что консалтинг — понятие чуть более широкое, чем заказная разработка, потому что, помимо непосредственно разработки, консалтеры предоставляют инфраструктурные решения. Но четкого разделения на рынке чаще всего нет.
IT-отделы в компаниях. На сегодняшний день практически не осталось организаций, которым не нужны технологии. Поэтому в компаниях, не связанных с производством ПО, стали появляться IT-отделы, а в некоторых случаях даже дочерние IT-компании. Крупные подразделения разработки есть в банках, страховых фирмах, в организациях, занимающихся строительством и продажей недвижимости.
Преимущества работы в таких структурах обычно измеряются финансовой мотивацией, стабильностью компании и брендом работодателя.
Недостатки же похожи на те, с которыми сталкиваются сотрудники продуктовых компаний: однотипные задачи, постоянная доработка существующего софта, бюрократия, регламенты и фиксированный график (не всегда, разумеется, но бывает).
Поделиться книгой: