разработка приложений – последние статьи и новости

Предположим, что вы уже проверили идею, поговорили с потенциальными пользователями или у вас просто «чуйка», что продукт нужен рынку. Теперь нужно все продумать и найти команду, которая поможет его разработать. От идеи до готового продукта вы пройдете через несколько этапов: Прототипирование Разработка технического задания. Дизайн. Разработка продукта. Публикация. С командой, которую вы выберете для реализации, вы можете пройти как все этапы, так и часть из них. Из опыта нашей команды, чтобы избежать долгих блужданий от одной функции к другой, перерасхода бюджета и потери времени, нужно хорошо представлять, что вы хотите получить на выходе. При этом прототипированию, техническому заданию и дизайну нужно уделить не меньше времени и внимания, чем самой разработке. Но сначала нужно сложить полное представления о первой версии продукта. Определите минимальный набор функций для продукта, чтобы быстрее выйти с ним на рынок Стартапам лучше как можно быстрее столкнуть идею с реальностью. Сделать сначала самое необходимо и выйти на рынок с минимально жизнеспособным продуктом (MVP — minimum viable product). Уровень минимальной жизнеспособности для продуктов может отличаться. У стартапа нет аналогов Если стартап предлагает рынку что-то новое, у него нет аналогов, а значит, нет и прямых конкурентов, то первая версия может быть очень упрощенной и дорабатываться на лету. Скорее всего, пользователи простят несовершенства, если продукт будет решать их задачи. Без продукта будет больнее, чем с ним. Когда Uber, AirBnb и другие первопроходцы только появились, они были очень упрощенными версиями себя сегодняшних. AirBnb был просто одностраничным сайтом, где два приятеля сдавали свое жилье участникам конференции по дизайну. Стартап хочет быть первым, но и другие тоже хотят Если на рынок одновременно выходят несколько конкурентов с подобными продуктами, есть фактор сроков. Тогда нужно быть не только первыми, но и лучшими. В 2020 году так вышел на рынок Checkbox. Когда государство разрешило использовать программные регистраторы кассовых операций вместо железных ящиков, на рынке появилось несколько предложений. Checkbox сразу же разработали сайт, предложили на сайте тарифы, начали сотрудничать с учетными системами, запустили PR-кампанию и активно занимались маркетингом. Продукт работал с неточностями, но со временем становился лучше. Благодаря скорости, приятному дизайну, простому устройству системы и продвижению Checkbox – выжившее и самое известное решение на сегодня. Стартап выходит на сформировавшийся рынок Если аналоги на рынке есть и с ними уже работают потенциальные клиенты стартапа, то нужно дать то, к чему они привыкли и еще немного больше. Сделать удобнее, приятнее, добавить возможности, которых нет у других. Когда Monobank вышел на рынок, все уже пользовались Privat24 и другими банковскими приложениями, хорошо понимали, что такое мобильный банкинг. Приложение Мono выполняло все стандартные функции, но при этом имело простой функциональный дизайн, высокую отказоустойчивость («не тормозило» и «не висло») и, в отличие от приложений других банков, было человечным и вызывало эмоции. Начните с прототипов и технического задания, чтобы полностью осознать продукт Когда понятно какой продукт для стартапа будет минимально жизнеспособным, важно полностью его представить еще до разработки дизайна и программирования. Для визуализации продукта хорошо подходят прототипы – схематические изображения экранов. Пример прототипа Прототипы рисуют на основе пользовательских сценариев, например: Как пользователь начинает работу с продуктом: он регистрируется, заполняет набор полей, входит с помощью кода из SMS или авторизуется через соцсети? Куда он попадает после регистрации? Что должно быть на основном рабочем экране? Как пользователь будет выполнять ключевую функцию? Например, размещать заказ или совершать покупку? Какие нужны дополнительные разделы? Профиль, настройки? Нужно все продумать и уделить внимание деталям. Чем лучше продуманы прототипы, тем проще работать с дизайном и не обнаружить в середине пути, что функциональные части спорят друг с другом и нужно все переделывать. Когда прототипы готовы, нужно их протестировать и прописать ключевые моменты в техническом задании. Обычно этот этап помогает найти неточности и логические дыры. Сейчас их проще всего устранить без больших потерь времени и денег. На основе прототипов можно начинать работу с дизайном. Разработку дизайна лучше доверять UI/UX-дизайнеру с опытом Очень важно, чтобы дизайнер разбирался в UX (user experience) – пользовательском опыте и умел его проектировать. Если есть возможность, то хорошо привлечь дизайнера для отрисовки и прототипов тоже. В моей практике веб-дизайн и дизайн приложений пробовали рисовать ребята, которые рисуют плакаты и оформляют посты для соцсетей. С таким дизайном сложно работать, это просто яркие нефункциональные картинки. Они не помогают пользователю двигаться по сценарию, не направляют его, а иногда и усложняют этот путь: скрывают часто используемые функции в боковом меню, размещают на экране несколько кнопок, которые отвечают за одно и то же действие, проектируют несогласованные системы. Например, в одном месте зеленый текст кликабельный, в другом – информационный и на него нельзя нажать. В плохом дизайне рядом размещены фильтры с подсказками «найти клинику» и «поиск врача». Это несогласованность. Пример несогласованного дизайна В дизайне нет единообразия: можно найти более трех ключевых цветов, два-три стиля и пять-семь размеров шрифтов, разное выравнивание текста в разных частях системы. В итоге это все пестрит в глазах у пользователя и плохо воспринимается. Лучше искать дизайнера, у которого в портфолио есть похожие работы, который имеет опыт в построении интерфейсов, разбирается в пользовательском опыте. Если привлечь дизайнера для работы с прототипами, то можно понять, насколько он компетентен, умеет ли работать со сроками, и посмотреть, захочется ли двигаться с ним дальше. Можно также попросить, чтобы он нарисовал один-два экрана и объяснил, почему в макете все сделано именно так. На этапе прототипирования и дизайна лучше проявить терпение. Все хорошо продумать, протестировать, довести до качественного состояния. И затем переходить к разработке. Зафиксируйте стоимость и сроки разработки, и регулярно получайте промежуточные результаты Перед тем как перейти к разработке, согласуйте с командой и зафиксируйте в договоре стоимость и сроки работы. Их достаточно точно можно сформулировать на основе прототипов и технического задания. Сам процесс разработки обычно делится на этапы – спринты. Если был этап прототипирования, то заранее понятно, сколько их будет и как они будут разделены. Для спринта берется смысловой блок, например, регистрация или процесс оформления покупки. Важно, чтобы после спринта вы могли получить понятный результат – работающую часть продукта. Перед началом работы один-два ближайших спринта разбивают на задачи. Обычно спринт занимает две-три недели. Регулярно получайте промежуточные результаты. Итеративный процесс позволяет видеть каким будет продукт практически с самого начала. Выполняет ли он все требования, заложенные на этапе прототипов, соответствует ли дизайну. И более того, если в процессе станет понятно, что что-то лучше убрать или изменить, это можно сделать. Планы важны, но еще важнее успех продукта. Если в процессе появляются новые вводные, то никогда не поздно переосмыслить то, что делается, и внести корректировки. Лучше потерять немного времени в процессе, чем выпустить продукт, который будет никому не нужен. Попросите разработчиков защитить технологии Вероятнее всего, разработчики будут предлагать технологии, с которыми умеют работать. Одни будут подходить лучше, другие хуже. Глубоко разбираться необязательно, но примерно ориентироваться было бы хорошо. Например, при разработке приложения можно выбрать, какое вы будете разрабатывать: нативное или кросс-платформенное. Нативные – это приложения, которые разрабатываются под каждую платформу отдельно: iOS, Android, веб. В процессе развития, когда нужно будет добавлять новые функции, их нужно программировать для каждого приложения также отдельно. Нативная разработка подходит приложениям, которым нужно использовать возможности операционной системы по максимуму. Например, Instagram выполняет ресурсоемкие операции: проведение прямых эфиров, наложение эффектов на фото и видео, редактирование изображений. Для эффективной работы ему нужно использовать преимущества и возможности каждой операционной системы и даже отдельных устройств на все сто. Делать это при кросс-платформенной разработке гораздо сложнее, чем при нативной. Если производительность для продукта критична, то экономия даже половины стоимости не оправдает потери 10% производительности. Нативные приложение программируют на: Android – Kotlin, Java; iOS – Swift. Кроссплатформенные – это приложения, где один код используется для нескольких платформ. Например, Flutter (фреймворк от Google) позволяет разрабатывать одно приложение для iOS, Android, веб и десктопа. Это очень удобно: продукт может использоваться на разных девайсах, и в процессе развития функции добавляются один раз сразу для всех платформ. Расход времени и денег сокращается в два-три раза, а уровень качества сохраняется. Кроссплатформенные приложения программируют на: Flutter; React Native. Кроме видимой части – интерфейсов в приложении и фронт-энда в веб-проектах продукт имеет невидимую часть – серверное приложение, которое отвечает за логику работы: производит расчеты, управляет доступами, хранит данные. В случае с мобильным приложением для его взаимодействия с серверным приложением необходим API – программный интерфейс, который будет их соединять, так как напрямую общаться они не могут. Серверные приложения и API чаще всего программируют на: .NET; Node.js; Java; Python; PHP. Большой плюс, если выбранные технологии активно развиваются создателями, имеют большое сообщество, открыты, гарантировано бесплатны не только сейчас, но и в будущем. Это позволит продукту не устареть и постоянно обновляться. Получите от разработчиков все данные и доступы Когда продукт готов, его публикуют в App Store/Google Paly (в случае с мобильными приложениями) или под вашим доменом (в случае с веб-проектами). Над поддержанием и развитием продукта вы можете дальше работать с людьми, которые его разработали, или собрать собственную команду. Какой бы путь вы ни выбрали, нужно владеть всем, что касается продукта, и не зависеть от одной конкретной команды. Что нужно получить от разработчиков: Исходный код всех частей продукта (серверного приложения, мобильных приложений или сайта). Обычно он находится в хранилище исходного кода на таких площадках, как GitHub или GitLab. Там вам должны предоставить уровень доступа оwner. С этим доступом вы можете в любой момент удалить текущую команду и передать доступ, кому нужно. Исходники макетов. Сейчас это чаще всего ссылка на макеты в Figma. Макеты необходимы для будущих доработок, чтобы вы могли свободно использовать элементы и стили для проектирования новых функций. Спецификацию к проекту. Это может быть небольшой документ, где будет описано, на каких технологиях выполнен проект, где зарегистрирован домен, где располагается хостинг, там могут быть предоставлены доступы ко всем учетным записям. Этот документ вы сможете передать команде для дальнейшей работы с продуктом. Помните о безопасности. У вас в любой момент должна быть возможность заменить команду без последствий. Позаботьтесь о безопасности. Хостинг, домен, учетные записи разработчика должны быть зарегистрированы на ваше имя или на имя вашей компании. Приложения в App Store и Google Play также должны быть опубликованы от вашего имени. У вас должен быть ко всему доступ. Для Android-приложения у вас должен быть ключ и пароль к нему. При первой публикации создается хранилище ключей, в нем ключ для текущего приложения, который защищен паролем. Это все понадобится для следующих релизов продукта. Выбирайте команду, которая разбирается в каждом этапе и поможет принимать хорошие решения Многие стартапы приходят к команде разработки с идеей и не разбираются в технической части и процессе. Хорошая команда возьмет на себя максимум и проведет через этот процесс «за ручку», не будет ожидать от вас экспертизы в вещах, в которых вы разбираться не должны. Поможет с прототипами, техническим заданием, дизайном, будет своевременно демонстрировать промежуточные результаты и все объяснять. А после – поможет с публикацией, все подготовит и передаст. Сократить риски можно, проверив сотрудничество на одном отрезке работы. Например, сделайте вместе прототипы. Этого должно быть достаточно, чтобы понять, подходит вам команда или нет. И только если подходит – двигаться дальше.

No items found.