Разработка мобильных приложений: как сделать это дешевле

Разработка мобильного приложения была и остаётся дорогой. Никому не хочется вкладывать время и деньги в то, что не вернёт даже малую их часть. Зато наверняка хочется проверить, насколько вашим клиентам нужно мобильное приложение. Этой статьёй мы в Лайв Тайпинг надеемся помочь вам сделать мобильное приложение без ненужных трат на первых порах.

Но сначала задайте себе важный вопрос.

Что дают мобильные приложения бизнесу?

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

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

Недостаток времени и денег — ещё два предупредительных выстрела. И того, и другого будет уходить много. Вы должны будете рассказать команде студии разработки, каких целей хотите достичь с приложением и какими именно путями, выслушать аргументы «за» и «против», идти на компромиссы, оценивать, согласовывать, соглашаться и отказывать. Коммуникация будет вестись как устно, так и письменно. Есть ли у вас личное время или доверенный человек, который будет готов выделить своё? Есть ли у вас семизначная сумма денег?

Какое бы решение вы не приняли, читайте статью дальше.

MVP

Вспомним, что это такое.

Аббревиатура MVP расшифровывается как Minimum Viable Product («минимально жизнеспособный продукт»). В таком приложении недопустимы функциональные или изобразительные излишества — всё, что в нём будет, должно работать строго на бизнес-цель продукта.

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

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

Проектирование, аналитика и техническое задание

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

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

Суть процесса в том, чтобы собрать ваши требования к проекту и перевести их на язык разработки. Вот что предстоит выяснить:

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

Что при этом происходит:

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

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

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

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

Для какой платформы делать приложение: iOS или Android?

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

Есть несколько причин для того, чтобы начать с создания приложения для владельцев айфонов:

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

Но окончательный выбор платформы всё же зависит от цели приложения и его аудитории. Хотите зарабатывать и делаете ставку на платёжеспособных пользователей? Выбирайте iOS. Создаёте продукт, нацеленный на массы или регионы, жители которых не привыкли или не могут платить за цифровые продукты? Делаете сервисное приложение для курьеров и торговых представителей и не можете позволить себе дорогой парк устройств? Выбирайте Android. Хотите захватить мир? Выбирайте обе платформы.

Как сэкономить на дизайне

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

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

Рассмотрим подробнее второе условие. Выполнять его дизайнерам и разработчикам помогают гайдлайны операционных систем. Это такие руководства по оформлению интерфейса приложений на iOS или Android. Когда разработчику нужно реализовать стандартные элементы интерфейса (те, что зафиксированы в гайдлайнах), он обращается к UI-китам — наборам готовых решений пользовательского интерфейса под разные платформы. Подробнее о UI-китах, их назначении и о том, как они помогают сэкономить на дизайне, рассказали в Tilda.

Допустим, стоит задача разработать для обеих платформ внешне одинаковое приложение. Поэтому нужно сделать какой-то элемент не таким, каким он обычно выглядит в своей ОС. Например, мы пытаемся повторить тулбар iOS в Android-версии. Это значит создание элемента с нуля, что дольше и дороже. В совокупности такие изменения сильно повлияют на стоимость проекта.

С анимациями похожая история: чем они сложнее и круче, тем больше времени и бюджета требуют.

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

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

Кроссплатформенные приложения: что это и как экономит деньги

Подход к разработке приложения может быть нативным и кроссплатформенным.

Нативные приложения создаются на конкретном языке программирования для конкретной платформы: языки Java и Kotlin — для Android, а Swift не ниже третьей версии — для iOS.

Достоинства:

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

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

Кроссплатформенные разработка мобильных приложений осуществляется с помощью веб-технологий (HTML, CSS и JavaScript) инструментами Cordova, Xamarin, React Native и Flutter и работают сразу на iOS и Android. Чтобы написанный код заработал на мобильных устройствах, его нужно либо «перевести» на понятный им язык, либо сделать прослойку, которая работает на устройстве и переводит обращения к функциям устройства с непонятного для них языка на понятный.

Достоинство: низкая стоимость разработки и поддержки из-за привлечения одного веб-разработчика.

Недостатки:

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

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

Как сэкономить на бэкенде?

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

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

Во-вторых, использовать бессерверную архитектуру приложений, или, иначе говоря, Serverless. Это решение не требует ни особых знаний для развёртывания и поддержки, ни ощутимого бюджета — всю поддержку берёт на себя тот облачный сервис, на котором вы построите архитектуру. Много возможностей для этого имеют, в частности, AWS, Azure и Firebase.

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

