Идея
Как бы тривиально это не звучало, но хорошее приложение начинается с хорошей идеи. Если у вас её нет, подумайте над существующими в мире проблемами и возможными способами их решения. Перебирайте варианты, пока не обнаружите подходящий пробел на рынке, а потом ищите лучший путь, которым его можно заполнить. Это половина успеха.
Ключом к ответу может стать понимание того, почему эта проблема вообще существует, а для её решения до сих пор нет ни одного приложения. Погрузитесь в тему, соберите данные и обсудите их с командой. И, если у вас достаточно ресурсов на разработку, беритесь за дело.
Подготовка
Следующий шаг после рождения идеи – составить план работы над проектом. Его проще всего начать с анализа конкурентов. Найдите на рынке похожие мобильные приложения и проанализируйте следующие факторы:
- Количество загрузок – если приложение загружают, значит, это кому-нибудь нужно.
- Оценки и отзывы – помогут предусмотреть слабые места и адаптировать «фишки», которые нравятся пользователям, под свой продукт.
История компании – будьте готовы столкнуться с теми же трудностями, что и ваши ближайшие конкуренты. Заодно попробуйте понять, как они завоевали признание аудитории.
Благодаря анализу конкурентов вы убиваете сразу двух зайцев. Во-первых, учитесь на чужих ошибках, причём бесплатно, без траты лишнего времени и ощущения собственной неполноценности. Во-вторых, вы начинаете понимать, на что вам придётся пойти, чтобы выжить на рынке мобильной разработки. Что именно пользователь хочет увидеть в своём смартфоне? Есть ли для вашего приложения свободная ниша? Ответы на эти вопросы помогут вам найти баланс между вашими возможностями и потребностями рынка. Ну а если ваша идея настолько уникальна, что подобных приложений ещё нет в природе, посмотрите, как разработчики-первопроходцы из других сфер презентовали себя аудитории.
Монетизация
Если вы не занимаетесь разработкой мобильных приложений исключительно ради удовольствия, то наверняка заинтересованы в том, чтобы получить с продукта хорошую прибыль. Покупки в приложении, оплата подписки или премиум-версии, размещение рекламы, продажа данных – все эти способы монетизации можно использовать, даже если вы распространяете приложение не бесплатно. Чтобы выбрать оптимальный вариант, посмотрите, на чём зарабатывают ваши конкуренты, и определитесь, в какой момент начнёте монетизацию. Если спохватитесь слишком поздно, рискуете попасть в трудные времена.
Маркетинг
Эта ступень мобильной разработки связана с пониманием главного вызова, стоящего перед любым разработчиком. Вам придётся продвигать своё приложение, чтобы о нём узнали и начали пользоваться. Сотни качественных мобильных приложений пылятся на виртуальных полках потому, что у их разработчиков не было маркетинговой стратегии и бюджета на её реализацию. А без неё могут обойтись только B2B-приложения, сделанные для внутреннего использования сотрудниками компании-заказчика.
Дорожная карта продукта и MVP
Этап стратегического планирования завершается составлением дорожной карты вашего мобильного приложения, которая зафиксирует его идеальный путь от минимального жизнеспособного продукта (MVP) до попадания в топы магазинов. Составьте список контрольных точек и расставьте их в зависимости от собственных приоритетов. Учитывайте функционал приложения, возможные пожелания аудитории и следующие из них обновления. Но над ними вы будете думать, когда получите фидбек от первых пользователей MVP. Пока же можно сосредоточиться на других вещах.
Внутренняя архитектура
Внутренняя архитектура зависит от функционала мобильного приложения и выбранного способа обработки и хранения данных. Обычно мы составляем два списка – характеристик, которыми должно обладать приложение, и ключевых визуальных элементов. Они становятся фундаментом для всех будущих архитектурных работ.
Инструменты: доска и маркеры. Много маркеров.
Вайрфрейм
Затем мы рисуем на доске или бумаге экраны и располагаем на них необходимые элементы и данные. Несмотря на то, что один и тот же элемент может присутствовать на нескольких экранах, у него должен быть «дом». Именно на этом этапе в проект можно внести любые изменения.
Пользовательские сценарии
Они определяют способы взаимодействия пользователя с приложением. Учитывайте все варианты его поведения, чтобы понять, сколько касаний ему потребуется для завершения того или иного действия, причём количество этих касаний должно быть пропорционально сложности действия. Если обнаруживается, что интерфейс не понятен пользователю интуитивно, приходится возвращаться к предыдущему шагу и менять вайрфреймы. При этом после любого изменения все пользовательские сценарии проверяются заново на случай, если мы, упростив одно действие, усложнили другое.
Проверка на аудитории
Самый простой способ проверить, насколько хорош ваш UX-дизайн – протестировать его на будущих пользователях. Отправьте им ссылку, после перехода по которой они смогут «потыкать» по отрисованным вайрфреймам. О функциональности речь не идёт, только о проверке навигации. Прислушивайтесь к комментариям, возвращайтесь на один-два-три шага назад, исправляйте проблему и тестируйте. Снова и снова.
Стайлгайды
Стайлгайды – это стройматериалы для отделки «интерьера» мобильного приложения и повышения его юзабилити. Без продуманного стайлгайда элементы дизайна будут менять цвета и плавать по экрану, сбивая пользователя с толку.
Руководство по стилю мобильного приложения должно быть максимально подробным и опираться на характеристики аудитории. Ей нужно работать в приложении по ночам? Делаем тёмную тему. Это внутреннее приложение для сотрудников крупной компании? Убираем всё лишнее. Как это сделать? Опытный UI-дизайнер предложит сотню вариантов цветовой палитры, шрифтов и виджетов (кнопок, форм, значков и т.
Рендеринг
Рендеринг – это процесс отрисовки вайрфреймов в цифре в соответствии со стайлгайдом. Дизайнер должен придерживаться рекомендаций, но не следовать им слепо. Только так визуальная составляющая мобильного приложения будет выглядеть целостно.
Проверка дизайна
Не стоит жалеть времени на то, чтобы отправить отрисованные в диджитале экраны тем же пользователям, которым отправляли вайрфреймы. Это своего рода переломный момент, после которого любые изменения становятся крайне затратными. По сути, вы заливаете фундамент будущего дома, так неужели не надо свериться с планом и десять раз проверить все измерения?
От дизайна к разработке
Настало время подключать разработчиков, которые качественно реализуют продуманный до мелочей и многократно протестированный дизайн. Что может пойти не так? Например, вы заказали дизайн у одной компании, а разработку – у другой. Или у них внутренний раскол. Поэтому рекомендуем работать с профессиональной командой, которая занимается мобильной разработкой от идеи до результата.
В некоторой степени успех совместной работы дизайнеров и разработчиков зависит от выбора инструментов. Например, приложение Zeplin показывает последним все свойства загруженного в него дизайна, хотя не обладает всеми возможностями Sketch или Photoshop. В любом случае, убедитесь в том, что команда пользуется точными значениями измерений и не ленится копировать HEX-коды цветов.
Архитектура системы
В мобильной разработке существует великое множество технологий. Одни почти не требуют затрат, но не отличаются высокой производительностью, другие потребуют больших вложений во имя блестящего результата. Худшее, что вы можете сделать на данном этапе – использовать устаревшие или ненадёжные инструменты, которые приведут к тому, что вам придётся переписывать код, доплачивая остальным членам команды за переработку. Чтобы избежать этого, рекомендуем принять ряд важных решений до начала работы над проектом. Каких именно, расскажем ниже.
Разработка и итерация
Как вы могли понять из начала нашего гайда, разработка мобильного приложения состоит из множества этапов. Разобраться в следующих будет в разы проще, если вы слышали про Scrum — метод управления проектами, который подразумевает разбивку рабочего процесса на небольшие отрезки – спринты. В каждом из них есть стадии планирования, разработки, тестирования и подведения итогов. Скрам – один из подходов методологии Agile, о которой написано множество книг, поэтому глубоко вдаваться в терминологию мы не будем. Тем более, что какими бы методами не пользовалась та или иная компания, этапы работы над мобильным приложением будут примерно одинаковыми.
Планирование
Чтобы спланировать спринт, составьте список задач с конкретными критериями оценки результата. Это поможет разработчикам оценить временные затраты на выполнение каждой из них и равномерно распределить обязанности внутри команды.
На этапе разработки команда воплощает в жизнь идеи дизайнеров и свои собственные. Результат проверяет QA-команда (отдел контроля качества) или менеджер проекта. Последний также распределяет задачи между разработчиками, добиваясь равномерной загрузки команды на протяжении всего спринта.
Разработчики должны чётко представлять концепцию приложения и его отличительные черты. Ничто так не мотивирует, как амбициозные цели, но в погоне за ними нельзя забывать о реальности. Возможно, вам придётся смириться с тем, что часть функций так и останется нереализованной.
Тестирование
Тестировать приложение не должны его же разработчики.
Тип тестирования выбирают исходя из проверяемой характеристики приложения:
- Функционал – должен соответствовать заявленному. Хорошо, если у подрядчика есть QA-команда, а у неё – план тестирования со списком всех функций приложения и его желаемым поведением. Но если таковой нет – необходимо позаботиться об этом и нанять специально обученных специалистов. Юзабилити – интерфейс мобильного приложения должен быть интуитивно понятным и дружелюбным. О проблемах с этими качествами вам лучше всего расскажут те, кто видят продукт впервые.
- Производительность – никто не будет пользоваться приложением, которое грузит рабочий экран больше 10 секунд. И хотя производительность обычно тестируют на более поздних стадиях разработки, следить за временем отклика надо уже сейчас.
- Дизайн – тут дизайнерам придётся ещё раз включиться в работу и удостовериться в том, что каждая деталь визуального стиля была реализована разработчиками в соответствии со стайлгайдом. Кстати, это ещё одна веская причина работать с компаниями, которые занимаются и разработкой, и дизайном.
Но и это ещё не всё:
- Регрессионное тестирование – используется для проверки уже протестированного кода на ошибки, исправленные ранее, или возникшие в результате этих исправлений. Здесь на помощь вновь приходит QA-команда с чек-листами изменений, внесённых в код на каждом из спринтов.
- Тестирование под платформу – существует бесчисленное количество комбинаций мобильных устройств и установленных на них операционных систем. Посмотрите, как приложение работает на смартфонах с разными размерами и разрешениями экранов, и запустите его на всевозможных версиях ОС.
- Приемочное пользовательское тестирование – проводится будущими пользователями приложения и показывает, готов ли продукт к выходу на рынок. Собирайте отзывы и готовьтесь к старту, только если только ваше приложение с блеском прошло все предыдущие проверки.
Анализ
В конце каждого спринта обсуждайте его результаты с заинтересованными сторонами. Сделайте выводы из трудностей, с которыми вы столкнулись, и постарайтесь больше их не допускать. Отмечайте успешные решения и используйте их в дальнейшем. Двух одинаковых проектов быть не может, поэтому разработчики постоянно прокачивают свои навыки, в том числе – навыки планирования работы над проектом. Который, кстати, переходит в следующую стадию.
Перед запуском
К этому моменту приложение (или хотя бы MVP) должно быть полностью готово к выходу на рынок. Но если вы хотите потратить маркетинговый бюджет с умом, то размещать приложение в публичный доступ Google Play и Apple App Store пока рано. Нужно ещё раз протестировать его — на этот раз на небольших группах целевой аудитории. Сделать это можно двумя способами.
Фокус-группы
Первое правило фокус-группы — участники должны увидеть приложение впервые. Вам необходимо выяснить, кто они, откуда узнали о вашем продукте и пользуются ли чем-то похожим. Когда перейдёте непосредственно к тестированию, не давайте подсказок, а наблюдайте за тем, какие сложности возникают у людей в процессе использования приложения. Затем попросите каждого участника высказаться и обсудите все спорные моменты.
Бета-тестирование
Вместе с фокус-группой (или вместо неё) можно устроить пробный запуск приложения для ограниченной аудитории опытных пользователей и охотников за новинками. Обязательно скажите им, что цените их интерес, попросите фидбек и пообещайте принять во внимание конструктивную критику. Кстати, бета-тестирование также позволяет проверить, как ваше приложение работает с разными устройствами и операционными системами.
Помните: лучше получить как можно больше подробных отчётов об ошибках и исправить их, чем не получить ни одного и узнать о проблеме от недовольных комментаторов из магазинов.
API-сервер
Большинству мобильных приложений нужен backend-сервер, который обменивается данными с ними. Если сервер перегружен или не отвечает, приложение не будет работать. Хорошая новость: благодаря облачным технологиям конфигурацию сервера можно менять в зависимости от размера пользовательской базы.
Магазины приложений
Разработка мобильного приложения не заканчивается с его публикацией в сторах. Даже за умеренно популярными приложениями стоит целая история обновлений. Исправленные ошибки, улучшение производительности, новые возможности – поводов масса. Выбрать нужный именно вам поможет мониторинг следующих аспектов.
Падения
Для отслеживания падений приложения есть немало библиотек. Они хранят информацию о том, что делал пользователь во время падения, на каком устройстве оно произошло и многое другое – в общем, всё, что поможет разработчикам решить проблему. Кроме того, функцию отправки сообщения о падении можно встроить в само приложение. Вам останется только рассортировать их.
Аналитика
Современные системы аналитики мобильных приложений собирают информацию об аудитории вашего приложения (распределение пользователей по полу, возрасту, местонахождению, языку и т. ) и особенностях взаимодействия с ним (времени входа в приложение, времени, проведённом в приложении, количестве просмотренных экранов и пр. Некоторые даже составляют тепловые карты, которые показывают, на какие кнопки пользователи нажимают чаще остальных. Используйте эти данные как ориентиры на будущее: вкладывайтесь в доработку тех областей, в которых концентрация действий аудитории наиболее высока.
Производительность
Этот показатель нельзя измерить двумя предыдущими способами, но следить за ним необходимо. Как часто происходило то или иное действие и как долго оно длилось – вот вопросы, которые помогут оптимизировать работу приложения. Если простейшее действие занимает больше времени, чем ожидалось, это тревожный сигнал.
Поддержка репутации
Оценки и отзывы в магазинах крайне важны, особенно для новых приложений. Всегда отвечайте комментаторам: благодарите за хорошие слова и постарайтесь помочь тем, кто столкнулся с трудностями при использовании вашего приложения. Комментаторы обычно не ожидают, что им ответят реальные разработчики. Чуть больше клиентоориентированности – и две звезды превращаются в пять, а ваша репутация взлетает до небес.
Дальнейшие улучшения
Цель мониторинга – понять, что делать дальше. Используйте статистику и отзывы, чтобы выявить слабые места, а потом возвращайтесь на n шагов назад и укрепляйте их. Повышайте конверсию пользователей в покупателей, расширяйте клиентскую базу, зарабатывайте, в конце концов. Ведь мобильная разработка – это очень динамичная среда, и, чтобы быть на плаву, надо постоянно работать над продуктом и над собой.
Какие тренды проявились в онлайне
По данным SlickJump, в 2020 году он достиг 80% в рунете. Это окончательно оторвало пользователей от привычных десктопов и заменило традиционные приложения на их веб-аналоги.
Веб-сервисы, в отличие от традиционного ПО, позволяют вносить доработки так, чтобы все пользователи автоматически получали последнюю версию, не скачивая обновления. Это дает возможность быстро менять функционал IT-продуктов, добавлять и тестировать новые функции.
Веб-технологии стали доступнее, выросло число пользователей интернета — появилась возможность быстро запускать бизнес на основе несложных веб-решений сразу на широкую аудиторию.
Компании запускают онлайн-каналы продвижения или полностью переходят в интернет.
Причем как количественно — за счет появления новых игроков, так и качественно — за счет расширения клиентской базы.
Итого: конкуренция усиливается, а цикл обновления и жизни продукта сокращается.
Что мы не учли и к чему это привело
Мы прошли шесть шагов до ТЗ, но все-таки допустили просчеты. Что можно было сделать иначе для лучших результатов:
Я сам как владелец продукта разрабатывал концепцию платформы в свободное от других задач время. Мы привлекали сотрудников, занятых на других проектах. Разработка MVP затянулась более чем на полгода. Если бы работала выделенная команда, проект реализовали бы быстрее и проще.
Можно было создать сайт не на «Тильде», а на «Битриксе». Тогда на верстку ушло бы меньше времени — через админ-панель было бы удобнее выкладывать контент.
Мы недооценили себестоимость создания цифрового образа эксперта. Эта работа состояла из нескольких этапов: отправка вопросов и получение заполненной анкеты, интервью с экспертом, написание, согласование и верстка текста для его персональной страницы. Всего на каждого эксперта уходило пять-шесть часов.
Когда мы начали продвигать платформу с помощью разных инструментов: презентаций на бизнес-мероприятиях, рассылок, посевов в соцсетях и Telegram-каналах — на нас хлынул поток заявок от экспертов. Ресурсов на обработку стало не хватать. На первом этапе можно было сконцентрировать усилия только на привлечении клиентов, но не расширять пул консультантов.
Как оптимизировать затраты и получить максимум
- Перед составлением ТЗ проделайте подготовительную работу и определите, какой минимальный функционал можно реализовать для запуска продукта.
- Не тратьте много времени на теорию и концепцию — сосредоточьтесь на том, что можно быстро реализовать, чтобы протестировать спрос.
- Проверяйте на старте гипотезы о болях и предпочтениях клиентов. Но не запускайте масштабное исследование рынка — в большинстве случаев можно уложиться в 7–10 дней.
- Стремитесь получить результат с минимальными затратами. Продумывайте каждый шаг: для чего мы это делаем? как упростить процесс? Можно использовать метод анализа «Пять почему». Он заключается в том, что первопричину проблемы определяют с помощью пяти последовательных ответов на вопрос «почему?».
- Не делайте лишнюю работу: лучше отказаться от сложных и трудозатратных решений в пользу простых и функциональных.
Фото на обложке: mojo cp/shutterstock. com
Что нужно сделать, чтобы стать хорошим программистом
Нельзя стать хорошим разработчиком, если не создавать проекты. Но никто не должен решать за вас, какие проекты вам подходят.
vlada_maestro / shutterstock
Если нет эмоциональной связи, то вы теряете интерес и бросаете проект, чтобы начать что-то другое и на этот раз сделать всё правильно. А потом делаете то же самое с новым проектом. И с ещё одним / двумя / пятью / десятью / пятьюдесятью. Разумеется, вы получите опыт, но вместе с ним — и груз в виде брошенных проектов.
Если же изначально брать что-то очень сложное, то в любом случае вы останетесь победителем. Справились — отлично, теперь вы знаете, что можете работать над сложными проектами. Не получилось — тоже хорошо, такой опыт не на каждой задаче получишь. Какой толк от 100500 одинаковых приложений? Нужно учить программистов не делать что-то под копирку, а создавать новое. Или хотя бы решать проблемы. Это поможет стать более ценным специалистом. Потому что вы будете понимать, что нужно бизнесу, и всегда сможете запрограммировать как надо или предложить альтернативу. Например, заказчику нужно на сайте изменить какую-то надпись. Допустим, поменять сообщение, которое уведомляет об использовании cookies, или заменить на сервере файл политики конфиденциальности. Обе задачи на 5 минут: 3 минуты, чтобы запустить редактор кода и FTP-клиент, по одной минуте на каждую задачу. Но если подумать, то можно найти решение лучше. Например, можно предложить заказчику добавить новые настройки в панель администратора, чтобы он мог выполнять такие мелочи самостоятельно. Тогда вы сможете тратить своё время на что-то более полезное, а не отвлекаться 10 раз, потому что в надписи, которую вы добавили, была опечатка.
Учись бесплатно: вебинары по программированию, маркетингу и дизайну.
Курс для тех кто мечтает о работе в IT, но не знает, с чего начать, или переживает, что ничего не получится. Мы поможем вам преодолеть все страхи и пройти весь путь к новой профессии: от выбора IT-направления до трудоустройства.
Узнать про курс
Обучение: Профессия Разработчик
Отсутствие фиксации договорённостей со стейкхолдерами
Момент, которым нельзя пренебрегать в самом начале — обсуждение ожиданий от продукта со стейкхолдерами — людьми или организациями, которые способны оказать влияние на развитие проекта.
На старте определите и согласуйте со всеми стейкхолдерами цели и планируемые результаты.
Ожидания от продукта задают требования к результату и существенно влияют на дальнейшую работу всей команды. Согласование помогает избежать возможных недопониманий и разногласий по развитию проекта.
Простое решение: составьте текстовый документ или таблицу, где будут собраны ожидания стейкхолдеров. Чтобы упростить себе жизнь, вы можете воспользоваться нашей подсказкой по структурированию содержания.
В документе важно не просто зафиксировать ожидания всех и каждого, но и привести пожелания к общему знаменателю. Цель должна быть единой, понятной и одобрена всеми участниками.
После формирования документа синхронизируйте его с командой (наверняка вам подкинут ещё пару-тройку идей) и смело отправляйте стейкхолдерам, чтобы финально согласовать все моменты.
Вариант посложнее: железная команда аналитиков и дизайнеров Redmadrobot на этапе старта проекта всегда собирает паспорт продукта — документ с описанием характеристик и основных целей.
Он содержит в себе ключевые показатели и выступает в роли ориентира для дальнейшего развития проекта или группы проектов. Если хотите избежать проблем, то его нужно проработать, синхронизировать с командой (собрать всевозможные идеи) и согласовать со стейкхолдерами.
После этого итоги согласования нужно зафиксировать для всех — разослать письма, выложить документ в облако или создать борд в Miro.
Чтобы использовать шаблон паспорта в своих целях, дополните его нужными вопросами исходя из вашей специфики
Бездумное формулирование целей и задач в команде
Одна из причин, почему идеи не выдерживают проверку временем — отсутствие «моста реализуемости». Менеджер может понимать цели стейкхолдеров и то, как их достичь, но не представлять вижн результата. Или, всё же видеть желаемый результат, но не учитывать всех трудностей, которые, вероятно, возникнут в будущем.
На выходе мы имеем старое доброе «ничего», а прикрываемся «внешними факторами», «незапланированными активностями» и «кто-то виноват, а мы не подозревали».
Шаг за шагом подробно опишите, как планируете осуществить намеченные планы.
Простое решение: вариант для самостоятельного использования — воспользуйтесь одной из проверенных временем методологий постановки задач, например, SMART. Мы часто используем в работе подходы DoD и DoR.
Но проект — дело командное, поэтому, если есть возможность планировать и думать над реализацией всем вместе, её нужно обязательно использовать.
Вариант посложнее: изучите вместе с коллегами одну из методологий постановки задач и грамотно её внедрите. Для этого разделите планирование результатов на несколько итераций, после чего сделайте deep dive (погружение в проект) всей команды по методологии постановки задач.
Определитесь, как вовлечь в процесс планирования и достижения результатов всех коллег и, самое важное, — проследите за тем, чтобы это сработало на нужный вам результат.
Перекладывание ответственности
Здесь всё просто: ответственность и распределение ролей в команде должны быть понятны всем участникам. В какой-то момент (а он точно может наступить, поверьте) придётся разбираться, почему что-то пошло не так и кто-то не выполнил важную задачу.
Чтобы это происходило как можно реже (а лучше не происходило вовсе) сделайте распределение ответственности в команде прозрачным. Тогда каждый сможет понять свои задачи и как от его работы зависит судьба проекта.
А в том случае, если в проекте что-то пойдёт не по плану, менеджер должен чётко понимать, в какой его части произошёл сбой. Иначе PM рискует поставить под угрозу результаты работы и деморализовать всю команду.
Одно из лучших решений для создания «прозрачности» — использовать матрицу ответственности. Её можно выбрать исходя из сложности проекта, размера команды и предпочтений.
Простое решение, если не хотите заморачиваться и у вас небольшой проект:
- Соберитесь вместе с коллегами и обозначьте, какие могут быть роли в команде. Например, менеджер — делает заметки во время встреч, а дизайнер — потом согласовывает их со стейкхолдерами — роли могут быть какими угодно, придумайте их сами.
- Прикиньте какие роли на себя может взять каждый участник команды.
- Проговорите основные обязанности каждой роли и за какой результат отвечает. Например, договоритесь, что именно менеджер назначает встречи, ведёт заметки по ходу встреч, и фиксирует их результаты; аналитик (так уж получилось, что он у нас очень чёткий парень) заводит задачи в таск-трекере и описывает их для команды; разработчики самостоятельно собирают прототипы на «Тильде», чтобы показать их стейкхолдерам или пользователям).
Главное — договоритесь о том, как планируете взаимодействовать в команде и зафиксируйте это любым удобным способом: текстом, в Miro или, например, набросайте mind map — как вам удобно.
Вариант посложнее: для крупных проектов можно сделать ролевую модель проекта в виде карты и добавить описание функций каждой роли (это можно сделать, например, в Miro).
Но сама по себе матрица принесёт мало пользы. Чтобы выстроенная система ответственности дала плоды, нужно постоянно контролировать её исполнение. Например, решать возможные последствия её распределения: избавляться от ненужного, улучшать текущее и добавлять новое.
По ходу реализации
Главная задача менеджера в ходе реализации проекта — выполнить запланированные задачи, которые приведут его и всю команду к нужному результату. Этого можно добиться, если грамотно управлять изменениями, внедрять качественные улучшения в процессах, избавляться от лишнего и постоянно получать промежуточный результат. А вот короткий список того, что может помешать вам на этом непростом пути.
Отсутствие инструментов для командной работы
В любой работе нужны инструменты, но важно внедрять лишь те, что будут способствовать развитию проекта. К сожалению, часто происходит наоборот, когда новые возможности добавляют в жизнь команды лишнюю бюрократию, вредные регламенты и другие неприятные вещи.
Применяйте в работе только те инструменты, которые жизненно необходимы для реализации проекта. Встройте их в ваши процессы и расскажите команде, как ими пользоваться.
Потом определите ответственных за техническую поддержку и актуальность работы инструментов. Вся информация в них должна периодически обновляться, быть упорядочена в соответствии с возможными правилами и доступна команде.
Простое решение: не гонитесь за модой — используйте доступные и универсальные инструменты, такие как Trello или Google-таблицы.
Благодаря своей системе карточек, Trello отлично подойдёт для распределения задач. В них вы можете фиксировать важные части проекта: процесс выполнения работ, ведение сделок и заявок, организацию документооборота и другие вещи. Ну а Google-таблицы хороши своей многозадачностью. В Redmadrobot команды часто используют их в самых разных делах:
- Планируют и ведут бюджеты проектов.
- Формируют и контролируют план, и ход простых проектов.
- Распределяют задачи.
- Фиксируют итоги ретроспектив.
- Формируют бэклог продукта.
- Планируют ресурсную загрузку всех сотрудников и отдельно каждого проекта.
- Собирают мониторы продукта и дефектов системы, и так далее.
Задача эффективного инструмента — упростить жизнь команде. Trello и Google-таблицы хорошо с этим справляются. Но независимо от ваших предпочтений, есть типы инструментов, которые понадобятся вам в любом проекте: делегирование, встречи или «синки», риск-менеджмент, каналы коммуникации и взаимодействия.
Вариант посложнее: за долгие годы нанесения непоправимой пользы нашим клиентам мы создали систему инструментов. Её может использовать любая команда, работающая в проектах разного уровня и сложности. Вы можете использовать её как базу при формировании собственного списка нужных сервисов.
Отсутствие чётких приоритетов
В ситуации, когда приоритетно всё — на самом деле никаких приоритетов не существует. Если работа кипит и проект развивается, то это ещё не значит, что команда идёт к нужному результату.
Точно определите приоритет для каждой задачи, чтобы команда понимала, что нужно сделать в первую очередь.
Так вы будете знать, как распределены усилия между коллегами и убедитесь, что цели и задачи в вашей голове совпадают с их приоритетами.
Простое решение: если у вас небольшой проект, то используйте методологию MоSCоW — она хорошо подходит для определения приоритезации. Также обратите внимание на методологии RICE и ICE.
Вариант посложнее: в крупном проекте поможет формирование собственной системы приоритезации входящих задач. Её можно построить на базе Google-таблиц или Trello.
С помощью Google-таблиц или Trello можно собрать систему с упором на потребности команды. Например, Google-таблицы позволяют настроить фильтры и формулы, которые автоматизируют учёт. Исходя из баллов, выставленных по конкретному параметру, фильтры и формулы могут автоматически выстраивать итоговый список с приоритетами, что значительно экономит время.
Про взаимодействие
Проекты реализовываются людьми, которые постоянно взаимодействуют друг с другом. Ваша задача, как менеджера — понять, как нивелировать проблемную «человеческую» часть — коммуникацию и взаимодействие. Не допускайте следующих ошибок.
Неинформирование команды
Чтобы чётко определить вектор развития проекта, эскалацию, решение проблем и запросов, важно рассказывать команде обо всех рабочих изменениях. Это касается не только коллег, но и стейкхолдеров.
Если вы узнали об изменениях в проекте, то не поленитесь рассказать об этом команде, для этого организуйте постоянное информирование всех её участников.
- Обязательно отправляйте письма на всех участников со статусом выполнения проекта. Раскрывайте: короткий текущий статус, над какими ключевыми задачами работает сейчас команда, где есть проблемы и блокеры (где требуется внимание стейкхолдеров) и каких результатов уже достигла команда.
- Определите периодичность таких писем.
- Продумайте процесс информирования с точки зрения производства. Например, при проектировании интерфейса, согласовании важных результатов или сдаче работ, вспомните про матрицу распределения ответственности и убедитесь, что на мероприятии задействованы все необходимые стейкхолдеры.
- Помните, что в нашем мире и без того много информации и каналов коммуникации. Определитесь, в какой форме и в какое время лучше информировать людей, чтобы они смогли эффективно и своевременно отреагировать на ваши сообщения.
Отсутствие реакции на изменения или критичные ситуации
Проблемы сами по себе не исчезают и не утихают, а как правило накапливаются и создают эффект бомбы с замедленным действием. Наивно полагать, что если проблему или конфликт не провоцировать, то он исчезнет.
Поэтому, каждой команде нужен понятный механизм эскалации вопросов и конфликтов. Менеджер проектов должен уметь принимать верные решения в критических и незапланированных ситуациях, и находить пути выхода из «застоя» (в ситуациях, которые требуют пересмотра).
Создайте внутри команды понятный механизм эскалации вопросов и конфликтов. Так коллеги поймут, что в любой ситуации они будут услышаны и их точка зрения имеет значение для окружающих.
Простое решение: расскажите команде про базовые правила эскалации. Для этого сформулируйте, как вы видите процесс эскалации в идеале, зафиксируйте его в виде простых тезисов. Разместите информацию в «общем пространстве», чтобы в нужный момент у всех был доступ к документу.
Вариант посложнее: сформируйте собственную систему эскалации. Для этого составьте список коллег, которые будут помогать вам в решении проблемных ситуаций и конфликтов, а также в определении стратегических действий. О возможностях инструмента эскалации и способах его организации написано много статей, поэтому, если вам интересна эта тема, просто «загуглите».
Помните, что от ваших решений зависит успех продукта. Профилактика конфликта — сигнал к тому, что команда готова открыто говорить о своих проблемах.
Несколько тезисов о формулировке проблемы
Слова в ней молчат, говорят только цифры. Проблема в неких низких коэффициентах, высоких показателях отказов, большом разбросе параметров и др. – это белые буквы на белом фоне.
Особенно громко говорят рубли/доллары. У кого-то может быть мнение, что главному инженеру предприятия важнее всего услышать технические характеристики, на то он и не финансовый директор. Но, не понимая цифр, вы не понимаете бизнеса клиента и не понимаете свой проект.
Внедрение чего-то нового в предприятиях всегда рассматривается как инвестиционный проект, где деньги, как правило, являются единственной причиной принятия решения.
По теме: «Мое овощехранилище решает одну из глобальных проблем человечества»
Одна из частых ошибок в формулировании проблемы – это ее подмена технологической задачей. Например, на слайде «Проблема» можно часто видеть что-то типа «увеличение передаваемой мощности с сохранением габаритов вариатора».
Самое главное, что отличает проработанную проблему от недоработанной, это проверка у клиента.
В пример приведу проект, который предлагал новый способ нанесения покрытий на крупные детали в сфере машиностроения. Технология экономила средства на дорогом и сложном в работе материале баббите. В проблеме обозначалось то, что текущим методом слой наносится толщиной не менее 5 мм, в то время как с помощью его технологии можно уменьшить толщину до 1 мм.
Когда команда пришла на производство, они выяснили, что в реальности проблемы не существовало. Значительная толщина слоя была обусловлена не технологией нанесения, а рядом других причин. Например, тем, что на предшествующем переделе дорого получать идеальную форму детали, и дешевле будет использовать более толстый слой покрытия, чтобы выровнять дефекты.
Конечно, далеко не всегда проблему получается сформулировать выпукло и красиво. Скажем, проблема коррозии или износа – это общие понятные места, нет нужды доказывать необходимость борьбы с ними. Или, например, вы разработали технологию производства водорода, которая такая же, как и все другие, по качеству продукта, но дешевле на 30%. В этих случая нужно просто предложить свое конкурентное решение, сделав акцент на новизне технологии и на рыночных возможностях, которые откроются при снижении цены продукта.
Чек-лист
Что учесть при создании приложения, чтобы им реально пользовались клиенты:
- сперва анализ, потом ТЗ;
- работа над ТЗ с участием всех отделов;
- кастомизация без фанатизма;
- баланс между основными и дополнительными функциями;
- тщательный выбор подходящей технологии;
- выбор надежного подрядчика;
- возможность прямой коммуникации между командами заказчика и разработчика;
- контроль безопасности (тесты);
- подготовка к прохождению ревью;
- сбор обратной связи;
- мониторинг активности пользователей.
Фото на обложке: HayDmitriy/Depositphotos
Как покупатели взаимодействуют с носимыми устройствами?
Первые разработчики столкнулись с нехваткой знаний о том, как, когда и для чего потребители будут использовать носимые технологии. Какие пользовательские сценарии, функции и интерфейсные решения окажутся востребованными на новых платформах? Эту проблему упомянули 10 из 15 респондентов.
По словам Андрея Гарькавого, генерального директора Stanfy (создание приложений для мобильных телефонов и носимых гаджетов), при разработке первого проекта для Apple Watch было много белых пятен в области пользовательских сценариев.
Дизайн приложений под Apple Watch — непростая задача. Паттерны совершенно новые, не было готовых ответов и устоявшихся моделей взаимодействия с интерфейсами часов, которые бы точно сработали. Мы перепробовали несколько вариантов интерфейса, пока не нашли подходящий.
— Андрей Гарькавый
Очень важно знать конкретные способы и примеры пользовательского взаимодействия с устройствами. Это помогает принимать важнейшие решения при выборе платформы и разработке продукта. Левент Гёрсис, президент Movel, говорит, что выбрать Google Glass в качестве платформы для одного из проектов помогло именно понимание будущих функций приложения и задач, которые оно должно решать.
Знание пользователей и условий, при которых люди будут использовать приложение, оказывает большое значение при выборе платформы или устройства.
— Левент Гёрсис
Непонимание пользовательских сценариев негативно влияет на разработку приложений. Слишком много внимания уделяется технологической стороне и мало — удобству пользователя.
Чтобы преуспеть на технологическом рынке, нужно объединять технологии с конкретной пользовательской историей. Только это запустит процесс освоения технологии потребителями. Сосредоточьтесь на том, кто сегодня получит максимальную пользу от вашего продукта. Только потом можно будет думать о масштабировании и росте.
— Эл Бейкер, сооснователь и генеральный директор Reemo (создание «умных» браслетов, позволяющих распознавать жесты)
Анника Сиберг, креативный директор MentorMate (разработка мобильных приложений), согласилась с Бейкером, подчеркнув, что пользовательскому взаимодействию не должны мешать технические ограничения и сложные аспекты проектирования.
Наша задача состояла в том, чтобы людям было не только легко, но и интересно использовать приложение. Мы хотели, чтобы люди замечали ценность, которую даёт продукт, а не стоящий за ним сложный бэкенд.
— Анника Сиберг
Преодоление вызова
Попытки обойти незнание пользовательских сценариев привели экспертов к трём умозаключениям.
Дизайн под носимые устройства требует постоянного упрощения
Убедитесь, что вы правильно понимаете контекст использования приложения. Максимально упрощайте то, что вы собираетесь делать на часах. Осознайте ту грань, за которой приложение становится сложным и непригодным для использования.
— Джон Михаэли, начальник отдела маркетинга и развития бизнеса MediSafe
Лучшие взаимодействия с устройством — короткие и быстрые
То, что очевидно сейчас, не было ясно в начале разработки. Люди используют приложение всего несколько секунд. Если взаимодействие продлится более 3–5 секунд, человек скорее достанет телефон.
— Маркиян Мацех, менеджер по продукту ELEKS
Шон Мехра, директор по продукту в HealthTap (приложение, позволяющее консультироваться с профессиональными врачами), привёл несколько подобных примеров.
Умные часы не предназначены для потребления информации — это прибор для быстрого и точечного восприятия данных. Например, «Что там с погодой? Как поживают мои акции?», а не «Дай-ка я почитаю электронную книгу».
— Шон Мехра
Люди не хотят, чтобы приложение для носимых устройств было лишь расширением приложения в телефоне
Во время работы бывает соблазн просто перенести всю функциональность мобильного приложения в версию для носимых устройств. Это опасное желание, потому что пользователи пользуются часами и телефоном по-разному и в разные моменты. Создавая продукт для часов, нужно начать с нуля и решить, какие виды взаимодействия с мобильным приложением в нём вообще имеет смысл использовать.
— Чарльз Тиг, основатель и генеральный директор Lose It!
Ограничения технических возможностей платформы
Первому поколению носимых устройств присущи технические ограничения — об этом сказали 8 из 15 экспертов.
Бобби Гилл, основатель и генеральный директор Blue Label Labs, рассказал, как эту проблему усугубили скудный инструментарий и документация на Apple Watch.
Возникало много вопросов, связанных не с кодом и техническими нюансами, а с плохой документацией. Модель отличная, всё работает, но набор инструментов и вся обвязка сейчас достаточно примитивны.
— Бобби Гилл
Дмитрий Тарасов, основатель и генеральный директор Tarasov Mobile, выразил те же настроения, описывая опыт разработки приложения под Samsung Gera.
— Дмитрий Тарасов
Эксперты поделились несколькими примерами из жизни, чтобы технологические затруднения стали понятнее.
Анимация
Во-первых, для многих компаний стала проблемой реализация анимации. Например, Blue Label Labs планировала анимировать интерфейсы отслеживания благоприятных периодов для зачатия с тем, чтобы сделать приложение BabyMed более удобным для пользователей.
Когда мы начали разработку, думали, что сможем здорово реализовать анимацию. Согласно документации, это было реально. Однако на деле мы столкнулись с ограничениями платформы, которые помешали воплотить задумки. Поддержки при этом никакой не было.
— Бобби Гилл, Blue Label Labs
С той же проблемой столкнулись Stanfy, когда разрабатывали анимацию в приложении Waterbalance для Apple Watch. Для решения пришлось придумывать обходные пути.
Чтобы сделать хорошую анимацию под Apple Watch, приходится делать некоторые вычисления на смартфоне и передавать результаты обратно на часы. Если будете делать так же — позаботьтесь, чтобы пользователям не приходилось слишком долго ждать.
— Андрей Гарькавый, Stanfy
Тактильная обратная связь
Во-вторых, начались проблемы с использованием тактильной обратной связи на Apple Watch (технология Taptic Engine).
По задумке Sickweather часы должны были вибрировать на запястье владельца после 20 секунд мытья рук — таким образом работал таймер. Грэм Додж, президент Sickweather, рассказывает, что первая версия ОС Watch не поддерживает эту функцию уведомления.
Пришлось искать, как креативно обойти это ограничение. Часть взаимодействия с часами пришлось снова переложить на смартфон.
Теперь, когда начинается отсчёт таймера, приложение с часов уведомляет телефон о старте. Смартфон отсылает обратно нотификацию, когда таймер заканчивается. Из-за изменения логики пришлось слегка реструктурировать разработку проекта.
— Грэм Додж
Нет возможности создать под часы нативное приложение
В-третьих, из-за невозможности разработки нативного приложения под часы страдает конечный дизайн.
Маркиян Мацех из ELEKS рассказала, как проекты под носимые устройства выиграют, когда появятся нативные приложения.
Если говорить о приложениях на умные часы, лучший способ запуска и взаимодействия с приложением с точки зрения дизайна и пользовательского опыта — это голосовое управление. Например, «Окей, Гугл, включи таймер номер 1234» или «Эй, Siri, заводи мою Tesla». Сейчас платформы не дают возможности такого взаимодействия. То есть надо сначала сказать: «Эй, Siri, включи приложение Tesla», подождать 2–3 секунды, а потом командовать: «Заводи машину». То же самое с Android. Это большой недостаток обеих платформ.
Компания Sickweather столкнулась с аналогичной проблемой и придумала совсем другой способ с ней справиться.
Когда наше приложение Sick Score загружало данные с iPhone, это порой занимало довольно много времени. При этом высвечивалась обычная надпись «Загрузка». Вместо этого мы написали «Сканирование». Это даёт пользователю ощущение, что в момент загрузки приложение действительно делает что-то продуктивное, сканирует болезни вокруг, а не просто тупит. Такое небольшое изменение повлияло на пользовательский опыт в положительную сторону.
— Грэм Додж, Sickweather
Сэп Сэйди, генеральный директор Plastic Mobile, также рассказал о недостатках ненативной разработки приложения под Apple Watch для риэлторской компании. В приложении напрашивалась функция звонка агенту, но с часов нельзя делать исходящие звонки. Поэтому в результате часы отсылают уведомление на смартфон, а приложение на смартфоне автоматически звонит агенту при открытии.
Скромные возможности батареи
Батареи Google Glass быстро нагревались и очень мало времени держали заряд, что ограничивало разработчиков.
Проблема Google Glass — это ограниченные возможности батареи и камеры. Нельзя сделать всё, что ты хочешь. Из-за нетривиальных вычислений Google Glass быстро нагревается, и батарея умирает примерно через час.
Разработка без тестовых устройств
8 из 15 экспертов стали пионерами разработки под носимые устройства и начали создавать продукты до выхода самих устройств. А ведь тестирование на реальных устройствах — важная часть рабочего процесса.
Тестирование — это стандартный этап нашей разработки. В случае с носимыми устройствами нужно было не только исправить ошибки, но и проверить все этапы пользовательского взаимодействия с часами и со смартфоном.
— Сэп Сэйди, Plastic Mobile
Шон Мехра из HealthTap разделяет эти чувства.
Вы можете пользоваться симулятором. Однако ощущения от пользования маленьким экраном и касаний пальцами вы можете прочувствовать только на самом устройстве.
Самой большой проблемой была визуальная составляющая проекта. Трудно представить, как всё это будет выглядеть на экране, когда у тебя нет реальных часов на запястье.
— Бобби Джилл, Blue Label Labs
Компания Runtastic, разрабатывая программное обеспечение и параллельно сам девайс — фитнес-браслет Orbit, — столкнулась с такими же трудностями тестирования и улучшения продукта в отсутствие тестовой базы.
Я думаю, одна из самых больших проблем — разработка и запуск продукта, включающего и оборудование, и софт. Это гораздо сложнее, вы будто работаете над двумя взаимозависимыми проектами. Возникает много сложностей, когда дело доходит до выдерживания сроков и устранения неисправностей.
— Стефани Петерсон, вице-президент по стратегическим коммуникациям и маркетингу Runtastic
Небольшой размер устройства
Размеры носимых устройств (и соответствующие ограничения производительности, памяти и батареи) ограничивают функциональные возможности, доступные разработчикам. Эту проблему отметили 7 из 15 экспертов. Приходится сосредоточиться на главной функциональности продукта, отбросив всё лишнее.
Самое сложное — решить, что вы хотите сделать с этим маленьким экраном. Разработать приложение нетрудно, но есть очень много ограничений. Главное — определиться, что вы хотите предложить своим пользователям.
— Дмитрий Костин, генеральный директор Touch Instinct
Сэп Сэйди рассказал, как размер экрана Apple Watch повлиял на его проект PizzaPizza.
Разрабатывая PizzaPizza, мы хотели реализовать на часах весь процесс заказа пиццы — от начала до конца. Для этого требуется функциональность корзины. Сделать полноценную корзину на экранчике 2×2 сантиметра, с которой нужно взаимодействовать пальцем, — та ещё задача. Как вообще можно её решить, сохранив простоту управления для пользователей?
Команде разработчиков HealthTap также пришлось пересмотреть свои первоначальные планы.
Мы строили планы, мечтали о многих функциях. Однако, когда дело дошло до реальной разработки, пришлось упрощать, упрощать и ещё раз упрощать проект.
— Шон Мехра, HealthTap
Устранение неисправностей съедает слишком много времени
Процесс устранения ошибок занял намного больше времени, чем ожидалось. Об этом сказали 4 из 15 экспертов.
Среда разработки под часы оказалась для нас наибольшей проблемой. Основную часть времени мы убили на тестирование и исправление багов, а не на саму разработку.
— Маркиян Мацех, ELEKS
Одной из проблем, затягивающих сроки проекта, была корректировка дизайна в середине разработки.
Из-за неочевидных ограничений платформ нам пришлось переосмыслить наш подход к разработке и функциональности приложения прямо посреди проекта.
Тем не менее, несмотря на эти первоначальные задержки, Левент Гёрсис из Movel прогнозирует, что разработка носимых приложений упростится с развитием технологий.
Во многих случаях приложения под носимые устройства будут иметь ограниченный набор функций или экранов, что сократит цикл разработки. С другой стороны, отрасль новая, API только развиваются, и в ряде случаев придётся тратить много времени на локализацию проблемы или ожидание, пока производитель обновит API и устранит дефект.
Отсутствие рефлексии и подведения итогов
В условиях проекта, к ошибкам часто приводит отсутствие анализа: проделанных действий, применённых подходов и практик, а также построенных недавно процессов.
Вам, как менеджеру, необходимо слушать и слышать что происходит в вашей команде в разных отрезках времени, и своевременно вносить качественные изменения в её работу. В таких случаях помогает рефлексия, которая позволяет осмыслить пройденный путь.
Простое решение: контролируйте эмоциональный фон команды, подводите итоги на итерационной и постоянной основах. Например, проводите еженедельные или двухнедельные «синки». При подведении итогов не забывайте делать срез по выполненным и планируемым задачам.
Всегда отмечайте успехи команды и не бойтесь говорить про неудачи. И проговаривайте проблемы, не только текущие, но и уже решённые. Обязательно фиксируйте итоги с подобных встреч и преобразовывайте их в задачи на развитие.
Вариант посложнее: мы в Redmadrobot пользуемся двумя инструментами: ретроспектива проекта команды и индивидуальная рефлексия для руководителя. Ретроспектива помогает регулировать эмоциональный фон команды, снимать обратную связь по прошедшему периоду и, что важно, — благодарить друг друга.
Индивидуальная рефлексия — это инструмент управленца, помогающий проводить анализ его действий в проекте за прошедший период. Здесь важно проанализировать, что вы планировали сделать, что получили в итоге и как будете действовать в следующий раз. Достаточно простая формула успеха, если ей пользоваться вовремя и с пониманием.
Вопросы рефлексии корректируются в зависимости от ситуации, но стандарт при их составлении один. Постарайтесь найти ответ на каждый из них:
- Куда я попал?
- Что я планировал сделать?
- Что получил в итоге?
- Что получилось и не получилось?
- Что я буду делать дальше?
У нас получился не самый полный список ошибок, но если вы сможете не совершать хотя бы их, то сделаете работу над проектом проще и эффективнее. Мы, роботы, убеждены, что совершение ошибок — это путь к совершенству, ведь мы постоянно на них учимся. Поэтому, советуем вам не бояться рисковать. А ещё, не забывайте прислушиваться не только к коллегам, но и к самому себе. Согласны?
менеджер проектов в Redmadrobot
Какую из перечисленных ошибок вы совершали чаще всего?Игнорировал мнения стейкхолдеров. Не уделял должного внимания планированию. Перекладывал ответственность на других. Не использовал необходимые инструменты в работе. Не ставил чётких приоритетов. Не прописывал контрольных точек. Не информировал команду. Не реагировал на изменения или критичные ситуации. Не проводил рефлексию. Редко подводил итоги.
Backend-разработка (программный интерфейс и сервер)
Сервер влияет на производительность мобильного приложения и масштабируемость продукта, то есть способность системы увеличивать ту же производительность за счёт увеличения доступных ресурсов. Технологии здесь те же, что и в разработке веб-приложений. Отправная точка – определиться с:
- Языком программирования – написать мобильное приложение можно на Java, SWIFT, а сервер на Javascript, C#, Go-lang, PHP, Python и ещё десятке языков. И у каждого из них есть фреймворки на любой вкус.
- Системой управления базой данных – они делятся на два типа: те, что работают на SQL, и все остальные. SQL-системы надёжны и подходят для решения практически любых задач. Самые популярные – MSSQL, MYSQL и PostgreSQL. Кроме того, придётся выбрать движок (подсистему хранения) и выстроить схему базы. Ваша цель на данном этапе – сделать систему надёжной и хорошо структурированной. Не поленитесь и тщательно продумайте каждый её элемент.
- Хостингом для сервера и API – здесь вновь важно учесть производительность и масштабируемость приложения наряду с его надёжностью и ценой в магазинах. Такие провайдеры, как Amazon AWS и Rackspace, предлагают разработчикам облачные решения, причём размер облака можно будет увеличить, когда вырастет база пользователей. Они же помогут с резервным копированием данных и оперативными обновлениями.
Заключение
Возникающие вызовы заставляют разработчиков искать творческие решения проблем.
Распространение носимых технологий спровоцировало всплеск активности как со стороны разработчиков, так и со стороны продуктовых компаний. Люди начали экспериментировать с платформами, создавая приложения для умных часов, браслетов, очков и одежды.
Первопроходцы приняли вызовы, брошенные новыми технологиями. Творческое мышление привело к созданию уникальных и инновационных кейсов для потребителей.
Эксперты выявили основную проблему разработки и развития технологии, которая существует и сейчас. Это отсутствие информации и исследований о конечных потребителях приложений для носимых устройств.
Наверняка технологии и платформы улучшат в будущем, пользователей носимых устройств станет больше, и проблема не будет столь актуальной. Первые приложения для носимых устройств уже позволяют сделать выводы об идеальных сценариях использования технологии, которые будут развиваться в будущем.