Как быстро запустить продукт без кода, если разработка перегружена? Кейс «Умназии»

Сейчас много говорят о возможностях no-code-инструментов, но не приводят реальных кейсов их использования в России, поэтому мы в сообществе «Cyberband | IT продукты без кода» рассказываем о практической пользе таких сервисов для запуска новых продуктов. В этой статье речь пойдет о том, как был запущен продукт «Умназия Репетиторы» без кода.

Статья посвящена истории запуска MVP продукта «Умназия Репетиторы» без кода, в момент старта самоизоляции и загруженности команды разработки. Мне хотелось дать максимальную ценность из полученного опыта, поэтому статья достаточно объёмная.

Спойлер: в конце статьи, вы найдете результаты, экономику продукта, список всех использованных No-code сервисов со ссылками, выводы по приобретенному опыту запуска такого продукта без кода.

1. Об Умназии

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

2. Идея продукта и контекст

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

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

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

Итак, перед началом тестирования контекст был следующим:

  • Старт самоизоляции. Никто не знал, сколько это продлиться. Школы не спешили настраивать Zoom. Родителям нужно было занять детей, и желательно чем-то полезным.
  • Умназия в своей основе предполагает возможность заниматься самостоятельно. Но в данных условиях было очевидно, что усидчивость и внимание у детей будут низкими, чтобы заниматься без помощи.
  • Умназия тестировала продукт «Репетитор» год назад с отрицательными результатами.
  • Для нового теста набор продуктов расширился до 4.
  • Воронка вводных уроков, где предлагали приобрести полный набор всех курсов, показала отрицательный результат.
  • Блок репетиторов на вводных занятиях не вызывал интерес.
  • Команда разработки была перегружена.

3. Важные решения и подход к тесту

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

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

  1. Выбрать главный предмет, по которому будем предлагать репетитора. Важные критерии такого продукта были следующими: а) его популярность у детей и родителей, б) структурированность курса и возможность его быстрой адаптации под репетитора, в) доступность хороших репетиторов по данной теме, г) скорость их нахождения и онбординга.
  2. Сделать «Финансовую грамотность» первым и главным продуктом для формата репетиторов. Из двух предметов «Математика» и «Финансовая грамотность» мы выбрали второй. Программа «Финансовая грамотность» для детей уже была очень популярной в Умназии. Она было достаточно сложной, поэтому репетитор по этому продукту был очень кстати. Курсы были отлично структурированы и идеально подходили под быструю адаптацию в индивидуальные занятия. Также, популярность высшего образования в сфере экономики и финансов дала возможность быстро найти репетиторов из лучших российских ВУЗов, желающих заниматься с детьми и хорошо разбирающихся в теме.
  3. Создать стандартную воронку продаж через вводные уроки.
  4. Привлекать лидов на конкретную программу, вместо всех курсов как раньше.
  5. Оставить предложение в конце вводного урока только по продукту «Репетитор по финансовой грамотности». Ранее на вводных занятиях цена по сравнению с обычным пакетом самостоятельного обучения была намного выше и, конечно, смущала большинство людей, поэтому репетитора не выбирали.
  6. Сделать запуск быстро, сделать запуск без кода, не отвлекая команду разработки.
  7. Автоматизировать и улучшать продукт постепенно.

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

4. Готовимся к запуску

Хоть мы и видели перспективу такого запуска, но из-за прошлых неудачных тестов продукта «Репетиторы» не хотелось тратить много времени на тест.

С чего мы начали и какие No-code инструменты использовали?

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

Ещё перед началом я настроил АБ тест с помощью Google Optimize, который вел 50% на лендинг с 1 бесплатным вводным уроком, а ещё 50% на лендинг с 2 платными вводными уроками по символической сумме. Эту идею мне предложили в продуктовой команде. Мне она показалось достаточно интересной в части того, что показатель доходимости до вводного приблизится к 100%, как и повысится готовность приобрести пакет занятий у таких лидов. Итак, меньше чем за неделю у нас появились:

  1. лендинг на Tilda: https://welcome.umnazia.ru/tutor-free,
  2. подключенный Google Sheets для сбора заявок,
  3. прием платежей через CloudPayments,
  4. письма-отбивки через Mailchimp,
  5. АБ тест через Google Optimize,
  6. настроенная аналитика через Google Tag Manager, который отдавал данные в Google Analytics и Amplitude,
  7. план вводного занятия.
