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

У нас очень серьезные компетенции в разработке мобильных приложений, создании крутецких сайтов, сложных веб-сервисов и 3D-графики с анимацией.

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

Сложности работы над приложением

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

Но что есть, то есть. Сделать хорошее приложение, которое будет удобным для пользователей и способным решать задачи бизнеса (для которого эти приложения и делаются) непросто. Разработка включает в себя:

• изучение желаний клиента;
• проработку интерфейсной логики;
• разработку дизайна;
• программирование;
• тестирование;
• и много всякого другого.

Вот от этого одному человеку сложно (а обычно и просто невозможно) сделать хорошее приложение самостоятельно, каким бы талантом он не был. Нужна опытная и профессиональная команда, которая у нас есть. Да, нам и нашим клиентам повезло.

Конструкторы приложений: за и против

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

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

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

Более того, Apple очень строго проверяет приложения при загрузке в App Store. Политика компании требует от бизнеса загрузки только качественных приложений с уникальным дизайном. Сделанные на шаблоне приложения зачастую просто невозможно загрузить в App Store, а все вложенные в них силы и деньги уходят в никуда.

Да-да, конструкторы тоже стоят денег, причем, бизнес-тарифы у многих приложений обходятся в среднем по $200 в месяц, что не так уж и мало.

Как работаем мы

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

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

За годы существования ARJay мы выработали достаточно простую, понятную нам и клиентам схему, позволяющую создавать качественные решения.

Итак:

Долгие консультации

Кто-то скажет, что длительное общение с клиентом на первой стадии сотрудничества — трата времени. А мы не согласимся. Мы долго и душно обсуждаем задачу, чтобы разобраться в желаниях заказчика.

Очень часто клиент приходит с определенной идеей, но когда мы начинаем ее обсуждать и «примерять» к реальным бизнес-задачам, оказывается, что нужно совсем не это, а что-то кардинально иное. Мы можем изучить задачу и предложить оптимальное ее решение, поэтому делаем приложения, которые приносят выгоду и причиняют добро.

Конечно, если клиент уверен, что лучше осознает, что именно ему нужно, мы соглашаемся и делаем то, что он хочет. И иногда клиенты возвращаются с доработками по ранее предложенному функционалу.

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

Создание техзадания

Когда обсуждение заканчивается, и мы окончательно убеждаем клиента, что мы Лев Толстой на словах (и не только!), переходим к разработке ТЗ. Клиент, конечно, может прийти уже с готовым техническим заданием, однако исчерпывающая информация в самописных заданиях встречается крайне редко, даже если к ТЗ прикладывают руку неглупые IT-специалисты на стороне клиента.

Если хоть какое-то ТЗ есть, мы его актуализируем, подробно прописываем все требования и предстоящие работы. А если ТЗ нет вообще, мы его делаем с нуля под запрос клиента.

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

А если не будет сделано как надо, у него будут все необходимые документы, чтоб предъявить нам законные претензии. Но до сего дня такого не случалось.

Дорожная карта

На техзадании, к сожалению (или счастью), прямое взаимодействие с клиентом не завершается. На следующем этапе создаем подробную дорожную карту, в которой описываются предстоящие работы с привязкой к точным датам и дедлайнам.

В ней содержатся все предстоящие работы и клиент может:

• отслеживать процесс разработки;
• контролировать работы.

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

Формирование команды

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

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

Проектирование

Работы по каждому приложению начинаются с разработки User Flow или «Пользовательского пути» использования готового решения. Грубо говоря, это визуализация всего пути человека с момента запуска приложения до решения его конкретных задач и достижения начальных целей.

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

Почему Юзерфлоу реально нужны? Ну, допустим, приходит заказчик на создание приложения. Нормальная схема работы предполагает создание дизайна, после чего пишется код тестового продукта (про это ниже расскажем) и выясняется, что выбранный вариант будет пользователю не удобным. Кнопка расположена не там, все потребности не закрыты, на нужные экраны попасть невозможно и т.д. В такой ситуации приходится:

• перерисовывать дизайн;
• переписывать код.

А все это требует времени и денег. Использование User Flow позволяет на этапе прототипирования предусмотреть путь пользователя, определить особенности эксплуатации приложения, выбрать оптимальные элементы интерфейса и их расположение, продумать навигацию и связанные экраны.

Дизайн

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

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

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

Программирование

На поздних стадиях создания дизайна начинают работы программисты. Для сложных решений мы создаем MVP — минимальный жизнеспособный продукт со всем необходимым функционалом, но не полным дизайном, чтобы протестировать работу и эффективность решения. MVP обычно создается, когда готово 90-95% дизайна.

Если все в порядке, то на основе MVP собирается уже полностью жизнеспособный продукт, отвечающий всем заявленным требованиям клиента.

Тестирование

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

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

Конечно, весь наш небольшой рассказ — это максимально краткое описание рабочего процесса, которое не затрагивает многих важных технических моментов. Однако мы не ставим перед собой задачу полностью объяснить что и как мы делаем, в эти подробные сведения мы посвящаем клиента на предварительных консультациях. Не зря же мы на них выделяем много времени!