Бывший сотрудник LucasArts об организации разработки, утренних стендапах и повышении эффективности

Независимый игровой разработчик Райан Дорси написал серию статей в которых ответил на вопросы по организации процесса разработки.

В первой заметке Райан рассказывает о расписании работы студии LucasArts, разрабатывавшей игру Star Wars: First Assault. Планирование спринта и как утренние стендапы могут серьёзно повысить эффективность всего процесса.

Редакция DTF публикует перевод первой части серии.

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

Статья не будет касаться спора, не будет приводить аргументов в пользу того или иного определения. Эта статья опишет моё личное представление, вдохновлённое Джеффом Моррисом, старшим продюсером Star Wars: First Assault. Он — настоящая легенда, его подход на световые года обошел методы других продюсеров, с которыми мне приходилось работать. Он высказал много важный вещей, но мой рассказ основывается именно на следующем:

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

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

Возможно вы сами должны этим заняться. Игра станет лучше примерно на 20 баллов на портале Metacritic. Грамотно организованный процесс разработки — причина, по которой вся команда ещё не выдохлась, не иссохла, мораль держится на высоком уровне, а каждый разработчик до сих пор каждый день уходит домой живым. Разработчики должны правильно расставлять приоритеты, чем обязан заниматься и продюсер.

Пришла пора поговорить о более конкретных вещах, а именно о дизайне ежедневного процесса разработки на примере игры Star Wars: First Assault.

К черту. Да, я сказал «Спринт». Можете называть его как вам хочется, но в том или ином виде им пользуются все.

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

Правильная оценка времени, необходимого на выполнение задачи — настоящее искусство. Я не хочу никого обидеть, но обычно инженеры самыми первыми говорят, что это вообще невозможно. Чушь. Каждый может спокойно достичь 80% точности, если будет следить за собой и стараться. Я видел примеры собственными глазами, поверьте, это правда. Мне удалось добраться примерно до 95% точности к концу разработки Star Wars: First Assault, потому что мы пытались научиться давать оценку.

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

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

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

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

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

Для большинства разработчиков в команде это обычный день работы по плану. А для лидов ударной группы (Strike Team — небольшая команда внутри проекта, состоящая из опытных разработчиков, специализирующихся в различных дисциплинах — прим. ред.) и руководителей каждого направления разработки — шанс оценить достигнутый за прошедшие две недели прогресс и изменить приоритеты на следующий спринт. Давайте я попробую привести конкретный пример того, чем занимался в качестве лида ударной группы.

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

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

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

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

1. Заблокировано: к этим задачам невозможно приступить, потому что для них чего-то не хватает. Либо не выполнена связанная задача, либо не решён технический вопрос.

2. Не начато: к этим задачам пока не приступили, но это возможно.

3. В прогрессе: над этими задачами ведётся активная работа.

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

5. Готово: эти задачи полностью прошли свой путь. Ура!

Каждой дисциплине был выделен собственный цветовой код на физической доске, а задачи, над которыми работал один и тот же человек, были сгруппированы вместе. Кроме того, они даже находились примерно на том же месте, чтобы никто не запутался. Небольшая деталь, но она позволяла сэкономить по 15-20 секунд на человека на каждом собрании.

Возможно, кто-то из вас сейчас подумал «А зачем вообще нужна физическая доска с заданиями? Почему нельзя просто присылать всем разработчикам информацию на компьютеры по почте или ещё как?» В общем-то, можно, но делать так — совсем не круто. Есть что-то очень приятное в том, чтобы перемещать реальные физические карточки по доске, отмечая выполненные задания. И, кроме того, каждое утро вы сможете видеть прекрасные лица людей, с которыми вы работаете. И тогда точно не забудете, что коллеги всегда готовы, если что, подставить плечо.

Как только карточки попадали в колонку «Ждут подтверждения», их забирал владелец задачи, чтобы лично удостовериться в исполнении. Затем возвращали нашему старшему продюсеру Джеффу, и уже он прикреплял их в соответствующую колонку.

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

Вообще, утренние собрания не должны происходить для всей команды за раз. Мы делили каждый стендап на две части: одна фокусировалась на разработке систем, вторая — на уровнях. Различных подходов может быть множество, и если вас терзают сомнения, не бойтесь экспериментировать. В самом лучшем случае, когда мы все старались, на 20 человек в общей сумме уходило всего пять минут. Джефф следил за временем, и каждый раз объявлял, сколько прошло, когда последний человек заканчивал говорить. И так каждый день.

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

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

А вот ещё две связанные и очень важные темы. Их я обязательно коснусь в третьей части.

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