В арт-аутсорсе часто возникает парадоксальная ситуация: проект формально растёт, показатели выглядят хорошо, команда справляется, но непонятно, насколько система устойчива и как долго выдержит текущий темп.
Когда я впервые столкнулась с этим, стало ясно: нам не хватает не процессов, а измеримости. Казалось бы - изучай, внедряй, пользуйся. Но в арт-аутсорсе ААА-тайтлов мы работаем с художниками, которые приходят делать качество, а не количество. А сами проекты зависят от клиента, арт-видения и постоянно меняющихся приоритетов.
На старте это выглядит так:
художники воспринимают любые цифры как попытку оцифровать творчество;
тимлиды опасаются, что показатели превратятся в KPI;
менеджер стоит по другую сторону - ему нужна прозрачность, потому что бизнес ждёт управляемый пайплайн.
Любое неосторожное "замеряем" разрушает доверие. Поэтому я искала способ внедрить метрики так, чтобы они стали инструментом навигации, а не контроля; и чтобы команда со временем сама начала ими пользоваться.
Постепенно из этого выросла система на четырёх показателях: estimation accuracy, task complexity, variability и volatility. В этой статье я разберу, как она устроена, какие сигналы даёт и как внедрить её без потери доверия команды.
Метрики не делают систему идеальной. Но правильно внедрённые, они делают её наблюдаемой, а значит, управляемой.
Контекст: почему аутсорс ААА тайтлов - особая среда
Геймдев аутсорс ААА тайтлов - это чаще производство арт-контента (персонажи, окружение, VFX, анимация) для крупных игровых студий. Несколько ключевых особенностей делают управление здесь нетривиальным:
Высокая вариативность задач: сегодня команда делает продакшн-ассет по чёткому брифу, завтра - эксплоративную работу с частично определённым стилем и несколькими раундами согласования с клиентом.
Волатильный входящий поток: приоритеты на клиентской стороне меняются, к плановым задачам добавляются срочные вставки, объём работы между периодами может отличаться на 30-40%.
IP-зависимость: многие задачи проходят через approval-лупы, которые не всегда предсказуемы по длительности.
В такой среде стандартные метрики "сдано/не сдано" дают мало сигналов для управления. Нужна другая логика.
Четыре метрики: что это и зачем
Прежде чем переходить к деталям - коротко про саму систему.
Estimation accuracy (точность оценок) - процент задач, которые попали в плановый коридор по времени. Показывает не то, насколько хорошо команда умеет оценивать, а насколько система в целом предсказуема.
Task complexity (сложность задачи) - уровень неопределённости на входе: насколько чёткий бриф, есть ли зависимости от клиента, знаком ли пайплайн. Не объём работы, а её природа.
Variability (изменчивость микса) - насколько сильно меняется состав типов задач от периода к периоду. Высокая variability означает, что система постоянно переключается между разными режимами работы.
Volatility (волатильность потока) - насколько сильно флуктуирует объём входящей работы. Отличается от variability: это не про типы задач, а про их количество.
Каждая из них по отдельности даёт частичную картину. Вместе они позволяют 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% эксплоративное | ~35% продакшн, ~40% правки, ~25% эксплоративное |
Предсказуемость | Высокая | Низкая |
На бумаге оба месяца "сбалансированы". На практике месяц Б сложнее планировать и прогнозировать - не из-за людей, а из-за структуры работы.
Как считаем
Мы отслеживаем распределение типов задач за период в процентах от общего объёма. Например: продакшн - 70%, правки - 20%, эксплоративное - 10%. Если в следующем периоде эти доли значительно смещаются, variability высокая - даже если общий объём часов тот же.
Никакой сложной математики: достаточно смотреть на изменение долей от периода к периоду. Устойчивое смещение на 15-20% в одном из типов - уже повод обратить внимание.
Когда variability растёт, реакция - не "попросить команду точнее оценивать", а изменение операционной логики:
Группировать похожие задачи, чтобы сократить переключение контекста
Защищать часть команды от нестабильного входящего потока
Закладывать более широкие коридоры на период с высоким миксом
Шаг четвёртый: volatility - волатильность входящего потока
Даже если мы понимаем сложность и следим за миксом задач, системы могут ощущаться нестабильными. Следующая причина - volatility.
Volatility - это не про типы задач. Это про то, насколько сильно флуктуирует объём входящей работы.
Можно иметь стабильную команду, знакомый микс задач и хорошие оценки, и всё равно терять предсказуемость, если количество входящих задач постоянно прыгает.
Пример
Период А | Период Б | |
|---|---|---|
Отклонение от плана | Небольшое, управляемое | +30-40% за счёт срочных вставок |
Режим работы | Проактивный | Реактивный |
В периоде Б ничего "не сломалось". Просто изменился объём входа - и это и есть volatility.
Как считаем
Volatility - это отклонение входящего объёма работы от среднего за последние N периодов. Например: если в среднем за квартал команда получает 200 задач в месяц, а в конкретном месяце пришло 280 - отклонение составляет +40%. Именно это число мы и отслеживаем в динамике. Резкий рост отклонения от периода к периоду - сигнал, что система переходит в реактивный режим.
Почему её часто неправильно диагностируют
Высокую volatility часто принимают за плохое планирование или низкую производительность команды. На практике система просто работает в нестабильных условиях входящего потока. Попытки "зафиксировать план" в такой среде, как правило, делают всё хуже.
Когда volatility растёт, мы не просим команду работать быстрее. Мы меняем режим работы системы:
Резервируем часть capacity под незапланированные задачи
Устанавливаем явные WIP-лимиты
Планируем с буферами вместо фиксированных обязательств
Заранее коммуницируем стейкхолдерам, что предсказуемость в этот период будет ниже
Как эти метрики работают вместе: реальный сценарий
Отдельно каждая метрика даёт частичную картину. Вместе они позволяют читать систему.
Ситуация: середина продакшна, деливери становится менее предсказуемым. Прогнозы не держатся, правочные итерации растут, дедлайны давят.
Что показывают метрики:
Метрика | Было | Стало | Что это значит |
|---|---|---|---|
Estimation accuracy | ~80-85% | ~60-65% | Растёт неопределённость, не падает исполнение |
Доля high-complexity задач | ~20-25% | ~40-50% | Оценки стали гипотезами, не обязательствами |
Variability | Низкая (~70% продакшн) | Высокая (продакшн + правки + эксплоративное) | Переключение контекста растёт |
Volatility | Стабильная | +30-45% от плана | Входящий поток нестабилен |
Что делаем:
Улучшать точность оценок здесь - не решение. Вместо этого мы перестраиваем систему:
Ограничиваем параллельное выполнение 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 лиды сами попросили добавить параметры. Сначала — посмотреть на корреляцию точности со сложностью задачи. Потом — отслеживать изменения микса. Метрика перестала быть «моей» и стала частью общего языка принятия решений.
Это и есть то, к чему я стремлюсь: не навязывать прозрачность как требование сверху, а проектировать системы, в которых прозрачность становится собственной потребностью команды.
Если вы работаете в геймдеве или смежных областях с высокой вариативностью задач — буду рада обсудить, как эти метрики работают в вашем контексте. В комментариях или напрямую.
