Shark Develop - компания по разработке мобильных приложений для iOS и Android

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

пользователи уходят из вашего приложения | Клиентам | 3 причины, почему пользователи уходят из вашего приложения и как это исправить 2

Что делать, если пользователи уходят из вашего приложения и не возвращаются? Мы рекомендуем обратиться к нескольким методам, которые, возможно, вы либо не используете, либо используете неправильно.

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

“Потрясающе! Это приложение творит чудеса!” – думаете вы.

А затем спад.

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

Вам говорили: “Разработайте приложение и клиенты придут”? Да! Они пришли. Но если вы не сможете их удержать, они уже никогда не вернутся.

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

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

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

Причина № 1: вы не используете социальные сети и другие маркетинговые каналы

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

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

Что вы можете сделать: Запустите рекламную кампанию с повторным взаимодействием с приложением на Facebook

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

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

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

Три подсказки для создания хорошего рекламного объявления:

  1. Используйте картинку или фотографию, которая выглядит реальной и имеет прямое отношение к теме вашего объявления.
  2. Используйте слова-действия, чтобы обратить внимание пользователей на вашу рекламу.
  3. Четко и ясно изложите клиентам суть вашего предложения, настроив кнопку «призыв к действию».

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

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

Причина № 2: ваши push-уведомления не выполняют свою функцию

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

Пользователи могут расценить push-уведомления как спам, если они работают неправильно. Когда это произойдет, пользователи могут отключить push-уведомления для вашего приложения. Более того, это в принципе может оставить негативное впечатление о вашей компании.

Согласно исследованию Google, лишь 52% пользователей приложений предпочитают получать push-уведомления. Поэтому, если у вас есть возможность отправлять сообщения своим пользователям, лучше воспользуйтесь ею правильно!

Что вы можете сделать: обзор и пересмотр тактики для push-уведомлений

Три вещи имеют значение, когда речь заходит о push-уведомлениях для приложений:

1. Подбор наиболее точных слов

Устройства Android позволяют вместить в push-уведомления от 40 до 60 символов, устройства iOS – до 120. Из-за небольшого размера этих уведомлений вам нужно придумать текст из нескольких слов, который заставит ваших пользователей через уведомление перейти к приложению. Вот несколько советов:

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

2. Подготовка хорошего контента 

Итак, вы привлекли пользователя своим сообщением и побудили его нажать на push-уведомление, что дальше? Дальше его должен ждать хороший и интересный контент. Что такое плохой контент? Одно из двух: либо вы уведомили пользователя о чем-то, что на самом деле не несет никакой ценности, либо само уведомление не соответствовало контенту, к которому оно привело.

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

3. Частота рассылки уведомлений

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

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

Причина № 3: App-nesia или люди, забывающие ваше приложение

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

Что вы можете сделать: Прямой поисковый трафик для вашего приложения через глубокие ссылки или перенаправление App Store

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

Теперь подумайте, каким образом вы хотите привлечь пользователей в МОБИЛЬНОЕ приложение из БРАУЗЕРА? Вероятно, они просто перейдут на ваш мобильный сайт? Вы должны понимать, что ваше приложение и ваш мобильный сайт выполняют две совершенно разные функции. В то время как мобильные сайты посещаются для получения подробной информации о вашей компании, приложения дают доступ к более эксклюзивным функциям.

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

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

В качестве запасного варианта, пользователи могут быть перенаправлены на страницу приложения в App Store или Play Market, если глубокие ссылки не поддерживаются. Вместо этого им предлагается открыть ваше приложение.

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

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

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

Источник: apptractor.ru

Разработка ПО по договору Time&Material: риски и преимущества

пользователи уходят из вашего приложения | Клиентам | Разработка ПО по договору Time&Material: риски и преимущества 4

Правильное построение взаимоотношений между заказчиком и исполнителем это половина успеха разработки. Подходящий для проекта тип контракта помогает минимизировать риски и увеличить шансы на положительный результат для обеих сторон: клиента и компании-разработчика. В прошлой статье мы сравнили подходы Fixed price и Dedicated team. Сегодня мы рассмотрим ещё одну модель ценообразования в аутсорсинге – работу по договору Time&Material.

При упоминании Time and Material часто возникает вопрос: «Почему бы подрядчику не потянуть резину чтобы получить побольше денег?». На деле это вопрос доверия. Этот способ ценообразования позволяет исполнителю гибко настроить процесс разработки, не огораживаясь от рисков и не возводя преград в виде строгих ТЗ перед заказчиком. Хороший исполнитель заинтересован в правильном результате и старается сохранять процессы прозрачными.

Это хороший подход когда качество продукта для клиента на первом месте и не вызывает беспокойства мысль, что может быть потрачено больше ресурсов, чем планировалось. Однако для минимизации рисков, при составлении договора по модели Time and Material, надо детализировать план разработки ПО и обсудить сроки выполнения этапов и всего цикла разработки.

Что такое договор Time&Material?

T&M это модель работы, при которой оплачивается не результат, а время исполнителя. Например, вы платите не за разработку и внедрение программы управления предприятием, а за человеко-часы, потраченные сотрудниками исполнителя на разработку. Но что означает Time&Material на самом деле? Западный опыт работы по Time & Material подразумевает, что заказчик оплачивает услуги исполнителя на основе человеко-часов, дополнительно возмещая затраты на используемые материалы.

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

Договор Time and Material имеет ряд особенностей:

  • Оплата происходит не за конечный результат, а за рабочий процесс. Работа ведется короткими этапами.
  • Положительное отношение к изменениям со стороны исполнителя. Этот подход хорошо дисциплинирует заказчика и стимулирует более обдуманно планировать и проектировать проект.
  • Максимальная гибкость. Клиент может позволить себе делать что угодно в каких угодно объемах. Вносить изменения можно с большей скоростью.

Первое опасение возникающее у потенциального клиента – компания разработчик может раздуть время и бюджет проекта до бесконечности. Для того чтобы снять это опасение давайте рассмотрим как работают компании по модели T&M.

Как работают по договору Time&Material?

T&M хорошо применять там где невозможно определить полный объем работы или сроки их реализации. Для каких типов проектов рекомендуется модель T&M?

1. Проект находится на стадии тестирования, технического обслуживания или доработок. Для выполнения отдельных блоков работ T&M – очень удобный вариант. Каждую стадию можно описать в подробных ТЗ, особенно когда готова вся документация по проекту.

