Русский
Русский
English
Статистика
Реклама

Онбординг

Наковали кадров как первая линия техподдержки стала одним из главных каналов онбординга

18.05.2021 18:11:11 | Автор: admin

Привет! Я Илья Тананаев. Руковожу отделом первой линии техподдержки в ITSumma. И хочу поделиться опытом, как из поиска решения проблемы пропущенных чатиков с клиентами мы построили кузницу кадров. Успешно успевая при этом обрабатывать 3k+ клиентских обращений в сутки.

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

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

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

С чего всё началось

ITSumma начиналась с того, что мы помогали сайтам выдерживать нагрузки и не падать при любых обстоятельствах. Сейчас, спустя 13 лет после основания компании, техподдержка уже далеко не единственное направление нашей работы, но по-прежнему существенное. У нас большой отдел эксплуатации, который следит за инфраструктурой клиентов и реагирует на инциденты 24/7 с SLA в 15 минут.

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

С ростом числа клиентов дежурным админам стало слишком тяжело одновременно решать свои обычные рабочие задачи и отвечать на запросы клиентов; начали появляться потерянные или неотвеченные клиентскиечатики. Мы поняли, что пора разделить контроль за отслеживанием входящих запросов и задач и, собственно, их исполнение.

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

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

Итерации решения

Сначала первая линия не работала 24/7, да и в принципе, не сразу взяла на себя работу с вообще всеми клиентами. Тем не менее, когда мы вышли на две стабильные смены с 7 утра по Москве (с 12 по Иркутску наш стандартный режим для большинства сотрудников) и с 11 по Москве в будние дни, это уже сильно сняло нагрузку с админов и помогло упорядочить работу. Мы поняли, что первая линия действительно полезна, а от админов круглосуточной техподдержки поступил запрос на работу первой линии не только в дневное время.

В 2019-м мы ввели еще смены для подстраховки на время пиковой нагрузки по будням с 10 утра по Москве. А позже, проанализировав ситуацию, решили, что нужно переводить первую линию на 24/7 чтобы помогать техподдержке всё время.

Итоги первого года работы первой линии:

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

  • Ответственным за SLA стал не только отдел эксплуатации, но и первая линия поддержки.

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

  • Сотрудники первой линии начали не просто передавать задачи и создавать таски, но и самостоятельно выполнять некоторые из них, например, обновлять сертификаты. Чем помогли админам эффективнее использовать свои ресурсы.

  • Высвободили часть ценного времени ведущих админов, тем самым получив ресурс для роста компании.

Постепенно на первую линии перешло реагирование на некоторые алерты мониторинга, обновление сертификатов, редактирование конфигурации nginx и ssl certbot. Например, если у клиента в ночное время приходил алерт по продовой площадке и не резолвился, то нужно было оповестить клиента в течении 15 мин согласно SLA.

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

Расписание для людей

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

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

Мы попробовали разные варианты: 8- и 12-часовые смены, только дневные и только ночные, вперемешку и т.д. Вот что получилось:

  • Думали было над 12-часовыми сменами вперемежку день/ночь но даже не стали пробовать на практике: поразмыслив, поняли, что это был бы жестокий удар по биоритму и здоровью.

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

  • Отдельно ночные и дневные дежурные вариант, которые устроил больше всего.

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

Развитие специалистов первой линии поддержки

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

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

Но это нам теперь понятно, что развитие выгодно и сотрудникам, и нам, как компании. А началось все очень прозаично и прагматично.

Таско-дни или командировки в другие отделы

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

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

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

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

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

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

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

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

Направления для командирования сотрудников первой линии поддержки такие:

  • документация;

  • мониторинг;

  • эксплуатация;

  • дежурства второй линии;

  • аккаунтинг;

  • и даже разработка.

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

Это нас возвращает к тому, зачем понадобилось автоматизировать обучение. Компания быстро развивается, есть много возможностей для роста, и в итоге достаточно часто на первую линию нужны новички (не путать с текучкой, её у нас как раз нет). Так настройка системы обучения и knowledge sharing превратились в приоритетные задачи.

