Нелояльный, немотивированный
Сотрудники должны быть лояльными и мотивированными — об этом знают все. Даже люди, далёкие от кадров, такие, как я. Насколько я слышал, существуют методы расчёта лояльности. Надеюсь, что они работают. По крайней мере должны.
Потому что мой опыт говорит об обратном.
И в этом я не одинок. Хотите пример? Вот отрывок из вакансии, которую мы обсуждали в чате программистов пару дней назад.
Ищем уникального разработчика, готового с горящими глазами развивать проекты складской логистики.
По функционалу — проектирование, написание кода, менторство, коллаборация со всеми членами нашей прекрасной команды.
Планы наполеоновские. У нас вы сможете реализовать свой потенциал в полную силу… Ищем человека бесстрашного и амбициозного.
Текст я немного сократил. Вакансия действующая и, если вы, будучи автором, её опознали — не благодарите за обратную связь.
А теперь — комментарии разработчиков.
Если что, тут сарказм
Самое время поругать бизнес в целом и рекрутеров в частности. В конце концов, мы знаем, что бывает по-другому.
В мире десятки торговых компаний, где работают высококлассные программисты. Одна из них — Amazon — изобрела модные сегодня облака.
Сейчас облака не писк моды, но в момент своего создания они были большим прорывом. Поверьте мне, скучающий программист такого не придумает.
Amazon могли остаться банальным «проектом складской логистики», но они что-то такое про себя понимают.
А остальные?
Я, честно, хотел написать конструктивную статью. И до конструктива мы обязательно доберёмся. Но сначала нам важно очертить круг проблем.
Констатируем, что может быть не все, но очень многие IT-компании не знают, как продавать себя программистам. И речь не только о России — эта проблема мировая.
Более того, речь не только о рекрутерах или об эйчаре в целом.
Вот, скажем, как маркетологи Tefal продают свои сковородки? Показывают смеющихся домохозяек.
А как продать софт админу, которому предстоит поддерживать его у заказчика? Показывать смеющегося админа?
Вопрос с подвохом
Горе вам, если вы ответили «да». Админы на такое не ведутся. Это не веяние моды, не тренды последних лет: админы никогда на такое не велись.
Их интересует, как всё это будет работать. Будет ли софт падать? Придётся ли ездить на работу в два часа ночи? Бегать по офису, язык на плечо?
За каждым из этих «красивых» образов стоят технические характеристики. На них админы и смотрят.
Можно гипнотизировать админа «мудростью глаз и особыми жестами рук», но эти замечательные приёмы не работают. Настойчивость, воронки продаж, специальные слова, шаманские бубны, тренинги, скрипты, работа с возражениями, молитвы, ритуалы, карты Таро, заклинания… Ни один из классических методов не действует.
Считается, что бизнес осознал это в середине восьмидесятых. Первопроходцами стали Apple, которые в 1977 году научились продавать Apple II.
Продали миллион штук
Как? Они рассказывали, что внутри у этого компьютера 62 микросхемы, пятидюймовый дисковод и цветной видеоконтроллер. Покупателей-программистов это впечатляло.
Так компания Apple придумала то, что мы сейчас называем техническим пиаром.
Я не строю иллюзий: технический PR — всё равно PR, он работает по тем же законам. Если пиарщик не может сделать буклет для программистов, то и программист не может — он не умеет делать буклеты.
Но вместе они могут.
И рекрутер вместе с программистом могут написать хорошую вакансию.
Гай Кавасаки из Apple никогда не был технарём, тем не менее, сумел наладить связь с разработчиками. В наши дни его называют родоначальником Developer Relations.
Название перекликается с Public Relations (связи с общественностью) или Investor Relations (связи в инвесторами). Действительно, если компании важно общаться с технарями, почему бы ей не завести связи с технарями?
Они вам не деврелы
Тех, кто занимается DevRel, нельзя называть деврелами. Это как специалиста по PR называть пиаром. Десять-пятнадцать лет назад их называли евангелистами, а в наши дни популярным стало само-название — developer advocate.
Advocate означает вовсе не адвокат или защитник — это, скорее, представитель. По-русски, представитель разработчиков звучит громоздко и всё-равно непонятно, поэтому (несмотря на то, что я написал выше), у нас специалистов по DevRel называют именно деврелами, особенно, в неформальной речи. В последнее время появилось слово девадвокат, возможно, оно и станет названием профессии.
Девадвокаты, как считает ChatGPT — друзья программиста. Но не только. Дело в том, что у профессии программиста есть один серьёзных недостаток.
Программиста век недолог
Студент, закончивший ВУЗ в двадцать три года, год работает джуном, потом ещё три-четыре года — мидлом и, наконец, к двадцати семи становится сеньором.
Если у сеньора есть тяга к руководству, к тридцати он идёт в тимлиды и далее — вверх по управленческой линии. Как правило, такой тяги у программистов нет — они чувствуют себя неуютно, заставляя людей работать.
И вот этим программистам — большинству — дальше расти некуда. В индустрии ходят слухи про техлидов, в которых превращаются сеньоры. Техлиды — это тимлиды здорового человека, которые решают сложные технические задачи и никогда не ругают подчинённых. Когда я спросил в нашем чате программистов (800 человек), есть ли у нас техлиды, отозвались два человека. Первый утверждает, что его должность — это маркетинг, а второй — что стечение обстоятельств.
Короче, техлиды — это шляпа
Ситуация усугубляется тем, что в индустрии под тимлидами и техлидами понимают всё, что угодно. Может быть, и вы не согласны с моим определением. Я не настаиваю. Пусть это будут карьерные веточки А (административная) и П (профессиональная).
Ситуация такова, что рост типа А встречается часто, а рост типа П — очень редко.
Программисты мыкаются по зарплатной синусоиде: в тимлиды — за деньгами, обратно в сеньоры — за спокойной жизнью.
Через двадцать лет они становятся пятидесятилетними сеньорами и уже не в силах поспевать за версиями React (я проверил, на момент написания статьи их восемнадцать). Старожилов индустрии перестают брать на работу, и они устраиваются в один из банков, где влачат жалкое профессиональное существование до самой пенсии. Ужасная старость.
Есть ли выход?
В начале статьи мы обсуждали, что рекрутеры не понимают, как писать технические вакансии, и не понимают, что написано в резюме. В то же время программисты иронично относятся даже к вероятности выучить программирование за несколько недель.
Вывод, который кажется очевидным — ни один эйчар никогда ни при каких обстоятельствах не выучит программирование настолько, чтобы составить вменяемую техническую вакансию. Если он не бывший программист, ставший эйчаром — такое редко, но бывает. Либо…
Либо, вменяемую вакансию может написать программист вместе с рекрутером. И тогда он уже не просто программист, он немного и девадвокат.
Вот, собственно и долгожданный конструктив: если качество работы рекрутера и маркетолога зависит от программиста, надо быть тем самым программистом, который им помогает. Тогда и винить будет некого.
Перед программистом открывается новый путь — не А, и не П. Третий путь Д.
Третий путь
Программист не идёт в девадвокаты сразу. Сначала он должен сходить в тимлиды и убедиться, что руководство — это не его. «Возраст тимлида» — где-то тридцать лет, и в этом время он уже опытный профессионал.
В исследовании Хабра об IT-бренде работодателя в списке важнейших черт хорошей компании третьим пунктом идёт профессиональная среда. В переводе на русский: хорошая компания — это место, где много профессионалов, которые помогают своим коллегам.
Программистов, склонных к деврелу, можно опознать именно потому, что они помогают.
Освоив инструмент, такой программист потратит пару вечеров, чтобы описать его в рабочей wiki. Может быть даже воркшоп проведёт.
Для этого программисту не нужны ни рекрутеры, ни эйчары, и ни бизнес в целом.
Разве что участники
Помимо воркшопов в компании можно делать тренинги, хакатоны и код-ретриты. Ретрит — это мероприятие, которое проводят вне рабочего времени, чтобы программист не сидел под Дамокловым мечом задач и сроков. Этот формат работает, если надо освоить что-то непривычное, что-то, что требует перегрузки головы.
Например, работу с иммутабельными данными или с TDD.
Кстати, о TDD
Я работал в разных компаниях и почти всегда с легаси. Тесты у нас сейчас — что-то вроде карго-культа, так что я начитался легаси-тестов на годы вперёд. Барахло — сказочное!
Выше я ссылался на исследования Хабра. Если помните, больше всего соискатели ценят возможность делать качественные продукты. А тесты — хорошие тесты — одна из тех вещей, которые обеспечивают качество. Вместе, например, со статическими анализаторами. Чтобы ваша компания стала лучшим местом работы, можно:
Разобраться с любым хорошим анализатором кода и провести по нему воркшоп, чтобы все научились статическому анализу.
Провести код-ретрит по TDD, чтобы коллеги научились писать хорошие модульные тесты.
Потом можно идти дальше, и начать бороться не только с плохим кодом, но и со скукой.
Борьба со скукой
Если вас достал тимбилдинг, может быть, пора устроить что-нибудь действительно интересное?
Перед новым годом мы здорово провели месяц, решая задачки на Advent of Code. Но AoC это большое мероприятие, не все доходят до конца. Через полгода — 13 сентября — будет день программиста. Подготовьте восемь интересных задач и сделайте программистскую неделю (в ней восемь дней, если вы не знали).
Каждое утро публикуйте одну задачу, собирайте статистику. А в конце недели пригласите участников в бар — похвастаться решениями.
Вот ещё случай из жизни
Был недавно новый год в «одной известной компании». Туда позвали «одного известного КВН-щика». Он привык вести корпоративы для пьяной бухгалтерии, поэтому спасовал перед скромными интровертами. «Наденьте», — говорил КВН-щик, — «вот этот дурацкий костюм». Программисты смотрели на него с недоумением.
В IT-компании корпоратив может быть именно программистским, а не средне-статистическим.
Я бы собрал несколько команд из разных отделов — по два человека — и устроил бы квест. Нашёл бы пять несложных задач, немного запутанных, но таких, чтобы можно было решить за десять минут.
Решил задачу — узнал код, который пригодится на следующем этапе.
Я бы взял внутренний телевизор и показывал бы этот айтиатлон всем коллегам — чтобы болели. Попутно я бы проводил конкурсы с коварными IT-вопросами для тех, кто смотрит.
В конце все команды пришли бы на финиш, где и решали бы финальную задачу.
А подарил бы я им какую-нибудь нердовскую клавиатуру, которая стоит пятнадцать тысяч и очень здорово выглядит.
Сам такую хочу. Денег жалко.
Можно было бы закругляться
Но у нас осталась ещё одна тема, возможно, самая важная.
Речь идёт о помощи не кому то конкретно, а всему IT-сообществу. Вариантов может быть много разных, но в первую очередь я имею в виду open source. Полезно самому участвовать в проектах с открытым кодом. Полезно открывать свои домашние проекты. Полезно делать открытыми свои рабочие проекты. Полезно привлекать коллег к доработке софта, который использует ваша компания.
Порог входа в любые проекты весьма высок, и open source здесь не исключение. На этапе входе новичкам не помешает помощь наставников. Так что научитесь сами и помогите другим.
Просто не будет
На низовом уровне всё можно делать самому. Но хакатон придётся согласовывать с менеджментом, а идеи для IT-корпоратива — с эйчарами. К сожалению, здесь могут возникнуть проблемы.
И я не знаю, как их решать. Всякий раз, когда у меня возникает конфликт с компанией, я ухожу. Возможно, так поступать неправильно, но я не верю, что могу изменить чьи-то взгляды на жизнь.
Кроме того, я всё ещё программист, а не специалист по пиару. Я могу рассказать, что интересно программистам, могу отобрать задачи для конкурса, могу провести воркшоп. Я не умею строить технический бренд.
Просто помогаю, сколько могу. И надеюсь на лучшее.
Заключение
Эта статья не была бы написана, если бы не Московский клуб программистов и не сообщество русскоязычных деврелов. Хочу поблагодарить моего большого друга Марию Жог, сказавшую, что все мои соображения — просто слова, пока я не оформлю их в виде статьи. Большое спасибо Нине Пакшиной, давней соратнице по клубу программистов, которая внимательно вычитала черновик и дала много ценных советов. IT-сообщества существуют благодаря таким людям, как Нина, а клуб программистов — точно благодаря ей.
Светлана Кривенко бульдозером прошлась по тексту, заставив меня переписать почти половину. Мы со Светой проводим ретриты, делаем воркшопы и записываем ролики. А ещё она внимательный и скрупулёзный рецензент, и я даже не знаю, как можно адекватно её отблагодарить.
Надеюсь, мне удалось донести мысль, что уход в тимлиды — не единственный путь для толкового амбициозного сеньора. Взгляните на индустрию свежим взглядом. Может быть, именно благодаря вам мир программирования станет лучшим местом, чем является сейчас.
И — удачи на вашем пути.
