Перешли всем отделом геймдизайна на Notion. Полёт нормальный

Недавно наш отдел геймдизайна поменял основной инструмент и переехал с Google Документов на Notion — хотели решить проблемы хранения и организации документов. В общем, ни разу не пожалели. 

Notion — это такой мегакомбайн, совмещающий в себе Jira, Confluence и Google Docs. В нем бок о бок уживаются огромная база данных, совместная работа над документами, календари, напоминания, списки задач, канбан-доски, интеграции сторонних инструментов и много-много другого.

Для себя мы организовали удобное хранилище всех геймдизайнерских материалов (ГДД, концепт-доки, фоллоу-апы, планы по контенту и так далее), сделали систему тегов, которая быстро позволяет найти любой документ, и создали готовые шаблоны для создания ТЗ в пару кликов.

Под катом расскажу, зачем решили сменить инструмент, как его выбирали и почему остановились на Notion. А мой коллега поделится логикой и организацией инструмента изнутри.

Почему решили переезжать

Раньше весь отдел геймдизайна пользовался исключительно сервисами Google. Для команды разработки был общий корпоративный аккаунт, внутри которого Google Drive с папками под различные геймдизайн-документы (ГДД), технические задания (ТЗ), конфиги и другие проектные материалы. 

Все довольно стандартно и со своими проблемами.

В Google Drive нет прозрачной иерархии документов, есть лишь набор папок по аналогии с файловой системой. Из-за этого регулярно что-то терялось, приходилось пинговать коллег, спрашивать, искать ссылки в Slack и часто безрезультатно. Например, когда нужно было переработать старую фичу, а ТЗ по ней куда-то пропало или было спрятано в такой вложенности папок, что для поисков нужно было призвать Индиану Джонса или Нейтана Дрейка. 

Отсюда первая проблема — в Google Drive очень ограниченный поиск. Он неплохо ищет по названиям, но совсем не умеет искать по тексту внутри документов. Геймдизайнер мог банально забыть имя файла и потратить лишнее время на его поиски. Вторая проблема — игнорирование шаблонов документации. У нас под каждую фичу готовится определенный набор шаблонных документов — ТЗ, концепт-доки, сетки ивентов и так далее. При этом каждый геймдизайнер сам изобретал структуру папок и ГДД, и, соответственно, только он ее и понимал, а другой просто терялся. Когда в очередной раз продакт-овнер получал на согласование подобный документ, то тратил время, чтобы понять хотя бы структуру. Шаблоны, конечно, были, но их почти никто не использовал из за банального неудобства самого процесса: найти ссылку на шаблон > копировать шаблон > переместить в нужную папку.

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

В какой-то момент проект покинул геймдизайнер, на котором было завязано очень много процессов и документов по монетизации и кору. Инструкций по работе с ними не осталось, пришлось вручную разгребать весь Google Диск, что привело к задержкам и различным проблемам на продакшене.

Процессы в отделе геймдизайна предстояло полностью переделать и выбрать для этого другой удобный инструмент. Опыт работы тогда был в Google Документах, Confluence и, внезапно, в Notion.

Требования к новому инструменту

Перед тем, как что-то делать, нужно сначала понять, зачем. Поэтому мы сформировали несколько целей:

• сократить сроки разработки и согласования ГДД;

• быстро вникать в задачу;

• быстро и легко находить нужные документы;

• удобно и комфортно работать в одном информационном пространстве.

Вместе с ведущим геймдизайнером и главой LiveOps мы определили критерии, которым должен был соответствовать наш будущий инструмент. После чего поставили оценки и вывели среднее значение. 

Далее провели несколько встреч с остальными геймдизайнерам, комьюнити-менеджерами, лидами, продактом и другим заинтересованными сотрудниками, на которых уточнили наиболее актуальные проблемы, которые хотелось бы решить. И все это сопоставили с возможностями инструментов, где безоговорочным победителем стал… спойлер-спойлер… Notion.

Краткий обзор инструментов

Сначала вкратце пробежимся по инструментам, их плюсам и минусам. А затем перейдем к главной теме статьи.

Google Документы

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

Были и другие вещи, которые не устраивали. Например, в Google Документах сложно работать с картинками, гифками или видео. Мы постоянно взаимодействуем с визуальным контентом, но когда в документ вставляешь картинку, ее потом нельзя скопировать в другой док. Приходится скринить, вырезать и вставлять в другой инструмент. Одним словом — костыли.

Также здесь нет кастомных шаблонов, например, невозможно сделать пресет с ТЗ на фичу — можно использовать только официальные, которые нам не подходили. В определенный момент такие мелочи становятся критичными. 

Плюсы:

+ одновременная работа в реальном времени над одним документом;