Онбординг-курсы

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

Документирование нашей работы прошло довольно стандартный путь:

  • Понятно, что сначала документации как таковой не было были разрозненные наброски.

  • На первой итерации по улучшению я выделил время и постарался её систематизировать стало чуть лучше, но еще не достаточно.

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

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

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

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

Для автоматизации процесса онбординга поднялиMoodle и сделали свои курсы. Они состоят из некоторой справочной информации, видеоуроков и тестов. У роликов есть временне метки с описаниями, поэтому к такому материалу удобно возвращаться, если позже понадобится что-то уточнить.

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

При проверке скрипта на корректность перед запуском на какие критерии обращаем внимание?

1. block for commit.

2. block for delay.

3. PS/SQL file successfully completed.

4. exit.

5. set auto commit off.

6. current schema.

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

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

Можем ли мы изменять категорию задач вручную в созданной задаче? Если да, то где?

a. Можем, но аккуратно в Состояние.

b. Нет

c. Можем. В созданной задаче в правой колонке. Там, где Категория

d. Неее. Такого быть не может

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

Как видите, это не похоже на строгую сертификацию. Это просто еще один способ помочь новому сотруднику усвоить много информации в короткие сроки.

После доработки документации онбординг курсы это лучшие инвестиции в развитие отдела.

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

  • Сэкономили время опытных специалистов на онбординг новичков.

  • Уберегли главного наставника новичков от выгорания.

  • Сделали онбординг качественнее (и это, пожалуй, главное). Когда один и тот же человек пятый-десятый раз рассказывает одно и то же, он легко может что-то пропустить, потому что путается, что кому уже рассказывал. С автоматическими курсами такое не произойдет.

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

Результаты

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

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

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

Сейчас в первой линии работает 13 человек, из них 4-5 постоянно находятся в командировках в бэк-отделах, получают новые знания и повышают имеющиеся. За время этого не очень-то длинного эксперимента уже 9 человек пошли на повышение. Например, первая линии поддержки была отправной точкой для тимлида отдела дежурств и тимлида отдела документации, специалистов в отделах документации, мониторинга, бэкапов и аккаунтинга.

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

Takeaways

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

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

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

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

Подробнее..

Перевод Принципы онбординга новых пользователей

27.10.2020 14:04:24 | Автор: admin

Как привлекать и активировать пользователей.

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

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

Что такое онбординг

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

Онбординг это процесс между регистрацией пользователя и его превращением в вовлеченного пользователя.

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

Мне нравится, как Джулиан Шапиро разбивает этот процесс на два этапа:

  • Первый сеанс. Всё, через что проходит пользователь сразу после первой регистрации. Если потерять пользователя здесь, он наверняка никогда не вернется.

  • Последующее вовлечение. Всё, что происходит далее, в том числе уведомления, поддержка и использование продукта на ранних стадиях.

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

Зачем нужен онбординг

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

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

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

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

Намерение пользователя

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

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

  • Почему вы искали продукт X?

  • Что вы надеялись получить от него?

  • Что отличает его от конкурентов?

  • Помог ли продукт достичь желаемых целей?

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

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

Анализ вовлечения пользователей

Уже готовы сломя голову кинуться вносить изменения в продукт? Притормозите: нам предстоит пройти еще один этап изучения этой темы. Согласно общему правилу, сбор информации полезно отделять от созидания. Это же относится и к созданию продукта. Что делают лучшие пользователи, когда учатся работать с вашим продуктом? Здесь мы опускаемся на уровень ниже изучения того, какую пользу дает продукт, и узнаем, каким образом пользователи извлекают эту пользу. Выделив самые важные действия, можно сформировать процесс онбординга таким образом, чтобы они поощрялись.

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

Занимаясь онбордингом для Hugo, я действовал следующим образом:

  1. Выбрать метрику успеха.

  2. Сгруппировать данные на уровне пользователей по множеству событий.

  3. Сделать таблицу, в которой можно считать корреляцию между столбцами.

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