И это касается массы других возможностей приложения. Нужны чаты или push-уведомления? Их дешевле брать готовыми, в виде SaaS (Software-as-a-Service, или программное обеспечение как услуга). В среднесрочной перспективе это дешевле и надёжнее, чем писать свою платформу. Вы тем самым избегаете всех грабель, которые собрали разработчики платформы до того, как она заработала.

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

Подробнее о способах сэкономить на бэкенде вам расскажет старший аналитик Лайв Тайпинг.

Фрилансер или агентство?

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

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

Минусы:

  • срывы дедлайнов и растягивание задач — частая ситуация в работе с фрилансерами. Если он работает над несколькими проектами, в первую очередь он будет решать задачи на горящих. Фрилансер может и вовсе перестать выходить на связь и пропасть. Тем не менее, многое зависит от того, как вы выстроите работу со специалистом;
  • отношения с фрилансером основаны на взаимном доверии, но всегда есть риск наткнуться на недобросовестного исполнителя. Кроме того, без тестирования и code review со стороны профессионалов не факт, что проект будет реализован без багов и другие специалисты смогут его поддерживать, если вы решите сменить исполнителя;
  • у фрилансера нет заинтересованности в работе над вашим проектом, кроме материальной. Но включённость в проект важна, и от того, каких специалистов вы подберёте и как построите взаимодействие, будет зависеть успешность проекта.

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

Региональные студии против столичных

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

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

  • «Тэглайн». Самый авторитетный рейтинг разработчиков мобильных приложений на российском рынке. Учитывает годовую выручку студии, количество сотрудников, качество сайта студии и её узнаваемость среди коллег по цеху.
  • «Рейтинг Рунета». Главные критерии попадания в него — количество выпущенных приложений и их средняя оценка в сторах, поэтому вам не придётся выбирать среди псевдостудий, сделавших два давно мёртвых проекта.
  • Clutch. Рейтинг с редакцией в США. Позиции студий зависят от реальных отзывов и оценок от уже работавших с ними клиентов.
  • Ruward. Агрегатор других рейтингов. Учитывает позиции студий в «Тэглайне», «Рейтинге Рунета», Clutch Russia и ряде второстепенных рейтингов.

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

Что ещё стоит иметь в виду при выборе студии мобильной разработки:

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

Экономия с помощью конструкторов приложений

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

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

Зачем нужно приложение на конструкторе? Чтобы осмотреться в мобильной среде, увидеть востребованность бизнес-идеи в ней, а если она есть, то это будет зелёным светом к разработке приложения с нуля.

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

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

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

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

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

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

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

Экономия с помощью маркетплейсов

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

Пионерами и лидерами в этой нише остаются Amazon, eBay, Alibaba и Ozon, где большинство из нас что-то покупало хотя бы раз в жизни, а в России, по данным сайта Shopolog, существует несколько десятков маркетплейсов.

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

Мобильное приложение или PWA?

А нужно ли вообще делать приложение? Если у вас есть адаптивный сайт и веб-разработчик, то несколько манипуляций — и вы получаете PWA, или Progressive Web App. Это не просто сайт: он всё ещё открывается в мобильном браузере, но уже может работать офлайн, посылать push-уведомления, иметь доступ к некоторым аппаратным частям устройства и открываться с рабочего стола через клик на иконку. При этом места на устройстве он занимает меньше.

Понятие PWA появилось в 2015 году на фоне популяризации принципа mobile first. Принцип гласит, что, поскольку мобильный интернет-трафик сравнялся с десктопным (а впоследствии и обогнал его), то дизайнеры и разработчики теперь должны делать сайты в первую очередь для пользователей смартфонов, то есть быстрыми, удобными и полезными. По релевантным запросам такие сайты идут в мобильной поисковой выдаче выше конкурентов.

За эти годы появилось уже достаточно кейсов, подтверждающих, что PWA играют на руку бизнесу: пользователям нравится тот опыт, который они получили от приложения, и они продолжают им пользоваться, нести трафик и покупать товары. От скорости загрузки PWA-версий сайта выиграли Lancome, Tinder, Uber, Pinterest и другие известные продукты.

Установить на своё устройство PWA пользователь мог только тогда, когда он работал с мобильным сайтом, и их нельзя было найти в магазинах приложений. Но в феврале 2019 с выходом браузера Chrome 72 и появления функции Trusted Web Activity в его Android-версии возможность скачать PWA из стора получили как минимум пользователи ОС Android.

