Методология управляемого хаоса для разработки проектов

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

Именно поэтому постепенно выделился отдельный термин — управляемый хаос. Данная методика является гибридной и основная ее цель — эффективное построение работы компании в условиях СНГ рынка.

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

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

Ситуации, в которых традиционное распределение ресурсов эффективно

1. Проект крупный или на проект делается большая ставка

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

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

2. У компании есть стабильное финансирование и нет стимула к изменениям

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

3. Пул проектов строго ограничен их малым числом

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

4. Компания специализируется на крупных хардкорных проектах

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

5. Компания занимается аутсорс- или аутстаф-разработкой

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

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

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

Ситуации, в которых эффективен управляемый хаос

1. Многопроектность — основополагающая стратегия развития компании

В одном из своих многочисленных докладов CEO & Founder нашей компании Михаил Харьковский рассказывал о том, что такое многопроектность, в чем ее преимущества и недостатки. Посмотреть его можно на главной странице компании CCSoft, либо на youtube канале компании CCSoft. Он рассматривал многопроектность с точки зрения глобальной стратегии развития компании, а в данной статье мы плотно соприкасаемся с многопроектностью и рассматриваем методику построения рабочих процессов и управления компанией при многопроектности.

2. Компания занимается разработкой собственных проектов

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

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

3. Компания специализируется на казуальных или мидкорных проектах

Этот пункт не аксиома, но существенно облегчит имплементацию рассматриваемой методики.

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

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

В чем суть управляемого хаоса?

1. Позволяет запускать множество проектов одновременно при минимальных ресурсных затратах на этапе старта работ

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

2. Позволяет максимально оптимизировать ресурсы

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

3. Позволяет быстро перекидывать ресурсы с проекта на проект

Зачастую те же аутсорс работы нельзя запланировать (вы никогда не знаете сроки, в которые потенциальный заказчик сделает заказ), да и быстро он не запускается (вы никогда не знаете, когда заказчик примет окончательное решение и даст отмашку на старт разработки). Именно поэтому старт таких работ достаточно хаотичен и под него нужно подстраиваться (мы не берем в учет случаи запланированного аутсорса, т.е. долгого и стабильного сотрудничества, когда все уже предсказуемо и понятно). И чтобы грамотно запускать\останавливать процессы разработки, вы должны быть готовы к гибкости.

4. Появляется готовность к любой разработке

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

5. Позволяет быстро расширять свой бизнес

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

6. Позволяет варьировать направления развития компании

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

Преимущества управляемого хаоса

1. Экономия ресурсов разработки

Когда разработчик работает в одном проекте, неизбежно у него появляются временные простои, связанные с ожиданием прогресса от другого специалиста (например, программист ждет графику от дизайнера). Если же девелопер переключается между проектами — это экономит деньги за счет отсутствия простоя в работе.

2. Грамотное распределение ресурсов

Распределяя ресурсы, вы всегда имеете возможность оптимизировать их. Допустим, для отрисовки UI в казуальные и мидкорные проекты не всегда нужен сильный художник. Зачастую достаточно посадить на две-три недели квалифицированного артиста UI, который отрисует концепт главных интерфейсов и 2-3 второстепенных окна, а затем заменить его на джуниора или более другого дизайнера (“технаря”), который не рисует концепты, зато хорошо делает методичную нудную работу вроде сборки интерфейсов на основе уже готовых концептов и макетов.

3. Более низкий бюджет на разработку всех проектов

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

4. Экономически выгодные предложения для партнеров

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

5. Возможность запускать больше проектов

Если у вас есть свободный ресурс, почему бы не начать делать новую работу? Например, у вас освободились дизайнеры — начинайте рисовать концепты для новых проектов. И, как уже было сказано, не обязательно полноценно запускать проект! Можно, например, сначала отрисовать графику, а через два месяца начать делать код. Либо наоборот, сначала делать код на заглушках, а затем уже привлечь дизайнеров к процессу разработки.

6. Упрощенное планирование работы компании

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

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

Очень важный пункт. Проблема многих разработчиков в том, что они годами сидят на 1-2 проектах, поэтому опыт их работы довольно ограничен. Если же разработчик постоянно переключается между проектами, он получает больше опыта работы в разных проектах, жанрах и направлениях. И важно соблюдать адекватность степени перехода между проектами: девелопер не должен “прыгать” туда-сюда по десятку проектов; он должен “ходить” между двумя-тремя проектами, и как только заканчивается один, взамен ему дается другой. То есть общий пул его задач должен быть ограничен таким числом, которое дает определенную нагрузку на разных задачах. Но стек его задач не должен быть непосильным, а переключение между проектами не должно забирать много времени и моральных сил. Поначалу будет тяжело, но постепенно девелоперы привыкают к такому режиму работы. Это лишь вопрос привычки.

8. Возможность “заткнуть” слабые места в команде компании

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

Факторы, которые позволяют управлять хаосом

1. Четкое планирование проектов и ресурсов на них

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

2. Своевременное выполнение задач на всех стадиях разработки и, как следствие, своевременное освобождение ресурсов

Нужно не только грамотно расписать задачи на бумаге, но и вовремя их выполнить. Это означает, что нужно постоянно отслеживать прогресс по работе (или иметь добросовестных сотрудников и ответственных тим лидов), и вовремя реагировать на задержки. Предсказывать их, устранять, чтобы не ломать общие планы.

3. Квалификация руководящего звена, от СЕО до тим лидов

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

4. Понимание сути стоящих задач

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

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

5. Единая стандартизация процессов разработки внутри компании

Чтобы упростить процесс “ходьбы” с проекта на проект и максимально сократить время “входа” в проект для любого разработчика, необходимо стандартизировать процессы разработки внутри компании. Нужно понимать, что если у вас игры на Flash, то все должны писать, допустим, на чистом флеше или на одинаковых фреймворках. Не должно быть такого, что кто-то из девелоперов предпочитает PureMVC, кто-то Robotlegs, а кто-то вообще “пилит” собственный движок. И в итоге, чтобы войти в проект на собственном движке, любому из сторонних программистов понадобится лишнее время. В таких условиях говорить о безболезненной “переброске” ресурсов очень сложно.

6. “Подушка безопасности”

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

7. Необходимы гарантии, что сотрудники не уволятся за короткий период

Жизненно важно иметь гарантии того, что вы не потеряете сотрудника на середине разработки, ведь из-за этого сломается вся цепочка из текущих и будущих задач. Каким образом их получить? Легко: начиная от подписанных контрактов, по которым сотрудник обязуется отработать N времени именно в вашей компании, и заканчивая личными договоренностями, если вы работаете в компании друзей. Есть и другие многочисленные варианты, наверняка у вас будет свое решение данного вопроса. Основная мысль в том, что, имея такие гарантии, можно не бояться строить планы наперед. И если вдруг сотрудник решит уволиться, у вас будет достаточно времени для его полноценной замены.

Недостатки и “узкие места” управляемого хаоса

1. Сроки разработки могут растягиваться

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

2. Недостаточная квалификация разработчиков

Если уровень разработчиков недостаточен, стек их задач постепенно заполняется и появляются накладки по задачам. Отсюда начинаются опоздания по срокам и все вытекающие проблемы.

Этот риск устраняется:

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

3. Неправильное планирование разработки

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

4. Вероятность из управляемого хаоса перейти к неуправляемому

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

5. Зависимость от множества факторов и специфичность самой методологии

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

6. Иные риски и подводные камни

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

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

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