Устранение препятствий

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

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

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

Обучение

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

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

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

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

Увлечение

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

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

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

Продуктивность

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

Итерации

Опубликовать новый процесс онбординга это еще не всё: к онбордингу следует относиться как к любой другой функции продукта, то есть постоянно оптимизировать и делать итерации.

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

Удержание пользователей в онбординге

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

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

  • Внимание. Что не даст пользователю отвлекаться на другие 10 миллиардов интересностей в Интернете? Ваша задача снизить воздействие отвлекающих факторов. Дайте понять, что нужно делать дальше, и по возможности не уводите внимание от этого.

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

Возвращение пользователей в онбординг

Когда пользователи уходят на ранних этапах, это, конечно, неприятно, но мир не совершенен. Что делать, когда такое происходит (а такое обязательно произойдет)?

  • Средство связи. Как связаться с пользователями, которые отвалились? На этот вопрос существует не так много подходящих ответов, но важно выбрать для своего приложения правильное сочетание. Начинать стоит с электронной почты, push-уведомлений и ретаргетинга.

  • Сообщение. Допустим, вы нашли пользователя, которого хотите вернуть, что вы собираетесь сообщить? Можно, например, напомнить ему, что он не завершил начатый процесс. Или сказать, что что-то изменилось например, упали цены или появилась новая функция. Наконец, вы можете дать и более полезную информацию. Главное здесь выбрать структуру, лучше всего подходящую в контексте действия, которое пользователь собирался выполнить, когда выпал из онбординга.

Другие принципы онбординга

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

Кастомизация и персонализация

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

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

Лазер, а не дробовик

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

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

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

Активный и пассивный онбординг

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

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

Приятные первые моменты

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

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

Продуманные настройки по умолчанию

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

Учитывайте различный контекст

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

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

Триггеры и характер использования продукта

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

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

Онбординг навсегда

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

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


Статья первоначально опубликована в блоге conordewey.com.

О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Подробнее..

Recovery mode ИТ-аутстаффинг глазами клиента обсуждаем с руководителем разработки Mail.ru Cloud Solutions

03.03.2021 14:04:54 | Автор: admin

В 2021 году половина российских компаний планирует нанимать временный персонал для привлечения к проектной деятельности. Это показал опрос Hays, в ходе которого высказались почти 5 тысяч респондентов. 15% из них планирует за счет аутстаффинга оптимизировать свои расходы. 7% опрошенных испытывают сложности с поиском подходящих сотрудников в штат.

Компании Holyweb, которая специализируется на аутстаффинге ИТ-персонала, стало интересно, что стоит за этими цифрами. Они решили задать вопросы непосредственно тому, кто принимает такие решения руководителю разработки на стороне клиента.

Глеб Корсунов, CBDO Holyweb, обсудил с Михаилом Кебичем, руководителем разработки публичного облака Mail.ru Cloud Solutions, какие существуют опасения относительно аутстафф-подрядчиков, как безболезненно подключить внешних специалистов к инхаус-команде и как влиять на их мотивацию.

Приятного чтения!

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

Функция аутстаффинга дополнять, усиливать или заменять команду заказчика. Это рабочий инструмент, у которого есть свои плюсы и минусы. Мы в Mail.ru Cloud Solutions им пользуемся и нам он помогает.

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

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

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

С помощью аутстаффинга мы решаем задачи управления ресурсами быстро привлечь под задачу дополнительные руки и так же быстро сократить этот ресурс, если он не нужен здесь и сейчас. Если кто-то из аутстафферов уйдет, на наш бизнес это никак не повлияет. У нас своя разработка: все, кто отвечает за предоставление сервиса в режиме 24/7, работают во внутренних командах Mail.ru Cloud Solutions. На аутстафф мы стараемся отдавать полностью отчуждаемые задачи, чтобы они находились в зоне ответственности одной команды разработки от и до. Это могут быть сложные и объемные проекты на нескольких месяцев. Впрочем, мы всегда стремимся уменьшать циклы разработки стандартный спринт для инхаус-команды составляет две недели, и аутстафф двигается в том же ритме.

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

