Лого vc.ru

Распространённые вопросы о разработке первого продукта

Распространённые вопросы о разработке первого продукта

Сооснователь и генеральный директор студии Aspirity Георгий Савченко о том, с чего новичкам следует начинать работу над проектом.

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

Клиенты задают разные вопросы: «Сможете ли разработать мне приложение или веб-сайт?», «Сколько будет стоить разработка?», «Посоветуйте, в какую компанию идти и кого нанимать?», «Как потратить минимум денег на MVP?» и другие. Мы отвечали на эти вопросы раз за разом, снова и снова.

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

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

У меня появилась идея приложения или веб-сайта, и я хочу ее реализовать. С чего начать?

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

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

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

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

  • Убедитесь, что ваш продукт будет востребован. Для определения востребованности продукта существуют такие методики и инструменты, как lean startup, customer development, business model canvas и прочие. Для начала нужно сформировать хотя бы примерное понимание, кто будет пользоваться вашим продуктом и платить за него, какую проблему, головную боль людей он решает.
  • Рассчитайте бизнес-модель, хотя бы примерно. Если прикидки сходятся и дают нужные цифры — замечательно.
  • Разрабатывайте продукт в том или ином виде самостоятельно или идите к разработчикам.
  • Запускайте продукт, показывайте его пользователям и налаживайте обратную связь.
  • Меняйте продукт на основе той информации, которую вы получили от пользователей, и переходите к первому пункту плана — так до бесконечности. Не надейтесь, что можно один раз «отлить в граните» сайт или приложение и остановиться. Программное обеспечение меняется быстро, поэтому постоянные изменения неизбежны как реакция на тренды и действия конкурентов.

Иллюстрация принципа постоянных изменений в графическом виде:

Сработает ли идея? Пойдет ли бизнес? Будут ли пользоваться продуктом?

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

Основные положения юнит-экономики таковы. Юнит (единица) в случае интернет-проекта — это один клиент вашего продукта. Чтобы бизнес был прибыльным, стоимость привлечения одного клиента (CPA — cost per acquisition) должна быть меньше вашего общего заработка с этого же клиента за все время его жизни (LTV — lifetime value) — CPA < LTV.

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

Далее метрики могут быть детализированы как LTV = ARPU * LT–COGS, где ARPU — средний доход с одного клиента-юнита (Average Revenue Per User), LT — время жизни клиента (LifeTime), COGS — себестоимость или затраты на пользователя (Cost Of Goods Sold)

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

Существуют интересные прикидки по параметрам модели на основе юнит-экономики. Например, некоторые эксперты считают, что на старте проекта должно выполняться соотношение CPA * 3 < LTV (то есть заработок с одного клиента должен в три раза превышать затраты на его привлечение), поскольку тройной запас по стоимости позволит учесть риски старта проекта, дешевизну начальных каналов привлечения (например, друзья и знакомые основателей, которые более лояльны), а также насыщение каналов со временем. В итоге прибыль при количестве клиентов N будет равна N * (LTV – 3 * CPA).

Далее нужно оценить объем рынка. Да, у вас может получиться положительная прибыль на одного клиента, но важно помнить про объем рынка. При небольшом количестве клиентов бизнес может быть прибыльным, но зарабатывать $100 в месяц — наверное, это не то, чего бы вам хотелось.

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

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

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

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

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

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

Как разработать продукт (сайт, приложение)? Я ничего в этом не понимаю

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

Программный продукт можно разработать несколькими способами:

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

Эти способы, конечно же, можно комбинировать.

Давайте пойдем от того, что вам необходимо на самом деле. Скорее всего, вы хотите следующего:

  • Быстрый старт. Вы же уже проверили гипотезы в рамках продукта без программирования, и вам хочется как можно быстрее масштабировать систему. Либо ваш минимальный, созданный «на коленке» продукт уже не справляется с возрастающими потребностями пользователей, и вы понимаете, что теряете деньги. Либо вас торопит инвестор. В любом случае, нужно быстрее.
  • Быстрые изменения потом. Вы постоянно анализируете (или будете анализировать) обратную связь от пользователей в рамках маркетинговых активностей и аналитики. Вы будете желать, чтобы эти изменения моментально воплощались в жизнь.
  • Эффективная стоимость разработки. Нет нужды говорить, что предыдущие два пункта всегда должны рассматриваться в контексте финансовых показателей и бизнес-моделей. Решать, нужно ли потратить больше и сколько, чтобы реализовать изменения, которые принесут вам какую-то планируемую (далеко не подтвержденную) сумму денег, или это будет невыгодно.
  • Отсутствие вовлеченности в разработку. Вас должна как можно меньше беспокоить техническая сторона проекта. Вы хотите заниматься бизнесом и меньше всего думать о том, что могут возникнуть технические проблемы. Иными словами, ваша вовлеченность в разработку должна быть низкой.

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

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

