Оценка эффективности в GameDev: обычные подходы к оценке для необычных людей
Оценка эффективности сотрудников, создающих игры — особый вызов. Здесь в ежедневной работе переплетаются креативность художников, точность программистов, аналитическое мышление гейм-дизайнеров, оперативность продюсеров, гибкость тестировщиков, стратегическое видение маркетологов и внимание к деталям скрам-мастеров.
В таком разнообразии ролей важно найти способы измерять эффективность, не разрушая хрупкий баланс взаимодействий – ведь почти всегда мы имеем дело не с отдельными сотрудниками, а с кросс-функциональными командами, где важны и железная дисциплина, и скорость, и качество, и креативность одновременно, а нетерпимость к «bullshit» сочетается с высокой потребностью в конструктивной обратной связи.
Как создать критерии оценки, которые действительно заработают и не вызовут отторжения у команды? Делюсь опытом одного из проектов.
Шаг 1. Опрос менеджеров: собираем исходные данные
Первым этапом стало интервью с руководителями разных команд. Мы спрашивали у них просто и по-человечески:
- Вспомни человека, которого вся команда считает топ-перформером, чем он выделяется?
Что по твоему мнению отличает человека в роли Х, который круто работает, от человека того же уровня на той же роли, который работает хуже?
Подумай про офигенного коллегу из соседних команд (это может быть кто-то из функциональных команд или профи из другого проекта). Что именно позволяет тебе со стороны судить, что он крут?
Вспомни коллегу из другой команды, с кем соприкасался по работе, который, по твоему мнению, не дотягивает на текущей роли. Что именно заставляет тебя так думать?
Есть ли что-то, чего ты не встречал у коллег на роли Х, но всегда думал, что было бы круто, чтобы он это делал?
Что ты часто встречаешь у людей в этой роли, но думаешь, что эффективность была бы лучше без этого?
Подумай о тех ребятах, с которыми мы расстались. Какие именно факты помогли тебе принять это решение?
Например, для креативных команд ключевым критерием была скорость работы. «Тот, кто делает качественно, но медленно, хуже того, кто делает быстро, но не так качественно», «Топ-перформеры выполняют задачу быстрее, чем ожидается» — говорили менеджеры.
В то же время для технических ролей первостепенными оказались точность выполнения задач и умение работать с фидбеком: «Топовые сотрудники не просто реагируют на обратную связь, но и сами её запрашивают», «Если фидбека недостаточно, крутой специалист сам за ним придёт», «Хороший сотрудник быстро выдаёт правки и не сопротивляется им».
Мы также услышали, что успешные лидеры заряжают команды общей целью и готовы «держать руку на пульсе» ключевых событий проекта, что в дизайн-командах ценится баланс между вовлечённостью и ответственностью — когда сотрудники не боятся брать на себя крупные задачи, но также осознают продуктовый контекст и бизнес-цели, не имеют «розовых очков» по поводу разработки игр.
Встречались, конечно, и специфические критерии, релевантные не для всех специалистов, но значимые для конкретных менеджеров: умение дополнять ТЗ от себя в соответствии с общим стилем, самостоятельность и отсутствие запроса на частую обратную связь, умение прятать эмоции и сохранять ровную коммуникацию в любых обстоятельствах. И так далее.
Шаг 2. Моделирование критериев: превращаем идеи в рабочий инструмент
На основе собранных данных мы разработали прототипы общих критериев оценки — краткий и расширенный. Далее провели несколько сессий с участием команд, чтобы их протестировать. Здесь применялся метод когнитивной лаборатории: сотрудники, проводившие тестовую оценку, проговаривали все свои мысли вслух. Кроме того, мы предъявляли им разные шкалы оценки – числовые, буквенные или процентные.
Это позволило выявить узкие места и найти самый удобный для большинства способ заполнять оценочную форму, а также способствовало созданию доверия к будущей оценке – сотрудникам понравилось, что их мнением по, казалось бы, чисто техническим вопросам, искренне интересовались.
Вполне ожидаемо, что краткий перечень критериев набрал больше очков, чем расширенный – он, напротив, нередко вызывал раздражение и ощущение перегруженности деталями.
В итоге мы сократили перечень, оставив лишь самые значимые показатели — сроки, качество, объём задач для оценки результата, а также организацию работы, эффективную коммуникацию, командное взаимодействие, ответственность и продуктовое мышление для оценки поведения. Всё это — в таких формулировках, которые реально используются и не выглядят ни выхолощенными, ни бюрократичными, ни формальными.
Вот несколько примеров:
(+) Корректно оценивает время, необходимое для выполнения задач.
(+) Эффективно использует трекеры, фиксирует актуальный статус и прогресс по задачам.
(+) Работает с фидбеком: принимает, проактивно запрашивает и даёт фидбек.
(-) Берёт на себя больше задач, чем в состоянии выполнить.
(-) Допускает одни и те же ошибки.
(-) Замалчивает проблемы.
Шаг 3. Тестирование критериев: от теории к практике
После уточнения критериев мы провели их тестирование — то есть пробную оценку эффективности — в разных командах. Это помогло понять, какие показатели действительно работают, а какие нуждаются в доработке.
Шаг 4. Работа с отчетами: для сотрудников и менеджеров
Следующий шаг — тестирование форматов отчётов. Мы снова разрабатывали разные варианты: для сотрудников — более развёрнутые, для менеджеров — лаконичные сводки с ключевыми метриками.
Кроме того, мы уделили внимание тому, как команды будут использовать собранные данные. Обсуждали форматы mini check points, когда результаты оценки обсуждаются на коротких встречах в конце спринтов, и другие варианты отслеживания прогресса со стороны сотрудников и менеджеров.
Итог ожидаем – продуктовый подход работает везде!
Все этапы разработки — от первичного опроса менеджеров до внедрения — были выстроены по принципам продуктового подхода: гипотеза, тестирование, обратная связь, новая итерация.
Кажется, только так можно создавать инструменты оценки, которые окажутся действительно адаптированы под специфику GameDev.