Пример 1. Лендинг нового продукта. Умназия: "Репетитор по финансовой грамотности" для детей.

Далее было сформировано ТЗ к отделу маркетинга, который запустил рекламу. Тест начался.

5. Первые вводные уроки и первая продажа

Итак, первые заявки пошли. Кто заплатил символическую сумму за 2 вводных урока в 100% случаев доходили до этого занятия. Кто не оплатил, хотя заявку отправил с лендинга с платными вводными, мы связывались и предлагали 1 бесплатный.

Мы провели первые вводные уроки. Так как мне было интересно понять клиентов, я провел несколько вводных параллельно с нашими менеджерами. И вот на одном из моих первых бесплатных вводных уроков произошла первая покупка. Это произошло спустя 1,5 недели, как было принято решение тестировать.

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

Как происходили события следующую неделю до первого платного занятия.

  1. Начали поиск репетиторов из лучших профильных ВУЗов.
  2. Адаптировали программу под репетиторов, вместе с методистами добавили интересные теоретические части в начале уроков.
  3. Нашли и выбрали лучших репетиторов.
  4. Провели для них онбординг и тестовые уроки.
  5. Так как продажи не остановились на 1-ой покупке, я делегировал их полностью команде наших замечательных администраторов и менеджеров.
  6. Поучаствовал ещё на нескольких вводных как «отдел контроля», чтобы понять, какие цели у родителей по обучению «Финансовой грамотности» самые популярные, почему нужен репетитор, и что останавливает от покупки.
  7. Начал думать о дальнейшей автоматизации.
  8. Просчитал предварительную экономику нового продукта.

6. Организация бизнес-процессов и делегирование

Мы справились с большим объемом задач за неделю и запустили следующий этап тестирования нового продукта. Здесь мне нужно выразить огромную благодарность:

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

Итак, спустя всего 2 недели с начала разработки продукт был запущен, начались первые продажи и первые платные занятия с репетиторами. Уже в этот период работа в Google Sheets тормозила процесс и менеджеров, и менторов. Это нужно было менять.

А что с экономикой? Точные данные раскрывать не могу, но основные результаты отмечу.

  1. Я сделал расчет юнит-экономики с учетом операционных затрат менеджеров на вводные уроки и звонки, и репетиторов, которым мы начали платить за проведенные уроки.
  2. Конверсии в покупки были перспективными.
  3. Понятно, что по экономике первых продаж прибыль была отрицательной, особенно с учетом операционных костов. Но здесь ставка была на продления занятий и LTV (lifetime value) клиентов.
  4. У продукта «Финансовая грамотность» есть 5 ступеней. Прохождение всех ступеней я оценил в 5-6 пакетов по 8 занятий.
  5. Для расчета я остановился на мультипликаторе «2,5», чтобы предположить LTV клиента. Кто-то купит все пакеты занятий, кто-то остановится только на одном и не будет продлять. Коэффициент «2,5» показался нам справедливым.
  6. С учетом мультипликатора «2,5» в повторные покупки и с учетом операционных костов на менеджеров и репетиторов, первая когорта на цифрах выглядела перспективной, выходящей в плюс даже с учетом маркетинговых затрат и финальной стоимости привлеченного клиента из когорты (CAC — customer aquisition cost).

Осталось подтвердить такие же хорошие конверсии в следующих когортах клиентов и гипотезу по продлению пакетов занятий.

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

7. Оптимизация работы менеджеров

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

Основная задача была в ускорении их работы с заявками, но все ещё остаться на уровне «Без кода».

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

Прямой интеграции у Tilda и Airtable нет, поэтому для передачи данных мы использовали Integromat, который связал 2 сервиса с помощью Webhook (хорошо, что у Тильды он легко подключается).

