Несколько месяцев назад познакомился с СТО одной небольшой, но известной на рынке ИТ-компании. Очень классно пообщались, но когда коснулись темы мотивации сотрудников, он несколько раз вскользь упоминал модель В. И. Герчикова — мол, и он своих инженеров по ней оценивает, и HR у них вовсю эту модель используют.

Но что-то во мне тогда вызвало противоречие, и всё это время я ходил и думал — а почему я, любитель всяких моделей и подходов, не взял её на вооружение, когда узнал про неё лет 15 назад? И почему больше-то нигде особо в своей ИТ-карьере я и не встречал людей, которые бы её активно применяли?

Давайте, для начала, вспомним, что это за модель такая.

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

Какие же это 5 типов?

👉 Инструментальный тип — для него деньги — это единственный мотиватор. За деньги готов работать дольше, сильнее, больше и даже по выходным. Переработку не оплатят? Тогда и ему нет смысла работать.

👉 Профессиональный тип — деньги не так важны, если есть возможность поработать над сложным и уникальным проектом и вырасти профессионально. Незаметно для себя будет копать вглубь и овертаймить, но сделает всё качественно, хоть и не всегда в срок.

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

👉 Хозяйский тип — вокруг своей зоны ответственности построит забор, будет наводить у себя порядок и никого пускать не будет. Лучшая мотивация для него — свобода, но такими ребятами сложно руководить.

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

И вот недавно наткнулся на статью про то, как Герчиков разрабатывал эту модель — и меня осенило! Я понял, в чём у меня тогда было противоречие.

Владимир Исакович 7 лет проработал на сталелитейном заводе «Сиблитмаш» в Новосибирске в 60-х годах прошлого столетия. И всё это время он неформально общался с простыми рабочими, и даже клуб книголюбов на заводе организовал. И вот его наблюдения за отношением рабочих к трудовой деятельности на заводе и легли в основу этой модели.

Уловил уже мысль, да? 60-е годы, Советский Союз времён Брежнева, завод, рабочие... Я вполне могу представить себе патриотичную 👩‍🏭 Дарью, которая с мыслями «Партия сказала — надо! Комсомол ответил — есть!» нарисовала стенгазету о том, что её завод — лучший в регионе по выработке норм часов, или же люмпена 🫠 Колю, который палец о палец не ударит, если ему не вставят пистон.

Но когда я начинаю транслировать модель Герчикова на инженеров, мне часто просто не хватает типов. А притягивать за уши сотрудника к какому-то ближайшему типу и мотивировать его, исходя из этого — может сказаться на ментальном здоровье сотрудника не лучшим образом.

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

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

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

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

Можешь пройти тест Герчикова, чтобы убедиться, что ты не люмпен. А тем временем, нас уже 300+ 🚀

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

Думая, как же можно расширить воронку, ко мне в голову приходит идея, с которой я иду к рекрутеру и говорю — «Собери все профильные конференции и спикеров на них, пробегись по должностям, и тех, кто нам подходит, найди в LinkedIn и сразу предлагай им собес со мной».

И вместо «Хорошо, принято» я услышал — «Хорошо, только можешь накидать мне список сайтов конференций, с которых ты бы хотел, чтобы я посмотрела спикеров?».

Вот что тут произошло? Да чистой воды манипуляция! 😠 Я, как заказчик, пришёл поставить задачу рекрутеру, а вместо этого сам получил от неё задачу.

Или из свежего. Приходит ко мне руководитель разработки и говорит — «Ругаемся со смежным отделом, не можем договориться». Ну, думаю, раз эскалирует — значит, действительно требуется моя помощь. Погружаюсь туда — а там просто нужно собрать ожидания с двух сторон, зафиксировать их в документе, принять обеим сторонам и следовать. Руководитель же со своей стороны не сделал ничего, а сразу пришёл ко мне, чтобы я решил его проблему 😢

В обоих этих кейсах общее — сброс ответственности. Или, как пишут Уильям Онкен и Дональд Уосс в статье «Management Time: Who’s Got the Monkey?», опубликованной в 1974 году в Harvard Business Review, — произошла «передача обезьяны».

🐒 «Управленческая обезьяна» — это проблема или задача, которой кто-то должен заниматься.

И во втором случае, когда руководитель разработки услышал от меня: «ОК, я разберусь», — он пересадил свою обезьяну со своих плеч на мои. Конечно же, у меня полно своих дел, и я не бросил всё и не побежал разбираться, что там происходит между отделами. Но знаете, что сделал руководитель разработки через пару дней? Он начал «кормить» свою обезьяну, написав мне: «Подскажи, когда тебе удастся решить наш конфликт?».

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