Плюс означает предпочтительную ситуацию, минус — не самую лучшую. Плюс-минус значит, что эффект зависит от ситуации

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

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

Сколько будет стоить разработка? За сколько разработаете продукт?

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

Трудозатраты приведены примерно — для понимания порядка показателей

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

Всего в году 247 рабочих дней, отнимем 30 из них на отдых и больничные. Итого, при 7-часовом рабочем дне, это 7 * (247 – 30) = 1519 рабочих часов. Час работы такого программиста обойдется в 70 000 * 12 / 1519 = 553 рубля (если предположить, что вы платите деньги из своего кармана «в конверте» каждый месяц по 70 тысяч рублей).

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

Теперь вы можете подсчитать и понять, во сколько вам обойдется реализация продукта. Так, мобильное приложение для одной платформы у фрилансера обойдется вам в 300 ч * 600 руб/ч = 180 тысяч рублей, а у региональной компании 300 ч * 1300 руб/ч = 390 тысяч рублей руб.

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

Можно ли мне создать продукт без программистов, самостоятельно?

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

Конечно, существуют ограничения на создание «продукта без программистов»:

  • Вы создаете MVP (minimal viable product, минимально жизнеспособный продукт), с помощью которого хотите протестировать ваши гипотезы по тому, как клиенты будут использовать продукт. То есть временное решение, прототип.
  • Задача понятна и может быть решена существующими на рынке техническими средствами.
  • В итоге продукт все равно нужно будет переделать.

Такой продукт часто называется прототипом.

Первый пример — программа лояльности

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

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

Есть несколько вариантов реализации. Первый — нанять разработчиков и объяснить им, что вы хотите. Либо можно сделать первый прототип самому. Например, с использованием следующих средств:

  • Для создания сайта воспользоваться сервисами Tilda или Wix. Я рекомендую Tilda, который в стандартной поставке содержит множество красивых визуальных шаблонов сайтов. Конечно, без практики создать сайт в таких сервисах тоже не получится. К тому же, вы должны понимать, как работают веб-сайты, на что в первую очередь обращает внимание пользователь, как сделать меню и другое. Облегчает задачу наличие большого числа разнообразных шаблонов.
  • Формы заявки: Google Forms или CRM-формы Bitrix24. Опять же, ничего не нужно будет программировать самому. Нужна лишь сноровка и опыт работы в компьютерных программах. Если у вас проблемы с последним, рекомендую сначала стать хотя бы «продвинутым» пользователем сайтов и приложений.

Итак, вот какие шаги вам нужно выполнить:

  • Cоздаете в Tilda свой сайт, помещая на главную страницу основную информацию и кнопку «Зарегистрироваться».
  • Создаете опросник в Google Forms с вопросами о партнерских продуктах. Копируете ссылку на него в буфер обмена.
  • На сайте меняете свойства кнопки, устанавливая ей в качестве целевого действия ссылку на опросник, созданный на предыдущем этапе.

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

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

Второй пример — интернет-магазин

Если вам нужен интернет-магазин, нет нужды нанимать программистов для его реализации. Можно использовать платформы вроде Ecwid, или сообщество во «ВКонтакте», где в меню группы вы можете разместить каталог товаров, которые продаете. На индивидуальный магазин вы потратите сотню тысяч рублей, а вот самостоятельно можете реализовать за несколько выходных.

Еще один вариант — вообще не создавать интернет-магазин, а воспользоваться размещением на площадках объявлений и аукционов, например, tiu.ru, au.ru, avito.ru и других. Такие площадки имеют расширенные (часто платные) возможности для предпринимателей или компаний, которые торгуют профессионально. Часто такая площадка способна сгенерировать вам достаточно трафика сразу же после размещения товаров. В этом заключается огромное преимущество размещения на платформе, а не на своем индивидуальном сайте или сообществе во «ВКонтакте».

