Как быстро запустить продукт без кода, если разработка перегружена? Кейс «Умназии»
Сейчас много говорят о возможностях no-code-инструментов, но не приводят реальных кейсов их использования в России, поэтому мы в сообществе «Cyberband | IT продукты без кода» рассказываем о практической пользе таких сервисов для запуска новых продуктов. В этой статье речь пойдет о том, как был запущен продукт «Умназия Репетиторы» без кода.
Ну я даже не знаю,
чтобы это все реализовать вы фактически изучили разработку самостоятельно:
1. технический английский
2. push оповещения
3. mailchimp - свой язык для шаблонов и скрипты для компаний
4. интеграция , которая в приведенных системах делается через openid и JWT токены
5. канбан блин
Может проще было все же программиста позвать?
Ну и самое главное: вы в итоге получили-то не продукт а просто настройку и связку чужих продуктов, причем все немедленно накроется если хотя-бы один из внешних сервисов упадет или потеряет ваши данные.
Понимаю что это школа и репетиторы, но все же.
Хороший комментарий про программиста, давайте разбираться.
1. Технический английский. Повезло с образованием, бэкграундом + без стремления, везение не работает. В целом, сейчас сложно представить, чтобы современный продакт менеджер в Москве не мог работать в иностранных сервисах или не знал язык.
2. Push оповещения. Их не было. Коммуникация выстроена через триггерные емейлы.
3. Mailchimp - ну очень простой конструктор email рассылок, сопоставим по сложности с легкой Тильдой.
4. Про сервисы интеграции, Integromat. В приведенных системах это делается сложно, если смотреть "под капот". Но для настройки приведенных в кейсе сценариев можно в это не залезать. Это, скажем, для интересующихся людей, информация со звездочкой.
5. Не понял, что имеете ввиду, но Airtable автоматически настраивает вид канбан доски из обычной таблицы.
И теперь главный вопрос. Не проще ли было взять программиста? Ответ на этот вопрос складывается из контекста:
1. В стартапах не супер большая команда разработки,
2. В момент реализации были условия срочности + разработка была занята более понятными фичами и продуктами.
3. Нарисовать прототип и сделать нормальное ТЗ, отдав реализацию программисту - для меня, как для продакта, легко, но сложно для бизнеса. Потому что в таком случае пришлось бы ждать, ждать, ждать... Опять обращаю внимание на контекст.
Такой подход позволил через 7-10 дней не только собрать первую версию, но и сделать первые продажи. В разработке так не будет. А все остальные усложнения делались поэтапно, когда я видел перспективу дальнейшего развития и автоматизации. Плюс в том, что команда разработки на выходе получит ТЗ уже протестированной гипотезы и бизнес кейса. Да ещё и с четкой приоритезацией фич. Для бизнеса такой подход полностью оправдан.
И да, вы правы, если один из сервисов упадет, возникнет проблема. Но также могут упасть и серваки на обычной платформе. И для меня, как для продакта, отслеживать, чтобы все работало, не сложно, плюс, в этом менеджеры помогают. У продакта столько метрик, за которыми нужно следить, этот контроль не станет чем-то сверх сложным.
Надеюсь, смог прояснить логику выбора именно этого подхода в контексте событий, в которых мы тогда оказались.