Рынок найма в IT — это страшный сон Гудхарта
Современный рынок найма в IT сформировал один негласный стандарт: если в резюме нет цифр — ты не работал, а просто присутствовал на проекте. «Увеличил конверсию на 18%», «ускорил загрузку на 40%», «привлёк 50 000 новых пользователей» — вот язык, который понимает современный рекрутер и HR-специалист. Всё остальное — лишний шум, который отсеивается ещё до первого звонка.
Я не собираюсь спорить с самим принципом измеримости. Цифровые показатели в любом проекте нужны. А результат работы нужно уметь показывать. Научно обоснованный, ориентированный на итог подход — это не мода, а признак зрелости профессии. Однако, между «умением измерять результат» и «культом цифры как единственного доказательства существования» — огромная пропасть. И мы давно шагнули, провалились и летим в эту бездну.
Когда мера становится целью, она перестаёт быть мерой
Это не я придумал — это закон Гудхарта, сформулированный ещё в 1970-х. Экономисты это давно поняли: как только показатель становится целью управления, он перестаёт отражать то, для измерения чего изначально создавался. Современный рынок найма воспроизводит этот эффект с неизменной точностью. Современный подходы в IT-найме требуют цифры как доказательство результата. Итог закономерен: мы получили ситуацию, когда специалисты в IT научились производить цифры — часто в ущерб самому результату.
Вот что происходит на практике.
Разработчик смотрит на два проекта: первый — тяжёлый рефакторинг старого кода, который хоть и держится, но держится на честном слове и может рухнуть в любой момент. Второй — переезд на новую модную архитектуру, которая, по правде говоря, бизнесу не нужна, но зато потом можно написать в резюме: «Спроектировал и внедрил микросервисную инфраструктуру». Выбор очевиден — не потому что разработчик — коварный человек, а потому что система оценки чётко сигналит: первое невидимо и незначимо, второе же хорошо продаётся.
Дизайнер стоит перед похожей развилкой. Можно потратить два месяца на пересборку информационной архитектуры — убрать лишние шаги в процессах, сделать продукт логичным, консистентным и предсказуемым. Это огромная работа. Результат почувствуют пользователи, но он не выразится в мгновенном изменении «до/после». А можно запустить серию A/B-тестов на кнопках и заголовках — и получить заветное «поднял конверсию шага на 12%». Рынок аплодирует второму. Первое же как-будто остаётся за кадром.
Продакт-менеджер в погоне за квартальными KPI штампует мелкие фичи, каждая из которых выглядит как ценный результат, но в сумме превращает продукт в лоскутное одеяло. Закрыть технический долг? Провести глубокое исследование мотивов пользователей? Отказаться от устаревших и неактупльных функций? Всё это правильно и важно для настоящего продуктового развития — и совершенно непродаваемо в скупой строчке резюме.
Это ли карьеризм? Скорее это адаптация. Ребята из IT не стали хуже — они рационально реагируют на среду, которую создал сам IT-рынок. Как рыбы, которые мутируют под размер ячейки сети. Сеть ловит только определённый тип рыб — один вид погибает, другой вид начинает доминировать.
Откройте любой карьерный сайт. Просмотрите сотню резюме. Вы увидите картину почти фантастического успеха: каждый дизайнер поднимал конверсию, каждый разработчик ускорял системы и проектировал архитектуры, каждый продакт запускал продукты, которые взлетали и покоряли сердца пользователей. Среди временно безработных: cплошные победители, сплошные достижения, сплошной рост.
А теперь один вопрос: по статистике, от 80 до 90% IT-продуктов и стартапов проваливаются. Проекты закрываются, продукты не выходят в прод, компании банкротятся. Это нормальная, честная статистика, в которой высокая неопределённость — часть ДНК индустрии.
Но где все эти люди? Куда исчезли все, кто работал на провалившихся проектах? Как найти их по резюме?
Они никуда не исчезли. Они просто научились переупаковывать опыт. «Продукт закрыли» мутирует в «провёл исследование и дал рекомендации по стратегии». «Команда разошлась» — в «выстроил процессы в условиях высокой неопределённости». Провал представляется кейсом, а кейс — достижением. Потому что признать, что проект не выжил, и честно объяснить почему — это слишком рискованно в системе, где резюме фильтруют по цифровым показателям успеха.
В итоге бизнес нанимает людей по резюме, где написана одна реальность, а получает людей с совершенно другим опытом. И даже не потому, что последние этакие хитрецы и лгуны — а потому что честность в этой системе наказывается.
Компании думают, что жёсткие входные фильтры повышают качество найма. На деле они создают несколько системных проблем одновременно.
Первая: отсеиваются люди, которые брались за сложные, долгие, непродаваемые задачи — именно те, которые делают продукты здоровыми на горизонте двух-трёх лет. Их опыт просто не вписывается в формат.
Вторая: действующие сотрудники начинают выбирать задачи не по их ценности для продукта, а по их «резюмепригодности». А это уже настоящая диверсия — не злонамеренная, но системная.
Третья: возникает культура имитации результата. Все заняты улучшением измеримого, пока неуправляемо деградирует важное. Некоторые метрики реально растут, однако продукт слабеет. Это реальные случаи, которые опытные продакты или технические директора видели хотя бы раз.
Я беспокоюсь здесь не только о людях, которых несправедливо оценивают. Стоит беспокоиться больше о качестве того, что производит индустрия. Потому что система, которая вознаграждает только легко демонстрируемый результат, начинает производить именно его — и только его. Точно так же, как завод, настроенный на количество производимых гвоздей, начнёт делать мелкие гвозди миллионами штук: план выполнен, гвозди произведены, да только они никому не нужны.
Я не против измерений. Я против того, чтобы путать измеримое с ценным. Это не одно и то же. И никогда им не было.
Разбор по ролям: кто гневит старину Гудхарта
Есть задачи, которые держат продукт живым, но никогда не попадут в резюме. Рефакторинг старого кода — когда система работает, но держится на честном слове и понятна только одному человеку в команде, который уволился полгода назад. Стабилизация архитектуры, которая начинает трещать под нагрузкой. Документирование сложной бизнес-логики, накопленной за пять лет. Устранение хрупкости там, где пока ничего не сломалось, но обязательно сломается.
Всё это важно. Всё это тяжело. И всё это совершенно непродаваемо в строчке резюме.
Зато «мигрировал монолит на микросервисную архитектуру» — продаётся отлично. Даже если этот монолит обслуживал пятьдесят пользователей в день и прекрасно справлялся. Даже если после миграции команда потратила полгода на то, чтобы разобраться с новой сложностью, которую сама же и произвела. В резюме остаётся красивый факт: «Спроектировал распределённую систему». Всё остальное теряется за скобками.
Разработчик идёт туда, где есть хайп: новый фреймворк, облачная инфраструктура, модная база данных. Не потому что это нужно бизнесу прямо сейчас, а потому что через год это будет востребованным словом в фильтре поиска вакансий. Бизнес платит за изменения ради изменений, разработчик получает строчку. Надёжность системы при этом никого особо не интересует — её не видно в резюме.
Самая ценная работа дизайнера часто выглядит незаметно. Убрать пять лишних шагов из пользовательского сценария. Выстроить внятную информационную архитектуру, чтобы пользователь не думал, куда нажать и что делать. Проработать состояния ошибок, пустые экраны, edge cases — всё то, с чем люди сталкиваются в самые неприятные моменты.
Это тонкая, долгая работа. Когда она сделана хорошо, пользователь просто не замечает интерфейс — он просто пользуется продуктом без лишнего трения. Измерить это почти невозможно. Сравнить «было / стало» трудно, потому что хорошая информационная архитектура не создаёт всплесков удоволсьтвия. А показатели удовлетворения пользователей — не умею оценивать отдельно качество интерфейса и качество сервиса.
Поэтому дизайнер идёт туда, где есть быстрая и понятная цифра. A/B-тест кнопки: красная против зелёной, большая против маленькой, «Купить» против «Положить в корзину». Тест даст результат за две недели, и этот результат можно представить в виде подтвержденных достижений. Иногда в ход идут агрессивные приемчики — навязчивые поп-апы, тёмные паттерны. Они краткосрочно поднимают конверсию. В долгосрочной перспективе разрушают доверие к продукту. Но в резюме остаётся только подтвержденная конверсия, а долгосрочный эффект упущен.
Самое горькое: дизайнер, который несколько месяцев перестраивал логику продукта и сделал его действительно понятным, выглядит в резюме слабее того, кто провёл тридцать A/B-тестов подряд. Рынок не различает качество вмешательства — он ориентирован на количество измеримых изменений.
Продакт находится в самом эпицентре этой проблемы, потому что именно он отвечает за приоритеты. И именно его приоритеты влияют на развитие продукта.
Работа с удержанием пользователей — один из самых важных рычагов в продукте — даёт результаты через кварталы. Это медленная, аналитически сложная работа: понять, почему люди уходят, убрать причины, проверить гипотезу, ждать месяцы, а то и годы, пока накопятся новые данные. Резюмепригодность минимальная.
Закрытие технического долга — вообще не существует в языке найма. Это звучит как «мы убирали за собой мусор». Никого сейчас не нанимают за умение убирать мусор, даже если этот мусор тормозит развитие десятков других продуктов компании.
Зато «запустил 12 фич за квартал» — звучит как продуктивная и востребованная работа. Не важно, что половина из фич никому не была нужна. Запустил, показал хоть какое-либо вовлечение пользователей — значит результат уже оправдан.
Ещё хуже с метриками тщеславия. Число регистраций, количество скачиваний, просмотры, клики, активации — всё это легко растёт, если чуть снизить качество трафика или добавить агрессивную рекламу. Удержание при этом падает, реальная вовлечённость падает, деньги не приходят — но в презентации для инвесторов и в строчке резюме всё выглядит как рост.
Настоящая аналитика — это часто неудобный разговор. «Ребята, наши данные грязные, мы не можем доверять этим выводам». «Этот A/B-тест был настроен неправильно, результаты невалидны». «Метрика, на которую мы ориентируемся уже два года, не отражает реальное поведение пользователей».
Такой аналитик полезен. Но его ценность почти невозможно продать: он ничего не "построил", он разрушал иллюзии. Это не тот нарратив, который проходит фильтр найма.
Поэтому аналитики идут в бесконечное построение дашбордов. Красивые графики, автоматические отчёты, интерактивные визуализации — всё это хорошо смотрится в портфолио и легко описывается. «Построил систему аналитики для продукта с аудиторией X миллионов». Звучит серьёзно. Неважно, что данные в эту систему поступают с ошибками, а выводы из неё делаются поверхностно.
Аналитика постепенно превращается не в инструмент понимания, а в инструмент легитимации решений, которые уже приняты. Данные подбираются под нарратив. Метрики выбираются те, что растут. Это не ложь в прямом смысле — это почти незаметная избирательность, которую порождает среда, вознаграждающая только позитивные результаты.
Лучший тестировщик — тот, которого не замечают: продукт стабилен, критических багов не было, релизы проходят без инцидентов. Это профессиональный идеал. И одновременно — резюмешный кошмар. Потому что «обеспечивал стабильность продукта» — это не достижение в языке найма.
Поэтому QA учится считать. Количество заведённых багов, объём тест-кейсов, процент покрытия кода автотестами. Если KPI завязан на эти цифры — поведение меняется немедленно: баги дробятся на несколько карточек, тест-кейсы пишутся на очевидные сценарии, автотесты покрывают простые пути, а не критические края.
Сложное исследовательское тестирование — когда нужно думать как пользователь и искать нестандартные ходы — занимает много времени и не производит красивых отчётов. Проверка редких, но дорогих ошибок в бизнес-логике — то же самое. Этим заниматься невыгодно, если тебя оценивают по количеству.
Руководителю деформация даётся, пожалуй, тяжелее всего — потому что от него зависит на что ориентируется вся команда.
Настоящее лидерство — это медленная работа. Вырастить джуниора до мидла за год, передав ему понимание процессов и способ думать. Разрешить конфликт между двумя сильными специалистами, которые тянут проект в разные стороны. Выстроить процесс, который работает без постоянного ручного управления. Объяснить команде, почему мы не делаем эту фичу, даже если бизнес давит.
Всё это невидимо снаружи и сложно представить в виде достижения. Зато реорганизация команды — видима. Запуск новой инициативы с громким названием — видима. Внедрение нового процесса, который через полгода тихо умрёт, но успеет попасть в презентацию — видимо.
Руководители начинают управлять не ради устойчивости команды, а ради управленческого следа. Каждый квартал должен выглядеть как трансформация. Постоянная реорганизация, постоянные новые рамки и методологии — не потому что они нужны, а потому что так формируется нарратив «я строю и меняю процессы».
Команда при этом устаёт от изменений, теряет ориентиры и перестаёт доверять руководству и самой себе. Но в резюме руководителя всё выглядит как динамичное лидерство и движение в светлое будущее.
Все эти истории объединяет одно: люди не ведут себя как настоящие диверсанты по своей воле. Они ведут себя рационально в системе, которая выстроена так, что сложноизмеримая польза не существует. Если твоя работа не конвертируется в строчку резюме — с точки зрения рынка её и не было. И пока эта логика доминирует, самые важные задачи будут оставаться без хозяина.
Хотите узнать больше о создании цифровых продуктов, управлении продуктом, дизайне и аналитике? Подписывайтесь на мой телеграм-канал.