732
Основательно и познавательно про управление продуктами. Разбираюсь сам, доношу другим. Управляю развитием b2b платформы для облачных сервисов. Для контактов @de_blocker
Никогда не подводил итогов года, но что-то в этом году захотелось впервые попробовать это сделать. Вообще весь год прошел в странном режиме "да, но". Вроде делал интересные мне вещи и получал от этого удовольствие, но при этом почти в каждой задаче осталось что-то недоделанным и незавершенным.
Итак, начну с своих околоигровых проектов:
На краудфандинге сделал колоду игровых механик для геймдизайнеров и даже продал за год почти 150 колод, но превратить это в полноценный инструмент геймдизайна не получилось. Нужно больше теоретической базы и примеров, чем надеюсь заняться в следующем году.
Сделал демо-версию аркады и опубликовал её в Google Play, но не хватило энергии завершить оставшиеся 7 уровней до полноценной игры.
Для свой старой стратегии про партизан сделал тактический режим, но уперся в необходимость отрисовки карт для этого режима и в итоге режим пока не ушел в релиз.
По части работы и около:
Поменял работу из сервиса налогового мониторинга в тревел индустрию и на новом месте фактически дорос до продакт лида, но документально пока никак это не оформилось.
Попробовал себя в качестве ментора на GetMentor, но в итоге понял, что для полноценной деятельности в роли ментора нужно больше времени и подзабил на это направление.
На запущенный на Stepik в прошлом декабре курс по поиску работы записалось за год 600 человек, из которых четверть завершила курс, но дополнительные модули курса, его платную версию и книжный формат реализовать за год так и не смог.
Что очень хотелось сделать, но так и не сделал этого за год:
Сервис структурированных интервью. Спроектировал базу, отрисовал экраны, но до итоговой сборки так и не добрался. В будущем году хочу попробовать другой подход, поскольку самостоятельное программирование у меня последнее время хромает.
Дописать фантастическую повесть. Расписал всю структуру и написал где-то четверть текста, но торможу во всем остальном.
А как у вас? Подводите итоги года или нет?
Давайте обсудим темные паттерны, которые используются в тревел сервисах и не только. Поизучав тему, я сформулировал 14 таких паттернов.
1. Ложный дефицит. Показ сообщения, типа «осталось только 2 номера по этой цене», чтобы создать ощущение срочности и побудить пользователей быстро сделать бронь.
2. Скрытые сборы. Сервис может не раскрывать дополнительные сборы, такие как курортные сборы или налоги, до тех пор, пока пользователь не будет готов совершить бронирование.
3. Вводящие в заблуждение формулировки. Часто грешат на Booking, что они используют расплывчатые формулировки, чтобы пользователям было трудно понять условия бронирования.
4. Принудительные покупки. Пользователю могут автоматически подключать подписку или незапрошенный доп. сервис, типа страховки, без возможности отказа от покупки. На днях за такое судили Уральские авиалинии, которые на промо тарифах принудительно добавляли страховку.
5. Подталкивание. Сервис может использовать всплывающие окна, пуши, подсказки различного рода, чтобы побудить пользователей совершить бронирование, даже если они не готовы или не заинтересованы. Ложный дефицит является одной из самых заметных механик такого подталкивания.
6. Манипулирование социальными доказательствами. Фальшивые отзывы, показ фраз типа "номер этой категории был забронирован час назад" без привязки к реальной брони. Все чтобы создать впечатление, будто объект более популярен, чем он есть на самом деле.
7. Согласие по умолчанию и автоматическое добавление в корзину доп. сервисов. Дополнительные услуги, типа страховки или трансфера, будут по умолчанию добавлены к покупке и могут иметь запутанную схему отказа от них. Но в отличие от принудительных покупок тут можно отказаться. Встречаются случаи, когда отказавшись на раннем этапе оформления от навязанного сервиса, на финальном этапе вам его снова добавят, испытывая вашу внимательность.
8. Цены-обманки и цены-якори. Сервис может отображать цены таким образом, чтобы ввести покупателя в заблуждение и в итоге побудить выбрать более дорогой вариант или же наоборот в карточке отеля показываются похожие отели с более высокой ценой, чтобы пользователь почувствовал выгоду от покупки в просматриваемом отеле и скорее сделал бронь.
9. Невозвратные бронирования. Сервис может предлагать невозвратные бронирования, которые нельзя или сложно отменить, если планы пользователя изменятся. В явном виде такое не запрещено, поскольку такие тарифы прописаны на законодательном уровне. Темноты добавляет отсутствие хорошо заметного сообщения об особенностях тарифа или попытка продать такой тариф по цене обычного с возможностью отмены.
10. Скрытые правила отмены. Правила отмены могут быть скрыты за мелким шрифтом или местом их отображения на странице, что затрудняет понимание пользователями возможностей отмены бронирования.
11. Предложения, ограниченные по времени. Сервис бронирования может предлагать ограниченные по времени скидки, промокоды или персональные предложения, чтобы создать ощущение срочности и побудить быстрее совершить бронирование.
12. Промокоды. Сервис может специально передавать наборы промокодов на сайты-публикаторы промокодов, чтобы привлечь пользователей, привыкших всегда искать промокоды. При этом промокод может не давать реальной выгоды по сравнению с обычной покупкой.
13. Неполная или искаженная информация. Сервис может не предоставлять или искажать информацию, необходимую пользователям для принятия обоснованного решения, например, время в пути от отеля до достопримечательностей или пляжа, качество удобств отеля и т.п.
14. Динамическое ценообразование. Корректировка цены в зависимости от спроса и глубины бронирования, поэтому пользователи могут в конечном итоге платить больше за один и тот же объект, если будут ждать слишком долго с бронированием. Однако тут сервису нужно не попасться на нарушении паритета цен с отелем, поэтому такое встречается для уже выкупленных броней или спецсоглашений с отелями.
А вы с какими темными шаблонами сталкивались при бронировании отелей или покупке авиабилетов?
Ищу себе коллегу
К себе в команду (группа компаний МТС Travel / Броневик) ищем сильного продакта на развитие B2B-продукта для отельеров.
Основная задача - развить конкурентоспособный B2B-продукт, который приносит пользу отелям, а также дает им возможность поднять свой средний чек и увеличить продажи.
Ссылка на вакансию: https://spb.hh.ru/vacancy/86206184
Работать можно из любого города, но, к сожалению, только из РФ.
Любые вопросы можно задать напрямую @de_blocker
Какие книги почитать продакту про тревел-продукты
Поделюсь подборкой книг, которые прочитал и которые могут быть полезны продакту как при запуске, так и развитии тревел-продуктов.
Airbnb. Как три простых парня создали новую модель бизнеса.
Книга хорошо раскрывает тему создания Airbnb и начальных стадий его развития. Хотя полноценного рецепта создания такого маркетплейса, как Airbnb, в книге нет. Довольно много информации про Airbnb как социальное явление, риски связанные с этим и, в целом безуспешные, попытки компании устранить эти риски. Книга хорошо зайдет, если вы на начальной стадии запуска своего продукта или стартапа в сфере тревел, есть чему поучиться у упорства создателей Airbnb.
The Machine.
Книга довольно детально рассказывает о создании и развитии Booking.com до сегодняшних дней. Поскольку книга вышла в 2022 году, то и тему Ковида тоже затронули. Я бы выделил в книге пару интересных мне тем — как Booking.com стал тем, что есть в ходе непрекращающихся поглощений и слияний, а так же как компании удалось превратить себя в «машину по зарабатыванию бабла», что и вынесено в название книги. Поскольку книга писалась тремя журналистами без разрешения компании, то кажется, что история получилась вполне себе без прикрас и с демонстрацией многих черных пятен в истории компании. Если строите такой же крупный бизнес, то книга однозначно стоит ознакомления.
The Business of Tourism.
Академический учебник детально раскрывающий все аспекты туризма как сферы бизнеса. О качестве книги можно судить хотя бы по тому, что c первого издания в 1983 году вышло уже 11 изданий этого учебника. Я читал десятое и могу сказать, что кажется все возможные темы о бизнесе на туризме и туризме как социокультурном явлении в книге раскрыты очень глубоко. Однозначно рекомендую к изучению.
Аналитика гостиничного рынка.
Свежее (на титуле стоит 2024 год) учебное пособие по аналитике гостиничного бизнеса, где описаны все основные метрики этого бизнеса, показаны системы для работы с этими метриками и анализа гостиничного рынка в целом. В общем, книга довольно практична и помимо метрик дает актуальную информацию по состоянию гостиничного бизнеса в России.
Немного не про продукты - оказывается ведущий канала "Ступени геймдева" Сергей Гресь делает у себя разбор карт из колоды геймдизайнера, что я делал.
Тут можно посмотреть первый разбор - https://www.youtube.com/watch?v=s6fb5JvDypY, а на этой неделе он подключает к продолжению разбора еще одного нарративного дизайнера - /channel/gamedevstairs/2107
Доделал свой очередной мини-проект. В этот раз я ставил себе цель сделать игру на Android и опубликовать её в Google Play. Идея игры пришла где-то пару лет назад, тогда же сделал первый набросок, но полноценно смог заняться только с февраля этого года. В общем, почти 4 месяца спустя у меня готов вертикальный срез игры (так в геймдеве называют MVP, когда в игре готов основной геймплей, показан весь основной звуковой и графический контент и остаётся только масштабировать это в полноценную игру). И вот на днях опубликовал демо игры в Google Play. Следующим этапом будет завершить игру - планирую 10 уровней и закрученный сюжет. Пытался в юмор, но видимо это не мое, поэтому будет трагедия. Судя по темпу работы, на завершение игру у меня уйдет минимум полгода в фоновом режиме или больше, поскольку хочется поскорее приступить к запуску следующей идеи в сфере HRtech.
https://play.google.com/store/apps/details?id=com.noblocker.redstarredemption
В комментарии к прошлому посту пообещал разобрать разницу в подходах к развитию продуктов и бизнеса Booking и Airbnb. Выполняю обещанное.
Хочу начать с того, что с точки зрения бизнес-моделей оба сервиса практически не отличаются – оба являются двусторонними маркетплейсами с клиентами-физическими лицами с одной стороны и поставщиками жилья, с другой стороны. Оба сервиса транзакционные – оба зарабатывают в первую очередь на комиссии с каждой сделанной транзакции через маркетплейс, а размещение объектов и их поиск полностью бесплатны для всех участников маркетплейсов.
Не смотря на сходство бизнес-моделей, сервисы начинались с кардинально разных посылок практически во всех аспектах своей деятельности. Выделю эти отличия по ряду направлений.
Целевые клиенты: Для Booking основными и главными клиентами были отели, тогда как Airbnb ориентировался в первую очередь на потребителей – тех, кто ищет возможность недорого переночевать в новом месте. Также если говорить, о местах проживания у Airbnb, то их владельцы не были профессионалами в отельном бизнесе – это было чаще всего единственное жилье, которое сдавалось пока хозяева в отпуске или отъезде.
Стандарты обслуживания: Booking не навязывал никаких стандартов отелям – звездность отеля, отзывы клиентов и рынок сами порешают, тогда как Airbnb в начале своей деятельности пытался сформировать единый подход к оказанию услуги проживания. Собственно, это прямо записано в их названии, которое когда-то расшифровывалось как Air bed and breakfast – надувной матрас и завтрак. Доходило до смешного, что Airbnb требовали от хозяев класть надувной матрас поверх обычных кроватей.
Подход к UX: Весь свой подход к UX Booking долгое время строил на принципе – «бронируй и отваливай», тогда как Airbnb изначально пытался предложить высокий уровень пользовательского опыта – качественные красивые фотографии жилья, широкий выбор необычных мест проживания.
Продвижение: Почти 15 лет с момента своего создания Booking использовал только онлайн-рекламу для привлечения пользователей и прямые продажи для привлечения отелей, не вкладывая ничего в формирование и продвижение своего бренда. Хотя они были крупнейшим рекламодателем Google в мире, реклама не позволила им сделать своей название в сознании потребителей именем нарицательным, как какому-нибудь Xerox или Pampers. У них не было оффлайн рекламы, они даже логотип своей компании на офисе не вывешивали. При этом Airbnb делал все для продвижения себя именно как бренда, узнаваемого и приятного потребителям. Они сохранили этот подход и по текущий момент, вкладывая больше в продвижения бренда, чем поисковую рекламу. При этом Booking, после выхода на американский рынок, перенял их подход и стал гораздо больше вкладывать в строительство своего бренда.
Безопасность сервиса: В силу того, что на Airbnb жилье сдавали не профессионалы и жилье не имеет определенных стандартов, как в отелях, компании приходилось вкладывать гораздо больше средств и усилий в безопасность как потребителей, так и домовладельцев. Первые бывало подвергались насилию и были даже убийства, а домовладельцы страдали от разрушенного жилья и украденных вещей. Одно время в США было популярно проводить вечеринки в съемном жилье, в результате чего жилье приходило в полную негодность. Из-за этого Airbnb нужно было выстраивать гораздо более доверительные отношения с владельцами жилья, предоставляя им защиту от таких случаев. Airbnb пришлось завести собственную службу детективов и выплачивать несколько десятков миллионов долларов ежегодно, чтобы избежать судебных тяжб и обвинений. Для Booking все гораздо проще – при работе с отелями такие проблемы гораздо реже, а основной проблемой чаще всего является овербукинг или недостоверное описание номеров от отеля.
Последнее направление, которым хочу закончить – это тестирование продуктовых гипотез в обеих компаниях. Но тут у компаний гораздо больше общего, чем различий.
Никто меня не просил об этом, но я все же продолжу. Сегодня хочу рассказать немного про историю, наверное одного из самых известных, тревел сервисов, а до недавних пор и буквально монополиста на российском рынке. Конечно же это Booking.com.
История Booking довольно запутана - основатель компании был довольно рано отстранён от управления и участия в техническом развитии сервиса, а вся прочая история компании - это серия причудливых поглощений и слияний.
Сервис основал Герт-Ян Бруинсма, который после окончания университета, создал акционерное общество из своих знакомых, собрав деньги на запуск сервиса в Нидерландах. Ему удалось создать довольно хорошо работающую систему, фронт которой был выставлен в интернет, а бэк в сторону отелей работал на основе факсов, которыми система автоматически обменивалась с отелями. У него не было какой-то четкой стратегии развития и выхода на глобальные рынки, поэтому в первые годы он спокойно раздавал направо и налево лицензии и права на работу с сервисом в других странах без какой-либо системы и четких условий лицензирования.
Например, его знакомые открыли копию сервиса в Великобритании и когда Бруинсма захотел перевести их компанию под единое управление Букинга, то ему пришлось за эту операцию отдать буквально половину акций оригинального Букинга. Интересно, как его друзья решили в Великобритании извечную проблему маркетплейса - набор поставщиков. Они одним из первых подключили хостел с названием Four Seasons - такое же название, как у крупнейшей сети отелей. И другим отелям говорили, что Four Seasons уже подключился, не уточняя, что это совсем не отельная сеть. Другая выдающая находка, которая позволила Booking быстро привлекать поставщиков - это демонстрация сервиса отелю. Представитель Booking создавал отель в сервисе, прежде чем придти в отель на презентацию сервиса. Придя же в отель, он просил номер их факса и доступ к телефону, чтобы по dial-up выйти в интернет. Потом он заходил с ноутбука через модем на сайт Booking, находил этот отель, делал пробный заказ и через минуту факс отеля выплёвывал листок с этим заказом. Такая демонстрация лучше любых слов убеждала владельца отеля. Ну и конечно, свою роль сыграл размер комиссии - Booking брал 6 процентов против 30-40 которые брали офллайн турагентства.
Несколько первых лет сервис развивался в таком режиме, пока не начал консолидацию своих активов - сначала Booking поглотил своих лицензиатов в Великобритании, а потом уже сам Booking был поглощён, в первый, но не последний раз. Друзья и акционеры Бруинсмы, видя, как растет сервис, создали отдельную компанию Booking Online, которая служила прослойкой между Booking и конечными клиентами - компания по агентской схеме нагоняла заявки, поскольку клиентская часть основного Booking была не особо хорошего качества и строилась по принципу - бронируй отель и отваливай нахер. В итоге, все кончилось тем, что эти самые друзья договорились с Бруинсмой выкупить у него компанию и дать ему почетную пенсию, но без его участия в управлении компанией. И собственно на этом участие основателя Booking в работе сервиса и закончилось. Следующие владельцы выкинули устаревший код Бруинсмы и сделали ставку на начавший набирать популярность Google - став его крупнейшим рекламодателем в мире, при этом на каждый евро потраченный на рекламу, сервис получал два евро прибыли, просто машина по генерации прибыли.
Следующее поглощение Booking произвела американская компания Priceline, которая сначала купила английскую компанию Active Hotels, сравнимую по размеру с Booking, а потом собственно и сам Booking. Американцы пытались сделать основную ставку на англичан, поставив их во главе европейских операций, но тогдашний CEO Booking показал просто нереальную хватку - Booking самостоятельно интегрировал все отельные предложения англичан в свою систему и за несколько месяцев перевел все их заказы на себя, буквально убив бизнес коллег по холдингу, что в итоге привело к увольнению всего персонала и закрытию компании.
Как устроен бизнес тревел сервисов на примере Островка и Booking.com
Волею судеб, я оказался на этот раз в тревел индустрии, поэтому немного порефлексирую на тему этого бизнеса и того, как он работает.
И Островок и Booking.com относятся к так называемым сервисам OTA – Online Travel Agency и весь их бизнес построен на модели маркетплейса – свести вместе владельцев мест размещения (отели, владельцы апартаментов и т.п.) и покупателей. Диапазон покупателей в этом типе маркетплейса достаточно широк – это конечно обычные физические лица, но и достаточно разношерстные b2b клиенты – туроператоры, турагенства, корпоративные заказчики, сервисы онлайн бронирований для бизнеса, агенты и те же самые OTA. При этом надо учесть, что со стороны поставщиков маркетплейса представлены не только прямые владельцы отелей и других объектов, но и промежуточные поставщики – опять те же самые OTA и инвентарные системы, у которых есть прямые договоры с отелями.
В итоге, получается довольно запутанная цепочка перепродажи, где сервисы одного и того же типа могут выступать одновременно как поставщиками, так и покупателями. При этом один и тот же отель может присутствовать одновременно у нескольких поставщиков. Что в свою очередь создает проблемы с контентом маркетплейса. Например, у Островка больше 140 поставщиков и описание одного и того же отеля, номеров в нем и тарифов могут прилететь в систему от нескольких десятков поставщиков и все они могут быть разные. Островку, например, пришлось делать свою систему сборки консистентных описаний номеров, отелей на основе заранее заданных правил и машинного обучения, чтобы у себя на сайте показывать уникальные и непротиворечивые описания.
Другая проблема тревел сервисов – это многочисленные и разнообразные тарифы и схемы тарификаций дополнительных услуг. Полученные от разных поставщиков и самого отеля они так же могут быть разные для одних и тех же объектов. Для этого в Островке сделали систему тегирования, которая каждый тариф размечает набором тегов и это позволяет в итоге делать уникальные срезы и сортировки тарифов – по цене, по надежности поставщика и т.п.
Надежность поставщика – это еще одна проблема индустрии. Так называемый Success Rate бронирования (то есть когда покупатель смог без ошибок забронировать объект) достигает 94% у Expedia (лидер на американском рынке), но может падать до 60% у других поставщиков. Условно говоря 2 из 5 бронирований будут неуспешны, но отказаться от таких поставщиков нельзя, поскольку при всем прочем они дают самые лучшие для покупателей цены.
В результате у OTA сервисов есть специальные системы, которые выстраивают цепочку из поставщиков для одного и того же объекта – сначала пробуем заказать у самого дешевого, но проблемного поставщика, потом идем к тому, кто подороже и так далее, пока не забронируем номер для покупателя.
В следующих заметках расскажу, как запускался и развивался Booking и как устроено взаимодействие тревел сервисов с отелями.
Аскар Рахимбердиев из МойСклад выпустил свой ежегодный неофициальный рейтинг российских SaaS сервисов, который я свел для наглядности в таблицу.
Рейтинг основан на данных по годовой выручке из финансовой отчетности за 2022 год и некоторых инсайдерских данных. В него входят компании с годовой выручкой на российском рынке не менее 100 млн. За 2022 год участники рейтинга в среднем выросли на 41%, что очень неплохо для кризисного года. Средняя рентабельность 18%, что кажется вполне здоровым показателем.
Остальные пояснения по рейтингу можно посмотреть в публикации Аскара https://www.facebook.com/arahimberdiev/posts/10231033060315801
Как неоднократно писал у себя на канале, мне интересно пробовать новое - новые направления, продукты, способы продвижения, механики и так далее. В прошлом году я попробовал и сделал голосовой навык для тренировки собеседований, запустил онлайн курс по поиску работы и улучшению резюме, в этом году попробовал краудфандинг и делаю мобильную игру.
И вот в качестве тестирования нового - хочу попробовать себя в менторинге. За плечами у меня довольно обширный опыт консультирования в сфере маркетинговых стратегий и планов, был трекером стартапов, прорабатывал идеи новых продуктов от замысла до бизнес-плана и GTM стратегии, давал рекомендации по улучшению резюме специалистам в разных областях, преподавал на курсах и сам их писал. Так что кажется, что и в менторинге я тоже смогу быть полезным.
История для меня как обычно некоммерческая, хочу более глубоко изучить этот инструмент, его возможности и ограничения. Поэтому первым записавшимся - услуга будет полностью бесплатна. Темы для менторства обозначены в моем профиле на https://getmentor.dev/mentor/dmitriy-vostrecov-1798, в целом мне более интересно пообщаться на тему SaaS сервисов и продуктов на их основе, но в целом можем поговорить на тему любых других продуктов, карьеры и поиска работы (как минимум не сделаете тех ошибок, что я). Записывайтесь через сервис GetMentor, хотя можете и просто в личку написать.
Делаю очередную игру в качестве хобби и глубоко прочувствовал, что значит настоящая итеративная разработка.
В этот раз, я решил обойтись без исчерпывающего геймдизайн документа (аналог PRD в разработке игр). То есть неопределенность полная, все по заветам Agile, где каждое следующее действие должно эту самую неопределенность уменьшать. Поэтому все идеи по фичам кидаю в бэклог, при этом идеи прямо на глазах трансформируются - становятся неактуальными, отклоняются из-за слишком длительной реализации, расщепляются на подзадачи, сливаются из нескольких в одну. Очень живой бэклог получился и столь же органично идёт его сортировка - более понятные и конечные задачи сами всплывают к верху. Анализ результатов идёт непрерывно и параллельно самой разработке и корректировки в бэклог делаются на основе этого анализа, всё как в каноне. Как такового спринта у меня в соло разработке конечно нет, можно сказать что спринт однодневный, поскольку каждый день я стараюсь принести ценность проекту, при этом сохраняя его целостность (см. Принцип jpg)
В чем же мораль? А мораль простая. Хоть я уже 15 лет работаю по Scrum и в парадигме Agile, но впервые это получилось настолько органично и полно по сравнению с коммерческой разработкой внутри компаний. А что мешает компаниям делать так же, пожалуй напишу в следующий раз.
Новые каналы в каталоге каналов по продакт-менеджменту
/channel/product_channels/21
Мой хороший друг рассказывает у себя в канале, как он создал и продал бесплатный Productivity сервис. В его канале его можно попытать на тему, как же он нашел покупателя и другие вопросы по развитию продуктов.
/channel/dobrych/70
По завершении этой эпопеи, стоит под своим надзором провести первых клиентов через все этапы пресейла и запуска продукта. И собственно только в этот момент начнется регулярная работа продакта по развитию продукта - валидировать гипотезы по ценообразованию и набору функций, собирать обратную связь с клиентов, корректировать продуктовую стратегию, создать родмеп для дальнейшего развития продукта на основе выявленных недочетов, но об этом как-нибудь в другой раз.
3/3
Я при собеседованиях кандидатов придерживаюсь методики структурированного интервью - по различным исследованиям, в том числе вполне научным, оно даёт наибольшее качество в оценке навыков и последующем качестве работы кандидатов. Пару лет вынашиваю идею, сделать сервис по этой теме, но пока развитие LLM ставит крест на этой идее, в общем надо идею адаптировать к текущему уровню развития языковых моделей.
В чем состоит методика - заранее готовится опросник для интервью и кандидатам задаются одни и те же вопросы, в одном и том же порядке. Вопросы открытые и выясняющие, что делал и как поступал кандидат в разных ситуациях. В ходе интервью все ответы кандидатов фиксируются и по итогу оцениваются. В результате, мы получаем базис, который позволяет сравнивать друг с другом разных кандидатов и выбирать лучшего, что малоосуществимо на практике для других видов собеседований.
Новый CPO показал, как структурированные интервью используются в Сбере - для каждого этапа (скрининг, оценка софт и хард скиллов) есть свой перечень вопросов и для каждого вопроса ещё даны комментарии, что считать хорошим ответом, а что нет. Это ещё больше упрощает жизнь нанимающих менеджеров, которые в массе проводить интервью не умеют. За основу методики в Сбере взяли метод описанный в книге Джеффа Смарта и Рэнди Стрита "Кто". Забавно, что авторы выдают методику за свою и ни разу в книге не упоминают структурированное интервью.
Лично я, исходя из опыта более трёх сотен интервью, как с одной стороны, так и другой, оцениваю метод структурированного интервью как наиболее точный и удобный, особенно в условиях онлайн собеседований. А вы какую методику применяете при проведении собеседований?
Думаю над механикой геймификации и полез изучать варианты геймификации в тревел сервисах. В России их оказалось не очень много, но десяток заметных кейсов можно выделить. Судя по такому небольшому их числу геймификация себя не оправдывает, иначе кейсов было бы больше и компании чаще применяли бы их.
1. Связной Тревел делал квест для конечных покупателей - покупатели авиабилетов размещают геометки на скидку, другие их собирают - этакий вариант Покемон Go. Вживую не видел, но описание механики крайне запутанное и не стимулирует к участию. Результат тоже не очень - хоть и заявлено 20000 участников, но было поставлено и собрано только около 400 меток (1 метка на 50 участников - довольно низкое вовлечение), вознаграждение слабо дифференцировано - нет никаких повышающих награду рангов, в итоге скидка в среднем составила чуть больше 1000 рублей.
2. Свой вариант квеста предлагал сервис аудиогидов izi.travel - стандартные механики поиска геометок, викторин, поиска подсказок, поиск "клада" должны неплохо привлекать пользователей в сам аудиогид, но мало помогут в привлечении туристов из других локаций.
3. Аэрофлот тоже попробовал себя в геймификации через приложение Аэроигры - пакет из простых игр в формате мобильного приложения, в которых можно было менять внутриигровые очки на мили Аэрофлота.
4. Туроператор ITM Group попробовал добавить игровой опыт туристам на Бали через механику квестов. Подробностей не нашел, но судя по всему они просто давали задания через мессенджер, выполнение которых туристы должны были отмечать в своих соцсетях. В целом, дешево и сердито - достаточно посадить одного оператора на выдачу заданий и призов и не нужно тратить ресурсы на создание приложений.
5. Создатель CRM для турфирм встроил геймификацию в свой сервис, чтобы ускорить и упростить обучение пользователей работе с сервисом. На этой же основе он сделал мотивацию пользователей для повышения продаж. Интересно было бы посмотреть на реализацию, но жаль, компания не дожила до сих дней.
6. Оператор TEZ Tour во времена короны предлагал туристам отстреливать вирусы в своем сервисе в обмен на скидки на бронирование отеля или покупку тура. Как видно подходит любая простая игра с набором очков и репетативным геймплеем.
7. Компания Level Travel пошла еще дальше и геймифицировала работу своих сотрудников. В подкасте они описывали как через геймификацию лучше внедряли Scrum и межкоммандные взаимодействия. Сейчас же кажется все свелось к внутренней валюте, за которую можно покупать пиццу в офис и отгулы. Как они пишут: "богаче всех тот, кто больше всех работает". Также по итогу года они отправляют самую продуктивную команду в путешествие. Надеюсь не пешее ))
8. Туроператор Coral Travel интересно встроил геймификацию в обучение турагентов - в серии из 4 вебинаров про горнолыжные курорты Турции можно было отвечать на вопросы викторины и собирать баллы и части горнолыжной экипировки. Тех кто собрал все части приглашали на пятый вебинар, где участники с самым большим числом баллов получали уже реальные призы - от футболки и сертификата на обучение до скидки на рекламный тур.
9. Также для обучения геймификацию используют корпорации - в игровой форме обучая персонал тревел-политикам. А MICE компании используют игры и игровые механики в рамках организации корпоративных обучающих мероприятий. Но это все же немного не тревел, а ближе к геймификации образования.
10. Завершу подборку тоже кейсом почившего в бозе Связной Тревел - под обложкой майнинга тревелкойнов предлагалась простая механика викторины с фотозагадками. Выигрышем в игре выступали скидки на авиабилеты, а для удержания и привлечения новых участников предлагалось размещать ссылки на игру в соцсетях, чтобы получать дополнительные попытки в игре.
А в следующий раз хочу сделать аналогичный обзор зарубежных кейсов геймификации в тревеле. Ожидаю, что там будет поинтересней.
Немного пофантазировал на тему будущей трансформации сервисов бронирования отелей.
Какие цели у сервиса бронирования отелей?
Сервис должен помогать найти тот самый вариант, который нужен пользователю.
Пользователю не хочется продираться через страницы предложений, он хочет быстро получать результат.
Пользователю по сути не нужно множество вариантов, ведь купит он только один единственный, хоть множество вариантов и создают иллюзию богатства выбора и крутости сервиса (да, есть пользователи которые так и оценивают).
Но что может ускорить процесс выбора и быстрее довести пользователя до его единственного варианта?
Узнать у пользователя больше информации о его желаниях - сколько готов потратить, зачем едет, с кем поедет, на чем поедет, на какой срок, что хочет есть, где хочет побывать, что увидеть, чем заняться. Но часто пользователь не может определиться в своих желаниях - типа я пойму что это то, что нужно, только когда это увижу. А значит надо пользователю дать визуальный способ выбрать то, что он хочет. Как устроены все современные сервисы? Поиск + фильтры + куча офферов с непонятными пользователю названиями и непонятными отличиями. Ну ещё некоторые надстраивают то же самое над геолокацией, чтобы пользователь по карте выбирал где он хочет жить.
Как же может выглядеть такой сервис бронирования, где все для визуалов? Возможно это что-то вроде Tinder - задаешь параметры поиска, а дальше листаешь фотографии номеров с кратким описанием. Понравилось - свайп для добавления в отобранное, чтобы из нескольких вариантов выбрать итоговый. Не понравилось смахиваешь прочь. При этом сервис был бы ещё лучше, если бы на лету учитывал выбор пользователя и в следующих карточках учитывал действия пользователя и подсовывал то, что с большей вероятностью понравится пользователю.
Описанное вполне органично вписывается в уже привычные модели работы с мобильными приложениями, но кажется может быть трудно реализовано в виде веб сервиса. Тут скорее всего может быть что-то похожее на Pinterest, но модель рекомендаций должна учитывать как добавление в отобранные, так и то, какие карточки номеров пользователь увидел, но не прореагировал на них. При этом чтобы пользователь оставался в состоянии потока, важно отказаться от переходов на другие страницы - надо уметь показать крупные фото и дополнительную информацию в одном окне.
Вот так, в первом приближении, я вижу развитие сервисов для бронирования отелей. Давайте порассуждаем, какие есть минусы у такого визуального подхода.
На работе возникла задача нанять продакта, да не абы какого, а синьорно-помидорного. И хотя я за свою жизнь провел сотни три собеседований на разные позиции, но в этот раз что-то завис. Как понять, что это тот самый? Куча просмотренных статей, книг и видео про собеседование продактов, личный опыт, когда я был на собеседуемой стороне, как-то не особо помогают. В моей практике собеседований в топовые компании не было ни разу, когда я мог бы сказать "Вау!" про собеседования. Обычно в чистом виде субъективщина, когда нанимающий менеджер нанимает не по компетенциям и по соответствию позиции, а просто по настроению. Провести собеседование по привычной схеме для меня не проблема, но в этот раз захотелось на берегу понять правильность собеседования и корректности оценок навыков и компетенций продактов.
В итоге, я начал с более глубокой, чем обычно, подготовки к собеседованию.
- Сначала сформулировал требования к человеку на конкретной позиции. Получился набор характеристик и примеров их проявления. Таким образом я зафиксировал ожидания от кандидата, которые уже служат основой для составления вопросов для собеседования. Требования хорошо бы откалибровать с другими участниками собеседования и командой, чтобы у всех были понятные всем ожидания, но я пока пропустил этот этап.
- Затем описал список вопросов для проверки компетенций и знаний продакт-менеджера на основе ранее описанных характеристик и требований к знаниям и навыкам. Для каждого вопроса я сделал заметки, на что именно обращать внимание в ответе, что именно подтверждает наличие навыка и знаний. В ответах мне интересен только прошлый опыт и поступки кандидата, а не его знание теории или потенциальное поведение.
- Наконец, сформулировал пару кейсов, максимально приземленных к работе, чтобы послушать как человек умеет мыслить и рассуждать.
При этом в оценке разных кандидатов я планирую использовать метод структурированных интервью - когда одни и те же вопросы задаются в одном и том же порядке разным кандидатам и каждый ответ фиксируется и единообразно оценивается. Согласно исследованиям такой подход является самым точным вариантом оценки кандидатов среди всех других методов собеседования, хотя все еще далек от 100% точности.
Какие минусы у этого подхода?
- Он достаточно времязатратен в процессе подготовки и в процессе самого собеседования. Чтобы разобрать все вопросы и один кейс - потребуется минимум 2 часа, а укладываясь в стандартный час теряешь глубину оценки кандидата.
- Я не учитывал вопросы связанные с корпоративной культурой и ценностями. Компания в процессе трансформации и они мне самому не особенно понятны - ценности и культуру исходной компании после покупки сейчас подвергают слому из головной компании.
Если у вас был опыт хороших собеседований на продакт-менеджера, то напишите в комментарии название компании и что понравилось. Будет интересно изучить позитивный опыт.
Чтобы создать новое в тревел индустрии нужно знать, что уже сделано до вас. На текущий момент я черпаю информацию в следующих источниках:
Карта российских тревел проектов https://rb.ru/traveltech-map/. Не все в ней логично и некоторые компании явно попали в карту за спонсорство, но лучше так, чем никак.
Ежегодная карта экосистемы с основными зарубежными тревел продуктами для отелей и туристического бизнеса https://insights.shijigroup.com/hospitality-technology-distribution-chart-2022/. Карта создана компанией Shiji, которая сама разрабатывает продукты для отелей, поэтому тут может быть некоторая предвзятость.
Новости и отчёты Skift - https://skift.com/. Одна из крупнейших аналитических компаний в сфере тревела. Открою секрет - их отчёты можно читать бесплатно, достаточно вбить ссылку на любой отчёт в Google и потом открыть закешированную страницу отчёта в самом Google без перехода на сайт. Да, у них тоже есть своя карта тревел продуктов - https://skift.com/traveltech250/
Питчи тревел стартапов на YouTube канале исследовательской фирмы Phocuswright - Phocuswright/" rel="nofollow">https://www.youtube.com/@Phocuswright/
Обе компании активно вкладываются в A/B тестирование новых продуктовых гипотез и изменений на своих сайтах, сделав их буквально основой своего бизнеса, но кажется, что в Booking продвинулись несколько дальше в этой культуре. Буквально каждый сотрудник может инициировать тестирование гипотезы и для этого не нужно получать согласие руководства. Одно время Booking даже представляли себя, как «компания по A/B тестированию, которую случайно занесло в продажу номеров в отелях». Airbnb начали заниматься data-driven подходом позже, но быстро переняли подход Booking, тоже сделав экспериментирование ядром своего бизнеса.
Читать полностью…
Ну а финал всей истории известен - сама компания Priceline в итоге поменяла свое название на Booking, чтобы ассоциироваться с самым крупным своим активом.
Напоследок хочу выделить ещё один показательный аспект бизнеса компании. Читая различные материалы про Booking, я везде натыкался на примерно идентичный перечень на чем же зарабатывает компания - комиссия отелей, продажа рекламы на своих площадках, перепродажа выкупленных номеров. Но все забывают сказать, что фактически компания ещё зарабатывает на налоговых льготах - в Нидерландах действует примерно такой же набор льгот по налогам для инновационных компаний, как и сейчас в России, вообще наша ФНС активно перенимает голландский опыт, и как результат Booking из-за льгот ежегодно платит на четверть миллиарда евро налогов меньше, а как известно сэкономленный рубль лучше двух заработанных.
Итак, продолжу про тревел сервисы – на чём же они зарабатывают и как вообще устроена цепочка продажи номера от отеля до клиента.
Если брать российский тревел рынок, то наиболее активны на нём сервисы следующих типов - OTA, агрегаторы отелей и менеджеры каналов. Агрегаторы отелей заключают прямые договоры с отелями на продажу их номеров и обеспечивают эти продажи через широкую сеть партнеров – OTA, туроператоров, турагентства и т.д. Менеджеры каналов – это система для отелей, которая позволяет отелю управлять всеми каналами продаж через прямые интеграции с OTA, агрегаторами и сайт самого отеля.
Еще можно упомянуть такие сервисы, как OBT (Online Booking Tool) и PMS (Property Management System). Первые предназначены для сегмента корпоративных заказчиков, которым требуется часто отправлять сотрудников в командировки и OBT, интегрированные с другими агрегаторами и OTA, позволяют компаниям экономить на заказе отелей и билетов. PMS же предназначены для автоматизации всей деятельности отелей, это такие отельные ERP.
На зарубежных рынках типов систем гораздо больше. Например, только разных типов агрегаторов отелей там несколько – одни агрегируют под единой системой предложения и тарифы отелей, вторые только контент об отелях, третьи - отзывы, четвертые выкупают у отелей номера по оптовой цене и сами устанавливают в итоге стоимость продажи и т.д. и т.п. А помимо этого есть сервисы, которые автоматизируют или переводят некоторые бизнес-операции, типа подтверждения у клиента бронирования номеров, в страны с более дешевой рабочей силой. Кстати, это действительно проблема – до 40% броней отменяется или гость просто не заезжает, в результате отель теряет деньги на нераспроданных номерах, поэтому чем раньше отель узнает, что бронь недействительна, тем выше шанс, что он успеет продать номер другому гостю.
В общем случае, хотя возможны и варианты, цепочка продажи номера от отеля до клиента выглядит следующим образом:
Клиент – OTA – агрегатор отелей – менеджер каналов – отель
Каждый посредник в цепочке берет свой процент комиссии, который в итоге может дорасти до 30% и больше. К слову, когда Booking.com только начинал в конце 90-х, то они ставили меганизкий процент комиссии – от 2 до 6%, что выглядело сказочно в мире, где были только оффлайновые турагентства, которые брали до 50% от стоимости номера.
Сейчас же OTA сервисы берут от 15 до 25% комиссии, у того же Booking.com комиссия сейчас в диапазоне 15-18% и когда они были в РФ, то они еще на этот процент накручивали НДС. У агрегаторов отелей примерно такой же процент комиссии и в этом случае комиссия у OTA, использующего агрегатор, соответственно снижается.
Может показаться, что для отеля выгоднее продавать номера напрямую, используя свой сайт. Но на самом деле прямые продажи с сайта тоже не бесплатны. Если отель использует для продажи на сайте менеджер каналов, то последний берет свой процент с каждой транзакции. Даже, если отель продает вообще без каких-либо посредников, то у него остаются затраты на рекламу, поддержку сайта, обслуживающий продажи персонал и т.п. В итоге, стоимость, казалось бы, бесплатного канала, может составлять до 10-15% от стоимости номера.
Что еще вам хотелось бы узнать про бизнес тревел сервисов?
Инструкция для человека
Знакомая подарила детям шуточные "Инструкции по использованию человека" - бланк, где заполняешь данные о себе. Темперамент, положительные и отрицательные стороны характера, что лучше всего умеешь, что не получается и так далее, получается такая концентрированная само-характеристика на человека.
И я подумал, а почему подобный инструмент не используют в рабочих отношениях. Учитывая довольно низкий уровень менеджерской культуры в стране, когда руководителям трудно найти подход к своим сотрудниками и понять их мотивацию, кажется что информация о свойствах характера, честная информация о сильных и слабых сторонах сотрудника, могла бы им помочь быстрее адаптировать новых сотрудников и управлять своими подчиненными лучше. Да, есть куча тестов различного вида, но насколько я видел никто их системно не использует в реальной работе и зачастую их результаты не передаются руководителю. Резюме тоже не может быть заменой такому инструменту, поскольку резюме показывает приукрашенный образ человека, а кроме того, сейчас не принято описывать в резюме свои софт-скиллы.
Просматривая один из курсов по управлению удаленной командой, я отметил интересную технику, которая наиболее близка к идее об инструкции для человека, хотя тут она сводится к роли, а не конкретному человеку. Эта техника называется "Транспарант". Техника полезна когда в команде появляется новый человек или нужно прояснить цели и роли существующих членов команды.
Техника "Транспарант" выполняется в 3 шага:
1. Каждый участник команды готовит "транспарант" с описанием своей роли в команде, например в Miro или на листке бумаге, если все в офисе.
На транспаранте пишется
- название роли
- главная цель, которой служит эта роль
- 2-3 главных задачи
- ключевые обещания этой роли другим ролям в команде, клиентам, другим подразделениям в компании
2. Когда все транспаранты готовы, то каждый член команды смотрит на чужие транспаранты и дописывает на них свои ожидания в виде - "я жду от тебя, что ты ..."
3. Когда все ожидания написаны, устраивается обсуждение. Может оказаться, что транспаранты части ролей переполнены дополнительными ожиданиями, а у части не добавилось ни одного ожидания. Обе эти ситуации требуют прояснения.
В первом случае, кажется что автор транспаранта выполняет функции сверх своих рабочих функций, возможно против своего желания. В этом случае руководитель должен синхронизировать всех членов команды и возможно назначить других ответственных за обозначенные ожидания и их результат.
Во втором же случае, может оказаться, что по какой-то причине члены команды не обращаются к этой роли с какими-то запросами сверх рабочих, а возможно стараются не обращаться и по рабочим вопросам, например, из-за токсичности человека или низкого качества работы или иной причине.
Кажется, что данную технику можно масштабировать также и на уровень межкомандного взаимодействия в компании и даже на уровень общения с клиентами и партнерами. Например, похожую методику, называемую "Обещания" использует ВкусВилл - на их сайте можно ознакомиться с Кодексом, где зафиксированы обещания всех ролей в компании перед клиентами и компанией.
Если бы я знал о технике "Транспарант" раньше, то попробовал бы применить её, поскольку она на мой взгляд позволяет быстрее влиться в новый коллектив, понять цели и задачи команды, зафиксировать их для будущих сотрудников.
А у вас в компании используется ли какая-нибудь техника для синхронизации команды и ускорения адаптации новых членов команды?
В моей эхо-камере только и разговоров, что о ChatGPT. Подкину немного, поскольку сам начинаю все чаще его использовать. Ранее я уже писал, как подключиться к основному сервису, но для коротких запросов, не подразумевающих диалога, я использую один из бесплатных ботов в Телеграме - 30 запросов в сутки вполне достаточно для моих текущих задач.
Хочу поделиться, какие запросы и правила их построения я чаще всего использую.
1. Структурирование ответа - в запросе мы сразу задаем структуру ответа, который хотим получить.
Придумай несколько идей для статьи в блоге о ретро автомобилях. Используй этот формат:
[краткое изложение идеи]
[название и подзаголовок для длинного поста в блоге, основанного на этой идее]
[название и подзаголовок для поста блоге в виде списка, основанного на этой идее]
[возможная целевая аудитория для этой идеи за пределами сообщества]
Можно управлять форматом ответа - разбей результат на абзацы, он должен легко и быстро читаться, оформи в виде нумерованного списка, оформи в виде таблицы с заголовоками "А", "В" и т.д.
Можно накладывать ограничения "
2. Ролевые запросы - в запросе предлагаем языковой модели представить от чьего имени она будет давать ответ. Это не обязательно может быть человек или профессия (продакт менеджер, юрист, Instagram блогер), это может быть и какая-то система (Linux терминал, база данных SQL).
Представь, что ты продакт менеджер B2B SaaS сервиса для "...". Опиши, как бы ты его улучшил.
Или, Напиши текст по теме "..." в стиле юриста.
3. Генерация инструкций
Напиши, как пользоваться плагином "..." для Figma. Основные функции, особенности работы, как установить.
4. Создание заголовков
Придумай [количество] [характеристика стиля] заголовков для сценария видео на Youtube по [теме] [используя сильные слова вызывающие эмоции] [содержащие числа или данные] - всё, что в скобках можно менять под свои требования.
5. Обучение
Объясни детально, понятно, как будто мне 5 лет, без использования маркетинговой лексики, с примерами, как Илон Маск, студентов университета.
Опиши ежедневный план обучения по теме "..." на 2 недели.
6. Работа продакт менеджера
Опиши функции типовго сервиса/приложения для "..."
Каких функций не хватает сервису/приложению "..."
Опиши PRD для сервиса/функции "..."
Опиши типичного пользователя сервиса "..." Укажи какие у них стимулы, барьеры и возражения. Что должна учитывать маркетинговая кампания для их привлечения. Какие функции сервиса им потребуются.
7. При работе с ChatGPT через их сайт в режиме диалога самая полезная функция - это уточние деталей и просьба развернуть ответ:
Опиши пункт Х подробнее с деталями и количественными данными.
Для пункта Х приведи 3 примера.
А вы как часто используете ChatGPT?
Хоть я и не фанат Стива Джобса, как один из моих бывших руководителей - у него даже портрет Джобса на стене висел, но всегда интересно заглянуть в мыслительные процессы и изнанку ежедневной работы столь неординарного человека.
Поэтому я и прочитал практически все книги о Джобсе, среди которых была одна странная книжка про то, как он писал емейлы. Автор книжки просто собрал в интернете все истории про то, когда Джобс сам отвечал на письма в Apple от клиентов и журналистов и что он при этом ответил. Например, ответ на письмо одного назойливого фаната был всего из пары слов - "Fuck off" :)
И вот вчера увидел новость, что проект "Архив Стива Джобса" опубликовал целую книгу "Make something wonderful", составленную из емейлов, выступлений и интервью Джобса. Кажется, что эта книга будет более информативной относительно стиля работы и общения Джобса, чем указанная выше странная книжка.
Книгу, опубликованную архивом, можно бесплатно скачать на сайте архива в epub или почитать там же онлайн - https://stevejobsarchive.com/book
Обожаю составлять списки, поэтому вот вам список бесплатных видео курсов и лекций по управлению продуктами на русском, которые есть на Youtube
1️⃣ Курс Product management (2021) от VK Team
user-ef8fy2sm4u">2️⃣ Канал с лекциями по управлению проектами и продуктом от Академии Яндекса
3️⃣ Курс Product management от акселератора Цифра
4️⃣ Product Manager IT проектов от OTUS
5️⃣ Курс Создание программного продукта и управление его развитием от Acronis (ссылка на первую лекцию, текстовую расшифровку курса также можно найти на Habr)
6️⃣ softdevmgmt">Курс Менеджмент разработки ПО
7️⃣ Курс по Jobs to be Done от Tilda
8️⃣ Сборник лекций по Product Management от LeadStartup (на оригинальном канале они раскиданы по разным плейлистам)
Как профессионально делать заметки о встречах
Буду краток.
1. Фиксируем кто был на встрече - имя, фамилия, если были внешние компании, то компания и если есть должность
2. Фиксируем дату встречи
Когда пишем кем-то сказанное, то фиксируем кто именно это сказал
3. Фиксируем договоренности в формате - дата начала работ, дата окончания работ, предполагаемые действия, кто исполнитель, кто ответственный
Если есть привычка, то это можно делать в электронном виде - по документу на повторяющиеся встречи. Но мне обычно хватает ежедневника, привычка работы с бумагой и можно писать когда сам делаешь презентацию на встрече и шаришь свой экран.
Но электронное конечно удобней с точки зрения поиска и более жёстко можно задать структуру.
Вот такие 3 простых правила, которые позволят вам держать все под контролем.
3. Следующий блок - это собственно сама безопасность. Поскольку у нас цель разместить продукт в публичном облаке, при этом в продукте есть обработка персональных данных и других видов тайн, требующая определенного уровня защищённости, то сваливать все это на безопасников совсем неправильно. Именно продакту стоит посмотреть влияние функций продукта на безопасность - выключение ряда функций может радикально повысить безопасность, не влияя на общую функциональность продукта. Также необходимо проверить, какие операции с продуктом не покрыты его собственными функциями или настройками. Например, в нашем случае, проектная кастомизация частично делалась через прямые операции с базой данных. Соответственно такое надо или превращать в UI или выносить в предустановки сервиса.
Также стоит проверить все интеграции с другими системами - они тоже должны быть покрыты требованиями к безопасности, а безопасники порой про эти нюансы забывают.
4. Далее стоит заняться бизнес-процессами. Нужно покрыть бизнес-процессами весь путь клиента через продукт - от заявки клиента, через пресейл, поставку продукта, его эксплуатацию, развитие продукта до вывода из эксплуатации и завершения работы с клиентом. В моем случае получилось более 90 отдельных под-процессов, отражающих специфику продукта и работы с ним. Не стоит ожидать, что получится просто работать в рамках уже существующих процессов в компании. Например, в моем случае существующие процессы в компании никак не были описаны, большую часть нужных процессов нужно строить в рамках продуктовой команды с нуля и с новыми штатными единицами. А это дополнительный бюджет и организационные изменения. Также все бизнес-процессы, выходящие за периметр продуктовой команды, нужно согласовать с руководством соответствующих функций, поскольку им тоже может потребоваться дополнительный штат для работы с вами и эти затраты стоит учитывать в общем бюджете продукта.
6. Поскольку одной из целей превращения продукта в SaaS было исключение проектных работ, то следующим шагом беремся за них. Для тех кто не в теме, поясню - проектные работы это не про проектирование, а отдельный проект по кастомизации платформы, включающий проектирование, создание архитектуры, разработку, devops операции и еще десятки других работ. Источником нужной информации будут паспорта выполненных проектов, типовые оценки проектных работ. Необходимо выделить те операции и данные, которые мы хотим стандартизировать. Например, если в рамках проектных работ под каждого клиента писалось отдельное ТЗ, то в рамках SaaS достаточно одного типового описания функций продукта. Определенные справочники информации или информационные модели в продукте начинают прекрасно унифицироваться в рамках заданных нами критериев SaaS, хотя до этого это могла быть объемная и дорогостоящая проектная работа. Завершив анализ проектных работ, мы получим перечень однократных операций по унификации, которые нам нужно будет выполнить до запуска продукта, чтобы уложить его в наши критерии к SaaS, перечень функций продукта, которые надо исключить в SaaS версии, а также перечень новых артефактов и документов, которые потребуются при взаимодействии с клиентом.
7. После прохождения перечисленных этапов можно отдавать все в техническую проработку архитектору, а самому стоит взяться за создание лицензионной политики. К этому этапу мы уже обогащены знаниями по всем требуемым расходам на запуск и эксплуатацию продукта и поэтому можем отталкиваться от них в расчетах ценообразования. Можно сравнить с теми гипотезами, что мы ранее писали в обосновании запуска SaaS и удивиться насколько мы заблуждались.
8. Наконец финальный этап работы продакта - подготовить материалы для пресейла и маркетинга - презентации, информация для лендинга, пресс-релиза по запуску, описания функций, лицензионной политики, схем выбора типовых сайзингов и т.д. и т.п. В идеале, все что требует расчетов, типа, стоимости лицензий, сайзингов, остатка проектных работ (с ходу на 100% от них вряд ли получится избавиться) должно быть покрыто калькуляторами.
2/3