Экономия на поддержке

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

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

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

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

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

Модели оплаты

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

  • Fixed price. Модель предполагает, что за утверждённый бюджет в утверждённые сроки студия создаст то, что оговорено в техническом задании.
  • Time & Materials. Модель предполагает, что клиент платит постфактум за те человеко-часы, которые команда потратила на решение отдельных задач.

Обычно кажется, что FP выгоднее: ведь исполнитель назвал цену на берегу, а по T&M стоимость может оказаться непрогнозируемо больше. Так и есть, когда стоит цель сделать проект к конкретной дате или когда проект небольшой и не предполагает доработок. Но в случае с проектами посложнее исполнитель закладывает в оценку по FP максимум рисков, которые заказчик вынужден оплатить, даже если они не проявились. Так что с работой по T&M стоимость может стать непрогнозируемо меньше. Но всё же существуют оптимальные условия для такой модели. О них ниже.

  • Предстоит работать над стартапом среднего или большого размера.

Рынок, на котором стартап хочет занять место, может быстро поменяться, а вместе с ним поменяются и требования к продукту. Но при работе по FP клиент уже описал в техническом задании функциональность, которую исполнитель сделает при любых обстоятельствах — даже если функциональность больше не нужна. Мало того, что он её описал, так он за неё ещё и заплатил. И если результат оказался не пригоден для рынка, придётся платить за доработку или замораживать проект. Модель Time & Materials даёт возможность быстро пересматривать и кардинально менять приоритеты.

  • У клиента есть время на регулярную коммуникацию с командой.

Fixed Price освобождает клиента от необходимости бдить за течением проекта: студия получает деньги и называет сроки, а клиент в это время занимается своими делами и ждёт результата. При работе по Time & Materials клиент — это соучастник, напрямую влияющий на проект. Кстати, это самое соучастие и экономит бюджет, потому что требования к продукту не составляются в функциональное задание, а уточняются напрямую, и можно быстро обсудить возможные решения, их плюсы и минусы, а потом выбрать самый короткий путь реализации. На Fixed Price же студия должна заложить время на отработку рисков в оценку и нести за них ответственность сама. Под рисками мы имеем в виду неверно истолкованные части ФЗ, что вызывает неожиданный, мягко говоря, результат, недовольство клиента и переделки.

  • Нет чётких дедлайнов.

Амбициозный проект трудно создавать в рамках строгих сроков и функциональности. Строгость — черта модели Fixed Price. Но если риски вылезают наружу, то менеджер приходит к клиенту и говорит, что задача оказалась сложнее, чем предполагалось, и придётся упрощать разработку, чтобы уложиться в сроки. Модель Time & Materials позволяет избежать связанной с этим неловкости: оплата по факту выполнения задачи даёт возможность обсуждать её столько, сколько нужно, и работать без нервов.

Книга

Базой для этой статьи послужила выпущенная в Лайв Тайпинг книга «Что вам нужно знать о разработке мобильных приложений для бизнеса». Мы постарались собрать в неё многолетний опыт студии в создании сайтов и мобильных приложений с нуля. Из книги читатель узнает:

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

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

Заключение

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

0
23 комментария
Написать комментарий...
Константин Нелюбин

Всё очень хорошо написано. Но насчет нативности не соглашусь. 
У меня приложение, которое скачано 900 000 раз. Сделано на кроссплатформе.
За всё время ни один пользователь не пожаловался, что приложение не нативно или управление непривычно. Это выдумки. Если UI продуман, то нативность не принципиальна. У кроссплатформы нет минусов, кроме узкости спецов и рисков связанных с дальнейшей поддержкой. Ну, отсутствие библиотек и  SDK  под них. 

Ответить
Развернуть ветку
Александр Маломанов

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

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

Ответить
Развернуть ветку
шевроле камары

Под React Native написано столько библиотек, которое Android и не видывал (в том числе и под UI, хоть полностью повторяй иосный без переплат по времени). Другой вопрос в их качестве)) но с багами в основном только непопулярные

Ответить
Развернуть ветку
Валентин Усманов

Откуда 10% от общей стоимости за аналитику? не много? ИМХО, вся аналитика в рунете - профанация! А что вы там исследовать и анализировать будете?
А то я бы не хотел с занесенных 2-х лямов 200к отдать, за то что кто-нибудь конкурентов нагуглит. Или через автосервис прогонит

