ААА – не только бюджет, но и длина твоего крика

В последние годы многие студии разработки пришли к выводу, что лучше фокусироваться не на fast delivery, т.е. желании выпустить игру на рынок побыстрее, а на качестве этой самой игры. Особенно это важно для крупнобюджетных проектов, которые в игровой индустрии принято называть “ААА” или Triple-A. В конце концов, как сказал один умный человек: “То, что вы сделаете быстро, также быстро забудут, а то что вы сделаете плохо – запомнят надолго”.

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

Времени стало больше, рук тоже, чего же тут плохого? В самой нацеленности на качество – ничего. Но люди – живые существа. Нам свойственна длительная адаптация. Когда команда приучена к одному подходу, а затем вводят другой – появляются когнитивные искажения и ложные динамические стереотипы, которые могут выстрелить в ногу, если вовремя их не адресовать. И тогда “ААА” будет не только обозначением класса нашей разработки, но и криком души, который будут издавать разработчики.

Всё это – риски, о которых мы поговорим подробнее ниже. Их можно условно разделить на две группы: со стороны руководителей и со стороны исполнителей. Поговорим сперва о первых.

Риски со стороны руководителей

Когда руководитель проекта слышит от высшего руководства “смените подход, нацельтесь на качество”, зачастую это может быть расшифровано как “старайтесь больше”, в то время как подразумевалось “аккуратнее принимайте решения”. А что делает человек, который думает, что мало старается? Правильно, вкладывает больше времени. В командной разработке это может вылиться в большее количество итераций и постоянно подвергание сомнению текущих решений. Постепенно это может выработать динамический стереотип вида: “Если мы вносим изменения, значит всё хорошо”. Но этот процесс не должен стать водоворотом, из которого невозможно выбраться. И тут мы подходим ко второму риску.

Казалось бы, я тут совместил две разные вещи. Да, именно так, но я это сделал потому что они выливаются в то, что в обоих случаях от руководства просто не поступает отмашки “молодцы, теперь это достаточно хорошо”. Почему такое может быть? Всё очень просто.

Когда один менеджер ставит другому какую-то абстрактную и, прямо скажем, недостижимую цель вида “добейся лучшего результата”, человек зачастую табуирует для себя возможность остановиться и сказать “good enough”. А секрет успеха не в том, чтобы запретить себе говорить “good enough”, а в том, чтобы чётко описать в каких условиях это будет озвучено. Тут может помочь понимание таких терминов из Agile практик как User Story и Definition of Done. Вот статья на русском.

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

Марк Черни ещё в 2002 году на D.I.C.E. Summit озвучил самые важные компоненты успешного игрового проекта: персонаж, камера, управление (англ. Three C’s: Character, Camera, Controls). Это то, что необходимо финализировать до разработки любого контента, эксплуатирующего нашего внутриигрового героя. Если вы начнёте производство, скажем, локаций параллельно с персонажем и будете их обновлять, когда появиться прыжок новой длины, новое оружие, возможность садиться в транспорт и т.д, – вы просто выбросите много денег на двойную работу.

Обратите внимание, что на GDC выступлениях, посвященных релизам студий Sony, даже на скриншотах самых ранних прототипов присутствует почти готовый персонаж. Это как раз следствие работы по Методу Черни.

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

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

В такие моменты важно включить критическое мышление и смотреть только на факты. Какую задачу вы решали изначально? Подходит ли вообще новое решение? Правда ли оно лучше? Остановившись и ответив на эти вопросы, можно прийти к выводу, что, вообще-то, вы просто сделаете фичу совсем другой. Она будет ни лучше, ни хуже. Это просто другая реализация. А если так, может и не стоит на неё тратить драгоценные ресурсы разработки?

Зачастую такие искажения могут ещё появиться из-за желания следовать трендам и смотреть “как делают все”. Или из стремления скопировать у лучших и подглядеть в каком-то конкретном успешном проекте, например, того же жанра или уровня графики.

