Про планы и эксперименты

В небольшом городке старой евровы, под мирный хруст камина, отгоняющего мрак декабрьских вечеров, два уважаемых джентельмена записали подкаст «FCOVNO».
И затронули важную тему: разрабатывать ли игры строго по плану или позволять себе эксперименты, поиски лучшей механики и долгие прототипирования.

Уважаемые джентельмены затронули и другие темы — но с другими все понятно.
Делать маленький-крутой проект или большой-крутой? Конечно, маленький. Большой дольше, дороже, больше требований к команде.
Лучше задумывать игру от сеттинга или механики? В чем лучше разбирайся — от того и задумывай. Я лично всегда задумывал от механики, по другому не умею. Но если Дыбовскому поставить условие «делай от механики» — ничего хорошего он не сделает.

Тема про эксперименты и прототипирование сложнее — у меня от этой хуйни брат умер.
Четкого мнения нет, поэтому просто порассуждаю.

За.
Так мы улучшаем качество.

Самый очевидный аргумент: чем дольше будем прототипировать, тем лучше будет механика. Исключение — проекты с жестким референсом, который заменяет прототип. Что-то спорно или непонятно? — смотри референс. Это хорошая фича или плохая? — смотри референс. Однако, для не-совсем-вторичного продукта на эти вопросы может ответить только прототип.

Против.
Это дорого.

Самый очевидный аргумент: это стоит времени, это стоит денег. За время, пока вы экспериментируете с базовой механикой — другая студия уже выпустит три новые фермы и клон CCS.

За.
Сразу-хороших идей не бывает.

Я не знаю ни одного человека — и сам не являюсь тем, кто способен в голове родить сразу-прекрасную идею. Все идеи фрагментарны, неполны, содержат много домыслов и проверяются только прототипом. Я не знаю ни одного мало-мальски оригинального проекта, который не стал бы лучше от изменений в механике даже на поздних этапах. Чаще эти изменения вносили (и проекты проседали по срокам), реже — не вносили (и получили продукт хуже, чем он мог бы быть)

Против.
Риск попасться в ловушку.

Есть и обратные примеры, когда изменения не шли на пользу и даже делали продукт хуже. Риск создают психологические ловушки:

1. Мы думаем, что старые решения плохие, но на самом деле мы просто устали от них: разработка длится уже много месяцев, решения многократно тестируется, обсуждение потрепало нервы, в результате решения просто утомили. Оно могут быть и удачны и уместны, но усталость от них портит все впечатление.

2. Мы думаем, что новое решение хорошее, но на самом деле просто очарованы эффектом новизны. Любое решение требует вызревания, иначе мы рискуем спутать свое очарование с актуальностью и адекватностью решения.

За.
Не жалко отсекать лишнее.

Практически любой проект — даже соблюдающий планы и дедлайны — нуждается в фичекате. Фичекат бывает плохим и вынужденным: “мы еще не сделали продукт, но уже потратили все деньги, поэтому давайте вырежем половину функционала”.

Но бывает и правильный, нравственный фичекат: «мы уже сделали эту фичу, но поняли, что с ней проект стал грузен и избыточен”. Жадный разработчик оставит все как есть: фича сделана, время потрачено, деньги вложены. Щедрый, экспериментирующий спишет эти фичи как неудавший эксперимент, потому что знает, что вес фичи измеряется не только сроком разработки.

Против.
Лишнее все равно плодится быстрее.

Как бы убедителен я ни был в предыдущем пункте, но практика говорит обратное: при одинаковых ресурсах сторонники длительного прототипирования и экспериментального подхода сильнее перегружают свои проекты лишними и, что важнее, недоделанными фичами: зародышами и осколками экспериментов, которые никто не довел до хорошей реализации и не осмелился зарубить (что пошло бы на пользу) —  вместо этого бросившись изобретать новую фичу.

За.
Разработка без рефлексии демотивирует команду.

Бывает, что продукт уже покинул стадию прототипа, но с запозданием стало очевидно, что его механика требует серьезных переделок. Это уже не воспаленная фантазия дизайнера, а требование самого проекта, который вопит “поменяйте меня” и этот вопль слышат все члены команды. В таком случае нежелание вносить изменения и отклоняться от плана заставит всех почувствовать себя бурлаками на аутсорсе, тянушими нечто чужое, что не позволено трогать — хотя известно, как сделать лучше.

Против.
Отсутствие цели тоже демотивирует.

И обратное тоже верно.
Слишком долгие эксперименты и выдумывание новых фичей — особенно если старые сделаны через жопу — самые очевидные признаки плохого руководства проектом и продуктом. Команду это, в лучшем случае, пугает. Как капитан корабля, орущий посреди торгового плавания “А теперь мы отправляемся в Китай вместо Индии… А лучше вообще бросаем шелка и идем воевать с Кракеном!”.

__

Итога не будет. Добавляйте свои «за и против» в комментариях.