Методологии управления проектами, ч. 1
Многие из вас, конечно же, мечтают сделать собственную игру. Некоторые из многих даже обзавелись небольшой командой энтузиастов, которая готова заниматься разработкой вашей идеи. Но те из некоторых, кто реально хоть немного прикоснулся к процессу работы над игрой с нуля, уже, возможно, столкнулись с многочисленными сложностями, которые подстерегают геймдизайнера на каждом шагу. Дело в том, что геймдизайнер в небольшой команде во время разработки становится также и человеком, который управляет проектом и организовывает труд других людей. Но как это сделать, если зачастую даже свой собственный труд организовать довольно сложно? Часто можно столкнуться с тем, что схватиться хочется за все задачи сразу, или работа над задачами проекта откладывается на мифическое “завтра”, или же кто-то в команде простаивает без дела, а кто-то наоборот, по уши завален работой, которую и за месяц не закончить. Одним словом, не хватает какой-то системы.
.
Работа коллектива над каким-то общим делом невозможна без следующих вещей:
1) четкого планирования;
2) последовательности и итеративности процесса;
3) распределения задач согласно возможностям каждого члена команды;
4) согласованности и слаженности работы над задачами и самой команды;
5) анализа качества проделанной работы и выявления недочетов с их последующим устранением.
.
Звучит все это очень сложно. Но хорошая новость в том, что здесь не нужно изобретать велосипеды - все уже давно придумали за вас.
.
Существует целый ряд систем работы над проектами, каждая из которых имеет право на существование, потому что выбор системы зависит от целей, которые вы преследуете в процессе разработки и от типа продукта, который вы разрабатываете. Согласитесь, команда по разработке веб-сайтов и большой кондитерский комбинат не могут работать по одним и тем же принципам. Пробежимся по трем популярным системам, которые я попыталась раскрыть с точки зрения геймдизайна. Каждая из этих систем представляет свой подход к управлению проектом.
.
.
1. Классический “водопадный” менеджмент.
.
Он называется так потому, что этапы разработки в рамках данного подхода идут ступеньками, каскадами, где один этап работы плавно перетекает в другой. То есть:
- сначала вы определяетесь с идеей игры и вырабатываете требования к ней;
- далее следует этап проектирования - написания документации и требований для программистов и художников;
- третьим этапом идет реализация ваших задокументированных требований;
- затем наступает процесс тестирования, поиска и фикса багов;
- и последний этап - поддержание проекта: добавление нового функционала и контента в игру.
.
.
Все это звучит довольно убедительно и логично, только название “водопад” эта система получила неспроста: переход на каждый новый этап предполагает полное завершение работы над предыдущим и возвращение, а также скачки с этапа на этап совершенно не предусмотрены в этой модели. Это лишает ее гибкости, которая так необходима геймдизайну с его вечными плейтестами и переделкой фич. Кому подойдет такая модель? Например, строительной компании: фундамент дома нельзя построить после остекления восемнадцатого этажа.
.
Итог:
Плюсы - последовательность.
Минусы - отсутствие гибкости.
.
.
2. Kanban
.
Это слово японское, потому что придумали этот метод работы японцы на заводе Toyota. Метод заключается в трех основных принципах:
.
1) Визуализация рабочего процесса
Это ведение так называемой доски с задачами, отсортированными по приоритету. Далее карточка может проходить несколько итераций работы, кочуя из столбца в столбец.
.
2) Ограничение количества задач в рамках одной итерации
Одновременно в работу в рамках каждой итерации разрешается брать только определенное количество задач, заранее установленное руководителем проекта. Самое удивительное, что не существует сроков для выполнения одной задачи, никто не рассчитывает и не прогнозирует время на задачу, руководитель просто ставит задачи в порядке приоритетности, а сотрудники стараются сделать как можно больше. В качестве регулирования здесь выступает принцип команды: если в столбце для тестировщиков максимум может быть 5 карточек, то программисту уже не перенести туда шестую - столбец забит. Значит, есть какая-то проблема с тестировщиками, и чтобы помочь, программист может взять на себя задачу из тестирования.
.
3) Оптимизация
Рабочий процесс по системе Kanban постоянно оптимизируется. Как в случае с примером из предыдущего пункта, скопление задач в итерации тестирования может быть сигналом о том, что отдел недостаточно укомплектован, или работу сотрудников нужно каким-то образом оптимизировать.
Все это здорово, но в данной методологии очень многое зависит от самой команды. Во-первых, они должны пересекаться ролями, чтобы поддерживать друг друга в выполнении задач, то есть, сотрудники должны быть относительно универсальными. Во-вторых, совершенное отсутствие ориентированности на временные рамки не предполагает работу в рамках дедлайна. В-третьих, очень многое здесь зависит от сознательности и мотивированности каждого конкретного сотрудника делать работу хорошо и быстро, потому как никакого контроля за эффективностью обработки задач выполнения нет.
.
Итог:
Плюсы: ориентированность на качественное выполнение задач.
Минусы: невозможно работать в условиях дедлайна.
.
.
3. Lean Six Sigma
.
Lean 6 sigma - это довольно сложная система, которую не описать в двух словах - за более подробными характеристиками лучше обратиться к другим источникам, я попробую лишь описать самые ключевые ее характеристики, которые могут найти применение в геймдеве. Итак, это система, объединенная из двух: системы Lean, известной как “бережливое производство”, ориентированной на сокращение финансовых и временных потерь в рамках рабочего процесса, и системы Six Sigma, или “шесть сигм”, предназначенной создать такой рабочий процесс, который постоянно улучшает и оптимизирует себя таким образом, чтобы не решать проблемы в рабочем процессе, а устранять их превентивно.
.
Так как сама система состоит из двух частей, в ней можно выделить два основных аспекта.
.
Аспект первый - бережливость принципа Lean
.
Определение того, что действительно важно для вашего проекта. Для того, чтобы понять, что является ценностью, определите несколько параметров, один из которых, или все одновременно должны быть в любом аспекте вашей игры. Например, во free-to-play проектах это монетизация (фича приносит прибыль), виральность (фича требует совместной с другими игроками игры) и ретеншен (фича заставляет игрока снова вернуться в игру). В текстовом квесте это может быть оценка с позиции сюжета. Например: а) фича раскрывает персонажа, б) фича раскрывает игровой мир, в) фича создает якорь для будущих игровых событий. Таким образом, все что кажется “просто прикольным”, или “а давайте добавим вот как у них” идет мимо кассы. Все добавляемые фичи должны проходить проверку на наличие ценности для самого проекта.
.
.
Второй аспект - совершенствование принципа Six Sigma.
.
Этот аспект скорее представляет собой не принцип, а алгоритм по выявлению проблемы и ее устранению с последующим изменением процесса работы таким образом, чтобы исключить саму возможность появления подобных проблем в будущем.
1) Определение основных проблем проекта. Здесь может быть сформирована команда, которая будет заниматься выявлением подобных проблем.
2) Сбор данных. На этом этапе собираются все данные по проекту, формируются тезисы и предположения о проблемах, существующих на проекте.
3) Поиск решения. Все измерения и предположения анализируются, проверяются на правильность и прочность, из них уже формируются четкие выводы.
4) Внедрение улучшения. Согласно сделанным выводам, принимаются меры по улучшению рабочего процесса, устранению обозначенных проблем.
5) Контроль процессов. Стандартизация рабочего процесса. Документирование и фиксирование выявленных в итоге предыдущих четырех этапов принципов, чтобы они в итоге превратились в правило, руководство к действию.
.
Что можно сказать про Lean Six Sigma в сфере геймдева? Этот метод является слишком сложным для маленьких команд, в нем многовато бюрократии и формальностей, а его безусловная “стандартизация” делает его менее гибким в условиях постоянно меняющихся требований к проекту.
.
Итог:
Плюсы: анализ процессов с целью их последующего улучшения.
Минусы: чрезмерно формализованный процесс, который перестает быть достаточно гибким.