Что делать, шеф?

👉 Научись понимать, когда на тебя хотят посадить чью-то обезьяну

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

👉 Если чужая обезьяна уже на тебе — верни её владельцу

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

👉 Отбивай желание вешать на тебя чужих обезьян

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

👉 Корми или пристрели обезьяну

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

❓ А сколько чужих обезьян сейчас на тебе?

Планирование Q3, Performance Review, стратегическая сессия — и меня знатно выкинуло из жизни на пару недель 😫 Заметка сама себя не напишет, поэтому надо наверстывать упущенное.

Лето, а значит, вы, как и я, погружены в процесс Performance Review — кто-то только начал собирать обратную связь по сотрудникам, а кто-то уже даже прошёл процесс калибровок. А дальше — дача обратной связи сотрудникам.

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

💡 Самое главное в фидбеке в рамках Performance Review — он должен быть предсказуемым для сотрудника.

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

И хорошо, если Серёжа сам понимает, что это были не лучшие его полгода и готов услышать твой негативный фидбек. А представь, что нет 🥲 Серёжа как ни в чём не бывало ждёт повышения, премии, бонуса — а тут ты такой красивый со своим негативным фидбеком. Расклад мы знаем: демотивация Серёжи, конфликт и увольнение.

В общем, разобрались: дача негативного фидбека в рамках Performance Review — это не про расправу и не про охоту за головами. Так про что это?

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

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

Чтобы фидбек выглядел убедительным и аргументированным, к нему нужно хорошо подготовиться:

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

И на самой встрече:

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

И уже после того, как вы всё обсудили и сотрудник понял твои искренние намерения помочь ему в развитии — составьте план развития. Это должен быть конкретный список того, что сотрудник должен изменить или улучшить в своей работе до следующего Performance Review.

❓ А ты сам когда-нибудь получал негативный фидбек в рамках Performance Review?

Как-то мне в наследство перешёл в подчинение лид, и вот этот лид взял себе нового Golang-разработчика и на каждом 1:1 начал жаловаться мне на него: мол, перформанс низкий, слабо обучаем, тяжело управляем. Когда я спросил, какой же план по развитию этого сотрудника, мне лид сказал, что вообще не готов заниматься им. И на мой вопрос — А, собственно, зачем ты вообще тогда брал его на работу? — я получил очень удивительный ответ: А я и не хотел его брать, меня рекрутер заставил. Занавес.

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

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

Рекрутер 90% своего времени работает вне компании — он общается с холодными кандидатами и пытается всеми правдами и неправдами дотащить их до первого этапа собеса: где-то уговаривает, где-то давит, где-то продаёт. Как бы ни действовал рекрутер — его подходы работают, кандидаты на собесы идут, и KPI закрывается. И если уж кандидата удалось затащить на собес, то нет повода бросать проделанную работу на полпути — теперь надо кандидата тащить дальше до оффера и вывода на работу. И дело даже не в KPI, рекрутмент — это про достижение результатов.

И супернаивно полагать, что, переключаясь с холодных кандидатов вне компании на нанимающих менеджеров внутри компании, рекрутер может моментально переобуться и поменять паттерн общения — это суперсложно, и так могут далеко не все. Поэтому вполне себе логична такая профдеформация, когда рекрутеры и к нанимающим менеджерам начинают применять свои методы «продажи» кандидатов.

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

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

И вот тут уже говорить, что «человека мне навязали и я не хотел его брать» — это суперневзрослая и нездоровая позиция. Скорее всего, из-за отсутствия внимания и поддержки лида, увольнение сотрудника на испытательном сроке будет непростым и компания снова откроет поиск. И мы имеем то, что из-за незрелости лида мы получаем репутационные риски для компании и потерю времени и денег.

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

❓ А на тебя давили рекрутеры?

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

Мы же с тобой хотим быть хорошими лидами 😎, поэтому давай попробуем сначала разобраться, что там по финансовым метрикам, и сегодня копнём в различие между Revenue и GMV.

💡 Важно! Для простоты расчётов в примерах я сознательно опускаю НДС. Но имей в виду: если товар продаётся за 1200₽ с 20% НДС, то в Cash Flow отражается вся сумма — 1200₽, а в P&L — только 1000₽, без НДС.

Любая компания либо продаёт товары, либо оказывает услуги. Представь, наша компания произвела и продала за месяц 100 холодильников по 1000 рублей. За 80 холодильников наши клиенты заплатили сразу, а за 20 — оплата пока задерживается.

