Структура технического задания 101 — Манжеты Гейм-дизайнера
1-QuOZ90JJ9kHSWi2DDe_eOw

Структура технического задания 101

Простая и удобная структура ТЗ для всех!

Привет, читатель! Сейчас я поделюсь с тобой тем, как я пишу дизайн документы к играм. Если ты уже работаешь в большой компании, где есть своя выработанная структура ведения документации, то всегда есть шанс, что ты сможешь что-то улучшить. Если на тебя возложена ответственность за изобретение этой структуры с нуля, то ты попал по адресу.

Чтобы мы находились в одном языковом поле, нужно договориться о терминах. Итак, в моём понимании, дизайн документ — это структурированный текст с изображениями, который позволит любому человеку в команде понять твой замысел по одной конкретной задаче. Таким образом, дизайн документ — это минимальная сущность, которая описывает только одну задачу. Все подобные документы, в сумме, описывают проект целиком. Кстати, некоторые GD называют такие документы не дизайн документами, а «ТЗ». Для них «Дизайн документ» — это как раз вся сумма ТЗ, описывающая проект, если ты привык к таким названиям, то можешь считать, что я пишу про ТЗ.

* * *

Название задачи

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

Общая информация

Этот блок нужен для того, чтобы КМы, техподдержка и прочие НЕпрограммисты могли понять, о чём вообще конкретная задача. Советую писать этот блок в формате User Story, то есть, описывая то, что пользователь получит при выполнении задачи. Здесь же обязательно прописывается «ЗАЧЕМ?» задачи, без которого вообще работу я советую не начинать.

Логика

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

Визуализация

Этот блок заполняется, если реализация задачи требует каких-то действий с UI. Описываются все элементы UI, относящиеся к задаче и их логика работы. В этом блоке обязательно присутствуют изображения (мокапы, макеты экранов, элементы GUI и прочее).

Локализация

Блок, который состоит из таблицы, в строках которой описаны все текстовые переменные и константы. В столбцах — их переводы на все необходимые языки.

Аналитика и статистика

Блок, который заполняется, если за задачей нужно следить. Указываются все точки, на которые нужно навесить триггеры, а также KPI, которые нужно держать под контролем после релиза задачи.

* * *

Вот так всё просто. Ничего лишнего — всё прозрачно и структурировано для любого читателя. Отдав такой документ программистам, ты гарантированно получишь то, что описал в нём.

Спасибо за внимание!

Владимир Ковтун
Владимир Ковтун
Гейм-дизайнер, который умудрился родиться в лучшее для этой профессии время. Семьянин и филолог, который считает, что браться за всё сразу — это нормально.
  • Roman Golenok

    Хоть пример бы дали, что ли.