В итоге, данные с заявками на вводный урок 2 платных/1 бесплатный с Tilda поступали через Integromat в Airtable на лист «Заявки интро». Оплаты пакетов занятий поступали на лист «Заявки репетиторы». Лист «Заявки репетиторы» линковался с листом «Заявки интро», что позволяло подтянуть к оплатившему клиенту информацию о его вводном уроке: дата проведения, класс ребенка, имя, контактные данные, цель обучения, желаемые даты занятий.

Пример 2. Airtable, листы "Заявки интро" и "Заявки менторы", вид таблицы.

Новые заявки стали поступать сверху в таблицу «Заявки интро». У каждого клиента, кроме новых заявок, были статусы, по которым заявка двигалась в продажу. Основными статусами были: к прозвону, назначен вводный, проведен вводный, позвонить напомнить, куплен пакет занятий, апгрейд занятий. По этим статусам заявки из таблицы очень наглядно двигались по канбан доске Airtable (другой вид той же информации). А дата и время вводных отлично были структурированы с помощью вида «Календарь».

Пример 3. Airtable, лист "Заявки интро", вид канбан доски и календаря.

Таким образом, Airtable превратился в CRM систему для нового продукта. Работа менеджеров стала заметно быстрее и проще. А для меня, как для продакт менеджера, стало очень наглядна визуализация результатов и работ по заявкам. Я мог зайти и быстро оценить ситуацию, и если было нужно, закопаться поглубже в данные, чтобы установить причинно-следственные связи.

8. Оптимизация работы репетиторов

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

Для решения данной задачи, также был использован Airtable. Я создал отдельный лист в таблице Airtable «Ученики/уроки». После оплаты менеджеры добавляли туда учеников, назначали ментора из списка, линковали с предыдущими листами, чтобы у репетиторов было представление о новых учениках и их целях. Из общего вида таблицы на листе «Ученики/уроки» для каждого ментора мы создали их личные:

  • таблицы с учениками, отфильтрованные по конкретному репетитору,
  • календари для каждого репетитора, отфильтрованные по занятиям только их учеников.
Пример 4. Airtable, лист "Ученики/Уроки", вид таблица.

Как стала выглядеть работа репетиторов:

  1. Репетитор видел в своей таблице нового ученика, первую дату платного занятия и желаемые даты на будущее.
  2. Он проставлял даты и время занятий, ссылки на Zoom с темой урока.
  3. После проведения урока ставил статус «Проведен», записывал комментарии и результаты (которые в будущем стали обратной связью с родителями), ставил дату следующего урока.
  4. Управлял расписанием занятий по календарю, из которого также можно было открыть любую карточку занятия со всеми данными.

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

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

9. Автоматизация общения с клиентами

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

Теперь задачей было автоматизировать общение с клиентом и сделать процесс для него более прозрачным. В качестве решения я выбрал триггерные email письма:

  • Перед занятием. За 1 час до начала урока приходило напоминание и ссылка на подключение.
  • После занятия. Родители стали получать комментарии от репетитора о проведенном занятии, дату и ссылку следующего занятия.

Для реализации такого сценария понадобились триггерные столбцы в Airtable на листе «Ученики/уроки», Gmail, отправляющий письма, и Integormat, который бы связал 2 этих сервиса. При определенных условиях Integromat запускал сценарий отправки сообщения.

Для реализации сценария № 1 «Письмо перед занятием» использовались следующие триггеры:

  1. Столбец с текущей датой и временем в часах (Airtable).
  2. Столбец с датой и временем занятия, минус 1 час (Airtable).
  3. Столбец, в котором сравнивалась текущая дата и дата за 1 час до урока. Если дата хоть одного из занятий была равна текущей дате, то поле автоматически заполнялось значением «today», если нет «no» (Airtable).
  4. При заполнении в одном из занятий значения «today» в 2 отдельных столбцах автоматически заполнялись: номер занятия, ссылка на Zoom и тема урока. Все это сделано через формулы в Airtable.
  5. Integromat проверял каждые 50 минут совпадения условий.
  6. Если в одном из столбцов Airtable с номером занятия есть значение «today», то Integromat запускал сценарий отправки письма с напоминанием о предстоящем занятии, ссылкой на подключение Zoom, темой урока (автоматически подтягивались из столбцов Airtable).