Итого имеем:

👉 Выручка (Revenue): 100 × 1000₽ = 100 000₽ — это сумма всех продаж, независимо от того, оплатили их или нет.

👉 Входящий денежный поток (Cash In): (100 − 20) × 1000₽ = 80 000₽ — это поступление реальных денег в компанию.

👉 Дебиторская задолженность: 20 × 1000₽ = 20 000₽ — это деньги, которые покупатели уже должны, но ещё не заплатили.

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

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

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

Впрочем, не все компании продают товары или оказывают услуги собственного производства. Маркетплейсы — такие как Ozon, Wildberries или Авито — продают не свои товары. Агрегаторы, такие как Яндекс.Такси, Профи.ру или Травелата, — не свои услуги. В таких компаниях выручка — это не объём проданных товаров и услуг, а лишь комиссия (процент) с этих продаж.

Тем не менее, чтобы продемонстрировать масштаб бизнеса, маркетплейсы и агрегаторы часто акцентируют внимание на метрике GMV (Gross Merchandise Value) — это общая стоимость всех товаров и услуг, проданных через площадку.

Чтобы стимулировать продажи, маркетплейсы и агрегаторы раздают покупателям кэшбэки, промокоды, скидки и другие плюшки, например бесплатную доставку или же второй товар в подарок. Всё это называется CI (Customer Incentives). Самое забавное, что CI снижает стоимость товара для клиента, но в расчёт GMV всё равно попадает полная цена товара. Более того, GMV не учитывает возвраты товаров, а ещё включает в себя НДС 🙈

Представь, что мы — маркетплейс. За месяц через нашу площадку продали 1000 товаров по цене 1000₽ каждый. Всем покупателям мы раздали скидку в 10%, поэтому фактически они заплатили по 900₽ за товар. Таким образом, все клиенты заплатили: 1000 × 900₽ = 900 000₽

Однако 10% товаров оказались бракованными, и мы вернули деньги клиентам за 100 единиц. Следовательно, чистые денежные поступления после возвратов составили: 900 000₽ − (100 × 900₽) = 810 000₽

А теперь внимание, вопрос: сколько мы зачтём себе GMV? Правильно — 1 000 000₽ 🙈

Как ты уже понял, GMV — это просто красивая метрика, которая показывает товарооборот на площадке, но по ней никак нельзя понять, как в целом у компании идут дела. Часто бывает даже так, что площадка раздаёт сумасшедшие скидки клиентам: GMV летит в космос 🚀 а вот выручка — отрицательная 😢 Как в том анекдоте, когда мужик продавал рубль за 99 копеек: прибыли нет, но оборот бешеный.

❓ А сколько GMV в месяц делает твоя компания?

Дорогой друг, поделюсь с тобой своими переживаниями.

Так уж сложилось, что к вещам, которые я делаю, я отношусь основательно: планирую, реализую, вычитываю, выверяю и проверяю — это моя сильная сторона. Она же и слабая 😢 Там, где нужно на хромой козе въехать в дом из соломы и навоза — я не сильно подхожу. Сначала козу подлечу, потом дом укреплю, и только потом поеду. Результат, конечно, выше ожиданий, а если ещё и проект взлетит — его к тому же потом легче и проще поддерживать. Но если не взлетит, то спрашивается: зачем на всё это тратилось столько усилий, если можно было бы и без них?

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

И за последние два месяца ко мне несколько раз прилетал фидбек: «Тёма, у тебя лонгриды. Сокращай — тяжело читать!».

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

И вот пару дней назад в чатике с бывшими коллегами снова прилетел фидбек про лонгриды. А другой мой коллега ответил: «Не, норм, я читал по паре постов в неделю последний месяц — ощущение, как будто прочитал добротную книгу про пипл-менеджмент».

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

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

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

А ещё такие лонгриды мешают мне органически привлекать аудиторию 😢, ведь мало кто будет репостить такие большие посты — я это осознаю и принимаю. И вижу, что среди моей аудитории много блогеров с супер интересными каналами и близкой мне аудиторией — я буду рад, если ты просто где-то отметишь меня и расскажешь про мой бложик — это бесконечный источник кармы и моей благодарности 🥰

На этом с моими переживаниями всё — дальше расскажу, как я изобретал унифицированную систему оценки задач для кросс-команд 🙂

P.S. На фотографии — я во дворце Гугун в Пекине.