2. Проекты, срок разработки которых занимают до 6 месяцев, на команду от 5 человек и требуют наличия технической документации. Модель «Оплата по факту» позволяет исполнителю подстраиваться под желания клиента и требования рынка, поэтому четкие спецификации, хоть и нужные, могут отсутствовать на первых порах. Тогда документация будет писаться в ходе работы или станет первой задачей в рамках проекта.

3. Крупные проекты, которые требуют команды от 25 человек, со сроками разработки от года. В связи с большими объемами и долгим временем разработки, предварительные спецификации будут фрагментированы и могут занимать тысячи страниц, которые будут корректироваться по ходу разработки.

Концепция договора Time&Material предполагает, что вы платите после выполнения работ по заранее определенному плану. Этапы разработки определяются в начале сотрудничества.

Пример рабочего процесса по T&M

  • Проект делиться на отдельные этапы. Каждый этап оценивается по стоимости и срокам. Вы можете внести любые изменения или дополнения в процессе разработки, не требуется согласования и подписание дополнительных документов.
  • Подрядчик оценивает проект в часах, необходимых для выполнения этапа. При этом он не закладывает риски, чтобы перестраховаться, как в случае с моделью Fixed price.
  • По окончании разработки руководитель проекта согласовывает итоговую смету с заказчиком, после чего происходит оплата. В большинстве случаев работа по Time & Material стоит для заказчика дешевле, так как студия не обременена рисками, которые накладывают на проект условия Fix price.
  • Разрабатывая продукты на основе T&M, исполнитель может гибко построить процесс разработки и старается сохранять максимальную прозрачность, выдавая результат, который вы ожидаете, в максимально сжатое время. Так подрядчик пытается наладить долговременное сотрудничество в будущем.

Результатом работы в конкретном периоде может служить как рабочий прототип или релизная версия, так и полноценный билд ПО. Разделение на этапы в модели T&M имеет общие черты со спринтами в Scrum, поэтому оплата по факту нередко сочетается с гибкими методологиями разработки.

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

Подобная модель на практике невозможна без хорошей системы планирования задач и мониторинга их выполнения. Для этого можно использовать такие системы, как JIRA, Redmine или Basecamp.

Со стороны заказчика

Плюсы:

  • Делегирование — заказчик ведет коммуникацию с менеджером проекта и обсуждает с ним основные требования. А менеджер уже планирует всю разработку, распределяя задачи внутри команды.
  • Гибкая разработка. Объемы и порядок работ изменяются при необходимости, достаточно внести новые требования в бэклог проекта.
  • Экономия бюджета. На средних и крупных проектах модель T&M помогает заказчику сэкономить от 10 до 30 процентов бюджета, так как проект делится на короткие и прозрачные этапы.
  • Сбалансированная команда. Заказчик имеет право определить количественный состав и квалификацию членов команды совместно с менеджером проекта со стороны подрядчика.
  • Прозрачная разработка и результат. Клиент максимально вовлечен в проект, имея доступ к системам управления задачами и учета трудозатрат. Разбивая проект на этапы и имея договоренности о промежуточных результатах клиент получает работающие промежуточные версии с законченным функционалом. Это исключает неприятные сюрпризы в случае многомесячной разработки без обратной связи с заказчиком или дискоммуникации.

Минусы:

  • Глубокая вовлеченность. Проект в T&M требует как больше внимания от заказчика, так и достаточную компетенцию для управления проектом. Это может быть минусом с точки зрения временных затрат на проект, но окажется весомым преимуществом с точки зрения качества конечного продукта.
  • Неопределенный бюджет. В случае отсутствия четкого понимания об объемах и сроках разработки проекта, заказчик несет финансовые риски. Желая сэкономить на количестве специалистов, клиент также рискует получить дополнительные расходы на разработку проекта.
  • Недобросовестные подрядчики. Всегда есть риск столкнуться с недобросовестной компанией, которая будет завышать реальные трудозатраты с целью получения прибыли. Поэтому нужно очень тщательно подходить к выбору исполнителя и планированию разработки проекта.

Со стороны исполнителя

Плюсы:

  • Погружение в проект. T&M мотивирует исполнителя раз за разом оправдывать ожидания заказчика, следуя намеченному плану работ, вовремя проходя установленные контрольные точки.
  • Оплата по факту. Исполнитель получает оплату за отработанные реальные трудозатраты команды на проекте.
  • Низкие риски. Исполнителю нет нужды закладывать дополнительные риски проекта в стоимость разработки. Короткие этапы проще оценивать, это бережет репутацию разработчиков и нервы всех участников проекта.
  • Распределение ресурсов. Подрядчик заинтересован в полной загрузке команды разработки без простоев. Это мотивирует менеджеров тщательнее планировать и распределять нагрузку, устраняя узкие звенья проектов.

Минусы:

  • Заказчик с характером. Стремление клиента сэкономить каждую копейку рождает взаимное недоверие и споры. Такое взаимодействие деструктивно и вряд ли запустит проект на нужную орбиту.
  • Отсутствие гарантий. Смена приоритетов или иссякший бюджет проекта может оставить компанию исполнителя без работы. Обычно к этому моменту нагрузка команды распланирована далеко вперед, на привлечение дополнительных ресурсов потрачены время и деньги исполнителя.
  • Постоянно меняющиеся требования. Метания проекта из стороны в сторону демотивирует команду разработчиков. Постоянно ускользающий результат работ и смена целей приводит к выгоранию. Люди должны видеть ясную цель и чувствовать движение к результату. Сотрудничая по модели Time and Material компания заинтересована в том, чтобы предоставить вам качественный результат за оптимальное время — это, в свою очередь, гарантирует дальнейшее успешное сотрудничество.

Заключение

Мы рекомендуем заказчикам, которые хотят реализовать крупный долгосрочный проект, не рисковать и выбирать гибкую модель разработки и оплаты — Agile и Time&Material. Обычно на старте разработки крупных проектов заказчики редко имеют точное представление о всём необходимом функционале. Однако по мере развития проекта, мы вместе с вами глубже вникаем в задачи — так появляются новые идеи и улучшения. Time and Materials в таком случае очень удобен — вы можете вносить корректировки непосредственно в ходе работ.

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

Источник: vc.ru

Fixed price VS Dedicated team: какую схему оплаты выбрать?

пользователи уходят из вашего приложения | Клиентам | Fixed price VS Dedicated team: какую схему оплаты выбрать? 6

