Как выжить малыми силами

Страница 1 из 2

Об авторе


Азаров Сергей — в игровой индустрии с 2003 года, работал в компаниях Destiny Games и Step Creative Group, с 2006 года являюсь сотрудником «Нового Диска». В настоящее время занимаю позицию team leader'а, программиста Unity3D, ведущего гейм-дизайнера и технического аналитика.

Введение


Я думаю, напоминать о событиях 2008 года нет смысла, отмечу лишь, что для нашей команды, как в целом и для других, он оказался стрессовым. Конечно, большая финансовая подушка компании позволила его преодолеть без сильных потрясений, однако, следующий за ним год изменил наше положение в корне. Закрытие не перспективных проектов, поиск новых, отказ от разработки собственного инструментария и game engine. Из этой ситуации нужно было выходить. Нашим спасением стал Unity3D и неожиданный проект на тему музыкального бренда «Ранетки» - «мы выживали как могли».

Для помнящих, что такое Unity3D версии 2.1+, пояснять не надо с чем мы столкнулись, особенно если учесть, что все элементы игры мы писали без использования сторонних плагинов, включая GUI. В таких вот условиях мы подошли к середине лета 2009 года, кризис и падение экономики были в самом разгаре, наша разработка тормозилась, эффективность была хуже некуда, а сроки выпуска проекта приближались и грозили накрыть нас с головой. Закрывать на это глаза было уже невозможно, надо было что-то менять и менять радикально и кардинально.

Революция


Предпосылки изменений в системе трудовых взаимоотношений были заложены еще во времена работы в Step Creative Group, когда системный программист иногда отпрашивался работать дома с целью быстрее закончить особо важный элемент кода, что, соответственно приносило положительный результат. Однако, это было скорее исключением, чем системной закономерностью и было связано с жесткими дедлайнами в условиях ограниченного бюджета. В «Новом Диске» условия были комфортнее, а сроки разработки демократичнее и без овертаймов. Однако 2009 год все изменил. И то, что бродило в умах на подсознательном уровне, переросло в конкретные революционные веяния. Боевых действий конечно не велось, но определенные требования был выдвинуты. Команда программистов из трех человек, чтобы успеть все сделать по проекту, предложила переход на удаленную форму работы, в противном случае она не гарантировала соблюдения сроков и качества результата, даже с учетом овертаймов, и как итог, возможно, даже будет вынуждена покинуть компанию. К чести нашего тогдашнего руководителя он был прогрессивных взглядов и сдался без сопротивления, однако, чтобы успокоить умы других, мы были вынуждены согласиться на одно условие - оплата труда должна быть сдельной (по факту выполненных задач). Оглядываясь назад, можно смело сказать - это было мудрое решение, которое позволило как оценить перспективы для руководства, так и переломить офисный образ мышления у сотрудников.

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

Итогом нашей революции стало увеличение реальной производительности почти в 2 раза. В среднем без каких либо особых моральных и физических потрясений каждый программист работал по 7-9 часов чистого времени, что ввиду сдельной оплаты выросло в увеличение зарплаты на 10-15%. Вдобавок к этому мы смогли закончить помимо основного проекта (Ранетки. Game Live) еще два оутсорс проекта. К сожалению, из-за конфликта ведущего программиста и ведущего художника, первый уволился, несмотря на то, что инициатором революции был именно он. Свою роль, конечно, сыграли и не отлаженные процессы контентного конвейера, которые, как мне кажется, позволили возникнуть конфликту. В результате роль ведущего пришлось брать на себя. Все задачи по программированию были перераспределены на двух человек. Через полгода работы, когда все проекты были сданы, а новые задачи еще не были утверждены руководство предложило нам окладный вариант оплаты труда с сохранением работы из дома. Так завершился первый шаг на нашем пути к созданию распределенной команды, эффективность которой, только зарождалась.

Становление


Несмотря на тот факт, что проект «Ранетки. Game Live» в целом, вопреки скептическому настрою к нему со стороны команды, окупился и даже принес прибыль, кардинально наше положение это не поменяло, потому что четкого видения куда двигаться не было. Однако, задатки все же стали проявляться, особенно с появлением в Unity поддержки Android и iOS. Направление мобильных (или мультиплатформенных) игр выглядело достаточно перспективно, тем не менее, оно не находило отклика у руководства, к тому же в разработке у нас был социальный проект для сетей FB, VK и т.п., который через длительное время разработки был закрыт из-за разногласий с правообладателем. Данное событие и факт неопределенности начал давить морально на людей в офисе, команда стала сокращаться в размерах и потери в контентном отделе стали влиять на скорость разработки, программисты значительно опережали появление графических материалов (художники работали в офисе), начались простои.

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

В качестве первого проекта было предложено несколько вариантов концептов, как с механиками, еще не представленными в AppStore и Google Play, так и более предсказуемыми в плане аудитории и перспектив. Руководством был выбран вариант аркадного файтинга, который мы назвали Cyber Fist.

Picture_1.jpg

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

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

Picture_2.jpg

Что это нам дало:
  • в плане взаимодействия все более или менее понятно, альтернативу Skype найти сложновато, касательно премиум-аккаунта, то он необходим для проведения обучающих тренингов по новым технологиям, инструментарию и т.п. с возможностью трансляции экрана нескольким пользователям, которые, в свою очередь, могут сделать видеозапись этого процесса.
  • Использование Redmine это вопрос соотношения возможностей и цены - он бесплатный и при этом достаточно удобен и прост в освоении. Однако, нам пришлось потрудиться, чтобы приучить людей правильно им пользоваться, выработать, что называется, рефлексы.
  • Unity3D как среда разработки это вопрос удобства с позиции написания кода, все-таки C# проще, нежели С++ (по крайней мере для нашей команды), к тому же к этому времени движок оброс огромным количеством сторонних плагинов, которые сильно облегчали жизнь, чем мы незамедлительно воспользовались.
  • Что касается системы контроля версий, то здесь вопрос предпочтений и привычек команды. Использовать можно что угодно. Мы работали и с SVN и пробовали UAS и GIT, разницы нет для маленькой команды. Главное, чтобы система контроля версий умела рассылать уведомления о действиях, совершенных в репозитарии.
