Как создать ТЗ для программиста

Рекомендации геймдизайнеру от программиста (архитектора).

Вступление

Компьютерные игры — относительно молодая отрасль, которая в перспективе сменит киноиндустрию, так-же как кинофильмы заменили театр. Создание игры — это коллективное творчество, во многом напоминающее создание кинофильма. Кроме того, создание компьютерных игр — одна из самых сложных IT задач, поскольку она включает все себя практические все IT области.

Все слышали про pre poduction, но мало кто знает как именно это происходит. И если про стадию разработки написано много, а про стадию издания — еще больше, то про стадию планирования известно очень мало. В лучшем случае вам посчастливится ознакомится с результатами планирования. А вот как были достигнуты эти результаты? — загадка во тьме.

Этот документ является результатом «разбора полетов» после написания игры Звездная арена для социальных сетей. В этом документе я попытался упорядочить список проблем и решений к которым я и Александр пришли в процессе совместной работы над игрою. Кроме того этот документ является частью большой работы по выстраиванию рабочего процесса создания компьютерных игр.

Я намеренно оставил за кадром другие документы: концепцию, экономическое обоснование и ТЗ для других исполнителей. Это позволило сфокусироваться на одной теме и осветить ее и только ее достаточно подробно.

Самое важное:

1. Четкое понимание конечного результата. (Контроль качества.)
2. Сроки исполнения.

Зачем нужна документация:

1. Экономия времени на коммуникациях. (Один раз написать, вместо того чтобы 100 раз пересказывать, путаясь в показаниях.)
2. Способ увидеть, как будет выглядеть готовый проект.
3. Анализ и выявление проблем еще на стадии планирования. (Чем раньше будет выявленна архитектурная ошибка — тем дешевле ее исправить)
4. Фиксирование принятых решений. (Точные данные, вместо разрозненных слухов разной степени свежести.)
5. Планирование работ.

Какие бывают документы:

1. Концепция («Про че игра?»)
2. Спецификация (Что мы хотим получить?)
3. Техническое задание (Как это устроено — именно о нем будет идти речь.)
4. План работ (Как мы это будем делать.)

Кто участвует в обсуждении ТЗ:

Чем раньше будет получена обратная связь от заинтересованных специалистов — тем меньше будет сделано лишней работы.

1. Геймдизайнер (Написание документации)
2. Архитектор (Отслеживание полноты и подробности описания, декомпозиция.)
3. Программист (Оценка объемов работ.)

Требования к оформлению документации:

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

1. Форматирование. (Легко напечатать и приятно читать/держать в руках)
2. Выделение ключевых фраз. (Для чтения документа по диагонали)
3. Составление списков. (Вместо сплошного текста)
4. Разбиение длинных списков по группам. (По три пункта в группе)
5. Многократные повторения. (Избегать ссылок по документу)
6. Дата, номер страницы, количество страниц, нумерация пунктов. (Для точных ссылок при обсуждении прочитанного)
7. Оглавление, список документов, история изменений. (Для поиска по документации/версиям)

Требования к содержанию ТЗ

Нет четкого списка требований, которому должна удовлетворять документация. Поэтому разработка ТЗ приостанавливается задолго до приближения к ее полноте. В итоге следующий этап разработки начинается без ТЗ, в надежде, что ТЗ будет дописана по ходу, или даже по итогам разработки.

1. Русский язык. (Никаких мемов, искаженных аглийских терминов, албанского языка и прочего мусора. Даже внутреннюю документацию читают очень многие.)
2. Никаких общих слов типа:
   • все возможные варианты
   • карта придумывается компьютером
   • взаимодействие различных объектов
   • после всех действий и т.д.
3. Все названия видов сущностей(классов) должны иметь:
   • русское название (для игрока)
   • английское (для кода)
   • краткое описание (расшифровка/подсказка/комментарий)
4. Сущность должна иметь только одно название. (Чтобы “броня” не превращалась на другой странице в “армор” или “щит”).
5. Предложения должны быть полными и понятными читателю без пристального изучения контекста. (Не надо подразумевать, что читатель сам догадается до того, что подразумевал автор)
6. Все что можно измерить, должно быть измерено.
   • размеры картинки в пикселях и байтах
   • количество столбцов и клеток в таблице
   • количество символов в текстовом поле
   • количество оружия на уровень
   • время сессии и т.д.

Главные требования к результату работы программиста:

Эти важные требования подразумеваются, но никогда никем не озвучиваются.