Допустим, вы решили разработать программное обеспечение, не имея собственной команды разработчиков. Понятно, что без подрядчика здесь не обойтись. Не ясно другое: как эту работу оплачивать? То есть какую из моделей финансового взаимодействия выбрать: фиксированную ставку или выделенную команду? Что будет рационально именно для вас? Вопрос резонный и волнующий, а потому – давайте разбираться.

Существует ещё одна модель — Time & Material. Прочитать о ней вы сможете в следующей статье.

С точки зрения клиента

Модель с фиксированной ставкой (Fixed price model)

Когда использовать:

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

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

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

Модель с выделенной командой (Dedicated team model)

Когда использовать:

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

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

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

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

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

С точки зрения разработчика

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

Модель с выделенной командой (Dedicated team model)

Преимущества выделенной команды:

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

Минусы выделенных команд:

  • На каждом проекте есть более или менее интересные задачи. Так вот задачи по доработке и поддержке проектов, как правило, относятся к не самым интересным. К примеру, в таком случае, команда может тратить более 20% времени на техподдержку разных проектов заказчика.
  • Поскольку любая выделенная команда – это «компания внутри компании», команда подчиняется всем процессам заказчика. Иногда эти процессы отличаются от тех, к которым они привыкли в своей компании. Тут важную роль играет способность конкретного специалиста приспосабливаться к новым условиям: все очень индивидуально.
  • У выделенных команд обычно упрощенные спецификации на разработку нового функционала или проекта. Это дает им определенную свободу: возможность предлагать свои решения поставленных задач, вместо того чтобы слепо следовать написанным спецификациям. Но и здесь есть свои оговорки: буквально каждое такое решение должно быть согласовано с владельцем продукта на стороне клиента до начала его разработки, что требует от специалиста настойчивости в обосновании своих решений.

Модель с фиксированной ставкой (Fixed price model)

Преимущества проектов с фиксированной ценой:

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

Минусы проектов с фиксированной ценой:

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

Заключение

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

Источник: webmartsoft.ru

Локализация — что это и чем она отличается от перевода?

пользователи уходят из вашего приложения | Клиентам | Локализация — что это и чем она отличается от перевода? 8

В заголовок статьи вынесен, казалось бы, простой вопрос. Статью из журнала мы переводим, приложение или игру – локализируем, ничего сложного. На самом деле всё не так. Как выясняется, очень многие, в том числе заказчики переводческих услуг, разницы между двумя терминами не видят, а следовательно не хотят выделять физические и финансовые ресурсы на априори более сложный и долгий процесс локализации. Фразу «зачем вам время на исследования, сел да перевёл быстренько» можно услышать до неприятного часто. Поэтому мы хотим немного рассказать о разнице между этими двумя понятиями и показать её на конкретных примерах.

Википедия повествует, что локализация — это перевод и культурная адаптация продукта к особенностям определенной страны, региона или группы населения. И это самое чертовски короткое и точное определение, что видел свет. Под этим загадочным словосочетанием «культурная адаптация» скрывается целая глыба. Чтобы правильно локализовать продукт, требуется всестороннее изучение целевой культуры. Тогда программа/игра/книга/фильм будет правильно адаптирован к потребностям рынка и понят конечным потребителем.

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

Например, в Германии на законодательном уровне запрещено использование нацистской символики. Это значит, что изображение свастики придётся убрать из игры, предназначенной для распространения в Германии. Так, известны международные разбирательства, касающиеся серии игр Wolfenstein для ПК и для устройств на платформе iOS. Игру Wolfenstein 3D для платформ под управлением iOS (2011) убрали из магазина приложений App Store в Швейцарии и Австрии по причине наличия в ней свастики. Однако Wolfenstein подвергалась цензуре и ранее. К примеру, в версии для Super Nintendo, вышедшей в 1994 году, все свастики были убраны из нацистского замка, а собаки охранников превратились в крыс. В том же 1994 году игра была запрещена в Германии. В ПК-версии Wolfenstein: The New Order (2014) для стран Германии и Австрии, в отличие от международной версии игры, также была введена цензура. А в Wolfenstein II: The New Colossus цензура пошла ещё дальше. У Гитлера забрали его фирменные усы, называли его канцлером, а свастику заменили на трёхконечный символ.

 

 

Однако перевод — слишком общий термин. Так, Википедия присваивает переводу те же качества, что и локализации:

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

Давайте по пунктам разберём, что же характерно для перевода, а что для локализации:

Литературный перевод Локализация
Учёт культурных особенностей +
Учёт юридических аспектов +
Перевод стилистических особенностей + +
Адаптация шуток + +

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

В блоге переводчика и локализатора Аникьева есть пример, на котором хорошо можно понять тонкости локализации. Пример основан на переводах книги Аллена Карра «Лёгкий способ бросить курить»:

Первое — прекращение повторяющихся ночных кошмаров, мучивших меня каждую ночь. Мне снилось, что меня преследуют… Когда я описывал, что каждую ночь за мной кто‑то гонится во сне, я однажды набрал вместо «преследование» — «целомудрие». Возможно, это была одна из «опечаток по Фрейду», но она подсказала мне, как лучше всего перейти ко второму преимуществу.

Вам непонятно, как можно так опечататься? Тайну приоткрывает сноска, которая в разных вариантах книги может оказаться как внизу страницы, так и в конце книги:

Слова «преследование» (chase) и «целомудрие» (chaste) в английском языке отличаются лишь одной буквой.

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

Мне снилось, что я иду по непрочному полу… Когда я описывал, что во сне я хожу по непрочному полу, я однажды набрал вместо «непрочному» — «непорочному».

Вот это — локализация.

Посмотрим на ещё один хороший пример локализации:

пользователи уходят из вашего приложения | Клиентам | Локализация — что это и чем она отличается от перевода? 9

Типы локализации можно классифицировать по степени углублённости:

Самый поверхностный — «коробочная локализация»

Если игра выходит на физическом носителе и продается в оффлайне, локализуется то, что написано на упаковке. Если она продаётся не на физическом носителе, а на какой-либо платформе, то переводится её страница в магазине: описание и скриншоты. Этим коробочная локализация ограничивается.

Локализация интерфейса

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

Текстовая локализация

Переводятся все тексты в игре. Пример — GTA V. Игра переведена вплоть до субтитров, поэтому вы, с одной стороны, можете слушать и пытаться понять сленг афроамериканцев в игре, но при этом видите субтитры на русском.

Локализация с озвучкой

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

Графическая локализация