Пять лет назад я руководил отделом из 60+ человек, который отвечал за разработку мобильного клиентского приложения Ситимобил. В отдел входило 6 кросс-функциональных продуктовых команд разработки, где работали мобильные и бэкенд-разработчики, а также тестировщики — до 10 человек в каждой команде.

Одной из моих постоянных задач было формирование новых команд разработки и расформирование старых. И я заметил, что каждый раз команды тратили много времени на то, чтобы адаптировать процесс разработки под себя. Часто они выбирали story points для оценки задач — и только где-то к пятому спринту успевал накопиться нужный объём задач, относительно которых можно было начать калибровать эти story points. Пять спринтов у мобильной команды — это 10 недель, или 2,5 месяца 🫠! И это ещё не считая того, что спустя какое-то время командам всё равно приходилось пересматривать эти «эталонные» задачи, чтобы оценки оставались актуальными.

Мы находились в фазе быстрого роста и не могли себе позволить тратить по 3 месяца на стабилизацию новой команды. Плюс была ещё одна проблема — story points разных команд не совпадали. А у нас частенько делались большие задачи на 2 и более команды — и продуктовые менеджеры просто не могли друг друга понять. Один менеджер говорил: «Эта задачка на 5 story points», — а другой менеджер не понимал, о чём речь, потому что у него в команде «5 story points» — это вообще про другое.

И мы поняли, что нам нужна другая система оценки — такая, которая была бы:
👉 понятна всем (как time-based подход),
👉 одинаковой для всех команд,
👉 простой во внедрении и не требующей постоянного обслуживания, как story points,
👉 и при этом — не скатывалась в абсолютную time-based точность, вроде «3 дня и 2.5 часа».

Мы нашли компромисс между гибкостью story points, которые позволяют оценивать сложность задачи, и time-based подходом, который фокусируется на времени выполнения. Так у нас и появилась абстрактная единица оценки — CityPoint (далее просто CP). Она аналогична часам, но при этом в оценке задач можно использовать только фиксированные значения: 1, 2, 4, 8 и 16.

Где:
👉 1 CP (~30 мин) — совсем мелочь, типа «сбегать за кофе» или «подвинуть компонентик на пиксель»
👉 2 CP (до 2 часов) — что-то несложное, типа «запилить формочку» или «накинуть фантик к анимашке»
👉 4 CP (до 4 часов) — нормальная задача, можно две такие за день закрыть
👉 8 CP (до 1 дня) — существенная задача, займёт весь рабочий день
👉 16 CP (до 2 дней) — крупная задачка, один день точно уйдёт, и второй зацепит

Итого,
👉 точная оценка тут не обязательна. Если есть уверенность, что задача займёт примерно 3 часа — нет нужды дробить её на подзадачи по 1 и 2 CP. Гораздо логичнее дать ей сразу 4 CP и спокойно в неё уложиться.
👉 даже если задача совсем мелкая — она всё равно должна получить оценку в 1 CP. Нет смысла объединять кучу мелких задач в одну и ставить ей какую-то общую оценку, или, наоборот, пытаться присвоить 0 супер-маленьким задачам.
👉 CityPoint задаёт и верхнюю границу тоже. Если кажется, что задача займёт около трёх дней — значит, её нужно декомпозировать на несколько задач. Максимальная оценка одной задачи — 16 CP.

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

❓А в чём ты оцениваешь задачи в своей команде? Если хоть в чём-то оцениваешь — поставь реакцию под постом. Хотя если не оцениваешь — тоже поставь реакцию 🙈

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

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

Логика там была абсолютно простой. Бюджет на senior-ставку был 350 000 рублей gross (и такие вилки когда-то были), и он был абсолютно уверен, что, наняв двух джунов до 150 000 рублей gross, он даже сэкономит 50 000 рублей компании с каждой senior-ставки, за что будет большим молодцом.

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

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

Через год случился performance review, и HR пришли с бюджетом на повышения. Изначально, для этих двух senior-ставок было забюджетировано повышение в 60 000 gross рублей на обе ставки суммарно, а вот джуны, которые херячили весь год, за год выросли и хотели повышения должности и повышения зарплаты — минимум +60 000 рублей gross каждый. И всё справедливо — выйдя на рынок, их точно бы уже оценили в middle и дали бы те самые 210 000 рублей gross.

Математика проста 🧮 Даже если взять экономию в 50 000 рублей с каждой senior-ставки и сложить с бюджетом на повышения в 60 000 рублей — это будет 160 000 рублей. Это меньше ожидаемых повышений, которые ожидают наши джуны — 240 000 рублей gross. И становится совершенно непонятно, откуда брать остальные 80 000 рублей gross. Повысить всем по чуть-чуть? Кому-то повысить, а кому-то не повысить? — все эти подходы ведут к нашей с вами любимой тройке развития событий: демотивации, конфликту и увольнению.

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

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

