Как отправлять разработчиков на конференции

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

Тут поможет опыт компаний, у которых этот процесс уже выстроен. А мы знакомы с их опытом, потому что проводим IT-конференции, куда отправляют своих разработчиков и супергиганты (Сбер, Яндекс, Mail.ru Group), и лидеры определённых сегментов рынка (HeadHunter, JetBrains, Контур). Поэтому вывели набор советов из всего, что узнали.

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

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

Поэтому стоит сразу решить, например, следующее:

— Из какого бюджета финансируется посещение конференций? (Обычно из бюджета на обучение, в который входят и другие вещи.)

— Отправляем ли разработчиков на конференции в другие города, или только на местные мероприятия?

— А в другие страны? (У некоторых компаний есть такая практика: на российские отправлять многих разработчиков, а на зарубежные — самых отличившихся.)

— Отправляем ли сотрудников на мероприятия не строго по их профилю? Что если Java-разработчик захочет на конференцию по тестированию? (У многих есть интерес к смежным темам, мы для таких даже сделали билет-абонемент на разные конференции.)

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

— Разработчик может просто сообщить «хочу поучаствовать в конференции», или должен обосновать «почему конкретно эта конференция будет мне полезна»?

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

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

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

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

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

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

Почему для компаний полезно проявлять активность первыми? Причин несколько.

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

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

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

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

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

Что в такой ситуации делать?

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

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

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

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

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

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

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

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

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

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

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

В целом этот текст подходит для любых конференций — хоть в офлайне, хоть в онлайне. А в чём специфика онлайн-мероприятий, что изменилось с пандемией?

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

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

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

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

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

Выше мы написали о том, как стоит делать. А как не стоит? Какие ловушки подстерегают на пути?

Проблема 1: чересчур сложный для разработчика процесс

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

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

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

Проблема 2: обязательность отчёта о посещённой конференции

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

— «Повод для нетворкинга разработчиков, укрепляются внутренние связи»

— «Сходит один сотрудник, а узнают что-то и другие»

— «Сотрудник будет внимательно слушать доклады»

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

Чтобы не вызывать негатив, можно сделать отчётные мини-митапы опциональными: приветствовать их, но не навязывать в обязательном порядке.

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