Для реализации сценария № 2 «Письмо после занятия» использовались следующие триггеры:

  1. Репетитор после занятия заполнял: а) статус «Проведено», б) комментарий о результатах для родителя, в) ссылку на следующее занятие и тему урока, г) дату и время следующего занятия (в Airtable).
  2. Integromat проверял каждый день в 10:00 по московскому времени следующие условия в Airtable: а) статус одного из занятий «Проведено», б) поле с результатами «Не пустое», в) отправлялось ли раньше это сообщение «No».
  3. Если все условия соблюдены, то Integromat триггерит письмо с комментариями от репетитора о проведенном занятии для родителей, датой и ссылкой следующего занятия.
  4. После отправки он автоматически ставит в столбец Airtable галочку, что письмо уже отправлялось для данного занятия. Это позволяет отправить такое письмо 1 раз, а не отправлять его каждый день клиенту (ведь остальные условия соблюдены).
Пример 5. Integromat, два сценария автоматизации: "Письмо перед занятием" и "Письмо после занятия".

Таким образом, репетиторы полностью перешли на Airtable, заполняя даты, статусы и результаты. А родители получили прозрачную и понятную коммуникацию с напоминанием о предстоящем занятии и с результатами проведенного урока.

10. Результаты и экономика

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

Отдел маркетинга сообщал результаты рекламы, стоимость кликов и заявок во вводное занятие. По статусам в Airtable можно было быстро понять сколько было заявок в 2-х недельной когорте, сколько проведено вводных, сколько приняли решение купить пакет занятий. При этом, благодаря связкам/линкам между листами «Заявки интро» и «Заявки репетиторы» было понятно, к какой когорте относится оплативший клиент, так как на лист оплат подтягивалась информация о дате вводного урока и создании заявки. Более того, можно было отнести повторную покупку в правильную когорту, в которой клиент оставил заявку на вводный урок.

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

Говоря о количественных результатах, такой MVP продукта давно перевалил за 100 тысяч рублей выручки. Спустя около 2 месяцев теста первая когорта с учетом LTV (первые продажи и продления) и CAC (расходы на маркетинг, менеджеров и репетиторов) показала положительный результат по юниту. Это было отличной новостью.

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

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

11. Выводы

Давайте ещё раз перечислим все использованные No-code инструменты для запуска MVP нового продукта:

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

  1. No-code инструменты становятся отличным решением для современных продактов, которые позволяют быстро тестировать новый продукт в условиях перегрузки команды разработки.
  2. Даже если бы команда разработки была свободна, запуск и реализация таких фич заняла бы намного больше времени.
  3. Продакты и основатели проектов могут не просто проводить кас девы и тестировать прототипы, но и выйти на более сложный уровень: теста MVP без кода и без привлечения команды разработчиков на этот этап.
  4. No-code инструменты не заменят код, но в быстром и дешевом тесте MVP дадут большое преимущество.
  5. Улучшать продукт даже на No-code лучше постепенно, как это было у нас. Найдите то, за что пользователи будут готовы вам платить уже сейчас, то что будет решать их проблему в самой простой реализации.
  6. Кто-то может долго существовать на таком стэке, некоторые даже инвестиции на No-code проектах привлекали. Я же сторонник того, что это классные решения на стадии MVP продукта, не основанного на супер технологиях.

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

Больше реальных кейсов, обзоров No-code сервисов, новостей и обучающих материалов, вы найдете в нашем Telegram-канале. Будьте в курсе новых возможностей!

Подписывайтесь в наш Telegram-канал: @cyberband_agency

Статью подготовил Кирилл Петров — создатель агентства разработки без кода Cyberband, ex Product owner в Умназия, ex Strategy consultant в IBM. На момент запуска продукта «Умназия Репетиторы» являлся действующим PO в Умназии.

Образовательная платформа Умназия: umnazia.ru

Умназия на vc.ru

0
22 комментария
Написать комментарий...
Alexander Olssen

Наконец-то реальный опыт, где все по полочкам.

Ответить
Развернуть ветку
Кирилл Петров
Автор

Благодарю за обратную связь

