За фичу отвечают как минимум три человека: гейм-дизайнер, который ее придумал и описал, исполнитель, реализовавший ее в срок, и специалист по тестированию, который проверил, что все работает именно так, как планировал гейм-дизайнер. Последний должен составить ее полное описание, а исполнители и продюсер – дать оценки, насколько фича важная и рискованная. После этого уже можно приступать к составлению плана работы. Однако не всегда мы можем придерживаться планов, самые разные факторы способны принудить срочно поменять, добавить или убрать ту или иную фичу.
Зачастую фичекрип – это не проблема добавления новых фичей, а проблема того, что текущие фичи влекут за собой новые изменения. Здесь не обойтись без внутренней экспертизы, и, к сожалению, не всегда исполнители могут адекватно оценить стоимость добавления того или иного игрового элемента. По-хорошему исполнители должны доверять решениям гейм-дизайнера. В свою очередь он, прежде чем предлагать нововведения, должен задуматься, какие еще фичи придется отменить или отложить, чтобы реализовать свою, и какими будут последствия.
Лучше еще в самом начале разработки определиться с тем, какие фичи нельзя «вырезать» ни в коем случае, какие – только в случае крайней необходимости, а чем можно пожертвовать. Фичекат может быть болезненным, но чаще всего это полезный процесс, помогающий команде сконцентрироваться на действительно важных вещах и не затягивать разработку.
Иногда, вместо того чтобы просто вырезать что-то, разработчики принимают решение разбить фичу на части и выдавать игрокам контент постепенно. Это позволяет выделить больше времени на тестирование и успеть внести изменения, если что-то пошло не так. Если на каждом этапе такая фича вносит в геймплей что-то новое, игроки будут с нетерпением ждать ее развития. Но есть риск, что получится наоборот. Если, например, игрок видит на карте место для ловли рыбы, но при этом в игре все еще не реализована механика рыбалки, ему становится очевидно, что он купил недоделанную игру, и это может вызвать негативную реакцию.
В течение спринта на крупных проектах выполняются сотни задач, и один человек просто не сможет вникнуть в каждую, чтобы правильно ее приоритезировать. Поэтому очень важно, чтобы заказчик самостоятельно понимал ценность предлагаемой фичи, а исполнитель – риски ее реализации.
В команде должно быть четкое понимание, какие новые идеи превращаются в задачи. Их может утверждать продюсер или демократическое голосование, но важно избежать ситуации, когда, с одной стороны, приоритетные фичи не делаются, а с другой – сотрудники постоянно отвлекаются на новые задачи, пока не выполнены текущие.
Если каждый выбирает только то, что ему нравится, есть немаленькая вероятность, что проект не будет доведен до конца. Для инди-команд такая демократия может работать, если люди «в доле». Если проект не завершится или не получится, они потеряют не только время, но и деньги. Поэтому важно, чтобы в команде был визионер – человек, понимающий ситуацию в целом, – и чтобы к его мнению прислушивались.
Большие проекты всегда предполагают сложный менеджмент. С одной стороны, важно не подавить инициативу сотрудников, с другой – объяснить, что не все нововведения хороши и иногда для проекта лучше следовать заранее установленному плану. Здесь очень важна работа креативного директора, или Scrum-мастера, или лида направления, обучающего людей самостоятельно принимать взвешенные решения.
Бюджет проекта – это план затрат, необходимых для его исполнения. Сюда включают заработную плату сотрудников, стоимость оборудования, закупку материалов, программного обеспечения, ассетов, налоги и пр. В игровой индустрии обычно он состоит из двух частей: планируемые расходы и прогнозы доходов. К сожалению, без грамотно составленного feature-листа сделать адекватный план бюджета и бизнес-план невозможно. А это влечет за собой большую проблему: если бюджет будет сильно завышен, то издатель/инвестор не захочет с ним работать, если же вы ошибетесь в сторону уменьшения, не исключена ситуация, когда вы подпишете договор на определенную сумму, а деньги закончатся задолго до завершения проекта.
План бюджета – это обычно именно внутренний документ, по которому фактически работает команда. А бизнес-план предназначен для демонстрации планов и прогнозов инвесторам/издателям.
Документация и инструменты управления помогают понять, в какой последовательности реализовывать фичи, где может не хватить ресурсов и времени, где проект может «просесть». Задачи разбиваются на более мелкие и структурируются по времени и приоритету.