Это настоящая классика. Когда я смотрю как стагнируют левел-дизайнеры при продумывании новых локаций, я объясняю им, что они пытаются одновременно делать две работы: дизайн и сборка. Сперва нужно сделать одно, потом другое. И именно в этом порядке: придумали, потом собрали. В продакшене то же самое. Часто задачи настолько крупные, что они зависают в бэклоге на одном статусе и перетекают из одного спринта в другой. Люди просто пытаются сделать много задач одновременно, при этом теряют понимание порядка действий. А могут вообще не браться, думая, что задача невыполнима.

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

Большее качество означает больший уровень ответственности, верно? Зачастую многие не выдерживают давления этого факта и у них это выливается в то, что они начинают излишне дотошно контролировать команду. Чаще спрашивают статус задач, генерируют искусственные кризисы в виде несуществующих показов игры инвесторам или платформодержателям, а иногда даже начинают говорить своим сотрудникам как лучше делать их работу.

Тут важно остановиться, выдохнуть и оценить, действительно вам нужно менять уровень контроля и собственной осведомленности о всевозможных мелочах. А знание всех промежуточных стадий этих мелочей для вас что-то меняет? Возможно и нет. Да, вам придётся тщательнее выбирать из существующих опций и, возможно, чаще спрашивать мнение внешних специалистов. Но коллги, которых вы нанимали в команду, не стали хуже. Им не нужен поводок или кандалы. Они не меньше вашего хотят сделать крутой продукт.

Про частые сборки билдов уточню отдельно. Я лично не раз видел, когда при стремлении к более высокому качеству сокращали промежутки времени между патчами и показами игры. У многих руководителей возникает идея, что так команда будет в тонусе. Логичное предположение, но часто неверное. Уверены ли вы, что до этого было хуже, потому что вы редко выкладывались? А может кто-то выгорел потому что это было слишком часто?

Тут я всегда советую плотнее пообщаться с отделом обеспечения этого самого качества, QA-специалистами. Они подскажут как добиться на вашем проекте снижения количества поломок. Возможно им как раз необходимы более редкие выкладки и больше времени на тесты. Главное не предполагайте, а проверяйте подобные вещи.

Звучит, казалось бы, прозаично. Чего тут такого? Да, у нас есть ведущий специалист в команде и он, помимо прочего, выполняет ручную работу, показывая примером, как надо это делать. Он же лучше других понимает, как это делать, верно?

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

И это самая большая проблема последних лет. Если человек продолжает щёлкать задачки своими руками, он не уделяет время решению проблем команды. А ведь именно это и есть основная функция лида в разработке. Случается такое по двум причинам: сотрудник сам не понимает изменение своих функций или же начальство продолжает требовать от лида ручную работу. Поскольку у нас раздел с заметками для руководителей, просто обозначу, что крайне рекомендую отделить мух от котлет лидов от исполнителей.

А если уж лид ну очень хочет продолжить что-то делать руками, а не только коммуницировать, направьте его амбиции на обучение тиммейтов. Это принесёт куда больше пользы, т.к. мидлам и синьорам ещё есть что доказывать на этом поприще, а лидам – нет. А вот как раз оценку сроков, костов и реализуемости фичей стоит оставить исключительно на лида. Исполнители могут легко (и незаметно для руководства) гореть от того, что их просят не только выполнять задачи, но и оценивать их сверху. Это две разных функции.

Если первая глава статьи была про риски и совета “сверху”, то текущий блок будет скорее универсальным. Его можно применить на всех уровнях иерархии. Начнём с пары пунктов про психологическое здоровье.

Я часто наблюдал, когда люди на проекте были чем-то недовольны, но не понимали чем именно, а главное – почему. При этом абсолютно все всегда пытаются мужественно “разобраться сами”. Но если у вас нет психологического образования, это будет затруднительно, каким бы эрудированным и опытным ни были. Чем может быть чревато то, что мы пытаемся сами разбираться в чердаке своего сознания? Приведу пример из личного опыта.