1. Гибкость системы к изменениям. (Динамические требования.)
2. Автоматический сбор данных об ошибках. (Обратная связь.)
3. Простота запуска и настройки заказчиком. (Демонстрация результата.)

Первый этап написания ТЗ:

Описание предметной области, ее формализация в понятных программистам терминах.

1. База данных (метаданные)
   • список типов объектов
   • характеристики объектов
   • связь/зависимость между объектами
2. Бизнес-процессы (полный игровой цикл)
   • список процессов (сценарии работы)
   • список функционала (что должен уметь)
   • список ожидаемых изменений (что вообще может быть)

Второй этап написания ТЗ:

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

1. Интерфейс (визуальная часть)
   • список экранов игры с названиями (или группы элементов)
   • список элементов на каждом экране с названиями и текстом подсказок
   • описание поведения элементов (подмигивание, подсказка, блокирование, всплывающие диалоги и т. д.)
2. Админка (управление)
   • сервер (жизненные/системные показатели )
   • игровой контент(распродажи, квесты, монстры, вещи, магазины, дроп, локации и т.д.)
   • игровые данные(контент генерируемый игроками)
   • статистика и отчеты (какую статистику нужно собирать?)

Третий этап написания ТЗ:

Как мы собираемся это все делать.

1. Исследование необходимых технологий
   • Список требований к каждой технологии
   • Описание тестов/демонстрации работы каждой технологии
   • Список будущих требований/возможных проблем (что дальше?)
2. Список требований к разным видам контента(ресурсов) для игры (размеры картинки мечей, длинна названий квестов, разновидности спецэффектов, размеры видеороликов и т.д.).
3. Список небходимых инструментов для работы с контентом (редактор карт, админка квестов, ).
4. Расстановка приоритетов по задачам.
5. Требования к первой работающей сборке (что должен уметь первый прототип).
6. Список остальных итераций разработки проекта с требованиями к их результатам. (Что нужно показать в конце каждого этапа, чтобы закончить его)

Сопровождение документации

1. Большая часть того, что написано на первых этапах – устареет и будет нуждаться в переписке заново задолго до окончания планирования.
2. Главный принцип первых этапов планирования: расставить список разделов и составить список вопросов по каждому разделу.
3. Чем ниже детализация на начальных этапах – тем лучше. (количество типов оружия, вместо полного списка с названиями, количество квестов по уровням, вместо их подробного перечня и т.п.)
4. Чем легче найти нужный пункт в документации и изменить его, не затрагивая остальное – тем лучше. Поэтому нужно избегать графических схем и сплошного текста из сложноподчиненных предложений. Оставьте графические презентации и эмоциональные описания для финальной отчетности.
5. После каждого цикла планирования — проверять и тестировать полноту документации и равномерность уровня ее детализации. (Если в доме из 5 комнат описана только одна – нужно описать остальные четыре, или выкинуть подробное описание одной комнаты, чтобы все комнаты были описаны одинаково подробно.)
6. Составить список неудобных вопросов. Темные пятна всегда есть, и их стараются обойти и замолчать, не осознавая этого.
7. Предоставлять краткие инструкции конечным исполнителям. Конечные исполнители не должны сталкиваться с полной документацией, и мучительными поисками нужного упоминания по всему объему.
8. Признак мастерства: каждый следующий уровень планирования уточняет, но не изменяет результаты описания более абстрактных уровней. Именно хороший навык перемещения по уровням абстрагирования/детализации позволяет перейти от припадочного описания деталей к планомерному перечислению сущностей.

Срезание углов

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

1. Проект в 2-3 месяца.
2. Команда из 2-3 человек.
3. Ограниченный бюджет. (Он всегда ограничен)
4. Нет требований к документации. (Никто не знает как надо делать)
5. От нее нет никакой пользы. (Никогда не использовали документацию)

Однако следует помнить: разработка документации занимает 40% всех усилий. И определяет на 90% вероятность успешного завершения разработки проекта.

Первые шаги

Настоятельно рекомендуется новичкам выбирать в качестве первых проектов «клоны» классических игр. Пока нет успешного опыта такой игры — нет виденья всего цикла разработки продукта. А значит нет понимания того, как дойти до финиша.
Не стоит начинать разработку игры, не написав хотя бы двух полноценных ТЗ в качестве упражнения. Это может быть ТЗ по арканоиду. Но это обязательно должен быть ТЗ по которому разработчики смогут написать полноценный арканоид, даже если они никогда не видели этой игры прежде.