+ удобная работа с текстом и форматированием.

Минусы:

- ограниченный поиск;

- сложная иерархия папок;

- неудобная работа с изображениями;

- отсутствие кастомных шаблонов;

- слабая интеграция со сторонними сервисами.

Confluence 

Изначально показался нам идеальной заменой, но когда копнули поглубже — мнение изменили. 

На проекте мы постоянно работаем с гуглдоками не только для описания фичей, но и для управления игровым контентом и балансом. Поэтому сразу решили, что конфиги у нас останутся в Google Drive, какой бы инструмент мы в итоге не выбрали.

Другой решающий момент — нельзя редактировать страницу нескольким сотрудникам одновременно (как раз по этой причине долгое время не уходили с гуглдоков, где такая возможность есть). В онлайне у нас над одним документом может работать 5-6 геймдизайнеров, поэтому в Confluence приходится либо шарить экран, либо постоянно сохранять изменения.

Плюсы: 

+ тесная интеграция с Jira;

+ удобная работа с текстом и форматированием;

+ хороший поиск;

+ наглядное отслеживание изменений на страницах.

Минусы:

- нет совместной работы над одним документом в реальном времени;

- низкая скорость отклика пользовательского интерфейса и его неудобство.

Notion

Notion объединил в себе все сильные стороны первых двух инструментов, приправив все это новыми возможностями и скоростью работы, которые перекрыли фактически все запросы сотрудников.

Решили переезжать на него всем отделом ГД и, по мере работы над задачами, переносить всю старую документацию. Но перед этим:

• формализовали и согласовали процесс работы с инструментом;

• сделали страницу онбординга для сотрудников, где подробно описали принципы работы инструмента, составили гайды, шаблоны и полезные лайфхаки;

• провели презентацию для команды и показали демо;

• раздали доступы сотрудникам.

Совсем отказаться от Google Документов, разумеется, не получилось, но организовать удобные процессы для геймдизайнеров — вполне:

1. Confluence оставили для высокоуровневого описания бизнес-процессов компании (регламенты, процессы, инструкции — все то, что может быть полезно сотруднику). Каждый сотрудник имеет к ним доступ.

2. В Notion переместились геймдизайнерские документы, аналитические отчеты и комьюнити отчеты.

3. А в Google Sheets остались конфиги для работы с контентом. 

Теперь передаю слово моему коллеге @ArtemAnisin, Head of LiveOps, который изначально и предложил Notion. Он расскажет, чем же хорош инструмент, как мы на него переезжали и организовывали внутри, а также плюсы и минусы.

Переезд на Notion

Шаг 1. Создаем рабочие пространства 

Первым шагом (помимо самой регистрации инструмента) сделали рабочие пространства. Каждый может просматривать любое содержимое, но редактировать только свое: геймдизайн, комьюнити, аналитика. Доступ трехуровневый: view, edit, admin. Admin — один аккаунт, view — только для просмотра, edit выдается всем, кто работает с инструментом в рамках своего пространства. 

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

Раздел фоллоу-апов для редактуры доступен всем, но, если нужно, то можно поставить запреты. Можно вообще расшарить доступ даже тому, кто не зарегистрирован в Notion — например, гостя-блогера, чтобы показать ему какую-то фичу. Он не сможет ничего менять, а только ознакомиться в удобном формате.

КМ используют Notion для предоставления оперативной отчетности: готовят опросники, исследования, ретроспективы. Все это сильно пересекается с ГД — они берут эти данные для аналитики, принятия решений и так далее. Все, что касается описания кухни и внутренних процессов отдела комьюнити — составление контент-плана, график публикации, список ресурсов — описывается в Confluence в отдельном пространстве, как и HR. 

Как уже говорилось выше, основная работа по проекту ведется в Jira — создание эпиков, тикетов, выполнение задач и движение до релиза. При этом в эпиках по геймдизайну обязательно есть ссылка на документ в Notion.

Шаг 2. Придумываем шаблон документа

Мы сделали универсальный шаблон, на основе которого создаются гейдизайнерские документы. Внутри есть все, что нужно учесть при разработке фичи. Сотрудник делает пару кликов и получает готовый заполненный шаблон для ТЗ: подготовка, проблемы, гипотезы, юзерстори, девелоперстори так далее.

Каждый геймдизайнерский документ состоит из двух фаз: подготовка и реализация. В каждом прописаны необходимые тезисы, которые обязательно нужно отразить в итоговом документе, а также приведены примеры.

1. Подготовка (препродакшен). Здесь в несколько пунктов описывается целесообразность разработки фичи:

• Проблема. Какую проблему хотим решить, откуда она и почему ее нужно решить;

• Гипотеза. Что нужно проверить;

