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

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

На старте это выглядит так:

• художники воспринимают любые цифры как попытку оцифровать творчество;

• тимлиды опасаются, что показатели превратятся в KPI;

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

Любое неосторожное «замеряем» разрушает доверие. Поэтому я искала способ внедрить метрики так, чтобы они стали инструментом навигации, а не контроля; и чтобы команда со временем сама начала ими пользоваться.

Постепенно из этого выросла система на четырёх показателях: estimation accuracy, task complexity, variability и volatility. В этой статье я разберу, как она устроена, какие сигналы даёт и как внедрить её без потери доверия команды.

Метрики не делают систему идеальной. Но правильно внедрённые, они делают её наблюдаемой, а значит, управляемой.

Контекст: почему аутсорс ААА тайтлов — особая среда

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

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

• Волатильный входящий поток: приоритеты на клиентской стороне меняются, к плановым задачам добавляются срочные вставки, объём работы между периодами может отличаться на 30-40%.

• IP-зависимость: многие задачи проходят через approval-лупы, которые не всегда предсказуемы по длительности.

В такой среде стандартные метрики «сдано/не сдано» дают мало сигналов для управления. Нужна другая логика.

Четыре метрики: что это и зачем

Прежде чем переходить к деталям — коротко про саму систему.

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

Шаг первый: estimation accuracy как индикатор предсказуемости системы

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

Estimation accuracy — это не про точность людей. Это про предсказуемость системы.

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

Как считаем

Мы сравниваем плановое время с фактическим и проверяем, попадает ли задача в допустимый коридор — не точку, а диапазон. Например:

• Оценка: 10 часов → попадание: 8-12 часов (±20%)

Нас интересует не отдельная задача, а процент попаданий за период (месяц).

Что читаем в тренде

Стабильный диапазон — скажем, 75–85% — гораздо полезнее для управления, чем резкие колебания между «идеально» и «провалено». Когда процент начинает устойчиво снижаться, это сигнал: что-то в системе меняется. Типы задач, сложность, требования, договорённости на входе.

Важно: одно падение — почти никогда не проблема. Устойчивый нисходящий тренд на нескольких периодах — вот повод остановиться и разобраться.

Парадоксально, но «идеальная» точность — 95%+ — тоже сигнал. Чаще всего это означает чрезмерные буферы или заниженные ожидания.

Чего не делаем ни при каких условиях

Estimation accuracy никогда не становится персональным KPI и не используется для сравнения команд. В этот момент метрика перестаёт быть навигационным инструментом и превращается в источник защитного поведения, как раз теряя всякую управленческую ценность.

Шаг второй: сложность задачи как контекст для оценки

Estimation accuracy хорошо показывает, что система становится менее стабильной, но не объясняет, почему.

Задачи с одинаковой оценкой могут вести себя совершенно по-разному. Не потому что команда «плохо оценила», а потому что природа работы разная. Именно здесь появляется второе измерение — task complexity.

Сложность — это про неопределённость, не про объём

Два ассета, оба оценены в 10 часов:

• Ассет А: продакшн по знакомому пайплайну, чёткие требования, предсказуемый результат.

• Ассет Б: тот же размер, но новый визуальный стиль, частично определённый бриф, несколько стейкхолдеров в ревью.

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

Как complexity меняет планирование

Когда мы начали учитывать сложность рядом с оценкой, планирование перестало быть простой арифметикой и стало разговором о распределении рисков. Вместо «влезем ли мы в объём?» мы стали спрашивать «где мы берём риск — и почему?».

Одна и та же оценка начала означать разные вещи:

• Для задач низкой сложности — это обязательство.

• Для задач высокой сложности — это гипотеза, а не обещание.

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

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

Шаг третий: variability — изменчивость микса задач

Даже при нормальной estimation accuracy и понимании complexity системы теряют предсказуемость. Одна из частых причин — variability.

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

Пример

Два месяца. Та же команда. Тот же объём.

На бумаге оба месяца «сбалансированы». На практике месяц Б сложнее планировать и прогнозировать — не из-за людей, а из-за структуры работы.

Как считаем

Мы отслеживаем распределение типов задач за период в процентах от общего объёма. Например: продакшн — 70%, правки — 20%, эксплоративное — 10%. Если в следующем периоде эти доли значительно смещаются, variability высокая — даже если общий объём часов тот же.

Никакой сложной математики: достаточно смотреть на изменение долей от периода к периоду. Устойчивое смещение на 15-20% в одном из типов — уже повод обратить внимание.

Когда variability растёт, реакция — не «попросить команду точнее оценивать», а изменение операционной логики:

• Группировать похожие задачи, чтобы сократить переключение контекста

• Защищать часть команды от нестабильного входящего потока

• Закладывать более широкие коридоры на период с высоким миксом

Шаг четвёртый: volatility — волатильность входящего потока

Даже если мы понимаем сложность и следим за миксом задач, системы могут ощущаться нестабильными. Следующая причина — volatility.

Volatility — это не про типы задач. Это про то, насколько сильно флуктуирует объём входящей работы.

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

Пример

В периоде Б ничего «не сломалось». Просто изменился объём входа — и это и есть volatility.

Как считаем

Volatility — это отклонение входящего объёма работы от среднего за последние N периодов. Например: если в среднем за квартал команда получает 200 задач в месяц, а в конкретном месяце пришло 280 — отклонение составляет +40%. Именно это число мы и отслеживаем в динамике. Резкий рост отклонения от периода к периоду — сигнал, что система переходит в реактивный режим.

