4 ошибки, которые поставят крест на развитии приложения

«Мне снится один и тот же страшный сон. Я влез в кредиты, чтобы создать приложение, а его скачала только мама. Разработчики уверяют, что теневой бан в App Store существует, а инвесторы внесли меня в черный список», — из вымышленного дневника стартапера. Как не оказаться в этом кошмаре, рассказываем в статье.

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

Иногда к нам в Purrweb приходят клиенты с идеями продуктов, которые мы называем «всё на черное». Владелец стартапа настолько уверен в своей гипотезе, что потребности и боли ЦА проверять не хочет. Такой проект может выстрелить, но чаще его сложно развивать и сделать коммерчески успешным. Он просто не нужен или не удобен пользователям.

Чтобы такого не случилось, рекомендую провести исследование аудитории до запуска проекта. Оно даст четкий срез потребностей будущих пользователей продукта, а иногда и неочевидные инсайты. Анализ бизнес-идеи и ЦА для стартапа стоит в агентствах около 300 000 ₽. При среднем чеке кастомной разработки в 7 млн ₽ посчитать потери в случае, если продукт не попадет в нужную аудиторию, несложно.

Вот какие исследования будет полезно провести любому стартапу:

1. Количественное исследование: опрос. Задача этапа — получить статистические данные. Например, нужно сделать сервис для аренды жилья. В опросе мы узнаем, сколько времени в среднем уходит у собственника, чтобы сдать квартиру. Или как долго арендатору приходится искать жилье. Стоит оставить и поля для открытого ответа. В них респондент сможет написать свои мысли, а вы получите полезные инсайты.

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

— Коэффициент уверенности (КУ) отражает, насколько мы будем уверены в результатах исследования. Я рекомендую выбирать стандартный КУ 95%, чтобы снизить вероятность провальных результатов до минимума — 5%. Такое соотношение оптимально, когда нужен баланс между бюджетом, сроками исследований и их точностью.

— Погрешность исследования отражает, насколько полученные результаты отклоняются от истины. Например, мы опросили 100 арендаторов, 20% из которых ищут жилье больше полугода. Если мы задали погрешность в 10%, то допускаем, что число таких арендаторов на реальном рынке может быть в диапазоне от 10 до 30%. Чем ниже показатель погрешности, тем более узким будет этот интервал и точнее результат.

— Общее число целевой аудитории отражает, сколько человек из нашей ЦА есть в России или другой стране. Здесь необязательно указывать точное количество. Например, мы опрашиваем тех же арендаторов. Понятно, что ЦА измеряется не десятками, не сотнями, а скорее миллионами человек, если речь идет о российском рынке. В этом случае можно задать 10 млн человек для расчета выборки. Если же вы делаете продукт для более узкой аудитории, ориентируйтесь на открытые статистические данные в Wordstat или Google Trends.

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

Мы опрашиваем около 20 человек, если сфера продукта понятна и хорошо изучена. Если же идея клиента лежит в менее очевидной плоскости — например, он хочет сделать приложение для сельскохозяйственных закупок, — выборку лучше увеличить до 40 респондентов.

О том, как провести кастдевы самому, рассказали в этой статье.

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

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

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

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

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

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

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

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

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

Мы в Purrweb подходим к архитектуре комплексно, это помогает заложить резервы для будущего развития продукта 👇🏻

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

2. Используем подход Domain-Driven-Design Эрика Эванса. Его еще называют предметно-ориентированным проектированием. DDD мы используем в случае монолитной архитектуры, так как с ним проще добавить в продукт новые фичи и, если нужно, поделить его на микросервисы.

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

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

3. Выбираем подход к разработке: no-code или кастом. Первый вариант сразу накладывает ограничения на развитие: для приложения используют стандартизированное ПО. Time to market продукта будет намного короче, но потом его не получится масштабировать. С кастомной разработкой можно сделать приложение любой сложности и добавлять фичи до бесконечности.

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

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

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

Помимо BPMN-диаграмм, мы в Purrweb ведем и другие документы. Например, UML-диаграммы и критерии приемки продукта. Но клиенту разбираться в них вовсе не обязательно. Главное, что должно быть понятно из документации, — как приложение закрывает потребности целевой аудитории. Если из документации это не очевидно, стоит синхронизироваться с подрядчиком еще раз.

Итак, чтобы не попасть в страшный сон стартапера, нужно:

Готово, вы восхитительны! Шансы на успешный релиз и дальнейшее масштабирование повышаются. Если вам хочется больше узнать о секретах успеха развития ИТ-продуктов, приходите в наш телеграм-канал. Там мы много рассказываем о MVP и стартапах. До встречи в следующих статьях, stay tuned!

Как думаете, какие еще ошибки мешают приложению масштабироваться?