И это не говоря про то, что на одного сотрудника в бюджете закладывается ещё один ДМС, один комплект корпоративной техники (ноутбук, монитор, а иногда ещё и телефон), одно рабочее место в офисе, один пакет корп. лицензий и ещё много чего интересного… — и разбивание одной ставки на две бьёт по разным статьям бюджета компании 😢

❓ А ты готов рискнуть и сплитить ставку? Поддержи автора — поставь реакцию под постом.

Бывали ли у тебя такие ситуации, когда прямо на собеседовании хочется дать кандидату отказ? Ну прям очень хочется, но ты почему-то себя останавливаешь и говоришь: «Спасибо за общение, рекрутер вернётся с фидбеком».

И тут возникает вопрос — а можно ли вообще прямо на собеседовании давать отказ?

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

☝️ Это не запрещено политикой HR

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

✌️ Ты — нанимающий менеджер этой позиции

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

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

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

Например:

👉 Ты ищешь senior-разработчика, дал кандидату первую задачку — он её завалил, дал вторую — тоже завалил, и сам это понимает. Тут можно сказать: «Вижу, что у тебя хорошая база, но её всё же недостаточно для уровня позиции, которую я сейчас рассматриваю. Подкачайся и приходи к нам снова через полгодика».

👉 Ты ищешь QA-автоматизатора, который построит автотестирование с нуля, а кандидат — мануальный тестировщик, который немного писал автотесты по готовому шаблону, но красиво подал это в резюме. Тут тоже можно сказать: «Дружище, мне понравилось, как мы прошли теоретическую секцию, но сейчас мне нужен человек, который за пару месяцев выведет нас на высокий уровень автотестирования и принесёт лучшие практики с рынка. Боюсь, твоего опыта для этого будет недостаточно».

Или обратная ситуация:

👉 У тебя бюджет на уверенного middle, а пришёл матёрый senior. Можно честно сказать: «Ты супер классный, мне нравится, как ты решил все мои задачки, но для текущей позиции ты overqualified. Как только у меня откроется позиция твоего уровня, я сразу же попрошу рекрутера с тобой связаться».

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

Если же причина отказа абстрактна:

👉 тебе показалось, что кандидат был резковат и груб
👉 он опоздал на собеседование, а для тебя это «редфлаг» и ты уже раздражён
👉 тебе кажется, что кандидат культурно не подойдёт в команду (вы все болеете за «Спартак», а он — за «Динамо»)

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

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

Я подготовил 4 каверзных кейса, уверен, Катя принесёт чего-нибудь даже похлеще 🙃

Прожарка состоится 19 августа в рамках Tg-конференции 🎙 Рупор лида 3: Lead в поиске.

А вот сама конференция стартует 18 августа и продлится аж до 22 августа, и все 5 дней много разных интересных спикеров будут говорить про найм глазами нанимающих менеджеров, а именно:

👉 18-ое августа, Татьяна Гороховская — Hiring-позиция: в огне, но с чек-листом
👉 19-ое августа, Тёма Пулявин (это я) + Катя Лысенко — Коньки-горбунки собеседований или отсобеседуй меня полностью
👉 20-ое августа, Круглый стол — Что я узнал про найм за 1.5 года: битва AI, выгорание, кризис рынка ИТ
👉 21-ое августа, Саша Поломодов — System design глазами нанимающего
👉 22-ое августа, Иван Доронин — Если ты Lead, который ищет работу

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

Подключайся, точно будет жарко 🔥

Тебе, как лиду, важно строить рабочие отношения со своим руководителем, основанные на доверии. Чем выше уровень доверия, тем меньше со стороны руководителя контроля, и тем больше у тебя свободы и автономности в принятии решений.

Доверие нужно заслужить, и обычно оно появляется через закрытые качественно и в срок проекты.

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

Тебе нужна «маленькая победа» 🏆

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

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

И вот твоя задача — найти такую проблему, которая:
👉 действительно заметна и болезненна для руководителя
👉 решается быстро
👉 даёт чёткий, осязаемый результат

И решить её 💪

Это и будет твоя «маленькая победа» — закрытый в короткие сроки проектик, которого от тебя не ожидали, но который давно «болел» у руководителя. Этой маленькой победой ты покажешь, что он сделал правильный выбор, наняв тебя, что ты умеешь решать проблемы и что уровень доверия к тебе можно повышать.

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

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

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

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

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