Любая игра представляет собой какой-то движок, дизайн, графические объекты, текстуры — всё то, что не является текстом. Допустим, надпись на заборе в шутере. Графическая локализация подразумевает, что все надписи внутри должны быть переведены. Это могут быть газеты, вывески магазинов, какие-то записки и так далее.

Что делать с играми, сеттинг которых находится в определённой локации?

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

Глубокая локализация — культурная адаптация

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

Заключение

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

Источник: inlingogames.com

Продвижение мобильного приложения. С чего начать?

пользователи уходят из вашего приложения | Клиентам | Продвижение мобильного приложения. С чего начать? 11

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

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

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

Когда речь идёт о том, как продвигать мобильное приложение, чаще всего выделяют два направления работы: генерация потока новых пользователей и возврат текущих юзеров (а также тех, кто удалил приложение), так называемая «работа на удержание».

В этой статье мы рассмотрим первую часть — как раскрутить мобильное приложение и привлечь в него пользователя.

Первым делом определимся, готовы ли мы вкладывать деньги. Можно пойти путем органического продвижения или коммерческого (платного).

Органическое продвижение приложений

Под органическим понимается такое продвижение, которое не требует или почти не требует денежных вложений. Рассмотрим основные варианты путей продвижения приложения:

  1. Email-рассылки. Отлично подходят для случаев, когда у вас есть целевая база (клиентов, подписчиков и т. п.), и вы, во-первых, уверены, что эти люди знакомы с вашим брендом и хоть немного лояльны, во-вторых, вы чётко представляете, какую пользу принесёт приложение этим людям. Пишете честное письмо, рассказываете, как старались разработчики, как спорили UX-дизайнеры и как круто и полезно у вас получилось. В конце даёте ссылку — и вуаля, десятки, сотни и тысячи условно-бесплатных инсталлов ваши.
  2. Продвижение в поиске сторов (так называемое ASO, App Store Optimization). Аналог SEO из «десктопного» интернета. Подходит для тех, кто хочет, чтобы его приложение можно было без труда скачать из сторов (то есть для всех). Бережно заполняете все поля карточки приложения в сторе, подбираете высокочастотное название, ставите цепляющие картинки — и трафик пошел. На самом деле, это отдельная наука со своим законами, поэтому на эту тему стоит погуглить, прежде чем браться за работу. [learn_more caption=»Читайте также:» state=»open»]

    [/learn_more]

  3. Контент. Напишите статью, как вы зафакапили разработку и потеряли полгода, и опубликуйте её на отраслевых порталах. Сделайте обзоры для порталов о приложениях. Пишите на своей стене в Facebook о ходе работ (красочно, в историях). Пишите, пишите, пишите. Контент-маркетинг работает.
  4. Перелив трафика с вашего сайта или других ресурсов. Если у вас уже есть некая посещаемая площадка, то стоит воспользоваться этим: предлагать скачать приложение посетителям, вошедшим с мобайла, размещать баннеры рекламы приложения на сайте.

Коммерческое продвижение приложений

Хорошо, вы сделали email-рассылку, пишете контент и колдуете над ASO, но установок всё ещё недостаточно.

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

  1. Мотивированное ASO. Факторы ранжирования в сторах зависят не только от хорошо заполненных карточек, но ещё и от «показателей» приложения — количества установок, постоянных активных юзеров и так далее. Этими цифрами можно управлять, если покупать мотивированные установки — установки, которые совершаются пользователями за деньги или какие-то иные бонусы. Это также отдельный мир, который стоит предварительно изучить. В профессиональной среде этот способ называется «мотив». Если вы уверены в том, что приложению нужно лишь пробраться к топам сторов, а дальше всё пойдет, то такой способ вполне оправдан.
  2. Контекстная реклама. Если вы считаете, что человек, ищущий что-то через Google на смартфоне — это ваша целевая аудитория, и вы сможете его заинтересовать настолько, чтобы он не поленился поставить ваше приложение вместо того, чтобы закрыть свою потребность на соседнем по выдаче сайте (не приложении), то вы можете выйти в мобильную поисковую (контекстную) рекламу — Google Adwords, Яндекс. Директ.
  3. Медийная реклама. Это уже реклама в привычном её понимании: при посещении сайтов, подключенных к рекламной сети, или использовании приложений, продающих рекламные места, у юзера на экране появляется ваш рекламный баннер с каким-то интересным предложением и призывом его получить, скачав приложение. После клика человек попадает в стор, а дальше свою важнейшую роль должны сыграть цепляющие изображения в карточке приложения при ASO. При этом, важно, чтобы описание приложения было релевантным тому, что юзер увидел на рекламном баннере. Никому не хочется посмотреть тизер эффектного шутера, а после перейти и узнать, что это пошаговая карточная игра, хоть и про стрелялки. Систем медийной рекламы очень много — Google Adwords, Google AdMobInmobiOctobird и так далее.
  4. Таргетированная реклама в соцсетях. Если вы настроены на раскрутку мобильного приложения только по РФ, то Inmobi и Octobird вам едва ли подойдут — там не так много качественного трафика из России. Обратная ситуация с продвижением в социальных сетях: VK, Одноклассники, Instagram, Facebook и даже Мой Мир дают возможность охватить миллионы юзеров нашей страны. Таргет идеально подойдет для тех, чьё приложение обладает wow-эффектом: если юзер может ЗАХОТЕТЬ скачать его, увидев две строки текста и одну картинку или видео, то соцсети позволят вам получать стабильный поток установок. Системы myTarget (объединяющая VK, Oдноклассники и Мой Мир) и Facebook, при верной их настройке, позволят вам закупать установки по модели CPI, то есть с оплатой за установку. Другими словами, вы указываете, сколько вы готовы заплатить за инсталл, а система поставляет их в возможном при такой ставке объёме.
  5. Посевы в соцсетях. Если приложение обладает wow-эффектом, но вы не обладаете возможностью запустить таргетированную рекламу, то есть второй вариант. Вы можете купить рекламу приложения на Android или iOS в сообществах вроде «Лучшие приложения для iPhone». Больше всего подобных сообществ в VK. Одна такая публикация стоит от 100 до 10000 рублей. В таких сообществах сидит аудитория, привыкшая регулярно качать приложения, поэтому свою долю внимания вы обязательно получите. Однако стабильности в этом способе мало, т. к.показ рекламного объявления происходит не равномерно (как в таргетированной рекламе), а всплесками: сегодня купили рекламу — всплеск с последующим угасанием до нуля в течение суток, и завтра нужно снова договариваться о новом размещении.
  6. Партнерки (или CPA-сети, арбитражные сети). Как в рунете, так и в мировом интернете есть большое количество мобильных партнерских программ, где происходит встреча «веб-мастеров» (людей, которые генерируют трафик на мобильные приложения) и заказчиков, то есть вас. Вы заявляете, что готовы платить за одну установку Х долларов, партнёрская программа берёт на себя работу с веб-мастерами и платит деньги тем, кто нагенерил вам установки. Задача веб-мастера: купить инсталл дешевле, чем то, за сколько он должен продать его вам. Обычно выход на партнерские программы — это долго, дорого и сложно, но если вы крупный игрок и хотите получать месяцами много установок — попробовать стоит. На Западе такой способ продвижения мобильных приложений — один из самых популярных. Но будьте готовы к фроду — ботам, которых вам обязательно будут пытаться продать под видом живых установок.