Третий пример — сайт-сообщество

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

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

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

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

Нужно понимать, что программная часть — всего лишь инструмент, решающий задачу. Основа большинства успешных цифровых продуктов — инновация ценности, а не технологическая инновация. Большинство широко распространенных цифровых продуктов — Uber, Facebook, «ВКонтакте» и прочие, — хоть и имеют в своей основе нетривиальные технические решения, но это не то, что обеспечивает их конкурентоспособность.

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

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

Присылайте колонки, соответствующие требованиям редакции, на secret@vc.ru.

>> Чтобы бизнес был прибыльным, стоимость привлечения одного клиента (CPA — cost per acquisition) должна быть больше вашего общего заработка с этого же клиента за все время его жизни (LTV — lifetime value) — CPA < LTV.

Все таки меньше, а не больше.

0

Сорри, опечатка, уже поправила редакция.

"Как разработать продукт (сайт, приложение)? Я ничего в этом не понимаю".
***
Никак. Нельзя "ничего в этом не понимать" и создать успешный продукт.
Инвестируй в то в чем понимаешь или понимай то во что инвестируешь.

0

Не надо давать таких вредных советов заказчикам.
Если все потенциальные клиенты будут так делать, то большая проектов умрет на стадии "Убедитесь, что ваш продукт будет востребован" и большинство разрабов с голодухи перемрёт.

0

Но, может, в долгосрочной перспективе и лучше, что неуспешных проектов будет меньше?

На 100% проверить, что продукт будет востребован и будет генерировать прибыль, можно только построив продукт.

На одной конференции услышал интересную мысль "Время довольных клиентов прошло. Нужно, чтобы ваши клиенты были успешными". Как разработчик, представьте, что лучше (1) к вам приходит клиент, вы ему разрабатываете проект, который не взлетает, и потом клиент не возвращается (2) проект "взлетает", и клиент приходит к вам опять за доработками.

0

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

Кстати, очень часто бывает так, что проект "взлетает", и клиент уходит к другому за доработками, потому что у него на 10% дешевле или сроки меньше или ещё по сотне других причин.

0

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

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

0

Я, возможно, не совсем правильно донес мысль. Все, про что Вы говорите ("пресейлы, кастдев, проверка на прототипах") включено во второй диаграмме в "Реализовали / доработали продукт" и "Сняли обратную связь". Просто не детализировано. Можно считать прототип первой версией продукта.

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

0

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

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

Прототип - это только снятие фидбека по текущему функционалу/user journey с сомнительной чистотой, потому что UI всегда внесет свои коррективы в UX)

Так умиляют все эти статьи для мамкиных стартаперов)

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

Поэтому и писался материал, потому что вопросы жизненные.

0

Сережа, не дурите людям голову. 300 часов на приложение, 800 на сайт) ибо вы этим формируете неоправданные ожидания у той группы людей, которые это все читает и верит в чудеса. Разброс от проекта к проекту будет настолько сильный, что предсказать это просто нельзя. И почему вы пишете о разработчике, а UX, а дизайн, а тестирование, а администрирование сервера, а менеджмент, я бы ваши оценки смело умножил на 3 и назвал бы это потолком для MVP, куда больше будет походить на правду

0

Вы абсолютно верно подметили, что разброс может быть гигантским, но в статье постарался явно упомянуть, что цифры примерные, для понимания порядка. То есть простое мобильное приложение - это не 30, но и не 3000 часов. За 300 часов вполне есть очень простые проекты, так же как и простые вебсайты за 800.

По поводу UX/UI/менеджмент/тестирования, это частично заложено в стоимости часа студии, если мы смотрим стоимость часа по различным вариантам подрядчиков (и не заложено, например, в просто программисте), хотя, возможно, нужно было описать это более явно. Не было идеи очень подробно расписать структуру затрат на MVP, это могло бы быть темой для следующей статьи :) чего точно не хотелось - так это дать чересчур оптимистичные цифры.

Прямой эфир
Компания отказалась от email
в пользу общения при помощи мемов
Подписаться на push-уведомления