Я тут напросился к Саше Поломодову на подкаст.

Если кто не знает Сашу — прямо сейчас рекомендую вбить в YouTube «Поломодов» и наслаждаться бесконечным количеством роликов про то, как Саша рассказывает, как проводить и как проходить секции system design интервью.

С Сашей я познакомился пару лет назад на выезде CPO&CTO-клуба Avito в Бодруме (мы, кстати, на фото оттуда), и до сих пор не перестаю восхищаться его продуктивностью и энергией.

Поговорили очень лампово про мой карьерный трек, как я запускал биржу контента 15 лет назад и сделал своё казино с крестиками-ноликами 🙈

В такую серую дождливую летнюю погоду самое то — укутаться в плед, взять чай с лимоном и 2,5 часа послушать подкаст.

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

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

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

И вот третий такой кандидат и побудил меня написать эту заметку. Он — крепкий технарь, но точно не руководитель. И я ему задаю вопрос: «Слушай, а если вместо руководящей позиции мы тебе предложим инженерную, ты согласишься?». Тут он сразу приободрился, одобрительно начал кивать головой и подчеркнул: «Это будет даже лучше!». Я ему начал объяснять, что в этом случае мы будем оценивать его как инженера, и есть немаленькая вероятность, что именно столько, сколько он хочет, мы предложить не сможем, и спросил – готов ли он двигаться по своим ожиданиям. Тут я получил категоричный отказ, мол, он уже привык к такому уровню заработка и меньше получать никак не хочет.

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

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

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

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

Я в своих наблюдениях не одинок — всё, о чём я тут пишу, было подмечено канадским исследователем Лоуренсом Дж. Питером ещё в 1969 году в книге «The Peter Principle: Why Things Always Go Wrong».

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

Что делать, шеф?

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

И если ты понимаешь, что это не твоё — не страшно сделать шаг назад, чтобы потом сделать два шага вперёд 😎

Я в ИТ лет 20, 15 из которых ежедневно писал код, 10 из них — на PHP.

Последние лет 5 про PHP я ничего не слышал — в Ситимобил мы ушли на Golang, а в Ситидрайв PHP никогда и не было — JavaScript/TypeScript, переходящий в Golang.

А оказывается, мало того что PHP живее всех живых 🔥, так ещё и в самом расцвете сил!

И даже ребята запускают интересные конференции про PHP, а именно — Пых.конф’25, про которую меня попросил рассказать Пётр Мязин. Из уважения к PHP-сообществу и Петру не могу не рассказать!

С Петром мы знакомы довольно-таки давно, и я даже в 2018 году на его подкасте «Пятиминутка PHP» рассказывал про JWT (рекомендую послушать 🔉).

Так вот, Пых.конф’25!

19 сентября, Москва, Конгресс-центр ЦМТ (+ он-лайн).

👉 Асинхронность и протоколы для неблокирующего I/O
👉 RAG в PHP-бэкендах и круглый стол «Кодим с ИИ»
👉 И... аж олдскулы свело: Yii3, Doctrine, Swoole, WordPress и Битрикс!

Билеты можно купить вот по этой ссылке.

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

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

Итак, кейс 💼

Ты вышел на работу лидом команды.

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

Твои действия?

Что делать, шеф?

Во-первых ☝️, уточни у руководителя, по каким метрикам и критериям он оценивает «низкую» и «высокую» скорость команды

И тут могут быть две развилки:

👉 Субъективное восприятие: руководитель оторван от контекста работы этой команды, не погружён в её детали, и его оценка скорости субъективна — базируется на прошлом опыте, который не релевантен этой команде.

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

Во-вторых ✌️, выслушай руководителя и возьми время на собственный анализ (около недели). Погрузись в команду и проведи аудит текущего состояния

Тут важно понять:

👉 Есть ли у команды метрики и показатели (velocity, capacity, throughput, cycle time, lead time)?
👉 Как команда оценивает задачи? Насколько точны оценки: не завышены ли, не занижены ли?

В-третьих 🤟, накидай гипотезы улучшений и изменений

👉 Если метрик нет — надо их внедрить
👉 Если у команды постоянное переключение между задачами — переработай систему приоритизации
👉 Если слабое описание задач заставляет команду много коммуницировать — проработай шаблон задач
👉 ... в конце концов, может быть там CI/CD, выполнение которого нужно ждать 2 дня

Все гипотезы надо поделить на 3 категории целей:

