Немного магии. От идеи до продукта в AR студии

Как работает проектный менеджер в студии разработки проектов дополненной реальности? С какими проблемами сталкивается и от чего получает удовольствие?

Рассказывает Ольга Воронцова, Head of Project Operations в Magic Quick.

Большая часть проектов приходит к нам уже с готовой идеей. Однако бывают клиенты, которые где-то что-то слышали про дополненную реальность и хотят использовать её. В таком случае мы собираем креативную группу. В неё входят лиды от разных направлений, которые впоследствии будут участвовать в реализации всего проекта: bizdev, продукт, разработка, арт и UX. На выходе мы определяемся какую концепцию будем реализовывать и по ней пишем ТЗ.

На основании этого клиентского ТЗ менеджер собирает команду и создаёт внутреннее ТЗ, которое можно обсуждать всей командой продакшена.

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

Пара слов о том, почему мы работаем в Notion.

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

Сейчас мы посматриваем в сторону продуктов Atlassian. Как таск-трекинговая система Jira объективно лучше. Notion больше похож на Confluence, который, кстати, с Jira очень хорошо интегрируется.

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

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

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

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

Как правило, начинаем с интерфейса. От этого будет зависеть, как в UI будут вписаны 3D модели и какую функциональность необходимо будет реализовать разработчикам. По интерфейсу всегда хорошо понятно какой будет пользовательский путь.

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

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

Что может пойти не так?

Во-первых, есть чисто субъективное мнение у заказчика, как должен выглядеть проект. Особенно если нет чётких референсов. Как показывает практика, если референсы есть, то обычно бывает немного правок. Если референсов нет, то попасть с первого раза в то, что хочет заказчик сложно. Поэтому здесь мы сталкиваемся с субъективными вещами из серии «мне просто не нравится».

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

Если заказчик просит поменять что-то, основанное на субъективном мнении, почти во время сдачи проекта, приходится объяснять и договариваться. У нас UI — не просто картинка. UI отражает полноценный пользовательский опыт взаимодействия с продуктом. Каждый элемент UI зачем-то нужен. Он функционален. Либо он несёт нагрузку смысловую, либо, если это даже просто какая-то иконочка или идентификатор чего-то, он обязательно должен в себя включать какой-то смысл.

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

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

Так как технология очень молодая, клиенты не всегда сами понимают, как работает дополненная реальность и приходится по ходу цикла производства им какие-то вещи объяснять.

Мне нравится, когда получается увидеть результат. Когда ты можешь что-то потрогать на девайсе. В этот момент наступает стадия, когда даже при наличии багов и большого объёма работы впереди, ты понимаешь, что создаёшь что-то, чего ещё не было. Несколько недель назад это было только в виде концепции на бумаге. Сейчас у тебя уже в руках то, чем ты можешь пользоваться. И ты принимал в этом участие. Продукт создан именно таким благодаря твоим принятым решениям. И это самая настоящая магия, ради которой хочется делать всё больше проектов хороших и разных.