Почему её часто неправильно диагностируют

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

Когда volatility растёт, мы не просим команду работать быстрее. Мы меняем режим работы системы:

• Резервируем часть capacity под незапланированные задачи

• Устанавливаем явные WIP-лимиты

• Планируем с буферами вместо фиксированных обязательств

• Заранее коммуницируем стейкхолдерам, что предсказуемость в этот период будет ниже

Как эти метрики работают вместе: реальный сценарий

Отдельно каждая метрика даёт частичную картину. Вместе они позволяют читать систему.

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

Что показывают метрики:

Что делаем:

Улучшать точность оценок здесь — не решение. Вместо этого мы перестраиваем систему:

• Ограничиваем параллельное выполнение high-complexity задач

• Выстраиваем последовательность эксплоративных задач, а не запускаем всё одновременно

• Защищаем часть команды от волатильного входящего потока

• Расширяем коридоры доставки

• Синхронизируемся со стейкхолдерами: предсказуемость временно снизится — это осознанное решение, а не сбой

Метрики не говорят нам, что «сломалось». Они помогают понять, что нужно изменить в системе.

Разговор с клиентом о широких коридорах

Один из самых частых практических вопросов: как объяснить клиенту, что коридор деливери стал шире?

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

Что не сработало — и что я из этого вынесла

Два момента, которые изменили то, как я думаю об этих метриках.

1) Ошибка с визуализацией, которая стоила нам доверия команды.

Когда я впервые запустила estimation accuracy, я раскрасила результаты интуитивно: зелёным — задачи, выполненные быстрее оценки, жёлтым — точное попадание в 100%, красным — превышение. Мне такое распределение казалось логичным.

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

Но главная проблема была в другом: мы целились в 70-80% попаданий, а не в 100%. 100% точность — это сигнал тревоги (чрезмерные буферы), а не успех. Когда художник делал задачу точно в оценку и видел жёлтый — у него случался когнитивный коллапс. Он сделал всё правильно, а система говорит «осторожно».

Мы переделали визуализацию полностью: зелёным стало попадание в коридор (например, 80–120% от оценки), синим — выполнение быстрее коридора, красным — выход за верхнюю границу. Жёлтого не осталось вовсе. И отдельно — график процента попаданий по периодам, где целевая зона явно обозначена как 70–80%, а не 100%.

После этого разговоры с командой изменились. Метрика перестала восприниматься как оценка людей.

2) Когда estimation accuracy выглядела нормально, но система ощущалась нестабильной. Именно тогда мы добавили variability и volatility. Оказалось, что стабильный процент попаданий может маскировать хаос на входе, просто потому что команда адаптируется к нему молча, за счёт сверхурочных и срезанных углов.

Как внедрить: практика

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

С чего начинать

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

Первый разговор с лидами я строила не вокруг «давайте внедрим метрику», а вокруг вопроса: «Как мы сейчас понимаем, что план реалистичен?» Обычно выяснялось, что никак и скорее интуитивно. Estimation accuracy стала ответом на этот вопрос, а не новым требованием сверху.

Кто и что делает

Лид выставляет сложность задачи (low / medium / high) при распределении и анализе ТЗ. Это происходит до старта задачи — как часть обычного планирования, а не отдельный процесс. Лид лучше всего понимает природу задачи: насколько чёткий бриф, есть ли зависимости от клиента, насколько знаком пайплайн.

PM забирает данные из Jira через фильтры, обрабатывает в Google Sheets и обновляет дашборд статистики раз в месяц. Анализ трендов происходит раз в 3-6 месяцев, в зависимости от того, насколько стабильна система. Если что-то начинает меняться — смотрим чаще.

Как технически устроен сбор

Никакой магии: фильтры в Jira по периоду, выгрузка в таблицу, формулы в Google Sheets. Для estimation accuracy нужны два поля — плановое время и фактическое. Для complexity — кастомное поле в задаче, которое заполняет лид. Для variability и volatility достаточно тегов типа задачи и данных о входящем объёме за период.

Дашборд состоит из трёх уровней.

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

Уровень тасков — детализация по каждой задаче: тип, сложность (complexity), estimation, фактическое время и diff. Здесь видно, какие конкретно задачи выбиваются из коридора и есть ли паттерн — например, все промахи на задачах с complexity 3 или на конкретном типе.

Уровень сабтасков — разбивка по стадиям (Proto, Highpoly, Lowpoly+Bake, Textures) с цветовой индикацией попадания. Этот уровень нужен реже, но помогает понять, на какой именно стадии производства возникает неопределённость.

Первые два месяца это занимало около двух часов в месяц. Когда шаблон устоялся — меньше часа.

Как вводить метрики без потери доверия

Начинайте с объяснения, зачем. Не «мы будем трекать точность оценок», а «мы хотим понимать, где в системе растёт неопределённость, чтобы реагировать заранее, а не постфактум». Разница в формулировке меняет восприятие.

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

Никогда не используйте метрики для сравнения людей или команд. Это правило без исключений. Как только цифра начинает использоваться как KPI — она перестаёт быть навигационным инструментом и становится источником защитного поведения.

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

Итог: метрика работает, когда команда сама её запрашивает

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

После нескольких месяцев работы с estimation accuracy лиды сами попросили добавить параметры. Сначала — посмотреть на корреляцию точности со сложностью задачи. Потом — отслеживать изменения микса. Метрика перестала быть «моей» и стала частью общего языка принятия решений.

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

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