Нелояльный, немотивированный

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

Потому что мой опыт говорит об обратном.

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

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

По функционалу — проектирование, написание кода, менторство, коллаборация со всеми членами нашей прекрасной команды.

Планы наполеоновские. У нас вы сможете реализовать свой потенциал в полную силу… Ищем человека бесстрашного и амбициозного.

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

А теперь —

Если что, тут сарказм

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

В мире десятки торговых компаний, где работают высококлассные программисты. Одна из них — 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-сообщества существуют благодаря таким людям, как Нина, а клуб программистов — точно благодаря ей.

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

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

И — удачи на вашем пути.

UPD: После публикации статьи мне написали сотрудники Хабра, и подсказали, что сейчас идёт неделя нейроарта, а по сути — конкурс картинок, нарисованных Кандинским (последней версией нейросети).

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

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

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