Нестандартные методы продвижения приложений

Далее можно прибегнуть ещё к нескольким способам, которые считаются нестандартными:

  1. Предустановки приложения на телефон. Вы можете договориться о том, чтобы устройство уже продавалось с вашим приложением. Предустановка приложения на телефон или планшет до или в момент его продажи максимально приближает приложение или игру к пользователю.
    Производители и продавцы смартфонов и планшетов устанавливают несколько популярных приложений на устройства своих покупателей. Список популярных или основных приложений расплывчат, поэтому за небольшую плату производители и продавцы могут устанавливать и ваше приложение.
    Такой способ продвижения избавляет пользователя от поиска приложения в сторе, в котором они, кстати, могут и не найти приложение. С другой стороны, есть риск того, что не каждый пользователь будет внимательно изучать содержимое своего телефона и может не заметить ваше приложение на новом телефоне.
    Договориться о предустановках приложения можно напрямую с производителем, но можно и через посредников. Если предустановки делать на заводе, то объем установленных приложений будут насчитывать минимум 100 000 установок. Если же договариваться с ритейлорами, то объемы установок будут на порядок меньше.
    Процесс переговоров с заводом длительный и может занять несколько месяцев, а вот договориться с ритейлором можно и за более короткий срок.
    Продвигать приложение таким образом можно в нескольких случаях:

    • если мобильное приложение рассчитано на массовую аудиторию и
      соответствует широкому спросу;
    • если размер приложения превышает 100 мегабайт и его скачивание займет много времени.
  2. Летсплей. Метод очень хорошо подходит для продвижения мобильных игр. Он представляет собой запись игры с комментариями игрока. Летсплей может содержать советы по прохождению уровней игры, а может быть и записью игрового процесса. Видео геймплея показывает и рассказывает о секретах и уловках игры, но может быть очень эмоциональным и смешным.
    Такой метод преследует несколько целей:

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

    Обычно съемками и публикацией летсплеев занимаются подростки или молодые люди. По стоимости летсплей обойдется недорого, если конечно это не летсплей от именитого игрока со своим каналом и большой аудиторией. Летсплеи размещают на форумах, в социальных сетях и в YouTube.
    Летсплеи нравятся аудитории. Подумать о его необходимости не будет лишним в стратегии продвижения приложения. Снять летсплей самостоятельно приемлемо, только вся его прелесть в том, чтобы рассказ велся от имени человека, который играет первый раз. Хороший летсплей всегда может рассчитывать на виральный эффект, что только поспособствует продвижению игры.

  3. Видеообзор приложения. Метод направлен на целевых пользователей и лишен эмоциональной составляющей. Хотя никто не запрещает и не мешает использовать юмор в обзоре. Видеообзор подходит не только играм, но и другим мобильным приложениям.
    Если говорить о видеообзоре мобильной игры, то он представляет собой что-то среднее между трейлером, рекламой игры и знакомством с игровым процессом.
    Видеообзор не игровых мобильных приложений больше направлен на то, чтобы показать выгоды приложения, основные преимущества или вовсе может представлять собой видеогид по приложению.
    Преимущество видео в том, что пользователи не хотят тратить свое время и читать описание приложения. Им проще посмотреть видео и принять решение, хотят ли они такое приложение или нет. С этой точки зрения видео становиться необходимым элементом продвижения приложения.
  4. Кобрендинг. Одним из перспективных методов маркетинга приложения является кобрендинг или подмена паблишера. В этом случае разработчик отказывается от упоминания своего имени и отдает приложение крупному издателю с расчетом на долю его трафика.
    Собирая приложения таким способом, издатель может раскручивать новые приложения используя кросс-промоушн внутри своих приложений т.е. рекламировать одни приложения с помощью других.
    Только в этом случае можно предложить аудитории воспользоваться дополнительной услугой, но которую предлагает уже другое приложение.
    Преимущества от кобрендинга есть. Многие издатели и разработчики уверенны, что только продуктивно сотрудничая можно добиться впечатляющих результатов.

Итого

При продвижении приложения обязательно воспользуйтесь всеми возможностями бесплатных и условно-бесплатных методов продвижения, после чего переходите к платным. Нужно засветиться в сторе? Идите в мотивированное ASO. Знаете, что ваши платящие пользователи вводят свои запросы в поисковую строку гугла? Осваивайте контекстную рекламу на поиске. Можете зацепить wow-эффектом? Используйте медийную рекламу или соцсети. У вас много денег и хочется просто получать много установок? Обратитесь в партнёрские программы. У вас много денег, есть приложение, но нет желания разбираться в продвижении? Обратитесь в агентство.

Но обязательно перед стартом продвижения любого приложения определитесь с тем, как вы будете анализировать результаты. Фундамент: unit-экономика.

Инструменты:

Дешевых и качественных вам инсталлов!

Источники: livetyping.comblog.applead.net

Качественный код и зачем нужен Code Review

пользователи уходят из вашего приложения | Клиентам | Качественный код и зачем нужен Code Review 13

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

Что такое качественный код

