Мобильных разработчиков часто спрашивают, сколько будет стоить реализовать ту или иную идею. Например, сделать аналог «Убер» или «Авито». При такой постановке вопроса трудно оценить предстоящие трудозатраты, что создает большой разброс цен у разных разработчиков и недоверие со стороны заказчика. Ещё одной проблемой является недостаточная проработка идеи. Зачастую заказчик видит общую концепцию приложения, но слабо представляет детали. Это приводит к лишним затратам на обсуждение и переписывание требований.
Эта статья адресована в первую очередь тем, кто задумался о заказе собственного приложения. В ней мы ответим на распространенные вопросы и дамим несколько советов, которые помогут вам проработать идею и не потратить лишнего.
Из этой статьи вы узнаете:
сколько стоит создать приложение по вашей идее;
из каких этапов состоит разработка;
как составить бриф и получить оценку без ТЗ;
нужно ли рисовать прототипы и как это лучше сделать;
стоит ли пользоваться конструкторами приложений;
нужно ли создавать под проект нативное приложение, или можно обойтись кроссплатформенным;
как спланировать сроки релиза, чтобы выпустить приложение вовремя.
У меня есть идея приложения. Сколько будет стоить разработка?
C ходу вам никто не скажет. Каждый более-менее крупный проект состоит из нескольких компонентов: самого приложения, сайта, базы данных, панели управления. Насколько затратным выйдет каждый компонент — зависит от ваших потребностей, уникальности задачи и специфики бизнеса.
Недавно мы разместили на бирже заказ на разработку клона «Убер». Одни исполнители просили 100 000 рублей, а другие — до 5 000 000.
Почему такой большой разброс цен?
Разные разработчики — разная стоимость часа работы.
Разные разработчики — разное понимание исходных требований.
Многие независимые разработчики оценивают проект, опираясь на личный опыт. Не факт, что ваше приложение будет похоже на то, что они уже делали.
Получить ориентировочную стоимость разработки можно и самостоятельно, с помощью специального калькулятора. Это не займет более трех минут вашего времени.
Из каких этапов состоит разработка?
Разработка приложений не ограничивается написанием кода. Вот что происходит после того, как ваша идея попадает в руки к разработчику:
Планирование и оценка — знакомство с документацией заказчика, составление плана работ.
Аналитика — выявление требований и способов их реализации.
Дизайн — отрисовка экранов, подготовка материалов для вёрстки, иконок, скриншотов для магазинов, создание интерактивных прототипов.
Разработка —верстка, разработка API, подключение (иногда интеграция со сторонними сервисами).
Тестирование — проверка всех возможных сценариев использования в различных условиях.
Релиз — публикация приложения в Apple App Store и Google Play.
Сопровождение — поддержка и развитие проекта после релиза.
Каждый этап требует времени и усилий. Если вам предлагают сделать приложение за 100 000 рублей без ТЗ – это повод насторожиться.
Когда я смогу узнать точную стоимость и сроки?
Как правило, точную оценку можно получить уже на этапе аналитики. К этому моменту ваша идея детализируется до конкретных требований, реализацию которых можно измерить в человеко-часах.
Проработка требований может занять от нескольких дней до нескольких недель, в зависимости от сложности проекта. Вы можете значительно ускорить этот процесс, если предоставите разработчику качественное ТЗ.
А можно как-нибудь без ТЗ?
Да, можно. Если вы хотите узнать нижний порог стоимости разработки, то ТЗ можно заменить на краткий бриф.
Бриф — это своего рода анкета для вас и разработчика. Он помогает лучше понять целесообразность идеи и определиться с функциями, которые должны быть в приложении.
В брифе необходимо проработать 4П: пользователей, проблемы, преимущества и прибыль.
Пользователи
Разные люди — разные потребности. От выбора целевой аудитории зависит то, каким должно быть приложение. Например:
В приложениях для пожилых людей используют большие кнопки и минимум настроек.
В приложениях для вызова такси часто встречаются дополнительные опции для пассажиров с детьми и домашними питомцами.
Проблемы
Если приложение не поможет пользователю решать его задачи, то он его, скорее всего, удалит.
Опишите конкретные ситуации, в которых ваше приложение будет полезно людям. Например:
«Заказать такси, когда забыл деньги»,
«Сравнить цены на пылесосы»,
«Найти кафе поблизости».
Преимущества
Чтобы «выстрелить», ваше приложение должно выгодно отличаться от аналогов. Как этого добиться:
Следует помнить, что магазины приложений в некоторых случаях берут внушительную комиссию за покупки пользователей, что может отразиться на сроках окупаемости проекта.
Бриф формирует общее видение проекта. В дальнейшем его можно использовать при составлении ТЗ с требованиями.
Старайтесь описывать требования, а не озвучивать. Так вам не придется по несколько раз пересказывать одно и то же. Если же вам легче формулировать мысли устно, воспользуйтесь голосовым вводом в Google Документах.
Нужно ли рисовать прототипы?
На ваше усмотрение. Прототипы помогают представить, как будут выглядеть экраны приложения. Если вы нарисуете их сами, то дизайнеру не придется придумывать всё с нуля. Он сможет глубже понять вашу идею и поможет развить её до окончательного варианта.
Создавать прототипы можно с помощью бесплатных сервисов или нарисовать от руки.
Список наиболее удобных решений для создания прототипов:
При создании прототипов ориентируйтесь на сценарии действий пользователя. Задавайте переходы между экранами, чтобы не упустить важных шагов.
Что ещё может повлиять на сроки оценки?
Могут возникнуть сложности при планировании интеграции. Например, если приложение должно обмениваться данными с внешним сервисом на Bitrix. Такие моменты сложно оценить, так как приходится постоянно взаимодействовать с командой на стороне клиента. Работа может стопориться просто из-за того, что разработчик всё утро ждал обратную связь от специалиста по CRM.
Создайте общее информационное пространство, в котором ваши специалисты будут отвечать на вопросы мобильных разработчиков. Например, с помощью Google Таблиц, Trello или других менеджеров задач. Собранную таким образом информацию потом можно использовать для доработки ТЗ.
Что лучше: нативное приложение или кроссплатформенное?
Кроссплатформенные приложения менее отзывчивы и не всегда корректно работают на обеих платформах. Если нужно быстро создать простое приложение (например, на основе сайта), то этот вариант вам подходит.
Нативные приложения могут по максимуму использовать возможности своих платформ и работать в офлайн. При этом дизайн приложения будет соответствовать тому, к чему привыкли пользователи Android или iOS. При нынешних тенденциях рынка данный вариант является предпочтительным.
Если ваш бюджет ограничен, закажите нативное приложение для одной платформы. Так вы получите минимально жизнеспособный продукт (MVP) c полным функционалом. С его помощью вы получите адекватную обратную связь от пользователей и поймете, нужно ли вкладывать в разработку для второй платформы.
Стоит ли использовать конструкторы приложений?
Конструкторы приложений предназначены для решения базовых задач бизнеса. Их главный плюс — возможность собрать и настроить приложение самостоятельно, экспериментируя с готовыми модулями. Если ваше приложение является типовым для своей ниши (делает то же, что и другие), вы можете собрать его с помощью конструктора. Если вам нужно что-то более специфичное, то этот вариант не подходит.
Стоит отметить, что большинство конструкторов — это франшизы. Фактически вы получаете доступ к приложению, который необходимо оплачивать. При этом некоторые недобросовестные владельцы франшизы оставляют за собой право менять условия сотрудничества или блокировать доступ клиента к личному кабинету.
Перед тем, как воспользоваться услугами конструктора, почитайте отзывы о приложениях, которые были созданы на его основе. Информация об успешных кейсах в портфолио не всегда соответствует реальному опыту использования.
Что если мое приложение должно быть готово к определенной дате?
Планируйте срок с запасом. К примеру в AppStore приложения проходят ревью, которое может занять более месяца. А повлиять на Apple нельзя.
Даты мероприятий, связанных с презентацией и продвижением приложения, назначайте после прохождения ревью.
Резюме
Одну и ту же идею можно оценить по-разному. Назвать точную стоимость и сроки разработки можно только после выявления и согласования требований.
Никогда не обсуждайте требования устно. Для правильной оценки у всех членов команды должна быть одинаковая информация, зафиксированная письменно.
Чтобы лучше донести свою идею для разработчика, можно составить бриф и нарисовать макеты экранов. В брифе нужно описать 4П: пользователей, проблемы (сценарии), преимущества и прибыль (способы монетизации) .
Чтобы не пришлось по несколько раз объяснять одно и то же — фиксируйте требования письменно.
Прототипы помогают проработать пользовательские сценарии и не упустить важных шагов. Если рисуете прототипы от руки, не забудьте показать логику перемещения между экранами (нажал здесь — перешел туда) .
Чтобы наладить коммуникации между разработчиками и вашими специалистами, ведите обсуждение в менеджерах задач.
Кроссплатформенные приложения подходят только для небольших и неприхотливых приложений. Во всех остальных случаях лучше выбрать нативную разработку.
Если ваш бюджет ограничен, создайте MVP-версию приложения для одной платформы, чтобы получить обратную связь от пользователей.
Конструкторы приложений подходят для решения типовых задач бизнеса. Для чего-то более специфичного лучше обратиться к студиям разработки.
Если ваше приложение должно быть готово к определенной дате, планируйте его выпуск хотя бы за месяц. Мероприятия по презентации и продвижению назначайте после ревью (особенно критично для iOS).
Итак, у вас есть готовый бизнес и вы хотите сделать для него мобильное или web-приложение. С чего же стоит начать разработку?
Начните с проектирования
Главная задача на старте разработки — придумать, как упаковать бизнес-модель в мобильный или web-интерфейс и как этот интерфейс будет реализован технически. Это важно, потому что хороший пользовательский опыт — такой, при котором пользователь быстро и приятно решает свою задачу — одна из составляющих успеха будущего проекта.
На пути к хорошему UX стоит решение двух вопросов: как пользователь будет работать с вашим продуктом и как именно должно работать приложение. Чтобы понять, как это обеспечить, разработку приложений нужно начинать с проектирования.
Работу над диджитал-проектом нельзя провести по готовому сценарию. Чаще всего это проектная работа. Если вкратце, вас ждут семь этапов: знакомство и оценка, проектирование, дизайн, разработка, тестирование, поддержка и маркетинг. И для каждого проекта содержание и набор этапов разные, потому что каждый раз у проекта свои бизнес-цели, целевая аудитория, технические ограничения, ограничения по бюджету, особенности бизнес-процессов и так далее. Чтобы понять, как во всех этих условиях сделать приложение максимально полезным и бизнесу и пользователям, нужно сделать проектирование.
Зачем проектирование нужно мне, клиенту?
Проектирование не даёт вам готовый продукт. «Почему тогда я должен платить за ваше понимание того, как вы будете делать проект?», — спросите вы. Ведь вы хотите платить за успешный запуск.
Вопрос резонный. А теперь ответ.
Во-первых, если мы не разберёмся, мы не сделаем проект успешным. Во-вторых, если вы не заплатите за то, что вам продают как проектирование, вы либо заплатите за него скрытым образом (например, за высокий процент издержек, заложенных на риски), либо вам придётся платить за то, что кто-то исправит последствия так себе сделанного проекта.
Правильный ответ: ни за то, ни за другое.
Проектирование не нужно делать вообще только в том случае, если у вас во дворе бьёт фонтан из денег, а вашим партнёрам чихать на дедлайны. А когда вместо фонтана денег — частокол ограничений, тогда оно очень даже необходимо. Ограничения могут быть во времени, в бюджете, в программном обеспечении, в организации бизнеса или в платформе, на которой мы хотим это сделать.
Как проектирование помогает избежать рисков?
Повторимся: разработка мобильного приложения — это проектная работа. У проектной работы есть одна особенность: оценить стоимость проекта позволит понимание того, какой он по объёму. А чтобы понять объём, нужно посмотреть на проект изнутри, то есть уже начать его делать. Во время проектирования команда занимается именно этим: изучает проект и придумывает то, как он будет устроен.
Проектирование как сложносоставной процесс начинается с функционального проектирования: компания и клиент обсуждают и описывают функции, которые должны быть в приложении. Это такое ТЗ без упоминания о языках программирования, технологиях и других специфических деталях. На этом этапе вы и исполнитель определяете, что можно будет делать с помощью приложения, а как это будет устроено — определят уже разработчики и на другом этапе.
Затем студия вместе с вами думает, как это всё будет выглядеть. Для этого дизайнеры рисуют прототип интерфейса. Он показывает основные окна приложения, расположение кнопок, взаимосвязь между ними.
Дальше, если есть необходимость прояснить рисковые технические моменты, делается техническое проектирование или, по-другому, исследование о том, возможно ли воплотить те или иные идеи в жизнь. Это делается, чтобы определить, как желаемая функциональность будет работать изнутри.
Например, вы хотите сделать мобильное приложение для интернет-магазина. Скорее всего, он работает на собственной CMS, в нём установлена система учёта товарных остатков, ИТ-система для работы с логистикой товаров, система бухгалтерии и не одна система оплаты. Чтобы всё это интегрировать в мобильное приложение, нужно разобраться, каким способом передавать данные от этих систем. А чтобы понять это, нужно исследовать имеющийся проект.
Изучить детали проекта, выяснить все ограничения, поговорить с Дайян.
Почему важно делать техническое проектирование? Потому что оно позволяет узнать больше про технические ограничения проекта, стоимость и риски. Технические ограничения могут повлиять и на функции, и на прототип, и на дизайн, поэтому чем раньше вы сделаете техническое проектирование, тем лучше. В процессе может выясниться, что вам придётся переутвердить или доделать какие-то бизнес-процессы, чтобы продукт получился таким, каким вы его хотите видеть.
Вывод
Создание мобильного или web-приложения — это проектная работа. И отвечая на вопрос «с чего начать разработку приложения?», напомним, что для того, чтобы оценить и провести проектную работу максимально успешно в рамках ограничений, нужно сделать проектирование.
В процессе проектирования команда выясняет функциональные требования проекта, создаёт прототип и на его основе решает, как функциональность будет реализована.
Начиная создание приложения с проектирования, вы узнаёте максимальное количество рисков проекта ещё до того, как начали разработку. Для проекта это намного дешевле и безопаснее, чем начать делать его вслепую. В этом случае вы можете столкнуться с проблемой, которая потребует серьёзной, а значит, дорогой доработки. С проектированием этого можно избежать.
Почему цена разработки приложения может отличаться так сильно и почему не все готовы работать по фиксированной цене? Эта статья адресована менеджерам, предпринимателям и компаниям, которые собираются заказать разработку приложения. Она избавит вас от непонимания и возмущения, связанного с оценкой трудозатрат на разработку ПО, и объяснит, к какой категории клиентов вы относитесь и как эту категорию менять.
Фиксированная цена может быть разной. Чтобы дать фиксированную оценку, агентство должно чётко понимать объём труда, а это и есть самая сложная часть в области разработки программного обеспечения. Спросить цену у разработчиков — это всё равно что задать вопрос: «Сколько стоит вспахать поле?». Как только вы определитесь с размером поля, то всё станет понятно. Вот только для ПО не существует всем понятных единиц измерения, кроме денег.
Если вы клиент, то к какой из следующих категорий вы относитесь?
Случай 1. Клиент знает размер поля и уже вспахивал его много раз
Тогда вы не будете искать новых подрядчиков. Вы либо работаете с теми, кого хорошо знаете и с кем есть отношения и доверие, либо «вспахиваете поле» самостоятельно, то есть со своей командой.
Это лучший случай, здесь всё налажено.
Случай 2. Клиент знает размер поля и вспахивал поле раз или два
В этой ситуации вы ищете подрядчика для очередного сезона. Может, кто-то сделает работу дешевле или быстрее или готов начать в ближайшее время. Возможно, те, с кем вы работали раньше, сейчас не могут помочь или ставят слишком высокую цену.
Тут начинается рутинный процесс подбора команды из имеющихся на рынке. После того, как вы пять раз «вспашете» одно и то же поле, у вас должны сложиться отношения с конкретной командой и появиться уверенность в корректности оценки. Всё это до тех пор, пока вы не переедете на другой участок.
Случай 3. Клиент знает примерный размер поля и примерный бюджет
При этом ни тип почвы, ни то, какая её часть вообще пригодна, вы не знаете. Если подрядчик только что озвучил точную стоимость, то вам нужно спросить его, откуда он знает размер поля. Он уже на нём работал? Или примерно на таком? Это поле площадью плюс-минус 10 соток? Ну, может, плюс-минус 30 соток? Так не пойдёт, слова «примерно» и «может» вам не подходят.
Но если вы доверяете подрядчику и вам без разницы, будет ли это нижняя граница бюджета или верхняя, то, скорее всего, для вас приоритетны скорость и качество, а не цена.
Если ваше поле не прямоугольное, больше футбольного, или с размерами вообще ничего не понятно, то у вас может быть случай 4. Вам как минимум нужна помощь в измерениях. Тяжело сравнивать подрядчиков по тому, что включено в общую цену, ведь все думают про размеры исходя из своего опыта. Помните, что разработчики мыслят не «сотками» и «гектарами».
Стоимость в час не сильно поможет сравнить подрядчиков. Без понимания производительности, которая зависит от опыта команды, технологий, инструментов и людей. Вспахать поле можно лопатой, ручным плугом, трактором — скорость будет разная.
Мы рекомендуем провести межевание — измерение участка земли и определение его границ. Зная площадь, подрядчика выбрать гораздо легче. Вы сразу переходите в случай 2.
Случай 4. Клиент не знает размер поля и понимает, что нужно межевание
Либо сделайте это сами, если умеете, либо попросите профессионалов. Обязательно посмотрите на зафиксированные измерения, убедитесь что вы их понимаете. Это нормально — знать примерные размеры перед межеванием и иметь определённый бюджет на вспашку поля. А вот заказывать услугу вспашки земли с фиксированной ценой без знания размеров поля не нормально. Потому что в такой игре кто-то точно проигрывает. Вам же не хочется иметь половину перепаханого поля? Пока вы найдете подрядчика для второй половины, пахотный слой высохнет и поле придётся обрабатывать заново.
Если у вас очень необычное поле или чётких границ вообще нет, определитесь, сколько и какой нужно земли для посадки растений, которые обеспечат вам выживание (иначе говоря, что нужно для разработки MVP — минимально жизнеспособного продукта) и далее обрабатывайте участок небольшими площадями (гибкая методология разработки).
Правильное построение взаимоотношений между заказчиком и исполнителем это половина успеха разработки. Подходящий для проекта тип контракта помогает минимизировать риски и увеличить шансы на положительный результат для обеих сторон: клиента и компании-разработчика. В прошлой статье мы сравнили подходы 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 в таком случае очень удобен — вы можете вносить корректировки непосредственно в ходе работ.
Постоянная коммуникация и обсуждение всех деталей помогут вам создать проект, который будет эффективно решать задачи вашей компании и иметь перспективу для дальнейшего развития.
Допустим, вы решили разработать программное обеспечение, не имея собственной команды разработчиков. Понятно, что без подрядчика здесь не обойтись. Не ясно другое: как эту работу оплачивать? То есть какую из моделей финансового взаимодействия выбрать: фиксированную ставку или выделенную команду? Что будет рационально именно для вас? Вопрос резонный и волнующий, а потому – давайте разбираться.
Существует ещё одна модель — Time & Material. Прочитать о ней вы сможете в следующей статье.
С точки зрения клиента
Модель с фиксированной ставкой (Fixed price model)
Когда использовать:
Когда проект краткосрочный.
Когда у вас есть полное описание проекта, с указанием четких целей, рабочих процессов и результатов.
Когда вероятность того, что требования к проекту изменятся, ничтожно мала.
Когда вы работаете с новым исполнителем (пилотный проект с фиксированной оценкой может стать отличной проверкой подрядчика, который обещает быть вашим постоянным партнером).
Модель с фиксированной ставкой любит грамотно и тщательно составленную документацию. Документацию, требования в которой не будут меняться с направлением ветра, настроением и чем бы то ни было. Конечно, договариваться с подрядчиком можно о чем угодно, но если проект идет полным ходом, а вы решаете перевернуть все с ног на голову – пеняйте на себя. И имейте в виду, что дедлайн (с большой вероятностью) будет просрочен, а релиз проекта – задержан.
В форс-мажорных ситуациях необходимо определить, насколько важны изменения для текущей версии продукта. Если менять состав задач все-таки нужно, но отодвинуть дедлайн при этом нет возможности, остается разве что вариант жертвовать другими задачами.
Модель с выделенной командой (Dedicated team model)
Когда использовать:
В долгосрочной разработке программного обеспечения, когда текущий план развития подразумевает привлечение дополнительных ресурсов и использование новых технологий.
Когда первоначальные потребности и цели неясны, то есть в самом начале не совсем ясно, каким будет конечный результат (например, в случае стартапа).
Когда заранее известно, что будут меняться требования к проекту или приоритеты задач (поскольку на вас работает выделенная команда, поменять курс не составит сложностей).
Преимущество модели с выделенной командой в том, что последняя находится в полном вашем распоряжении: поставщик услуг предоставил инфраструктуру, административную поддержку и специалистов, а уж вы вправе диктовать им методологию разработки и практики, техническую платформу и даже корпоративную культуру и политику. Команда находится на удаленном расстоянии, но выполняет все, чем должна заниматься команда, находящаяся у вас в офисе. По сути, функции менеджера проекта остаются за вами.
Чтобы выбрать модель, действительно целесообразную для вас в каждом конкретном случае, нужно обсудить целый ряд деталей. И обсуждать это стоит непосредственно с подрядчиком.
Возможно, в вашем случае оптимальнее всего будет начать с фиксированной ставки и через некоторое время перейти к привлечению выделенной команды.
И не бойтесь, что мнение подрядчика будет идти вразрез с тем, что оптимально для вас. Впрочем, вот вам мнение разработчиков относительно каждой из моделей взаимодействия.
С точки зрения разработчика
Чтобы быть как можно более объективными, мы обсудили вопрос с разработчиками, которые имеют опыт более трех лет и успели за это время поработать как в выделенной команде, так и в проектах с фиксированной оценкой. И вот, что из этого вышло.
Модель с выделенной командой (Dedicated team model)
Преимущества выделенной команды:
Некоторые люди любят знать, что они будут делать следующие несколько месяцев, поэтому они предпочитают стабильность работы в выделенной команде.
Модель выделенной команды позволяет разработчику получить более глубокие знания технологий проекта. Осознание того, что скорее всего придется поддерживать проект после окончания его разработки, заставляет разработчиков более четко продумывать его архитектуру, масштабируемость и т.д.
Ежедневное общение с заказчиком или его представителем – обязательное требование для таких проектов. Это повышает коммуникативные навыки разработчиков и улучшает взаимопонимание между клиентом и командой.
Минусы выделенных команд:
На каждом проекте есть более или менее интересные задачи. Так вот задачи по доработке и поддержке проектов, как правило, относятся к не самым интересным. К примеру, в таком случае, команда может тратить более 20% времени на техподдержку разных проектов заказчика.
Поскольку любая выделенная команда – это «компания внутри компании», команда подчиняется всем процессам заказчика. Иногда эти процессы отличаются от тех, к которым они привыкли в своей компании. Тут важную роль играет способность конкретного специалиста приспосабливаться к новым условиям: все очень индивидуально.
У выделенных команд обычно упрощенные спецификации на разработку нового функционала или проекта. Это дает им определенную свободу: возможность предлагать свои решения поставленных задач, вместо того чтобы слепо следовать написанным спецификациям. Но и здесь есть свои оговорки: буквально каждое такое решение должно быть согласовано с владельцем продукта на стороне клиента до начала его разработки, что требует от специалиста настойчивости в обосновании своих решений.
Модель с фиксированной ставкой (Fixed price model)
Преимущества проектов с фиксированной ценой:
Некоторые разработчики, напротив, любят изменения. Каждый новый проект требует изучения новых технологий, подходов и решений. И четкий дедлайн воспринимается некоторыми специалистами как вызов: достаточно ли они хороши, чтобы справиться с задачей в короткие сроки?
Понятные спецификации позволяют более полно взглянуть на проект.
Новый проект, к примеру стартап, может рассмотреть предложенное подрядчиком техническое решение, которое наилучшим образом подойдет для реализации проекта, разработки его архитектуры, подбора необходимых инструментов и т.д.
Уже на стадии оценки разработчики «разбивают» проект на отдельные задачи, так что клиент заранее представляет, как будет строиться работа. В то время как выделенная команда проделывает то же самое, уже в процессе работы на стороне заказчика.
Минусы проектов с фиксированной ценой:
В таких проектах разработчики редко общаются напрямую с заказчиком. Как правило, этим занимается менеджер проектов. А это значит, что успешность проекта во многом зависит от того, насколько хорошо налажен диалог. Но есть и другая сторона: разработчикам не приходится отвлекаться от работы на ежедневные разговоры.
Такие проекты нельзя назвать гибкими, ведь риски по умолчанию присутствуют всегда, а при данной модели ими сложно управлять. Все осложняется и тем, что нужно уложиться в бюджет. Но это проблема отнюдь не программиста, а управленца на проекте.
Заключение
Все очень и очень относительно: одни и те же особенности разных моделей могут считаться как плюсами, так и минусами. Причем как для вас, так и для подрядчика. А потому однозначно отвечать на вопрос, какая же из моделей лучше, попросту не имеет смысла. Ведь в каждой конкретной ситуации ответ будет новым. Разговаривайте с подрядчиком, обсуждайте нюансы, приходите к общему знаменателю и принимайте рациональные решения.
Что такое разработка пользовательского интерфейса и зачем её заказывать? Попробуем ответить на этот вопрос в этой статье.
В повседневной жизни мы постоянно сталкиваемся с интерфейсами. Это и сайты соцсетей, и элементы управления в салоне автомобиля, и пульт ДУ для телевизора, и голосовое управление умным домом, и панель кнопок в лифте.
Выходит, мы используем один продукт для управления другим продуктом. Но давайте не будем перечислять все явления в нашей жизни, а поговорим непосредственно о веб-сервисах и мобильных приложениях и о том, как сделать их использование удобным.
Что такое UI
Прежде чем начать говорить о разработке графического интерфейса пользователя, давайте на всякий случай уточним, что это такое.
Интерфейс — общая граница между двумя функциональными объектами, требования к которой определяются стандартом; совокупность средств, методов и правил взаимодействия (управления, контроля и т. д.) между элементами системы (источник: wikipedia.org).
Мы разобрались, что такое пользовательский интерфейс, но пока не ясно, насколько он нам нужен и стоит ли тратить деньги на его разработку и дизайн. Поэтому на минуту вернёмся к лифтам.
Лифт удобен. Он позволяет добраться до верхних этажей с минимумом временных и физических затрат. Но какой от него был бы толк, если бы мы не могли легко его открыть, выбрать этаж и при необходимости остановиться раньше времени? Всё перечисленное осуществимо, но каким путём? Позволит ли рычажное управление сделать пассажиру необходимые действия или разумнее будет использовать кнопочное управление? Тут и появляется важный момент: какой интерфейс управления лифтом выбрать.
Современные веб-сервисы и системы в корне меняют работу людей. Существуют, например, системы управления театральными механизмами, которые упрощают работу с электронным оборудованием, лишая необходимости постоянно находиться у аппаратуры. Но едва ли работа упростится, если у таких систем будет слишком сложный интерфейс.
Получается, что программный интерфейс не только решает нашу проблему взаимодействия с приложением, но и делает это взаимодействие максимально комфортным. Нам важно наличие интерфейса, позволяющего при меньшем количестве усилий ознакомиться с возможностями приложения и понять принципы работы в нём.
Пример перегруженного интерфейса
Пример «чистого» интерфейса
Разработка UI
Чтобы у нас с вами не возникло проблем при использовании какого-либо приложения, умные люди визуализируют его функциональные возможности в виде понятных элементов, и за этой визуализацией кроется целая кухня UX/ UI-дизайна.
Грань между UX (User Experience) и UI (User Interface) очень тонка, но если разобраться, то становится ясно, что UX помогает понять пользователя. В UX-дизайне больше психологического аспекта, нежели технологического. UX изучает пользователя: как пользователь живёт, что он думает, как и что делает и что его окружает. Перед дизайнером ставится задача — помочь обычному человеку легко разобраться с вашим программным продуктом и получить при этом удовлетворение от работы с ним.
А понять пользователя очень важно. Никому не захочется заполнить двадцать полей формы для регистрации на сайте или перещелкать штук пятнадцать вкладок, прежде чем добраться до нужной функции. «Пользователя не следует заставлять взаимодействовать с программой дольше, чем абсолютно необходимо для решения той или иной задачи» (Алан Купер, «Психбольница в руках пациентов»).
Это реальная проблема, которую должен решить дизайнер, и с этапами решения этой проблемы мы познакомимся немного ближе.
Концепция
Сначала нам необходимо сориентироваться в элементах будущего интерфейса. Для этого мы определим задачу, исследуем предметную область, аудиторию и то, как она пользуется продуктом.
Создание мокапа
Этот этап позволяет быстро понять видение клиента и внести уйму изменений до начала разработки интерфейса. Мы намечаем расположение кнопок, форм и других нужных элементов, а уже потом подбираем цветовую палитру, шрифты, изображения, преобразуя всё это в удобный и красивый макет. То есть начинаем с варфрейма (план расположения элементов на странице), а заканчиваем созданием из этого плана красивой картинки. В случае разработки приложений под Android и iOS труд дизайнера облегчается гайдлайнами — правилами оформления и расположения элементов интерфейса, регламентом UX/UI, который был создан непосредственно экспертами по дизайну из Google и Apple.
Пример мокапа
User Flow Diagram (карта экранов)
Как только мы разобрались с эскизом, самое время приступить к карте экранов и понять, как же будет вести себя обычный человек при использовании будущего инструментария приложения и какое состояние будет принимать интерфейс при каждом взаимодействии пользователя с ним.
Пример карты экранов
Утверждение структуры
Клиент утверждает разработанную структуру и пользовательские сценарии, а разработчик движется дальше. Этот этап позволяет исключить будущие изменения или сделать их незначительными. Если структура потеряет баллы в логике или дизайн потребует глобальной переработки, это не пойдёт проекту на пользу.
Выбор стиля UI
Существует множество различных концепций, например: material design, metro, skeuomorphism и т. д.
Skeuomorphic design (слева) и flat design (справа)
При выборе стиля интерфейса следует учесть текущие тенденции в дизайне, адаптивность, время на разработку и внедрение дизайна, и много других не менее важных моментов.
В любом веб-сервисе или мобильном приложении дизайн помогает пользователю решить его насущную проблему, поэтому нестандартные фишки и яркие цвета отходят на второй план.
Согласование стиля
Наконец, клиенту можно показать версию разработанного дизайна, попутно обосновывая стилевые решения. На этом этапе обрабатываются любые замечания клиента, чтобы прийти к обоюдному решению. Когда стиль выбран, дизайнер рисует макет, опираясь на правила гайдлайнов и фирменную стилистику клиента. На выходе мы получаем удобный и красивый дизайн мобильного приложения.
Для более наглядной демонстрации работы приложения инвесторам и потенциальным пользователям можно заняться разработкой интерактивного прототипа. Хотя стоит отметить, что это не обязательный этап, так как мокап+user flow diagram вполне себе является прототипом, описывающим будущий продукт с точки зрения UX. Однако интерактивный прототип даст более полное представление и о возможностях приложения, и об объеме работ по их реализации.
Варианты прототипа зависят только от ваших временных ресурсов и от уровня желаемого качества. Это может быть тестовый стенд, на котором оператор вручную выполняет изменения состояния приложения в зависимости от выбора пользователя, или это может быть уже программная реализация, которую можно запустить на смартфоне или в браузере, прокликать все экраны, оценить логику работы продукта.
Задача процесса проектирования пользовательского интерфейса приложения — неотъемлемая часть прототипирования. Дизайнеры изучают будущих пользователей, используя для этого разные методы: обсуждение вопроса с ближайшим окружением, разговор непосредственно с клиентом, обсуждение с потенциальной аудиторией (вживую или на форумах) и интервью для выявления актуальности проблемы и поиска путей её решения пользователем.
Результатом такого изучения становится описание целевой аудитории и более ясное понимание того, какие трудности могут возникнуть при использовании сервиса, и как эти трудности преодолеть.
Утверждение результата
Вот он, последний этап работы над UI. Здесь всё очень просто: клиент оценивает результат, даёт комментарии и предложения, а мы при необходимости вносим правки.
К этому моменту у нас должно быть готово техническое задание, заключающее в себе всю информацию, с которой мы работали на этапе прототипирования и проектирования. Имея на руках готовый дизайн и ТЗ, мы приступаем к разработке приложения.
Вывод
Поэтапная разработка интерфейса приложений и сложных систем экономит время, структурирует всю работу, уменьшает вероятность дополнительных денежных вложений. Думаю, из всего вышенаписанного уже понятно, что интерфейс в принципе необходим для удобного взаимодействия пользователя с приложением. Но что самое главное — это умение разработать интерфейс, в котором пользователь найдёт ключевые функции продукта за минимально необходимое для этого время.
Согласитесь, что эта задача не из лёгких, потому что и слишком сложный, и наоборот, непродуманный простой интерфейс могут здорово испортить всё впечатление от любого веб-сервиса или мобильного приложения.
В «Психбольнице» Алана Купера говорится, что излишняя экономия на UI в дальнейшем выливается в трату на техподдержку, исправление ошибок, обучение новых сотрудников. Красивая обёртка в виде современного дизайна не есть человечный интерфейс; ключом к этой человечности служит проектирование под реального пользователя.
Проектирование интерфейса пользователя уменьшает время его разработки и упрощает взаимодействие пользователя с продуктом. Хорошо разработанный UI = благодарный пользователь = счастливый вы.
Рынок мобильных приложений продолжает бить и без того внушительные рекорды. По данным аналитической компании 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-уведомлений, получать отзывы и отслеживать интерес внутри приложения.
Пока ваши клиенты вынуждены вбивать адрес сайта через мобильный браузер или узнавать последние новости компании через почтовые рассылки, конкуренты получают выгоду от функций, которые доступны только для мобильных приложений.
Фрилансеры — это люди, которые выполняют разовые работы с разовой оплатой по описанной задаче или техническому заданию. Услуги фрилансеров более выгодные в сравнении с штатными работниками, т.к. заказчик не платит за простои и другие сверхплаты касаемые штатных работников. Использование услуг фрилансеров наиболее удобно так же по причине возможности привлечения специалиста узкой специализации.
Фрилансом часто занимаются люди в свободное от работы времени в качестве дополнительного заработка или для повышения опыта в определенной сфере.
Очень часто используется оценка работы по планируемым трудозатратам (временная оценка помноженная на тарифную ставку 1 часа), но так же часто цена назначается фиксированная.
Качество работы фрилансера
Принято считать, что фрилансеры работают плохо, но это скорее досадное исключение, чем правило. Большинство проблем возникает от неправильного взаимодействия между заказчиком и исполнителем. Разумеется, есть фрилансеры, которые действительно безответственно относятся к работе или берутся за проект не имея достаточной квалификации. Чтобы не допустить ошибки в выборе исполнителя, мы рекомендуем внимательно ознакомиться с завершенными работами, по возможности найти способ и пообщаться с его(ее) прошлыми заказчиками.
Отличие фрилансера от удаленного работника
Не стоит полагать, что фрилансер — это удаленный работник. Удаленные сотрудники это люди выполняющие работу на постоянной основе, а фрилансеры привлекаются на проект разово. Не надейтесть, что фрилансер посвятит работе больше времени, чем вы ему оплачиваете за потраченые часы. Вместе с этим, фрилансеры могут выполнять несколько проектов от разных заказчиков единовременно.
10 фактов про фрилансеров
ФРИЛАНСЕРЫ ВЫПОЛНЯЮТ ТОЛЬКО ЧАСТЬ РАБОТЫ
Студии мобильной разработки имеют разнопрофильных сотрудников, а так же партнерства для решения комплексных задач;
ТРУДНОСТИ КОММУНИКАЦИИ
Часто фрилансеры перестают отвечать на сообщения и звонки. В особенности это неприятно, когда приближается срок здачи;
НИЗКОЕ КАЧЕСТВО РАБОТЫ
К качеству работы фрилансера стоит относиться с опаской. Фрилансеру не придется выполнять поддержку своего кода, а следовательно достаточно решить задачу с минимальными гибкими возможностями. Времени на приведение в порядок кода — тоже не выделяют;
ОТСУТСТВИЕ ПОДДЕРЖКИ
Фриланесеры не заинтересованы в обременительной поддержке. Обычно они свободно относятся к своей работе и не хотят лишних проблем;
НЕВЕРНОЕ ПОНИМАНИЕ ЗАДАЧИ
На маленьких проектах люди не пытаются вникнуть в суть задачи, а обходятся простым решением. Это часто создает проблему не правильного понимания задачи;
ДОПЛАТЫ
Совесть для фрилансера из другого города — дело чуждое. Не редки случаи вымогательства денег. Особенно часто это бывает в середине проекта, когда исполнитель говорит что дальше делать не выйдет, если не сделать что-то дополнительное. Заказчики вынуждены доплачивать, ведь он уже оплатил часть работы и потратил много времени;
ФРИЛАНСЕРЫ БОРЯТСЯ ЗА ЗАКАЗ
Заказы фрилансерам обычно идут по принципу тендера. Очень часто фрилансеры делают заявки во все тендеры подряд «авось повезет». Исполнителю может выпасть такой субъект, который вообще будет не компетентен в вопросе;
ЧУЖОЕ ПОРТФОЛИО
Начинающие фрилансеры заимствуют работы портфолио у студий или у западных фрилансеров, выставляя их как собственные. Это может быть красивой ошибкой а не подтверждением профессионализма;
ЗАВИСИМОСТЬ ОТ ФРИЛАНСЕРА
Отдавая важный кусок работы фрилансеру, свы можете стать зависимым от него. Это опасно, т.к. на следующем этапе может быть поставлена новая задача, которая выходит за рамки компетенции фрилансера;
ФРИЛАНСЕР НЕ ВСЕГДА ФРИЛАНСЕР
Люди занимаются фрилансом часто в свободное время или как хобби. Это не обязывающая работа со свободным графиком, дисциплиной тут вообще даже не пахнет. Мы часто слышим фразу «От нас ушел фрилансер и выбрал работу в компании, что нам теперь делать на половине пути?»
В каких ситуациях пригласить фрилансеров в проект может быть уместным
Дизайн;
Тексты;
Тестирование;
Аудит чужого кода;
Разовые работы которые не нуждаются в поддержке;
При заказе работы у фрилансера, обязательно составьте подробное техническое задание, чем более конкретно и четко будут поставлены задачи, тем больше вероятность получить хороший результат.
Принимайте работу фрилансера внимательно
На этапе заказа опишите выходные данные, перечислите то, что должен сдать разработчик. Например при разработке мобильного приложения под IOS:
Макеты, прототипы интерфейса приложения;
Схему структуры приложения (схема переходов);
Схема базы данных приложения (если используется);
Исходный код;
Архив используемых медиаматериалов (изображения, аудио, видео и др.), а так же исходники медиаматериалов при наличии;
Сертификаты публикации в маркеты (комплект);
Реквизиты доступа к сервисам разработчика, которые используются для работы приложения;
Касательно достаточности и актуальности материалов рекомендуется провести аудит. Хорошей практикой является запрос отчетных материалов по завершению промежуточных этапов.
Где найти фрилансеров
В интернете существует огромное количество бирж фрилансеров. Практически все проекты проходят через эти биржи. Биржи фриланса позволяют просмотреть рейтинг, специализации, заслуги фрилансера (портфолио) и в некоторых случаях дают связь с другими заказчиками.
Мы рекомендуем размещать заказы разработки мобильных приложений на платных биржах, по причине того, что порогом платного участия ограничивается более 70% низкоквалифицированных участников, и создает скопление профессионалов, которые действительно хотят и могут работать. Биржи предлагают выполнять оплату через их сервис, это удобно, т.к. вы получаете дополнительную услугу независимого арбитража, который может сохранить ваши деньги от некачественной работы.
Выбирайте профессионалов
Экономия на разработке и неправильное использование услуг фрилансеров могут дорого обойтись в последствии. Мы часто сталкиваемся с тем, что к нам обращаются заказчики с просьбами доработок проектов выполненных фрилансерами, при том большинство из них настолько технически не верные, что внесение простой доработки может потянуть изменения по всему проекту и занять втрое больше времени чем планируется.
Заказывать крупную услугу лучше у профессиональных разработчиков. Так вы получаете качественную работу, поддерживаемый программный код, исчерпывающую документацию и гарантию. В случае возникающих требований доработки, вы всегда можете обратиться в студию мобильной разработки повторно.
Работа с компаниями так же удобна когда требуется вовлечение разнопрофильных специалистов.
Не экономьте на качестве, в долгосрочной перспективе это окупится!
Преимущества и недостатки кроссплатформенных приложений
Преимущества разработки кроссплатформенного приложения включают в себя:
Более короткое время разработки. Если вы выберите верный технический стэк и распланируете свой проект тщательно, вы получите возможность переиспользовать до 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 – эта технология до сих пор используется для мобильной версии сайта. Однако все это не отвечало требования компании и могло в любой момент провалиться. Именно поэтому вам следует искать опытного разработчика, разрабатывать грамотный план стратегии вашей работы.
