Что я отношу к HR
Для начала нужно определить, что я отношу к HR-процессам. Я даже специально почитал в интернете, что к ним относится, чем должны заниматься HR и вообще – кто всем этим должен заниматься. Оказалось, что, по мнению интернета, HR в том числе должны придумывать KPI и методы повышения эффективности работы программистов. Честно говоря, я никогда в жизни не видел, чтобы HR этим занимались.
На изображении примерное информационное поле, которое я отношу к HR-процессам, – это собеседования, вакансии, адаптация, обучение, наставничество, планы развития и т.д. Руководителей кто-то должен выращивать, если их неоткуда нанимать. Еще людей нужно увольнять, информировать, давать им обратную связь и так далее. Все это – HR. Вот обо всем этом и пойдет речь.
Конечно, было бы здорово, если бы в какой-нибудь большой компании существовала отдельная служба, которая всем этим занимается. А я как руководитель отдела пользовался бы этой службой как сервисом. Приходил и заказывал: «Дорогие ребята, мне нужно пять программистов с такими-то компетенциями. Через полгода приведите их, чтобы они были обучены, адаптированы и так далее».
Но это мечта.
Как все началось
Я пришел в компанию-франч, где сейчас работаю, какое-то время там поболтался, не зная, чем заняться и куда себя применить. Опыт у меня был большой, и я пробовал его то туда приткнуть, то сюда, поработал с разными подразделениями, но как-то не срослось. В итоге я создал новый, свой отдел – или мне его создали – и придумали цель. Сказали: «Давай ты наймешь 30 программистов, чтобы через год у тебя был отдел из 30 человек».
Нужно было не просто нагнать 30 программистов. Они должны были остаться, научиться, работать, приносить прибыль (потому что мы во франче), делать проекты и вообще стать полноценным отделом.
Для меня эта цель была амбициозной. До этого я никогда не нанимал и не учил 30 программистов.
С отделом HR я перестал работать очень быстро. Почему? Я пришел к ним и сказал: «Мне нужно нанять 30 программистов за год. Это примерно три программиста в месяц. Справитесь?»
HR у нас были. Они умели нанимать, у них существовали какие-то процессы адаптации. Но они сказали: «Нет».
Месяц мы что-то вместе попробовали. Уже на этапе того, как проводить собеседования, привлекать людей, проверять и адаптировать их, мы разошлись. Процессы, которыми пользовались HR, меня не устраивали. Они не давали нужного результата за требуемое время, а менять процессы HR не хотели.
Стоит отметить, что я их понимаю. Им за это особо не платят, ответственности за результат на них не лежит и полномочий у них нет. Поэтому мне всегда немного жалко HR. Среди них бывают люди, которые приходят с огоньком и хотят что-то сделать, изменить, чего-то достичь.
Например, внедрить классную программу адаптации, удержания или поднятия настроения программистов. Они идут к руководителю отдела и с огнем в глазах говорят: «Давай сделаем». А руководитель крайне редко отвечает: «Давай». Обычно он говорит: «Меня не трогайте. Делайте что хотите, но так, чтобы мои программисты не отвлекались от работы, и результаты не падали. И веселитесь». Поэтому все обычно сводится к каким-нибудь тимбилдингам или корпоративам.
Попытки найма готовых программистов
Первое, что я попробовал, – нанять готовых программистов. Но от этой идеи отказался очень быстро. С нужной скоростью – 30 человек в год, или три человека в месяц – я не мог находить готовых программистов в необходимом количестве и нужного качества.
По крайней мере, у нас в Челябинске готовые программисты крайне редко сами приходят во франч. Обычно HR видит резюме и начинает человека вызванивать.Опытный программист приходит, он уже считает себя специалистом и хочет много денег. Но при этом работать во франче он не умеет.
Я сам переходил с завода во франч и знаю, в чем разница. На заводе ты, во-первых, работаешь за оклад. Во-вторых, можешь практически бесконечно долго решать любую задачу. Время не ограничено и на твою зарплату никак не влияет.
Кроме того, на заводе у тебя более узкий кругозор. У тебя стоит УПП, от силы еще ЗУП. Когда ты приходишь во франч, у тебя в стеке должны быть 15 разных конфигураций. Задачи нужно решать быстро – вникать, разбираться. Нужно работать с совершенно разными людьми, быть вежливым, аккуратным, по возможности точным, попадать в сроки и так далее.
Я взял нескольких готовых программистов. И, честно говоря, картина получалась такая: берешь программиста, даешь ему задачу. Он решает ее плохо. Ты говоришь: «Дружище, ты плохо решил задачу».
Что он делает? Обижается и увольняется. Именно потому, что пришел с определенным апломбом.
Я быстро забил на эту идею. Возможно, потерял на нее месяц, а месяц – это уже почти 10% всего срока. Поэтому перешел к найму стажеров.
На всякий случай снова сходил к HR: «У вас есть какой-нибудь понятный процесс – вакансии, адаптация, – чтобы нанимать стажеров потоком?»
Они показали существующий процесс. Брали людей без образования и опыта и фактически говорили: «Садись, быстро учись. Если быстро научишься – будешь работать».
Конверсия у этого процесса была практически нулевая. Он мне не подошел, поэтому пришлось выстраивать все заново. С этого и начинается вся история.
Отдельным пунктом здесь идут зумеры. С одной стороны, нужно было разработать HR-процессы. С другой – научиться работать с зумерами. Все, о чем я рассказываю, происходило именно с ними.
Я очень много нового для себя узнал. Я не зумер, я вообще старый человек, мне за сорок. Но почти за семь лет, как мне кажется, я научился с ними работать. Зумеры были дополнительным усложнением – задачей со звездочкой.
Вакансии
Первое, с чего я начал, – вакансии. В тот момент я еще работал с HR. Пришел к ним и сказал: «Давайте напишем вакансию, чтобы к нам пошли стажеры. Люди, которые раньше не работали в 1С, например выпускники».
У HR была стандартная вакансия. Мы ее вывесили, но никто не откликался. Я пришел и сказал: «Давайте что-то менять. Видите, никто не идет».
Вакансия – это продажа. Она должна чем-то отличаться от других предложений, что-то в ней должно привлекать людей. Нужно понимать своего клиента – этого стажера: что ему интересно и ради чего он должен к тебе идти.
HR сказали: «Хочешь – сам переписывай свою вакансию. Мы ничего переписывать не будем».
У них были стандартные сухие вакансии: изложение требований, ДМС, кофе с печеньками и все остальное.
Я начал экспериментировать с текстами. Эта история продолжается до сих пор. За шесть-семь лет я, наверное, раз десять переписывал вакансию в зависимости от сезона, от того, кто мне нужен и на кого я охочусь.
Самую первую вакансию HeadHunter, правда, забраковал. Она называлась «Будущий программист 1С». Вакансия несколько часов провисела, успела закэшироваться, потом модераторы HeadHunter ее нашли и закрыли со словами: «Так не может называться профессия».
Потом были разные эксперименты. Я пробовал писать о себе: «Приходите стажироваться к Ивану Белокаменцеву. Кто это такой? Спросите у Google. Google знает, кто я такой».
Пробовал размещать вакансии с указанием зарплаты и без нее. Пробовал писать пугающие тексты: «Ты придешь, мы тебя здесь так будем учить, что с тебя семь потов сойдет».
Бывало наоборот: писал, что человека окружат заботой и у него будет персональный наставник. Всякую разную чушь писал. Я знал, что если что-то не получается, надо пробовать сделать по-другому.
В процессе работы с вакансиями я вычислил сезоны жатвы – периоды, когда выпускники начинают искать работу.
Первая волна идет примерно с мая. Те, кто в июле защищает диплом, начинают выходить на рынок уже в мае. Однажды за один май я взял четырех человек. Двое из них уже уволились, а двое выросли в прекрасных программистов. Это были студенты четвертого курса.
Вторая волна начинается после получения диплома – примерно в августе-сентябре. В сентябре люди приходят очень часто.
Третья волна приходится примерно на октябрь-ноябрь. Это те, кто думал, что найдет какую-нибудь классную работу: что их возьмут в СберТех или куда-нибудь писать на Python. Потом они разочаровываются и приходят устраиваться в «Битрикс» или в «1С». Среди таких разочаровавшихся в большом мире программирования тоже выросло много замечательных программистов 1С.
Если подытожить: вакансии нужно переписывать. Нужно писать по-разному, выделяться, и это работает – по крайней мере, у меня. В лучшие периоды за месяц приходило до четырех человек. Причем это даже не просто отклики, а хорошие ребята, уже прошедшие собеседование: выпускники, которые умеют на чем-то программировать, готовы учиться и в итоге остаются.
Отклики вместо холодных звонков
Еще одно расхождение с HR касалось активных прозвонов. Я спросил: «Как вы ищете людей?»
Они ответили: «Мы вывешиваем вакансию, на нее никто не идет. Поэтому ищем резюме, делаем подборку и отправляем руководителю отдела. Он говорит: «Попробуйте затащить вот этих». И HR начинает их прозванивать».
Если сравнивать с продажами, это активные продажи, холодные звонки.
Я понял, что так работать не смогу. Ты сразу оказываешься в слабой позиции: звонишь человеку, причем стажеру, и уговариваешь его прийти к тебе работать. Что за дичь?
Я предложил сделать так, чтобы все кандидаты приходили с откликов. Чтобы у нас были такая зарплата, такая работа и такая атмосфера, что люди сами захотят к нам прийти.
В итоге так и получилось. Во всем моем отделе есть только один человек, которого я позвал сам, – мой старый друг. Все остальные пришли с откликов.
Собеседования
С собеседованиями я тоже проводил довольно много экспериментов.
Когда нанимаешь готового опытного специалиста под конкретные задачи и тебе нужно, чтобы он завтра сел и начал работать, понятно, о чем спрашивать: «У меня такие-то проекты. Это умеешь?» Человек отвечает, что умеет, не умеет или ему нужно немного подучиться. Здесь все понятно.
Но что спрашивать у стажера? Человек выпустился из института, 1С не видел, программировал на чем-то другом.
Первые два года я проводил собеседования сам. Потом отпустил этот процесс, и теперь он уже давно происходит без меня.
Сначала я пробовал действовать так, как обычно рекомендуют: спрашивал человека о жизненных принципах, о том, чего ему хочется, что его мотивирует, и обо всем остальном. В итоге я от этого отказался.
Я начал смотреть на конверсию. Запоминал, что человек говорил на собеседовании, как отвечал на вопросы, какое впечатление о себе создал, а через полгода смотрел, что из него получилось.
И видел: этот человек на собеседовании мне понравился, а результат плохой. А другой на собеседовании три слова связать не мог, но из него получился замечательный программист, который прекрасно разговаривает и вообще стал душой компании.
Потом я наткнулся на книгу Канемана «Думай медленно… решай быстро». Он писал о том, как проводили собеседования то ли в израильских ВВС, то ли еще где-то.
Там пришли к выводу, что спрашивать все это на собеседовании нет никакого смысла. Нужно проверить совсем базовые навыки, а все остальное выяснится только во время испытательного срока.
В итоге я пришел к тому же.
Что мне нужно проверить на входе? Во-первых, я беру людей, у которых есть высшее или среднее ИТ-образование. Это нужно, чтобы не учить человека тому, что такое программирование вообще, цикл, условный оператор и так далее. Это требование сразу написано в вакансии.
Во-вторых, нужно проверить, ходил ли человек с ИТ-образованием на пары. Бывают люди с дипломом, которые никогда не программировали и видели только Excel. Это я проверяю на собеседовании с помощью элементарных задач на программирование.
После этого нужно понять, способен ли человек учиться. Как это сделать?
Сначала я пробовал недельную стажировку. Говорил: «Приходи к нам в офис. Будешь неделю сидеть и изучать 1С на базовом уровне».
Например, можно было прочитать книгу Радченко – старый добрый вводный обзорный курс. Но со временем стало понятно, что людям это очень неудобно. Никто не хочет неделю сидеть в моем офисе и заниматься непонятно чем ради непонятного результата. К тому же Радченко тяжело читать, если человеку не настолько сильно нужно попасть в нашу компанию.
Поэтому я заменил книгу своими видео. Сам записал и выложил на YouTube около 30 коротких роликов. Этот курс называется «Подготовишка 1С».
Человеку, который пришел на собеседование, говорят: «Посмотри эти 30 видео. После этого получишь задачу, решишь ее дома и пришлешь результат. Если все хорошо, придешь еще на один день в офис и при нас порешаешь задачи». Мне нужно понять, способен ли человек учиться и решать задачи.
Те, кому не очень нужно, кто не любит или не хочет учиться, отсеиваются между первым собеседованием и прохождением этого недельного курса. Но большинство людей проходят курс, возвращаются и пробуют устроиться. Подавляющее большинство тех, кто пришел после маленького курса, успешно проходят следующий этап и остаются.
Сейчас я вообще не участвую в этом процессе. Первое собеседование проводит один человек. Он же выдает кандидату ссылку на курс и объясняет, что делать. Потом кандидат приходит, другие люди проверяют, как он решает задачи. И только после этого, если он все прошел, я с ним знакомлюсь.
Теоретическое обучение (оторванное от работы)
После того как программист пришел, его нужно учить.
Когда мы только начинали всю эту историю, человека брали, сажали и говорили: «Учись. Есть подборки материалов, можешь почитать вот это, вот это и вот это. Наверное, тебе поможет».
Конечно, стажеру никто не предлагал пройти какой-нибудь полноценный курс по 1С, потому что он не стал бы этого делать. Поэтому люди сидели и читали интернет.
Что получалось в итоге? Они читали с разной скоростью и читали разное. Один – здесь, другой – там, третий – еще где-нибудь. В результате появлялись три программиста, которые смотрели на одно и то же с разных точек зрения – в зависимости от того, каких авторов прочитали. Это первая проблема.
Вторая заключалась в том, что материалы содержали слишком много лишней для стажера информации. Это нормально. Если автор пишет в интернете материал, например, об управляемых формах, он, конечно, постарается написать все и рассказать обо всем, что в них есть.
Но мне это не нужно, и стажеру это не нужно. Чтобы немного научиться работать с управляемыми формами, стажеру достаточно узнать, что такое элементы, что такое события, как их перетаскивать и как связывать одно с другим. Все остальное он изучит потом.
Несколько месяцев я мучился и никак не мог себя заставить, но в итоге сел и начал сам записывать материалы – короткие, насколько это возможно, и не содержащие лишней, на мой взгляд, информации, которую человек все равно узнает позже.
Я разделил обучение на несколько потоков компетенций. Я выращиваю программистов-универсалов, которые могут решать большинство задач и работать в разных форматах: в проектах, в сопровождении и так далее.
Первый поток – программистские компетенции, то есть все, что связано непосредственно с программированием.
Второй поток я назвал «слесарь». Слесарь – это человек, который занимается сопровождением и решает задачи, связанные с сервисами, обновлениями и всем остальным, что вроде бы не программирование, но и не аналитика. Такой технический специалист. Слесарь, короче.
Потом я добавил «скелет». Скелет – это группа компетенций, связанных с учетом. Не с учетом в конкретной конфигурации, а с учетом вообще.
В моем понимании любой программист-универсал должен примерно знать, как выглядит процесс закупки: что существуют документы «Заказ поставщику», «Поступление товаров» и какой-нибудь приходный ордер. Открыв любую конфигурацию с полноценным учетом, он должен найти в ней эти документы. Он должен понимать, что такое номенклатура, контрагенты, реализация, НДС, оборотно-сальдовая ведомость и так далее. Все это входило в «скелет».
Примерно год назад я добавил еще и компетенции аналитиков. Люди у меня выросли, стали мидлами и сеньорами. Мы дошли до того, что должны самостоятельно выполнять проекты силами своего отдела, но у нас не было ни одного аналитика, который мог бы, например, научить пользователя заводить ресурсную спецификацию.
Поэтому появился отдельный пласт аналитических компетенций. Сейчас примерно половина отдела умеет работать аналитиками, и мы выполняем проекты самостоятельно.
По всем этим потокам компетенций материалы я изготавливал сам.
Еще есть флаеры, лесенки, бусидо, точилки. Это просто названия. Зумерам нужно какое-нибудь название, которое они запомнят и будут гадать, что оно означает.
Например, флаер – это учебная задача, которую я даю человеку, чтобы он что-то изучил.
Почему именно практическая задача? Потому что в реальной работе человек может три года ждать, пока ему попадется задача на конкретную тему, например написать небольшой HTTP-сервис. Он так и не научится писать HTTP-сервисы, если его специально не заставить.
Поэтому я придумываю маленькую задачу и говорю: «Напиши HTTP-сервис».
Когда человек решает задачу, я немного увеличиваю ему часовую ставку. Он начинает больше зарабатывать, потому что подтвердил, что чему-то научился.
Лесенка – это последовательная разработка. Я хочу, чтобы человек полюбил программирование. Многие его не любят и относятся к нему просто как к работе: такая дурацкая работа – сидеть и программировать.
Гипотеза была такой: чтобы человек полюбил программирование, он должен сделать что-то свое, вложить туда душу и развивать это последовательно. Он начинает разработку с нуля, потом что-то добавляет, потом еще что-то и еще.
Это мы назвали лесенкой. Я задаю программисту стартовую задачу, он ее выполняет. Потом я выступаю в роли product owner, владельца продукта, и предлагаю идеи: «Давай здесь добавим вот это. А теперь давай вот это».
У человека внутри что-то начинает загораться, и он продолжает доделывать разработку. За каждый этап я тоже даю ему прибавку к зарплате, чтобы был еще и материальный интерес.
Есть еще бусидо. Я хочу, чтобы каждый программист, например, знал КД2 и имел хотя бы небольшой практический опыт работы с ней, чтобы не боялся.
Для этого существует отдельный класс компетенций. Я говорю: «Вот тебе конкретная задача по КД2».
Она уже не совсем маленькая, не на один час. Человеку может понадобиться целый день, чтобы изучить, что такое КД2, и сделать то, что я попросил. Это называется бусидо.
Примерно год назад, когда мы начали учить аналитиков, дошли до курсов 1С.
Чтобы понять, есть ли от них польза, я, наверное, штук десять купил и прослушал. Продолжаю слушать до сих пор. Пробовал давать их людям, но пока впечатления не очень хорошие.
Честно говоря, мне еще предстоит научиться делать так, чтобы человек действительно чему-то учился с помощью курсов. Предыдущие точечные форматы обучения срабатывали лучше.
Есть еще оплачиваемое изучение. Оно используется, когда я обнаруживаю в компетенциях отдела какую-нибудь дыру.
Например, никто не знает всю УНФ на таком уровне, чтобы поучаствовать в пресейле и рассказать о ней клиенту. Тогда я выбираю человека, который умеет хорошо и быстро что-то изучать, а потом рассказывать, и говорю:
«На тебе деньги, иди изучай. Ты должен разобраться на таком уровне, чтобы разговаривать с клиентом».
Он берет деньги и изучает.
Такой формат тоже существует и очень помогает. Оказывается, за деньги у программистов находится дофига свободного времени, которое они совершенно не против потратить на работу.
Обучение практикой
Предыдущие форматы были связаны с теорией, учебными задачами и изучением отдельных тем. Но больше всего учит практика.
Мне нужно было решить две проблемы.
Первая – проблема специализации во франче. Человек приходит, начинает работать, и у него получается, например, решать задачи в ЗУП или УНФ.
У него сдельная зарплата. Поскольку задачи у него получаются, все менеджеры начинают тащить их именно к нему. Человек хорошо зарабатывает, и после этого его не оттащишь от ЗУП или УНФ. Он на них хорошо зарабатывает, а мне нужно, чтобы он изучал ERP. Но он не хочет.
Вначале эта проблема специализации стояла очень остро. У меня как у руководителя отдела не получалось загружать людей разными задачами.
Например, я начинал заниматься продажами и приносил сопровождение УПП. Но УПП видел только я, потому что давно работаю в сфере 1С.
Вторая проблема – расширение компетенций команды. Если в команде не хватает нужной компетенции, просто так ее не достанешь. Я добываю ее с помощью денег или изучаю сам. Очень многие вещи я сначала осваивал самостоятельно, а потом учил остальных.
Чтобы научить программистов так, как мне нужно, пришлось применять директивные методы.
В обычной ситуации, когда появляется задача или возможность поучаствовать в проекте, я спрашиваю: «Нашим соседям нужен человек на проект. Загрузка такая-то, четыре месяца полный рабочий день. Кто хочет пойти?»
Если кто-то поднял руку – хорошо. А если никто не поднял, что делать? Если отказать коллегам, они больше не придут. А люди, которые сидят у меня, ничему не научатся.
Поэтому приходится не спрашивать, а говорить: «Сережа, ты пойдешь работать на этот проект, потому что мне нужно, чтобы ты научился». И Сережа идет.
Это касается любых задач. Если приходит несрочная задача и я понимаю, что три человека точно могут решить ее быстро, а остальные не умеют, то при наличии возможности отдаю ее тому, кто не только выполнит задачу, но и чему-то научится.
Это хороший метод.
Для стажеров существовал еще один метод – решение через астральное тело. Он очень сильно помогал в первое время, когда у меня вообще были только стажеры.
Стажер – это астральное тело, а я стою у него за спиной и помогаю решать задачу, а клиент об этом ничего не знает.
Стажер подключается к клиенту, принимает задачу, потом кладет трубку и рассказывает ее мне. Мы вместе что-то придумываем и начинаем решать (руками стажера). Затем он звонит клиенту и все докладывает.
У клиента создается впечатление, что с ним работает офигенный программист. У самого программиста поднимается настроение: он заработал деньги и решил задачу.
Со стажерами такое бывало очень часто. Для меня это было просто спасением. Если бы я сам созванивался со всеми клиентами по каждой задаче, выстраивать какие-либо HR-процессы уже не получилось бы.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