Все вышеописанное это логическое развитие, которое в целом не было для нас чем-то неожиданным, введение этих элементов упростило жизнь, но прирост производительности все же был недостаточным. Наибольший результат нам дало изменение режима работы и смена методологии разработки.

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

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

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

В итоге, все вышеописанные действия, позволили нам достаточно быстро (для команды из семи человек) получить первую игровую демо-версию проекта (напомню, это был Cyber Fist). Однако, усилиями вышестоящего руководства, проект, задумываемый как аркадный файтинг с F2P бизнес-моделью, превратился в ММО проект с кланами, командными сетевыми боями и клиентами под Web, PC и две мобильные платформы (Android, iOS). Такие объемы маленькая команда уже не могла потянуть, а расширяться нам не давали, в итоге проект остановили.

Picture_3.jpg

Несмотря на то, что нам не дали довести проект до конца, работа над ним позволила вскрыть еще ряд проблем в организации нашего pipeline'а, а также осмыслить и выработать стратегию по их преодолению. Кульминацией этого стал следующий набор изменений и условий, которые мы посчитали и считаем необходимыми для эффективного функционирования распределенной команды:
  • Инструментарий разработки было решено перевести на систему All-in-One. Все операции с контентом, настройками проекта, созданием билдов, написанием игровой логики, балансировки и т.п. должны были делаться в одном месте, причем в максимально простом и удобном виде, исключающим монотонную рутину. Извне создавались только исходные материалы, текстуры, модели, звуки, видео.
  • Необходимо стимулировать профессиональный рост сотрудников, особенно, если они сами желают развиваться в определенной области. А чтобы этот рост не пропадал впустую нужно ставить перед людьми сложные цели, к которым они будут стремиться и закреплять полученные знания.
  • Доверие членам команды есть критичный аспект эффективности команды. Естественно, здесь имеется ввиду доверие к человеку, как к профессионалу. Каждый в зоне своей ответственности должен отвечать своим профессионализмом. Из доверия рождается уверенность, что поставленная задача будет выполнена наилучшим образом без перманентного контроля со стороны team leader'a.
  • В свете вышесказанного проистекает основа основ в любой маленькой команде - важны люди, а не процессы, инструментарий, или что-то другое. Люди есть основа успешности, а профессионалы своего дела, ценны несоизмеримо. Именно поэтому их должны ценить, а они должны знать, что их ценят, это стимулирует их на дальнейшие развитие. Правило все заменимы — не работает в условиях небольших команд.
  • Насколько бы не было сильно доверие сотрудникам в профессиональном плане, если не бросать вызов их способностям, они деградируют. Нужно стараться ставить людей в такие условия, чтобы их способности максимально раскрывались. Эффект от преодоления подобных препятствий огромный - резкий скачок производительности, и повышение удовольствия от процесса работы.
  • Нужно избавляться от рутины (цикличные повторяемые действия), либо сделать так, чтобы она занимала минимум времени, либо работа такого характера была максимально облегчена за счет инструментария. Конечно, полностью исключить такие процессы нельзя, особенно когда приходится разрабатывать серию однотипных продуктов, однако, неприятный эффект можно и нужно сгладить. Уменьшение рутины дает команде возможность поднять качество за счет высвобожденного времени.
  • Необходимо уменьшить коммуникации в промежутках между итерациями. Собственно отсюда и вытекает условие доверия сотрудникам как профессионалам. Вмешательство в процесс работы исполнителя до того, как он представит результаты итерации, должно быть минимальным. Если этого не получается и приходится часто обсуждать промежуточные результаты, это значит, что назрела системная проблема. Нужно дать людям работать. Профессионал в зоне своей ответственности сам поймет что плохо, а что хорошо, что изменить, а что оставить.
  • Нужно минимизировать или вовсе избавиться от ситуаций изменения условий задачи в процессе работ над итерацией. Любые изменения должны происходить либо до ее начала, либо по ее завершению. Люди негативно реагируют, когда посреди работы им говорят, что теперь у задачи другие требования, и все что было сделано ранее, не подходит. В этом свете прототипирование и грамотный pre-production занимают ключевую роль в разработке.
  • Исправление ошибок на этапе тестирования необходимо осуществлять порциями. Ввиду мультизадачности каждого из членов команды, если выплеснуть на них весь список багов сразу, можно прийти к ситуации переполнения буфера входящих задач, от которого изначально мы избавились введением итеративной разработки.
В определенной степени вышеописанное некоторым читателям может показаться повторением известных истин. Однако, все же лучше иметь возможность практического подтверждения, что это работает. Наша команда пришла к этому через тернии и определенное, в целом немалое, время. И мы твердо можем сказать, что да, это работает и работает эффективно. Доказательством этого стал наш следующий проект, который поставил нас в достаточно жесткие условия и потребовал от нас аккумуляции всех ресурсов, в том числе скрытых.
 
  стр. 1 из 2  

Copyright © 2017 ООО "ДТФ.РУ". Все права защищены.

Воспроизведение материалов или их частей в любом виде и форме без письменного согласия запрещено.

Замечания и предложения отправляйте через форму обратной связи.

Пользовательское соглашение