Как отношение инхаус команды к аутстафферам влияет на качество сотрудничества?

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

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

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

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

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

Как доверять, но проверять?

Универсальный совет выделите сотрудника, который следит за загрузкой специалистов и администрирует всю работу аутстафф-команды.

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

Если для эффективной работы программисту нужно играть на балалайке или в Dota пожалуйста. Оценивать мы будем результат.

Эта позиция в той же степени распространяется и на внутренних сотрудников Mail.ru Cloud Solutions.

Аутстафф-сотрудники не такие мотивированные, как штатные? Так ли это и как можно на это влиять?

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

При правильной организации процессов и хорошем онбординге вовлеченность и мотивация аутстфферов сопоставима с мотивацией штатного специалиста.

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

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

Когда можно делать первые выводы об эффективности аутстафферов? Первый месяц работы самый важный?

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

Если аутстаффер работает внутри команды, то мы в Mail.ru Cloud Solutions оцениваем его точно так же, как и штатных сотрудников. Онбординг новых специалистов занимает столько же времени, они полностью интегрируются в команду и работают по той же системе и с теми же KPI, что и инхаус-разработчики. КПД каждого отдельного разработчика измеряется в зависимости от сложности сервисов и задач, с которыми работает его команда. Быть эффективным и попадать в сроки команды невозможно без качественной коммуникации.

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

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

Как найти баланс при подборе разработчиков не перегнуть палку и не проглядеть подходящих кандидатов?

Мы проводим полноценное техническое интервью такое же, как для сотрудников Mail.ru Cloud Solutions, которых берем в штат. Обязательно уделяем внимание софт-скилам разработчика и его кругозору. Кроме того, устраиваем собеседование с руководителем команды и продуктовым менеджером.

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

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


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

Остались вопросы? Пишите в комментарии или Глебу в Facebook ответим всем.

Если вы хотите присоединиться к команде Mail.ru Cloud Solutions: прямо сейчас открыты вакансии Python/Go-разработчика в команду PaaS и Go-разработчиков в команды объектного хранилища и IAM.

Полный и актуальный список вакансий MCS.

Подробнее..

Как PHPPython разработчиков в Lamoda учат писать на Go

12.02.2021 10:14:08 | Автор: admin
Привет! Меня зовут Михаил Мохначев, я тимлид команды Core в Lamoda.

Наша команда занимается обеспечением работы сайта и системы приема заказов, что бы ни случилось. Мы очень активно используем язык Go 95% трафика идет через сервисы, которые написаны на нем. Но также есть сервисы на РНР и Python.

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

Найти кандидата, чьи навыки идеально подходили бы под наш запрос, очень сложно. Go-разработчиков в принципе мало на рынке, а Go-разработчиков, хорошо знающих к тому же PHP/Python, еще меньше. Поэтому мы решили подойти к этой задаче по-другому: мы нанимаем РНР или Python-разработчиков, и сами учим их писать сервисы на Go по рецепту Lamoda.

image


Технический онбординг: структура


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

Технический онбординг по Go в Lamoda:

  1. Представляет из себя статью-путеводитель в Confluence.
  2. Состоит из нескольких этапов.
  3. Рассчитан на прохождение за 2 недели.


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

Этап 1: предварительный


Время прохождения этапа: 1 день.

Заведение задачи онбординга, в которой сотрудник логирует время и учится работать с нашим таск-трекером.

Настройка окружения на новом рабочем ноутбуке сотрудника.

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

Этап 2: теоретический


Время прохождения этапа: примерно 2 дня.

Теория Go знакомство с документацией языка и основными практиками. Все нужные ссылки собраны в нашем путеводителе в Confluence.

A tour of Go каждый сотрудник, изучающий язык, проходит этот вводный курс, который является стандартом в обучении разработке на Go.

Знакомство с нашими внутренними спецификациями и требованиями (например, с соглашением о наименовании API-методов), которые будет необходимо соблюдать в дальнейшем при разработке.

Этап 3: создание собственного сервиса