• Цель / Описание фичи. Что хотим получить в результате;

• User Story, Player Story, Developer Story. Описываем фичу в виде сценариев для игрока и разработчика.

2. Реализация (продакшен). Если фича прошла первую фазу подготовки, то здесь уже описывает конкретная реализация:

• Ресурсы. Что понадобится для реализации фичи: конфиги, арты;

• Аналитика, Статистика, EventLog. Что требуется по аналитике, какие данные нужно отследить;

• GUI. Описание интерфейсов;

• Code. Техническое описание алгоритмов, конфигов, параметров настроек и так далее;

• Localization. Ключи локализации.

Проблема Google Диска как раз в том, что было непонятно, где находится шаблон, как его искать и так далее. А здесь достаточно нажать new —> GDD template —> генерируется шаблон, и в нем сразу можно писать, даже копировать ничего не нужно.

Документами в любой момент можно делиться по ссылке во вне, экспортировать в PDF или markdown. 

Окно редактирования напоминает Confluence — все интуитивно и понятно. Но по юзабилити в разы лучше, особенно по времени отклика. Все нужные инструменты форматирования на месте: редактирование текста, заголовки, шрифты, добавление картинок и видео (с визуальным контентом теперь одно удовольствие работать).

Одна из крутейших возможностей — шорткаты, позволяющие очень быстро модифицировать, менять и перестраивать текст. Например, быстро заменить блоки текста на список или to-do.

Большой плюс Notion — огромное количество различных инструментов и интеграций, база которых постоянно растет. Например, в Notion можно нативно на страничку встроить интерфейсы Miro или Figma — такие embed-штуки, которые быстро работают и красиво выглядят. И не придется никуда переходить, в рамках одного документа будет только то, что к нему относится.

Шаг 3. Проектируем базу данных

Теперь нужно организовать сам формат хранения документов. Notion можно описать как огромную базу данных — все документы в ней хранятся в виде древовидной системы страниц и разделяются с помощью тегов. 

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

Внутри каждого отдела все организовано примерно одинаково: есть таблица, в ней документы, кастомные теги, исполнители, даты и так далее. Все это так или иначе похоже на любой таск-трекер с важным отличием — любой документ в Notion можно легко найти хоть через несколько лет с помощью гибкой системы тегов.

Теги, они же Лейблы, — это кастомные фильтры, по которым можно выделить и упорядочить нужные в данный момент документы. У нас они подразделяются на несколько групп.

1. Статусы документов (чтобы понять, на каком этапе находится документ):

• Idea — есть идея для фичи;

• Discuss — находится на стадии обсуждения;

• Preproduction — подготовка, описание проблемы, гипотез, юзерстори и так далее;

• Development — находится в разработке;

• Done — фича готова;

• Released — фича выпущена в прод.

2. Типы документов (чтобы понять содержание документа): 

• Research — исследование по фиче;

• Develop — фича, которая уйдет на разработку; 

• Processes — описание рабочих процессов;

• PostResearch — аналитика и пост-исследование; 

• Checklist — какие-либо чек-листы для проверок;

• Presentation — презентация фичи.

3. Типы фичей (чтобы понять, к каким направлениям относится документ):

• Core, Meta, UI, UX, Monetization, Art, Analytics и так далее.

4. Сроки, исполнители и все остальное: 

• Ответственный, дедлайн, ссылки на эпики в Jira и чаты в Slack, номер релиза, дата последнего обновления документа, кем оно было сделано и так далее.

На основе тегов и выстраивается вся база данных, которая частично совмещает в себе и таск-трекер вроде Jira, и инструмент для совместной работы вроде Confluence. Выглядит она как простая и понятная табличка, где каждый столбец по своей сути является лейблом, а значит — фильтром. 

Все документы содержатся в одной базе данных с возможностью разделения по тегам и виду отображения. Можно, например, включить все готовые документы или уже выпущенные в релиз, отсортировать по статусу, версии апдейта и так далее. В Confluence или Google Документах такого и близко нет. Причем не важно, сколько именно документов у вас будет храниться, все работает крайне быстро. 

Как и в Jira, можно менять вид отображения базы данных и фильтровать нужные документы: от простой таблицы до календарного представления и канбан-доски с механикой перетаскивания задач. Тут кому как удобнее.

А так, например, выглядит календарный вид отображения — когда нужно посмотреть дату обновления документа или дедлайн.

Плюсы, минусы и будущее

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

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

В будущем планируем улучшить документы онбординга для новых сотрудников и подробнее описать внутреннюю организацию инструмента. Еще добавить интеграцию со Slack, чтобы при смене статуса документа он отправлялся в личку. То же самое планируем сделать и в Jira — связать тикеты и документы.