В этой статье я поделюсь нашим опытом: как мы растили джунов до мидлов за полгода и при этом приносили пользу проектам. Расскажу, как проходило обучение, и разберу конкретные кейсы.
Лично я работаю в ИТ с 2008 года и выступал в проектах в разных ролях: был бизнес-аналитиком, архитектором, руководителем проектов и руководителем отдела. Поэтому я буду рассказывать об обучении с разных точек зрения.
Сначала поговорим о нашем практическом опыте и о том, как все происходило в реальности. Я расскажу, почему мы решили этим заняться, так как важно понимать нашу мотивацию. Затем – о заложенных в обучение идеях и нашем, как я считаю, необычном подходе. Поделюсь тем, что мешает джунам становиться хорошими специалистами и мидлами, далее подробно разберу сам процесс обучения, а в конце покажу результаты в цифрах.
Предпосылки
По нашему опыту, естественный рост джуна до мидла, если просто нанять человека на работу и оставить работать, занимает до двух лет. Все это время человек требует внимания и наставничества, а мы несем дополнительные трудозатраты.
При этом проекты продолжаются, и люди нужны нам уже сейчас. Поэтому мы решили, что два года – это слишком долго, и взяли на себя миссию готовить специалистов за шесть месяцев.
Есть еще один важный момент. Даже если человек работает у нас полгода или год, обычно у него есть опыт только на нескольких этапах проекта. На других этапах опыта вообще нет. С этим тоже нужно работать, чтобы специалист получался универсальным: мы могли поставить его на любую часть проекта, и он выполнял свою задачу, не требуя дополнительного внимания архитекторов.
Архитекторы всегда заняты. У них важные задачи, горят дедлайны, а тут приходит джун и говорит: «Слушай, мне непонятно, как формочку заполнять». Это тоже не очень хорошо.
Особенность 1С заключается еще и в том, что большинство людей, которые приходят к нам работать аналитиками, – бывшие предметники или бизнес-аналитики, которые раньше были бухгалтерами либо финансовыми менеджерами. Они не используют в своей работе такой важный инструмент, как схемы бизнес-процессов.
При этом специалисты, которые умеют пользоваться этим инструментом, получают неоспоримое преимущество и экономят время. Благодаря схемам бизнес-процессов сразу становятся видны белые пятна. Если этот механизм не использовать, вся информация остается на бумаге или в сплошном тексте, и результат получается не таким качественным, как хотелось бы.
Лично наша головная боль была связана с обработкой интервью. Она занимала очень много времени. Бывали случаи, когда на обработку часового интервью аналитик-джун тратил два-три часа.
Нас это не устраивало. Среди франчайзи очень большая конкуренция, и в результате мы не могли предложить привлекательную цену на обследование, выигрывали меньше тендеров и заключали меньше договоров. Поэтому решили с этим бороться.
Саша и Маша: герои нашего обучения
Наши герои – Саша и Маша. Именно их мы учим.
Это представители современного поколения, в основном поколения Z. Они, безусловно, очень умные, умеют работать с современными гаджетами и уже знают, что такое искусственный интеллект. При этом у большинства из них есть комплекс отличника, а сами они часто не уверены в себе.
На практике проблема Саши и Маши заключается в том, что их не очень хотят брать на проекты, потому что у них нет опыта. Но как им получить этот опыт, если они не участвовали в проектах? Получается замкнутый круг: их не берут на проект без опыта, а получить опыт без проекта они не могут.
Мы подумали над этой проблемой и пришли к простому выводу. Чтобы у них появился опыт, причем желательно системный, в ходе обучения нужно выполнить учебный проект, максимально приближенный к реальному.
Именно так у специалистов появляется необходимый опыт. Он получается системным, а архитекторам удобно брать таких людей в проекты, потому что у них есть одинаковое, стандартизированное понимание того, как нужно работать.
Ключевые навыки
Мы очень любим SMART, поэтому у нас обучение проходит не просто для галочки: «Я прошел обучение – молодец».
Мы разработали 40 компетенций, на которые необходимо обратить внимание в ходе обучения.
В ходе обучения аналитики не просто получают какой-то общий результат. По каждому навыку у них есть отдельная оценка, за развитие компетенций они получают звезды.
Саша видит, что ему, например, не хватает звезд по бизнес-архитектуре или схемам процессов, и понимает, чему нужно уделить внимание. Он может прийти и спросить: «Что мне сделать, чтобы все-таки развить этот навык?»
Таким образом, у нас появляется предметная обратная связь по конкретным навыкам, которые мы хотим проработать.
Всего компетенций 40, но я выделил семь навыков, которые особенно мне нравятся и которые считаю наиболее важными.
Первый – умение задавать вопросы. Об этом навыке я расскажу подробнее, потому что мы выяснили: главная проблема начинающих специалистов состоит именно в этом. Они не понимают, как работать с заказчиком, как правильно проводить интервью, как выстраивать и планировать работу, какие вопросы задавать.
Кроме того, очень важно научить джунов работать с контрольными примерами и готовить показ 1С для заказчика. Это важная функция, которую часто выполняют архитекторы или ведущие специалисты. Для нас это минус, потому что контрольных примеров много, их нужно показывать, а мы не можем все время отправлять архитекторов на такие задачи.
Поэтому мы вынуждены передавать эти задачи подготовленным джунам, но при этом должны требовать от них качественной работы. Они должны уметь эффективно проводить демонстрации контрольных примеров, потому что именно в этот момент заказчик по-настоящему понимает, как ему предстоит работать в программе. Это важно: пока он не увидит систему визуально, он ее не поймет.
Но нам нужно оптимизировать эту работу. Любой сотрудник должен уметь проводить контрольный пример. Это должна быть обычная задача, не требующая какой-то дополнительной колоссальной подготовки.
Отдельно мы выделили навык подготовки интервью: умение планировать встречу и объяснять заказчику, что мы от него хотим.
Еще один важный навык – использование схем процессов как метода экономии времени. Очень часто мы собираем информацию об одном и том же процессе у разных сотрудников заказчика. При использовании схем всегда визуально видно, остались ли белые пятна. Без нее у нас есть только сплошной текст, по которому непонятно, где информации не хватает.
Очень важно и то, как аналитик ставит задачу разработчику. В ходе обучения мы уделяем этому много внимания, потому что как мы объяснили задачу разработчику, так он ее в итоге и сделает.
Шестой навык – тестирование. Это «мастхэв» для любого аналитика 1С. У нас нет отдельной должности тестировщика, поэтому любой аналитик обязан уметь тестировать. От этого навыка зависит результат каждого этапа.
Кто-то недотестировал функционал, бухгалтер увидел, что ему не хватает нужной галочки, а для него это важная часть процесса. Он пошел жаловаться своему руководителю. Затем мы пришли на совещание, где должны подписать акт, а нам говорят: «Работы не приняты». В результате сроки сорваны, а мы несем дополнительные затраты на переделку функционала. Нам это не нужно.
Седьмой важный навык – знание Excel. Любой аналитик должен хотя бы знать, что такое ВПР и что такое сводные таблицы. Без этого никуда, потому что эти инструменты позволяют сэкономить колоссальное количество времени при анализе.
Поэтому в обучение мы заложили отдельный реальный кейс по Excel. В нем нужно пошагово выполнить все необходимые действия. Только после сдачи этого кейса аналитик получает подтверждение, что готов работать в Excel и является подготовленным специалистом.
К сожалению, этот навык необходимо проверять, даже если вы нанимаете бывшего бухгалтера или финансового менеджера. Оказалось, что это тоже важный вопрос.
Набиваем шишки на учебном проекте
Наши Саша и Маша уже полгода работают, многого нахватались и чувствуют эйфорию: у них что-то получается, они молодцы.
Но им не хватает важного знания: что делать, если что-то пойдет не так? Что скрывается за поворотом? Аналитик сделал свою задачу, после него работает разработчик, но что происходит там, он тоже не знает.
Поэтому наша задача в ходе обучения – создать такую систему, в которой специалисты смогут набить как можно больше шишек. Они должны увидеть эти ситуации, прочувствовать их и в дальнейшем использовать полученный опыт в реальной работе.
Пока они не набили шишки, пользоваться этим знанием они не будут.
При этом нам неважно, чтобы они достигали стопроцентного результата. Наша задача – дать им возможность столкнуться с как можно большим количеством проблем и отработать их.
Слушать лекции недостаточно!
Саша и Маша любят, когда к ним приходит умный человек и что-то рассказывает умными словами. Они слушают и говорят: «Ага, все понятно». Но, по моему опыту, через две недели эта информация выветривается, и ничего не происходит.
Поэтому основная часть нашего обучения – не лекции, а практика. Большую часть времени занимает самостоятельная работа. Есть жесткие дедлайны, в рамках которых участники начинают выполнять задачи.
Без практики знания не удерживаются. Если вы просто наняли умного внешнего консультанта, а он что-то рассказал, но практики не было, то можно считать, что деньги потрачены зря. Сила – в практике.
Сквозной сюжет и спасение галактики
Мы работаем с современным поколением, в основном с поколением Z. Обучение длится шесть месяцев, а значит, ребята могут быстро потерять к нему интерес.
Чтобы этого не произошло, мы придумали сквозной сюжет. Во время обучения постоянно что-то происходит. Мы не просто выполняем кейс в 1С, а с помощью 1С спасаем галактику, Землю и весь мир. Так гораздо веселее.
Можно взять классический кейс. Допустим, у нас есть деревообрабатывающий завод. На нем стоит станок, который делает 12 распилов в час. После него работает следующий станок, который должен шлифовать 20 деталей в час, но выдает только три. Нужно разобраться, почему.
Это скучно. Я бы не хотел выполнять такой кейс. У начинающего специалиста есть мессенджеры и множество других каналов, на которые он может переключиться, и все внимание к обучению пропадет.
Поэтому мы заменили этот кейс на более веселый. У нас не просто деревообрабатывающий завод, а предприятие по производству космических деревянных кораблей.
На заводе есть очень интересный станок. Он похож на домну, а внутри работают короеды – живые существа, которые питаются древесиной и вырезают нужный корпус.
Если завод работает неритмично, короеды начинают голодать, испытывают стресс и могут даже погибнуть. Такой кейс начинающим специалистам выполнять гораздо интереснее.
Мы делаем акцент на подобных историях, добавляем немного юмора, и людям это нравится.
Почему задания должны быть командными
Мы долго думали, должны ли задания быть индивидуальными или командными. Но ответ оказался достаточно простым.
Наши основные клиенты – крупные организации. В таких проектах результат всегда коллективный. Поэтому мы приняли решение, что участники должны работать в командах и выдавать командный результат.
Саша может прекрасно писать технические задания, но если в командной работе он ноль, то это огромный минус. Его необходимо переучивать, чтобы он мог встроиться в команду и работать на общий результат.
Сжатые сроки и синдром студента
Обучение должно проходить в сжатые сроки.
У нас был случай, когда участники жаловались, что ничего не успевают, и просили растянуть очередной этап. Мы пошли им навстречу и увеличили сроки. Но это не помогло.
Синдром студента никто не отменял: они все равно сделали все в последний момент.
Главный вывод для будущих проектов заключался в том, что при таких обстоятельствах нет смысла растягивать дедлайны. Они должны быть короткими.
В этом случае в учебном проекте появляется ритмичность: участники четко идут вперед, выполняют задачи одну за другой, и между этапами не возникает пауз.
Поэтому в обучении всегда должны быть сжатые сроки. Не нужно идти на уступки и растягивать это удовольствие.
Само обучение – это проект
В конце каждого этапа аналитик получает не просто общую обратную связь от наставника. У него есть конкретная таблица, где указано, сколько звезд он получил по каждому навыку и над чем ему еще нужно поработать.
Кроме того, очень важно собирать обратную связь с проектов. Поскольку в обучении много практики, ведущие наставники видят не всю работу участников. Сотрудники на местах могут подсветить проблему, которую мы затем разбираем и даем участникам соответствующую обратную связь. Они же помогают понять, кого из учеников следует дополнительно отметить.
Важно заранее планировать работу. Мы подошли к обучению как к проекту, поэтому у тех, кто его проводит, тоже есть обязательства. Перед каждым этапом мы собираемся, обсуждаем план, определяем, кому что нужно сделать и каких результатов необходимо добиться.
Однажды мы должны были провести важный кейс, но у ведущего эксперта заболел котик. Такое бывает, поэтому занятие пришлось отменить. Однако мы заранее запланировали резервные даты и изначально предполагали, что что-то может пойти не так. В результате эта ситуация никак не повлияла на общий график обучения.
Далее подробно поговорим про этапы обучения, как это все проходило.
Первый этап: инициация проекта
Первый этап обучения – инициация проекта.
Саша и Маша еще плохо знакомы друг с другом, поэтому мы объединяем их в команду. Кроме них есть еще две команды.
Для нас, как для преподавателей, основная задача этого этапа – познакомить участников и научить их работать вместе. В этот момент мы даем им относительно легкие задания.
Например, предлагаем разобраться, какие полезные функции есть в Excel или Word, прочитать книгу Карла Вигерса и сформулировать собственные выводы по прочитанному материалу.
Кроме того, даем немного теории и объясняем, почему проекты не возникают каждые два часа. Участники должны понимать, что это не так просто: сначала происходят продажа и инициация проекта.
Второй этап: обследование клиента
На этапе обследования клиента начинается настоящая работа.
Для начинающих аналитиков это обычно неизведанная область. Чаще всего они попадают на какой-то отдельный этап разработки и набирают компетенции именно там. Но нам важно подготовить их так, чтобы они могли самостоятельно провести обследование. Для этого необходимо научить их брать интервью, готовить схемы процессов и защищать проект перед заказчиком.
На практике во время этого этапа происходило множество событий. Однажды во время интервью наш Саша решил показать, насколько он умный. А умный он потому, что знает много ИТ-терминов.
Он задает начальнику производства, который практически не отходит от станков, вопрос: «Расскажите, как у вас происходит бизнес-процесс».
Начальник производства смотрит на него и хлопает глазами. Для него бизнес-процесс – это бизнес, деньги и что-то подобное. Он говорит: «Я вообще вас не понимаю».
В результате диалог не складывается, а заказчик хочет как можно быстрее закончить разговор.
Здесь приходится останавливать интервью и объяснять Саше, что так делать не нужно. В центре внимания находится заказчик. Аналитик должен разговаривать с ним на обычном языке или использовать терминологию самого заказчика, а не ИТ-термины. Большинство заказчиков – не айтишники. Это важно учитывать, но начинающие аналитики часто этого не понимают.
Был и другой случай. Ребята постеснялись идти на интервью по одному и отправились вдвоем: вместе им было смелее. Им казалось, что они сразу понимают, что хочет сказать заказчик, поэтому они начали его перебивать. В результате заказчик снова остался недоволен. Он считал, что его не слушают и что он не может донести важную идею. При таком подходе будущая автоматизация, скорее всего, окажется неверной.
Пришлось объяснять: «Так делать не надо. Заказчик находится в центре внимания. Дослушайте его мысль. Если вы этого не сделаете, он, скорее всего, свернет интервью, а вы не узнаете что-то важное». Этот баланс необходимо соблюдать.
На этом же этапе Саша и Маша получают первые шишки. Нам важно, чтобы они прочувствовали этап сдачи проекта, поэтому они самостоятельно его защищают. Они приезжают в офис, открывают презентацию и рассказывают заказчику, почему необходимо реализовать именно этот проект.
Нам важно посмотреть, как они ведут себя в стрессовой ситуации, чтобы в реальном проекте были к ней готовы. Поэтому мы заранее договорились с генеральным директором, и в решающий момент он зашел в помещение и начал задавать вопросы.
Мы смотрели, как Маша будет выкручиваться из этой ситуации и справляться со стрессом. Она, конечно же, справилась и продолжила презентацию.
Когда начнется реальный проект, подобных проблем уже не будет. Наши специалисты будут морально готовы к таким поворотам сюжета, и все пройдет гораздо стабильнее.
Кейс по умению задавать вопросы
Умению задавать вопросы мы посвятили отдельный кейс. Это важный момент, потому что на практике оказалось, что здесь тоже необходимо набить шишку.
Начинающие специалисты верят, что все знают, поэтому не до конца продумывают и формулируют вопросы. Мы создали специальный сюжетный кейс с кризисной ситуацией. Участникам нужно было провести четыре интервью всего за десять минут. Было три опрашиваемых, а все время строго ограничивалось.
Они приходили на интервью, начинали задавать вопросы и сразу сталкивались с первыми проблемами. Например, спрашивали: «Как вам помочь?»
Я люблю открытые вопросы, это прекрасно. Но на практике такой вопрос приводит к тому, что разговор начинается слишком издалека, хотя наша задача – выяснить последовательность бизнес-процесса: первое действие, второе, третье.
Приходилось корректировать участников: «Мы не в скорой помощи работаем. Этот вопрос сейчас не совсем уместен. Нам нужно выяснить последовательность действий. Спросите хотя бы, с чего начинается рабочий день человека».
Была и другая проблема. Ребята умные, поэтому никто никого не слушает. Они приходят на кейс вдвоем и на месте начинают выяснять, кто из них сейчас должен проводить интервью. Время интервью ограничено десятью минутами, мы закрываем эфир, а они не получают в результате вообще никакой информации.
Третий этап: проектирование
Следующий этап – проектирование. Для начинающих аналитиков он обычно неизвестен, потому что самую важную функцию здесь выполняет архитектор. Он придумывает всю систему и определяет, как она должна работать.
Но у аналитиков на этом этапе тоже есть важная задача: они готовят контрольные примеры, которые затем показывают заказчику. Именно здесь заказчик впервые видит, как примерно будет работать будущая система.
На практике, когда наш Саша начинает готовить показ контрольного примера, он первым делом выбрасывает из него все, что не относится к 1С. Все остальные функции кажутся ему лишними, хотя до этого участники нарисовали их и потратили на это много времени.
В результате заказчик просто не понимает, что происходит. Ему говорят: «Нажми кнопку здесь, потом нажми кнопку там». А он отвечает: «Но я еще делаю вот это».
Приходится возвращать аналитиков к полной картине: «Заказчик раньше обычно не работал в 1С. Ему нужно рассказать всю последовательность действий. Здесь он будет работать в 1С, а эту функцию продолжит выполнять так же, как раньше без 1С». Только после этого у заказчика складывается понимание того, как все должно происходить.
Был еще один важный случай. Маша рассказывала о работе с закупками. Она хотела показать, что хорошо знает систему, поэтому добавила информацию о замечательной обработке: если нажать одну кнопку, потом другую, получится очень хороший результат. Проблема заключалась в том, что заказчик эту обработку не заказывал. Маша потратила время, а заказчик не понял, зачем ему все это показывают.
Пришлось объяснять: «Контрольный пример – это показ только того, что указано в функциональных требованиях. Ничего лишнего добавлять не нужно». Сделаю пометку тут для руководителей, что это режим экономии: не делайте то, чего заказчик не просил.
Четвертый этап: разработка
Разработка – наш любимый этап. Здесь мы учим людей писать технические задания и проводить тестирование.
С техническими заданиями все было достаточно понятно. Мы пригласили ключевого разработчика, и он дал участникам хорошую обратную связь. После занятия я поговорил с разработчиков, и он дал обратную связь: «Наконец-то меня пустили! Я вам всем рассказал, как правильно писать технические задания. Давно хотел».
Главным открытием для нас стало тестирование. Оказалось, что нет универсальной методички по 1С, где было бы написано, как именно нужно его проводить.
В результате конкурентное преимущество получают аналитики, которые уже когда-то занимались тестированием. У них в голове примерно сложилось, что нужно делать, но системно объяснить это они часто не могут. В результате мы потратили много времени, чтобы понятно и последовательно объяснить аналитикам, как проводить тестирование.
На выходе мы получили от Маши прекрасный чек-лист. Команда, в которую она попала, стала показывать в тестировании лучший результат.
Я постоянно начал получать положительную обратную связь от разработчиков. Они говорили: «Ничего себе, они столько всего находят! Мы даже не знали, что такое может быть».
Конечно, мы уделили внимание и софт-скиллам. Выяснилось, что аналитики не понимают, зачем на проекте нужен руководитель проектов. Им кажется: «Я же умный, зачем мне руководитель?» Пришлось объяснять и это.
Пятый этап: опытно-промышленная эксплуатация
Финальный этап – опытно-промышленная эксплуатация. Именно здесь система непосредственно сталкивается с реальной работой заказчика. Все происходит в стрессовом режиме и для нас, и для заказчика. Поэтому особое внимание мы уделили специальному кейсу.
Задача участников – за 60 минут ответить на 100 вопросов. Казалось бы, ничего сложного, но на практике возникают разные ситуации.
Участники начинают разбирать вопросы, и Маша видит, что среди них есть задания, связанные с головоломками. Она очень любит головоломки и говорит: «Я буду заниматься ими». А на самом деле это «мусорные» вопросы, которые на результат не влияют.
В результате все сложные вопросы сыплются на одного Сашу. Они не успевают даже фиксировать вопросы, а общий результат команды падает. Даже информации о принятых решениях нет, потому что участники не успевают ее записывать.
На этом этапе мы также уделили время психологии заказчика.
Для Саши и Маши получение обратной связи и исправление ошибок – ежедневная рутина. Но заказчик в лучшем случае один раз в жизни сталкивается с подобным проектом. Для него это стресс.
Важно донести до начинающих аналитиков простую мысль: заказчики – такие же люди. Они не упертые бараны и существуют не для того, чтобы создавать аналитикам проблемы. Им действительно что-то мешает хорошо выполнять свою работу.
Результаты в цифрах
Обучение закончили 14 человек.
Инвестиции с нашей стороны как работодателя составили примерно 59 часов на одного человека. Я считаю, что это неплохой результат.
В среднем программа требовала 31 час в неделю суммарной вовлеченности команды, которая проводила обучение. Речь идет именно о наставниках и организаторах, а не об учениках.
После выпуска специалисты практически не требовали поддержки наставников. Уровень самостоятельности доходил до 90%.
Мы фактически получали готового специалиста, который мог встроиться в любую команду и начать системно работать. Самое важное – он не требовал дополнительного внимания.
Обычно после найма человека с рынка начинается разговор:
– А ты как это раньше делал?
– Вот так.
– Нет, мы делаем по-другому. Нужно делать вот так.
И человека приходится переучивать. В нашем случае такой проблемы нет, потому что все специалисты подготовлены по единому стандарту.
Отдельно я решил посмотреть, сколько подобное обучение стоило бы на рынке. Выбрал программы, которые мне понравились, и посчитал, что в текущих реалиях отделу персонала пришлось бы выделить на них минимум 3,5 миллиона рублей.
Мы все сделали самостоятельно и получили экономию около двух миллионов рублей. Практически в два раза.
Результаты по качеству
Есть и результаты, которые сложно выразить цифрами, но они не менее важны.
В командах, куда попали наши специалисты, значительно выросло качество тестирования. Практически все критические ошибки стали выявляться до того, как функционал доходил до заказчика. Следовательно, заказчики стали более довольными.
У аналитиков появилось понимание того, что такое дедлайн и почему важно заканчивать работу именно в срок. Они побывали на каждом этапе проекта и теперь знают: если плохо выполнить задачу, на следующем шаге это обязательно аукнется.
Преимущество получила команда, которая начала пользоваться таск-менеджером. Другие команды продолжали работать без системы, что-то забывали и в спешке передавали информацию устно.
Мы стали рекомендовать: «Пользуйтесь таск-менеджером. Тогда результаты будут стабильными и не будет переработок».
Люди часто жалуются на дедлайны, но на самом деле они жалуются на неудачную систему работы. У них просто нет системы контроля выполнения задач.
Повысилась и универсальность специалистов. Стало неважно, куда брать аналитика: на регучет, на закупки или на другой участок. Они ко всему готовы, все примерно попробовали и понимают, как работает вся эта история.
Еще один важный результат – максимальная лояльность персонала во время обучения. Причем не только со стороны тех, кто непосредственно учился. Дошло до того, что у нас стало ноль заявок на подбор: новых сотрудников начали набирать только по сарафанному радио. Однажды сотрудник, который услышал про обучение, решил к нам вернуться. Он сказал: «У вас такое классное обучение. Я хочу к вам обратно».
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