Время прохождения этапа: неделя или чуть больше.

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

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

Так как мы используем подход Specification First, то первым делом сотрудник пишет OpenAPI спецификацию своего сервиса.

Затем на ее основе создается базовый код приложения при помощи генератора gogi.

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

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

Следующий этап тестирование. С unit-тестированием в Go все хорошо оно по сути встроено в язык и описано в документации. А для функционального тестирования мы используем инструмент Gonkey (про автотесты с помощью Gonkey у нас есть целая статья). Он не требует написания кода, лишь интеграции и новичок знакомится с ним, тестируя свой сервис.

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

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

Этап 4: инфраструктурный


На этом этапе сотрудник встраивает созданный им сервис в нашу систему.

Он узнает, зачем нужны Makefile, и какие команды должны в них присутствовать.

А также какие docker и docker compose файлы нужно создать, чтобы приложение могло развернуться через Bamboo на боевом окружении, и чтобы другой разработчик мог развернуть его у себя локально.

Результат технического онбординга


Что получает новый сотрудник?

  • Он изучает Go, причем не только теоретически, но и практически. Так, как это работает у нас.
  • Познает все наши инструменты для создания сервисов.
  • Осознает инфраструктуру.

Причем это происходит в комфортном режиме обучения: без стрессов и дедлайнов.

Что получает Lamoda?

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

Хочу подчеркнуть, что при помощи технического онбординга мы не пытаемся создать Go-гуру, который знает все от и до. Наша задача научить человека писать сервисы по рецепту Lamoda.

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

Школы для разработчиков, корпоративные тренинги и онбординг-сервисы EdTech и TampD-стартапы, которые следует знать

31.01.2021 18:12:32 | Автор: admin

Мы запустили Актион Акселератор и ждем всех, кто делает MOOC-курсы, решения в духе Education 4.0, сервисы для обмена знаниями, онбординга и управления персоналом. Помогаем ресурсами и экспертизой независимым командам и тем, кто развивает что-то похожее in-house.

Участникам акселератора мы рекомендуем изучать сторонние EdTech и T&D-проекты смотреть, кто привлекает инвестиции и аудиторию. Сегодня делимся подборкой таких компаний.

Фотография: Max Duzij. Источник: Unsplash.comФотография: Max Duzij. Источник: Unsplash.com

Galvanize организует онлайн-курсы и очные тренинги для частных лиц и фирм, занимающихся разработкой программного обеспечения и data science. Управляет несколькими кампусами в США, где находится не только образовательная инфраструктура, но и коворкинги. Более восьми тысяч выпускников учебных программ Galvanize зарабатывают от 90 тыс. долларов в год в Amazon, Facebook, Google, Apple и нескольких сотнях других ИТ-компаний.

Команде удается поддерживать контакт с клиентами и оставаться в курсе того, какие им нужны навыки и специалисты. Отсюда высокая актуальность тренингов и конверсия студентов для выхода на работу 80% из них требуется менее шести месяцев, а рост заработной платы в среднем составляет 30 тыс. долларов. Эти моменты стали ключевыми в сделке с K12 крупным игроком в образовательной сфере, который выложил 165 млн долларов за проект в 2020 году.

Помимо Galvanize K12 выкупили еще одного организатора буткампов для разработчиков Tech Elevator, а потом переименовали себя в Stride, чтобы обозначить выход за рамки школьного образования и фокус на lifelong learning и персонализированном развитии карьеры собственных учеников. Кстати, за несколько лет до сделки Galvanize и сами приобрели двух производителей образовательного контента для аналитиков, дата-сайентистов и разработчиков, а глава последней компании возглавил Galvanize и довел его до сотрудничества с K12/Stride.

Из других примечательных особенностей запуск курса по машинному обучению вместе с IBM в 2017 году, когда компания решила познакомить аудиторию со своими облачными решениями и Watson API. Так появился IBM Cognitive Course.