👉 Краткосрочные — можно сделать здесь и сейчас с минимальными ресурсами и силами, но при этом сразу получить значимый результат

👉 Среднесрочные — план на пару месяцев: внедрить какой-то процесс, посмотреть на ротацию сотрудников, переработать систему оценки и планирования

👉 Долгосрочные — план на 3+ месяцев: пересмотреть зоны ответственности команд, устранить технический долг, изменить управленческие подходы и культурные практики

В-четвёртых 🖖, презентуй план руководителю

Он что-то добавит, что-то уберёт — главное получить от него ОК на твой план.

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

Если руководитель всё равно не верит в метрики и считает, что то, что команда делает за 2 недели, можно сделать за час — нужно работать с восприятием руководителя. Прям садиться и «на пальцах» объяснять, почему та или иная задача занимает столько времени. Тут важно построить с ним доверительные отношения, потому что если он раньше не доверял команде, то и тебе самому легко попасть в его недоверие.

В-пятых 🖐, реализуй план в жизнь

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

Это очень кратко и тезисно — как бы я сам хотел услышать ответ на такой вопрос на собеседовании. А как ответила на него Катя — смотри и слушай в записи.

Как-то, работая в «Ситимобил», я проходил тренинг по Ситуационному лидерству (SLII®), и вот этот тренинг я до сих пор считаю лучшим, что проходил. Не столько из-за подачи и организации тренинга, хотя и это было на высшем уровне, сколько из-за самой концепции — она тогда соединила разрозненные кусочки знаний о развитии сотрудников и делегировании задач у меня в голове в единую картину и дала готовый инструмент, который можно было применять сразу после тренинга.

Тренинг базировался на модели ситуационного лидерства, которую разработали американские исследователи поведения Paul Hersey и Kenneth Blanchard и описали в своей книге «Management of Organizational Behavior» аж в 1969 году, и сейчас у неё уже десять переизданий!

В чём идея?

Идея в том, что любой человек, который переходит на новую должность, берётся за новый проект или открывает для себя новую область, неминуемо проходит через четыре уровня зрелости (Maturity Levels).

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

☝️ M1: Новичок-энтузиаст (не может, но хочет)

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

✌️ M2: Разочаровавшийся ученик (не может и не хочет)

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

🤟 M3: Способный, но осторожный исполнитель (может, но не хочет)

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

🖖 M4: Самостоятельный профессионал (хочет и может)

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

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

Каждому уровню зрелости — свой стиль руководства.

☝️ S1 для M1. Указывающий

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

✌️ S2 для M2. Наставнический

Ты объясняешь сотруднику, почему необходимо выбрать именно этот инструмент и начать его допиливать. Слушаешь его идеи и предложения по допиливанию, обсуждаешь их. Свои идеи и предложения не навязываешь, а «продаёшь».

🤟 S3 для M3. Поддерживающий

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

🖖 S4 для M4. Делегирующий

Ты сосредоточен на стратегии развитии платформы и подключаешь сотрудника к её реализации. Определяешь сроки, скоуп и точки контроля. Согласовываешь план — дальше он сам решает, как его выполнить. У него есть все права, полномочия и ответственность для реализации.

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

❗️ Но помни, не все сотрудники могут пройти все четыре уровня — кто-то застрянет на промежуточных.

Фаря Рословец позвала меня на стрим 🍿

Будем говорить про масштабирование инженерных команд, выстраивание процессов и развитие инженерной культуры. Я расскажу на примере Citydrive, как за 3 года отмасштабировал ИТ-команду в 5 раз.

Встречаемся 4 сентября (завтра!) в 19:00 по Москве.

👉 Зарегистрироваться на стрим

Только ленивый ещё не высказал свой прогноз о том, как AI изменит рынок разработки программного обеспечения. Эксперты рынка звучат так же убедительно, как и финансовые эксперты в 2014 году, которые уверяли нас, что рубль укрепляется и не надо покупать доллары… а потом случился «чёрный вторник», и доллар с 30 рублей за штуку взлетел до 80.

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

Но всё ещё я слышу другое утверждение — «middle и junior разработчики скоро будут не нужны, останутся только senior’ы». И вот, мне оно тоже кажется неубедительным. Давайте объясню почему.

Понятие senior неоднородно. Того, кого считают супер-крутым senior’ом в условной веб-студии, в большинстве случаев не возьмут даже на позицию junior в FAANG.

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

А почему? Да потому что ему это и не нужно! У него нет таких задач. Всё, что требуется, так это быстро «на коленке» наклепать интернет-магазин или сайт-визитку для клиента и выложить это в прод. Ни миллионной аудитории, ни задачи коммивояжёра там не будет.

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