Не существует точного определения этого термина. Как правило, понимание того, как должен выглядеть качественный исходный код, основывается на многолетнем опыте специалиста. Некоторые программисты придерживаются абстрактного принципа KISS, который расшифровывается как Keep It Simple, Stupid! («Делай это проще, тупица!»). Отчасти этот метод проектирования справедлив, так как отражает главное правило хорошего кода — простота и ясность. Однако простоту часто путают с упрощением, поэтому о качестве исходного кода в профессиональной среде судят ещё по нескольким свойствам:

  • восприятие. Код не перегружен сложными конструкциями, поэтому его легко понять даже без дополнительной документации или комментариев;
  • сопровождение. В продуманный код легко вносить изменения: менять конфигурации или даже платформы;
  • расширение. В него просто добавить новую функциональность без риска сломать алгоритм кода. Даже если возникнут какие-то неполадки, их можно быстро устранить;
  • передача. Хороший код можно передать другим разработчикам для поддержки или доработки, и у них не возникнет трудностей с его прочтением;
  • покрытие тестами. Чем выше процент покрытия кода тестами, тем больше вероятность избежать ненужных багов в будущем.

Чтобы облегчить понимание кода в профессиональной среде, у каждого языка программирования есть свой Code Style — стандарт оформления. Именно он диктует правила: где ставить пробелы или скобки, как отделять строки или называть переменные. Может показаться, что эти нюансы не так важны, однако их соблюдение значительно облегчает понимание кода для тех, кто видит его впервые.

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

Как повысить качество кода?

Одна из самых популярных и при этом довольно простых в реализации техник носит название Code Review. Её смысл в том, чтобы любые изменения, вносимые программистом, попадали в основное хранилище кода и в релизную версию ПО только после того, как их проверят остальные участники команды.

Этот процесс состоит из нескольких этапов.

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

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

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

Дальше всё повторяется сначала и происходит систематически — каждый раз, когда в код вносится новая порция изменений.

Плюсы Code Review

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

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

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

Благодаря Code Review снижается так называемый bus-фактор, или «фактор автобуса». Так называют число, означающее количество участников команды, которых должен сбить автобус, чтобы все знания о проекте были потеряны. К примеру, в проекте занято четыре человека, если два из них по каким-то причинам уйдут, то оставшиеся смогут закончить работу, а если команду покинут трое — последний участник не справится в одиночку.

Минусы Code Review

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

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

Когда использовать Code Review?

Процесс Code Review достаточно прост, а его плюсы заметно преобладают над минусами, но в ряде ситуаций вы легко обойдетесь без него.

К примеру, нет смысла проводить Code Review при разработке прототипа или MVP — минимально жизнеспособного продукта. Главная задача такого проекта — получить от пользователей обратную связь, чтобы построить гипотезы для дальнейшего развития. Структура этих приложений делается максимально простой, и в дальнейшем код всё равно предстоит переписывать кардинальным образом.

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

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

Источник: livetyping.com

Разработка пользовательского интерфейса

пользователи уходят из вашего приложения | Клиентам | Разработка пользовательского интерфейса 15

Что такое разработка пользовательского интерфейса и зачем её заказывать? Попробуем ответить на этот вопрос в этой статье.

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

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

Что такое UI

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

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

Это точное, но скучноватое определение.

А вот иными словами, но интереснее: пользовательский интерфейс (UI) — это «способ, которым вы выполняете какую-либо задачу с помощью какого-либо продукта, а именно совершаемые вами действия и то, что вы получаете в ответ» (источник: Джеф Раскин, «Интерфейс. Новые направления в проектировании компьютерных систем»).

Зачем нужен UI

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

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

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

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

пользователи уходят из вашего приложения | Клиентам | Разработка пользовательского интерфейса 16

Пример перегруженного интерфейса

пользователи уходят из вашего приложения | Клиентам | Разработка пользовательского интерфейса 17

Пример «чистого» интерфейса

Разработка UI

Чтобы у нас с вами не возникло проблем при использовании какого-либо приложения, умные люди визуализируют его функциональные возможности в виде понятных элементов, и за этой визуализацией кроется целая кухня UX/ UI-дизайна.

Грань между UX (User Experience) и UI (User Interface) очень тонка, но если разобраться, то становится ясно, что UX помогает понять пользователя. В UX-дизайне больше психологического аспекта, нежели технологического. UX изучает пользователя: как пользователь живёт, что он думает, как и что делает и что его окружает. Перед дизайнером ставится задача — помочь обычному человеку легко разобраться с вашим программным продуктом и получить при этом удовлетворение от работы с ним.

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

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

Концепция

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

Создание мокапа

Этот этап позволяет быстро понять видение клиента и внести уйму изменений до начала разработки интерфейса. Мы намечаем расположение кнопок, форм и других нужных элементов, а уже потом подбираем цветовую палитру, шрифты, изображения, преобразуя всё это в удобный и красивый макет. То есть начинаем с варфрейма (план расположения элементов на странице), а заканчиваем созданием из этого плана красивой картинки. В случае разработки приложений под Android и iOS труд дизайнера облегчается гайдлайнами — правилами оформления и расположения элементов интерфейса, регламентом UX/UI, который был создан непосредственно экспертами по дизайну из Google и Apple.

пользователи уходят из вашего приложения | Клиентам | Разработка пользовательского интерфейса 18

Пример мокапа

User Flow Diagram (карта экранов)

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

пользователи уходят из вашего приложения | Клиентам | Разработка пользовательского интерфейса 19

Пример карты экранов

Утверждение структуры

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

Выбор стиля UI

Существует множество различных концепций, например: material design, metro, skeuomorphism и т. д.

пользователи уходят из вашего приложения | Клиентам | Разработка пользовательского интерфейса 20

Skeuomorphic design (слева) и flat design (справа)

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

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

Согласование стиля

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

Интерактивный прототип

«Прототип — это наглядная модель пользовательского интерфейса. В сущности это функционирующий «черновик» интерфейса, созданный на основе ваших представлений о потребностях пользователей» (источник: Эд Салливан, «Время — деньги. Создание команды разработчиков программного обеспечения»).

Для более наглядной демонстрации работы приложения инвесторам и потенциальным пользователям можно заняться разработкой интерактивного прототипа. Хотя стоит отметить, что это не обязательный этап, так как мокап+user flow diagram вполне себе является прототипом, описывающим будущий продукт с точки зрения UX. Однако интерактивный прототип даст более полное представление и о возможностях приложения, и об объеме работ по их реализации.

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

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

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

Утверждение результата

Вот он, последний этап работы над UI. Здесь всё очень просто: клиент оценивает результат, даёт комментарии и предложения, а мы при необходимости вносим правки.

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

Вывод

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

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

В «Психбольнице» Алана Купера говорится, что излишняя экономия на UI в дальнейшем выливается в трату на техподдержку, исправление ошибок, обучение новых сотрудников. Красивая обёртка в виде современного дизайна не есть человечный интерфейс; ключом к этой человечности служит проектирование под реального пользователя.

