14046
Канал про IT продукты и управление. Автор: Алексей Арефьев @alexaref Путь: сейчас CPO+CTO Kion, CPO more.tv, CPO Столото, PO Tele2. Консультирую компании и людей, подробности тут - https://bit.ly/48KBr1k
З/П IT-шников в РФ 2026 год
Собрал свежие циферки по вилкам зарплат разных IT профессий и ролей. Достаем попкорн и считаем чужие деньги💵
Внутри отчета:
- профессии
- грейды
- бабки/мес на руки
- динамика 2026 к 2025
Сравнение 2026 vs 2025
Медиана по профессии, тыс. руб./мес:
iOS: 295 → 333 (+13%)
Android: 282 → 310 (+10%)
Продуктовый дизайнер: 202 → 221 (+9%)
BE: 235 → 250 (+6%)
FE: 212 → 225 (+6%)
Архитектор: 450 → 472 (+5%)
Проджект: 170 → 178 (+5%)
Продакт: 270 → 280 (+4%)
DevOps: 230 → 238 (+4%)
QA авто: 220 → 226 (+2%)
Системный аналитик: 200 → 200 (0%)
QA ручной: 130 → 130 (0%)
Вся IT-медиана за год выросла на 4,5%, а инфляцию ЦБ ждёт на уровне 4,5–5,5%.
Заметно обогнали инфляцию только мобильщики, дизайнеры, фронты и бэки. Архитекторы и проджекты держатся примерно на её уровне, а у остальных зарплаты в реальных деньгах просели.
Вилки по грейдам 2026
Продакт менеджер
Джун: 110 000 - 175 000 руб.
Мидл: 165 000 - 315 000 руб.
Сеньор: 290 000 - 470 000 руб.
Лид: 340 000 - 560 000 руб.
Проджект менеджер
Джун: 75 000 - 145 000 руб.
Мидл: 110 000 - 235 000 руб.
Сеньор: 175 000 - 340 000 руб.
Лид: 220 000 - 435 000 руб.
Продуктовый дизайнер
Джун: 70 000 - 110 000 руб.
Мидл: 115 000 - 220 000 руб.
Сеньор: 215 000 - 340 000 руб.
Лид: 295 000 - 470 000 руб.
Системный аналитик
Джун: 75 000 - 135 000 руб.
Мидл: 150 000 - 255 000 руб.
Сеньор: 250 000 - 370 000 руб.
Лид: 295 000 - 450 000 руб.
Архитектор
Мидл: 365 000 - 535 000 руб.
Сеньор: 400 000 - 580 000 руб.
Лид: 440 000 - 655 000 руб.
QA ручной тестировщик
Джун: 60 000 - 100 000 руб.
Мидл: 105 000 - 185 000 руб.
Сеньор: 185 000 - 275 000 руб.
Лид: 180 000 - 335 000 руб.
QA авто тестировщик
Джун: 85 000 - 165 000 руб.
Мидл: 150 000 - 255 000 руб.
Сеньор: 245 000 - 370 000 руб.
Лид: 290 000 - 475 000 руб.
Разработчик BE
Джун: 75 000 - 145 000 руб.
Мидл: 160 000 - 290 000 руб.
Сеньор: 285 000 - 430 000 руб.
Лид: 355 000 - 550 000 руб.
Разработчик FE
Джун: 60 000 - 115 000 руб.
Мидл: 140 000 - 260 000 руб.
Сеньор: 270 000 - 415 000 руб.
Лид: 325 000 - 480 000 руб.
Разработчик iOS (Swift)
Мидл: 225 000 - 345 000 руб.
Сеньор: 320 000 - 465 000 руб.
Лид: 410 000 - 615 000 руб.
Разработчик Android (Kotlin)
Джун: 75 000 - 140 000 руб.
Мидл: 195 000 - 340 000 руб.
Сеньор: 335 000 - 470 000 руб.
Лид: 405 000 - 615 000 руб.
DevOps
Джун: 80 000 - 160 000 руб.
Мидл: 165 000 - 290 000 руб.
Сеньор: 280 000 - 440 000 руб.
Лид: 360 000 - 585 000 руб.
Цифры выше
Будут полезны, если:
- хотите залететь в какое-то направление с нуля
- уже растете в каком-то из них и думаете просить повышение
- нанимаете народ в команду и нужно прикинуть бабки для ориентира
... ну или просто любознательны как я😎
---
Источники:
- Калькулятор зарплат Хабр Карьеры, вилки и динамика по профессиям
- Исследование Хабр Карьеры за 1-е полугодие 2026: медиана по IT и прогноз инфляции ЦБ
- РБК о росте зарплат в IT за год
#рекомендуетсяизучить
Режим основателя
Пол Грэм (сооснователь Y Combinator) в 2024 году написал эссе, которое называется «Founder Mode». Материал вызвал много споров и критики, потому что предлагал альтернативный взгляд на управление.
Суть
«Founder mode» говорит о том, что основатель компании должен управлять ею не только через прямых подчинённых, а лезть гораздо глубже. Встречи с уровнями −2, −3, −4 и ниже становятся обычной практикой.
Цитата из эссеДальше в материале Пол говорит и про делегирование, и даже предупреждает, что термином «режим основателя» начнут прикрываться микроменеджеры. Но комьюнити всё равно взбудоражилось и мусолило тему микроменеджмента вдоль и поперёк.
Hire good people and give them room to do their jobs. Sounds great when it's described that way, doesn't it? Except in practice, judging from the report of founder after founder, what this often turns out to mean is: hire professional fakers and let them drive the company into the ground.
-
Нанимай хороших людей и дай им пространство для работы. Звучит отлично, правда? Вот только на практике, если судить по рассказам одного основателя за другим, это часто превращается в «найми профессиональных имитаторов и позволь им загнать компанию в землю».
GoPro: конец эпохи
В сентябре этого года GoPro согласилась продаться Starman Optical за $285 млн (Reuters) при том, что в 2014-м компания стоила почти $12 млрд. Не смог пройти мимо этой новости, потому что всегда был фанатом этого продукта.
Помню, как друзья показывали маленькую квадратную камеру (hero 1), которая могла якобы снимать в движении и тряске всякие приколы. Не верил, потом увидел, что может и словил вау эффект.
Сложно было поверить, что такой мощный продукт/бренд потеряет рынок. Хотел разобраться поглубже почему так.
Циферки
Как менялись доли рынка портативных камер (2024 → 2025 → 2026):
DJI: ~44% → 62% → 73%
Insta360: ~20% → 20% → 20%
GoPro: ~27% → 11% → 3%
При этом ещё в 2022-м у GoPro было около 80% рынка экшн-камер.
Еще интересно, что в 2025-м рынок весь вырос на 83%, а продажи GoPro всё равно падали.
Почему так вышло
Проспала смену сценария. Камеры стали покупать для влогов и соцсетей, а не только для экстрима. Быстрее всего растут подвесные камеры вроде DJI Pocket, а у GoPro такой нет.
Обновлялись медленнее конкурентов. Перегрев, слабая ночная съёмка, небольшие сенсоры: DJI и Insta360 решали эти проблемы быстрее.
Проиграла в цене и масштабе. У DJI своё производство и розница по всему миру. GoPro тем временем распылялась на дроны неуспешно (спойлером), а потом отступила на рынок Америки.
Вывод
Можно годами улучшать свой продукт и не заметить, что пользователи покупают его уже для другой задачи.
Из похожих историй примерно то же самое было с Kodak, Nokia. Может вы в комментах вспомните кейсы посвежее, у меня одно старье всплывает.
#продуктовыеистории
Когда на слайде спросили про цифру
#смешноибольно
Ловушка ожиданий и системные задержки
Вижу частую историю, когда кто-то кому-то что-то обещает, игнорируя фактор инертности.
Например
Хотим запустить новое направление, считаем кейс, закладываем доп.людей. Прикидываем роадмэп и... и забываем про задержку с наймом и обучением. На выходе сроки едут, ожидания не оправдываются, все расстраиваются.
Или представим, что у вас в моменте не хватает каких-то определенных спецов на борту. Вы заряжаете ударный найм на усиление, резко выводите кучу людей и казалось бы счастье, но нет. Ваши сеньоры, которые тащили задачи, отвлекаются от работы, перекидываются онбордить новичков. Общее проседание по системе еще выше.
Что делать
Прикидывать возможные задержки от активностей, которые планируете делать. Решится ли вопрос в моменте или потребуется время? А что будет потом?
Вроде бы очевидно, но в любимой операционке можно легко проскакивать эти вопросы, а потом разгребать последствия.
#продуктовыйпуть
Метрики: OMTM
Про то, что правда важно качать на определенном этапе развития продукта.
Определение
OMTM (One Metric That Matters) - самая важная метрика для команды на конкретном отрезке времени.
Зачем нужна OMTM
Чтобы сфокусироваться командой на решении основной задачи. Чаще всего OMTM используется на ранних этапах развития продукта, но по факту может быть полезна и позже.
Примеры
Для нового продукта в качестве OMTM может быть выбрана метрика Retention в целевое действие. Почему? Потому что она лучше всего отражает силу ценности продукта для клиента product market fit.
После того как команда прокачает Retention в качестве OMTM может быть выбрана конверсия в активацию, оплату или что-то подобное. Команда побежит работать над этой целью и так далее, расшивая узкие места в росте продукта.
Но ведь это похоже на NSM (North Star Metric)
Не совсем. NSM больше про долгосрочные цели и поэтому редко меняется во времени. Она отражает скорее общий объем создаваемой продуктом ценности для всех своих пользователей, а не точку приложения усилий в моменте, как OMTM.
NSM становится полезнее по мере усложнения структуры команды и приближения к этапу масштабирования. Она задает общую цель и помогает в приоритизации решений на разных уровнях системы. При этом у отдельных команд чаще всего будут свои цели на каждый квартал или полугодие - OMTM до уровня конкретной команды.
По сути NSM - стратегический уровень, а OMTM - тактический. Одна про далекий горизонт, к которому бежим, другая - про этапы, шаги, которые нужны, чтобы добежать.
Итого
OMTM - фокусная метрика, которую вы выбираете для решения конкретной задачи на конкретном промежутке времени. Со временем она может меняться и это нормально. Важно то, что все понимают куда нужно прикладывать усилия, а значит вероятность успеха будет расти, ну и красивый цвет лица останется😎
#продуктовыеметрики
Когда такой свеженький собрался в отпуск после пары лет без отпуска
#смешноибольно
Обзор книги: Искусство системного мышления
Дочитал книгу по системному мышлению от Джозеф О’Коннор и Иан Макдермотт. Мне ее рекомендовал мой ИИ-шный учитель как усиление к основной программе.
Оценка 7/10
Внутри много мяса, примеров и разборов, но есть и шероховатости, которые меня зацепили. Расскажу.
Основные тезисы
Книга дает постепенную развертку системного мышления. Начинает с основ и постепенно докручивает вокруг них все более сложные конструкции.
Из интересного, мне зашел кусок про ментальные модели. То, что мы формируем для себя как основу нашего мышления, то, что само по себе является "надсистемой" и влияет на наше мировосприятие.
Сам посыл - посмотри снаружи на то как ты мыслишь напомнил мне психотерапевтическую практику с метапозицией. Пока ты не выйдешь "за границы", не сможешь понять как это работает. В этом плане прям топ🔥
Дальше идут блоки про циклы обучений в системах. Мне это тоже близко. Сложно расти без циклов обратной связи. Одна из ключевых задач менеджера - строить эти практики внутри команды. И чем лучше они работают, тем выше общий результат.
Что не понравилось
Это глоссарий и "переназывание" базовых кусков системного мышления. Например, есть архетип "Трагедия общин", который везде так называется. В статьях, в образовательных программах, в умах людей.
Смысл штуки в том, что имея систему с общим ресурсом, каждый действует в своих интересах, игнорируя общий интерес. Если ресурсами не управлять, то это приведет к кризису для всех.
Вышел на новое место
Не так давно я присоединился к команде онлайн-кинотеатра Wink. Отвечаю за технологии и продукт. На мне счастье, рост и удержание клиентов.
Опыт интересный, потому что это своего рода камбэк. Три года назад до Киона, МТС Медиа и экосистемы мы уже работали с текущей командой, объединяли more.tv и Wink в совместное предприятие. Много знакомых людей вокруг, онбординг проще и вызов впереди.
Вместе с командой нам нужно будет усилить Wink. Мощная линейка оригинального контента, широкая сеть дистрибуции и крепкая IT платформа под капотом. Есть мысли как вокруг этой сильной базы забустить продукт, попробуем.
Пожелайте мне удачи на новом месте. Опытом и кейсами по ходу, само собой, буду делиться🔥
#продуктовыйпуть
Хороший менеджер снимает блокеры.
Отличный менеджер не ставит новые.
Легендарный менеджер просто ушёл в отпуск, и команда впервые начала работать спокойно.
#смешноибольно
Evolution Disaster Recovery от Cloud.ru
Команда Cloud.ru собрала продукт для восстановления инфры за минуты - это агент, который ставится в BM и реплицирует на уровне ОС. Поэтому неважно, где крутится прод: в другом облаке, в своей серверной или у другого провайдера.
Плюсом, обещают, что план восстановления можно тестировать в изолированном контуре, не трогая рабочую систему. Удобно.
Попробовать можно тут - перейти к сервису.
Реклама, ООО "Облачные Технологии", ИНН 7736279160, erid: 2W5zFK8spuX
#спонсорскийконтент
Про структуры и системы
Попало прямо в сердечко, цитирую:
Менеджера могут обвинить, что он действовал неправильно, хотя на самом деле у него просто не было нужной информации из-за несовершенства работы сотрудников в другом подразделении. А те могут заявить, что виной всему - методы сбора данных, которые должны обсуждаться всеми, в том числе и провинившимся менеджером. Получилось, что винить нужно систему. Поэтому, если вы ищете виноватого в ее пределах, то кончите тем, что сами им окажетесь, впрочем, как и все остальные, а причиной тому - петли обратных связей и причинно-следственных отношений. Никто не приходит на службу с намерением что-то испортить, но структура системы может не позволить сделать работу хорошо.
Если руководство
попадется в ловушку «поиски виновных», оно найдет, кого уволить, на их место возьмут других, но лучше от этого не станет. Чем искать выдающихся сотрудников, лучше организовать работу таким образом, чтобы с ней могли справляться обычные люди. Результаты зависят от структуры системы. Чтобы улучшить результаты, нужно изменить структуру системы.
#29 Задание
- Вы продакт в GodDamn Company.
- Основной продукт помогает подобрать утешительный трек, когда ты бьешься мизинцем о ножку стула или просто испытываешь разочарование по какому-то поводу.
- Ваша цель – расширить сценарии и библиотеку треков, чтобы привлечь новую аудиторию + заработать на подписке.
- Босс попросил собрать стратегию по новому сегменту и дал на это неделю.
- В прошлом было также: времени на подготовку давали мало, а на выходе получалось очень слабое решение. Исследований нормальных нет, кейс не проработан, эксперименты красные.
- Вас эта тема не устраивает, но вы понимаете, что босса пушит его босс и за неисполнение всем прилетит.
Что будете делать?
Напишите, пожалуйста, ответ в комментариях.
#продуктовыезадания
Когда случайно залетел на обсуждение задачки и словил поручение
#смешноибольно
Мой календарь — как legacy-код: никто не помнит, зачем эти встречи, но удалять страшно.
#смешноибольно
Статус «Готово» врёт
«Закрыть задачу» может означать совершенно разные вещи: закончил, передал дальше, перестал делать, отложил до завтра.
Часто ловлю тему, когда кто-то кому-то говорит «Готово», но в реальности это не то, чего ожидают.
Примеры
Разработчик говорит «Готово», когда написал свой кусок кода и отдал в тесты, но весь функционал ещё не вылез на прод.
«Готово», когда фича уже на проде, но в A/B-эксперименте собирает данные.
«Готово», когда раскатано на всех, но через пару-тройку месяцев не сняты повторные цифры, о которых договаривались.
И ведь не обязательно кто-то врёт. Хотя и такое бывает. Просто один говорит про код, второй про запуск, третий про результат. А слово у всех одно.
Дальше недопонимание, набросы, потеря энергии.
Почему так
Потому что мы варимся в разных контекстах и взгляд на «Готово» у каждого свой.
Что делать на уровне задач
Договориться о критериях готовности. На стол/бумагу/джиру/конфлюенс:
- Что именно должно быть готово?
- Кто принимает результат?
- Что происходит после этого и кто подхватывает дальше?
В разработке часть этой договорённости закрывает Definition of Done (DoD): общие критерии качества готового результата. Но кто принимает результат и что происходит дальше, тоже нужно проговорить.
Что делать на уровне команд
Проговаривать смысл слова «Готово». Объяснять, что вы как продакт вкладываете в это понятие. И выяснять, что под ним понимает команда. Калибруетесь несколько итераций и потом понимаете друг друга с полуслова.
P. S. А какой статус по задачам в вашей работе врёт чаще всего? Напишите в комментариях.
#инструментыпродакта
Ходил на Data&AI Talks
Позвали на конференцию поговорить про, барабанная дробь... ИИ-шку и бизнес.
Вокруг темы ооочень много хайпа, ну как крипта в свое время или agile, которыми лечили все что можно. Кто-то даже говорил, что вода рядом заряжалась и давала к силе +5. Ну да ладно.
Если серьезно, то вопрос болезненный, потому что кричат вокруг про Эй Ай все, но куда приложить непонятно и где заветные Х-ы тоже только знают по слухам. Поэтому хотелось ковырнуть немного и поговорить.
Дальше будут вопросы и мои тезисы, которые я озвучивал
1. Какие ключевые вызовы стоят перед бизнесом сегодня? Как изменился подход к разработке и выводу продуктов на рынок?
- основной вызов – это скорость vs качество
- все сломя голову говорят, что ИИ спасет от всего: ускорит, улучшит, задрайвит и т.д., но на деле не все так просто
- чтобы получить обещанные Х-ы роста от ИИ у тебя должна быть готова под это вся компания: инфраструктура, понятийный аппарат людей, инструменты, процессы
- это большая трансформация, требующая больших инвестиций, к которым мало кто готов
- поэтому идем итерационно: берем процесс/задачу, добавляем ИИ, пробуем, замеряем успех, масштабируем
- очень важно следить за качеством
- берем разработку продуктов
- ИИ круто помогает ускорять discovery: ресерч рынка, формулировка гипотез и моделирование сейчас проходят в разы быстрее, но вопрос в качестве этих ответов
- если тот же продакт вместо критического взгляда просто сходу возьмет в работу то, что ему даст машина, то это может привести к печальным последствиям и трате лишних ресурсов
- такая же ситуация и в разработке, когда машина напишет код за разработчика, он упрется в тестирование и его вернут на доработку из-за потенциальных ошибок, далее поправят и снова вернут
- сколько дополнительных денег мы готовы потратить на перепроверку результата?
2. Как трансформировалось взаимодействие между бизнесом и ИТ-подразделениями?
- с приходом ИИ между бизнесом и ИТ появился дополнительный «мостик» в понимании потребностей друг друга
- сейчас потенциальный бизнес заказчик может «переводить» предложения ИТ на обычный человеческий язык
- ровно и наоборот бизнес может доформулировать свои запросы с учетом ИТ специфики, общаясь с разработкой
- но, что важно в этих коммуникациях – это доменные области знаний и доверие к экспертизе друг друга
- если бизнесу ИИ говорит, что для решения задачи нужно написать всего лишь пару строк когда, то это должны свалидировать архитектура и разработка, потому что специфика системы может быть «чуточку сложнее»
- и реализовав, решение в 2 строчки на бою, оно может быть просто не масштабируемо на большой базе в принципе
3. Что дальше? Какая роль будет у ИТ? Будет ли это только поддержка инфры под ИИ и работоспособности агентов или в целом ничего не изменится?
- я думаю, что в будущем ИТ научится еще лучше слышать бизнес благодаря ИИ
- плюс, автоматизировать рутинные операции внутри процесса производства продуктов
- вместе с этим усилится роль ИТ архитекторов/менеджеров, которые будут проектировать подобные системы
- рынку нужно будет разворачивать «ИИ заводы» внутри компаний «под ключ», а значит кто-то должен будет это делать
- пример из прошлого Agile практики с трансформациями
- также важными останутся ключевые точки контроля в производственном процессе, где на людях с высокой экспертизой останется проверка ключевых решений, которые будет собирать машина перед релизом
- поэтому сеньор специалисты будут востребованы, но вопрос в каком кол-ве пока открыт…
Еще из интересного
Другие спикеры говорили про стандарты и измерения. Сейчас рынок пытается описать процессы и методологии применения AI. Договориться о стандартах и "линейке".
Путь похож на масштабирование Agile практик:
- подходы и практики обросли описательной частью
- появились принципы внедрения, инструкции, эксперты
- тема начала приживаться в компаниях
- и вот сегодня никого уже не удивить "гибкими" методологиями
Думаю совсем скоро тема упакуется в цельный предмет и мы будем разворачивать полноценные инструкции по применению.
#рекомендуетсяизучить
Запустили A/B-тест. Оба варианта проиграли текущей версии. В отчёте написали: «Подтвердили качество действующего решения».
#смешноибольно
Визибилити
Вокруг все чаще слышу тезис, что "визибилити" или "видимость" человека в компании имеет большое значения для развития карьеры. Типа важно, чтобы ты везде отсвечивал и будет тебе счастье.
Это правда? Поделитесь мнением в комментариях, пожалуйста.
#опрос
Установка для доверия в команде
Был недавно на одном тренинге, спикер дал интересный инструмент, который мне зашел.
Представьте, что вы работаете в NASA. Попасть туда очень сложно и те, кто пробился, это очень крутые спецы в своих областях. Обсуждая с ними что-то, вы будете их внимательно слушать, потому что доверяете экспертизе.
А теперь переложите этот фрейм на компанию, в которой работаете. Посмотрите вокруг. Эти люди тоже профи в своих областях, которые шли к текущей точке годами. Они эксперты и знают то, что не знаете вы. Послушайте их, а потом предлагайте что-то свое.
Вот такая установка
Убирает в работе лишние эмоции, надуманность и прочее. Создается среда уважения и доверия. Люди хотят сперва слушать, а потом говорить. Мощно меняет фокус энергии в команде. Попробуйте, меня проштырило прям🔥
#инструментыпродакта
#7 Шпаргалка CPO: стратегические рычаги роста продукта
Проблема - как качественно управлять ростом продукта.
Поработать с горячей шпаргалочкой, пшшш🔥
В doc формате тут - https://docs.google.com/document/d/10GYDxZdJ_JAR7g6tNCshG61HaELrfBfJP-EA-mjLZRY/edit?usp=sharing
---
Другие шпаргалки CPO:
- цели и метрики
- связка от целей до roadmap
- чек продукта на старте
- орбиты клиентов
- онбординг нового продакта в команду
#шпаргалкисипио
Басня о поиске причин
В офисе одной компании сотрудники постоянно жаловались на шум из соседнего цеха. Руководство потратило миллионы на звукоизоляцию стен, но жалобы продолжались. Приглашенный системный аналитик выяснил, что сотрудники жаловались на шум не потому, что он мешал работать, а потому, что они чувствовали себя изолированными от новостей компании и думали, что за стеной происходит что-то важное, о чем им не говорят. Проблему решили не инженерией, а улучшением внутренних коммуникаций.
Пример в IT
В одном из ваших продуктов падает метрика Retention (удержание пользователей). «Здравый смысл» диктует: нужно переделать UI или добавить новые фичи. Но системный анализ может показать, что проблема лежит вне продукта, например, перформанс-маркетинг закупает нецелевой трафик, который физически не может конвертироваться в постоянных читателей.
Вывод
Никогда не лечите симптом там, где он проявился. Истинная причина сбоя в сложных системах почти всегда лежит в другом узле или на другом уровне.
#продуктовыйпуть
Апдейты в TikTok
Недавно мессенджер подвез пачку новых фичей для комментариев, которые показались интересными.
Первая - голосовые комменты. Наговорили, накричали и положили под видео. Не знаю насколько это годно, но может я старпер.
Вторая - голосовалки. Заводишь опрос на всех, смотришь, что народу ближе.
Ну и третья - фото. Закинул стикер, мем, картиночку вместо статичного текста, выразил эмоцию.
Почему интересным показались эти обновления. Потому что базового формата медиа TikTok уже не хватает. Продукт спускается глубже на уровень комментариев и создает как бы "TikTok в TikTok-е". Больше возможностей для самовыражения, больше вовлеченности, больше рекламы.
За последние 2 лет темпы роста соц.сети сильно снизились. Раньше это были двузначные цифры, теперь меньше 10% YoY. Рынок постепенно заканчивается, теперь пошла работа на "выжимание" базы. Вангую - со временем увидим доп.возможности для рекламодателей внутри новых фичей.
#продуктоваястратегия
Додумывание за других, это проблема?
Поделитесь мнением в комментариях.
#опрос
- Почему задача не сделана?
- Там всплыл технический долг.
- А кто его брал?
- Мы. Под высокий процент фичами.
#смешноибольно
Тэкс, тут по навыкам в топах опроса было критическое мышление.
Напишите, пожалуйста, в комментах вы его как-то качаете? Если да, то как?
Закон Гутхарда: как НЕ хакнуть метрики
Мы выполнили KPI по регистрациям на 120%. Хорошо? Ну да, а чего же. Пошли на выручку смотреть, а она упала. Копнули глубже трафик, оказалось, что ботов нагнали. Премия получена, но в целом компании нехорошо.
Пожалуйста, словили закон Гутхарда.
Капелька истории
В 1975 году британский экономист Чарльз Гудхарт сформулировал закон, который звучит так:
«Когда метрика становится целью, она перестает быть хорошей метрикой».
Простыми словами как только вы привязываете к конкретному показателю бонус, повышение или оценку успеха команды, люди перестают делать хороший продукт. Они начинают «хакать» систему и оптимизировать все под одну цифру даже в ущерб здравому смыслу.
Примеры, когда плохо
Посмотрим как не надо делать.
💩 Разработка
Цель - количество строк кода.
Итог: разработчики пишут раздутый код без рефакторинга.
💩 QA и Баги
Цель - количество закрытых багов. Итог: тестировщики заводят микро-баги (опечатки, съехавший пиксель), а разработчики их героически фиксят. Реальные проблемы висят в бэклоге.
💩 Продукт
Цель - увеличить дневную аудиторию. Итог: команда начинает спамить юзеров кликбейтными пушами. Люди заходят, плюются и закрывают приложение. DAU растет, Retention и лояльность летят в пропасть.
Как лечить
Два простых правила.
1. Используйте метрики-противовесы
Если измеряете скорость ответа поддержки (Time to resolve), обязательно трекайте удовлетворенность (CSAT). Ускорение не должно ломать качество.
2. Не привязывайте мотивацию к одной прокси-метрике
KPI должны быть комплексными и привязанными к финальной ценности для бизнеса (например, LTV или Profit), а не только к промежуточным шагам.
Бонус
Если внутри компании используете North, то она неплохо будет калибровать вас и подсветит не свернули ли вы не туда в погоне за красивыми дашбордами.