Хочу мобильное приложение! Как понять, когда пора, как прикинуть бюджет и найти достойного подрядчика

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

Обсудили много чего. Так, из сегодняшнего интервью вы узнаете:

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

2. Чем ТЗ отличается от КП и что именно фиксируется в этом документе;

3. Из каких составляющих формируется бюджет мобильной разработки;

4. Когда уместно говорить о скидках, и каких размеров они могут достигать на самом деле;

5. Почему, при казалось бы очевидном благе, демпинг со стороны исполнителя — плохо для заказчика;

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

Что такое InstaDev

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

Много наших проектов связано с трекингом и геолокацией. Для примера — среди наших клиентов есть две крупных компании, занимающиеся доставкой воды. Но ярко выраженной специализации на конкретной отрасли деятельности клиентов у нас нет. Например, в нашем портфолио также можно найти приложение для медитации, входящее в топ-3 по России. И в рамках этого проекта помимо дизайна и разработки, мы полностью отвечали за развитие продукта, продвижение, аналитику, в том числе за выполнение финансовых KPI.

Минимальный, пожалуй, это около 0,5 млн рублей. Но за такие проекты мы обычно беремся, только если с ними к нам приходят наши постоянные клиенты. Средний бюджет у нас 2-4 млн рублей.

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

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

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

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

Сложные в технологическом плане проекты чаще всего подразумевают использование новых технологий. Один из примеров — проект, реализованный на Kotlin MultiPlatform для CRM-системы FinKoper. Для реализации требовались завязки на то, что называется websocket + интеграции с третьими всякими платформами. Словом, пришлось попотеть. Сейчас подобные проекты мы реализуем в спокойном режиме, но в тот момент это был вызов для нас. Нам пришлось перестраивать процессы внутри проектной команды. Отладка, тестирование и все остальное дались тяжелее, чем обычно.

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

Разумеется, первые проекты в новых для нас нишах тоже могут вызывать некоторые сложности. Одним из таких стало приложение для достаточно крупного агрегатора авиабилетов City.Travel. В этом случае нам повезло, что заказчиком выступила технологически развитая компания, и ее представители охотно делились с нами своей экспертизой. В итоге мы работаем с ними уже 8-10 лет.

1. Лид попадает к сотрудникам, отвечающим за обработку входящих заявок. Они связываются с потенциальным клиентом и обеспечивают заполнение брифа. Главная наша задача на этом этапе — понять, что именно клиент хочет.

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

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

4. Начинается основной этап работы.

5. После достижения заранее согласованных результатов, примерно 90% клиентов остаются с нами. Мы продолжаем осуществлять для них техническую поддержку и развитие приложения.

Чаще всего это ежемесячная оплата по часам. Если это фикспрайс проект — то это оплата за итерации.

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

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

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

Когда заказывать мобильное приложение, обязательно ли MVP?

Ситуации бывают разные, но основные признаки такие:

1. Если аналитика по сайту говорит, что мобильного трафика большинство — это первый и главный флаг;

2. Второй флаг — это наличие мобильных приложений у конкурентов по нише;

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

Если очень сократить, то главных вопроса, пожалуй, два:

1. Четко ли мы понимаем, какие именно проблемы будет закрывать приложение и какие именно задачи будут в нем решаться?

2. Есть ли у нас уже видение того, за счет чего именно будет раскачиваться этот новый канал? (Иначе, если у аудитории совсем нет спроса, то результаты запуска разочаруют. Особенно это относится к b2c-приложениям).

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

MVP (Minimum Viable Product или MVP) — это IT-продукт в минимизированном виде. Как правило имеет простейший функционал для удовлетворения какой-то конкретной потребности целевой аудитории. Цель MVP — проверка гипотез и получение обратной связи для последующих доработок в полноценный продукт.

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

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

Документация по мобильной разработке

ТЗ всегда готовятся индивидуально, и по объему и наполнению могут очень сильно отличатся.

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

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

Техническое задание (ТЗ) — это важное дополнение к договору с digital-подрядчиком. Подробный документ, в котором изложены требования к проекту.

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

Да, бывает такое. И это чревато проблемами, потому, что подрядчик может отказаться делать то, что он не закладывал в оценку. А то, что клиент говорил в начале — на самом деле совсем не так.

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

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

Бюджеты, расценки и скидки на мобильную разработку

1. Предпроектная аналитика, уточнение требований, создание ТЗ — это 10-15% общего бюджета;

2. Дизайн до 10%;