Ответить
Развернуть ветку
Александр Маломанов

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

 А вы какую сумму справедливыми тратами считаете, чтобы проект соломой обложить вокруг?

Ответить
Развернуть ветку
Ilya Karbyshev

Так без аналитики цена еще больше вырастет. "Скупой платит дважды" везде работает, и в диджитале тоже

Ответить
Развернуть ветку
Валентин Усманов

Глупость - закладывать аналитику как "процент от чего-то там"! Цена должна быть фикс, либо отдельно считатсья! Потому что цена аналитики не зависит от сложности самой разработки. Вот представьте вам делать приложуху для Ламоды, с которой можно содрать лям, но с простым функционалом! Корзина там и все. Чего там аналитировать? Но они же платят лям, класно 100 000 просто так взять с ляма. Как коррелирует цена аналитики с ценой самого приложения?

Ответить
Развернуть ветку
Александр Маломанов

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

Мысль лишь в том, понимание - что, как и в каком контексте делать - весьма важная задача, может составлять 1/10 часть проекта. А проектирование и прототипирование с дизайном (без этапа разработки) - до 1/3 проекта.
Это сродни фразам - "теперь новая машина в минимальной комплектации стоит от 1 миллиона рублей", "Android-флагман или Iphone - это один кило-доллар, а это 60-70 тысяч". В первом приближении звучит страшновато, но потом привыкаешь...

Ответить
Развернуть ветку
Валентин Усманов

Хорошо, что включает в себя аналитика? И как влияет на конечную цену и вообще на вид приложения? 

Ответить
Развернуть ветку
Александр Маломанов

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

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

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

Ответить
Развернуть ветку
Валентин Усманов

"Погружение" - все говорят а на деле то это что? гугл в помощь? И если сам хозяин логикой особо не владеет своих процессов? Или они неверно построены у него? То ж само в соседней ветке обсуждаем  - например,модель оплаты по подписке щас делать смысл, когда рынок этот сужается. А хозяин бизнеса говорит вам - делайте подписку! Когда все его топ конкуренты от нее отказались

Ответить
Развернуть ветку
Александр Маломанов

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

Про "делайте подписку!" - если ее ни у кого нет из конкурентов - повод задуматься и еще поискать. 

Но смена модели монетизации в бюджете всего проекта - не такие большие затраты - A/B-тестирование как раз для того и придумали, чтобы понять и быстро запустить то, что лучше продается

Ответить
Развернуть ветку
Ilya Karbyshev

Вы книгу самиздатом выпустили или прям регистрировали где-то? Вот что например надо сделать чтоб она в литресе появилась?

Ответить
Развернуть ветку
Евгений Бойченко

А про Литрес хорошая идея на самом деле

Ответить
Развернуть ветку
Ilya Karbyshev

В "МИФ" тогда уж сразу)

Ответить
Развернуть ветку
Дмитрий Федоров

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

Ответить
Развернуть ветку
Тамара Волнина

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

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

Подробнее о том, как мы ищем фрилансеров и работаем с ними, можно прочитать здесь:
https://livetyping.com/ru/blog/kak-nayti-frilancera-dlya-svoego-proekta
https://livetyping.com/ru/blog/kak-it-studii-vybrat-i-vospitat-horoshego-frilancera

Ответить
Развернуть ветку
Дмитрий Федоров

первый раз такое слышу. а если фрилансер как обычно бывает пропадет на середине проекта - кто, отвечает? менеджер? 

Ответить
Развернуть ветку
Тамара Волнина

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

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

Ответить
Развернуть ветку
Дмитрий Федоров

а если ваш клиент против использования фриласнеров на своем проекте? 

Ответить
Развернуть ветку
Тамара Волнина

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

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

Ответить
Развернуть ветку
Таня Семенова

Заинтересовала статья. Как раз думаем про создание приложения. Подскажите, если у нас небольшой интернет магазин, более 55% посетителей с мобильных устройств, актуально делать мобильное приложение? Как сделать минимально дешево, чтоб ыпроверить нужно нам оно или нет? Но так чтобы потом, если понадобиться, можно было доделать какие то нужные фишки? Если можно с живыми  примерами, спасибо

Ответить
Развернуть ветку
Александр Маломанов

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

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

Про живые примеры, к сожалению, не понял вопрос. Если про наш опыт в eCommerce - подробнее тут https://livetyping.com/ru/portfolio/ecommerce/all

Ответить
Развернуть ветку
20 комментариев
Раскрывать всегда