Как понять, что вы выросли из коробочного решения
Привет, это Максим Павлов — управляющий партнёр KTS. Мы создаём IT-продукты для бизнеса.
На старте бизнеса запускать процессы проще всего с помощью готовых (коробочных) решений. С развитием бизнеса ограничения таких решений начинают мешать. Рассказываю, по каким маркерам можно понять, что пора менять «коробку» на кастомный продукт.
Как понять, что пора разрабатывать собственный сервис
Далеко не всегда компаниям необходимо вкладывать миллионы рублей в разработку кастомного продукта. Расписываю дальше ситуации, когда на это есть основания.
Кейс №1. Разработчика коробочного сервиса выкупила другая компания
При покупке компании-разработчика сервиса другой компанией доступ к вашим данным могут получить новые владельцы. Особенно это актуально для нишевых решений: шанс, что ими заинтересуются компании побольше намного выше.
Например, одно популярное приложение для жильцов ЖК прежде принадлежало банку. Год назад долю в нём выкупила инвестиционная компания, где непонятны конечные бенефициары. Они могут быть и конкурентами, которые теперь могут получить доступ ко всей чувствительной информации.
Кейс №2. Разработчики не хотят внедрять ваши фичи в продукт или ставят их в план через полгода
Разработчики коробочных систем делают максимально универсальный продукт, который должен подходить для наибольшего количества клиентов. Если вы хотите дать вашим пользователям сервис, который будет максимально адаптирован именно под их запросы, то может возникнуть конфликт интересов.
Конечно, с идеей новой фичи можно прийти к разработчикам коробочного решения, попросить её реализовать. Однако если новая функция слишком сильно не вписывается в их концепцию развития, то её могут даже не поставить в план.
Если разработчики согласились внедрить новую функцию в продукт, релизный цикл не позволит сделать это оперативно. Вам придётся ждать несколько месяцев, а то и год, прежде чем до вашей фичи дойдёт очередь, и её всё-таки реализуют. В ситуациях, которые требуют быстрого реагирования, вы теряете возможность оперативной адаптации к новым условиям.
Кейс №3. Разработка собственного продукта может принести ощутимую пользу для бизнеса
Создание собственного приложения без понимания бизнес-эффекта разработки, скорее всего, не приведёт к ощутимым результатам. Бизнесу важно точно понимать, какой профит принесёт кастомная разработка: как она поможет отстроиться от конкурентов и привлечь новых клиентов.
При принятии решения важно помнить, что цель любой разработки — либо заработать больше денег, либо сэкономить. Здесь есть два подхода:
- Автоматизация текущих процессов — когда компания экономит на том, что работу, которую некогда делал человек, теперь удалось выполнять с помощью алгоритмов;
- Цифровизация — когда с помощью технологий компания получает возможность выстраивать принципиально новые процессы.
Именно цифровизация, а не автоматизация процессов помогает бизнесу выстраивать партнёрские отношения с клиентами на долгие годы.
Пример: большинство застройщиков разрабатывают по приложению на каждый этап пути клиента. Получается так, что жильцам приходится скачивать отдельные приложения для покупки квартиры, для умного дома, для оплаты заявок. Если для молодых это не проблема, то для людей более старшего возраста установка нескольких сервисов — уже не такая лёгкая задача.
Наш клиент Мангазея девелопмент поставил перед собой задачу убрать лишние препятствия на пути клиента. Следовательно, совместным решением с М Тех (IT-дочка компании Мангазея) стал уход от работы со множеством коробочных решений, создание единой экосистемы, которая бы превосходила возможности комбинаций коробочных систем.
Кейс №4. Вы хотите наладить дополнительный канал продаж
Приложение для клиентов — инструмент, с помощью которого можно допродавать свои услуги с высокой конверсией. Этого можно добиться через персональные предложения под каждого клиента. Однако если текущее приложение не позволяет этого сделать, а вы хотите допродавать услуги, то стоит задуматься о разработке кастомного решения.
Кейс №5. Вы хотите снизить вероятность утечки данных
Взломщики стремятся к тому, чтобы с помощью одной уязвимости получить много возможностей для кражи данных. Поэтому в фокусе их внимания — массовые сервисы. Получается так, что вероятность атаки на ваш продукт ниже, чем на сервис, которым пользуется много компаний.
Например, недавно появились новости об очередных сливах данных пользователей. Под удар попали банки и retail-сети. Доступ к данным был получен, так как компании использовали популярную коробочную CMS — Bitrix.
Как понять, какие фичи вносить в первый релиз
Наш клиент «Мангазея» понял, что пора делать собственную замену приложения для жильцов вместо коробочного Домиленда, объединив лучшие фичи из Домиленда, Ujin и Alphaopen.
Обычно в приложениях управляющих компаний жильцы оплачивают счета за коммуналку, заказывают заявки на пропуск и вызывают ремонтников.
Рассказываю, как мы с клиентом определяли, что должно войти в первый релиз приложения для жильцов.
Пункт №1. Фичи, без которых приложение не имеет смысла
В случае с приложениями для жильцов это функции, за которыми они приходят в приложение стабильно раз в месяц. А именно: оплата ЖКХ.
Если мы встраиваемся в этот стабильный паттерн поведения, то появляется возможность охватить наибольший процент аудитории.
Мангазее хотелось уйти от сложных платёжек к наглядной визуализации как в банковских приложениях, к которым все уже привыкли. Что мы и сделали.
Также мы реализовали выгрузку pdf-квитанции. В Домиленде такой функции не было. Оказалось, что есть категория пользователей, которым важно их видеть — даже в 2023 году.
Пункт №2. Фичи, которые помогают клиенту в ситуациях, когда что-то идёт не так
Если бренд находится с клиентом в момент трудностей, то клиент понимает, что о нём заботятся. Это, в свою очередь, влияет на лояльность.
В приложении для Мангазеи мы сделали категорию «заявки», где жильцы могут оставлять заявки для вызова ремонтников — например, для починки трубы. Также мы организовали жильцам связь с управляющей компанией через чат с диспетчером, который открывается для каждой заявки. В нём жильцы могут уточнять детали по заявке без конкретных шаблонов и траты времени на них.
Пункт №3. Фичи, которые делают новое приложение лучше, чем старое
В первом релизе вы не повторите весь функционал коробочного решения, которое развивается годами. Чтобы завлечь пользователей на новое приложение, совсем не обязательно воспроизводить все фичи коробки. Но вы можете добавить тот функционал, который клиенты давно просили реализовать.
В Домиленде не было функции заказа пропуска через приложение. Например, каждый раз, когда к жильцам приезжал доставщик, им приходилось выходить на улицу и забирать заказ там. Поэтому просьба внедрить оформление пропусков через приложение была самой частой. Жильцы хотели заказывать пропуска в два клика — что мы и сделали.
Пункт №4. Киллер фича
Это то, что выделит вас среди конкурентов и даст уникальные бизнес-возможности.
Мангазея стремится создать одно приложение, в котором будет сосредоточено всё взаимодействие жильца с компанией. Тем самым компания предоставляет своим жильцам уникальный опыт.
Киллер фича в этом случае — взаимодействие жильца с системами умного дома из того же приложения. Обычно пользователям нужно установить отдельное приложение для домофона, счётчиков, ещё чего-то. Здесь же реализовывается концепция «всё в одном».
Какие подводные камни могут быть при переходе с «коробки» на «кастом»
При разработке приложения вы можете столкнуться со следующими проблемами:
- Интеграция с другими системами
При разработке у нас были сложности на уровне данных. А именно, с их консистентностью и синхронизацией между учётной системой 1С-ЖКХ и сервером приложения. Нужно было продумать интеграцию как с внутренним контуром, так и с бухгалтерией, диспетчерами, охраной.
Обычно проблемы возникают во время получения доступов к нужным системам, и не у всех сервисов есть готовые коннекторы.
- Недостаточное покрытие документацией и инструментария для разработчиков от производителей умных устройств
При выборе домофона в Мангазее ориентировались на пользовательские характеристики. Получилось так, что тестовое приложение работает не идеально, поэтому нам пришлось коммуницировать с производителями домофонов.
Конечно, можно было бы взять коробочную систему домофона от производителя. Однако это не соответствовало стратегии развития продукта: тогда бы пришлось встраиваться в их релизный цикл, ждать разработки фич по полгода. Там же удалось выкатить MVP за три месяца, сейчас раз в месяц мы запускаем новые релизы.
Используя SDK от производителя, нужно следить за запрашиваемыми правами. В первом релизе запрашивался NFC, что ограничивало количество устройств, на которые можно было скачать приложение. В итоге мы столкнулись с тем, что приложение для пользователей Xiaomi было доступно только для тех устройств, в которых был NFC. После изменения настроек мы сняли эти ограничения.
Мы хотим выстраивать с клиентами долгосрочные отношения и предоставлять им уникальный опыт. Это означает, что у нас не должно быть ограничений от вендора по развитию приложения. Именно поэтому мы решили создать свое приложение, а не использовать комбинацию готовых продуктов.В итоге мы получили позитивный отклик, много предложений и замечаний, поэтому продолжаем развивать приложение вместе с KTS. Фидбек от жильцов был настолько положительный, что мы в M Tex решили выходить на внешний рынок и предлагать наше решение другим компаниям.