Я все таки решился запустить давний проект колоды карт для геймдизайнеров как краудфандинговую кампанию. Заодно и посмотрю, что за зверь такой краудфандинг.
Выбрал для этого Планету, как наиболее популярный у нас сервис. Финансово они берут 10% от собранных денег, если собираешь 100% от заявленной суммы или больше. Если же набирается от 50 до 100%, то их доля уже составляет 15%. При сборе менее половины заявленной суммы деньги возвращаются поддержавшим обратно.
Запуск самой кампании оказался довольно прост. Надо сделать описание кампании (обычная структура - о создателях проекта, что за продукт, на что пойдут деньги) и не менее 3 наград, которые могут включать собственно сам продукт на который собирается финансирование. Как вы сами видите в кампании - я не стал изобретать и просто поставил награды в виде разного числа колод, но этого оказалось мало и пришлось по правилам сервиса сделать еще цифровую награду. Для этой награды я придумал делать цифровой постер с разбором механик любой игры по выбору поддержавшего.
В целом на создание кампании и общение с сервисом, а там каждому назначают куратора, ушло 3 дня с учетом доработки кампании и подписания договора.
В качестве средства продвижения, я выбрал рекламные сообщения в профильных телеграм каналах для разработчиков игр в целом и геймдизайнеров в частности. Посмотрим, что из этого получится.
Ну и конечно, если вам интересен этот проект, то можете его поддержать репостом или непосредственно на Планете
https://planeta.ru/campaigns/190388
Выбрал для этого Планету, как наиболее популярный у нас сервис. Финансово они берут 10% от собранных денег, если собираешь 100% от заявленной суммы или больше. Если же набирается от 50 до 100%, то их доля уже составляет 15%. При сборе менее половины заявленной суммы деньги возвращаются поддержавшим обратно.
Запуск самой кампании оказался довольно прост. Надо сделать описание кампании (обычная структура - о создателях проекта, что за продукт, на что пойдут деньги) и не менее 3 наград, которые могут включать собственно сам продукт на который собирается финансирование. Как вы сами видите в кампании - я не стал изобретать и просто поставил награды в виде разного числа колод, но этого оказалось мало и пришлось по правилам сервиса сделать еще цифровую награду. Для этой награды я придумал делать цифровой постер с разбором механик любой игры по выбору поддержавшего.
В целом на создание кампании и общение с сервисом, а там каждому назначают куратора, ушло 3 дня с учетом доработки кампании и подписания договора.
В качестве средства продвижения, я выбрал рекламные сообщения в профильных телеграм каналах для разработчиков игр в целом и геймдизайнеров в частности. Посмотрим, что из этого получится.
Ну и конечно, если вам интересен этот проект, то можете его поддержать репостом или непосредственно на Планете
https://planeta.ru/campaigns/190388
Planeta.ru
Колода карт геймдизайнера | Planeta
Колода карт игровых механик для геймдизайнеров для проектирования новых игр и анализа чужих. 99 игровых механик в 14 группах покрывают все аспекты и механики видеоигр.
Итак, поставил точку в проекте "Колода геймдизайнера", отнеся вчера последние колоды в доставку. В целом, крайне интересный опыт организации и продвижения краудфандинга, но для себя сделал вывод, что физические товары не моё. Слишком много возни с изготовлением и доставкой. Я конечно попробую еще закинуть удочку дистрибуторам настольных игр, но ничего существенного не ожидаю.
Для тех кому интересна финансовая сторона дела, то результат следующий:
- Доход 101 тыс рублей
- На продвижение ушло 13,5 тыс - платная реклама в 2 телеграм каналах и еще в 4 каналах разместился по бартеру взамен на саму колоду
- % площадки составил 9,8 тыс
- Расходы на доставку 27 тыс
- Изготовление колод 40 тыс
Итого чистыми у меня осталось 10 тысяч рублей, то есть рентабельность с учетом всех моих прочих расходов и затрат времени очень даже отрицательная.
Неожиданный подарок сделала типография - хотя я заказывал 75 колод, они напечатали 80 и в результате у меня осталось несколько колод, которые возможно еще продадутся. Специально для этого сделал лэндинг на https://gamedeck.bitrix24.site/
С точки зрения продвижения - я разместил рекламные посты в 2 тг каналах про разработку игр, еще 4 геймдизайнера сделали посты у себя в каналах (кто-то просто разместил текст, а некоторые попробовали детально разобрать особенности колоды). Также разместил пост в Вастрик клубе и пост на работе во внутренней группе по хобби на 1000 подписчиков.
По времени кампания заняла чуть меньше месяца и наверное можно было бы потянуть время еще, но мне показалось, что важнее скорее доставить колоду поддержавшим и поэтому я досрочно прекратил кампанию (изначальный срок был 2 месяца). Чтобы сделать приятно тем, кто поддержал - я к исходной колоде на 99 карт добавил 28 дополнительных карт, которые были в первоначальной версии списка игровых механик и которые можно опционально применять. Но оценивая результат, кажется что так колода стала более громоздкой и оптимально использовать только базовую часть (я это сразу предусмотрел, поэтому базовая и дополнительная части колоды отличаются цветом рубашки).
Вообще, общение с людьми в процессе продвижения кампании дало идей на развитие еще на год вперед, открыл для себя некоторые другие аспекты геймдизайна, которые не учитывал при создании колоды. Поэтому если (или когда) вернусь к этому проекту, то готовый бэклог у меня уже есть. Ну и надеюсь, что обратная связь от геймдизайнеров, которые уже заказали колоду, подкинет еще инсайтов.
Дальше же планирую заняться давно вынашиваемым проектом в сфере HRtech по структурированным интервью и надеюсь в ближайшем времени дописать статью, как legacy продукт превратить в SaaS сервис.
Для тех кому интересна финансовая сторона дела, то результат следующий:
- Доход 101 тыс рублей
- На продвижение ушло 13,5 тыс - платная реклама в 2 телеграм каналах и еще в 4 каналах разместился по бартеру взамен на саму колоду
- % площадки составил 9,8 тыс
- Расходы на доставку 27 тыс
- Изготовление колод 40 тыс
Итого чистыми у меня осталось 10 тысяч рублей, то есть рентабельность с учетом всех моих прочих расходов и затрат времени очень даже отрицательная.
Неожиданный подарок сделала типография - хотя я заказывал 75 колод, они напечатали 80 и в результате у меня осталось несколько колод, которые возможно еще продадутся. Специально для этого сделал лэндинг на https://gamedeck.bitrix24.site/
С точки зрения продвижения - я разместил рекламные посты в 2 тг каналах про разработку игр, еще 4 геймдизайнера сделали посты у себя в каналах (кто-то просто разместил текст, а некоторые попробовали детально разобрать особенности колоды). Также разместил пост в Вастрик клубе и пост на работе во внутренней группе по хобби на 1000 подписчиков.
По времени кампания заняла чуть меньше месяца и наверное можно было бы потянуть время еще, но мне показалось, что важнее скорее доставить колоду поддержавшим и поэтому я досрочно прекратил кампанию (изначальный срок был 2 месяца). Чтобы сделать приятно тем, кто поддержал - я к исходной колоде на 99 карт добавил 28 дополнительных карт, которые были в первоначальной версии списка игровых механик и которые можно опционально применять. Но оценивая результат, кажется что так колода стала более громоздкой и оптимально использовать только базовую часть (я это сразу предусмотрел, поэтому базовая и дополнительная части колоды отличаются цветом рубашки).
Вообще, общение с людьми в процессе продвижения кампании дало идей на развитие еще на год вперед, открыл для себя некоторые другие аспекты геймдизайна, которые не учитывал при создании колоды. Поэтому если (или когда) вернусь к этому проекту, то готовый бэклог у меня уже есть. Ну и надеюсь, что обратная связь от геймдизайнеров, которые уже заказали колоду, подкинет еще инсайтов.
Дальше же планирую заняться давно вынашиваемым проектом в сфере HRtech по структурированным интервью и надеюсь в ближайшем времени дописать статью, как legacy продукт превратить в SaaS сервис.
Cтал всё чаще замечать некосистентность в тех или иных продуктах и сервисах.
Что такое консистентность? Как пишут, ссылаясь на Кэмбриджский словарь, - это качество быть одинаковым, последовательным, согласованным. Про консистентность часто говорят применительно к данным, интерфейсам и пользовательскому опыту. Но его можно рассматривать и как свойство продукта в целом, которое обеспечивает согласованность, целостность, последовательность и непротиворечивость этого продукта.
Это свойство хорошо тем, что консистентный продукт продукт упрощает и ускоряет работу пользователя с ним, снижает когнитивную нагрузку, позволяет быстрее пройти кривую обучения и принять нужные шаблоны работы с продуктом.
В чем же проявляется неконсистентность продукта и чем она плоха? Я приведу пару примеров, а вы возможно дополните меня.
Первым примером будет HH. В сервисе явно видна функциональная неконсистентность между мобильным приложением и веб сервисом для соискателей. Возможно это осознанная стратегия в условиях ограниченных ресурсов, а возможно просто недосмотр продактов HH, но в любом случае видно, что приоритет отдается мобильному приложению, тогда как веб-версия просто остановилась в развитии. На скриншоте ниже видно самое характерное отличие между разными версиями (черный - мобилка, белый - веб) - например, в приложении отображается число откликов на вакансию, а в вебе нет. Если это недосмотр, то это плохо, поскольку выдавливает пользователей с веб-версии и запускает цикл ухудшения - меньше пользователей порождает меньший приоритет и в итоге меньше ресурсов на развитие и стагнация это канала работы с сервисом.
Второй пример появился в процессе оформления полусотни накладных на посылки через СДЭК. И тут на первом месте неконсистентность данных - если взять адрес пункта доставки из их же справочника и ввести его в их же поиск адресов, то ничего не будет найдено. Сервис выводит адреса в том формате, который они же сами и не понимают. Скриншот это не передает в полной мере, но если ввести короткий адрес из правой колонки в поиск, то найти его он не сможет. Другая неконсистентность - функциональная, когда вводишь много накладных, то ожидаешь, что после оформления одного заказа, ты сможешь перейти к оформлению следующего. СДЭК же завершает цикл работы с заказом кнопкой "Оформить заказ" после которой ты никуда не переходишь и второе нажатие кнопки вызывает либо создание дубликата заказа, либо ошибку (там вообще что-то непредсказуемое). А вот чтобы создать следующий заказ надо (неожиданно) нажать кнопку "Вернуться к оформлению" и создание нового происходит через редактирование данных предыдущего заказа. И это всё плохо, тем что пользователь должен привыкать к очень неочевидным паттернам работы с сервисам, должен тратить больше времени на выполнение операций.
Что такое консистентность? Как пишут, ссылаясь на Кэмбриджский словарь, - это качество быть одинаковым, последовательным, согласованным. Про консистентность часто говорят применительно к данным, интерфейсам и пользовательскому опыту. Но его можно рассматривать и как свойство продукта в целом, которое обеспечивает согласованность, целостность, последовательность и непротиворечивость этого продукта.
Это свойство хорошо тем, что консистентный продукт продукт упрощает и ускоряет работу пользователя с ним, снижает когнитивную нагрузку, позволяет быстрее пройти кривую обучения и принять нужные шаблоны работы с продуктом.
В чем же проявляется неконсистентность продукта и чем она плоха? Я приведу пару примеров, а вы возможно дополните меня.
Первым примером будет HH. В сервисе явно видна функциональная неконсистентность между мобильным приложением и веб сервисом для соискателей. Возможно это осознанная стратегия в условиях ограниченных ресурсов, а возможно просто недосмотр продактов HH, но в любом случае видно, что приоритет отдается мобильному приложению, тогда как веб-версия просто остановилась в развитии. На скриншоте ниже видно самое характерное отличие между разными версиями (черный - мобилка, белый - веб) - например, в приложении отображается число откликов на вакансию, а в вебе нет. Если это недосмотр, то это плохо, поскольку выдавливает пользователей с веб-версии и запускает цикл ухудшения - меньше пользователей порождает меньший приоритет и в итоге меньше ресурсов на развитие и стагнация это канала работы с сервисом.
Второй пример появился в процессе оформления полусотни накладных на посылки через СДЭК. И тут на первом месте неконсистентность данных - если взять адрес пункта доставки из их же справочника и ввести его в их же поиск адресов, то ничего не будет найдено. Сервис выводит адреса в том формате, который они же сами и не понимают. Скриншот это не передает в полной мере, но если ввести короткий адрес из правой колонки в поиск, то найти его он не сможет. Другая неконсистентность - функциональная, когда вводишь много накладных, то ожидаешь, что после оформления одного заказа, ты сможешь перейти к оформлению следующего. СДЭК же завершает цикл работы с заказом кнопкой "Оформить заказ" после которой ты никуда не переходишь и второе нажатие кнопки вызывает либо создание дубликата заказа, либо ошибку (там вообще что-то непредсказуемое). А вот чтобы создать следующий заказ надо (неожиданно) нажать кнопку "Вернуться к оформлению" и создание нового происходит через редактирование данных предыдущего заказа. И это всё плохо, тем что пользователь должен привыкать к очень неочевидным паттернам работы с сервисам, должен тратить больше времени на выполнение операций.
Сегодня хочу рассказать, как превратить легаси продукт с проектным внедрением в SaaS сервис.
В паре компаний я уже превращал SaaS в он-прем продукт и делал SaaS из облачного сервиса. Сейчас же задача превратить достаточно сложную он-прем платформу в SaaS сервис по подписке и хочу подвести некоторые промежуточные итоги.
Опишу исходное состояние продукта - платформа-монолит, обвешанная микросервисами, обязательные интеграции с внешними системами на стороне клиентов, вся работа по развертыванию в он-прем или облако выполняется проектным офисом, последующая заточку функций и наполнение платформы данными под клиента тоже делает проектный офис, в общем степень унификации крайне мала, а доля ручных работ крайне велика. Помимо этого, данные в платформе относятся к одну из видов тайн, защищённых законом, и опять же по требованиям законов есть даже аппаратная составляющая - криптошлюзы для защиты коммуникаций с клиентами. Ещё один аспект, который надо учесть, что сопровождение клиента после внедрения продукта практически не ведётся - обновление платформы это обязанность клиента и как результат - зоопарк не особо совместимых версий.
И вот все это хозяйство надо превратить в SaaS. Зачем это делать, я пропущу, это тема для отдельного поста.
Считаем, что предварительную работу продакта мы провели - провели анализ рынка, собрали информацию по конкурентам в части SaaS, сделали гипотезы по ценообразованию и портрету целевого клиента. Потом само собой защита концепта новой версии продукта перед руководством. Если требуется согласовать с топами, то в идеале, вы сами без посредников должны представлять концепт топам.
А дальше начинается самое интересное, ведь мы в корпорации, где все как муравьи специализированны и каждый аспект нового продукта и каждый шаг нам нужно согласовать с соответствующим направлением.
Выделю главные блоки работ после согласования концепта:
1. Надо четко определить критерии, что для нас SaaS, а что не SaaS (некоторые называют это контуры продукта, но честно говоря, это термин из управления проектами, а не продуктом). Критерии позволят понять на базе чего мы будем делать в продукте унификацию и стандартизацию данных и функций. Наша цель полностью исключить проектные работы по кастомизации, поэтому мы ищем какие блоки кастомных настроек скрыть за базовыми предустановками, а какие за настройками клиентского UI. Помимо этого, критерии позволят вести аргументированный разговор с руководством, видение которого будет сопротивляться изменениям (возможно и неосознанно) и которое будет пытаться вернуть нас к исходному комбайну.
2. Следующий шаг - это определиться с базовой архитектурой продукта. Под SaaS стереотипно понимают одну инсталляцию продукта, с которой работают все клиенты, но на самом деле это не имеет никакого отношения к SaaS. SaaS, это в первую очередь бизнес модель предоставления сервиса по подписке, а техническая архитектура отделена от бизнес модели. Может быть, как описано выше, одна инсталляция для всех с разделением на уровне клиентских данных (это называют multi-tenant) и может быть по одной инсталляции продукта для каждого клиента или single-tenant. В этом случае клиенты полностью изолированы друг от друга, но такая архитектура сильно усложняет вопросы связанные с развертыванием, обновлением и мониторингом, хотя чего не сделаешь ради безопасности данных клиентов.
1/3
В паре компаний я уже превращал SaaS в он-прем продукт и делал SaaS из облачного сервиса. Сейчас же задача превратить достаточно сложную он-прем платформу в SaaS сервис по подписке и хочу подвести некоторые промежуточные итоги.
Опишу исходное состояние продукта - платформа-монолит, обвешанная микросервисами, обязательные интеграции с внешними системами на стороне клиентов, вся работа по развертыванию в он-прем или облако выполняется проектным офисом, последующая заточку функций и наполнение платформы данными под клиента тоже делает проектный офис, в общем степень унификации крайне мала, а доля ручных работ крайне велика. Помимо этого, данные в платформе относятся к одну из видов тайн, защищённых законом, и опять же по требованиям законов есть даже аппаратная составляющая - криптошлюзы для защиты коммуникаций с клиентами. Ещё один аспект, который надо учесть, что сопровождение клиента после внедрения продукта практически не ведётся - обновление платформы это обязанность клиента и как результат - зоопарк не особо совместимых версий.
И вот все это хозяйство надо превратить в SaaS. Зачем это делать, я пропущу, это тема для отдельного поста.
Считаем, что предварительную работу продакта мы провели - провели анализ рынка, собрали информацию по конкурентам в части SaaS, сделали гипотезы по ценообразованию и портрету целевого клиента. Потом само собой защита концепта новой версии продукта перед руководством. Если требуется согласовать с топами, то в идеале, вы сами без посредников должны представлять концепт топам.
А дальше начинается самое интересное, ведь мы в корпорации, где все как муравьи специализированны и каждый аспект нового продукта и каждый шаг нам нужно согласовать с соответствующим направлением.
Выделю главные блоки работ после согласования концепта:
1. Надо четко определить критерии, что для нас SaaS, а что не SaaS (некоторые называют это контуры продукта, но честно говоря, это термин из управления проектами, а не продуктом). Критерии позволят понять на базе чего мы будем делать в продукте унификацию и стандартизацию данных и функций. Наша цель полностью исключить проектные работы по кастомизации, поэтому мы ищем какие блоки кастомных настроек скрыть за базовыми предустановками, а какие за настройками клиентского UI. Помимо этого, критерии позволят вести аргументированный разговор с руководством, видение которого будет сопротивляться изменениям (возможно и неосознанно) и которое будет пытаться вернуть нас к исходному комбайну.
2. Следующий шаг - это определиться с базовой архитектурой продукта. Под SaaS стереотипно понимают одну инсталляцию продукта, с которой работают все клиенты, но на самом деле это не имеет никакого отношения к SaaS. SaaS, это в первую очередь бизнес модель предоставления сервиса по подписке, а техническая архитектура отделена от бизнес модели. Может быть, как описано выше, одна инсталляция для всех с разделением на уровне клиентских данных (это называют multi-tenant) и может быть по одной инсталляции продукта для каждого клиента или single-tenant. В этом случае клиенты полностью изолированы друг от друга, но такая архитектура сильно усложняет вопросы связанные с развертыванием, обновлением и мониторингом, хотя чего не сделаешь ради безопасности данных клиентов.
1/3
3. Следующий блок - это собственно сама безопасность. Поскольку у нас цель разместить продукт в публичном облаке, при этом в продукте есть обработка персональных данных и других видов тайн, требующая определенного уровня защищённости, то сваливать все это на безопасников совсем неправильно. Именно продакту стоит посмотреть влияние функций продукта на безопасность - выключение ряда функций может радикально повысить безопасность, не влияя на общую функциональность продукта. Также необходимо проверить, какие операции с продуктом не покрыты его собственными функциями или настройками. Например, в нашем случае, проектная кастомизация частично делалась через прямые операции с базой данных. Соответственно такое надо или превращать в UI или выносить в предустановки сервиса.
Также стоит проверить все интеграции с другими системами - они тоже должны быть покрыты требованиями к безопасности, а безопасники порой про эти нюансы забывают.
4. Далее стоит заняться бизнес-процессами. Нужно покрыть бизнес-процессами весь путь клиента через продукт - от заявки клиента, через пресейл, поставку продукта, его эксплуатацию, развитие продукта до вывода из эксплуатации и завершения работы с клиентом. В моем случае получилось более 90 отдельных под-процессов, отражающих специфику продукта и работы с ним. Не стоит ожидать, что получится просто работать в рамках уже существующих процессов в компании. Например, в моем случае существующие процессы в компании никак не были описаны, большую часть нужных процессов нужно строить в рамках продуктовой команды с нуля и с новыми штатными единицами. А это дополнительный бюджет и организационные изменения. Также все бизнес-процессы, выходящие за периметр продуктовой команды, нужно согласовать с руководством соответствующих функций, поскольку им тоже может потребоваться дополнительный штат для работы с вами и эти затраты стоит учитывать в общем бюджете продукта.
6. Поскольку одной из целей превращения продукта в SaaS было исключение проектных работ, то следующим шагом беремся за них. Для тех кто не в теме, поясню - проектные работы это не про проектирование, а отдельный проект по кастомизации платформы, включающий проектирование, создание архитектуры, разработку, devops операции и еще десятки других работ. Источником нужной информации будут паспорта выполненных проектов, типовые оценки проектных работ. Необходимо выделить те операции и данные, которые мы хотим стандартизировать. Например, если в рамках проектных работ под каждого клиента писалось отдельное ТЗ, то в рамках SaaS достаточно одного типового описания функций продукта. Определенные справочники информации или информационные модели в продукте начинают прекрасно унифицироваться в рамках заданных нами критериев SaaS, хотя до этого это могла быть объемная и дорогостоящая проектная работа. Завершив анализ проектных работ, мы получим перечень однократных операций по унификации, которые нам нужно будет выполнить до запуска продукта, чтобы уложить его в наши критерии к SaaS, перечень функций продукта, которые надо исключить в SaaS версии, а также перечень новых артефактов и документов, которые потребуются при взаимодействии с клиентом.
7. После прохождения перечисленных этапов можно отдавать все в техническую проработку архитектору, а самому стоит взяться за создание лицензионной политики. К этому этапу мы уже обогащены знаниями по всем требуемым расходам на запуск и эксплуатацию продукта и поэтому можем отталкиваться от них в расчетах ценообразования. Можно сравнить с теми гипотезами, что мы ранее писали в обосновании запуска SaaS и удивиться насколько мы заблуждались.
8. Наконец финальный этап работы продакта - подготовить материалы для пресейла и маркетинга - презентации, информация для лендинга, пресс-релиза по запуску, описания функций, лицензионной политики, схем выбора типовых сайзингов и т.д. и т.п. В идеале, все что требует расчетов, типа, стоимости лицензий, сайзингов, остатка проектных работ (с ходу на 100% от них вряд ли получится избавиться) должно быть покрыто калькуляторами.
2/3
Также стоит проверить все интеграции с другими системами - они тоже должны быть покрыты требованиями к безопасности, а безопасники порой про эти нюансы забывают.
4. Далее стоит заняться бизнес-процессами. Нужно покрыть бизнес-процессами весь путь клиента через продукт - от заявки клиента, через пресейл, поставку продукта, его эксплуатацию, развитие продукта до вывода из эксплуатации и завершения работы с клиентом. В моем случае получилось более 90 отдельных под-процессов, отражающих специфику продукта и работы с ним. Не стоит ожидать, что получится просто работать в рамках уже существующих процессов в компании. Например, в моем случае существующие процессы в компании никак не были описаны, большую часть нужных процессов нужно строить в рамках продуктовой команды с нуля и с новыми штатными единицами. А это дополнительный бюджет и организационные изменения. Также все бизнес-процессы, выходящие за периметр продуктовой команды, нужно согласовать с руководством соответствующих функций, поскольку им тоже может потребоваться дополнительный штат для работы с вами и эти затраты стоит учитывать в общем бюджете продукта.
6. Поскольку одной из целей превращения продукта в SaaS было исключение проектных работ, то следующим шагом беремся за них. Для тех кто не в теме, поясню - проектные работы это не про проектирование, а отдельный проект по кастомизации платформы, включающий проектирование, создание архитектуры, разработку, devops операции и еще десятки других работ. Источником нужной информации будут паспорта выполненных проектов, типовые оценки проектных работ. Необходимо выделить те операции и данные, которые мы хотим стандартизировать. Например, если в рамках проектных работ под каждого клиента писалось отдельное ТЗ, то в рамках SaaS достаточно одного типового описания функций продукта. Определенные справочники информации или информационные модели в продукте начинают прекрасно унифицироваться в рамках заданных нами критериев SaaS, хотя до этого это могла быть объемная и дорогостоящая проектная работа. Завершив анализ проектных работ, мы получим перечень однократных операций по унификации, которые нам нужно будет выполнить до запуска продукта, чтобы уложить его в наши критерии к SaaS, перечень функций продукта, которые надо исключить в SaaS версии, а также перечень новых артефактов и документов, которые потребуются при взаимодействии с клиентом.
7. После прохождения перечисленных этапов можно отдавать все в техническую проработку архитектору, а самому стоит взяться за создание лицензионной политики. К этому этапу мы уже обогащены знаниями по всем требуемым расходам на запуск и эксплуатацию продукта и поэтому можем отталкиваться от них в расчетах ценообразования. Можно сравнить с теми гипотезами, что мы ранее писали в обосновании запуска SaaS и удивиться насколько мы заблуждались.
8. Наконец финальный этап работы продакта - подготовить материалы для пресейла и маркетинга - презентации, информация для лендинга, пресс-релиза по запуску, описания функций, лицензионной политики, схем выбора типовых сайзингов и т.д. и т.п. В идеале, все что требует расчетов, типа, стоимости лицензий, сайзингов, остатка проектных работ (с ходу на 100% от них вряд ли получится избавиться) должно быть покрыто калькуляторами.
2/3
По завершении этой эпопеи, стоит под своим надзором провести первых клиентов через все этапы пресейла и запуска продукта. И собственно только в этот момент начнется регулярная работа продакта по развитию продукта - валидировать гипотезы по ценообразованию и набору функций, собирать обратную связь с клиентов, корректировать продуктовую стратегию, создать родмеп для дальнейшего развития продукта на основе выявленных недочетов, но об этом как-нибудь в другой раз.
3/3
3/3
Как профессионально делать заметки о встречах
Буду краток.
1. Фиксируем кто был на встрече - имя, фамилия, если были внешние компании, то компания и если есть должность
2. Фиксируем дату встречи
Когда пишем кем-то сказанное, то фиксируем кто именно это сказал
3. Фиксируем договоренности в формате - дата начала работ, дата окончания работ, предполагаемые действия, кто исполнитель, кто ответственный
Если есть привычка, то это можно делать в электронном виде - по документу на повторяющиеся встречи. Но мне обычно хватает ежедневника, привычка работы с бумагой и можно писать когда сам делаешь презентацию на встрече и шаришь свой экран.
Но электронное конечно удобней с точки зрения поиска и более жёстко можно задать структуру.
Вот такие 3 простых правила, которые позволят вам держать все под контролем.
Буду краток.
1. Фиксируем кто был на встрече - имя, фамилия, если были внешние компании, то компания и если есть должность
2. Фиксируем дату встречи
Когда пишем кем-то сказанное, то фиксируем кто именно это сказал
3. Фиксируем договоренности в формате - дата начала работ, дата окончания работ, предполагаемые действия, кто исполнитель, кто ответственный
Если есть привычка, то это можно делать в электронном виде - по документу на повторяющиеся встречи. Но мне обычно хватает ежедневника, привычка работы с бумагой и можно писать когда сам делаешь презентацию на встрече и шаришь свой экран.
Но электронное конечно удобней с точки зрения поиска и более жёстко можно задать структуру.
Вот такие 3 простых правила, которые позволят вам держать все под контролем.
Мой хороший друг рассказывает у себя в канале, как он создал и продал бесплатный Productivity сервис. В его канале его можно попытать на тему, как же он нашел покупателя и другие вопросы по развитию продуктов.
https://yangx.top/dobrych/70
https://yangx.top/dobrych/70
Telegram
Добрый канал
Произошло локальное историческое событие — буквально на днях мы закрыли сделку по продаже VSpace 💸
Продукт, с которого началась наша большая история: амбиция на первую в мире Cloud OS, попытки привлечь зарубежный венчур, поездки в Сколково, разочарование…
Продукт, с которого началась наша большая история: амбиция на первую в мире Cloud OS, попытки привлечь зарубежный венчур, поездки в Сколково, разочарование…
Обожаю составлять списки, поэтому вот вам список бесплатных видео курсов и лекций по управлению продуктами на русском, которые есть на Youtube
1️⃣ Курс Product management (2021) от VK Team
2️⃣ Канал с лекциями по управлению проектами и продуктом от Академии Яндекса
3️⃣ Курс Product management от акселератора Цифра
4️⃣ Product Manager IT проектов от OTUS
5️⃣ Курс Создание программного продукта и управление его развитием от Acronis (ссылка на первую лекцию, текстовую расшифровку курса также можно найти на Habr)
6️⃣ Курс Менеджмент разработки ПО
7️⃣ Курс по Jobs to be Done от Tilda
8️⃣ Сборник лекций по Product Management от LeadStartup (на оригинальном канале они раскиданы по разным плейлистам)
1️⃣ Курс Product management (2021) от VK Team
2️⃣ Канал с лекциями по управлению проектами и продуктом от Академии Яндекса
3️⃣ Курс Product management от акселератора Цифра
4️⃣ Product Manager IT проектов от OTUS
5️⃣ Курс Создание программного продукта и управление его развитием от Acronis (ссылка на первую лекцию, текстовую расшифровку курса также можно найти на Habr)
6️⃣ Курс Менеджмент разработки ПО
7️⃣ Курс по Jobs to be Done от Tilda
8️⃣ Сборник лекций по Product Management от LeadStartup (на оригинальном канале они раскиданы по разным плейлистам)
Хоть я и не фанат Стива Джобса, как один из моих бывших руководителей - у него даже портрет Джобса на стене висел, но всегда интересно заглянуть в мыслительные процессы и изнанку ежедневной работы столь неординарного человека.
Поэтому я и прочитал практически все книги о Джобсе, среди которых была одна странная книжка про то, как он писал емейлы. Автор книжки просто собрал в интернете все истории про то, когда Джобс сам отвечал на письма в Apple от клиентов и журналистов и что он при этом ответил. Например, ответ на письмо одного назойливого фаната был всего из пары слов - "Fuck off" :)
И вот вчера увидел новость, что проект "Архив Стива Джобса" опубликовал целую книгу "Make something wonderful", составленную из емейлов, выступлений и интервью Джобса. Кажется, что эта книга будет более информативной относительно стиля работы и общения Джобса, чем указанная выше странная книжка.
Книгу, опубликованную архивом, можно бесплатно скачать на сайте архива в epub или почитать там же онлайн - https://stevejobsarchive.com/book
Поэтому я и прочитал практически все книги о Джобсе, среди которых была одна странная книжка про то, как он писал емейлы. Автор книжки просто собрал в интернете все истории про то, когда Джобс сам отвечал на письма в Apple от клиентов и журналистов и что он при этом ответил. Например, ответ на письмо одного назойливого фаната был всего из пары слов - "Fuck off" :)
И вот вчера увидел новость, что проект "Архив Стива Джобса" опубликовал целую книгу "Make something wonderful", составленную из емейлов, выступлений и интервью Джобса. Кажется, что эта книга будет более информативной относительно стиля работы и общения Джобса, чем указанная выше странная книжка.
Книгу, опубликованную архивом, можно бесплатно скачать на сайте архива в epub или почитать там же онлайн - https://stevejobsarchive.com/book
Steve Jobs Archive
Make Something Wonderful | Book | Steve Jobs Archive
Read Make Something Wonderful, a curated collection of speeches, correspondence, and photographs from Steve Jobs revealing his approach to life and work with Apple and Pixar.
Делаю очередную игру в качестве хобби и глубоко прочувствовал, что значит настоящая итеративная разработка.
В этот раз, я решил обойтись без исчерпывающего геймдизайн документа (аналог PRD в разработке игр). То есть неопределенность полная, все по заветам Agile, где каждое следующее действие должно эту самую неопределенность уменьшать. Поэтому все идеи по фичам кидаю в бэклог, при этом идеи прямо на глазах трансформируются - становятся неактуальными, отклоняются из-за слишком длительной реализации, расщепляются на подзадачи, сливаются из нескольких в одну. Очень живой бэклог получился и столь же органично идёт его сортировка - более понятные и конечные задачи сами всплывают к верху. Анализ результатов идёт непрерывно и параллельно самой разработке и корректировки в бэклог делаются на основе этого анализа, всё как в каноне. Как такового спринта у меня в соло разработке конечно нет, можно сказать что спринт однодневный, поскольку каждый день я стараюсь принести ценность проекту, при этом сохраняя его целостность (см. Принцип jpg)
В чем же мораль? А мораль простая. Хоть я уже 15 лет работаю по Scrum и в парадигме Agile, но впервые это получилось настолько органично и полно по сравнению с коммерческой разработкой внутри компаний. А что мешает компаниям делать так же, пожалуй напишу в следующий раз.
В этот раз, я решил обойтись без исчерпывающего геймдизайн документа (аналог PRD в разработке игр). То есть неопределенность полная, все по заветам Agile, где каждое следующее действие должно эту самую неопределенность уменьшать. Поэтому все идеи по фичам кидаю в бэклог, при этом идеи прямо на глазах трансформируются - становятся неактуальными, отклоняются из-за слишком длительной реализации, расщепляются на подзадачи, сливаются из нескольких в одну. Очень живой бэклог получился и столь же органично идёт его сортировка - более понятные и конечные задачи сами всплывают к верху. Анализ результатов идёт непрерывно и параллельно самой разработке и корректировки в бэклог делаются на основе этого анализа, всё как в каноне. Как такового спринта у меня в соло разработке конечно нет, можно сказать что спринт однодневный, поскольку каждый день я стараюсь принести ценность проекту, при этом сохраняя его целостность (см. Принцип jpg)
В чем же мораль? А мораль простая. Хоть я уже 15 лет работаю по Scrum и в парадигме Agile, но впервые это получилось настолько органично и полно по сравнению с коммерческой разработкой внутри компаний. А что мешает компаниям делать так же, пожалуй напишу в следующий раз.
This media is not supported in your browser
VIEW IN TELEGRAM
Собственно пара кадров из игрушки
Как неоднократно писал у себя на канале, мне интересно пробовать новое - новые направления, продукты, способы продвижения, механики и так далее. В прошлом году я попробовал и сделал голосовой навык для тренировки собеседований, запустил онлайн курс по поиску работы и улучшению резюме, в этом году попробовал краудфандинг и делаю мобильную игру.
И вот в качестве тестирования нового - хочу попробовать себя в менторинге. За плечами у меня довольно обширный опыт консультирования в сфере маркетинговых стратегий и планов, был трекером стартапов, прорабатывал идеи новых продуктов от замысла до бизнес-плана и GTM стратегии, давал рекомендации по улучшению резюме специалистам в разных областях, преподавал на курсах и сам их писал. Так что кажется, что и в менторинге я тоже смогу быть полезным.
История для меня как обычно некоммерческая, хочу более глубоко изучить этот инструмент, его возможности и ограничения. Поэтому первым записавшимся - услуга будет полностью бесплатна. Темы для менторства обозначены в моем профиле на https://getmentor.dev/mentor/dmitriy-vostrecov-1798, в целом мне более интересно пообщаться на тему SaaS сервисов и продуктов на их основе, но в целом можем поговорить на тему любых других продуктов, карьеры и поиска работы (как минимум не сделаете тех ошибок, что я). Записывайтесь через сервис GetMentor, хотя можете и просто в личку написать.
И вот в качестве тестирования нового - хочу попробовать себя в менторинге. За плечами у меня довольно обширный опыт консультирования в сфере маркетинговых стратегий и планов, был трекером стартапов, прорабатывал идеи новых продуктов от замысла до бизнес-плана и GTM стратегии, давал рекомендации по улучшению резюме специалистам в разных областях, преподавал на курсах и сам их писал. Так что кажется, что и в менторинге я тоже смогу быть полезным.
История для меня как обычно некоммерческая, хочу более глубоко изучить этот инструмент, его возможности и ограничения. Поэтому первым записавшимся - услуга будет полностью бесплатна. Темы для менторства обозначены в моем профиле на https://getmentor.dev/mentor/dmitriy-vostrecov-1798, в целом мне более интересно пообщаться на тему SaaS сервисов и продуктов на их основе, но в целом можем поговорить на тему любых других продуктов, карьеры и поиска работы (как минимум не сделаете тех ошибок, что я). Записывайтесь через сервис GetMentor, хотя можете и просто в личку написать.
https://getmentor.dev
Дмитрий Вострецов | GetMentor – открытое сообщество IT-наставников
Product Manager @ VK | GetMentor – это открытое комьюнити IT-наставников, готовых делиться своими опытом и знаниями. Наша задача – помогать людям находить ответы на свои вопросы в работе или жизни через прямой доступ к экспертизе в разговоре 1-на-1.
В моей эхо-камере только и разговоров, что о ChatGPT. Подкину немного, поскольку сам начинаю все чаще его использовать. Ранее я уже писал, как подключиться к основному сервису, но для коротких запросов, не подразумевающих диалога, я использую один из бесплатных ботов в Телеграме - 30 запросов в сутки вполне достаточно для моих текущих задач.
Хочу поделиться, какие запросы и правила их построения я чаще всего использую.
1. Структурирование ответа - в запросе мы сразу задаем структуру ответа, который хотим получить.
Придумай несколько идей для статьи в блоге о ретро автомобилях. Используй этот формат:
[краткое изложение идеи]
[название и подзаголовок для длинного поста в блоге, основанного на этой идее]
[название и подзаголовок для поста блоге в виде списка, основанного на этой идее]
[возможная целевая аудитория для этой идеи за пределами сообщества]
Можно управлять форматом ответа - разбей результат на абзацы, он должен легко и быстро читаться, оформи в виде нумерованного списка, оформи в виде таблицы с заголовоками "А", "В" и т.д.
Можно накладывать ограничения "
2. Ролевые запросы - в запросе предлагаем языковой модели представить от чьего имени она будет давать ответ. Это не обязательно может быть человек или профессия (продакт менеджер, юрист, Instagram блогер), это может быть и какая-то система (Linux терминал, база данных SQL).
Представь, что ты продакт менеджер B2B SaaS сервиса для "...". Опиши, как бы ты его улучшил.
Или, Напиши текст по теме "..." в стиле юриста.
3. Генерация инструкций
Напиши, как пользоваться плагином "..." для Figma. Основные функции, особенности работы, как установить.
4. Создание заголовков
Придумай [количество] [характеристика стиля] заголовков для сценария видео на Youtube по [теме] [используя сильные слова вызывающие эмоции] [содержащие числа или данные] - всё, что в скобках можно менять под свои требования.
5. Обучение
Объясни детально, понятно, как будто мне 5 лет, без использования маркетинговой лексики, с примерами, как Илон Маск, студентов университета.
Опиши ежедневный план обучения по теме "..." на 2 недели.
6. Работа продакт менеджера
Опиши функции типовго сервиса/приложения для "..."
Каких функций не хватает сервису/приложению "..."
Опиши PRD для сервиса/функции "..."
Опиши типичного пользователя сервиса "..." Укажи какие у них стимулы, барьеры и возражения. Что должна учитывать маркетинговая кампания для их привлечения. Какие функции сервиса им потребуются.
7. При работе с ChatGPT через их сайт в режиме диалога самая полезная функция - это уточние деталей и просьба развернуть ответ:
Опиши пункт Х подробнее с деталями и количественными данными.
Для пункта Х приведи 3 примера.
А вы как часто используете ChatGPT?
Хочу поделиться, какие запросы и правила их построения я чаще всего использую.
1. Структурирование ответа - в запросе мы сразу задаем структуру ответа, который хотим получить.
Придумай несколько идей для статьи в блоге о ретро автомобилях. Используй этот формат:
[краткое изложение идеи]
[название и подзаголовок для длинного поста в блоге, основанного на этой идее]
[название и подзаголовок для поста блоге в виде списка, основанного на этой идее]
[возможная целевая аудитория для этой идеи за пределами сообщества]
Можно управлять форматом ответа - разбей результат на абзацы, он должен легко и быстро читаться, оформи в виде нумерованного списка, оформи в виде таблицы с заголовоками "А", "В" и т.д.
Можно накладывать ограничения "
2. Ролевые запросы - в запросе предлагаем языковой модели представить от чьего имени она будет давать ответ. Это не обязательно может быть человек или профессия (продакт менеджер, юрист, Instagram блогер), это может быть и какая-то система (Linux терминал, база данных SQL).
Представь, что ты продакт менеджер B2B SaaS сервиса для "...". Опиши, как бы ты его улучшил.
Или, Напиши текст по теме "..." в стиле юриста.
3. Генерация инструкций
Напиши, как пользоваться плагином "..." для Figma. Основные функции, особенности работы, как установить.
4. Создание заголовков
Придумай [количество] [характеристика стиля] заголовков для сценария видео на Youtube по [теме] [используя сильные слова вызывающие эмоции] [содержащие числа или данные] - всё, что в скобках можно менять под свои требования.
5. Обучение
Объясни детально, понятно, как будто мне 5 лет, без использования маркетинговой лексики, с примерами, как Илон Маск, студентов университета.
Опиши ежедневный план обучения по теме "..." на 2 недели.
6. Работа продакт менеджера
Опиши функции типовго сервиса/приложения для "..."
Каких функций не хватает сервису/приложению "..."
Опиши PRD для сервиса/функции "..."
Опиши типичного пользователя сервиса "..." Укажи какие у них стимулы, барьеры и возражения. Что должна учитывать маркетинговая кампания для их привлечения. Какие функции сервиса им потребуются.
7. При работе с ChatGPT через их сайт в режиме диалога самая полезная функция - это уточние деталей и просьба развернуть ответ:
Опиши пункт Х подробнее с деталями и количественными данными.
Для пункта Х приведи 3 примера.
А вы как часто используете ChatGPT?
Аскар Рахимбердиев из МойСклад выпустил свой ежегодный неофициальный рейтинг российских SaaS сервисов, который я свел для наглядности в таблицу.
Рейтинг основан на данных по годовой выручке из финансовой отчетности за 2022 год и некоторых инсайдерских данных. В него входят компании с годовой выручкой на российском рынке не менее 100 млн. За 2022 год участники рейтинга в среднем выросли на 41%, что очень неплохо для кризисного года. Средняя рентабельность 18%, что кажется вполне здоровым показателем.
Остальные пояснения по рейтингу можно посмотреть в публикации Аскара https://www.facebook.com/arahimberdiev/posts/10231033060315801
Рейтинг основан на данных по годовой выручке из финансовой отчетности за 2022 год и некоторых инсайдерских данных. В него входят компании с годовой выручкой на российском рынке не менее 100 млн. За 2022 год участники рейтинга в среднем выросли на 41%, что очень неплохо для кризисного года. Средняя рентабельность 18%, что кажется вполне здоровым показателем.
Остальные пояснения по рейтингу можно посмотреть в публикации Аскара https://www.facebook.com/arahimberdiev/posts/10231033060315801
Инструкция для человека
Знакомая подарила детям шуточные "Инструкции по использованию человека" - бланк, где заполняешь данные о себе. Темперамент, положительные и отрицательные стороны характера, что лучше всего умеешь, что не получается и так далее, получается такая концентрированная само-характеристика на человека.
И я подумал, а почему подобный инструмент не используют в рабочих отношениях. Учитывая довольно низкий уровень менеджерской культуры в стране, когда руководителям трудно найти подход к своим сотрудниками и понять их мотивацию, кажется что информация о свойствах характера, честная информация о сильных и слабых сторонах сотрудника, могла бы им помочь быстрее адаптировать новых сотрудников и управлять своими подчиненными лучше. Да, есть куча тестов различного вида, но насколько я видел никто их системно не использует в реальной работе и зачастую их результаты не передаются руководителю. Резюме тоже не может быть заменой такому инструменту, поскольку резюме показывает приукрашенный образ человека, а кроме того, сейчас не принято описывать в резюме свои софт-скиллы.
Просматривая один из курсов по управлению удаленной командой, я отметил интересную технику, которая наиболее близка к идее об инструкции для человека, хотя тут она сводится к роли, а не конкретному человеку. Эта техника называется "Транспарант". Техника полезна когда в команде появляется новый человек или нужно прояснить цели и роли существующих членов команды.
Техника "Транспарант" выполняется в 3 шага:
1. Каждый участник команды готовит "транспарант" с описанием своей роли в команде, например в Miro или на листке бумаге, если все в офисе.
На транспаранте пишется
- название роли
- главная цель, которой служит эта роль
- 2-3 главных задачи
- ключевые обещания этой роли другим ролям в команде, клиентам, другим подразделениям в компании
2. Когда все транспаранты готовы, то каждый член команды смотрит на чужие транспаранты и дописывает на них свои ожидания в виде - "я жду от тебя, что ты ..."
3. Когда все ожидания написаны, устраивается обсуждение. Может оказаться, что транспаранты части ролей переполнены дополнительными ожиданиями, а у части не добавилось ни одного ожидания. Обе эти ситуации требуют прояснения.
В первом случае, кажется что автор транспаранта выполняет функции сверх своих рабочих функций, возможно против своего желания. В этом случае руководитель должен синхронизировать всех членов команды и возможно назначить других ответственных за обозначенные ожидания и их результат.
Во втором же случае, может оказаться, что по какой-то причине члены команды не обращаются к этой роли с какими-то запросами сверх рабочих, а возможно стараются не обращаться и по рабочим вопросам, например, из-за токсичности человека или низкого качества работы или иной причине.
Кажется, что данную технику можно масштабировать также и на уровень межкомандного взаимодействия в компании и даже на уровень общения с клиентами и партнерами. Например, похожую методику, называемую "Обещания" использует ВкусВилл - на их сайте можно ознакомиться с Кодексом, где зафиксированы обещания всех ролей в компании перед клиентами и компанией.
Если бы я знал о технике "Транспарант" раньше, то попробовал бы применить её, поскольку она на мой взгляд позволяет быстрее влиться в новый коллектив, понять цели и задачи команды, зафиксировать их для будущих сотрудников.
А у вас в компании используется ли какая-нибудь техника для синхронизации команды и ускорения адаптации новых членов команды?
Знакомая подарила детям шуточные "Инструкции по использованию человека" - бланк, где заполняешь данные о себе. Темперамент, положительные и отрицательные стороны характера, что лучше всего умеешь, что не получается и так далее, получается такая концентрированная само-характеристика на человека.
И я подумал, а почему подобный инструмент не используют в рабочих отношениях. Учитывая довольно низкий уровень менеджерской культуры в стране, когда руководителям трудно найти подход к своим сотрудниками и понять их мотивацию, кажется что информация о свойствах характера, честная информация о сильных и слабых сторонах сотрудника, могла бы им помочь быстрее адаптировать новых сотрудников и управлять своими подчиненными лучше. Да, есть куча тестов различного вида, но насколько я видел никто их системно не использует в реальной работе и зачастую их результаты не передаются руководителю. Резюме тоже не может быть заменой такому инструменту, поскольку резюме показывает приукрашенный образ человека, а кроме того, сейчас не принято описывать в резюме свои софт-скиллы.
Просматривая один из курсов по управлению удаленной командой, я отметил интересную технику, которая наиболее близка к идее об инструкции для человека, хотя тут она сводится к роли, а не конкретному человеку. Эта техника называется "Транспарант". Техника полезна когда в команде появляется новый человек или нужно прояснить цели и роли существующих членов команды.
Техника "Транспарант" выполняется в 3 шага:
1. Каждый участник команды готовит "транспарант" с описанием своей роли в команде, например в Miro или на листке бумаге, если все в офисе.
На транспаранте пишется
- название роли
- главная цель, которой служит эта роль
- 2-3 главных задачи
- ключевые обещания этой роли другим ролям в команде, клиентам, другим подразделениям в компании
2. Когда все транспаранты готовы, то каждый член команды смотрит на чужие транспаранты и дописывает на них свои ожидания в виде - "я жду от тебя, что ты ..."
3. Когда все ожидания написаны, устраивается обсуждение. Может оказаться, что транспаранты части ролей переполнены дополнительными ожиданиями, а у части не добавилось ни одного ожидания. Обе эти ситуации требуют прояснения.
В первом случае, кажется что автор транспаранта выполняет функции сверх своих рабочих функций, возможно против своего желания. В этом случае руководитель должен синхронизировать всех членов команды и возможно назначить других ответственных за обозначенные ожидания и их результат.
Во втором же случае, может оказаться, что по какой-то причине члены команды не обращаются к этой роли с какими-то запросами сверх рабочих, а возможно стараются не обращаться и по рабочим вопросам, например, из-за токсичности человека или низкого качества работы или иной причине.
Кажется, что данную технику можно масштабировать также и на уровень межкомандного взаимодействия в компании и даже на уровень общения с клиентами и партнерами. Например, похожую методику, называемую "Обещания" использует ВкусВилл - на их сайте можно ознакомиться с Кодексом, где зафиксированы обещания всех ролей в компании перед клиентами и компанией.
Если бы я знал о технике "Транспарант" раньше, то попробовал бы применить её, поскольку она на мой взгляд позволяет быстрее влиться в новый коллектив, понять цели и задачи команды, зафиксировать их для будущих сотрудников.
А у вас в компании используется ли какая-нибудь техника для синхронизации команды и ускорения адаптации новых членов команды?
Как устроен бизнес тревел сервисов на примере Островка и Booking.com
Волею судеб, я оказался на этот раз в тревел индустрии, поэтому немного порефлексирую на тему этого бизнеса и того, как он работает.
И Островок и Booking.com относятся к так называемым сервисам OTA – Online Travel Agency и весь их бизнес построен на модели маркетплейса – свести вместе владельцев мест размещения (отели, владельцы апартаментов и т.п.) и покупателей. Диапазон покупателей в этом типе маркетплейса достаточно широк – это конечно обычные физические лица, но и достаточно разношерстные b2b клиенты – туроператоры, турагенства, корпоративные заказчики, сервисы онлайн бронирований для бизнеса, агенты и те же самые OTA. При этом надо учесть, что со стороны поставщиков маркетплейса представлены не только прямые владельцы отелей и других объектов, но и промежуточные поставщики – опять те же самые OTA и инвентарные системы, у которых есть прямые договоры с отелями.
В итоге, получается довольно запутанная цепочка перепродажи, где сервисы одного и того же типа могут выступать одновременно как поставщиками, так и покупателями. При этом один и тот же отель может присутствовать одновременно у нескольких поставщиков. Что в свою очередь создает проблемы с контентом маркетплейса. Например, у Островка больше 140 поставщиков и описание одного и того же отеля, номеров в нем и тарифов могут прилететь в систему от нескольких десятков поставщиков и все они могут быть разные. Островку, например, пришлось делать свою систему сборки консистентных описаний номеров, отелей на основе заранее заданных правил и машинного обучения, чтобы у себя на сайте показывать уникальные и непротиворечивые описания.
Другая проблема тревел сервисов – это многочисленные и разнообразные тарифы и схемы тарификаций дополнительных услуг. Полученные от разных поставщиков и самого отеля они так же могут быть разные для одних и тех же объектов. Для этого в Островке сделали систему тегирования, которая каждый тариф размечает набором тегов и это позволяет в итоге делать уникальные срезы и сортировки тарифов – по цене, по надежности поставщика и т.п.
Надежность поставщика – это еще одна проблема индустрии. Так называемый Success Rate бронирования (то есть когда покупатель смог без ошибок забронировать объект) достигает 94% у Expedia (лидер на американском рынке), но может падать до 60% у других поставщиков. Условно говоря 2 из 5 бронирований будут неуспешны, но отказаться от таких поставщиков нельзя, поскольку при всем прочем они дают самые лучшие для покупателей цены.
В результате у OTA сервисов есть специальные системы, которые выстраивают цепочку из поставщиков для одного и того же объекта – сначала пробуем заказать у самого дешевого, но проблемного поставщика, потом идем к тому, кто подороже и так далее, пока не забронируем номер для покупателя.
В следующих заметках расскажу, как запускался и развивался Booking и как устроено взаимодействие тревел сервисов с отелями.
Волею судеб, я оказался на этот раз в тревел индустрии, поэтому немного порефлексирую на тему этого бизнеса и того, как он работает.
И Островок и Booking.com относятся к так называемым сервисам OTA – Online Travel Agency и весь их бизнес построен на модели маркетплейса – свести вместе владельцев мест размещения (отели, владельцы апартаментов и т.п.) и покупателей. Диапазон покупателей в этом типе маркетплейса достаточно широк – это конечно обычные физические лица, но и достаточно разношерстные b2b клиенты – туроператоры, турагенства, корпоративные заказчики, сервисы онлайн бронирований для бизнеса, агенты и те же самые OTA. При этом надо учесть, что со стороны поставщиков маркетплейса представлены не только прямые владельцы отелей и других объектов, но и промежуточные поставщики – опять те же самые OTA и инвентарные системы, у которых есть прямые договоры с отелями.
В итоге, получается довольно запутанная цепочка перепродажи, где сервисы одного и того же типа могут выступать одновременно как поставщиками, так и покупателями. При этом один и тот же отель может присутствовать одновременно у нескольких поставщиков. Что в свою очередь создает проблемы с контентом маркетплейса. Например, у Островка больше 140 поставщиков и описание одного и того же отеля, номеров в нем и тарифов могут прилететь в систему от нескольких десятков поставщиков и все они могут быть разные. Островку, например, пришлось делать свою систему сборки консистентных описаний номеров, отелей на основе заранее заданных правил и машинного обучения, чтобы у себя на сайте показывать уникальные и непротиворечивые описания.
Другая проблема тревел сервисов – это многочисленные и разнообразные тарифы и схемы тарификаций дополнительных услуг. Полученные от разных поставщиков и самого отеля они так же могут быть разные для одних и тех же объектов. Для этого в Островке сделали систему тегирования, которая каждый тариф размечает набором тегов и это позволяет в итоге делать уникальные срезы и сортировки тарифов – по цене, по надежности поставщика и т.п.
Надежность поставщика – это еще одна проблема индустрии. Так называемый Success Rate бронирования (то есть когда покупатель смог без ошибок забронировать объект) достигает 94% у Expedia (лидер на американском рынке), но может падать до 60% у других поставщиков. Условно говоря 2 из 5 бронирований будут неуспешны, но отказаться от таких поставщиков нельзя, поскольку при всем прочем они дают самые лучшие для покупателей цены.
В результате у OTA сервисов есть специальные системы, которые выстраивают цепочку из поставщиков для одного и того же объекта – сначала пробуем заказать у самого дешевого, но проблемного поставщика, потом идем к тому, кто подороже и так далее, пока не забронируем номер для покупателя.
В следующих заметках расскажу, как запускался и развивался Booking и как устроено взаимодействие тревел сервисов с отелями.