Вступление
Начиная писать данную статью, меня не покидало ощущение, что я открываю «Ящик Пандоры». Холивар. Так как ну кто признается, что он плохой проектный менеджер? Кто скажет — я плохо управляю проектами? Ну я же… (дальше сами подставьте необходимый спич :-)
Тем не менее, в рамках управления рисками в GameDev данную область просто необходимо рассмотреть.
Большое количество игровых проектов терпят неудачу. Но что, если это не вопрос удачи, а следствие ошибок управления, рисков, не выявленных вовремя, или выявленных, но оставленных без должного внимания? Провал игрового проекта — это чаще всего не случайность.
Почему я разбираю провалы? Потому что успех игрового проекта часто уникален, а ошибки — типичны. Я публично веду исследование и собираю статистику причин провалов игровых проектов.
Я — Максим Торнов. Более 15 лет я помогаю компаниям видеть и управлять рисками до того, как они приведут к вредным для людей и компаний последствиям. Моя профессиональная сфера — управление рисками и операционная эффективность.
Данная статья является продолжением цикла моих статей об управлении рисками в индустрии GameDev. В этом цикле статей я переношу принципы корпоративного управления в контекст управления игровыми студиями и проектами, управления индустрией, которой я увлечен — индустрией GameDev.
Моя цель — дать вам не просто описание проблем, а инструменты для их диагностики. Каждая статья будет посвящена одному типу рисков: от управленческого до репутационного. Каждая статья — это разбор одного конкретного типа риска, его метрик и примера того, как он уже убил чей-то проект или навредил проекту.
Четкое понимание целей, целевого состояния проекта, продукта, позволяет лучше понять присущие риски. Эффективное управление рисками, дает конкурентное преимущество тому, кто знает, как управлять и эффективно этим пользуется.
В силу специфики своей деятельности, к управлению прое��тами я имею прямое отношение. Я 15+ лет управляю проектами, причем часть моих проектов — это проверка эффективности проектного управления, т.е. проверка того, как многие эффективные менеджеры эффективно управляют своими проектами.
Могу сказать, что за годы подобных проверок я редко встречал проектных менеджеров настолько эффективных, что их работой можно было бы восторгаться или брать за ориентир, пример для подражания или возможности, научиться чему-то, по настоящему уникальному и стоящему. Более того, единицы из них были сертифицированными проектными менеджерами.
Один мой знакомый разработчик, на мой вопрос: «А почему ты не пошел в GameDev?», из нескольких схожих причин, также емко сказал: «Там нужно постоянно работать на выходных».
Мы все часто слышали: «Нужно задержаться», «Нужно выйти в субботу», «Вся команда пашет, а ты домой собрался», «У нас дедлайн, нужно сделать и все», “It is the Crunch time, baby!” и т.д. в подобном ключе. Я сам, бывало, работал и по выходным, и до утра. Иногда это было дико интересно, а иногда у тебя был просто выбор - либо поработать как просят, либо уволиться.
Давайте разберемся, почему так происходит?
Проектное управление и как оно зарождалось
Генри Гант (1861–1919): Разработал диаграмму Ганта, которая позволяет менеджерам визуализировать задачи проекта, их продолжительность и взаимозависимости, а также разбивать крупные проекты на более мелкие, управляемые задачи.
Фредерик Тейлор (1856–1915): Опубликовал в 1911 году «Принципы научного управления», в которых основное внимание уделялось эффективности, методам экономии времени и разбивке задач для неквалифицированных рабочих, заложив основу для систематического управления.
Анри Файоль (1841–1925): Выделил пять основных функций управления (прогнозирование, планирование, организация, руководство, координация и контроль).
Вы наверное обратили внимание на появление весьма знакомых нам всем терминов, таких как:
Планирование
Задачи проекта
Продолжительность
Разбивка задач
Прогнозирование
Экономия времени
Организация
Руководство
Координация
Контроль
Да, мы все это слышали во время работы над проектами, во всех их возможных фазах.
Но сделаем шаг назад. Для эффективного управления проектными рисками, необходимо знать основы проектного управления. Для этого правильнее будет пройтись немного по теории.
Проектный менеджер
Кто это такой? Это роль? Это должность? Кого можно назвать Менеджером проектов?
Менеджер проекта — это человек, это профессионал, назначенный для руководства командой, управления ресурсами и контроля за планированием, выполнением и завершением проекта с целью достижения конкретных целей в рамках согласованных сроков и бюджета. По сути, он является «мини-генеральным директором» конкретного проекта.
Что отличает профессионала от непрофессионала? Обладание знанием методологии управления проектами, необходим опытом и контекстом, и другими навыками присущими управлению и коммуникации с людьми в командах. Умением системно применить свои знания и опыт.
Сертификации
Обратите внимание на термин профессионал. Это термин говорящий, что человек принадлежит и обладает компетенциями для возможности осуществлять профессиональную деятельность, в той области, где он осуществляет свою работу.
Т.е. человек подтвердил, что он обладает необходимыми теоретическими знаниями, методологией и опытом, для осуществления своей деятельности на должном, профессиональном уровне. Как это обычно происходит? Через специализированное, ПРОФЕССИОНАЛЬНОЕ образование и сертификации.
Три наиболее широко признанных сертификата в области управления проектами — это Project Management Professional (PMP), Certified Associate in Project Management (CAPM) и PRINCE2 Foundation/Practitioner. Эти сертификаты признаны во всем мире и подтверждают навыки управления проектами, от начального до опытного уровня.
Project Management Professional (PMP). У нескольких уважаемых мною коллег и друзей есть данная сертификация. Лучше всего подходит для: опытных менеджеров проектов, стремящихся подтвердить свою квалификацию. Этот сертификат, предлагаемый Институтом управления проектами (PMI), считается «золотым стандартом» в отрасли. Он охватывает традиционные (каскадные), гибкие и гибридные методологии, требуя обширного опыта работы над проектами и сдачи сложного экзамена.
Certified Associate in Project Management (CAPM). Лучше всего подходит для: Начинающих, менеджеров проектов начального уровня или членов команды. Этот сертификат, также предлагаемый PMI, идеально подходит для тех, кто имеет ограниченный опыт, но хочет начать карьеру в этой области или продемонстрировать понимание принципов управления проектами, служа ступенькой к получению PMP.
PRINCE2® Foundation/Practitioner. У меня есть данная сертификация и является на мой взгляд более предпочтительной относительно PMP, так как данный подход, в первую очередь, ориентирован на управление процессами, более структурирован, точнее определяет роли участников. Широко распространен в Европе и Австралии. Также применяется для работы в государственном секторе западных стран. Подход разделен на два уровня: Foundation (основы) и Practitioner (управление проектами с использованием этого метода).
Другие значимые сертификаты в области проектного управления:
Certified ScrumMaster (CSM): ориентирован на принципы и методологию Agile/Scrum, идеально подходит для менеджеров ИТ/программных проектов.
PMI-ACP (Agile Certified Practitioner): для тех, кто специализируется на управлении проектами по принципам, методологии Agile.
На мой взгляд, в современном мире, хорошо, когда совмещаются одна из первых трех методологий и одна из области Agile управления. И максимально плохо, когда управление проектами происходит интуитивно и несистемно, основываясь только на настроении, оценках, опыте, предпочтениях и мнении одной персоналии.
Что такое проект?
Данная статья не о том как управлять проектами. Данная статья о рисках проектного управления, а точнее о рисках проектного управления в области разработки игр, управления игровыми проектами.
До сих пор мы разобрали как зародилось проектное управление, кто такой проектный менеджер, как отличить профессионала от просто сотрудника со своим пониманием того, как управлять проектами. Теперь пришло время разобрать, что такое Проект.
Есть много определений проекта, но в целом наиболее точно определено тут.
Проект — это уникальная и временная организация, созданная для достижения ощутимого результата. Он имеет фиксированные — как правило, довольно короткие сроки, критерии достижения целевого результата в срок и в рамках бюджета.
От себя я бы еще добавил: В рамках управления проектом, проектный менеджер отвечает за эффективность проекта, направленную на достижение результата в срок, в рамках бюджета, с надлежащим качеством всех свойств итогового продукта проекта.
По моим личным наблюдениям, очень часто, плохое управление проектом, компенсируется нагрузкой на проектную команду. Плохое планирование, мониторинг прогресса, управление объемом, ожиданиями и качеством - напрямую влияют на уровень стресса команды и как следствие на итоговый результат. На основании проведенного мной анализа, подавляющее большинство провальных игровых проектов имели проблемы с проектным управлением.
Из чего состоит проект
Например, PRINCE2 определяет следующие свойства проекта:
Интегрированные элементы проекта
Люди
Контекст проекта
Принципы
Практики
Процессы
Целевые показатели эффективности проекта
Выгода и ценность
Затраты
Время и сроки
Качество
Объем работ
Устойчивость
Риски
Методы реализации и управления проектом
Традиционный каскадный подход (WaterFall)
Гибкий подход (Agile)
Гибридным подход, сочетающий линейно-последовательный, каскадный и итеративно-инкрементальный, гибкий подходы
Я лично предпочитаю №3, гибридный подход.
Управление проектом по созданию продукта (игры)
Говоря об индустрии GameDev мы в первую очередь говорим о продуктовом проектном управлении, что несколько отличается от классического проектного управления.
В рамках планирования проекта по созданию продукта, игры, на мой взгляд важно понимать контекст, а следовательно, понимать все свойства и характеристики продукта, т.е. его спецификацию.
PRINCE2 позволяет это учесть. Учитывая именно продуктовую специфику. В методологии спецификация продукта детализируется с помощью структурированного подхода, в частности, например, через фиксацию:
Описание продукта проекта: Подробное определение назначения, целей, состава, происхождения и критериев качества продукта. Определение конечного результата, включая ожидания владельца продукта в отношении его свойств и качества.
Критерии качества: Стандарты, которым должен соответствовать продукт, включая пределы, в которых продукт является приемлемым.
Включая системность в управлении:
Отчетность: Регулярные, привязанные ко времени отчеты для управляющего совета проекта о ходе выполнения целевых показателей.
Контрольные точки: Мониторинг и отчетность хода выполнения рабочих блоков/частей продукта.
Отклонения: Прогноз превышения согласованных уровней целевых показателей (например, стоимости или времени).
Это не реклама PRINCE2. Вы можете спокойно использовать ту методологию управления проектом, какую сочтете наиболее подходящей в вашем контексте и работе над игровым проектом.
Для меня, на основе моего опыта, на моих проектах я предпочитаю PRINCE2. Я просто считаю, что она наиболее гибко и удобно позволяет управлять проектами по созданию продуктов, включая создание игр, а следовательно, максимально эффективно позволяет управлять рисками выпуска игры - игрового продукта.
Например, PRINCE2 позволяет отслеживать переменные для измерения успеха, эффективности проекта, устанавливая для каждой из них метрики и допустимые отклонения:
Выгоды: Реализация запланированных улучшений.
Затраты: Фактические расходы по сравнению с бюджетом.
Сроки: Фактический прогресс по отношению к контрольным точкам графика.
Качество: Соблюдение критериев качества и стандартов производительности.
Объем работ: Конкретные, согласованные результаты (продукт и его элементы).
Устойчивость: Воздействие на команду, социальную сферу.
Риск: Вероятность и последствия потенциальных проблем и инцидентов.
В рамках управления разработкой вашей игры, управления вашим игровым проектом - какие управленческие метрики вы используете и отслеживаете? Как часто вы это делаете? Какова регулярность? Какие решения, как быстро и кто принимает? Что мешает, по вашему мнению, управлять проектом эффективно? Поделитесь, пожалуйста, в комментариях.
Я думаю достаточно теории. Более подробно о методологиях и подходах вы можете почитать по ссылкам:
Но вернемся к рискам присущим управлению игровым проектом. Риску срыва сроков, бюджета и выгорания команды.
Управление проектными рисками
Что такое проектный риск? Это потенциальная ситуация, которая может произойти в результате действия, бездействия, при которой цель, ожидаемый результат или целевое состояние не будут достигнуты.
Т.е. Риски присущие управлению проектами по созданию игр, это ситуации при которых не будут достигнуты цели таких проектов, например: не будет получена выгода и ценность от реализации игры, затраты превысят порог окупаемости, или никогда не окупятся, будут превышены запланированные сроки, а качество не будет соответствовать ожиданиям, объем работ увеличится и не будет реализован, игровую студию или команду покинут ключевые эксперты и разработчики, а студия закроется. Все это ��озможные последствия, в том числе и неграмотного проектного управления. Отсутствия понимания присущих рисков и эффективного управления ими.
Грамотное, системной управление проектом, позволяет снизить ситуацию неопределенности, вероятность возникновения рисков. Как обрести системность и грамотность управления игровым проектом? Об этом я рассказал выше.
Риски проектного управления в GameDev
Ну вот мы наконец и подошли к цели данной статьи - разобрать несколько ключевых рисков и метрик управления игровым проектом:
PM-31: Отклонение от плана по спринту (Sprint Burndown Deviation)
PM-32: Коэффициент добавления нового объема (Scope Creep Ratio)
PM-33: Скорость команды (Team Velocity) и ее волатильность
PM-34: Индекс удовлетворенности команды (Team Health Index)
Это определенно не исчерпывающий список. Тем не менее, на мой взгляд, это одни из ключевых рисков. Но перейдем к разбору каждого.
PM-31: Отклонение от плана по спринту (Sprint Burndown Deviation)
Риск: Постоянное недооценивание задач ведет к хроническому срыву спринтов, накоплению долга и потере доверия к планам.
Метрика: Отклонение фактических затрат (часов/story points) от запланированных в спринте, в %. Критический порог: Отклонение >20% в течение трех спринтов подряд.
Ранние индикаторы:
Для разработчика: К концу спринта >30% задач остаются в статусах «In Progress» или «To Do».
Общепринятая практика: Нарушение принципа устойчивого темпа (Sustainable Pace) из Agile Manifesto, когда команда регулярно перерабатывает для закрытия спринта.
Для руководителя: На ретроспективах основная тема — «почему не успели», а не «как улучшить продукт».
Экспертное мнение: График Burn-down Chart стабильно лежит над идеальной линией, что указывает на системную ошибку в планировании или скрытые трудозатраты (логика: если команда постоянно не успевает, план не отражает реальную сложность).
PM-32: Коэффициент добавления нового объема (Scope Creep Ratio)
Риск: Неконтролируемое расширение объема работ («расползание требований») ведет к срыву сроков, перегрузу команды и размыванию фокуса проекта.
Метрика: (Новые story points/часы, добавленные в спринт) / (Изначальный объем спринта) * 100%. Критический порог: Добавление >15% нового объема к утверждённому плану спринта.
Ранние индикаторы:
Для разработчика: В середине спринта появляются «срочные» мелкие задачи от продюсера или дизайнера, не связанные с целями спринта.
Общепринятая практика: Нарушение принципа «заморозки» объема спринта (Sprint Scope Freeze), одного из ключевых правил Scrum.
Для руководителя: В бэклоге продукта (Product Backlog) отсутствует четкий процесс приоритизации и утверждения новых элементов перед планированием спринта.
Экспертное мнение: Команда теряет ощущение завершенности, так как цели спринта постоянно смещаются, что ведет к демотивации (логика: невозможность достичь запланированного результата разрушает чувство прогресса).
PM-33: Скорость команды (Team Velocity) и ее волатильность
Риск: Резкие колебания или падение скорости команды указывают на скрытые проблемы (техдолг, выгорание, плохие оценки), что делает прогнозы ненадежными и угрожает релизному плану.
Метрика: Количество story points, завершаемых за спринт (Velocity). Волатильность — стандартное отклонение скорости за последние 6 спринтов. Критический порог: Падение скорости >25% от средней за 2 спринта подряд или волатильность >30%.
Ранние индикаторы:
Для разработчика: Команда начинает дробить или объединять story points в середине спринта, чтобы «подогнать» скорость.
Общепринятая практика: Нарушение принципа сравнимости story points в Scrum, где оценка относительна и стабильна, а не абсолютна.
Для руководителя: Прогнозы дат релиза, основанные на скорости, постоянно сдвигаются от спринта к спринту.
Экспертное мнение: Высокая волатильность скорости (>30%) делает метрику бесполезной для планирования, возвращая проект к управлению «по срокам, а не по объему» (логика: если скорость непредсказуема, любой план — это гадание).
PM-34: Индекс удовлетворенности команды (Team Health Index)
Риск: Низкая удовлетворенность или её резкое падение ведут к росту текучки, падению продуктивности, потере знаний и токсичной атмосфере.
Метрика: Средний балл анонимного опроса (1-5) по ключевым факторам: ясность видения, реалистичность сроков, поддержка, баланс нагрузки. Критический порог: Средний балл <3.5 или резкое падение (>0.5 балла) за один опрос.
Ранние индикаторы:
Для разработчика: На ретроспективах команда молчит или обсуждает только технические детали, избегая тем управления и атмосферы.
Общепринятая практика: Игнорирование принципа «индивидуалов и взаимодействий» над процессами и инструментами из Agile Manifesto, когда метрики ставятся выше морали.
Для руководителя: Ключевые специалисты начинают отказываться от неформального общения, участия в активностях или ищут задачи в одиночку.
Экспертное мнение: Падение индекса — это опережающий индикатор будущих проблем с качеством и сроками, так как демотивированная команда не может работать эффективно (логика: выгорание и недовольство всегда проявляются раньше, чем проваленные дедлайны).
Как я сказал ранее, это всего лишь пример, несколько рисков и метрик. В зависимости от контекста вашего игрового проекта, проекта по созданию продукта, всю совокупность рисков можно определить исходя из целей, которых вы хотите достичь, в рамках управления игровым проектом, созданием продукта.
Методология и системность управления рисками
Управление рисками, дает конкурентное преимущество тому, кто знает, как управлять и эффективно этим пользуется.
Таким образом, понимания то как управлять проектом и присущими проекту рисками, понимая цели и спецификацию конечного продукта, можно точнее определять сроки, объем и приоритеты работ, сохраняя тем самым фокус, здоровье и эффективность команды, чей заряд и мотивацию можно направить на реализацию интересных и уникальных механик, качественного игрового баланса, обеспечения техническое качество самой игры и как следствие увеличить шансы игрового проекта стать успешным.
Вы, наверное, задались вопросом, а что это за PM-31…34? Это ID рисков в методологии управления рисками в индустрии GameDev, которую я создал и развиваю, через разбор игровых провалов и анализ метрик управления игровыми и продуктовыми проектами.
Подписывайтесь на Telegram-канал - @GameDevRiskAdvisor. Сможете больше узнать о рисках, метриках и ранних индикаторах проблем, присущих игровым проектам в индустрии GameDev. На канале мы регулярно и кратко разбираем игровые провалы, риски, делимся рекомендациями.
Мнение и опыт
Поделитесь вашим мнением и опытом в комментариях. Как вы проходили кризисы в игродеве и как вы эти трудности преодолевали. Возможно, именно ваш опыт убережет коллег от "граблей" и потенциальных провалов.
Удачи в построении эффективных и устойчивых процессов.
С уважением,
Максим Торнов
P.S. Нет эта статья не была создана нейросетью. Если вы заметили опечатку или неточность, буду искренне благодарен за сообщение об этом в личные сообщения. Для более детального изучения темы приглашаю вас к моим другим публикациям и интервью в области корпоративного управления рисками и операционной эффективности:
Интервью
Статьи
