Как продуктовый подход помог при разработке сервиса «Европротокол онлайн»
Мне очень нравятся статьи с кейсами. Далее будет кейс от разработчиков Госуслуг с продуктовым подходом для сервиса «Европротокол онлайн».
1. Из-за сложности оформления европротокола и необходимости организации взаимодействия между разными независимыми организациями было несколько подходов к реализации сервиса. В итоге было принято решение собрать команду, по-новому взглянуть на то, что сделано, и уже после этого довести сервис до конечного пользователя.
2. Продуктовый подход подразумевает, что во главе угла ставится реальная польза продукта, сервиса, услуги. Разработчик наравне с заказчиком разделяет ответственность за финальный результат. Мы изучаем рынок, формулируем и валидируем гипотезы через эксперименты, прорабатываем пользовательские пути и готовим решение с учётом минимальных сроков и бюджетов.
3. Ключевой момент — польза: проведение исследований. Нам важно было получить ответы на следующие вопросы:
• Есть ли у пользователей потребность в электронном европротоколе в приложении «Госуслуги Авто»?
• На какую долю рынка (количество оформленных европротоколов) мы можем рассчитывать?
• Что мотивирует/демотивирует водителей использовать электронный европротокол?
• Какое время потребуется водителю для заполнения европротокола в нашем приложении?
• Какой формат оформления удобен: когда два пользователя, каждый со своего устройства, заполняют бланк, или когда один заполняет, а второй подтверждает?
4. Использованный подход дал нам ряд важных преимуществ:
• экономию бюджета за счёт раннего выявления слабых мест и реализации более удобного варианта сервиса;
• быструю разработку и скорый time to market за счёт полного понимания требований к продукту и конкретно к каждому члену команды;
• целевое позиционирование сервиса и быстрый рост его востребованности за счёт точного выявления ключевых потребностей пользователей и прямого, неискажённого восприятия их в процессе разработки.
Рекомендую посмотреть полный текст новой статьи на Хабре, где Наталья Рудометова, старший менеджер по продукту РТЛабс, рассказывыет и показывает, что стоит за тем, чтобы упросить такой, чаще всего неприятный, процесс?
Какие грабли собрала команда, чему научилась и что получилось в конце? Читайте по ссылке.
Информация предоставлена АО "РТ Лабс"
Мне очень нравятся статьи с кейсами. Далее будет кейс от разработчиков Госуслуг с продуктовым подходом для сервиса «Европротокол онлайн».
1. Из-за сложности оформления европротокола и необходимости организации взаимодействия между разными независимыми организациями было несколько подходов к реализации сервиса. В итоге было принято решение собрать команду, по-новому взглянуть на то, что сделано, и уже после этого довести сервис до конечного пользователя.
2. Продуктовый подход подразумевает, что во главе угла ставится реальная польза продукта, сервиса, услуги. Разработчик наравне с заказчиком разделяет ответственность за финальный результат. Мы изучаем рынок, формулируем и валидируем гипотезы через эксперименты, прорабатываем пользовательские пути и готовим решение с учётом минимальных сроков и бюджетов.
3. Ключевой момент — польза: проведение исследований. Нам важно было получить ответы на следующие вопросы:
• Есть ли у пользователей потребность в электронном европротоколе в приложении «Госуслуги Авто»?
• На какую долю рынка (количество оформленных европротоколов) мы можем рассчитывать?
• Что мотивирует/демотивирует водителей использовать электронный европротокол?
• Какое время потребуется водителю для заполнения европротокола в нашем приложении?
• Какой формат оформления удобен: когда два пользователя, каждый со своего устройства, заполняют бланк, или когда один заполняет, а второй подтверждает?
4. Использованный подход дал нам ряд важных преимуществ:
• экономию бюджета за счёт раннего выявления слабых мест и реализации более удобного варианта сервиса;
• быструю разработку и скорый time to market за счёт полного понимания требований к продукту и конкретно к каждому члену команды;
• целевое позиционирование сервиса и быстрый рост его востребованности за счёт точного выявления ключевых потребностей пользователей и прямого, неискажённого восприятия их в процессе разработки.
Рекомендую посмотреть полный текст новой статьи на Хабре, где Наталья Рудометова, старший менеджер по продукту РТЛабс, рассказывыет и показывает, что стоит за тем, чтобы упросить такой, чаще всего неприятный, процесс?
Какие грабли собрала команда, чему научилась и что получилось в конце? Читайте по ссылке.
Информация предоставлена АО "РТ Лабс"
Кому подходит Scrum, а кому Kanban?
- Scrum хорошо подходит в условиях неопределенности. Когда у вас есть только гипотезы, и вы еще не знаете верны они или нет. Акцент на скорости, метриках продукта и обратной связи от пользователей. Задача сформировать гипотезы в виде User Stories (US) и как можно быстрее запустить спринт. Мы тратим время на ресурсоемкие ритуалы Scrum. Именно они помогают сырую US как-то оценить, вовремя подправить и быстро обновить на проде, что позволяет своевременно собрать метрики, и сделать выводы.
Без настройки продуктовых метрик и без интервью с пользователями не обойтись. Чем быстрее и качественнее мы будем собирать данные, тем быстрее и правильнее будут наши решения. Ритуалы: Poker планирование и замер скорости путем закрытия Story Points на ежедневных встречах (Stand Up). Анализируем Burn Down Chart на ретроспективе.
- Kanban лучше подходит когда задачи расписаны на месяцы и каждый шаг необходимо согласовывать. Мы растягиваем процесс, но в итоге имеем согласованный и качественный релиз. Подробная доска поможет вам и ЗЛ увидеть узкие места. Установите WIP-лимиты (Work In Progress), например: больше одной задачи разработчикам в работу не брать.
Процесс закрытия задач последовательный, согласованный и поэтому требует больше времени. Вы можете параллельно запускать в работу несколько US, возвращать задачу на предыдущий этап и добавлять в любое время новую. Постоянно настраивать и улучшать доску под себя и свои нужды, устраняя узкие места и обеспечивая непрерывный поток. Мы знаем кто, что и когда делает и видим все этапы конвейера.
Если вас замучали «эджайлом» или вы сами мучаете им вашу команду, то этот выпуск подкаста «Магнитное Поле» – для вас! Потому что в нем Всеволод Сыров (Agile lead Магнита) как раз объясняет, нужен ли в каждой команде agile, как собрать идеальную команду и выстроить в ней процессы, как найти ее проблемы и решить, а также каким образом все-таки убедить всех «стейкхолдеров» договориться.
Это уже пятый выпуск подкаста «Магнитное Поле», который совместно записывают Завтракаст и IT-команда ритейлера Магнит. В предыдущих выпусках обсуждали Data Governance, современные облачные решения и микросервисы, IT HR, ecom и многое другое, так что стоит обратить внимание.
Ссылка в подкаст-сервисе и на YouTube-канале Завтракаста.
- Scrum хорошо подходит в условиях неопределенности. Когда у вас есть только гипотезы, и вы еще не знаете верны они или нет. Акцент на скорости, метриках продукта и обратной связи от пользователей. Задача сформировать гипотезы в виде User Stories (US) и как можно быстрее запустить спринт. Мы тратим время на ресурсоемкие ритуалы Scrum. Именно они помогают сырую US как-то оценить, вовремя подправить и быстро обновить на проде, что позволяет своевременно собрать метрики, и сделать выводы.
Без настройки продуктовых метрик и без интервью с пользователями не обойтись. Чем быстрее и качественнее мы будем собирать данные, тем быстрее и правильнее будут наши решения. Ритуалы: Poker планирование и замер скорости путем закрытия Story Points на ежедневных встречах (Stand Up). Анализируем Burn Down Chart на ретроспективе.
- Kanban лучше подходит когда задачи расписаны на месяцы и каждый шаг необходимо согласовывать. Мы растягиваем процесс, но в итоге имеем согласованный и качественный релиз. Подробная доска поможет вам и ЗЛ увидеть узкие места. Установите WIP-лимиты (Work In Progress), например: больше одной задачи разработчикам в работу не брать.
Процесс закрытия задач последовательный, согласованный и поэтому требует больше времени. Вы можете параллельно запускать в работу несколько US, возвращать задачу на предыдущий этап и добавлять в любое время новую. Постоянно настраивать и улучшать доску под себя и свои нужды, устраняя узкие места и обеспечивая непрерывный поток. Мы знаем кто, что и когда делает и видим все этапы конвейера.
Если вас замучали «эджайлом» или вы сами мучаете им вашу команду, то этот выпуск подкаста «Магнитное Поле» – для вас! Потому что в нем Всеволод Сыров (Agile lead Магнита) как раз объясняет, нужен ли в каждой команде agile, как собрать идеальную команду и выстроить в ней процессы, как найти ее проблемы и решить, а также каким образом все-таки убедить всех «стейкхолдеров» договориться.
Это уже пятый выпуск подкаста «Магнитное Поле», который совместно записывают Завтракаст и IT-команда ритейлера Магнит. В предыдущих выпусках обсуждали Data Governance, современные облачные решения и микросервисы, IT HR, ecom и многое другое, так что стоит обратить внимание.
Ссылка в подкаст-сервисе и на YouTube-канале Завтракаста.
❤1👍1
Дизайн-аутсорсинг в тренде
Вот важные инсайты:
— Актуальность аутсорсинга на рынке растет. Особенно это касается крупного бизнеса с развитой офлайн и диджитал-коммуникацией в разных каналах и сформировавшейся дизайн-системой.
— Внешнюю команду привлекают, когда нужен быстрый и качественный результат, когда нет необходимости расширять свой штат или самостоятельно искать подходящих специалистов.
— Выбирая сотрудников на аутсорс, компании обращают внимание на их умение планировать бюджет наперед, грамотно выстраивать все процессы.
— Среди студий набирает популярность тренд на сближение с клиентом: общение на равных и персональный мэтч.
Также благодаря исследованию, появился пилот — тестовый формат взаимодействия для новых клиентов. Это демо-версия будущей работы, которая позволяет реализовать небольшой объем задач на коротком отрезке времени и почувствовать коннект с подрядчиком.
Еще больше инсайтов читайте в статье на vc.
Вот важные инсайты:
— Актуальность аутсорсинга на рынке растет. Особенно это касается крупного бизнеса с развитой офлайн и диджитал-коммуникацией в разных каналах и сформировавшейся дизайн-системой.
— Внешнюю команду привлекают, когда нужен быстрый и качественный результат, когда нет необходимости расширять свой штат или самостоятельно искать подходящих специалистов.
— Выбирая сотрудников на аутсорс, компании обращают внимание на их умение планировать бюджет наперед, грамотно выстраивать все процессы.
— Среди студий набирает популярность тренд на сближение с клиентом: общение на равных и персональный мэтч.
Также благодаря исследованию, появился пилот — тестовый формат взаимодействия для новых клиентов. Это демо-версия будущей работы, которая позволяет реализовать небольшой объем задач на коротком отрезке времени и почувствовать коннект с подрядчиком.
Еще больше инсайтов читайте в статье на vc.
vc.ru
Аутсорсинг в дизайне: как устроена и кому подходит дизайн-поддержка? — Дизайн на vc.ru
Наша студия дизайна maryco взяла интервью у крупных игроков рынка Skillhunt, «Сравни», TRASSIR Cloud, «Анабар», Training Data, а ключевыми инсайтами поделилась в этой статье.
Пять стратегических причин, по которым действительно стоит создавать новую бизнес-модель
⁃ Когда есть шанс за счет инновационного продукта удовлетворить нужды большой группы потенциальных потребителей, рынка для которых пока нет — существующие предложения слишком дороги или сложны для них. Речь идет, скажем, о возможности «демократизировать» продукт на развивающихся рынках, примером чего служит автомобиль Nano компании Tata Motors.
⁃ Когда есть шанс хорошо заработать на принципиально новой технологии, создав для нее новую бизнес-модель (Apple и плееры mp3), или выгодно воспользоваться опробованной технологией на совершенно новом рынке (скажем, применив военные технологии в «гражданских» товарах или наоборот).
⁃ Когда есть шанс создать продукт/услугу для выполнения «работы», которую прежде никто не пытался выполнять вообще или выполнять именно таким образом. Чаще всего такая возможность выпадает в отраслях, которые чересчур увлекаются сегментацией товаров и потребителей. Из-за этого компаниям приходится постоянно совершенствовать свои продукты, и в результате то, что еще недавно было новым и престижным, становится стандартным. Предназначая свои продукты для выполнения той или иной «работы», компания может изменить рентабельность отрасли.
⁃ Когда бизнесу угрожают инноваторы, нацеленные на нижний ценовой сегмент. Если автомобиль Nano, как и задумано, окажется по карману рядовым индийцам, это сильно усложнит жизнь другим автопроизводителям. Похоже, тогда события будут развиваться по сценарию 30-летней давности: тогда металлургические мини-заводы, производившие дешевую и поначалу не слишком качественную сталь, начали вытеснять комбинаты с полным циклом.
⁃ Когда смещается «центр тяжести» конкурентной борьбы. Со временем, и это неизбежно, изменяются сами представления о приемлемом качестве продукта, то есть о стандартах для того или иного рынка. В результате продукция основных игроков отрасли «подтягивается» к этим стандартам и вся она становится более или менее одинаковой. Компании Hilti нужно было изменить бизнес-модель отчасти потому, что на глобальный рынок вышли «дешевые» производители; со своей продукцией нижнего ценового диапазона, но приемлемого при такой стоимости качества они начали потихоньку оттеснять в сторону производителей дорогого высококлассного оборудования.
⁃ Когда есть шанс за счет инновационного продукта удовлетворить нужды большой группы потенциальных потребителей, рынка для которых пока нет — существующие предложения слишком дороги или сложны для них. Речь идет, скажем, о возможности «демократизировать» продукт на развивающихся рынках, примером чего служит автомобиль Nano компании Tata Motors.
⁃ Когда есть шанс хорошо заработать на принципиально новой технологии, создав для нее новую бизнес-модель (Apple и плееры mp3), или выгодно воспользоваться опробованной технологией на совершенно новом рынке (скажем, применив военные технологии в «гражданских» товарах или наоборот).
⁃ Когда есть шанс создать продукт/услугу для выполнения «работы», которую прежде никто не пытался выполнять вообще или выполнять именно таким образом. Чаще всего такая возможность выпадает в отраслях, которые чересчур увлекаются сегментацией товаров и потребителей. Из-за этого компаниям приходится постоянно совершенствовать свои продукты, и в результате то, что еще недавно было новым и престижным, становится стандартным. Предназначая свои продукты для выполнения той или иной «работы», компания может изменить рентабельность отрасли.
⁃ Когда бизнесу угрожают инноваторы, нацеленные на нижний ценовой сегмент. Если автомобиль Nano, как и задумано, окажется по карману рядовым индийцам, это сильно усложнит жизнь другим автопроизводителям. Похоже, тогда события будут развиваться по сценарию 30-летней давности: тогда металлургические мини-заводы, производившие дешевую и поначалу не слишком качественную сталь, начали вытеснять комбинаты с полным циклом.
⁃ Когда смещается «центр тяжести» конкурентной борьбы. Со временем, и это неизбежно, изменяются сами представления о приемлемом качестве продукта, то есть о стандартах для того или иного рынка. В результате продукция основных игроков отрасли «подтягивается» к этим стандартам и вся она становится более или менее одинаковой. Компании Hilti нужно было изменить бизнес-модель отчасти потому, что на глобальный рынок вышли «дешевые» производители; со своей продукцией нижнего ценового диапазона, но приемлемого при такой стоимости качества они начали потихоньку оттеснять в сторону производителей дорогого высококлассного оборудования.
Какие фразы помогают донести точку зрения и инсайты
I suppose (that) — Я полагаю (считаю, думаю) - По сути, то же самое, что и «I think».
I suppose, you have a back-up plan. — Я так думаю, у тебя есть запасной план.
I belive (that) — Я думаю, полагаю, считаю (букв.: «Я верю»)
belive that some of your calculations might be slightly incorrect. — Я полагаю, что некоторые из ваших подсчетов могут быть немножко неверны.
I suspect (that) — Я подозреваю
I guess (that) — Я думаю. «Guess» буквально значит «догадываться», но в современном английском, особенно, американском варианте, это выражение очень часто используют как синоним «I think».
I reckon (that) — Думаю, что. Выражение «I reckon» (букв. «я считаю, полагаю») используется как синоним «I think», «I guess», но оно характерно для южных штатов США (хотя встречается и за их пределами).
I’m sure (that) — Я уверен
I have no doubt (that) — Я не сомневаюсь, что. Еще один способ выразить уверенность, пожалуй, даже более твердую, чем «I’m sure».
I am positive (that) — Я твердо уверен, что
In my opinion — По моему мнению. «Opinion» — это мнение, точка зрения. Вы также можете сказать «In my humble opinion» — «По моему скромному мнению».
From my point of view (perspective) — С моей точки зрения. «Point of view» — это точка зрения, а «perspective» — подход к рассмотрению какого-то вопроса. В контексте выражения мнения эти слова — синонимы.
As for me — Как по мне / Что касается меня; «As for me» — это простой неформальный способ выразить мнение.
To my mind — По-моему, по моему мнению. «Mind» — это буквально «разум, ум». Другими словами, «to my mind» значит «по моему мнению», «по-моему».
My impression is (that) — У меня такое впечатление, что. Используется, когда мы делимся мнением, своей точкой зрения.
To my knowledge — Насколько я знаю. Несмотря на то, что «mind» и «knowlege» значат похожие вещи (ум и знание), выражение «to my knowledge» имеет несколько другое значение, чем «to my mind». Оно значит «насколько я знаю».
As far as I know — Насколько я знаю
As far as I remember — Насколько я помню
As far as I can see — Насколько я вижу
It seems to me (that) — Мне кажется, что
appears to me (that) — Кажется / Похоже на то, что / Мне представляется, что
«It appears» и «It seems» близки по смыслу, но не идентичны. «It seems» — это просто «кажется», а «it appears» — это когда у вас сложилось некое впечатление на основе чего-то увиденного, услышанного, на основе догадки или информации.
It looks like — Похоже, что. «It looks like» или просто «Looks like» — очень употребительное в повседневной речи выражение. Разумеется, ему не место в официальной речи или тексте.
With all due respect — При всем моем уважении; Как и его аналог в русском языке, это выражение — вежливый способ возразить, не согласиться. Часто за ним следует «I think/suppose/believe that».
Язык — основной инструмент продакта. Даже на русском непросто выразить свои мысли так, чтобы всё было понятно и никого не задело. А если продакт общается с командой на английском, дело становится ещё сложнее.
В карточках собрали пять ситуаций, где продакту важно точно и аккуратно донести свою мысль, чтобы всё заработало. А ещё — рассказали о том, как получить скидку 20% на курс английского для продактов. Если вам такое интересно — добро пожаловать на сайт.
→ Курс «Продакт-менеджер».
→ Курс «Английский для менеджеров продукта».
→ Правила акции.
I suppose (that) — Я полагаю (считаю, думаю) - По сути, то же самое, что и «I think».
I suppose, you have a back-up plan. — Я так думаю, у тебя есть запасной план.
I belive (that) — Я думаю, полагаю, считаю (букв.: «Я верю»)
belive that some of your calculations might be slightly incorrect. — Я полагаю, что некоторые из ваших подсчетов могут быть немножко неверны.
I suspect (that) — Я подозреваю
I guess (that) — Я думаю. «Guess» буквально значит «догадываться», но в современном английском, особенно, американском варианте, это выражение очень часто используют как синоним «I think».
I reckon (that) — Думаю, что. Выражение «I reckon» (букв. «я считаю, полагаю») используется как синоним «I think», «I guess», но оно характерно для южных штатов США (хотя встречается и за их пределами).
I’m sure (that) — Я уверен
I have no doubt (that) — Я не сомневаюсь, что. Еще один способ выразить уверенность, пожалуй, даже более твердую, чем «I’m sure».
I am positive (that) — Я твердо уверен, что
In my opinion — По моему мнению. «Opinion» — это мнение, точка зрения. Вы также можете сказать «In my humble opinion» — «По моему скромному мнению».
From my point of view (perspective) — С моей точки зрения. «Point of view» — это точка зрения, а «perspective» — подход к рассмотрению какого-то вопроса. В контексте выражения мнения эти слова — синонимы.
As for me — Как по мне / Что касается меня; «As for me» — это простой неформальный способ выразить мнение.
To my mind — По-моему, по моему мнению. «Mind» — это буквально «разум, ум». Другими словами, «to my mind» значит «по моему мнению», «по-моему».
My impression is (that) — У меня такое впечатление, что. Используется, когда мы делимся мнением, своей точкой зрения.
To my knowledge — Насколько я знаю. Несмотря на то, что «mind» и «knowlege» значат похожие вещи (ум и знание), выражение «to my knowledge» имеет несколько другое значение, чем «to my mind». Оно значит «насколько я знаю».
As far as I know — Насколько я знаю
As far as I remember — Насколько я помню
As far as I can see — Насколько я вижу
It seems to me (that) — Мне кажется, что
appears to me (that) — Кажется / Похоже на то, что / Мне представляется, что
«It appears» и «It seems» близки по смыслу, но не идентичны. «It seems» — это просто «кажется», а «it appears» — это когда у вас сложилось некое впечатление на основе чего-то увиденного, услышанного, на основе догадки или информации.
It looks like — Похоже, что. «It looks like» или просто «Looks like» — очень употребительное в повседневной речи выражение. Разумеется, ему не место в официальной речи или тексте.
With all due respect — При всем моем уважении; Как и его аналог в русском языке, это выражение — вежливый способ возразить, не согласиться. Часто за ним следует «I think/suppose/believe that».
Язык — основной инструмент продакта. Даже на русском непросто выразить свои мысли так, чтобы всё было понятно и никого не задело. А если продакт общается с командой на английском, дело становится ещё сложнее.
В карточках собрали пять ситуаций, где продакту важно точно и аккуратно донести свою мысль, чтобы всё заработало. А ещё — рассказали о том, как получить скидку 20% на курс английского для продактов. Если вам такое интересно — добро пожаловать на сайт.
→ Курс «Продакт-менеджер».
→ Курс «Английский для менеджеров продукта».
→ Правила акции.
Telegram
Sergey Koloskov in Better write product manager
Как будет развиваться нетворкинг-менеджмент?
Перефразировав известную аксиому о том, что удача приходит к тем, кто ее не ждет, можно сказать, что лучший нетворк случается там, где его не ищешь.
Да, привычнее считать, что самые полезные знакомства происходят на специальных мероприятиях, в программе которых указано про «качественный нетворкинг», все приходят туда со стопкой визиток и целью установить пару десятков связей и потом «никогда не есть в одиночестве».
Тренды текущего Нетворк-менеджемента вижу в следующем:
1. Сообщество и рост при помощи сообщества становится основой для большего числа компаний
2. Набирает обороты маркетинг, основанный на сообществах
3. Комьюнити-менеджмент сближается с инфлюенс-маркетингом и адвокацией персонала
4. Мероприятия всё больше интегрируются с сообществами
5. Появляются «поп-ап» комьюнити
6. Сообщества становятся аналогом поисковикам и SEO
7. Рост числа подписок, микроплатежей и сообществ DAO
8. Технологии: битва между «все в одном» и «лучший в своем роде»
9. Посредственные сообщества вымирают
10. Люди мигрируют из социальных сетей в небольшие качественные сообщества
11. Бренды коллекционируют готовые сообщества
12. Аналитика сообществ взрослеет
13. ИИ не заменит комьюнити-менеджеров, но дополнит их
14. Лидеры сообщества по-прежнему будут иметь решающее значение для успеха сообщества
Слабые же связи, в том числе спонтанные знакомства, часто «выстреливают» инсайтами, совместными проектами, новыми возможностями и вообще новыми орбитами для личностного и бизнес-роста.
Почему так происходит? Потому что вы соприкасаетесь с совершенно незнакомым опытом, в котором можете разглядеть полезное для себя, найти то, что называют точкой соприкосновения. И при этом вам, вероятно, достаточно этой точки, расширять границы общения от вас не требуется.
Даже краткосрочное получение совместного опыта, как во время недели на катамаранах на Сейшелах, создает условия для естественного нетворкинга никогда не пересекающихся в «обычной деловой жизни» людей. При этом именно в таких условиях они говорят о главном для себя, о том, что не озвучишь больше нигде, рассуждают вслух о том, о чем говорили лишь сами с собой. Комментарий к этим мыслям, узнавание, что кто-то думал о том же, что и я, и продвинулся дальше, дает молниеносную реакцию для нового взгляда на себя, дело, траекторию развития бизнеса.
Перефразировав известную аксиому о том, что удача приходит к тем, кто ее не ждет, можно сказать, что лучший нетворк случается там, где его не ищешь.
Да, привычнее считать, что самые полезные знакомства происходят на специальных мероприятиях, в программе которых указано про «качественный нетворкинг», все приходят туда со стопкой визиток и целью установить пару десятков связей и потом «никогда не есть в одиночестве».
Тренды текущего Нетворк-менеджемента вижу в следующем:
1. Сообщество и рост при помощи сообщества становится основой для большего числа компаний
2. Набирает обороты маркетинг, основанный на сообществах
3. Комьюнити-менеджмент сближается с инфлюенс-маркетингом и адвокацией персонала
4. Мероприятия всё больше интегрируются с сообществами
5. Появляются «поп-ап» комьюнити
6. Сообщества становятся аналогом поисковикам и SEO
7. Рост числа подписок, микроплатежей и сообществ DAO
8. Технологии: битва между «все в одном» и «лучший в своем роде»
9. Посредственные сообщества вымирают
10. Люди мигрируют из социальных сетей в небольшие качественные сообщества
11. Бренды коллекционируют готовые сообщества
12. Аналитика сообществ взрослеет
13. ИИ не заменит комьюнити-менеджеров, но дополнит их
14. Лидеры сообщества по-прежнему будут иметь решающее значение для успеха сообщества
Слабые же связи, в том числе спонтанные знакомства, часто «выстреливают» инсайтами, совместными проектами, новыми возможностями и вообще новыми орбитами для личностного и бизнес-роста.
Почему так происходит? Потому что вы соприкасаетесь с совершенно незнакомым опытом, в котором можете разглядеть полезное для себя, найти то, что называют точкой соприкосновения. И при этом вам, вероятно, достаточно этой точки, расширять границы общения от вас не требуется.
Даже краткосрочное получение совместного опыта, как во время недели на катамаранах на Сейшелах, создает условия для естественного нетворкинга никогда не пересекающихся в «обычной деловой жизни» людей. При этом именно в таких условиях они говорят о главном для себя, о том, что не озвучишь больше нигде, рассуждают вслух о том, о чем говорили лишь сами с собой. Комментарий к этим мыслям, узнавание, что кто-то думал о том же, что и я, и продвинулся дальше, дает молниеносную реакцию для нового взгляда на себя, дело, траекторию развития бизнеса.
Выстраивание грамотной стратегии развития интернет-продукта с помощью метрик и OKR
Использование информации, собранной с помощью метрик — правильное решение для онлайн-бизнеса. На практике работа с аналитическими данными может выглядеть примерно так:
1. Определите точный объем затрат. Рассчитайте, сколько средств вам понадобится для организации бизнес-процессов.
2. Изучите статистические данные, произведите расчеты основных показателей и составьте прогноз спроса на определенные товары в интернет-магазине. Параллельно рассчитайте объем прибыли.
3. Учитывая прогноз, определите, сколько средств предстоит вложить в закупку товара. Понимая разницу между доходом и совокупным объемом затрат, можно будет подсчитать сумму, которую предстоит потратить на развитие онлайн-магазина и привлечение покупателей.
4. Обязательно рассмотрите метрики поведения пользователей на сайте интернет-магазина. Выявите проблемные части веб-ресурса, оперативно устраните недочеты. Если все хорошо, клиенты успешно взаимодействуют с онлайн-магазином, целесообразно выделить средства на внедрение новых эффективных решений.
5. Внимательно изучите целевую аудиторию. Разработайте идею рекламной кампании, определитесь с платформой для размещения и рассчитайте, сколько денег для этого потребуется. Запускайте рекламу только на тех площадках, которые приводят вам потенциальных клиентов.
6. Собирайте информацию по метрикам систематически. При необходимости сразу же реагируйте на ситуацию, вносите изменения и составляйте объективные прогнозы. Насколько часто целесообразно проводить анализ данных по метрикам, каждому предстоит определить опытным путем. Но на стартовом этапе работы делать это нужно как можно чаще. Старайтесь не реже одного раза в неделю изучать соотношение прибыли и расходов, каждый день следить за эффективностью рекламных кампаний. Мониторинг данных по метрикам можно проводить реже, когда бизнес-проект устойчиво «встанет на ноги».
Использование информации, собранной с помощью метрик — правильное решение для онлайн-бизнеса. На практике работа с аналитическими данными может выглядеть примерно так:
1. Определите точный объем затрат. Рассчитайте, сколько средств вам понадобится для организации бизнес-процессов.
2. Изучите статистические данные, произведите расчеты основных показателей и составьте прогноз спроса на определенные товары в интернет-магазине. Параллельно рассчитайте объем прибыли.
3. Учитывая прогноз, определите, сколько средств предстоит вложить в закупку товара. Понимая разницу между доходом и совокупным объемом затрат, можно будет подсчитать сумму, которую предстоит потратить на развитие онлайн-магазина и привлечение покупателей.
4. Обязательно рассмотрите метрики поведения пользователей на сайте интернет-магазина. Выявите проблемные части веб-ресурса, оперативно устраните недочеты. Если все хорошо, клиенты успешно взаимодействуют с онлайн-магазином, целесообразно выделить средства на внедрение новых эффективных решений.
5. Внимательно изучите целевую аудиторию. Разработайте идею рекламной кампании, определитесь с платформой для размещения и рассчитайте, сколько денег для этого потребуется. Запускайте рекламу только на тех площадках, которые приводят вам потенциальных клиентов.
6. Собирайте информацию по метрикам систематически. При необходимости сразу же реагируйте на ситуацию, вносите изменения и составляйте объективные прогнозы. Насколько часто целесообразно проводить анализ данных по метрикам, каждому предстоит определить опытным путем. Но на стартовом этапе работы делать это нужно как можно чаще. Старайтесь не реже одного раза в неделю изучать соотношение прибыли и расходов, каждый день следить за эффективностью рекламных кампаний. Мониторинг данных по метрикам можно проводить реже, когда бизнес-проект устойчиво «встанет на ноги».
Лайфхаки, которые необходимы для перехода в продакт-менеджеры или аналитики
В последнее время приходит очень много обращений и запросов на консультации по вопросам, как переходить в новую профессию. Открыт к этим запросам, а потому и собрал несколько лайфхаков:
⁃ Если есть возможность, лучше не подсаживаться на «денежную иглу» неплохой работы, а сразу потратить время, подготовиться и устроиться на лучшую. Считаю, что так можно расти сильно быстрее. Если нет такой возможности, то нужно учиться работать по 60-80 часов в неделю
⁃ Проходить собеседования — отдельный самостоятельный навык, который отличается от навыка работать по специальности. Я при поиске первой работы продактом прошел более 150 отборов. Между ними много общего, но прокачивать их надо по-разному.
⁃ Чтобы не перегореть за время активной подготовки к новой работе, лучше идти в комфортном темпе. По этой причине можно готовиться самостоятельно, а, например, не идти на курсы.
⁃ Обратите внимание на самое важное. Это может прозвучать банально, но аналитическое мышление и problem-solving — возможно, самые важные вещи в работе аналитиком и продактом
⁃ Не будьте токсиками, будьте людьми, с которыми приятно работать, которым не страшно задать любой, даже самый глупый, вопрос, с которыми комфортно решать проблемы. Помогайте заинтересованным людям в тематических сообществах, и, возможно, кто-то из них станет вашим коллегой в будущем, и вы вместе будете делать клёвый продукт.
⁃ Основная проблема - это необходимость практики. Даже начинающему специалисту недостаточно читать книги и смотреть обучающие видео, чтобы улучшать свои навыки. В стартапе, если вы готовы с головой погрузиться в работу и брать большое количество задач. На стажировке, это отличная возможность войти в профессию: к вам приставят более опытного продакта, который делегирует вам часть своих обязанностей. В пет-проекте (мой выбор, кстати),что позволяет пройти все стадии развития продукта: от создания идеи и MVP, до поиска точек роста и новых возможностей. И курсы, где все необходимые знания собраны в единую программу, рассчитанную на поэтапное освоение профессии. Большинство курсов построены с упором на практику, а поддержка ментора позволит разобраться с непонятными вопросами.
Интересен также опыт как перешёл в IT в 30 лет продуктовый аналитик Avito Алексей Авраменко — читайте по ссылке.
В последнее время приходит очень много обращений и запросов на консультации по вопросам, как переходить в новую профессию. Открыт к этим запросам, а потому и собрал несколько лайфхаков:
⁃ Если есть возможность, лучше не подсаживаться на «денежную иглу» неплохой работы, а сразу потратить время, подготовиться и устроиться на лучшую. Считаю, что так можно расти сильно быстрее. Если нет такой возможности, то нужно учиться работать по 60-80 часов в неделю
⁃ Проходить собеседования — отдельный самостоятельный навык, который отличается от навыка работать по специальности. Я при поиске первой работы продактом прошел более 150 отборов. Между ними много общего, но прокачивать их надо по-разному.
⁃ Чтобы не перегореть за время активной подготовки к новой работе, лучше идти в комфортном темпе. По этой причине можно готовиться самостоятельно, а, например, не идти на курсы.
⁃ Обратите внимание на самое важное. Это может прозвучать банально, но аналитическое мышление и problem-solving — возможно, самые важные вещи в работе аналитиком и продактом
⁃ Не будьте токсиками, будьте людьми, с которыми приятно работать, которым не страшно задать любой, даже самый глупый, вопрос, с которыми комфортно решать проблемы. Помогайте заинтересованным людям в тематических сообществах, и, возможно, кто-то из них станет вашим коллегой в будущем, и вы вместе будете делать клёвый продукт.
⁃ Основная проблема - это необходимость практики. Даже начинающему специалисту недостаточно читать книги и смотреть обучающие видео, чтобы улучшать свои навыки. В стартапе, если вы готовы с головой погрузиться в работу и брать большое количество задач. На стажировке, это отличная возможность войти в профессию: к вам приставят более опытного продакта, который делегирует вам часть своих обязанностей. В пет-проекте (мой выбор, кстати),что позволяет пройти все стадии развития продукта: от создания идеи и MVP, до поиска точек роста и новых возможностей. И курсы, где все необходимые знания собраны в единую программу, рассчитанную на поэтапное освоение профессии. Большинство курсов построены с упором на практику, а поддержка ментора позволит разобраться с непонятными вопросами.
Интересен также опыт как перешёл в IT в 30 лет продуктовый аналитик Avito Алексей Авраменко — читайте по ссылке.
vc.ru
Как я перешёл в IT в 30 лет — бесплатно, без смс и без выгорания — Карьера на vc.ru
Привет! Меня зовут Лёша Авраменко, я хочу поделиться своим опытом перехода в IT. Раньше я работал в банке в отделе рисков, а с января 2022-го вышел продуктовым аналитиком в Авито.
Подборка книг для роста в сфере анализа требований
1. «Разработка требований к программному обеспечению» Карл Вигерс и Джой Битти
Классика среди всех книг по разработке требований. В книге подробно даются процессы сбора, выявления, обработки требований и работы с ними. По каждому процессу показан пример работы.
Благодаря книге можно получить определенные методы, которые помогут сократить сроки разработки и уменьшить количество ошибок. Книга довольно трудна для первого прочтения, поэтому начинать лучше с книг под пунктами два и три.
2. «Психбольница в руках пациентов, или почему высокие технологии сводят нас с ума» Алан Купер
Алан Купер первым заговорил о том, что проектирование продуктов должно осуществляться до непосредственной разработки и является этапом первостепенной важности. Большинство продуктов функционирует и взаимодействует с пользователями только на основе задумки создателей, игнорируя реальные потребности использования.
Из книги следует мысль, что для продукта повышение качества взаимодействия важнее, чем снижение издержек. Для конечных пользователя удобный продукт всегда предпочтителен, чем неудобный многофункциональный.
3. «UX-дизайн. Практическое руководство по проектированию опыта взаимодействия» Расс Унгер и Кэролайн Чендлер. Отличная книга для совсем начинающих специалистов. В книге даются основы основ проработки бизнес-идеи, определения требований, проведению интервью, подготовке документации и формированию взаимодействия пользователей и продукта.
Книга помогает понять, с чего следует начать в первую очередь, как одни этапы разработки продукта взаимодействуют с другими. Очень много примеров и шаблонов. Практически сразу же после прочтения книги можно приступить к работе.
4. «Современные методы описания функциональных требований к системам» Алистер Коберн
В оригинале книга называется "Writing Effective Use Cases", что наиболее полно отражает ее суть. В книге описаны методы и примеры создания юз кейсов на основе практического опыта автора. Книга помогает понять, как использовать юз кейсы при описании сложных многофункциональных систем и вариантов взаимодействия с ними.
5. «Пользовательские истории. Искусство гибкой разработки ПО» Джефф Паттон
Книга рассказывает про пользовательские истории (юзер стори) как о методе описания требований к проектируемому продукту.
Пользовательские истории довольно просто и доходчиво дают понимание заказчику, команде, пользователям о задачах и функциях разрабатываемой системы. Пользовательские истории находятся на более высоком уровне абстракции. На их основе удобно описывать сценарии взаимодействия (юз кейсы).
1. «Разработка требований к программному обеспечению» Карл Вигерс и Джой Битти
Классика среди всех книг по разработке требований. В книге подробно даются процессы сбора, выявления, обработки требований и работы с ними. По каждому процессу показан пример работы.
Благодаря книге можно получить определенные методы, которые помогут сократить сроки разработки и уменьшить количество ошибок. Книга довольно трудна для первого прочтения, поэтому начинать лучше с книг под пунктами два и три.
2. «Психбольница в руках пациентов, или почему высокие технологии сводят нас с ума» Алан Купер
Алан Купер первым заговорил о том, что проектирование продуктов должно осуществляться до непосредственной разработки и является этапом первостепенной важности. Большинство продуктов функционирует и взаимодействует с пользователями только на основе задумки создателей, игнорируя реальные потребности использования.
Из книги следует мысль, что для продукта повышение качества взаимодействия важнее, чем снижение издержек. Для конечных пользователя удобный продукт всегда предпочтителен, чем неудобный многофункциональный.
3. «UX-дизайн. Практическое руководство по проектированию опыта взаимодействия» Расс Унгер и Кэролайн Чендлер. Отличная книга для совсем начинающих специалистов. В книге даются основы основ проработки бизнес-идеи, определения требований, проведению интервью, подготовке документации и формированию взаимодействия пользователей и продукта.
Книга помогает понять, с чего следует начать в первую очередь, как одни этапы разработки продукта взаимодействуют с другими. Очень много примеров и шаблонов. Практически сразу же после прочтения книги можно приступить к работе.
4. «Современные методы описания функциональных требований к системам» Алистер Коберн
В оригинале книга называется "Writing Effective Use Cases", что наиболее полно отражает ее суть. В книге описаны методы и примеры создания юз кейсов на основе практического опыта автора. Книга помогает понять, как использовать юз кейсы при описании сложных многофункциональных систем и вариантов взаимодействия с ними.
5. «Пользовательские истории. Искусство гибкой разработки ПО» Джефф Паттон
Книга рассказывает про пользовательские истории (юзер стори) как о методе описания требований к проектируемому продукту.
Пользовательские истории довольно просто и доходчиво дают понимание заказчику, команде, пользователям о задачах и функциях разрабатываемой системы. Пользовательские истории находятся на более высоком уровне абстракции. На их основе удобно описывать сценарии взаимодействия (юз кейсы).
Как управлять удаленной командой в текущих реалиях
Принцип 1. К каждому сотруднику — свой подход. Оцените зрелость вашей удаленной команды. В ней одновременно могут быть и опытные специалисты с высокой самомотивацией, которые понимают цели и задачи бизнеса, и рядовые сотрудники, с которыми важно работать внимательнее. Проранжируйте членов команды с точки зрения их опыта, уровня мотивации и ответственности, чтобы найти баланс дисциплины и самоконтроля, необходимый каждому из них.
Принцип 2. Уважайте культурные особенности региона
В каждой компании есть корпоративная культура, которая задает определенные рамки коммуникации и подходы к работе. Однако помимо этого существует так называемый национальный культурный код, который не меняется десятилетиями, если вообще меняется. И самый умный выход — повернуть национальное многообразие удаленной команды в пользу бизнеса. Направляйте нужных людей для решения нужных задач и комбинируйте противоположные точки зрения.
Принцип 3. Поддерживайте коммуникацию с удаленными командами убедительнее, чем со стандартными
Многочисленные исследования подтверждают, что наши слова и голос отвечают только за половину передачи сообщения. Другая половина — невербальные сигналы: поза, положение относительно собеседника, выражение лица, взгляд. Очевидно, что в этом плане дистанционная коммуникация неполноценна, и чтобы сделать ее эффективной, нужно больше усилий.
Принцип 4. Выстраивайте горизонтальные связи
Удаленная команда тем эффективнее, чем крепче горизонтальные связи внутри нее. Здесь нет отличия от стандартных команд, но с одним исключением: с удаленной командой ситуация обстоит сложнее, ведь сотрудник офиса в Волгограде вряд ли выпьет утренний кофе с коллегой с Урала. Чтобы нивелировать это, вовлекайте разных членов своей команды в кросс-функциональные проекты — если необходимо, выдумывайте их. Такие проекты не только позволят сотрудникам лучше узнать бизнес, но и повысят мотивацию.
Принцип 5. Даже если команда удаленная, организуйте личные встречи по крайней мере раз в год
Составьте рабочее расписание, в которое будет включена сессия знакомства. Кроме нее включите в повестку дня воркшопы или брейнсторминг, которые помогут членам команды сформулировать глобальные цели и обсудить проблемы. И, конечно, важен неформальный тимбилдинг: совместные развлечения сплачивают команду.
Совершенно новый вызов - релокации, встал перед руководителями IT-команд в прошлом году. Когда команда релоцируется, то неизбежно меняются подходы к управлению.
Принцип 1. К каждому сотруднику — свой подход. Оцените зрелость вашей удаленной команды. В ней одновременно могут быть и опытные специалисты с высокой самомотивацией, которые понимают цели и задачи бизнеса, и рядовые сотрудники, с которыми важно работать внимательнее. Проранжируйте членов команды с точки зрения их опыта, уровня мотивации и ответственности, чтобы найти баланс дисциплины и самоконтроля, необходимый каждому из них.
Принцип 2. Уважайте культурные особенности региона
В каждой компании есть корпоративная культура, которая задает определенные рамки коммуникации и подходы к работе. Однако помимо этого существует так называемый национальный культурный код, который не меняется десятилетиями, если вообще меняется. И самый умный выход — повернуть национальное многообразие удаленной команды в пользу бизнеса. Направляйте нужных людей для решения нужных задач и комбинируйте противоположные точки зрения.
Принцип 3. Поддерживайте коммуникацию с удаленными командами убедительнее, чем со стандартными
Многочисленные исследования подтверждают, что наши слова и голос отвечают только за половину передачи сообщения. Другая половина — невербальные сигналы: поза, положение относительно собеседника, выражение лица, взгляд. Очевидно, что в этом плане дистанционная коммуникация неполноценна, и чтобы сделать ее эффективной, нужно больше усилий.
Принцип 4. Выстраивайте горизонтальные связи
Удаленная команда тем эффективнее, чем крепче горизонтальные связи внутри нее. Здесь нет отличия от стандартных команд, но с одним исключением: с удаленной командой ситуация обстоит сложнее, ведь сотрудник офиса в Волгограде вряд ли выпьет утренний кофе с коллегой с Урала. Чтобы нивелировать это, вовлекайте разных членов своей команды в кросс-функциональные проекты — если необходимо, выдумывайте их. Такие проекты не только позволят сотрудникам лучше узнать бизнес, но и повысят мотивацию.
Принцип 5. Даже если команда удаленная, организуйте личные встречи по крайней мере раз в год
Составьте рабочее расписание, в которое будет включена сессия знакомства. Кроме нее включите в повестку дня воркшопы или брейнсторминг, которые помогут членам команды сформулировать глобальные цели и обсудить проблемы. И, конечно, важен неформальный тимбилдинг: совместные развлечения сплачивают команду.
Совершенно новый вызов - релокации, встал перед руководителями IT-команд в прошлом году. Когда команда релоцируется, то неизбежно меняются подходы к управлению.
👍1
Как ускорять А/В-тестирование
В своих выступлениях я часто говорю, что А/В-тест - достаточно долгий инструмент для проверки гипотез. Но есть лайфхаки, как его можно ускорить:
1. Определите ключевые метрики: перед началом тестирования определите, какие метрики будут являться ключевыми для оценки результатов. Это поможет сократить объем тестирования и сфокусироваться на наиболее значимых метриках. Определите наиболее важные изменения: сфокусируйтесь на наиболее значимых изменениях, которые могут повлиять на ключевые метрики. Это поможет сократить время на разработку и тестирование.
2. Уменьшите размер выборки: уменьшение размера выборки поможет ускорить А/B-тестирование, но необходимо убедиться, что результаты остаются статистически значимыми.
3. Используйте CUPED - это метод, который позволяет уменьшить влияние искажений на результаты исследования, связанных с различными факторами, которые могут повлиять на конечный результат. Он основан на использовании контрольной группы, которая исключена из эксперимента, но используется для сравнения с тестовой группой и оценки эффекта воздействия на тестовой группе. Кроме того, метод CUPED использует методы разности в различных периодах времени для более точной оценки эффекта воздействия.
4. Используйте стратификацию - это метод, который используется для улучшения точности результатов, путем разделения выборки на группы (страты), имеющие общие характеристики. Каждая страта может быть подвергнута отдельному анализу, и в конечном итоге результаты могут быть обобщены для всей выборки. Этот метод позволяет более точно определить различия между группами и улучшить точность выводов на основе выборки.
5. Отсеките выбросы. Выброс - это экстремальные значение в данных, которые находятся далеко за пределами других наблюдений. Например, в приложении пользователи тратят в среднем от 8 до 12 долларов, и внезапно появляется пользователь, который заплатил 100 долларов. Выбросы в данных А/Б-тестов увеличивают дисперсию метрики и длительность теста, а также смещают оценку среднего. Это может привести, в итоге, к неверному решению о принятии проверяемой гипотезы
6. Используйте многоразовые шаблоны: создание многоразовых шаблонов для элементов дизайна и контента сайта или приложения может значительно сократить время на разработку и внедрение изменений.
7. Используйте предварительное тестирование: проведите предварительное тестирование, чтобы проверить, какие изменения наиболее эффективны, прежде чем начать полноценное A/B-тестирование
В своих выступлениях я часто говорю, что А/В-тест - достаточно долгий инструмент для проверки гипотез. Но есть лайфхаки, как его можно ускорить:
1. Определите ключевые метрики: перед началом тестирования определите, какие метрики будут являться ключевыми для оценки результатов. Это поможет сократить объем тестирования и сфокусироваться на наиболее значимых метриках. Определите наиболее важные изменения: сфокусируйтесь на наиболее значимых изменениях, которые могут повлиять на ключевые метрики. Это поможет сократить время на разработку и тестирование.
2. Уменьшите размер выборки: уменьшение размера выборки поможет ускорить А/B-тестирование, но необходимо убедиться, что результаты остаются статистически значимыми.
3. Используйте CUPED - это метод, который позволяет уменьшить влияние искажений на результаты исследования, связанных с различными факторами, которые могут повлиять на конечный результат. Он основан на использовании контрольной группы, которая исключена из эксперимента, но используется для сравнения с тестовой группой и оценки эффекта воздействия на тестовой группе. Кроме того, метод CUPED использует методы разности в различных периодах времени для более точной оценки эффекта воздействия.
4. Используйте стратификацию - это метод, который используется для улучшения точности результатов, путем разделения выборки на группы (страты), имеющие общие характеристики. Каждая страта может быть подвергнута отдельному анализу, и в конечном итоге результаты могут быть обобщены для всей выборки. Этот метод позволяет более точно определить различия между группами и улучшить точность выводов на основе выборки.
5. Отсеките выбросы. Выброс - это экстремальные значение в данных, которые находятся далеко за пределами других наблюдений. Например, в приложении пользователи тратят в среднем от 8 до 12 долларов, и внезапно появляется пользователь, который заплатил 100 долларов. Выбросы в данных А/Б-тестов увеличивают дисперсию метрики и длительность теста, а также смещают оценку среднего. Это может привести, в итоге, к неверному решению о принятии проверяемой гипотезы
6. Используйте многоразовые шаблоны: создание многоразовых шаблонов для элементов дизайна и контента сайта или приложения может значительно сократить время на разработку и внедрение изменений.
7. Используйте предварительное тестирование: проведите предварительное тестирование, чтобы проверить, какие изменения наиболее эффективны, прежде чем начать полноценное A/B-тестирование
Ликбез про Graceful degradation
- Graceful degradation - это подход к разработке веб-приложений, который предполагает, что если какая-то часть функциональности приложения не работает или не поддерживается в браузере пользователя, то приложение должно продолжать работать и отображаться, но с упрощенной или частичной функциональностью.
- В контексте веба graceful degradation — это способность сайта адаптироваться под браузер, который несовместим с различным функционалом, использованным на сайте. Помимо наиболее распространенных случаев, таких как отключенный JavaScript или отключенные изображения, это может быть, например, не поддерживаемое CSS-свойство. В результате сайт упрощается, но остается доступным.
- Цель подхода — обеспечить доступ к ресурсу для максимального числа пользователей. При этом часть из них сможет видеть весь контент и работать с полным функционалом, а часть с сокращённым контентом и базовыми функциями. В веб-разработке GD применяется в ответ на развитие браузеров: веб-сервисы создаются под новые версии, в то время как большее число людей пользуются старыми.
- Чтобы реализовать этот подход, необходимо провести анализ возможностей браузеров, которые используют пользователи, и определить, какие функции могут быть не поддержаны.
При этом, важно не забывать о том, что любая функция, которая не работает в полной мере, должна быть явно указана пользователю, чтобы он не пытался использовать недоступную функциональность и не был разочарован в работе приложения.
- Нужно хорошо знать и изучать алгоритмы graceful degradation логики, которые используются в фичах. Тут в Авито рассказали историю: после релиза новой фичи на платформе заметили аномалию — жители маленького дагестанского села за неделю внезапно создали 45 тысяч новых резюме. Чтобы выяснить, что пошло не так, пришлось устраивать целое расследование.
QA-инженер компании Алёна Луцик рассказал на vc.ru про этот опыт. Разбирать ошибки всегда полезно, в автотестах важно завязываться не только на факт создания данных, но и на их корректность, а graceful degradation логика также решает.
Все подробности — по ссылке.
- Graceful degradation - это подход к разработке веб-приложений, который предполагает, что если какая-то часть функциональности приложения не работает или не поддерживается в браузере пользователя, то приложение должно продолжать работать и отображаться, но с упрощенной или частичной функциональностью.
- В контексте веба graceful degradation — это способность сайта адаптироваться под браузер, который несовместим с различным функционалом, использованным на сайте. Помимо наиболее распространенных случаев, таких как отключенный JavaScript или отключенные изображения, это может быть, например, не поддерживаемое CSS-свойство. В результате сайт упрощается, но остается доступным.
- Цель подхода — обеспечить доступ к ресурсу для максимального числа пользователей. При этом часть из них сможет видеть весь контент и работать с полным функционалом, а часть с сокращённым контентом и базовыми функциями. В веб-разработке GD применяется в ответ на развитие браузеров: веб-сервисы создаются под новые версии, в то время как большее число людей пользуются старыми.
- Чтобы реализовать этот подход, необходимо провести анализ возможностей браузеров, которые используют пользователи, и определить, какие функции могут быть не поддержаны.
При этом, важно не забывать о том, что любая функция, которая не работает в полной мере, должна быть явно указана пользователю, чтобы он не пытался использовать недоступную функциональность и не был разочарован в работе приложения.
- Нужно хорошо знать и изучать алгоритмы graceful degradation логики, которые используются в фичах. Тут в Авито рассказали историю: после релиза новой фичи на платформе заметили аномалию — жители маленького дагестанского села за неделю внезапно создали 45 тысяч новых резюме. Чтобы выяснить, что пошло не так, пришлось устраивать целое расследование.
QA-инженер компании Алёна Луцик рассказал на vc.ru про этот опыт. Разбирать ошибки всегда полезно, в автотестах важно завязываться не только на факт создания данных, но и на их корректность, а graceful degradation логика также решает.
Все подробности — по ссылке.
vc.ru
Как Москва превратилась в дагестанское село: детективное расследование QA-инженера Авито — Сервисы на vc.ru
Привет! Меня зовут Алёна Луцик, я QA-инженер в Авито. В 2018 году вскоре после релиза новой фичи я с командой заметила нечто странное: жители маленького дагестанского села за неделю создали на Авито 45 000 новых резюме. Мы в панике начали искать проблему…
Механики масштабирования Agile и Scrum
1. Создание нескольких команд: если объем работы слишком большой для одной команды, можно создать несколько небольших команд, каждая из которых будет отвечать за свою часть проекта. Каждая команда будет работать по методологии Scrum, а вся работа будет координироваться и согласовываться между командами.Каждая команда работает по методологии Scrum, а команды взаимодействуют друг с другом на регулярных встречах, называемых Scrum of Scrums. На этих встречах команды обсуждают свой прогресс, координируют работу и идентифицируют возможные проблемы.
2. Скрамбан: Scrum и Kanban можно объединить в одном методологическом подходе, который называется скрамбан. Этот подход позволяет справляться с более сложными проектами, где требуется гибридный подход. Scramban позволяет гибко управлять рабочим процессом, учитывая особенности каждой части проекта.
3. SAFe (Scaled Agile Framework): Это методологический подход, который разработан для масштабирования Agile на большие проекты. В рамках SAFe проект делится на несколько подпроектов, каждый из которых реализуется своей командой. Все команды работают в рамках общей стратегии и выстраивают связи друг с другом.
4. LeSS (Large-Scale Scrum): Этот подход разработан для масштабирования Scrum на большие проекты. В LeSS команда делится на несколько небольших, каждая из которых работает по методологии Scrum. Однако, в отличие от SAFe, в LeSS каждая команда является полноценной Scrum-командой, которая выполняет все этапы Scrum.
5. Еще одним подходом к масштабированию Agile и Scrum является использование методологии Nexus. Nexus представляет собой каркас, разработанный на основе Scrum, который позволяет объединить несколько Scrum-команд для работы над одним большим проектом. Nexus определяет роли, артефакты, правила и практики, которые позволяют командам работать вместе на более крупных и сложных проектах.
1. Создание нескольких команд: если объем работы слишком большой для одной команды, можно создать несколько небольших команд, каждая из которых будет отвечать за свою часть проекта. Каждая команда будет работать по методологии Scrum, а вся работа будет координироваться и согласовываться между командами.Каждая команда работает по методологии Scrum, а команды взаимодействуют друг с другом на регулярных встречах, называемых Scrum of Scrums. На этих встречах команды обсуждают свой прогресс, координируют работу и идентифицируют возможные проблемы.
2. Скрамбан: Scrum и Kanban можно объединить в одном методологическом подходе, который называется скрамбан. Этот подход позволяет справляться с более сложными проектами, где требуется гибридный подход. Scramban позволяет гибко управлять рабочим процессом, учитывая особенности каждой части проекта.
3. SAFe (Scaled Agile Framework): Это методологический подход, который разработан для масштабирования Agile на большие проекты. В рамках SAFe проект делится на несколько подпроектов, каждый из которых реализуется своей командой. Все команды работают в рамках общей стратегии и выстраивают связи друг с другом.
4. LeSS (Large-Scale Scrum): Этот подход разработан для масштабирования Scrum на большие проекты. В LeSS команда делится на несколько небольших, каждая из которых работает по методологии Scrum. Однако, в отличие от SAFe, в LeSS каждая команда является полноценной Scrum-командой, которая выполняет все этапы Scrum.
5. Еще одним подходом к масштабированию Agile и Scrum является использование методологии Nexus. Nexus представляет собой каркас, разработанный на основе Scrum, который позволяет объединить несколько Scrum-команд для работы над одним большим проектом. Nexus определяет роли, артефакты, правила и практики, которые позволяют командам работать вместе на более крупных и сложных проектах.
Как ChatGPT развивает продактов
1. Больше и быстрее читать
Сделать саммари любой статьи, вышедшей до 2022 года. Например, можно освоить всего Пола Грэма за вечер. Особенно полезно для проходных текстов, где смысла на абзац, а воды на 16 страниц.
2. Выбирать и сравнивать курсы
“Найди три лучших курса по пользовательскому поведению и сравни их, выведи достоинства и недостатки в таблице”. Дает толковые варианты.
3. Решать кейсы и повышать насмотренность
“Я готовлюсь к интервью на позицию продакта. Дай мне кейс, я решу, а ты проверишь”. Возможность, прокачиваться в разных областях и отраслях.
4. Обстукивать идеи
“Я хочу проверить гипотезу Х способом Y c целью Z. Скажи, какие слабые места ты видишь”. Очень неглупый собеседник с дельными вопросами.
5. Тестировать себя и находить зоны развития
“Я продакт-менеджер и развиваю продукт Х в отрасли Y. Протестируй меня, чтобы проверить мои знания и выяснить, где подтянуть их”. Взгляд со стороны на свои точки роста.
А еще с помощью ИИ можно создавать крутые тексты, яркие офферы, презентации, КП. Собирать лендинги и сайты без специальных навыков, готовить питчдеки, считать объем рынка и юнит-экономику; автоматизировать рутинные задачи. Вопрос лишь в том, как обучить ИИ под себя и быстро получать качественные ответы, а не воду.
1. Больше и быстрее читать
Сделать саммари любой статьи, вышедшей до 2022 года. Например, можно освоить всего Пола Грэма за вечер. Особенно полезно для проходных текстов, где смысла на абзац, а воды на 16 страниц.
2. Выбирать и сравнивать курсы
“Найди три лучших курса по пользовательскому поведению и сравни их, выведи достоинства и недостатки в таблице”. Дает толковые варианты.
3. Решать кейсы и повышать насмотренность
“Я готовлюсь к интервью на позицию продакта. Дай мне кейс, я решу, а ты проверишь”. Возможность, прокачиваться в разных областях и отраслях.
4. Обстукивать идеи
“Я хочу проверить гипотезу Х способом Y c целью Z. Скажи, какие слабые места ты видишь”. Очень неглупый собеседник с дельными вопросами.
5. Тестировать себя и находить зоны развития
“Я продакт-менеджер и развиваю продукт Х в отрасли Y. Протестируй меня, чтобы проверить мои знания и выяснить, где подтянуть их”. Взгляд со стороны на свои точки роста.
А еще с помощью ИИ можно создавать крутые тексты, яркие офферы, презентации, КП. Собирать лендинги и сайты без специальных навыков, готовить питчдеки, считать объем рынка и юнит-экономику; автоматизировать рутинные задачи. Вопрос лишь в том, как обучить ИИ под себя и быстро получать качественные ответы, а не воду.
👍1
Важные примеры SQL-запросов для пользовательской аналитики
1. Запрос на выборку данных о пользователях - запрос на выборку данных о пользователях может помочь в понимании характеристик аудитории, таких как пол, возраст, местоположение и т.д.
SELECT COUNT(DISTINCT user_id) as unique_users, gender, age, geo_location FROM user_profiles GROUP BY gender, age, geo_location;
2. Запрос на выборку данных о поведении пользователей - запрос на выборку данных о поведении пользователей может помочь в понимании, как пользователи взаимодействуют с продуктом.
SELECT behavior_type, COUNT(*) as total_events FROM user_behavior GROUP BY behavior_type;
3. Запрос на выборку данных о трафике - запрос на выборку данных о трафике может помочь в понимании, как пользователи приходят на сайт, какие каналы трафика наиболее эффективны и т.д.
SELECT channel, COUNT(DISTINCT user_id) as unique_users FROM user_traffic GROUP BY channel;
4. Запрос на выборку данных о конверсии - запрос на выборку данных о конверсии может помочь в оценке эффективности продукта и выявлении проблемных зон.
SELECT step_name, COUNT(*) as total_visits, SUM(CASE WHEN next_step_name IS NOT NULL THEN 1 ELSE 0 END) as total_conversions FROM user_funnel GROUP BY step_name;
Хотите научиться писать такие запросы за 1,5 месяца? Приходите на курс Яндекс Практикума. Там сможете перейти от неподъёмных отчётов в Excel к автоматизированной работе с метриками и исследованиями. Вместо сложных фильтров и долгих поисков — запрос, который выгрузит, обработает и проанализирует данные сам.
Доступ к материалам бессрочный — вы всегда сможете найти шаблон решения для сложной рабочей задачи.
Записывайтесь на занятия, чтобы тратить меньше времени на рутину - Записаться
1. Запрос на выборку данных о пользователях - запрос на выборку данных о пользователях может помочь в понимании характеристик аудитории, таких как пол, возраст, местоположение и т.д.
SELECT COUNT(DISTINCT user_id) as unique_users, gender, age, geo_location FROM user_profiles GROUP BY gender, age, geo_location;
2. Запрос на выборку данных о поведении пользователей - запрос на выборку данных о поведении пользователей может помочь в понимании, как пользователи взаимодействуют с продуктом.
SELECT behavior_type, COUNT(*) as total_events FROM user_behavior GROUP BY behavior_type;
3. Запрос на выборку данных о трафике - запрос на выборку данных о трафике может помочь в понимании, как пользователи приходят на сайт, какие каналы трафика наиболее эффективны и т.д.
SELECT channel, COUNT(DISTINCT user_id) as unique_users FROM user_traffic GROUP BY channel;
4. Запрос на выборку данных о конверсии - запрос на выборку данных о конверсии может помочь в оценке эффективности продукта и выявлении проблемных зон.
SELECT step_name, COUNT(*) as total_visits, SUM(CASE WHEN next_step_name IS NOT NULL THEN 1 ELSE 0 END) as total_conversions FROM user_funnel GROUP BY step_name;
Хотите научиться писать такие запросы за 1,5 месяца? Приходите на курс Яндекс Практикума. Там сможете перейти от неподъёмных отчётов в Excel к автоматизированной работе с метриками и исследованиями. Вместо сложных фильтров и долгих поисков — запрос, который выгрузит, обработает и проанализирует данные сам.
Доступ к материалам бессрочный — вы всегда сможете найти шаблон решения для сложной рабочей задачи.
Записывайтесь на занятия, чтобы тратить меньше времени на рутину - Записаться
Яндекс Практикум
Курс «SQL для работы с данными и аналитики»: обучение онлайн языку SQL для анализа данных
Онлайн-курс «SQL для работы с данными и аналитики» с нуля. Обучение языку SQL для начинающих от сервиса Яндекс Практикум.
👍1
Как DevOps может помочь продакт-менеджеру
- Более быстрое и безопасное внедрение изменений. DevOps позволяет автоматизировать процессы разработки, тестирования и выкатки продукта, что ускоряет его запуск и снижает риск возможных проблем.
- Мониторинг и анализ производительности продукта. DevOps позволяет в режиме реального времени отслеживать работу продукта и собирать аналитику о его использовании, что помогает продакт менеджеру принимать решения по улучшению продукта.
- Оптимизация процессов разработки. DevOps может помочь выявить узкие места в процессах разработки и эксплуатации продукта, что помогает оптимизировать их и снизить затраты на разработку.
- Улучшение коммуникации между командами. DevOps улучшает коммуникацию и сотрудничество между различными командами в рамках процесса разработки и эксплуатации продукта, что помогает повысить качество и скорость разработки.
Об этом можно также узнать в книгах и ресурсах:
1. В статье Применение DevOps-аутсорса на разных этапах жизненного цикла продукта от Станислава Тибекина, CVO компании Nixys.
Особенно рекомендую начать погружение с этой практической статьи, она будет полезна не только в плане привлечения аутсорсинга. Когда появляется потребность в DevOps-команде, перед бизнесом всегда встают конкретные вопросы: “А всё-таки, как решить мою проблему — нанять DevOps-специалиста в штат, использовать аутстафф или отдать проект на аутсорс? Есть ли четкие критерии для выбора? Что будет эффективнее?”
2. "The Phoenix Project" автора Г. Кима, К. Бехра и др.
Данная книга описывает историю компании, которая сталкивается с техническими проблемами, и как внедрение DevOps позволило ей изменить свой подход к управлению IT и достичь успеха.
3. "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation" автора Д. Фарли и Д. Хамбле
Данная книга объясняет, как внедрение DevOps-практик и автоматизации процессов позволяет создавать и доставлять программное обеспечение непрерывно, быстро и надежно.
4. "Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations" авторов Н. Форсгрен, J. Humble и G. Kim
В этой книге авторы рассматривают научный подход к изучению DevOps и объясняют, как организации могут создать высокопроизводительные команды и процессы с помощью DevOps-практик.
- Более быстрое и безопасное внедрение изменений. DevOps позволяет автоматизировать процессы разработки, тестирования и выкатки продукта, что ускоряет его запуск и снижает риск возможных проблем.
- Мониторинг и анализ производительности продукта. DevOps позволяет в режиме реального времени отслеживать работу продукта и собирать аналитику о его использовании, что помогает продакт менеджеру принимать решения по улучшению продукта.
- Оптимизация процессов разработки. DevOps может помочь выявить узкие места в процессах разработки и эксплуатации продукта, что помогает оптимизировать их и снизить затраты на разработку.
- Улучшение коммуникации между командами. DevOps улучшает коммуникацию и сотрудничество между различными командами в рамках процесса разработки и эксплуатации продукта, что помогает повысить качество и скорость разработки.
Об этом можно также узнать в книгах и ресурсах:
1. В статье Применение DevOps-аутсорса на разных этапах жизненного цикла продукта от Станислава Тибекина, CVO компании Nixys.
Особенно рекомендую начать погружение с этой практической статьи, она будет полезна не только в плане привлечения аутсорсинга. Когда появляется потребность в DevOps-команде, перед бизнесом всегда встают конкретные вопросы: “А всё-таки, как решить мою проблему — нанять DevOps-специалиста в штат, использовать аутстафф или отдать проект на аутсорс? Есть ли четкие критерии для выбора? Что будет эффективнее?”
2. "The Phoenix Project" автора Г. Кима, К. Бехра и др.
Данная книга описывает историю компании, которая сталкивается с техническими проблемами, и как внедрение DevOps позволило ей изменить свой подход к управлению IT и достичь успеха.
3. "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation" автора Д. Фарли и Д. Хамбле
Данная книга объясняет, как внедрение DevOps-практик и автоматизации процессов позволяет создавать и доставлять программное обеспечение непрерывно, быстро и надежно.
4. "Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations" авторов Н. Форсгрен, J. Humble и G. Kim
В этой книге авторы рассматривают научный подход к изучению DevOps и объясняют, как организации могут создать высокопроизводительные команды и процессы с помощью DevOps-практик.
Еще одна подборка ресурсов для улучшения английского языка
• Курсы от команды Across English - где учат делать ежедневную работу продакта на английском языке
• Muzli Inspiration by Invision – еженедельный дайджест с подборкой вдохновляющего дизайн-контента.
• The Hustle – письма по утрам с новостями бизнеса и технологий, которые могут пригодиться тебе именно сегодня.
•Nir and Far – рассылка о психологии потребительского поведения от автора книги «На крючке» Нира Эяля
• Канал Стэнфордской высшей школы бизнеса
• Канал Y Combinator
• Второй канал Y Combinator: The Vault с нестандартным контентом о жизни стартапов, интервью с основателями, прямыми трансляциями и т.п.
• Канал Уэса Буша, автора книги «Product-Led Growth»
•This is Product Management - подкаст, в котором продакт-менеджеры из разных компаний делятся своим опытом и знаниями о продакт-менеджменте. В подкасте затрагиваются такие темы, как разработка продукта, управление командой, маркетинг и продажи.
•The Product Experience - подкаст от двух продакт-менеджеров, в котором они обсуждают темы, связанные с продакт-менеджментом, и делятся своими личными историями и опытом. В подкасте затрагиваются такие темы, как дизайн продукта, управление командой, маркетинг и многое другое.
•The All Turtles Podcast - подкаст от стартап-студии All Turtles, в котором обсуждаются технологии, дизайн продукта и инновации. В подкасте также говорят о том, как разрабатывать продукты, которые решают реальные проблемы людей.
•Build - подкаст от интернет-магазина Webflow, в котором говорится о том, как создавать продукты и бизнесы. В подкасте также обсуждаются технологии, дизайн, маркетинг и другие темы, связанные с продуктами.
•Product to Product - подкаст от компании Roadmunk, в котором продакт-менеджеры и другие эксперты делятся своим опытом
• Курсы от команды Across English - где учат делать ежедневную работу продакта на английском языке
• Muzli Inspiration by Invision – еженедельный дайджест с подборкой вдохновляющего дизайн-контента.
• The Hustle – письма по утрам с новостями бизнеса и технологий, которые могут пригодиться тебе именно сегодня.
•Nir and Far – рассылка о психологии потребительского поведения от автора книги «На крючке» Нира Эяля
• Канал Стэнфордской высшей школы бизнеса
• Канал Y Combinator
• Второй канал Y Combinator: The Vault с нестандартным контентом о жизни стартапов, интервью с основателями, прямыми трансляциями и т.п.
• Канал Уэса Буша, автора книги «Product-Led Growth»
•This is Product Management - подкаст, в котором продакт-менеджеры из разных компаний делятся своим опытом и знаниями о продакт-менеджменте. В подкасте затрагиваются такие темы, как разработка продукта, управление командой, маркетинг и продажи.
•The Product Experience - подкаст от двух продакт-менеджеров, в котором они обсуждают темы, связанные с продакт-менеджментом, и делятся своими личными историями и опытом. В подкасте затрагиваются такие темы, как дизайн продукта, управление командой, маркетинг и многое другое.
•The All Turtles Podcast - подкаст от стартап-студии All Turtles, в котором обсуждаются технологии, дизайн продукта и инновации. В подкасте также говорят о том, как разрабатывать продукты, которые решают реальные проблемы людей.
•Build - подкаст от интернет-магазина Webflow, в котором говорится о том, как создавать продукты и бизнесы. В подкасте также обсуждаются технологии, дизайн, маркетинг и другие темы, связанные с продуктами.
•Product to Product - подкаст от компании Roadmunk, в котором продакт-менеджеры и другие эксперты делятся своим опытом
Основные методики для быстрого роста компании и трекинга
- HADI-циклы — методика проверки гипотез, которая состоит из 4 этапов: постановка гипотезы, действия по ее реализации, сбор данных о результатах работы гипотезы, выводы на их основе. Наглядно показывает, как действия команды влияют на результат — это позволяет быстро тестировать идеи и отказываться от нерабочих.
- Приоритизация гипотез — ранжирование гипотез по потенциалу увеличения прибыли и скорости проверки. Помогает определить, какие из них стоит проверять в первую очередь, и выстроить последовательность шагов для системного достижения цели .
- Daily meetings — ежедневные планерки команды, цель которых — понять, что сделал каждый сотрудник за прошлый рабочий день, какие сложности у него возникли, что он собирается сделать за текущий день. Помогает скорректировать ежедневную работу членов команды, узнать о проблемах, которые возникают в процессе, предложить варианты решения.
- Customer Development — методология изучения потребностей потенциальных клиентов с помощью глубинных интервью. Помогает выявить инсайты, благодаря использованию которых можно увеличить ценность продукта для клиентов, средний чек, а в результате и пожизненную ценность клиента (Lifetime Value — прим.)
- ABCDX-сегментация — инструмент максимизации прибыли, помогает выделить самый маржинальный клиентский сегмент.
- Работа с «пайплайном» — инструмент диагностики продаж: помогает выстроить процесс продаж, увидеть, что его тормозит, и сократить цикл сделки.
- Design Thinking - методика, которая использует процесс мышления дизайнера для создания инновационных решений. Она помогает сосредоточиться на пользователях и их потребностях, а также на поиске новых возможностей для улучшения продукта.
- Lean Startup - методика, разработанная Эриком Рисом, которая позволяет минимизировать риски и издержки при запуске стартапа. Основная идея заключается в том, чтобы быстро создавать и тестировать минимальные жизнеспособные продукты (MVP), а затем собирать обратную связь от пользователей и основываясь на ней улучшать продукт.
- HADI-циклы — методика проверки гипотез, которая состоит из 4 этапов: постановка гипотезы, действия по ее реализации, сбор данных о результатах работы гипотезы, выводы на их основе. Наглядно показывает, как действия команды влияют на результат — это позволяет быстро тестировать идеи и отказываться от нерабочих.
- Приоритизация гипотез — ранжирование гипотез по потенциалу увеличения прибыли и скорости проверки. Помогает определить, какие из них стоит проверять в первую очередь, и выстроить последовательность шагов для системного достижения цели .
- Daily meetings — ежедневные планерки команды, цель которых — понять, что сделал каждый сотрудник за прошлый рабочий день, какие сложности у него возникли, что он собирается сделать за текущий день. Помогает скорректировать ежедневную работу членов команды, узнать о проблемах, которые возникают в процессе, предложить варианты решения.
- Customer Development — методология изучения потребностей потенциальных клиентов с помощью глубинных интервью. Помогает выявить инсайты, благодаря использованию которых можно увеличить ценность продукта для клиентов, средний чек, а в результате и пожизненную ценность клиента (Lifetime Value — прим.)
- ABCDX-сегментация — инструмент максимизации прибыли, помогает выделить самый маржинальный клиентский сегмент.
- Работа с «пайплайном» — инструмент диагностики продаж: помогает выстроить процесс продаж, увидеть, что его тормозит, и сократить цикл сделки.
- Design Thinking - методика, которая использует процесс мышления дизайнера для создания инновационных решений. Она помогает сосредоточиться на пользователях и их потребностях, а также на поиске новых возможностей для улучшения продукта.
- Lean Startup - методика, разработанная Эриком Рисом, которая позволяет минимизировать риски и издержки при запуске стартапа. Основная идея заключается в том, чтобы быстро создавать и тестировать минимальные жизнеспособные продукты (MVP), а затем собирать обратную связь от пользователей и основываясь на ней улучшать продукт.
Про венчурную аналитику
Метрики, которые точно надо раскрыть в рамках фин-модели или текущего трекшна продукта:
1. Monthly Recurring Revenue (MRR) - это метрика, которая показывает ежемесячный доход продукта от подписок или других повторяющихся платежей.
2. Customer Acquisition Cost (CAC) - это метрика, которая показывает, сколько денег тратится на привлечение одного нового клиента.
3. Customer Lifetime Value (LTV) - это метрика, которая показывает, сколько денег один клиент приносит продукту за весь период его использования.
4. Churn rate - это метрика, которая показывает, как быстро пользователи покидают продукт.
5. Gross Margins - это метрика, которая показывает разницу между доходами и затратами на производство продукта.
6. Net Promoter Score (NPS) - это метрика, которая показывает, насколько вероятно, что пользователи будут рекомендовать продукт своим друзьям и коллегам.
7. Conversion rate - это метрика, которая показывает, сколько пользователей, зашедших на сайт продукта, совершили желаемое действие, например, сделали покупку.
8. Run rate - это метрика, которая показывает, сколько продукт зарабатывает в месяц или в год на текущий момент, и как быстро он растет.
9. Burn rate - это метрика, которая показывает, сколько денег продукт тратит каждый месяц или год, и сколько времени у него остается до исчерпания финансовых ресурсов.
10. Market size - это метрика, которая показывает, какой рынок адресует продукт, сколько там потенциальных пользователей, и каков его потенциал для роста
Про венчурную аналитику рекомендую почитать:
-“Венчурный капитал. Как заработать на стартапах" - авторы Брэд Фельд, Джейсон Мендельсон
-“Стартап. Начните свой бизнес на собственные условия" - автор Эрик Рис
-“Венчурная инвестиция в России. Как создать и продать стартап" - авторы Дмитрий Куреев, Виктор Пономарев, Юлия Соловьева
-“Основы венчурного инвестирования" - авторы Пол Драпер, Пола Као, Рэнди Коул
-“Венчурный бизнес: от идеи до IPO" - автор Джейсон МакКензи
-“Путь венчурного инвестора" - автор Питер Тил
-“Венчурные инвестиции. Принципы и практика" - автор Реймонд Курцвейль
- "Как создать стартап, привлечь венчурный капитал и обогнать конкурентов" - автор Джеймс Скрамко
-“Венчурный капитал и риск" - автор Джозеф Гайнс
- "Сделки с венчурным капиталом. Как выйти на новый уровень развития" - авторы Александр Горохов, Алексей Попов, Алексей Черняк
Метрики, которые точно надо раскрыть в рамках фин-модели или текущего трекшна продукта:
1. Monthly Recurring Revenue (MRR) - это метрика, которая показывает ежемесячный доход продукта от подписок или других повторяющихся платежей.
2. Customer Acquisition Cost (CAC) - это метрика, которая показывает, сколько денег тратится на привлечение одного нового клиента.
3. Customer Lifetime Value (LTV) - это метрика, которая показывает, сколько денег один клиент приносит продукту за весь период его использования.
4. Churn rate - это метрика, которая показывает, как быстро пользователи покидают продукт.
5. Gross Margins - это метрика, которая показывает разницу между доходами и затратами на производство продукта.
6. Net Promoter Score (NPS) - это метрика, которая показывает, насколько вероятно, что пользователи будут рекомендовать продукт своим друзьям и коллегам.
7. Conversion rate - это метрика, которая показывает, сколько пользователей, зашедших на сайт продукта, совершили желаемое действие, например, сделали покупку.
8. Run rate - это метрика, которая показывает, сколько продукт зарабатывает в месяц или в год на текущий момент, и как быстро он растет.
9. Burn rate - это метрика, которая показывает, сколько денег продукт тратит каждый месяц или год, и сколько времени у него остается до исчерпания финансовых ресурсов.
10. Market size - это метрика, которая показывает, какой рынок адресует продукт, сколько там потенциальных пользователей, и каков его потенциал для роста
Про венчурную аналитику рекомендую почитать:
-“Венчурный капитал. Как заработать на стартапах" - авторы Брэд Фельд, Джейсон Мендельсон
-“Стартап. Начните свой бизнес на собственные условия" - автор Эрик Рис
-“Венчурная инвестиция в России. Как создать и продать стартап" - авторы Дмитрий Куреев, Виктор Пономарев, Юлия Соловьева
-“Основы венчурного инвестирования" - авторы Пол Драпер, Пола Као, Рэнди Коул
-“Венчурный бизнес: от идеи до IPO" - автор Джейсон МакКензи
-“Путь венчурного инвестора" - автор Питер Тил
-“Венчурные инвестиции. Принципы и практика" - автор Реймонд Курцвейль
- "Как создать стартап, привлечь венчурный капитал и обогнать конкурентов" - автор Джеймс Скрамко
-“Венчурный капитал и риск" - автор Джозеф Гайнс
- "Сделки с венчурным капиталом. Как выйти на новый уровень развития" - авторы Александр Горохов, Алексей Попов, Алексей Черняк
Примеры MVP жизнеспособных продуктов
1. Uber. В изначальной версии приложение могло только соединять клиентов с водителями. Эта его простота и привлекла клиентов. А когда MVP продукта доказало свою состоятельность, появились все остальные функции, вплоть до семейного профиля, планирования поездок и возможности разделения тарифа. У многих стартапов возникают идеи, что чем больше возможностей — тем лучше. Но если бы у Uber всё это было с самого начала, клиенты не стали бы во всём разбираться. А так — компания получила множество данных для анализа, поняла, в каком направлении стоит развивать приложение, и сейчас превратилась в бизнес стоимостью $53 млрд.
2. Yahoo! Минимальным продуктом здесь была простая страничка со списком ссылок на популярные сайты. Это был вполне достаточный функционал, чтобы удовлетворить пользователей на ранних этапах интернета. А когда сайт приобрёл трафик и популярность, началась его адаптация и развитие. Сегодня это вторая по успешности поисковая система в мире с доходом $5+ млрд в год.
3. Snapchat. Сервис начинался максимально просто: быстрая маленькая утилита, позволяющая обмениваться сообщениями, которые удалялись бы через 10 секунд после прочтения. Когда в 2011 году на iOS была выпущена первая версия, из «продвинутых» функций в ней была разве что загрузка изображений. Сейчас у продукта 230 млн пользователей каждый день, а компанию оценивают в $35 млрд.
4. Instagram - первый MVP Instagram был небольшим приложением для iPhone, которое позволяло пользователям делиться фотографиями и применять к ним фильтры. Это приложение было создано за несколько недель и было доступно только на iOS. Благодаря большому спросу на приложение и положительным отзывам пользователей, Instagram быстро расширил свой функционал и стал доступен на других платформах.
5. WhatsApp. В 2009 году Ян Кум и Брайан Эктон решили создать мобильную телефонную книгу, которая бы показывала статус контакта: доступен, занят, на совещании и так далее. Контакты пользователей этой книги получали соответствующие всплывающие уведомления. Однако вскоре они стали использовать статусы для общения. Тогда создатели выпустили новую версию WhatsApp с функцией отправки сообщений.
6. Amazon — один из самых успешных примеров минимально жизнеспособного
продукта. Джефф Безос основал маркетплейс в начале 1990-х, и первоначально это был онлайн-магазин с книгами. Для решения он выбрал MVP одной функции: сначала Безос провел мозговой штурм и составил список товаров, которые можно было бы продавать в интернете. Из 20 различных вариантов в финал вышли 5 продуктов: видеокассеты, книги, программное обеспечение, компьютеры и компакт-диски.
1. Uber. В изначальной версии приложение могло только соединять клиентов с водителями. Эта его простота и привлекла клиентов. А когда MVP продукта доказало свою состоятельность, появились все остальные функции, вплоть до семейного профиля, планирования поездок и возможности разделения тарифа. У многих стартапов возникают идеи, что чем больше возможностей — тем лучше. Но если бы у Uber всё это было с самого начала, клиенты не стали бы во всём разбираться. А так — компания получила множество данных для анализа, поняла, в каком направлении стоит развивать приложение, и сейчас превратилась в бизнес стоимостью $53 млрд.
2. Yahoo! Минимальным продуктом здесь была простая страничка со списком ссылок на популярные сайты. Это был вполне достаточный функционал, чтобы удовлетворить пользователей на ранних этапах интернета. А когда сайт приобрёл трафик и популярность, началась его адаптация и развитие. Сегодня это вторая по успешности поисковая система в мире с доходом $5+ млрд в год.
3. Snapchat. Сервис начинался максимально просто: быстрая маленькая утилита, позволяющая обмениваться сообщениями, которые удалялись бы через 10 секунд после прочтения. Когда в 2011 году на iOS была выпущена первая версия, из «продвинутых» функций в ней была разве что загрузка изображений. Сейчас у продукта 230 млн пользователей каждый день, а компанию оценивают в $35 млрд.
4. Instagram - первый MVP Instagram был небольшим приложением для iPhone, которое позволяло пользователям делиться фотографиями и применять к ним фильтры. Это приложение было создано за несколько недель и было доступно только на iOS. Благодаря большому спросу на приложение и положительным отзывам пользователей, Instagram быстро расширил свой функционал и стал доступен на других платформах.
5. WhatsApp. В 2009 году Ян Кум и Брайан Эктон решили создать мобильную телефонную книгу, которая бы показывала статус контакта: доступен, занят, на совещании и так далее. Контакты пользователей этой книги получали соответствующие всплывающие уведомления. Однако вскоре они стали использовать статусы для общения. Тогда создатели выпустили новую версию WhatsApp с функцией отправки сообщений.
6. Amazon — один из самых успешных примеров минимально жизнеспособного
продукта. Джефф Безос основал маркетплейс в начале 1990-х, и первоначально это был онлайн-магазин с книгами. Для решения он выбрал MVP одной функции: сначала Безос провел мозговой штурм и составил список товаров, которые можно было бы продавать в интернете. Из 20 различных вариантов в финал вышли 5 продуктов: видеокассеты, книги, программное обеспечение, компьютеры и компакт-диски.
Чек-лист, как спроектировать платформу для экосистемы
1. Определите цель и ценности экосистемы. Необходимо понимать, какие цели хотите достичь и какую ценность предлагаете вашим пользователям.
2. Изучите потребности пользователей и рынка. Исследуйте рынок, понимайте потребности пользователей и анализируйте данные, чтобы создать платформу, которая наиболее эффективно удовлетворит потребности пользователей.
3. Разработайте стратегию взаимодействия между участниками экосистемы. Определите, какие участники будут использовать вашу платформу и как они будут взаимодействовать между собой.
4. Сформулируйте план продукта и определите функциональные требования. На основе стратегии и целей платформы необходимо разработать план продукта и определить необходимые функциональные требования.
5. Выберите технологические решения и архитектуру. Рассмотрите различные технологии, которые помогут реализовать платформу, и определите необходимую архитектуру.
6. Разработайте MVP (минимальный жизнеспособный продукт). Создайте минимальный жизнеспособный продукт, чтобы протестировать гипотезы и получить обратную связь от пользователей.
7. Проведите тестирование и оптимизацию. Проведите тестирование MVP, соберите обратную связь от пользователей и оптимизируйте продукт.
8. Запустите продукт и продолжайте его улучшать. После запуска продукта необходимо продолжать его улучшать, чтобы удовлетворять потребности пользователей и достигать целей экосистемы.
9. Разработайте стратегию масштабирования. Определите, как будет происходить масштабирование платформы и как вы будете решать проблемы, связанные с ростом экосистемы.
1. Определите цель и ценности экосистемы. Необходимо понимать, какие цели хотите достичь и какую ценность предлагаете вашим пользователям.
2. Изучите потребности пользователей и рынка. Исследуйте рынок, понимайте потребности пользователей и анализируйте данные, чтобы создать платформу, которая наиболее эффективно удовлетворит потребности пользователей.
3. Разработайте стратегию взаимодействия между участниками экосистемы. Определите, какие участники будут использовать вашу платформу и как они будут взаимодействовать между собой.
4. Сформулируйте план продукта и определите функциональные требования. На основе стратегии и целей платформы необходимо разработать план продукта и определить необходимые функциональные требования.
5. Выберите технологические решения и архитектуру. Рассмотрите различные технологии, которые помогут реализовать платформу, и определите необходимую архитектуру.
6. Разработайте MVP (минимальный жизнеспособный продукт). Создайте минимальный жизнеспособный продукт, чтобы протестировать гипотезы и получить обратную связь от пользователей.
7. Проведите тестирование и оптимизацию. Проведите тестирование MVP, соберите обратную связь от пользователей и оптимизируйте продукт.
8. Запустите продукт и продолжайте его улучшать. После запуска продукта необходимо продолжать его улучшать, чтобы удовлетворять потребности пользователей и достигать целей экосистемы.
9. Разработайте стратегию масштабирования. Определите, как будет происходить масштабирование платформы и как вы будете решать проблемы, связанные с ростом экосистемы.