Проектирование интерфейса пользователя уменьшает время его разработки и упрощает взаимодействие пользователя с продуктом. Хорошо разработанный UI = благодарный пользователь = счастливый вы.

Источник: livetyping.com

Зачем вашему бизнесу мобильное приложение

пользователи уходят из вашего приложения | Клиентам | Зачем вашему бизнесу мобильное приложение 22

Мобильное приложение способно увеличить продажи компании, потому как служит средством привлечения и удержания клиентов.

15 лет назад компании, которые предлагали владельцам бизнеса создать сайты, едва получали заказы, потому что все разводили руками и говорили “зачем нам сайт, кому он нужен, ведь мы и так продаем?!” Сегодня бизнес без собственного сайта немыслим. И те компании, которые заранее позаботились об этом инструменте, забрали себе львиную долю клиентов, а другие лишь разочарованно вздыхают, что они не смогли попасть в число первых.

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

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

Повышение продаж

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

Лояльность

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

Люди уже устали от множества бонусных карт. Программа лояльности в мобильном приложении заменяет бонусную карту и даёт покупателю возможность освободить место в кошельке — отличный способ завоевать расположение клиента.

Привлечение клиентов

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

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

Целевая аудитория

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

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

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

Формирование доверия клиентов посредством push-уведомлений

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

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

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

Отстройка от конкурентов

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

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

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

Google предлагает такую возможность уже сегодня. Компания Яндекс также заявила о возможности настройки рекламных кампаний в Яндекс.Директ для мобильных приложений.

Связка «сайт + приложение»

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

Как это сделать?

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

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

Источник: dinect.com

Почему разработка мобильных приложений стоит дорого

пользователи уходят из вашего приложения | Клиентам | Почему разработка мобильных приложений стоит дорого 24

Рынок мобильных приложений продолжает бить и без того внушительные рекорды. По данным аналитической компании App Annie, число загрузок в App Store и Google Play в первом квартале 2018 года составило 27,5 млрд, а сумма, которую потратили пользователи приложений — $18,4 млрд. По сравнению с аналогичным периодом 2017-го цифры выросли на 10 и 22% соответственно.

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

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

Разработка мобильного приложения занимает сотни часов

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

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

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

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

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

Многие гипотезы можно проверить только опытным путём: пока не попробуешь — не узнаешь, как это будет работать и будет ли вообще. Иногда везёт, а иногда всё идёт совсем не так, как задумывалось. Это тоже сказывается на сроках разработки.

В 2016 году Лайв Тайпинг разрабатывал стриминговое мобильное приложение Infiniscene, сейчас недоступное. От конкурентов его отличала возможность стримить на серверы сразу нескольких популярных сервисов, включая YouTube, Twitch и Hitbox. Решить непростую задачу было можно только подбором подходящей библиотеки, которая одновременно работала бы с iOS и Android-устройствами, поддерживала нужный протокол вещания, кодировала видео в правильные форматы — и всё это за доступную цену. Чтобы сделать окончательное решение, разработчикам нужно было изучить и проверить пять библиотек. Это заняло 40 часов. Подробности можно узнать из кейса проекта.

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

Работа над приложением — это не только код

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

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

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

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

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

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

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

Создание приложения не заканчивается после релиза

Сама по себе публикация продукта на маркетах требует специальных навыков. У Google Play и App Store есть правила — если их нарушить, ваше приложение отклонят, и придётся устранять ошибки и терять время.

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

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

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

Высокий спрос на программистов определяет цену

Сегодня 2,5 млрд жителей земного шара пользуются смартфонами, и 76% из них проводят перед экранами гаджетов больше трёх часов в день. Все прогрессивные компании от банков до пиццерий стараются это использовать, а успех сервисов вроде Uber и Airbnb сделал невероятно популярной бизнес-модель, когда услугу можно заказать в приложении, а затем получить в офлайне.

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

Согласно статистике Business of Apps, часовая ставка iOS- и Android-девелоперов в Восточной Европе, куда традиционно относят и Россию, составляет 35 $.

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

Теперь умножьте эту ставку на количество часов (от 300 до нескольких тысяч в зависимости от сложности проекта). И это только труд разработчиков, без учёта других расходов, о которых мы рассказали выше.

Отсутствие приложения может стоить дороже

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

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

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

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

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

Источник: livetyping.com

Заказ приложений у фрилансеров

пользователи уходят из вашего приложения | Клиентам | Заказ приложений у фрилансеров 26

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

Фрилансом часто занимаются люди в свободное от работы времени в качестве дополнительного заработка или для повышения опыта в определенной сфере.

Очень часто используется оценка работы по планируемым трудозатратам (временная оценка помноженная на тарифную ставку 1 часа), но так же часто цена назначается фиксированная.

Качество работы фрилансера

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

Отличие фрилансера от удаленного работника

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

