Вступление. Как создать ТЗ для программиста

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

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

Вступление

Компьютерные игры — относительно молодая отрасль, которая в перспективе сменит киноиндустрию, так-же как кинофильмы заменили театр. Создание игры — это коллективное творчество, во многом напоминающее создание кинофильма. Кроме того, создание компьютерных игр — одна из самых сложных 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. Оглавление, список документов, история изменений. (Для поиска по документации/версиям)

Дата добавления: 2015-07-18