Однажды, на одном из проектов, на которых я работал, став лидом, я столкнулся с огромным количеством коммуникации. И это мне казалось важным. Иногда я успевал погасить в самом начале какие-то излишне амбициозные идеи, которые могли сломать много игровых систем, а в каких-то моментах мне удавалось дать фидбек тим-мейтам. В какой-то момент я получил претензию по поводу того, что я мало сделал руками (и это проблема, см. “Риск 1.7”). Я получил фидбек, что “меня недостаточно”, я понял что что-то делаю не так по мнению начальства и тут, скорее всего проблема была именно в прозрачности коммуникации, она была недостаточной.

Но что произошло дальше? Мы созвонились с продюсером, обсудить текущее положение вещей и я… к великому стыду, наорал на него. На собственного руководителя. Почему? Я чувствовал растущий негатив внутри после того, как понял, что что-то делаю не так. Но я не понимал суть проблемы и способы решения. А тут ещё добавился тайм-прессинг в виде ограниченного времени звонка и я сорвался. Звучит где-то даже глупо и не взросло, но этого всего можно было избежать, если бы я просто обратился к психологу. Подобные вещи можно решить за 1-2 сеанса. Это позволит сберечь нервы ваших коллег и вас лично, а заодно сохранит ваш имидж.

В обязанности сотрудника входит не только выполнение задач, но и поддержание себя в работоспособном состоянии. Если младшие сотрудники ещё не понимают как этого добиться и ими занимаются лиды, то остальным грейдам, как правило, уже дают более гибкий подход к графику. И этот гибкий график не означает “лежу в ванной пол дня, а потом работаю пол ночи”. Напротив, вам нужно понимать как эффективно помочь команде разрабатывать продукт. Для этого полезно приучить себя эффективно использовать часы в рамках рабочего графика. Как это сделать?

Во-первых, вовремя оставлять работу в рамках графика и приходить домой вовремя. Или вставать из-за компьютера и присоединяться к семейной трапезе, если работаете удалённо. Для этого достаточно помнить (а может и обсудить с психологом), что вне работы есть близкие вам люди, которые вас ждут. Вы им нужны, это важно.

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

В-третьих, в уходе вовремя есть довольно неочевидный воспитательный процесс. Когда разработчик переживает, что мало сделал за день и остаётся кранчить, всё, что он по факту делает для себя это даёт понять, что ничего страшного не произошло, что “ничего не сделать, а потом переработать – норма”. Подводный камень тут в том, что с такой моделью поведения ваши переработки будут только расти, а умение эффективно распоряжаться рабочим временем – падать. Это путь вникуда. Если вы хотите сломать этот тренд, покажите самому себе, что за неэффективный рабочий день есть реальный штраф – невозможность это возместить в тот же день. Да, вам будет неприятно, пока вы с этим сталкиваетесь. Но на следующее утро у вас будет внутри чёткая устновка: “Если я не воспользуюсь рабочими часами, вечером мне будет неприятно как вчера”. Работает как часы. Пробуйте.

Фух, это получился самый большой раздел. Думаю, это правильно, т.к. он, на мой взгляд, самый важный. В завершение хочется добавить, что эффективная работа не означает бурную деятельность в каждый момент времени. Это означает выполнение задач в срок. Если вы можете сделать задачу быстрее в два раза, если сейчас возьмёте паузу в час – попробуйте. Аналогичный подход в спорте (VILPA) может снизить вероятность рака, если верить недавним исследованиям. Уверен, что в работе подобное будет иметь, если не такой же, то, как минимум, положительный эффект. 

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

Что с этим можно сделать? На старую документацию и правда стоит посмотреть. Полные атавизмы можно безжалостно удалить, чтобы они не давили на команду одним своим существованием (ну или выгрузите эти доки в PR для съёмки дневников разработчиков). А ещё хоть сколько-то “живые” документы стоит обновить и, главное, сделать читаемыми. С гиперссылками на разделы, хорошим шрифтом, удобной вёрсткой, иллюстрациями и пр.

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

