Нет ТЗ - результат ХЗ
Мир игростроя, как и любая проектная деятельность, очень сильно завязан на требованиях, которые необходимо учитывать в разработке продукта. И от качества проработки этих самых требований зависит, как ни странно, качество итогового продукта, а также время и ресурсы, затраченные на его реализацию. Как правило, требования собираются в виде Технического задания (далее ТЗ), которое передается команде разработчиков. Вот об этом и расскажу, точнее о моем личном опыте в составлении ТЗ.
Самая важная задача ТЗ это собрать требования от всех стейкхолдеров и донести их до участников разработки, сам документ не так важен как единая информация в головах участников. Но вот на удаленке сделать это можно например хорошей документацией и регулярными встречами. Но контекст все равно будет теряться, документация не панацея. чем плотнее и подробнее документация тем неохотнее ее читают, чем ветвистее - тем сложнее отследить взаимосвязи и вообще пропустить важные моменты. Тут хорошо работает правило - проще лучше. Но не ее отсутствие - баланс придется находить методом тыка и обратной связи.
В геймдеве я встречал несколько типов ТЗ (названия условные):
- Глобальное ТЗ или Бриф от ГД или Продюсера (верхний уровень контекста). Как правило, описывает общими понятиями новый режим игры или его крупную фичу, пачку персонажей или крупный апдейт. Эдакая первичная концепция. (например окно колеса фортуны или целое FTUE). Седержит список всех элементов и описание системы их взаимодействия.
- Общее ТЗ (Средний уровень контекста). Это конкретное описание всех особенностей работы одного составного элемента фичи, который является достаточно автономной единицей. Содержит описание ассетов и механики, управляющие ими, интеграцию с балансовыми таблицами, может содержать интерфейс, управляющий им. (например само вращающееся колесо фортуны или пальчик указатель со всеми состояниями и механиками из FTUE)
- ТЗ, Просто ТЗ. (Нижний уровень контекста) - Описание конкретной задачи в отделе, например, иконочку нарисовать 2D для колеса фортуны, эффект активации вращения, задача на создание конкретной механики (например активацию виньетки во время FTUE). Как правило, такое ТЗ ограничено одним отделом или человеком и не подразумевает плотного взаимодействия с другими отделами.
По нормальным стандартам (если в геймдеве вообще уместны стандарты), любое ТЗ проходит путь трансформации от Брифа через общие ТЗ до конкретных задач. Причем не важно, идет ли работа по методам гибкой разработки, где постоянно уточняется ТЗ, или полный расчет бюджета и плана на полгода вперед перед стартом работ, где идет подписание по каждой задаче.
Также стоит учесть, что чем меньше команда, тем скромнее нужно все описывать, тем меньше проработка документации, потому что контекст в целом можно передать устно во время встречи или письменно в групповом чате.
На практике для команды из 3-5 человек вообще не нужно особо ничего писать. Для команды от 10 человек, где есть несколько отделов (арт, дев, геймдизайн) и в каждом отделе по 3 человека, уже необходимо описывать ТЗ/Задачи. А затем по нарастающей. Для команды из 20 человек уже нужно хорошо прорабатывать Общие ТЗ. В командах от 30-40 человек нужно детально прорабатывать бриф. Во времена офлайн разработки можно было игнорировать детализацию документации, так как контекст легко передавался внутри офисного пространства быстрее любого документа. Но многие до сих пор думают прошлым и недооценивают недостаток контекста у распределенной команды.
Основное правило, чем больше команда тем больше детализации на уровне выше.
С ростом команды сначала детализируем ТЗ/Задачи, потом начинаем уделать внимание среднему уровню и детализируем Общие ТЗ, когда команда побольше начинаем детальнее описывать Бриф.
Чаще всего начинают наоборот с брифа, что приводит к трагедиям, потому что именно верхний и средний контекст размывается с ростом команды. И избыточен когда команда маленькая. В практике средний уровень контекста с общими ТЗ вообще вылетает из процесса, а именно им проще всего поднять общую производительность команды.
Наличие информации в брифе и общих ТЗ - зона ответственности Продуктовнера. Не важно, пишет ли он сам или у него есть команда лидов и техрайтеров, но его наличие, понятность и содержание как раз и описывает то, что он представляет себе в голове как результат. Также стоит понимать, что продуктовнером может быть артдир, ГД , продюсер или даже Лид. Тот кто лучше представляет, кому дали это право, тот и управляет этим продуктом.
Лично я предпочитаю проработать варианты решений, затем обсудить их с кортимой на встрече. И так уже совместно прийти к итоговому варианту, затем закрепить его в брифе и отправить ребятам на проверку уже согласованный вариант. - скорее всего, все будут в достаточном контексте задачи. Вариант отправить документ на прочтение без обсуждения - как правило, приводит к недопониманию команды и приходится потом несколько раз переделывать документ и несколько раз встречаться с участниками, чтобы разъяснить детали. Итоговый документ является результатом совместной работы с кортимой. Плохая практика описать документ до финального состояния, а потом предоставить его на комментирование команде, и отвечать на комментарии. В итоге у команды формируется разный контекст и разное понимание, итог - будут переделки и куча багов.
А теперь конкретно по этим типам ТЗ
Глобальное ТЗ или Бриф (верхний уровень контекста).
Необходимо для верхнеуровневого понимания, для чего вообще эта фича, затея, режим. Отвечает на вопрос: Зачем мы делаем это?
Может быть совсем простеньким для какого-нибудь колеса фортуны или очень пухленьким для FTUE.
Включает в себя:
- Цели отвечает на вопрос для чего все это делаем
- Потребности игрока или бизнеса которые будут во главе разрабатываемых решений
- Решения 1 или более гипотез, решений которые по мнению ответственных лиц закрывают первые 2 пункта. Концептуальные описания, часто с ссылкой на референсы из других игр.
- Ограничения. закрепляем договоренности о сроках, бюджетах, людях, технологиях, ориентиры по качеств, определяются ответственные (чтоб споров не было позже)
- Итоговое решение - Выбранное решение из гипотез определенных ранее. часто единственное предложенное решение становится итоговым. Этот пункт указывает на определенность в выбранном решении.
- Составные элементы итогового решения. Тут важно описать все элементы, механики, опорный список из которого формируются общие ТЗ.
- ТО что необходимо исследовать. На этом этапе должно быть понимание что понятно как делать, а для чего необходимо провести исследования. после проведения которых должно появиться конкретика.
На сколько детально описывать - автору надо понимать команду разработке и уровень их погруженности. Если например подобный бриф надо написать для аутсорсовой команды, то детализация должна быть крайне высокой. Для инхаус команды многое можно спустить на умолчаниях. Ну а если это твой друган - то он и по взгляду все поймет))
Как условный пример :
Цель - поднять процент возвращаемости игроков.
Потребности игрока - дать возможность игроку бесплатно получать награду за время проведенное в игре.
- Добавить колесо фортуны, которое можно периодически вращать и получать случайную награду из представленного списка.
- Добавить на главный экран иконку сундука, который можно открыть и получить случайную награду. перезапуск сундука по таймеру.
- Добавить миниигру в которой игроку необходимо отыскать клад при помощи металлоискателя. Попыток ограниченное количество (количество ростет с уровнем випстатуса), обновляются по таймеру, могут накапливаться.
- Старт события только с иконки на главном экране, никаких 3д обьектов на карте и миниигр.
- получение наград делаем в окне попапом без серьезных затрат по графике и механиках
- Мы спешим, надо сделать за неделю в ближайший апдейт. Все из готовых компонентов, никаких экспериментов.
- Качество вот как в этом рефе и ссылка.
Итоговое решение: Иконка сундука на главном экране, с таймером, открывается при тапе, дает случайную награду.
Составные элементы, компоненты: сундук на главном экране, попап с наградой,
НО Такое в работу отправлять нельзя, так как он содержит только описание идеи, референсы, поверхностные суждения о результатах. Оно содержит очень малое количество требований и следовательно без конкретики. И в целом словом "ТЗ" называться не может потому как не содержит в себе самих "заданий" или точность присутствует только у какой-то одной составляющей в которой автор ТЗ разбирается. (могут расписать баланс но не описать механику).
На практике такие ТЗ достаточно часто попадает в разработку и создает большое количество проблем. Но это отдельная тема на отдельный пост, напишу об этом в следующий раз.
С брифом может работать только продюсерская группа (Продюсер, Арт-директор, СТО, лидГД). До спуска на руководителей отделов его необходимо доработать до уровня Общих ТЗ
Общее ТЗ (Средний уровень контекста).
Это перевод из абстрактного состояния итогового решения в конкретные задачи для команды. Это основной инструмент для работы руководителей отделов, арт-директоров, геймдизайнеров.
Отвечает на вопрос: Как мы это делаем, как это работает?
Важно - Общее ТЗ должно содержать разъяснения для всех отделов в одном документе, чтобы программисты, например, понимали, как должна работать графика. Они должны знать, что для сундучка будут использоваться анимации и запускаться некоторые эффекты при его активации. Плохая практика состоит в том, чтобы писать на этом уровне отдельные документы для арт-команды, программистов и UX. Необходимо избегать описания требований к отдельному ассету, но важно указать, как он будет собираться и из чего будет состоять, а также какие компоненты будут подключены к нему.
Если компоненты фичи сложные, то может быть несколько общих ТЗ. Например, карта королевства для 4х стратегии в целом является компонентом, но есть также много механик, которые там работают, а также подкомпоненты, которые также требуют детального описания механик, анимаций и состояний.
Включает в себя:
- Описание механик взаимодействия между элементами, компонентами. Это необходимо, чтобы команда понимала, как вся эта конструкция работает. Описание архитектуры, того, что чему подчиняется и по каким правилам работает.
Пример: Если это сундук с наградой, то там описание только в том, что при нажатии мы видим эффект нажатия, потом анимация открытия сундука и попап, который с анимацией перекрывает экран. Важно описать подробно ВСЕ состояния, эффекты и переходы, вплоть до таймингов и задержек, как все это запускается и как переходит одно в другое. Если же речь заходит о FTUE, то здесь надо серьезно постараться, чтобы описать элементы, которые запускают другие составные компоненты, через какие анимации и повторяющиеся паттерны. Здесь необходимо описать именно систему взаимодействия элементов, а не сами элементы. Я, например, описываю инструменты, которые позволяют управлять сценарием и запуском нужных мне элементов. Потому что без инструментов придется описывать подробно все сценарии и потом вручную их программировать - поистине гиблая идея с кучей времени на описания и с огромным количеством багов.
- Описание механики отдельного элемента. Это частный случай первого пункта, только ограниченный отдельным элементом. Для простых элементов можно пропускать, но есть и не простые.
Пример: На сундуке должна быть анимация покоя. А ладошка-указатель из FTUE имеет три анимации: появление, ожидание и исчезновение, а также механику, которая переключает эти состояния. А если речь идет о таком компоненте, как иконка предмета или ресурсная точка из 4X? У обьекта просто миллион состояний, которыми надо управлять в зависимости от игровой ситуации.
Тут же ссылки на схожие или идентичные механики, которые уже есть в игре для их переиспользования.
- Визуальная концепция. Описание визуальных решений, которые определил арт-директор. Этот пункт описывает, как все должно выглядеть в итоге, стиль и подачу. Все с точки зрения игрока.
Пример: Иконка сундучка будет выполнена в виде парящей над персонажем птички. При нажатии на нее проигрывается анимация, и перед нами появляется всплывающее окно с прыгающим сверточком. При тапе на сверточек через яркую вспышку происходит его трансформация в наградный предмет.
- Доступные технологии, инструменты, гайдбуки. Тот, кто это расписывает, должен быть в контексте доступных технологий, уже разработанных инструментов, которые уже есть в игре, чтобы не создавать их дубликаты. Нужно понимать, какие решения можно сделать на их основе, как полностью использовать текущий потенциал. Здесь полностью проявляется технический креатив арт-директора. Здесь нужно указать все, что уже есть, ссылки на гайдбуки, артбуки, библиотеки шейдеров - все, что необходимо использовать в текущей задаче и уже было создано ранее.
- Спецификации. Все, что нужно сделать, должно быть описано поассетно: сколько, куда складывать, какого размера и с каким именем, в каком формате и так далее - все, что понадобится для того, чтобы рассчитать стоимость работ.
Расчет стоимости работ возможен только после составления общего ТЗ и заполнения спецификации. Только после этого можно приступить к планированию и бюджету. Если стоимость надо получить раньше - то надо менять подход в целом.
Каждое общее ТЗ можно передавать на выполнение сразу после его завершения, не дожидаясь завершения всех общих ТЗ по функционалу.
Общие ТЗ должны быть написаны таким образом, чтобы любой участник разработки мог понять, как все это работает. Это относится как к тем, кто уже работает не один год, так и к тем, кто на проекте всего месяц.
Уровень проработки следует оценивать по человеку, который хуже всех понимает. Оценивать по себе - это плохая практика, потому что то, что для тебя очевидно, может быть совсем неочевидным для исполнителя.
Время, затраченное на составление ТЗ, сдвигает срок начала работ, но впоследствии компенсирует его, когда сотрудники не тратят время на поиск нужной информации. Плохое ТЗ увеличивает срок разработки в два раза по сравнению с первоначальным - это было проверено много раз.
Немногие люди могут писать хорошие ТЗ, если найдете такого, старайтесь удержать его любыми возможными способами. Написание общих ТЗ требует системного мышления и технического склада ума. Это навыки, которые сложно развить.
Определение достаточности проработки зависит от исполнителя, а не от автора ТЗ. Завершать можно только тогда, когда все будет ясно исполнителю. Плохая практика считать, что ты написал отличное ТЗ, а команда при этом жалуется на неясность.
ТЗ, Просто ТЗ. (Нижний уровень контекста)
Это относится к техническому заданию для определенного отдела, человека. Оно описывает задачу, связанную с конкретной механикой, алгоритмом или ассетом. Хотя я думаю, что программисты не углубляются в такую детализацию задач, но в графике это часто встречается. Там нужно нарисовать картинку, создать текстуру, выполнить анимацию и другие подобные вещи. Это именно то, что должен сделать конкретный исполнитель. Обычно руководители отделов описывают это непосредственно в задачах, редко это попадает в общий документ.
В комплекте с Общим ТЗ исполнителю попадает полная информация о задаче.
Самые серьезные провалы в разработке ТЗ на среднем уровне контекста. Возникают когда продуктовнер игнорирует описание механик или просто не понимает, как их описать. И чаще всего исполнителям не хватает именно этих описаний. Плохая практика - когда вместо Общего ТЗ команде предоставляется референсная игра. Такой подход может использоваться только в рамках продюсерской группы, но исполнителям такое давать нельзя, потому что возникнет множество вопросов, а затем будет сложно согласовать результаты их работы, так как никто не позаботится о совместимости всего, что было сделано.
Понимающих вам исполнителей, которые понимают вас без лишних вопросов, чтобы только задумался, а они уже все поняли и начали делать!