Code Institute менее масштабный EdTech-проект из Европы. Он уступает Galvanize по численности сотрудников, но показатели трудоустройства учеников у CI даже выше до 94% выпускников выходят на работу менее чем за три месяца с момента завершения учебы.

Взаимодействие с бизнесом выстроено чуть иначе. Его представители контролируют качество контента напрямую. В экспертный совет входит и бывший CTO Red Hat, который сейчас работает в Google, ведущие инженеры PayPal, Mastercard, Dell и другихтехнологических компаний. Еще такой подход позволяет студентам получать дипломы Эдинбургского университета Нейпира там засчитывают CI-курсы в рамках классической программы по разработке ПО [Кстати, похожая система действует и в России в ИТМО экспертный совет оценивает стартапы магистров].

Фотография: Luca Bravo. Источник: Unsplash.comФотография: Luca Bravo. Источник: Unsplash.com

Команда работает над проектом шесть лет. Им управляет основатель и спикер Digital Marketing Institute. На старте Code Institute они провели seed-раунд на 500 тыс. евро, а в прошлом году привлекли 1,2 млн от двух венчурных фондов. Средства направят на развитие курсов и B2B-услуг.


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

Основатели Coassemble из Австралии. Ранее они занимались разработкой приложений и корпоративных образовательных программ. С 2016 года они привлекали клиентов в основном из США и развивали стартап на свои деньги. За это время им удалось заработать ряд индустриальных наград. В 2020-м команда решила обратиться к венчурному финансированию и в рамках первого раунда подняла 4,4 млн долларов. На эти средства Coassemble планирует расширить штат своего представительства в Денвере и сделать продукт доступным для небольших компаний ранее команда сотрудничала только с крупным и средним бизнесом.


Pathlight предоставляет инструментарий для онбординга и обучения сотрудников в связке с бизнес-аналитикой. Для всего этого здесь предусмотрены дешборды, интеграции с продуктами вроде Salesforce, Zendesk и Slack. Сервис делает ставку на отслеживание бизнес-показателей компании в режиме реального времени и помогает соотносить их с тем, как развивается команда. Для коучинга и управления персоналом есть шаблоны и мониторинг KPI.

Фотография: Ant Rozetsky. Источник: Unsplash.comФотография: Ant Rozetsky. Источник: Unsplash.com

Один из основателей проекта сделал exit из маркетплейса для автомобилей Shift и компании, разработавшей помощника для водителей Automatic. Для Pathlight команда привлекла 1,1 млн в рамках seed-раунда в 2016-м и еще 7 млн долларов от венчурного фонда в прошлом году. Сегодня она может похвастаться несколькими сотнями корпоративных клиентов из сферы финансов, электронной коммерции и менеджмента с многочисленным штатом сотрудников. Сервис помогает им управлять проектамина дистанционке, автоматизировать формирование отчетов с помощьюNLP-инструментария и проводить точечные образовательные сессии.


EmployStream/Able помогает управлять процессом онбординга сотрудников, которые только присоединяются к новому коллективу или переходят из одного подразделения в другое. Руководству и HR-департаменту компаний-клиентов Able позволяет кастомизировать бизнес-процессы отбора и оформления персонала, их наполнение и отправку уведомлений.

Одна из фишекпроекта электронный документооборот и шаблоны, соответствующие требованиям законодательства США для трудовых договоров, в том числе с удаленщиками. Еще есть интеграция с Salesforce. Все это подходит для компаний, которые нанимают постоянно и в большом количестве. Able помогает им быстрее справляться со скринингом кандидатов, проверкой документов и сократить количество ошибок при их оформлении.

С 2014 года команда работала под названием EmployStream и привлекла 4,5 млн долларов инвестиций, а в 2020-м провела еще один раунд на 7 млн и ребрендинг продукта. Кстати, он годится не только для крупных компаний Able используют десятки хантинговых агентств.


P.S. В одном из следующих материалов мы расскажем о компаниях, предоставляющих инструментарий для VR-тренингов медицинского персонала, плюс посмотрим на eLearning системы для развития других навыков, прокачки эмоционального интеллекта и soft skills.