Ответить
Развернуть ветку
Alex Ayer

Кирилл, скажи пожалуйста, сколько примерно времени ушло (или предположи - сколько уйдёт) на изучение всех этих no-code сервисов?

Ответить
Развернуть ветку
Кирилл Петров
Автор

Алекс, зависит от вашего бэкграунда. Если у вас есть верхнеуровневое понимание архитектуры ИТ продуктов, или вы связаны с продакт менеджементом, то какие-нибудь простые No-code сервисы, по типу Тильды, Airtable, Glide, Integromat, освоете быстро. С запасом времени и с большой мотивацией можно заложить 7-10 дней на 1 сервис. Каждый следующий будет легче. Более сложные конструкторы, типо Bubble io, займет, конечно, больше времени. Опять же у всех по-разному, я бы поставил 1-2 месяца, чтобы показать, что это не просто.

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

Ответить
Развернуть ветку
Alex Ayer

Прям услышал именно то, что ожидал. Спасибо за развёрнутый ответ! 

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

Спасибо за реальный кейс. 

Ответить
Развернуть ветку
Alex Chernyshev

Ну я даже не знаю, 
чтобы это все реализовать вы фактически изучили разработку самостоятельно:
1. технический английский
2. push оповещения
3. mailchimp - свой язык для шаблонов и скрипты для компаний
4. интеграция , которая в приведенных системах делается через openid и JWT токены
5. канбан блин

Может проще было все же программиста позвать? 

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

Понимаю что это школа и репетиторы, но все же.

Ответить
Развернуть ветку
Кирилл Петров
Автор

Хороший комментарий про программиста, давайте разбираться.

1. Технический английский. Повезло с образованием, бэкграундом + без стремления, везение не работает. В целом, сейчас сложно представить, чтобы современный продакт менеджер в Москве не мог работать в иностранных сервисах или не знал язык. 
2. Push оповещения. Их не было. Коммуникация выстроена через триггерные емейлы.
3. Mailchimp - ну очень простой конструктор email рассылок, сопоставим по сложности с легкой Тильдой.
4. Про сервисы интеграции, Integromat. В приведенных системах это делается сложно, если смотреть "под капот". Но для настройки приведенных в кейсе сценариев можно в это не залезать. Это, скажем, для интересующихся людей, информация со звездочкой. 
5. Не понял, что имеете ввиду, но Airtable автоматически настраивает вид канбан доски из обычной таблицы.

И теперь главный вопрос. Не проще ли было взять программиста? Ответ на этот вопрос складывается из контекста:
1. В стартапах не супер большая команда разработки, 
2. В момент реализации были условия срочности + разработка была занята более понятными фичами и продуктами.
3. Нарисовать прототип и сделать нормальное ТЗ, отдав реализацию программисту - для меня, как для продакта, легко, но сложно для бизнеса. Потому что в таком случае пришлось бы ждать, ждать, ждать... Опять обращаю внимание на контекст.

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

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

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

Ответить
Развернуть ветку
Alex Chernyshev

'Push оповещения. Их не было
 но Airtable автоматически настраивает вид канбан доски из обычной таблицы.'

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

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

Мне кажется, у ИТшников есть тенденция недооценивать юзеров вокруг них :). Я, скажем, всю жизнь проработал в экономике и финансах и интересуюсь ИТ в основном в порядке хобби (ну и немного автоматизировать свою работу), но незнакомых слов ни в статье, ни в обсуждении не встретил.

Вообще, no-code/low-code решения наверное и хороши прежде всего для тех пользователей, для которых ИТ это не профессия, а просто один из инструментов решения конкретных прикладных задач, зачастую ограниченных по времени. Потому что искать программиста, делать понятное ему ТЗ и доводить потом продукт до приемлемого состояния может быть дольше и дороже, чем собрать такую вот франкен-систему из нескольких сервисов, закрыть потребность и потом уже думать что делать дальше.

Ответить
Развернуть ветку
Alex Chernyshev

Ну экономика-финансы всегда были близки к ИТ, мы ит-шники начинали с того что писали для вас экономистов калькуляторы в 70х ) 
Половина автоматизации и софта в мире до сих пор наверное пишутся для финансовой сферы. 
Плюс у вас знание SQL и MS Excel уже лет 10 как обязательное требование в профессии.

