В чем на самом деле проблемы игры «Смута»?
Игра «Смута» — это интересный кейс, мимо которого сложно пройти. О нем очень много говорят, но по большей части с позиции пользователей, потребителей конечного продукта. А давайте попробуем зайти за ширму и посмотреть на данный продукт со стороны команды, с точки зрения проектного/продуктового управления и оценить, что действительно получилось, что не получилось и как можно это исправить в будущих проектах или избежать в других командах и продуктах.
Краткая сводка информации, которую мне удалось узнать из открытых источников.
Компания «Cyberia Nova» выиграла на конкурсе проектов государственное финансирование в размере 490 млн. руб. или 5 млн. долларов (но это не точно). Проект длился 2 года. Команда под проект по большей части новая. Взаимодействие с аудиторией началось только за 6 месяцев до плановой даты релиза. До этого компания не выпускала крупных игр.
Что получилось на выходе с точки зрения пользователей.
Вкратце, замахнулись на Ghost of Tsushima, получилось подобие первого ведьмака. Если не обращать внимание на баги, игра получилась линейная, без открытого мира (как обещали), практически без точек интереса, с обилием диалогов и простой, однообразной боевкой и прокачкой (все это в сравнение с современными AAA играми). Но нужно отметить, что получилось хорошо — это отлично проработанные с исторической точки зрения костюмы и сеттинг
А теперь к сути
В чем же может быть причина неудачи игры «Смута»? Данный кейс можно рассматривать и как с точки зрения незрелости государственного аппарата в части понимания взаимодействия с it отраслью, и как недостаточное понимание/отсутствие опыта непосредственных руководителей проектов, руководителей компаний в разработке крупных проектов (проектов с большими бюджетами, командой и большим количеством заинтересованных лиц). Но обо всем по порядку.
Представьте такую ситуацию вы IT компания по разработке игр. Появляется возможность участия в конкурсе на государственный грант. Вы подаетесь и выигрываете. Возможно вы даже такого не ожидали. До этого вы пилили небольшие игры с командой из 5–10 человек, в своем сегменте были успешны, но не более того. И тут вам на голову сваливается огромный шанс и много денег. Собравшись с чувствами, вы готовите все наработки, представляете план, расписываете сроки и т.д. И все, на бумаге отлично получилось, все сроки прописаны, бюджет расписан, команда составлена (на бумаге), осталось дело за малым… Вроде да, но как бы нет.
И тут начинается самое интересное, сложное и для неопытных команд непонятное.
Что делать дальше? Дальше получив аванс, вы начинаете собирать большую команду для разработки игры. По примерной оценке, для разработки такой игры за два года необходимо от 20–30 человек. Это, например, 5 backend, 5 frontend, 2 devops, 4 тестировщика, 2 системных аналитика, 1 бизнес-аналитик, 1 администратор, 1 РП, 4 дизайнера, плюс консультанты и сценаристы. Команда разноплановая, разнонаправленная и самое главное НОВАЯ. Браться за амбициозный проект за такие короткие сроки с новой командой — это брать на себя риски того, что все может накрыться медным тазом просто из-за того, что команда не сработается. Вот эта первая проблема всего данного предприятия — новая команда.
При формировании новой команды необходимо понимать путь развития команды. Рассмотрим формирование команды по Такману. Он выделял 4 этапа развития команды:
Рабочая группа (forming) — новые люди, все на энтузиазме, готовые работать. Довольно высокая производительность за счет личных качеств
Псевдокоманда (storming) — начинается разлад и споры, за счет чего проседает продуктивность
Потенциальная команда (norming) — все притираются друг к другу, начинается взаимопомощь и поддержка. Продуктивность начинает расти
Эффективная команда (performing) — сплоченная группа, готовая встать горой за каждого члена команды, всегда поддержит и поможет, максимальная эффективность
В среднем уходит год для выхода на максимальную продуктивность. При планировании работ необходимо перезакладывать рассчитанную загрузку в 1,5–2 раза на первый год, чтобы понимать настоящие сроки разработки. Но многие почему-то игнорируют данный факт. Даже если мы набираем самых профессиональных и опытных сотрудников, эффективность взаимодействия их между собой в первый год будет довольно низкая, а денег уйдет на содержание такой команды довольно много.
Таким образом, во-первых, мы упираемся в неопытность руководства проектом/продуктом по управлению большими проектами, из-за чего часть функциональности, которую, казалось возможно реализовать за 2 года, не удалось реализовать. Т.о., если вы берете крупный проект и хотите под этого проект набрать команду, необходимо учитывать низкую эффективность команды в первый год работы, иначе вас потом притянут за все ваши обещания.
Неопытность в крупных проектах не позволяет с высокой точностью определить корректно сроки по реализации того или иного функционала.
Первый этап разработки программного обеспечения — это проектирование (я надеюсь он был в данном проекте). Он обычно начинается параллельно сбору команды. Команда формирует и детализирует требования к будущему продукту, описывает образ результата, оценивает трудозатраты по согласованному техническому заданию (ТЗ). Вот и первая сложность. Работая с государством, скорее всего, ты находишься в рамках ТЗ от и до. ТЗ на весь двухлетний продукт, и ты вынужден двигаться по водопадному подходу (waterfall) (когда сформировано полное ТЗ на продукт и тебе нужно выполнить все пункты ТЗ без возможности сделать шаг вправо или влево), так как 90% государственных проектом заточены именно на это, из-за того, что с этим проще работать. Есть ТЗ, есть результат, все четко и прозрачно. Вроде да, а вроде и не совсем.
Водопадный подход хорош, когда у тебя есть четкое видение финального результата. Например, ты должен построить дом, ты просишь деньги у государства и говоришь: «Я построю такой-то дом за столько-то денег, вот чертежи, вот документы». Государство дает тебе деньги, потом проверяет действительно ли дом соответствует всем предоставленным документам. Все просто и понятно. И другого в данном случае быть не может. Но проекты в отраслях со спецификой быстроразвивающихся технологий и очень высокой вариативностью могут и должны двигаться иначе.
В данном случае подошел бы продуктовый подход, чем, по какой-то причине пренебрегли разработчики «Смуты». В чем суть: на каждом этапе разработки у тебя должен быть готовый продукт, который можно отдать пользователю в том или ином виде.
Обычно разработка проекта делиться на несколько этапов:
Прототип
MVP
Доработка (может быть несколько итераций)
Завершение и вывод на поддержку/сервис
По завершению каждого этапа на руках у разработчиков должен быть готовый (относительно, конечно же) продукт. После прототипа — кликабельный макет, в данном случае возможны макеты локаций, героев, сцены и т.д. После MVP (минимально жизнеспособный продукт) — минимальный функционал, который уже хоть что-то может делать с точки зрения пользователя, в данном случае это одна миссия, одна сцена боя, т.е. то, что пользователь может сделать сам. Этапы доработки уже представляют собой наполнения сделанного MVP новой функциональностью. И после каждого из этапов должен быть так же играбельный продукт.
Количество этапов доработки зависит уже от ТЗ и от желаний заказчиков и возможностей разработчиков.
В классическом продуктовом подходе есть backlog (список требований на каждую итерацию). После каждого этапа backlog пересматривается: добавляются новые требования, убираются неактуальные, каждый из этапов оплачивается отдельно, что так же снижает риски потратить много денег и получить непонятно что.
После каждого этапа результат разработки передается на тестирование пользователям, заинтересованным лицам (стейкхолдерам), т.е. выносится на суд общественности. Это все для того, чтобы в каждый из моментов времени можно было скорректировать направление или поправить то, что не понравилось и повысить удовлетворенность пользователей будущим продуктом.
Да, в рамках заказной разработки на государство или крупную корпорацию сложно придерживать гибкого подхода, т.к. платят тебе в любом случае по общему ТЗ на весь продукт и первоочередное на что ты будешь обращать внимание, это выполнен ли данный пункт (нужен он или нет, это, в данном случае, дело десятое).
Но даже в таких условиях есть возможность применить продуктовый подход. Каким образом? Невозможно прописать ТЗ досконально учитывая каждый нюанс, поэтому в рамках каждого из требований можно найти определенную вариативность и использовать ее. Для примера возьмем такое гипотетическое требование: «В игре должна происходить смена дня и ночи». Вполне конкретное требование и в принципе понятно, что должно быть. Но путей как это реализовать очень много: можно сделать динамическое изменение времени суток, чтобы заходило солнце и поднималась луна, а можно через затемнение экрана менять день и ночь. Каждое из этих описаний удовлетворяет требованию ТЗ. Но с точки зрения пользовательского опыта первый вариант предпочтительней (естественно он дороже, но сейчас не об этом). Я к тому, что опытный РП сможет двигаться даже в рамках ограничений по гибкому подходу уседев на двух стулья удовлетворяя требованиям и госконтракта, и пользователей (например на этапе проектирования, формируя, например, частные технические задания, для уточнения требований и варьируя их от этапа к этапу)
Заключение
Судя по получившейся игре, «Смута» делалась профессиональными разработчиками, специалистами в своем деле. Ошибки были на стороне руководства. С одной стороны, целеполагание, стратегическое и тактическое чутье, неопытность в создании крупных проектов стали причиной неудавшейся игры. С другой стороны, государственный аппарат тоже должен понимать реалии отрасли и адаптироваться к ней принимая правила игры, перенимая лучшие практики и разрабатывать новые методики.
Итого, что могло бы помочь сделать «Смуту» лучше (с точки зрения управления командой):
Продуктовый подход к разработке
Сплоченная команда или заложить больше времени на разработку (дополнительно год)
Гибкость государственного управление при финансировании ИТ-проектов
P.S.: по поводу бюджета в 490 млн руб., чтобы снять все вопросы. Это нормальная цена
крупного проекта, рассчитанного на 2 года. Применим несложную математику,
возьмем команду из 30 человек, возьмем среднюю ЗП разраба 180 тыс. рублей (учитывайте,
что компания тратит деньги не только на выплату ЗП работнику, но и на различные
траты, связанные с ним: пенсионный фонд, здравоохранение и т.д., что повышает
стоимость сотрудника примерно в 3 раза), т.е. получается 180 тыс330 человек *
24 месяца = 389 млн руб. только для содержание команды разработки, добавим сюда
операционные затраты (пусть 10%), затраты на администрирование (пусть еще 10%),
затраты на инфраструктуру (сервера и т.д.), в итоге получается 470 млн (максимально
прикидочно пол-палец-потолок). Так что, с моей точки зрения, деньги пошли куда
надо, единственное, с какой эффективностью они расходовались это другой вопрос,
но это я рассмотрел уже в статье.
Habrahabr.ru прочитано 3783 раза