10 фактов про фрилансеров

  • пользователи уходят из вашего приложения | Клиентам | Заказ приложений у фрилансеров 27

    ФРИЛАНСЕРЫ ВЫПОЛНЯЮТ ТОЛЬКО ЧАСТЬ РАБОТЫ
    Студии мобильной разработки имеют разнопрофильных сотрудников, а так же партнерства для решения комплексных задач;

  • пользователи уходят из вашего приложения | Клиентам | Заказ приложений у фрилансеров 28

    ТРУДНОСТИ КОММУНИКАЦИИ
    Часто фрилансеры перестают отвечать на сообщения и звонки. В особенности это неприятно, когда приближается срок здачи;

  • пользователи уходят из вашего приложения | Клиентам | Заказ приложений у фрилансеров 29

    НИЗКОЕ КАЧЕСТВО РАБОТЫ
    К качеству работы фрилансера стоит относиться с опаской. Фрилансеру не придется выполнять поддержку своего кода, а следовательно достаточно решить задачу с минимальными гибкими возможностями. Времени на приведение в порядок кода — тоже не выделяют;

  • пользователи уходят из вашего приложения | Клиентам | Заказ приложений у фрилансеров 30

    ОТСУТСТВИЕ ПОДДЕРЖКИ
    Фриланесеры не заинтересованы в обременительной поддержке. Обычно они свободно относятся к своей работе и не хотят лишних проблем;

  • пользователи уходят из вашего приложения | Клиентам | Заказ приложений у фрилансеров 31

    НЕВЕРНОЕ ПОНИМАНИЕ ЗАДАЧИ
    На маленьких проектах люди не пытаются вникнуть в суть задачи, а обходятся простым решением. Это часто создает проблему не правильного понимания задачи;

  • пользователи уходят из вашего приложения | Клиентам | Заказ приложений у фрилансеров 32

    ДОПЛАТЫ
    Совесть для фрилансера из другого города — дело чуждое. Не редки случаи вымогательства денег. Особенно часто это бывает в середине проекта, когда исполнитель говорит что дальше делать не выйдет, если не сделать что-то дополнительное. Заказчики вынуждены доплачивать, ведь он уже оплатил часть работы и потратил много времени;

  • пользователи уходят из вашего приложения | Клиентам | Заказ приложений у фрилансеров 33

    ФРИЛАНСЕРЫ БОРЯТСЯ ЗА ЗАКАЗ
    Заказы фрилансерам обычно идут по принципу тендера. Очень часто фрилансеры делают заявки во все тендеры подряд «авось повезет». Исполнителю может выпасть такой субъект, который вообще будет не компетентен в вопросе;

  • пользователи уходят из вашего приложения | Клиентам | Заказ приложений у фрилансеров 34

    ЧУЖОЕ ПОРТФОЛИО
    Начинающие фрилансеры заимствуют работы портфолио у студий или у западных фрилансеров, выставляя их как собственные. Это может быть красивой ошибкой а не подтверждением профессионализма;

  • пользователи уходят из вашего приложения | Клиентам | Заказ приложений у фрилансеров 35

    ЗАВИСИМОСТЬ ОТ ФРИЛАНСЕРА
    Отдавая важный кусок работы фрилансеру, свы можете стать зависимым от него. Это опасно, т.к. на следующем этапе может быть поставлена новая задача, которая выходит за рамки компетенции фрилансера;

  • пользователи уходят из вашего приложения | Клиентам | Заказ приложений у фрилансеров 36

    ФРИЛАНСЕР НЕ ВСЕГДА ФРИЛАНСЕР
    Люди занимаются фрилансом часто в свободное время или как хобби. Это не обязывающая работа со свободным графиком, дисциплиной тут вообще даже не пахнет. Мы часто слышим фразу «От нас ушел фрилансер и выбрал работу в компании, что нам теперь делать на половине пути?»

В каких ситуациях пригласить фрилансеров в проект может быть уместным

  • пользователи уходят из вашего приложения | Клиентам | Заказ приложений у фрилансеров 37

    Дизайн;

  • пользователи уходят из вашего приложения | Клиентам | Заказ приложений у фрилансеров 38

    Тексты;

  • пользователи уходят из вашего приложения | Клиентам | Заказ приложений у фрилансеров 39

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

  • пользователи уходят из вашего приложения | Клиентам | Заказ приложений у фрилансеров 40

    Аудит чужого кода;

  • пользователи уходят из вашего приложения | Клиентам | Заказ приложений у фрилансеров 41

    Разовые работы которые не нуждаются в поддержке;

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

Принимайте работу фрилансера внимательно

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

  • Макеты, прототипы интерфейса приложения;
  • Схему структуры приложения (схема переходов);
  • Схема базы данных приложения (если используется);
  • Исходный код;
  • Архив используемых медиаматериалов (изображения, аудио, видео и др.), а так же исходники медиаматериалов при наличии;
  • Сертификаты публикации в маркеты (комплект);
  • Реквизиты доступа к сервисам разработчика, которые используются для работы приложения;

Касательно достаточности и актуальности материалов рекомендуется провести аудит. Хорошей практикой является запрос отчетных материалов по завершению промежуточных этапов.

Где найти фрилансеров

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

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

Выбирайте профессионалов

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

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

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

Не экономьте на качестве, в долгосрочной перспективе это окупится!

Источник: ios-lab.ru

Преимущества и недостатки кроссплатформенных приложений

Преимущества разработки кроссплатформенного приложения включают в себя:

  • Более короткое время разработки. Если вы выберите верный технический стэк и распланируете свой проект тщательно, вы получите возможность переиспользовать до 80% кода.
  • Рентабельность. Разработать нативное мобильное приложение обойдется вам в минимум десять тысяч долларов, и здесь мы говорим не о клоне “Clash of Clans”. Умножая стоимость IOS и Android и добавляя 30% (разработка Android более дорогая) и вы получите приблизительную стоимость запуска приложения на обоих платформах App store и Play market.
  • Воздействие на большое количество пользователей. Многие кроссплатформенные приложения работают на IOS и Android системах (также на Windows, Linux, Tizen и даже Symbian).
  • Синхронизация обновлений. В мире где разработчики приложений внедряют обновления 4 раза в месяц, техническое обслуживание может забирать большую часть доходов приложения на себя, и это именно то место, где выигрывают кроссплатформенные разработки.

Где приложения, независимые от платформы проигрывают:

  • Проблемы с производительностью. Вычислительная мощность смартфонов относительно мала. Содействие материально-техническому обеспечению HTML5/CSS UI, напротив, требует много ресурсов GPU/CPU и может увеличить время отклика приложения.
  • Проблемы с дизайном. Соединение UX требований по дизайну двух платформ может вызвать затруднение. Apple особенно печально известны своим Human Interface Guidelines и отклоняют вебсайты в нативной обертке. Однако 20% отказов в App Store приходятся на баги приложения и плохой UI дизайн. Если вы обратитесь к надежной компании по разработке кроссплатформенных приложений на HTML, ваше приложение скорее всего получит зеленый свет.

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

Выбор между нативной и кроссплатформенной разработкой приложения зависит от набора функций приложения и его назначения

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

Возвращаясь в 2012 год к Facebook, самой большой мировой социальной сети, реализация их приложения на HTML5 вместо нативного приложения IOS вполне может называться самой большой ошибкой, которую они когда-либо делали. По словам Мика Джонсона, бывшего управляющего отдела IOS в компании Facebook, решение перейти к нативной разработке решит три главных проблемы, связанные с показателями приложения, включая скорость загрузки, пролистывание ленты новостей и загрузки фотографий. Facebook спустя год продолжил реализацию нативного приложения уже и на Android. Компания ничего не имела против HTML5 – эта технология до сих пор используется для мобильной версии сайта. Однако все это не отвечало требования компании и могло в любой момент провалиться. Именно поэтому вам следует искать опытного разработчика, разрабатывать грамотный план стратегии вашей работы.

Статья переведена Екатериной Гулидовой. Источник: Andrew Klubnikin на medium.com