Актион Акселераторподходит для команд, разрабатывающих решения в области корпоративного образования и управления персоналом. Он включает пять направлений: от Обучения 4.0 до организации информационного взаимодействия внутри коллективов предприятий. Мы делимся с участниками инфраструктурой и экспертизой Актион-МЦФЭР, а победителям каждого трека выделяем по 500 тысяч рублей.

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

Подробнее..

Онбординг как мы адаптируем сотрудников на удалёнке

11.11.2020 12:15:25 | Автор: admin

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

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

Преонбординг

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

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

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

Что мы готовим к выходу сотрудника?

  • узнаем, есть ли дома необходимая техника. Если нет организуем доставку из офиса;

  • необходимые доступы к внутренним сервисам;

  • план работ на время испытательного срока;

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

Первый день в компании

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

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

О чем говорим на первой встрече?

  • Рассказываем о том, чем занимается компания: история, продукты, значимые награды и достижения.

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

  • Объясняем, как и к кому можно обращаться. Например, в NAUMEN стараются избегать формальностей и сотрудники общаются друг с другом на ты.

  • Говорим о корпоративной культуре, ценностях и возможностях развития.

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

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

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

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

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

Первые три месяца в компании

Первые три месяца работы у новичков достаточно насыщенные. Им предстоит адаптироваться сразу в четырёх направлениях:

  • привыкнуть к коллегам и их стилю коммуникации в команде;

  • принять и освоить корпоративные правила;

  • перестать испытывать стресс из-за смены работы;

  • адаптироваться к рабочим процессам и самостоятельно выполнять рабочие задачи.

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

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

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

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

Также ответы на многие вопросы новенькие могут получить, не прибегая к помощи коллег, (не все же сотрудники должны быть экстравертами, верно?). На корпоративном портале под ответы на вопросы отведены два раздела. Первый для совсем новичков с базовой информацией о работе в компании, второй будет полезен абсолютно всем: здесь можно узнать где пообедать, как уйти на больничный или как рассчитывается заработная плата.

Performance Review

Заключительный этап онбординга Performance Review или PR. Это встреча, на которой новый сотрудник, руководитель и наставник обмениваются обратной связью и впечатлениями о том, как прошли эти три месяца. Цель PR по окончании испытательного срока подвести взаимный итог успешности и результативности достижения задач из плана работ.

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

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

Подробнее..

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

21.04.2021 18:22:57 | Автор: admin

Привет, хабровчане. Перевод статьи подготовлен в преддверии скорого старта онлайн-курса "IT-Recruiter".

Также приглашаем всех желающих на открытое демо-занятие Стратегия сорсинга и карты поиска в IT рекрутинге. На этом вебинаре обсудим:
Зачем нужна стратегия сорсинга?
Больше результатов при минимальных затратах.
Формируем карту поиска на основании приоритетности ресурсов.
Как наглядно можно сформировать стратегию сорсинга?
Что рекрутер получает в результате работы с картой поиска.


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

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

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

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

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

Напрашивается вопрос: почему онбординг такой отстой?

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

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

Есть во всем этом и положительный момент: можно исправить онбординг и сделать первый день работы похожим на вход в пятизвездочный отель.

1.Подумайте о личном

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

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

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

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

2. Используйте цифровую коммуникацию в свою пользу

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

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

3.Загляните под капот

Онбординг объединяет аспекты HR, преимуществ компании, IT, финансов и многие другие. Непросто думать одновременно обо всех источниках контента и системах, задействованных в работе бэкенда, да еще и о существующих бизнес-процессах.

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

4.Поговорите со старыми сотрудниками

Что в своем опыте они считают положительным? А что нет? Что больше всего им помогло? Узнайте, как они чувствуют себя сегодня. Продолжайте набирать и заботиться о существующей команде. Узнайте, что еще вы можете сделать для нынешних сотрудников.

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

5.Создайте сообщество

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

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

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


Узнать подробнее о курсе "IT-Recruiter".

Смотреть вебинар Стратегия сорсинга и карты поиска в IT рекрутинге.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru