В одной компании из страхового IT удалённые команды по 12-15 человек перевели на квартальные OKR, а delivery-менеджеру отдали сразу четыре команды и ответственность за цифры. Вышло наоборот: прозрачности не прибавилось, потому что менеджер не видел Jira, а отчёты собирали те же тимлиды, чью работу эти показатели и должны были просвечивать. Для российской IT-аудитории это хороший, пусть и неприятный, пример того, как метрики в IT иногда строят не контроль, а его декорацию.
О кейсе сообщает Habr / Карьера в колонке delivery-менеджера Outlines Tech по имени Степан. Он описывает историю с одного из прошлых мест работы в страховом IT: несколько крупных проектов, удалённые команды, у каждой свой тимлид, а у бизнеса привычный набор симптомов. Финансовые планы не сходились, допродаж не было, заказчики тянули с оплатой, а фичи, которые обещали выпустить за месяц, доезжали до продакшена через полтора-два. Руководство увидело просадку, но не увидело причин и решило лечить её квартальными OKR, связав финансовые показатели с time to market, то есть временем от попадания задачи в бэклог до релиза.
Следом поменяли и контур управления. Между тимлидами и руководством поставили ИТ-менеджеров, которые должны были отвечать и за координацию команд, и за деньги. Степану достались четыре команды, работавшие над проектами для двух крупных российских страховых компаний. На бумаге схема выглядела логично: если показатель проседает, менеджер находит узкое место и меняет процесс. На практике ему не дали главного: прямого доступа к данным и рычагов влияния. Разработчики вели задачи в Jira заказчиков, но ИТ-менеджер туда не смотрел; тимлиды сами собирали показатели, переносили их в Excel и присылали наверх готовую картинку. А заказчики, несмотря на новую схему, продолжали обсуждать задачи напрямую с тимлидами и менять требования в работе. Ответственный за OKR узнавал об этом уже после факта.
Дальше всё покатилось по довольно предсказуемому сценарию. По отчётам руководство всё же принимало решения: одному сотруднику хотели искать помощника из-за перегруза, другого уволили как недостаточно сильного, ещё нескольких сочли недозагруженными и растянули сразу на два проекта. Команда быстро поняла правила игры. Если от цифр зависят нагрузка, деньги и само место на проекте, люди начинают оптимизировать не работу, а презентацию работы. Логика простая: показал слишком высокий результат, в следующем квартале это станет новой нормой; показал безопасный минимум, меньше шанс, что к тебе придут с дополнительной нагрузкой. В результате метрики в IT начинают обслуживать не диагностику, а самозащиту команды, и у руководства на руках всё больше красивых отчётов и всё меньше понимания, что реально происходит внутри разработки.
Критичный узел в этой истории, конфликт интересов. Автору было важно, чтобы фичи выходили вовремя, заказчик их принимал и платил без задержек. Тимлидам было важнее закрывать внутренние показатели производительности команд. Формально это должно совпадать, но на практике совпадает далеко не всегда. Подгонка вскрылась лишь в командировке, когда Степан смог отдельно поговорить с сотрудниками и с тимлидами, а не смотреть на Excel как на единственный источник правды. После этого он отправил руководству подробный отчёт с описанием проблем, но вместо пересборки схемы услышал просьбу всё равно как-то повлиять на ситуацию. Ещё два месяца попыток ничего не изменили. Сначала уволили его коллегу, затем самого Степана, а ещё через три недели третьего менеджера. Прозрачности бизнес так и не получил.
Для российского рынка здесь важен не только драматичный финал, но и механика сбоя. Компании любят дашборды, OKR и KPI, особенно в моменты, когда сроки плывут, а экономику проекта хочется увидеть на одном экране. Но этот кейс показывает простую вещь: метрики в IT не работают как магия поверх сломанной оргсхемы. Если человек отвечает за показатель, но не видит первичные данные, он не управляет процессом, а ретранслирует чужую интерпретацию. Если заказчик меняет требования мимо формально ответственного менеджера, любой time to market становится смесью из разработки, коммуникации и организационных дыр. А если сотрудники заранее не понимают, как показатели влияют на зарплату, загрузку и карьеру, они почти неизбежно начинают считать метрики угрозой, а не инструментом.
Полезная часть кейса в том, что автор не ограничивается обидой на работодателя и формулирует практические правила. У каждой метрики должен быть конкретный управленческий вопрос: какое решение примут, если число пойдёт вверх или вниз. Ответственный за показатель обязан видеть сырые данные, а не только финальную табличку. Полномочия должны совпадать с ответственностью, иначе менеджера просто назначают виноватым без права что-либо менять. Правила игры лучше фиксировать до запуска системы, особенно если цифры влияют на деньги и нагрузку. И, наконец, компании стоит честно разделять вклад человека и дефекты самой системы: задержка релиза может говорить не о слабом разработчике, а о плохих доступах, плавающих требованиях или лишнем слое управления.
Соблазн лечить проблемы разработки новым набором показателей никуда не денется: цифры успокаивают, особенно тех, кто далёк от ежедневной работы команды. Но чем сильнее бизнес пытается измерить всё подряд, тем дороже становится ошибка в дизайне этих измерений. Главный вопрос не в том, сколько метрик у вас в отчёте, а в том, помогают ли они увидеть реальность раньше, чем команда научится её маскировать.