3. Менеджмент около 10%;

4. Тестирование — 10-15%;

5. Производство — 50-60%.

Арифметика здесь может быть абсолютно простой. Есть приблизительный уровень ставок. Например сейчас средний уровень в мобильной разработке — примерно 2 000 рублей в час.

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

Возвращаемся к подсчетам. Итак, получается, что заказчику нужно заплатить подрядчику около 300 000 рублей, чтобы один сотрудник работал над проектом целый месяц. Если сотрудников больше — то и ценник вырастает соответствующе. При этом для того, чтобы сделать какой-то проект, как правило, нужны усилия минимум 2-3 человек. Соответственно вот они 2 месяца поработали и уже стоимость подбирается к 2 млн рублей.

Но здесь стоит быть очень аккуратными. Например, мы иногда видим, что коллеги заявляют стоимость часовых ставок своих специалистов в 3 000-3 500 рублей. И это при том, что у агентства практически нет кейсов. То есть непонятно, есть ли реальная соответствующая экспертиза...

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

Но нужно обращать внимание на красные флаги. Например, если заказчик видит в КП, что над его приложением полгода будет работать команда из 8 человек, включая фронтенд-программиста, бекенд-программиста, проджект-менеджера, аналитика, QA-специалиста и т.д. за миллион-полтора рублей — это красный флаг! Это явно какая-то несостыковка. Либо подрядчик изначально завысил количество человеко-часов, либо количество вовлеченных специалистов, либо еще что-то...

Да, можно так сказать. Если подрядчик готов снизить цену в 30-50% от того, что сам же заявил ранее, это сигнал о том, что с высокой степенью вероятности сам подрядчик не понимает себестоимость собственных услуг. Если он не смог наладить собственные бизнес-процессы, то и достойной бизнес-экспертизы в рамках клиентских проектов от него ждать не приходится.

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

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

Но в игру «где-то кто-то предложил дешевле, поэтому опускайте цену» мы играть не будем. Хотя, порой, особенно, если речь о нашем старом, проверенном клиенте, мы готовы продемонстрировать лояльность, сделав небольшие ценовые уступки.

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

Разумеется, что в ставку по стоимости каждого специалиста, зашиты и расходы на различное ПО и сервисы, на налоги, на бухгалтерию, юристов, маркетинг и т.д. Отсюда такая разница. Иногда клиент спрашивает: вот, у вас специалист явно получает не более 200 000-250 000 рублей в месяц, почему вы от нас хотите 400 000? Именно поэтому.

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

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

Как найти мобильного разработчика, который «затащит» проект

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

2. Отзывы. Важно их смотреть не столько на сайтах самих агентств, сколько на независимых площадках.

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

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

5. Умение потенциального подрядчика четко объяснить, как будет строиться взаимодействие, коммуникации и производственный процесс. Если агентству просто важно получить заказ и оно при этом не смотрит на важные аспекты менеджмента — это тревожный сигнал.

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

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

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

Вполне распространена. Да, это делают далеко не все, но это вполне нормальная история. И чем крупнее клиент, тем чаще это встречается. Я рекомендую бизнесу именно так и делать.

Сначала расскажу про то, что мы любим.

• Мы очень ценим взрослость бизнеса клиента, когда есть выстроенные процессы, есть четкое понимание целей, есть делегирование и т.д. Если это есть, все остальное решаемо.

• Второе — это четкое понимание клиентом срока жизни продукта, его предназначения.

Теперь про то, что мы не любим:

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

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

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

Тут для нас довольно очевидны следующие тенденции:

1. Кроссплатформенная разработка, позволяющая сэкономить бизнесу ресурсы, будет развиваться и дальше.

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

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

4. Локальный взрыв с точки зрения вот всяких VR технологий (первый же пример — новый шлем виртуальной реальности от Apple). И мы скоро опубликуем статью про наш первый опыт работы с платформой Apple Vision Pro, следите за новостями в ТГ-канале InstaDev mobile. Понятное дело, что вначале широкой аудитории у технологий, требующих для пользователей специальных устройств не будет, но многие команды будут смотреть в эту сторону гораздо активнее. Мы держим руку на пульсе новых технологий.

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

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

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

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

Я думаю, что мобильник как основное устройство перестанет существовать в ближайшие 5-10 лет. Очевидно, что есть способы решения задач, которые сейчас решают мобильные телефоны. Да, пока альтернативные устройства слишком тяжелые и дорогие. Но в ближайшие годы они могут измениться до неузнаваемости.

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

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