Senior Prompt-Engineer’ами не рождаются — ими становятся.

И поэтому будут и senior и даже junior промпт-инженеры в веб-студиях, и junior и middle промпт-инженеры в средних компаниях. Все они будут расти, развиваться, создавая нормальное распределение уровней должностей промпт-инженеров.

Но поживём — увидим 😎

Как-то один из моих лидов несколько месяцев не мог закрыть позицию в свою команду. И не то чтобы позиция была какая-то особенная — рядовой Golang-разработчик. Да и с рынком тогда всё было нормально — собеседования шли регулярно. Но каждый раз у него было «что-то не то»: то кандидат не до конца знаком с нашим стеком, то глубины знаний Golang не хватало, то где-то по софтам недотянул.

Месяцы шли, задачки копились, а мы всё искали идеального кандидата... 🫠

Как-то я читал про концепцию руководителей типа А и B:
👉 Руководитель типа А — это лидер, который не боится конкуренции и нанимает людей не слабее, а иногда даже сильнее себя
👉 Руководитель типа B — напротив, опасается нелояльных сотрудников, поэтому предпочитает брать людей слабее, чтобы сохранить контроль

Есть даже целая теория о том, что руководитель типа А собирает вокруг себя команду А-игроков, а руководитель типа B — команду С-игроков.

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

Но идеальных кандидатов (может быть, даже к счастью) не существует. Каждая позиция уникальна, каждая команда со своими особенностями, и всегда найдётся то, чего кандидату будет не хватать для «идеального» соответствия.

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

Вот три вопроса, которые я задаю себе после каждого собеседования:

☝️ Чего именно кандидату не хватает, чтобы быть максимально подходящим для этой позиции?

Это могут быть конкретные технологии, практики и подходы. Или, например, умение обосновывать и отстаивать свою позицию, «продавать» решение команде, справляться с задачами в условиях неопределённости.

✌️ Смогу ли я научить этому кандидата?

Готов ли я инвестировать своё время и силы в его развитие? Будет ли у меня достаточно ресурсов? Смогу ли подключить к этому кого-то из команды?

🤟 Готов ли сам кандидат учиться и расти?

Насколько он открыт к развитию и получению новых знаний? Не будет ли он упираться и цепляться за старые подходы и навыки?

Моя задача за время собеседования собрать ответы на все эти вопросы. И если есть мэтч — даже если кандидат далеко не идеален для позиции — это даёт возможность рискнуть и попробовать взять его в команду.

❗️ Тут важно понимать, что сильные команды рождаются не из идеальных кандидатов, а из умения руководителя видеть потенциал и развивать людей.

Пару недель назад я рассказывал Фаре Рословец про работу каршеринга. Мы обсудили устройство блоков телеметрии, инциденты с прямыми и косвенными убытками, но больше всего Фарю заинтересовала тема масштабирования команд.

Я пришёл в Ситидрайв в апреле 2022 года. Тогда ИТ-департамент насчитывал около 30 человек, из которых примерно 12 были в одной большой команде NodeJs-разработчиков во главе с лидом.

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

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

Функциональные команды

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

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

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

Направления разработки

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

Например:
👉 команда бэк-офиса разделилась на две: одна отвечала за админки и внутренние сервисы, вторая — за системы управления парком
👉 появилась команда по процессингу заказов
👉 выделился домен пользователя (регистрация, рейтинги, риск-профили), вокруг которого мы начали собирать команду из Golang-разработчиков

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

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

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

Кросс-функциональные команды

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

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

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

Команды отвечают за:
👉 маркетинговые инициативы
👉 финансы и оплаты
👉 пользовательский опыт во время аренды
👉 регистрацию клиентов и допуск в сервис
👉 веб-версию

Такой путь — типичная эволюция для продуктовых команд разработки. Про всё это можно послушать в записи нашей трансляции на YouTube, RuTube и VK видео.

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

И вдруг — бац 💥! Тебе пишет разработчик: «Привет, я хочу уволиться».

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

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

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

Что делать, шеф?

☝️ Спрогнозируй риски

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

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

✌️ Дай оттоку оттечь

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

Говори ребятам спасибо за прошлые заслуги и спокойно отпускай их покорять новые горизонты.

🤟 Коммуницируй внутри команды

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

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

🖖 Держи руководителя в курсе

Докладывай о ситуации в команде, проговаривай с ним свой риск-план.

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

Важно показать руководителю, что ты контролируешь процесс и держишь всё под контролем.