Я лично когда-то вёл целый проект так, что у нас были by the book расписанные agile-задачи и по ним было легко найти любую информацию о сделанных фичах. Да, в таком подходе можно сократить много документации. Но подобная крайность подходит не всем. Если проект не эталон SCRUM или прочей гибкой методики разработки, а лишь заимствует оттуда части, то лучше задуматься о классическом ведении хотя бы ГДД, гейм-дизайн документов.

Суть очень простая. Когда разработчик берёт задачу, в ней может быть даже подробное ТЗ в рамках этой одной задачи. Но если есть вопрос “а что вообще было нужно” или “а как планировалось по дизайн”, то нужна уже ссылка на ГДД, который поддерживается в актуальном состоянии назначенным на фичу дизайнером. Кто-то, вообще, вместо ТЗ даёт ссылку на ГДД и пишет “сделать по описанию в документе”. Такое можно себе позволить, если ГДД расписан очень подробно.

Зачем ещё это нужно? В целом, для того, чтобы вы всегда могли найти описание дизайна вашей игры в одном месте, где будет куда меньше сущностей, чем в таск-менеджере с десятками тысяч тикетов. Пусть у вас будет отдельная внутренняя онлайн библиотека со всеми ГДД. Это сильно упростит жизнь на всех этапах разработки, а особенно на пост-продакшене, когда хочется что-то улучшить, но легко можно сломать, т.к. “никто уже не помнит как хотели сделать” или “никто не помнит, почему оно так реализовано”.

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

Может, вам для комфортного ведения задач не хватает дополнительного уровня вложенности в таск-менеджере? Или нет удобной утилиты для оценки задач? Не куплены лицензии на какой-то софт или слишком загружен тим-мейт и нужны дополнительные спецы? Самое время озвучить это. Начальство – не небожители, им просто может быть невидно то, что видите вы. Пытайтесь решить проблемы словами через рот. Увидите, вам пойдут на встречу.

Это куда более частая проблема, чем может показаться, несмотря на то, что звучит она гротескно и даже нелепо. Смотреть нужно в первую очередь на конфликты. Не оскорбления или наезды (этим стоит заняться отдельно), а несогласие по реализации тех или иных фичей. В таких случаях, кто-то может воспринять коллегу с противоположным мнением как человека, просто не желающего делать новую фичу. Он что, не хочет сделать игру лучше? Просто выпустит середнячок и забьёт?

Нет, на проекте нет злодеев. Никто не хочет выпустить плохую игру. Это никому не выгодно. Если вы отловили такое когнитивное искажение за собой или коллегой, попробуйте решить это открытым диалогом, без повышения голоса и обид. Опирайтесь на факты и спросите мнение своего лида. А если с точки зрения процессов, логически, вы всё решили, но всё ещё испытываете негатив, возможно, самое время обратиться к психологу. Помните, это не что-то плохое и это не ставит на вас клеймо. Кроме клейма осмысленного взрослого человека, занимающегося своим здоровьем.

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

Важно осознавать то, что, если вы видите проблему, но принимать по ней решение не вам, то ваша задача – озвучить своё наблюдение, а не достать своего руководителя. Заметили что-то важное? Это срочно надо адресовать? Скажите об этом. Но решение оставьте тому, кто это решение примет. Ваша задача выполнена. Иначе вы просто можете испортить отношения с коллегами в стремлении сделать лучше.

Во-вторых, задача профессионального разработчика не в том, чтобы продавить конкретную реализацию конкретной фичи в проекте, а в том, чтобы грамотно провести процесс её разработки. Грамотное итерирование. Без конфликтов, перехода на личности и с возможностью услышать друг друга. Да, конечно, будут вещи, которые вам покажутся истиной в последней инстанции. Да, их захочется довести до конца без изменений. Но если вы работаете командой, эту команду надо слышать. Иногда придётся от своих решений отказываться. Это нормально.

***

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