Stretch Goals и их проблема

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

В частности недавно опубликовали спич основателя Larian Studios на GDC, в котором он рассказывает о процессе разработки Divinity Original Sin 2. И как пример он упоминает о цели создания расы Undead, существование которой заставило команду писателей переделывать значительную часть диалогов незадолго до релиза.

Обсуждение целей кикстартера и пример с расой Undead находятся на 9 и 33 минутах соответственно.

К счастью разработчики Larian Studios обладали опытом большой студии, которая выпустила уже не один проект, и смогли удачно адаптироваться к ситуации и выпустить игру, которая на момент написания этой статьи имеет 93 metascore и 8.8 userscore на Metacritic. Но на их примере, мы можем увидеть, что им пришлось перенести дату релиза, и отчасти поэтому они смогли завершить многие запланированные фичи.

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

Я предлагаю посмотреть на эту проблему со стороны менджмента "стандартных" IT проектов.

Перед вами Iron Triangle, он же Project Management Triangle. Он демонстрирует нам ограничения (constraints), которые мы можем применить к нашему проекту. Его суть заключается в том, что возможно зафиксировать только две его вершины. Поскольку игровые, как и любые другие IT проекты, невозможно полностью запланировать с самого начала, одно из ограничений будет меняться в ходе разработки.

Все же многие команды неправильно интерпритируют смысл этой диаграммы и пытаются зафиксировать все три точки. Тем самым жертвуя невидимой четвертой характеристикой - качеством (quality). Для демонстрации этого существует следующая модель.

Подробнее об этом концепте можете прочитать в этой статье.

Так что же у нас происходит, когда мы добавляем stretch goals?

Stretch Goals фиксируют наш Scope - размер проекта. Вы можете сказать, что у нас осталось еще три свободные точки, которые позволят нам адаптироваться и менять их на протяжении разработки, но это не так.

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

И по факту единственное, что остается незафиксированным - это качество (Quality). И соответсвенно большинство студий им и жертвуют, руководствуясь принципом "F**k It, Ship It". Что приводит к огромному количеству багов в игре, несбалансированным геймплейным системам и соответственно тоннам негативных отзывов в Steam. Звучит знакомо?

В качестве небольшой отсылки: Divinity: Original Sin 2 тоже этим страдала в первые недели релиза...

На мой взгляд ответ достаточно простой - максимально не ограничивать Scope - не обещать будущим игрокам вещей, которые не являются основной игрой, и далеко не обязательно будут в неё входить в конце.

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