Проблема no-code/low-code в основном в том что будет потом: когда этот франкенштейн заработает, ну я выше описывал.

Ответить
Развернуть ветку
Кирилл Петров
Автор

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

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

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

А вообще каждому бы в современном мире пройти основы архитектуры ИТ сервиса, потратить неделю, будет очень полезно. 

Ответить
Развернуть ветку
Alex Chernyshev

'кейс своего знакомого, который просто предприниматель, причем из оффлайн проекта, '

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

Даже в  вашем-то случае, с вашим бекграундом это станет проблемой через год-два: обновление API ключей, изменения в API ( что-то запросто отвалитс )  бекапы данных  - ну вы понимаете полагаю.

Ответить
Развернуть ветку
Кирилл Петров
Автор

Я вас понял.

Ни в коем случае не настаиваю на том, что такая реализация на всю жизнь, как раз в конце статьи указал. Пока это даже не год, а меньше, в случае Умназии. Это протестировать MVP, подтвердить бизнес гипотезу, подтвердить интерес к определенным фичам / продукту в целом. А дальше, конечно, нужно идти в код. Что, кстати, и делает команда Умназии после подтверждения бизнес кейса по новому продукту. Такой запуск продукта - это не бизнес, это лишь подтверждение бизнес гипотезы для последующих реализаций. Процент смерти стартапов более 90% делает этот подход рациональным с точки зрения бережливого подхода. 

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

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

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

Ответить
Развернуть ветку
Вадим

Отличная статья. Несколько вопросов. Почему не взяли за основу готовую LMS систему, в которой уже встроены платежи, календарь, учетные записи для учеников и репетиторов, например с интеграцией ZOOM и календарем (будут автоматические уведомления и напоминания) и все что нужно для дистанционного обучения? Почему выбрали для платежей CloudPayments? 

Ответить
Развернуть ветку
Кирилл Петров
Автор

Вадим, хороший вопрос, я бы ответил так:
1. Сколько я не видел платформ, и сколько бы ко мне не обращалось клиентов с понятной функциональностью для реализации, всегда, всегда есть какое-то узкое место, из-за которого либо реализации идеи на какой-то платформе невозможна, либо нужно делать костыль и интеграцию.
2. Как я упоминал в тексте, часть такого процесса запуска у Умназии была отработана на упомянутых сервисах. Когда вопрос в срочности, очень сложно перескочить на незнакомый сервис эффективно. Я постоянно изучаю новые конструкторы, расширяю кругозор, в том контексте это было не оправдано.
3. Тогда занятие было бы на одной платформе, а учетка на другой. Не хотели городить несколько личных кабинетов, заменили ее грамотной коммуникацией. Стратегия такая - сформировать удобную учетку при переводе продукта на обычную платформу, в код.

Про CloudPayments.

Умназия использует 2 сервиса приема платежей Яндекс кассу и Cloud payments, оба удобные сервисы. Знаю, что CloudPayments может делать безакцептные платежи по подписке, но в данном кейсе это преимущество не использовали. Как то уже привыкли в тестах продукта использовать CloudPayments, на основной платформе Яндекс Касса. Наверно, ответ будет банальный и простой - привычка.

Ответить
Развернуть ветку
Maksim Sych

Очень крутая и структурированная статья. Спасибо!

Ответить
Развернуть ветку
Nikita Naumov

Кирилл, это топ, пиши ещё!

Ответить
Развернуть ветку
Ev Valk

Обычно в кейсах много воды, но этот читать интересно и познавательно) спасибо)

Ответить
Развернуть ветку
Кирилл Петров
Автор

Спасибо всем за вопросы и обратную связь! Подписывайтесь на Телеграм-канал: https://t.me/cyberband_agency. Все кейсы здесь выкладывать не буду, там найдете больше интересного, плюс не только мои кейсы, но и опыт знакомых / коллег / клиентов.

Ответить
Развернуть ветку
Ekaterina Yuzefovich

Отличный кейс. Спасибо. Было очень интересно читать.

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