Dogfooding: один из самых доступных инструментов дискавери продактов
Догфудинг — test as user — использование сотрудниками компании своих продуктов/сервисов. Это не уничижительное отношение к клиенту, а давно устоявшиеся понятие.
При весьма обширном списке плюсов догфудинг почти не имеет минусов. Это ли не повод начать его активно внедрять, если еще не? Не будем голословными: давайте вместе посмотрим, чем же он так хорош.
Преимущества:
- нет затрат каких-либо ресурсов (не нужно выделять отдельного исследователя, ФОТ, человекочасы и т.п.)
- подсвечивает неочевидные слабые места продукта
- улучшает CX
- можно релизить новые фичи сначала на сотрудников, а потом уже, после правок, на остальных пользователей
- сотрудников тоже можно поинтервьюировать в качестве пользователей — конверсия в исследовании будет прекрасна (но ответы со смещением, не забывайте)
- команда разработки лучше понимает как работает продукт "живьем"
- сотрудникам приятно пробовать новые фичи компании. Сплочение коллектива и повышение лояльности в качестве бонуса.
Недостатки:
- не заменит CX-исследований и QA. Да, очень условный недостаток
- подойдет не всем компаниям. Единственный настоящий минус, но ощутимый.
Хотите еще больше постов про лучшие практики в разработку продукте - приходите на канал Продуктовый подход. By AGIMA https://news.1rj.ru/str/product_agima : там хорошие методологические посты с примерами из реальной жизни. Подписывайтесь!
Догфудинг — test as user — использование сотрудниками компании своих продуктов/сервисов. Это не уничижительное отношение к клиенту, а давно устоявшиеся понятие.
При весьма обширном списке плюсов догфудинг почти не имеет минусов. Это ли не повод начать его активно внедрять, если еще не? Не будем голословными: давайте вместе посмотрим, чем же он так хорош.
Преимущества:
- нет затрат каких-либо ресурсов (не нужно выделять отдельного исследователя, ФОТ, человекочасы и т.п.)
- подсвечивает неочевидные слабые места продукта
- улучшает CX
- можно релизить новые фичи сначала на сотрудников, а потом уже, после правок, на остальных пользователей
- сотрудников тоже можно поинтервьюировать в качестве пользователей — конверсия в исследовании будет прекрасна (но ответы со смещением, не забывайте)
- команда разработки лучше понимает как работает продукт "живьем"
- сотрудникам приятно пробовать новые фичи компании. Сплочение коллектива и повышение лояльности в качестве бонуса.
Недостатки:
- не заменит CX-исследований и QA. Да, очень условный недостаток
- подойдет не всем компаниям. Единственный настоящий минус, но ощутимый.
Хотите еще больше постов про лучшие практики в разработку продукте - приходите на канал Продуктовый подход. By AGIMA https://news.1rj.ru/str/product_agima : там хорошие методологические посты с примерами из реальной жизни. Подписывайтесь!
Telegram
Эффект продакта // AGIMA
Ваша постоянная поддержка в мире любых явлений, в которых есть слово «продакт» 😏
Подборка ресурсов для прокачки скилов управления стартапом в качестве фаундера или продакта
При поддержке проекта «Цифровой базар» — конкурс цифровых стартапов от организаторов Projects Bazaar.
Сохраняйте пост в закладки! А если нужен консалтинг по продуктам, пишите автору канала.
Основы технологического предпринимательства
Базовые теоретические знания по всем этапам развития стартапа: от идеи до поиска команды и от анализа рынка до продвижения продукта.
Сам себе Startuper
Развитие soft-skills для фаундера стартапа: коммуникация, генерация идей, целеполагание и принятие решений в условиях неопределенности.
Перевод курса видеолекций "How to start a startup"
Классический курс живых видеолекций от мировых экспертов из Стэндфорда: Сэм Альтман, Питер Тиль и Алекс Шульц.
Создание технологического бизнеса
Продвинутые практические знания и навыки в формате case-study, которые помогут слушателям разработать свой проект по окончании курса.
Маркетинг инновационных продуктов
Теория и практика лучших методов продуктового маркетинга и дизайна на этапах создания, развития и выведения продукта в прибыль.
Хотите попробовать свои силы в запуске и управлении продуктами? Приходите на конкурс «Цифровой базар» — конкурс цифровых стартапов - https://telegra.ph/Cifrovoj-bazar--konkurs-cifrovyh-startapov-02-19
При поддержке проекта «Цифровой базар» — конкурс цифровых стартапов от организаторов Projects Bazaar.
Сохраняйте пост в закладки! А если нужен консалтинг по продуктам, пишите автору канала.
Основы технологического предпринимательства
Базовые теоретические знания по всем этапам развития стартапа: от идеи до поиска команды и от анализа рынка до продвижения продукта.
Сам себе Startuper
Развитие soft-skills для фаундера стартапа: коммуникация, генерация идей, целеполагание и принятие решений в условиях неопределенности.
Перевод курса видеолекций "How to start a startup"
Классический курс живых видеолекций от мировых экспертов из Стэндфорда: Сэм Альтман, Питер Тиль и Алекс Шульц.
Создание технологического бизнеса
Продвинутые практические знания и навыки в формате case-study, которые помогут слушателям разработать свой проект по окончании курса.
Маркетинг инновационных продуктов
Теория и практика лучших методов продуктового маркетинга и дизайна на этапах создания, развития и выведения продукта в прибыль.
Хотите попробовать свои силы в запуске и управлении продуктами? Приходите на конкурс «Цифровой базар» — конкурс цифровых стартапов - https://telegra.ph/Cifrovoj-bazar--konkurs-cifrovyh-startapov-02-19
Telegraph
«Цифровой базар» — конкурс цифровых стартапов
Стартапы, стартуем! Это «Цифровой базар» — конкурс цифровых стартапов от организаторов Projects Bazaar и Стартап Трекер Онлайн 🚀 🔭 Направления участия: Мобильные приложения, игры, боты, онлайн-платформы, маркетплейсы, социальные сервисы, B2B-решения для автоматизации…
Чем полезен подход Value Stream при разработке продукта?
Value Stream — это последовательность действий по созданию ценности от первичного запроса до поставки итогового результата клиенту, она не просто визуализирует производственную деятельность, а позволяет определить ее узкие места за счет анализа показателей каждого бизнес-процесса.
Value stream map состоит из нескольких элементов:
⁃ Этапы вашего процесса. Любой процесс поставки ценностей состоит из нескольких этапов.
⁃ Данные, которые соответствуют каждому из этапов. Для каждого этапа есть характерные данные, которые отражают то, что происходит в этом процессе. Сюда можно включить любую информацию которая относится к тому, как сейчас ведется работа на этом этапе.
⁃ С поставщиков начинается value stream, на получении клиентом ценности он завершается. Особенное внимание стоит обратить именно на клиентов — потому что это люди, которые непосредственно будут получать ценность и платить деньги.
⁃ Нижняя часть карты отражает то, сколько времени занимают каждый из этапов процесса и ожидания перехода от одного этапа к другому. Это очень важная часть карты, поскольку именно здесь вы сможете работать над тем, чтобы ускорить ваш процесс поставки ценности.
Какие метрики точно стоит учитывать в этом разделе:
⁃ время выпуска (Lead Time, LT) – общее время выполнения процесса, включая согласование, операции возврата, ожидание данных, материалов, объектов, исполнителей и прочих ресурсов;
⁃ время обработки (Process Time, PT) – время непосредственного выполнения работы, дающей результат процесса, ценный для потребителя;
⁃ доля работ, выполненных без ошибок (Percent Complete and Accurate, %C/A), которая должна стремиться к 100%, но на практике может не измеряться вовсе.
Value Stream — это последовательность действий по созданию ценности от первичного запроса до поставки итогового результата клиенту, она не просто визуализирует производственную деятельность, а позволяет определить ее узкие места за счет анализа показателей каждого бизнес-процесса.
Value stream map состоит из нескольких элементов:
⁃ Этапы вашего процесса. Любой процесс поставки ценностей состоит из нескольких этапов.
⁃ Данные, которые соответствуют каждому из этапов. Для каждого этапа есть характерные данные, которые отражают то, что происходит в этом процессе. Сюда можно включить любую информацию которая относится к тому, как сейчас ведется работа на этом этапе.
⁃ С поставщиков начинается value stream, на получении клиентом ценности он завершается. Особенное внимание стоит обратить именно на клиентов — потому что это люди, которые непосредственно будут получать ценность и платить деньги.
⁃ Нижняя часть карты отражает то, сколько времени занимают каждый из этапов процесса и ожидания перехода от одного этапа к другому. Это очень важная часть карты, поскольку именно здесь вы сможете работать над тем, чтобы ускорить ваш процесс поставки ценности.
Какие метрики точно стоит учитывать в этом разделе:
⁃ время выпуска (Lead Time, LT) – общее время выполнения процесса, включая согласование, операции возврата, ожидание данных, материалов, объектов, исполнителей и прочих ресурсов;
⁃ время обработки (Process Time, PT) – время непосредственного выполнения работы, дающей результат процесса, ценный для потребителя;
⁃ доля работ, выполненных без ошибок (Percent Complete and Accurate, %C/A), которая должна стремиться к 100%, но на практике может не измеряться вовсе.
Как использовать модель Double Diamond
Модель состоит из следующих этапов и стадий:
Стадия 1: найди правильное решение (Diamond 1 — исследование и поиск решения). Что бы вы ни делали, следует понять, какую именно задачу нужно решить, или на какой именно вопрос нужно найти ответ.
1) Открытие и исследование — знакомство с проблемой (расхождение):
Разработайте бриф (стандартное начало) — попробуйте проанализировать бриф или изначальный вопрос, оспаривая каждую его часть и оценивая сферы интересов. Приведите столько элементов, сколько можете, найдите характеристики, определите сферы интересов и крайности, перечислите места, людей (или персонажей), взаимодействия, которые связаны с кейсом и которые можно исследовать. Перед погружением в исследование распределите свои находки по темам, чтобы получить общую структуру: так вы сможете ограничить объем исследуемых материалов. Погрузитесь в исследование. Примените методы первичного исследования (на местах) и вторичного (кабинетного). В результате получится огромное количество неструктурированных результатов исследований.
2) Определение и синтез:
- Просуммируйте результаты исследования и поделитесь ими с командой.
- Сгруппируйте полученную информацию по темам.
- Найдите инсайты (инсайты — это правда о мотивациях, пожеланиях и досадах потребителей).
- Разработайте области возможностей (потенциальную область действий).
Стадия 2: сделай все правильно (Diamond 2 — разработка и внедрение). Как только вы определили правильный вопрос для поиска ответа, задачу для решения, нужно убедиться, что вы делаете все должным образом.
3) Разработка
Это веселая часть фазы расхождения. Вы должны запретить себе ограничиваться и подходить к процессу совершенно открыто. Используйте «да, и...» вместо «нет» или «да, но...». На этом этапе позвольте себе строить свои идеи на идеях друг друга.
В результате вы получите одну или несколько идей, которые потом сможете прототипировать и тестировать, чтобы найти лучший ответ на свой вопрос или решение задачи.
4) Результат и реализация. Примените гибкий подход из трех шагов:
- Разработка и прототипирование.
- Тестирование и анализ.
- Итерация и повторение.
Хотите больше знать о применимости продуктовых фреймворков? Приходите на магистерскую программу Управление цифровым продуктом от НИУ ВШЭ. Начать знакомство можно с Дня открытых дверей, где можно узнать всё об интересующих вас программах магистратуры и познакомится с руководителями программ, представителями бизнеса и выпускниками.
Регистрируйтесь по ссылке и подключайтесь online: http://dodmasters.hse.ru/
Образование актуально всегда, сейчас - это самая надёжная инвестиция!
Модель состоит из следующих этапов и стадий:
Стадия 1: найди правильное решение (Diamond 1 — исследование и поиск решения). Что бы вы ни делали, следует понять, какую именно задачу нужно решить, или на какой именно вопрос нужно найти ответ.
1) Открытие и исследование — знакомство с проблемой (расхождение):
Разработайте бриф (стандартное начало) — попробуйте проанализировать бриф или изначальный вопрос, оспаривая каждую его часть и оценивая сферы интересов. Приведите столько элементов, сколько можете, найдите характеристики, определите сферы интересов и крайности, перечислите места, людей (или персонажей), взаимодействия, которые связаны с кейсом и которые можно исследовать. Перед погружением в исследование распределите свои находки по темам, чтобы получить общую структуру: так вы сможете ограничить объем исследуемых материалов. Погрузитесь в исследование. Примените методы первичного исследования (на местах) и вторичного (кабинетного). В результате получится огромное количество неструктурированных результатов исследований.
2) Определение и синтез:
- Просуммируйте результаты исследования и поделитесь ими с командой.
- Сгруппируйте полученную информацию по темам.
- Найдите инсайты (инсайты — это правда о мотивациях, пожеланиях и досадах потребителей).
- Разработайте области возможностей (потенциальную область действий).
• определение и синтез — область для сосредоточения (схождение); • разработка и идеация — потенциальные решения (расхождение); • результат реализация — решение, которое работает (схождение).Стадия 2: сделай все правильно (Diamond 2 — разработка и внедрение). Как только вы определили правильный вопрос для поиска ответа, задачу для решения, нужно убедиться, что вы делаете все должным образом.
3) Разработка
Это веселая часть фазы расхождения. Вы должны запретить себе ограничиваться и подходить к процессу совершенно открыто. Используйте «да, и...» вместо «нет» или «да, но...». На этом этапе позвольте себе строить свои идеи на идеях друг друга.
В результате вы получите одну или несколько идей, которые потом сможете прототипировать и тестировать, чтобы найти лучший ответ на свой вопрос или решение задачи.
4) Результат и реализация. Примените гибкий подход из трех шагов:
- Разработка и прототипирование.
- Тестирование и анализ.
- Итерация и повторение.
Хотите больше знать о применимости продуктовых фреймворков? Приходите на магистерскую программу Управление цифровым продуктом от НИУ ВШЭ. Начать знакомство можно с Дня открытых дверей, где можно узнать всё об интересующих вас программах магистратуры и познакомится с руководителями программ, представителями бизнеса и выпускниками.
Регистрируйтесь по ссылке и подключайтесь online: http://dodmasters.hse.ru/
Образование актуально всегда, сейчас - это самая надёжная инвестиция!
dodmasters.hse.ru
Мероприятий для абитуриентов Высшей школы бизнеса
Серия мероприятий для абитуриентов Высшей школы бизнеса
Подборка ресурсов для подготовки ассессмента продакт-менеджеров
Сейчас особенно важно оценить свои компетенции и развиваться как профессионал дальше. Делюсь важными источниками для самооценки и проведения ее самостоятельно. Все команды и специалисты уникальны, как и ассессменты. Сохраняйте в закладки, чтобы не потерять, делитесь :
- Лайл М. Спенсер, Сайн М. Спенсер. Компетенции на работе
- Understanding Competencies and Competency Modeling
- Doing Competencies Well. Personnel Psychology
- Экопси. Data Enabled Employee Profile
- Экопси. Центры оценки: теоретические основы и технологии работы.
- Экопси. Разработка профессиональных компетенций на основе анализа данных, вебинар
- E-executive. Изготовление стула и понимание компетенций — что общего?
- Телеграм-канал «Экопси» о профессиональном развитии
- Телеграм-канал Анны Донской об оценке персонала
- Intercom: career path for product managers
- A competency-based model for the success of an entrepreneurial start-up
- Core Competency Deficits in Failed Startup Teams: Towards a Startup-specific Behavioral Competency Model
- Навыки менеджера продуктов от ProductSense
- Таблица навыков продакта, Product Star
Друзья, напоминаю, веду ещё канал с кейсами и эфирами (постараюсь на этой неделе онлайн-консультации по вопросам подписчиков провести - https://news.1rj.ru/str/sergeyproduct), канал с вакансиями, которые мне нравятся (https://news.1rj.ru/str/productjobgo) и подборки образовательных материалов для продактов (https://news.1rj.ru/str/eduproduct).
Также я продолжаю работать как продакт-консультант. Помогаю с налаживанием продуктовой работы и приоритизацией беклога, формулировкой стратегии и видением продукта, проверкой гипотез, проведением курсов по продакт-менеджменту и ассессментом отдела продактов. По запросам пишите автору канала - @SKoloskov
Сейчас особенно важно оценить свои компетенции и развиваться как профессионал дальше. Делюсь важными источниками для самооценки и проведения ее самостоятельно. Все команды и специалисты уникальны, как и ассессменты. Сохраняйте в закладки, чтобы не потерять, делитесь :
- Лайл М. Спенсер, Сайн М. Спенсер. Компетенции на работе
- Understanding Competencies and Competency Modeling
- Doing Competencies Well. Personnel Psychology
- Экопси. Data Enabled Employee Profile
- Экопси. Центры оценки: теоретические основы и технологии работы.
- Экопси. Разработка профессиональных компетенций на основе анализа данных, вебинар
- E-executive. Изготовление стула и понимание компетенций — что общего?
- Телеграм-канал «Экопси» о профессиональном развитии
- Телеграм-канал Анны Донской об оценке персонала
- Intercom: career path for product managers
- A competency-based model for the success of an entrepreneurial start-up
- Core Competency Deficits in Failed Startup Teams: Towards a Startup-specific Behavioral Competency Model
- Навыки менеджера продуктов от ProductSense
- Таблица навыков продакта, Product Star
Друзья, напоминаю, веду ещё канал с кейсами и эфирами (постараюсь на этой неделе онлайн-консультации по вопросам подписчиков провести - https://news.1rj.ru/str/sergeyproduct), канал с вакансиями, которые мне нравятся (https://news.1rj.ru/str/productjobgo) и подборки образовательных материалов для продактов (https://news.1rj.ru/str/eduproduct).
Также я продолжаю работать как продакт-консультант. Помогаю с налаживанием продуктовой работы и приоритизацией беклога, формулировкой стратегии и видением продукта, проверкой гипотез, проведением курсов по продакт-менеджменту и ассессментом отдела продактов. По запросам пишите автору канала - @SKoloskov
Тестирование в спринте: чек-лист
1. Тест-кейс — это документация тестировщика:
⁃ предусловия, или условия, которые не относятся к функционалу на проверке прямо, но обязательны для выполнения. Например, заполнение профиля доступно только зарегистрированному, авторизованному и подтверждённому пользователю. В таком случае в предусловиях тест-кейса «Заполнить профиль» должно быть: «пользователь зарегистрирован», «пользователь авторизован», «пользователь подтверждён»;
⁃ список шагов — список действий, которые позволят достичь поставленной цели: протестировать разработку; результат — краткое описание наиболее вероятного, по мнению тестировщика, результата после совершения всех шагов тестирования. В заключении может быть три варианта: «положительный», «отрицательный» и «тест блокирован».
2. Тестирование функциональности:
- Дымовое тестирование. Цель — проверить базовую функциональность приложения. Продумайте поведение пользователя, затем начните тестировать приложение. Сделайте позитивный тест и выполните целевое действие.
- После него начните тест негативный: попытайтесь «обмануть» программу, кликайте на разные кнопки, иконки, изображения и отслеживайте, как она реагирует на ваши действия. Продукт не должен открывать никаких лишних окон, картинок.
- Если всё прошло хорошо, переходите к следующему этапу. Если хотя бы в одном из этих тестов вы нашли ошибку, приложение нужно отправить на доработку с описанием обнаруженных багов в баг-репорте.
3. Регрессионное тестирование
⁃ регрессия багов. Цель тестировщика — увидеть и доказать, что найденная на более ранних этапах ошибка не была исправлена в полной мере или в принципе;
⁃ регрессия старых багов. Цель тестировщика — увидеть и доказать: разработчики изменили код или данные так, что старые баги начали снова воспроизводиться;
⁃ регрессия побочного эффекта. Цель тестировщика — увидеть и доказать: разработчики изменили код или данные так, что нетронутые части приложения сломались из-за этого (или приложение в целом вышло из строя).
4. Предрелизное тестирование
Процесс разработки должен быть построен так, чтобы для теста перед релизом оставались только мелкие функции, баги которых не требуют много времени для устранения. Также важно учитывать, чтобы возможные исправления не могли повлиять на другие части продукта и его поведение в принципе.
Хотите больше погрузиться в тестирование и документирование тестов? Приходите 21 марта в 20:00 в OTUS на открытый вебинар «Теория тестирования. Документация тестирования». Вместе с преподавателем-экспертом мы поговорим о той документации, которую составляет тестировщик, а именно: дефекты, чек-листы, тест-кейсы.
Регистрация на вебинар: https://otus.pw/LkiC/
1. Тест-кейс — это документация тестировщика:
⁃ предусловия, или условия, которые не относятся к функционалу на проверке прямо, но обязательны для выполнения. Например, заполнение профиля доступно только зарегистрированному, авторизованному и подтверждённому пользователю. В таком случае в предусловиях тест-кейса «Заполнить профиль» должно быть: «пользователь зарегистрирован», «пользователь авторизован», «пользователь подтверждён»;
⁃ список шагов — список действий, которые позволят достичь поставленной цели: протестировать разработку; результат — краткое описание наиболее вероятного, по мнению тестировщика, результата после совершения всех шагов тестирования. В заключении может быть три варианта: «положительный», «отрицательный» и «тест блокирован».
2. Тестирование функциональности:
- Дымовое тестирование. Цель — проверить базовую функциональность приложения. Продумайте поведение пользователя, затем начните тестировать приложение. Сделайте позитивный тест и выполните целевое действие.
- После него начните тест негативный: попытайтесь «обмануть» программу, кликайте на разные кнопки, иконки, изображения и отслеживайте, как она реагирует на ваши действия. Продукт не должен открывать никаких лишних окон, картинок.
- Если всё прошло хорошо, переходите к следующему этапу. Если хотя бы в одном из этих тестов вы нашли ошибку, приложение нужно отправить на доработку с описанием обнаруженных багов в баг-репорте.
3. Регрессионное тестирование
⁃ регрессия багов. Цель тестировщика — увидеть и доказать, что найденная на более ранних этапах ошибка не была исправлена в полной мере или в принципе;
⁃ регрессия старых багов. Цель тестировщика — увидеть и доказать: разработчики изменили код или данные так, что старые баги начали снова воспроизводиться;
⁃ регрессия побочного эффекта. Цель тестировщика — увидеть и доказать: разработчики изменили код или данные так, что нетронутые части приложения сломались из-за этого (или приложение в целом вышло из строя).
4. Предрелизное тестирование
Процесс разработки должен быть построен так, чтобы для теста перед релизом оставались только мелкие функции, баги которых не требуют много времени для устранения. Также важно учитывать, чтобы возможные исправления не могли повлиять на другие части продукта и его поведение в принципе.
Хотите больше погрузиться в тестирование и документирование тестов? Приходите 21 марта в 20:00 в OTUS на открытый вебинар «Теория тестирования. Документация тестирования». Вместе с преподавателем-экспертом мы поговорим о той документации, которую составляет тестировщик, а именно: дефекты, чек-листы, тест-кейсы.
Регистрация на вебинар: https://otus.pw/LkiC/
Количественные метрики при работе по Scrum
- Velocity — скорость, производительность команды. Количество задач и story point-ов, обработанных за один спринт. Velocity будет увеличиваться, когда команда учится работать быстрее и производительнее, совершенствует свои навыки. Если изменился формат — и люди теперь работают удаленно, то логично, что первые несколько спринтов Velocity упадет.
- Quality — метрика качества: сколько багов создается на релиз, модуль, или другую составную часть вашего продукта. То есть это метрика качества продукта, релиза, которую можно отслеживать количественно: сколько конкретно было багов.
- Story Creation — сколько историй создано вместе с командой. Story Creation — это не о тех историях, которые Product Owner или Scrum Master создали сами, а потом дали в команду для оценки. Должна быть совместная работа, а не «я все создал, а вы оценивайте».
- Accuracy of Commitment (Forecast). Насколько команда может придерживаться собственного плана, озвученного в первый день на Sprint Planning. Например, команда сделала прогноз, что закроет 24 пользовательских истории, чтобы прийти к цели спринта, а в итоге, закрыла всего 17.
- Overtime — овертаймит команда или нет, сколько времени это занимает.
Какую бы метрику не использовали, есть индикаторы, на которые смотреть обязательно:
- Отслеживайте Burn Down Chart не только по одному спринту, но смотрите шире: по командам, релизам и проектам.
- Замечайте количество и приоритетность дефектов: насколько их много в одном спринте или в одной истории.
- Смотрите на то, как улучшается или ухудшается Velocity и почему.
- Обращайте внимание на стабильность работы команды.
- Следите за скоростью backlog refinement: сколько спринтов нужно команде для детализации user story или любых других требований, с которыми они будут работать в следующих спринтах.
- Проверяйте стабильность работы Product Owner-а и команды с inflow vs outflow. Какие источники inflow, насколько стабильны требования, которые заходят в работу и насколько стабильно эти требования выполняются.
Хотите отшлифовать знания в чем отличие Scrum-мастера от обычного проектного менеджера и в чем его роль? Как устроена работа Scrum команды в проекте? Именно в этом и попробуем разобраться на бесплатном вебинаре “Роли в Scrum и их зоны ответственности" 23 марта в 20:00.
Там разберутся зоны ответственности каждой роли в Scrum, соответствия между действием и зоной ответственности и отличия Scrum Master от проектного менеджера
Спикер: Дмитрий Курдюмов, Agile мастер и СЕО Smart Units.
Участие бесплатное, но необходима предварительная регистрация по ссылке – https://otus.pw/dVyU/
- Velocity — скорость, производительность команды. Количество задач и story point-ов, обработанных за один спринт. Velocity будет увеличиваться, когда команда учится работать быстрее и производительнее, совершенствует свои навыки. Если изменился формат — и люди теперь работают удаленно, то логично, что первые несколько спринтов Velocity упадет.
- Quality — метрика качества: сколько багов создается на релиз, модуль, или другую составную часть вашего продукта. То есть это метрика качества продукта, релиза, которую можно отслеживать количественно: сколько конкретно было багов.
- Story Creation — сколько историй создано вместе с командой. Story Creation — это не о тех историях, которые Product Owner или Scrum Master создали сами, а потом дали в команду для оценки. Должна быть совместная работа, а не «я все создал, а вы оценивайте».
- Accuracy of Commitment (Forecast). Насколько команда может придерживаться собственного плана, озвученного в первый день на Sprint Planning. Например, команда сделала прогноз, что закроет 24 пользовательских истории, чтобы прийти к цели спринта, а в итоге, закрыла всего 17.
- Overtime — овертаймит команда или нет, сколько времени это занимает.
Какую бы метрику не использовали, есть индикаторы, на которые смотреть обязательно:
- Отслеживайте Burn Down Chart не только по одному спринту, но смотрите шире: по командам, релизам и проектам.
- Замечайте количество и приоритетность дефектов: насколько их много в одном спринте или в одной истории.
- Смотрите на то, как улучшается или ухудшается Velocity и почему.
- Обращайте внимание на стабильность работы команды.
- Следите за скоростью backlog refinement: сколько спринтов нужно команде для детализации user story или любых других требований, с которыми они будут работать в следующих спринтах.
- Проверяйте стабильность работы Product Owner-а и команды с inflow vs outflow. Какие источники inflow, насколько стабильны требования, которые заходят в работу и насколько стабильно эти требования выполняются.
Хотите отшлифовать знания в чем отличие Scrum-мастера от обычного проектного менеджера и в чем его роль? Как устроена работа Scrum команды в проекте? Именно в этом и попробуем разобраться на бесплатном вебинаре “Роли в Scrum и их зоны ответственности" 23 марта в 20:00.
Там разберутся зоны ответственности каждой роли в Scrum, соответствия между действием и зоной ответственности и отличия Scrum Master от проектного менеджера
Спикер: Дмитрий Курдюмов, Agile мастер и СЕО Smart Units.
Участие бесплатное, но необходима предварительная регистрация по ссылке – https://otus.pw/dVyU/
Что позволяют бесплатные продукты?
1. Снизить стоимость привлечения. Попробовать без денег проще, чем решиться сразу на покупку. Особенно актуально сейчас, когда неопределенность высока.
2. Увеличить виральность. Если продукт хорош и бесплатен, рекомендовать его одно удовольствие.
3. Пробиться через рекламный шум, создаваемый лидерами.
На чем зарабатывать?
1. На функционале, который нужен командам или профессиональным пользователям (Miro и Zoom)
2. На повышении лимитов. Например, 5 Гб — бесплатно; 50 Гб — за 50$ (Google Drive и iCloud)
3. На снижении раздражения. Можешь вручную вбить реквизиты и выставить счет в бесплатной версии. Или заплатить копеечку и сделать это автоматизировано.
Что должно оставаться бесплатным?
1. Функции, которые позволяют продукту распространяться. Например, совместное использование, возможность делиться (тот же Google Drive и Zoom)
2. Ваш главный «крючок». То, ради чего потребители приходят в продукт.
Хотите привлекать клиентов на сжимающемся, конкурентном, лихорадящем рынке — найдите способ взломать сложившуюся бизнес-модель.
Знакома ситуация “Отдаем продукт бесплатно — сидим без денег; начинаем продавать — отваливаются пользователи”? Приходите на курс «Продакт-менеджер». И за 8 недель получите знания и навыки, необходимые для запуска и развития продуктов. Старт 26 марта.
Также будут разобраны кейсы по незатратным способам проверки гипотез, улучшения ситуаций с рекламой, выбора метрики и поиска точки кратного роста продукта!
Программа:
-Проблемное интервью, чтобы находить боли и задачи потребителей
-Jobs-to-be-Done, чтобы успешно конкурировать
-Riskiest Assumption Test: проверять самое рискованное предположение
-Юнит-анализ. Следить, сходится ли экономика
-Пиратская воронка. За неделю проверять 5 гипотез. И делать выводы.
Преподаватели — Даниил Ханин (эксперт по юнит-экономике № 1, исполнительный директор Сбера), Андрей Торбичев (инвестор и предприниматель) и Светлана Чинарова (гуру performance-маркетинга).
Осталось 12 мест до полной группы. Программа тут; регистрация — тут. Для подписчиков канала - промокод FreshProductGo на 5000 рублей (не действует на Самостоятельный тариф).
Посмотреть стоимость и записаться на курс
1. Снизить стоимость привлечения. Попробовать без денег проще, чем решиться сразу на покупку. Особенно актуально сейчас, когда неопределенность высока.
2. Увеличить виральность. Если продукт хорош и бесплатен, рекомендовать его одно удовольствие.
3. Пробиться через рекламный шум, создаваемый лидерами.
На чем зарабатывать?
1. На функционале, который нужен командам или профессиональным пользователям (Miro и Zoom)
2. На повышении лимитов. Например, 5 Гб — бесплатно; 50 Гб — за 50$ (Google Drive и iCloud)
3. На снижении раздражения. Можешь вручную вбить реквизиты и выставить счет в бесплатной версии. Или заплатить копеечку и сделать это автоматизировано.
Что должно оставаться бесплатным?
1. Функции, которые позволяют продукту распространяться. Например, совместное использование, возможность делиться (тот же Google Drive и Zoom)
2. Ваш главный «крючок». То, ради чего потребители приходят в продукт.
Хотите привлекать клиентов на сжимающемся, конкурентном, лихорадящем рынке — найдите способ взломать сложившуюся бизнес-модель.
Знакома ситуация “Отдаем продукт бесплатно — сидим без денег; начинаем продавать — отваливаются пользователи”? Приходите на курс «Продакт-менеджер». И за 8 недель получите знания и навыки, необходимые для запуска и развития продуктов. Старт 26 марта.
Также будут разобраны кейсы по незатратным способам проверки гипотез, улучшения ситуаций с рекламой, выбора метрики и поиска точки кратного роста продукта!
Программа:
-Проблемное интервью, чтобы находить боли и задачи потребителей
-Jobs-to-be-Done, чтобы успешно конкурировать
-Riskiest Assumption Test: проверять самое рискованное предположение
-Юнит-анализ. Следить, сходится ли экономика
-Пиратская воронка. За неделю проверять 5 гипотез. И делать выводы.
Преподаватели — Даниил Ханин (эксперт по юнит-экономике № 1, исполнительный директор Сбера), Андрей Торбичев (инвестор и предприниматель) и Светлана Чинарова (гуру performance-маркетинга).
Осталось 12 мест до полной группы. Программа тут; регистрация — тут. Для подписчиков канала - промокод FreshProductGo на 5000 рублей (не действует на Самостоятельный тариф).
Посмотреть стоимость и записаться на курс
Ошибки выборки при проверках гипотез
Это отклонение средних характеристик выборочной совокупности от средних характеристик генеральной совокупности.
Например, есть интересный и немногочисленный сегмент пользователей (30–100 человек), можно опросить их всех. Или это стартап и уже есть первые пользователи. На практике требованиями количественной репрезентации иногда пренебрегают в силу нехватки ресурсов на обзвон (если это телефонный опрос) или времени на сбор ответов. Или если опрос проводят для сбора гипотез, а не для принятия конечного решения. Здесь важно понимать, какое решение должно быть принято на основе исследования. Если это важный продуктовый или бизнес-вопрос, то лучше потратить время и деньги на проверку гипотезы с репрезентативной выборкой, чтобы не получить неверные выводы. К примеру, опрос для сбора отклика по новой фиче, то можно остановиться на 30–60 респондентах.
Случайные выборки. Они предполагают, что в выборке каждый элемент генеральной совокупности имеет заранее заданную вероятность быть отобранным в исследование.
Простая случайная выборка. Сначала нужно присвоить каждому потенциальному респонденту идентификационный номер. Дальше с помощью генератора случайных чисел определить номера, которые будут включены в выборку для опроса.
Механическая выборка. Как и в простой выборке пользователям присваивается порядковый номер. Только отбор происходит не с помощью генератора случайных чисел, а с шагом равным n. Например, каждый сотый.
Стратифицированная выборка. Для такой выборки нужно поделить генеральную совокупность на сегменты или страты. После чего респонденты внутри каждой группы отбираются случайным образом. Из каждого сегмента выделяют пользователей пропорционально их доле в генеральной совокупности.
Кластерный отбор. Группа потенциальных респондентов отбирается случайным образом из всей генеральной совокупности. Далее внутри этой группы опрашиваются все пользователи. Например, можно опросить всех пользователей, которые зарегистрировались в сервисе в прошлом квартале.
Неслучайные выборки
Обычно такие методы отбора применяют, если нет возможности или ресурсов для формирования случайной выборки. Например, у тебя мало времени на опрос или нет данных о генеральной совокупности или респонденты труднодоступны.
Квотная выборка. Такой метод можно применять, если у вас есть знания о составе генеральной совокупности. Например, вы знаете, как ваши пользователи распределяются в разрезе по должности, отрасли компании, возрасту и так далее.
Стихийная выборка. Это метод без особых правил. В опрос попадают все, кто захочет пройти опрос. Такая выборка типична для онлайн-опросов, размещенных в свободном доступе.
«Снежный ком». Тоже достаточно популярная и простая методика. Каждого респондента просят порекомендовать нового среди его друзей, коллег и знакомых, которые подходили бы под параметры исследования.
«Типичный представитель». Из генеральной совокупности отбираются респонденты с типичными признаками целевой аудитории. Только определить, что взять за такой признак, обычно сложно.
Хотите лучше разобраться с основой основ: разработка MVP, тест гипотез, сборка прототипов, CustDev’ы с пользователями, когортный анализ, продуктовые метрики ?
Ребята из ProductStar расскажут вам всё о CustDev’ах на мини-марафоне 21 и 23 марта.
Если вы в продуктовой среде не первый день – узнаете новые фишки, структурируете существующие знания, сможете задать спикерам вопросы конкретно о ваших ситуациях.
Если вы новичок – поймете, что такое продакт-менеджмент, возьмете базу и даже на этом уровне сможете внедрить продуктовый подход в работу.
Регистрироваться: https://go.productstar.ru/2i9RM0
Это отклонение средних характеристик выборочной совокупности от средних характеристик генеральной совокупности.
Например, есть интересный и немногочисленный сегмент пользователей (30–100 человек), можно опросить их всех. Или это стартап и уже есть первые пользователи. На практике требованиями количественной репрезентации иногда пренебрегают в силу нехватки ресурсов на обзвон (если это телефонный опрос) или времени на сбор ответов. Или если опрос проводят для сбора гипотез, а не для принятия конечного решения. Здесь важно понимать, какое решение должно быть принято на основе исследования. Если это важный продуктовый или бизнес-вопрос, то лучше потратить время и деньги на проверку гипотезы с репрезентативной выборкой, чтобы не получить неверные выводы. К примеру, опрос для сбора отклика по новой фиче, то можно остановиться на 30–60 респондентах.
Случайные выборки. Они предполагают, что в выборке каждый элемент генеральной совокупности имеет заранее заданную вероятность быть отобранным в исследование.
Простая случайная выборка. Сначала нужно присвоить каждому потенциальному респонденту идентификационный номер. Дальше с помощью генератора случайных чисел определить номера, которые будут включены в выборку для опроса.
Механическая выборка. Как и в простой выборке пользователям присваивается порядковый номер. Только отбор происходит не с помощью генератора случайных чисел, а с шагом равным n. Например, каждый сотый.
Стратифицированная выборка. Для такой выборки нужно поделить генеральную совокупность на сегменты или страты. После чего респонденты внутри каждой группы отбираются случайным образом. Из каждого сегмента выделяют пользователей пропорционально их доле в генеральной совокупности.
Кластерный отбор. Группа потенциальных респондентов отбирается случайным образом из всей генеральной совокупности. Далее внутри этой группы опрашиваются все пользователи. Например, можно опросить всех пользователей, которые зарегистрировались в сервисе в прошлом квартале.
Неслучайные выборки
Обычно такие методы отбора применяют, если нет возможности или ресурсов для формирования случайной выборки. Например, у тебя мало времени на опрос или нет данных о генеральной совокупности или респонденты труднодоступны.
Квотная выборка. Такой метод можно применять, если у вас есть знания о составе генеральной совокупности. Например, вы знаете, как ваши пользователи распределяются в разрезе по должности, отрасли компании, возрасту и так далее.
Стихийная выборка. Это метод без особых правил. В опрос попадают все, кто захочет пройти опрос. Такая выборка типична для онлайн-опросов, размещенных в свободном доступе.
«Снежный ком». Тоже достаточно популярная и простая методика. Каждого респондента просят порекомендовать нового среди его друзей, коллег и знакомых, которые подходили бы под параметры исследования.
«Типичный представитель». Из генеральной совокупности отбираются респонденты с типичными признаками целевой аудитории. Только определить, что взять за такой признак, обычно сложно.
Хотите лучше разобраться с основой основ: разработка MVP, тест гипотез, сборка прототипов, CustDev’ы с пользователями, когортный анализ, продуктовые метрики ?
Ребята из ProductStar расскажут вам всё о CustDev’ах на мини-марафоне 21 и 23 марта.
Если вы в продуктовой среде не первый день – узнаете новые фишки, структурируете существующие знания, сможете задать спикерам вопросы конкретно о ваших ситуациях.
Если вы новичок – поймете, что такое продакт-менеджмент, возьмете базу и даже на этом уровне сможете внедрить продуктовый подход в работу.
Регистрироваться: https://go.productstar.ru/2i9RM0
Чем подход от решений лучше подхода от данных
При поддержке сервиса Kaiten.
1. Вы начинаете с вопросов, а не с данных. Коллектив, ориентированный на принятие решений, больше времени посвящает формулировке вопросов и обсуждению выдвигаемых предложений с теми, кто принимает решения.
2. Проектами руководят те, на ком лежит ответственность за принятие решений, а не специалисты по обработке данных. Ведь при строительстве дома решающее значение имеет мнение собственника дома (того, кто принимает окончательное решение), а не строителя, архитектора или водопроводчика, которые могут лишь грамотно направить, проконсультировать.
3. Над вопросами, на которые у вас нет ответов, вы размышляете чаще, чем над вопросами, на которые они у вас уже есть. Подход, основанный на принятии решений, заключается в поиске ответов на нерешённые вопросы.
4. Вы стараетесь оценить ситуацию в целом, после чего концентрируетесь на конкретном. Сотрудники компании, в своей работе опирающиеся на данные, зачастую слишком сильно углубляются в работу с имеющимися данными.
5. Вы аккумулируете новые данные. Сотрудники, которые в своей работе опираются на данные, склонны мыслить стереотипно и сосредоточены на поиске способов использовать уже имеющиеся данные.
6. У вас больше шансов обнаружить и уменьшить предвзятость. Те, кто привлекает к выполнению проектов неоднородные команды, склонны мыслить широко и не принимать предвзятых решений.
7. Бизнес смотрит вперёд, реже оглядываясь назад. Хотя прошлое может подсказать, в каком направлении двигаться дальше, не следует ожидать, что модели, существовавшие до пандемии, будут столь же эффективны в новых условиях.
Сейчас перейти или поддерживать переход фокуса на решения может помешать блокировка привычных инструментов. Хороший аналог Trello и Jira существует — сервис Kaiten. На Kaiten уже перешли Сбер, QIWI, Рег.ру, Skyeng, ДОДО Пицца. Перенести данные с других сервисов можно за 2 минуты с помощью специального бесплатного скрипта. Также Slack, Jira, Miro уже отзывают лицензии и блокируют свои сервисы у некоторых компаний в России. Пользователи Trello испытывают проблемы с оплатами.
В Кайтен есть все привычные инструменты:
⁃ Сервера находятся в РФ
⁃ Управление задачами - можно настроить RICE!
⁃ Канбан доска
⁃ Учёт времени работы сотрудников
⁃ Таймлайн для планирования проектов
⁃ Модуль для ведения базы знаний
⠀
По ссылке можно попробовать бесплатно сервис.
При поддержке сервиса Kaiten.
1. Вы начинаете с вопросов, а не с данных. Коллектив, ориентированный на принятие решений, больше времени посвящает формулировке вопросов и обсуждению выдвигаемых предложений с теми, кто принимает решения.
2. Проектами руководят те, на ком лежит ответственность за принятие решений, а не специалисты по обработке данных. Ведь при строительстве дома решающее значение имеет мнение собственника дома (того, кто принимает окончательное решение), а не строителя, архитектора или водопроводчика, которые могут лишь грамотно направить, проконсультировать.
3. Над вопросами, на которые у вас нет ответов, вы размышляете чаще, чем над вопросами, на которые они у вас уже есть. Подход, основанный на принятии решений, заключается в поиске ответов на нерешённые вопросы.
4. Вы стараетесь оценить ситуацию в целом, после чего концентрируетесь на конкретном. Сотрудники компании, в своей работе опирающиеся на данные, зачастую слишком сильно углубляются в работу с имеющимися данными.
5. Вы аккумулируете новые данные. Сотрудники, которые в своей работе опираются на данные, склонны мыслить стереотипно и сосредоточены на поиске способов использовать уже имеющиеся данные.
6. У вас больше шансов обнаружить и уменьшить предвзятость. Те, кто привлекает к выполнению проектов неоднородные команды, склонны мыслить широко и не принимать предвзятых решений.
7. Бизнес смотрит вперёд, реже оглядываясь назад. Хотя прошлое может подсказать, в каком направлении двигаться дальше, не следует ожидать, что модели, существовавшие до пандемии, будут столь же эффективны в новых условиях.
Сейчас перейти или поддерживать переход фокуса на решения может помешать блокировка привычных инструментов. Хороший аналог Trello и Jira существует — сервис Kaiten. На Kaiten уже перешли Сбер, QIWI, Рег.ру, Skyeng, ДОДО Пицца. Перенести данные с других сервисов можно за 2 минуты с помощью специального бесплатного скрипта. Также Slack, Jira, Miro уже отзывают лицензии и блокируют свои сервисы у некоторых компаний в России. Пользователи Trello испытывают проблемы с оплатами.
В Кайтен есть все привычные инструменты:
⁃ Сервера находятся в РФ
⁃ Управление задачами - можно настроить RICE!
⁃ Канбан доска
⁃ Учёт времени работы сотрудников
⁃ Таймлайн для планирования проектов
⁃ Модуль для ведения базы знаний
⠀
По ссылке можно попробовать бесплатно сервис.
kaiten.ru
Сервис для управления проектами, задачами, командой и бизнесом
Kaiten — платформа для управления проектами и задачами, которая помогает командам работать быстрее и продуктивнее. Удобные инструменты и наглядные доски.
Несколько лайфхаков успешных презентаций
Не забывайте про UX-мышление, когда готовите презентацию и лайфхаки:
1. С помощью правильной компоновки можно сделать слайд структурным, не поместив на него ни одной картинки или фигуры:
- разделить слайд по смыслу и сгруппировали родственные блоки;
- максимально сократить текст
- сделать заголовки центрами тяготения внимания;
-убрать лишнее пространство между текстами и заголовками;
-отдалить текст от остальных элементов презентации, чтобы он бросался в глаза.
2. Выравнивание добавляет упорядоченности на страницу и направляет внимание читателя. Это происходит за счет того, что создаются воображаемые прямые линии, которые мы воспринимаем как направляющие.
⁃ строки во всю ширину презентации очень тяжело читать, лучше разделить их на колонки и аккуратно выровнять;
⁃ интуитивно нам хочется равномерно заполнить весь слайд и выровнять все по середине. Но надо держать себя в руках: асимметричное расположение контента на слайде выглядит аппетитнее, а пустое пространство добавляет воздуха.
3. Единообразие: все, что может быть сделано единообразно, должно быть сделано единообразно. Если появляются различия в элементах, они должны быть обоснованы:
- Лучше выбрать один стандартный шрифт. Например, Arial, потому что он есть на всех компьютерах. В презентации можно использовать несколько вариаций одного шрифта по размеру и оформлению.
- В цветовой гамме должно быть не больше трех—четырех цветов, считая фоновый. Картинки и иконки тоже лучше оформить в едином стиле (можно скачивать коллекции иконок с единым дизайном).
- Хаотичная верстка разных слайдов. Есть режим шаблона, который позволяет закрепить базовые элементы на слайдах в определенном месте. Так повторяющиеся на нескольких слайдах объекты не будут «съезжать».
4. Приоритет и СТА в итогах презентации: самые приоритетные элементы нужно делать отличающимися от остального контента. При этом заметно отличающимися. Слабый контраст — когда шрифты чуть заметно отличаются по размеру, читатель размышляет не над содержанием, а над тем, специально ли так сделали или текст случайно «съехал». В конце обязателен вывод и предполагаемое решение. Или запрос на дискуссию.
Хотите быстро обучиться как всегда актуальным навыкам презентаций и коммуникаций на слайдах? Приходите к моим приятелям из Bonnie&Slide: “Мы в Bonnie&Slide видели, как росли компании, научившиеся делать презентации: как отдел продаж делал слайды, которые увеличивали продажи и средний чек. Мы видели, как финансовый отдел совершал меньше ошибок не от того, что больше знал математику, а потому что визуализировал свои цифры. Мы видели, как отдел маркетинга стал качественнее коммуницировать с дизайнерами — потому что задачи стали понятнее и информативнее.”
Выбрать обучение для себя и своих сотрудников со скидкой 20% можно по ссылке - ссылка
Не забывайте про UX-мышление, когда готовите презентацию и лайфхаки:
1. С помощью правильной компоновки можно сделать слайд структурным, не поместив на него ни одной картинки или фигуры:
- разделить слайд по смыслу и сгруппировали родственные блоки;
- максимально сократить текст
- сделать заголовки центрами тяготения внимания;
-убрать лишнее пространство между текстами и заголовками;
-отдалить текст от остальных элементов презентации, чтобы он бросался в глаза.
2. Выравнивание добавляет упорядоченности на страницу и направляет внимание читателя. Это происходит за счет того, что создаются воображаемые прямые линии, которые мы воспринимаем как направляющие.
⁃ строки во всю ширину презентации очень тяжело читать, лучше разделить их на колонки и аккуратно выровнять;
⁃ интуитивно нам хочется равномерно заполнить весь слайд и выровнять все по середине. Но надо держать себя в руках: асимметричное расположение контента на слайде выглядит аппетитнее, а пустое пространство добавляет воздуха.
3. Единообразие: все, что может быть сделано единообразно, должно быть сделано единообразно. Если появляются различия в элементах, они должны быть обоснованы:
- Лучше выбрать один стандартный шрифт. Например, Arial, потому что он есть на всех компьютерах. В презентации можно использовать несколько вариаций одного шрифта по размеру и оформлению.
- В цветовой гамме должно быть не больше трех—четырех цветов, считая фоновый. Картинки и иконки тоже лучше оформить в едином стиле (можно скачивать коллекции иконок с единым дизайном).
- Хаотичная верстка разных слайдов. Есть режим шаблона, который позволяет закрепить базовые элементы на слайдах в определенном месте. Так повторяющиеся на нескольких слайдах объекты не будут «съезжать».
4. Приоритет и СТА в итогах презентации: самые приоритетные элементы нужно делать отличающимися от остального контента. При этом заметно отличающимися. Слабый контраст — когда шрифты чуть заметно отличаются по размеру, читатель размышляет не над содержанием, а над тем, специально ли так сделали или текст случайно «съехал». В конце обязателен вывод и предполагаемое решение. Или запрос на дискуссию.
Хотите быстро обучиться как всегда актуальным навыкам презентаций и коммуникаций на слайдах? Приходите к моим приятелям из Bonnie&Slide: “Мы в Bonnie&Slide видели, как росли компании, научившиеся делать презентации: как отдел продаж делал слайды, которые увеличивали продажи и средний чек. Мы видели, как финансовый отдел совершал меньше ошибок не от того, что больше знал математику, а потому что визуализировал свои цифры. Мы видели, как отдел маркетинга стал качественнее коммуницировать с дизайнерами — потому что задачи стали понятнее и информативнее.”
Выбрать обучение для себя и своих сотрудников со скидкой 20% можно по ссылке - ссылка
3 вопроса для создания востребованного продукта
1: Как вы меняете процессы?
Да, как ваш продукт меняет то, что человек раньше делал сам, вручную или помощью других продуктов? Продукт – это в первую очередь про изменение процесса. Про это в том числе будут выступления на Продуктовом митапе: развивай, усиливай и расти.
Раньше заказывали такси по телефону. Как это было? Позвонить, повисеть на линии, сообщить адрес точки А, еще раз сказать адрес, потому что плохо слышно, услышать примерное время приезда такси, выйти на улицу и подождать 10 минут, пойти искать таксиста, который заблудился, сесть в такси, доехать до точки Б, оплатить, дождаться сдачи (если водитель найдет, конечно), выйти из машины.
Пришел Uber, убрал ненужные процессы и оставил только те, которые решают главную задачу человека –переместиться из точки А в точку Б. Если вы не меняете процессы, то вы не будете отличаться от конкурентов. Jobs To Be Done может точно определить, какие функции надо пилить в продукте, а какие нет. Посмотрите на свой бизнес и попробуйте понять, как вы меняете процессы для более качественного и быстрого решения задач клиентов.
2: Как вы меняете клиентов?
Попытайтесь забыть о процессах и сфокусируйтесь на людях. Что ваши клиенты могут себе позволить теперь, когда они успешно используют ваш продукт? Не говорите общими фразами. Привяжите их к вашему продукту. Например, пользователи Uber стали более свободными. Они быстрее перемещаются по городу и посещают больше мест за день.
Попробуйте понять, что теперь может позволить себе ваш клиент. Осознание того, как вы меняете клиента, поможет создать прорывную маркетинговую стратегию. Jobs To Be Done с ювелирной точностью определит новые состояния клиентов.
3: Как вы меняете рынок?
Многие думают, что бизнес получает деньги от клиентов, но это не так. У клиента как был определенный бюджет на решение данной задачи, так и остался. Вопрос состоит лишь в том, кому он отдаст этот бюджет. Вам или конкуренту? Поэтому очень важно понять, что именно вы собираетесь сделать с рынком и конкурентами. Например, Uber агрегировал в себе рынок таксопарков. Кого именно атаковать и как – поможет решить методология Jobs To be Done.
Если ваш продукт не отвечает на эти три вопроса, скорее всего, он такой же, как и у конкурентов, возможно, хуже. Четкие ответы на поставленные вопросы, особенно если вы получили их из уст пользователей, означают, что вы нашли нишу для востребованного продукта, который будет сам себя продавать.
Хотите поучаствовать в митапе, где будут еще рецепты запуска востребованных продуктов? Как найти точки роста компании и как собрать в digital-продукте? Приходите на
«Продуктовый митап: развивай, усиливай и расти», 5 апреля в 18:00 мск. Эксперты: Леруа Мерлен, AliExpress и AGIMA. Там будет о данных, как их собирать и на какие показатели ориентироваться. Юнит-экономика, А/Б-тест и Data Driven-подход к продукту.
Регистрация по ссылке - Продуктовый митап: развивай, усиливай и расти.
Когда нужна помощь по запуску продуктов, поиску точек роста и создании продуктовой культуры - обращайтесь к автору канала.
1: Как вы меняете процессы?
Да, как ваш продукт меняет то, что человек раньше делал сам, вручную или помощью других продуктов? Продукт – это в первую очередь про изменение процесса. Про это в том числе будут выступления на Продуктовом митапе: развивай, усиливай и расти.
Раньше заказывали такси по телефону. Как это было? Позвонить, повисеть на линии, сообщить адрес точки А, еще раз сказать адрес, потому что плохо слышно, услышать примерное время приезда такси, выйти на улицу и подождать 10 минут, пойти искать таксиста, который заблудился, сесть в такси, доехать до точки Б, оплатить, дождаться сдачи (если водитель найдет, конечно), выйти из машины.
Пришел Uber, убрал ненужные процессы и оставил только те, которые решают главную задачу человека –переместиться из точки А в точку Б. Если вы не меняете процессы, то вы не будете отличаться от конкурентов. Jobs To Be Done может точно определить, какие функции надо пилить в продукте, а какие нет. Посмотрите на свой бизнес и попробуйте понять, как вы меняете процессы для более качественного и быстрого решения задач клиентов.
2: Как вы меняете клиентов?
Попытайтесь забыть о процессах и сфокусируйтесь на людях. Что ваши клиенты могут себе позволить теперь, когда они успешно используют ваш продукт? Не говорите общими фразами. Привяжите их к вашему продукту. Например, пользователи Uber стали более свободными. Они быстрее перемещаются по городу и посещают больше мест за день.
Попробуйте понять, что теперь может позволить себе ваш клиент. Осознание того, как вы меняете клиента, поможет создать прорывную маркетинговую стратегию. Jobs To Be Done с ювелирной точностью определит новые состояния клиентов.
3: Как вы меняете рынок?
Многие думают, что бизнес получает деньги от клиентов, но это не так. У клиента как был определенный бюджет на решение данной задачи, так и остался. Вопрос состоит лишь в том, кому он отдаст этот бюджет. Вам или конкуренту? Поэтому очень важно понять, что именно вы собираетесь сделать с рынком и конкурентами. Например, Uber агрегировал в себе рынок таксопарков. Кого именно атаковать и как – поможет решить методология Jobs To be Done.
Если ваш продукт не отвечает на эти три вопроса, скорее всего, он такой же, как и у конкурентов, возможно, хуже. Четкие ответы на поставленные вопросы, особенно если вы получили их из уст пользователей, означают, что вы нашли нишу для востребованного продукта, который будет сам себя продавать.
Хотите поучаствовать в митапе, где будут еще рецепты запуска востребованных продуктов? Как найти точки роста компании и как собрать в digital-продукте? Приходите на
«Продуктовый митап: развивай, усиливай и расти», 5 апреля в 18:00 мск. Эксперты: Леруа Мерлен, AliExpress и AGIMA. Там будет о данных, как их собирать и на какие показатели ориентироваться. Юнит-экономика, А/Б-тест и Data Driven-подход к продукту.
Регистрация по ссылке - Продуктовый митап: развивай, усиливай и расти.
Когда нужна помощь по запуску продуктов, поиску точек роста и создании продуктовой культуры - обращайтесь к автору канала.
AGIMA
Product meetup
«Продуктовый митап: развивай, усиливай и расти», 5 апреля в 18:00 мск. Эксперты: Леруа Мерлен, AliExpress, AGIMA AI и AGIMA
Продукты – новые тренды наступившей весны
Robokazakh - Сервис удаленного открытия карт Visa и Mastercard в Банках Казахстана. Когда не можешь оплатить любимый Spotify, купить игру в Steam и получить деньги из-за рубежа…Весь процесс проходит онлайн, от вас потребуется загранпаспорт. Оформить заявку и прочитать ответы на частые вопросы можно в боте https://news.1rj.ru/str/Robokazakh_bot
Charlie - Персональная заботливая газета с крутыми фильтрами, которая поможет оставаться в курсе новостей, но не сойти с ума (то, что нам всем сейчас очень нужно).
Waitlyst - Инструмент для анализа фидбека аудитории (и, как следствие, создания мощных продуктов под запросы рынка).
Neuton TinyML - Инструмент, который позволяет создавать крохотные и понятные модели и встраивать их в любой микроконтроллер. Без знаний кода и ML.
Waitlyst - Софт, помогающий создавать топовые диджитал-продукты, учитывая отзывы и интересы клиентов.
Loggo - Быстрое и удобное решение для отслеживания симптомов гриппа и простуды (и не только).
Dowork ai - ПО, которое помогает аутсорс-компаниям с максимальной точностью оценивать проекты.
Reach.Live - Платформа, с помощью которой вы сможете хостить вебинары, демо, онлайн-собеседования и прочие ивенты.
Piktochart - Платформа, которая помогает превратить любой текст или «тяжёлый» контент в лаконичную визуальную историю.
togetherAI - Приложение на базе ИИ, помогающее семьям поддерживать здоровую (во всех отношениях) атмосферу в семье.
Делитесь и сохраняйте подборку себе!
Robokazakh - Сервис удаленного открытия карт Visa и Mastercard в Банках Казахстана. Когда не можешь оплатить любимый Spotify, купить игру в Steam и получить деньги из-за рубежа…Весь процесс проходит онлайн, от вас потребуется загранпаспорт. Оформить заявку и прочитать ответы на частые вопросы можно в боте https://news.1rj.ru/str/Robokazakh_bot
Charlie - Персональная заботливая газета с крутыми фильтрами, которая поможет оставаться в курсе новостей, но не сойти с ума (то, что нам всем сейчас очень нужно).
Waitlyst - Инструмент для анализа фидбека аудитории (и, как следствие, создания мощных продуктов под запросы рынка).
Neuton TinyML - Инструмент, который позволяет создавать крохотные и понятные модели и встраивать их в любой микроконтроллер. Без знаний кода и ML.
Waitlyst - Софт, помогающий создавать топовые диджитал-продукты, учитывая отзывы и интересы клиентов.
Loggo - Быстрое и удобное решение для отслеживания симптомов гриппа и простуды (и не только).
Dowork ai - ПО, которое помогает аутсорс-компаниям с максимальной точностью оценивать проекты.
Reach.Live - Платформа, с помощью которой вы сможете хостить вебинары, демо, онлайн-собеседования и прочие ивенты.
Piktochart - Платформа, которая помогает превратить любой текст или «тяжёлый» контент в лаконичную визуальную историю.
togetherAI - Приложение на базе ИИ, помогающее семьям поддерживать здоровую (во всех отношениях) атмосферу в семье.
Делитесь и сохраняйте подборку себе!
Как бороться с возражениями “это слишком дорого” и “у меня нет времени”
1. “Это слишком дорого” не означает “не могу себе этого позволить”. Это означает: я не получаю достаточной ценности, чтобы оправдать то, что я трачу”. Мы слышим “это слишком дорого” и предполагаем, что это не наш целевой клиент. Или что нам нужно снизить цену на наши решения. И часто ни то, ни другое не решает основных проблем. Деньги есть, и они решили не тратить их на ваше решение.
Вы можете уточнить:
⁃ Узнайте, за что еще ваши клиенты уже платят. Любая цена слишком дорога для клиента, который не хочет ни за что платить. Большинство стартапов на ранних стадиях выберут "бесплатный" вместо любой платной альтернативы.
⁃ Платит ли этот клиент за что-нибудь? Если да, то как они это оправдывают? Кого они должны убедить и как они это обосновывают?
⁃ Поймите, как покупка / закупка работает для вашего клиента. На предприятиях часто существует разделительная линия между тем, что может быть легко израсходовано, и тем, что требует многоэтапного утверждения закупок.
⁃ Нужно понять, какая ценность изменит правила игры (откроет новые возможности, устранит неопределенности). “Делай X быстрее” и “делай X дешевле” имеют значение только тогда, когда экономия настолько велика, что вы можете открыть новую возможность. Что изменит правила игры, так это “Раньше я не мог делать X; теперь я могу” или “Раньше мне приходилось беспокоиться о X; теперь мне не нужно об этом думать”. Это трудно выполнить на таком уровне ценности, а когда вы можете, это невероятно сложно.
2. “У меня нет времени” не означает нехватку часов или минут в календаре; это означает: я не вижу здесь достаточной ценности, чтобы прилагать усилия. Это одно из вежливых "да", которое заманивает в ловушку людей, занимающихся продуктами. Мы слышим “У меня нет времени” и думаем: “Хорошо, я оставлю этого клиента в покое и вернусь к нему позже”. Клиенты не утруждают себя жалобами на продукты, с которыми они на самом деле даже не могли начать. Что можно спросить:
- Выясните, сколько времени требуется клиенту, чтобы настроить / начать использовать ваш продукт.
- Затем определите разницу между клиентами. Для кого это быстро / легко? Для кого это медленно / сложно?
- Найдите существующую привычку / процесс клиентов, на которые ваш продукт наиболее похож
- Если у клиентов складывается первоначальное впечатление, что для начала использования вашего продукта требуется много времени или что для этого им необходимо принять множество решений, то существует действительно высокая планка того, насколько ценным он должен быть, чтобы его стоило использовать.
- Выясните, сколько времени требуется клиенту, чтобы настроить / начать использовать ваш продукт. Некоторые команды начали использовать показатель “5 минут до ”вау"" – первый шаг к этому - получение базовой линии.
Продуктовая команда должна быть сфокусирована на нуждах клиента. Но как узнать, что ему действительно нужно? (https://otus.pw/9d7B/) Об этом расскажу на вебинаре в OTUS 4 апреля.
Вы получите:
-Самое нужное из теоретической базы CustDev
-Понимание, как составить вопросы, чтобы ответы проверяли гипотезы и приносили инсайты
-Знание, как правильно из ответов собрать продукт, который купят
-Чек-лист для создания сценариев и подведения итогов
-Сценарий интервью
-Ответы на вопросы
Регистрируйтесь и подключайтесь: https://otus.pw/9d7B/
Занятие — часть курса «Product Manager IT-проектов», можно познакомиться с руководителем программы и задать все вопросы.
Если нужна помощь по продуктам, пишите автору канала — и мы назначим встречу за кофе!
1. “Это слишком дорого” не означает “не могу себе этого позволить”. Это означает: я не получаю достаточной ценности, чтобы оправдать то, что я трачу”. Мы слышим “это слишком дорого” и предполагаем, что это не наш целевой клиент. Или что нам нужно снизить цену на наши решения. И часто ни то, ни другое не решает основных проблем. Деньги есть, и они решили не тратить их на ваше решение.
Вы можете уточнить:
⁃ Узнайте, за что еще ваши клиенты уже платят. Любая цена слишком дорога для клиента, который не хочет ни за что платить. Большинство стартапов на ранних стадиях выберут "бесплатный" вместо любой платной альтернативы.
⁃ Платит ли этот клиент за что-нибудь? Если да, то как они это оправдывают? Кого они должны убедить и как они это обосновывают?
⁃ Поймите, как покупка / закупка работает для вашего клиента. На предприятиях часто существует разделительная линия между тем, что может быть легко израсходовано, и тем, что требует многоэтапного утверждения закупок.
⁃ Нужно понять, какая ценность изменит правила игры (откроет новые возможности, устранит неопределенности). “Делай X быстрее” и “делай X дешевле” имеют значение только тогда, когда экономия настолько велика, что вы можете открыть новую возможность. Что изменит правила игры, так это “Раньше я не мог делать X; теперь я могу” или “Раньше мне приходилось беспокоиться о X; теперь мне не нужно об этом думать”. Это трудно выполнить на таком уровне ценности, а когда вы можете, это невероятно сложно.
2. “У меня нет времени” не означает нехватку часов или минут в календаре; это означает: я не вижу здесь достаточной ценности, чтобы прилагать усилия. Это одно из вежливых "да", которое заманивает в ловушку людей, занимающихся продуктами. Мы слышим “У меня нет времени” и думаем: “Хорошо, я оставлю этого клиента в покое и вернусь к нему позже”. Клиенты не утруждают себя жалобами на продукты, с которыми они на самом деле даже не могли начать. Что можно спросить:
- Выясните, сколько времени требуется клиенту, чтобы настроить / начать использовать ваш продукт.
- Затем определите разницу между клиентами. Для кого это быстро / легко? Для кого это медленно / сложно?
- Найдите существующую привычку / процесс клиентов, на которые ваш продукт наиболее похож
- Если у клиентов складывается первоначальное впечатление, что для начала использования вашего продукта требуется много времени или что для этого им необходимо принять множество решений, то существует действительно высокая планка того, насколько ценным он должен быть, чтобы его стоило использовать.
- Выясните, сколько времени требуется клиенту, чтобы настроить / начать использовать ваш продукт. Некоторые команды начали использовать показатель “5 минут до ”вау"" – первый шаг к этому - получение базовой линии.
Продуктовая команда должна быть сфокусирована на нуждах клиента. Но как узнать, что ему действительно нужно? (https://otus.pw/9d7B/) Об этом расскажу на вебинаре в OTUS 4 апреля.
Вы получите:
-Самое нужное из теоретической базы CustDev
-Понимание, как составить вопросы, чтобы ответы проверяли гипотезы и приносили инсайты
-Знание, как правильно из ответов собрать продукт, который купят
-Чек-лист для создания сценариев и подведения итогов
-Сценарий интервью
-Ответы на вопросы
Регистрируйтесь и подключайтесь: https://otus.pw/9d7B/
Занятие — часть курса «Product Manager IT-проектов», можно познакомиться с руководителем программы и задать все вопросы.
Если нужна помощь по продуктам, пишите автору канала — и мы назначим встречу за кофе!
Крутые мысли из канала Product Management Владимира Миролюбова
1. Вы должны фильтровать идеи своих продуктов по двум простым параметрам: могут ли они расти и есть ли у вас доступ к масштабируемому каналу распространения.
Не стесняйтесь иметь узкую целевую аудиторию в начале. Все большие вещи вырастали из небольших групп по интересам. Если вы не можете использовать своё приложение в туалете или во время отвлечения внимания, например, за рулем машины, то у ваших пользователей будет меньше возможностей сформировать привычку пользоваться им.
Ссылка на пост - https://news.1rj.ru/str/ruspm/925
2. Плохую продуктовую стратегию (или её отсутствие) можно обнаружить по следующим признакам:
- Постоянные и бесконечные войны в приоритетах фич (и команд, их продвигающих).
- Менеджеры по продукту ищут краткосрочные цели, а не идут по долгосрочным.
- Разработчики, дизайнеры, маркетинг и другие команды не понимают, зачем они работают над теми или иными вещами.
- Рассинхрон между дорожной картой, бизнес-целями и метриками, которые вы постоянно меняете.
Ссылка на пост - https://news.1rj.ru/str/ruspm/964
3. Ошибка № 4 при проведении исследований пользователей и аудитории от Рэнда Фишкина (основатель MOZ и SparkToro): Предполагать, что аудитория, которой вы еще не привлекли, будет реагировать так же, как и клиенты, которые уже купили. Из-за этой ошибки многие упускают возможности роста. Разные сообщения для разных людей в разных каналах часто лучше, чем один шаблон для всех.
Ссылка на пост - https://news.1rj.ru/str/ruspm/969
4. Большинство команд думают, что они работают в продуктовых командах, в то время, как они могут быть фиче-командами или командами доставки. Стоит понимать разницу. Команды по продуктам: решают, что они создают. Команды по продуктовой разработке помогают определить специфику функций, которые они создают. Команды доставки выполняют определенные функции. Пользователям требуется больше времени, если перед ними больший выбор. Не заставляйте пользователей тратить на время – помогайте им и максимально ограничивайте выбор.
Ссылка на пост - https://news.1rj.ru/str/ruspm/982
5. Массовость как порок. Как только продукт мегакорпорации достигает массового масштаба, давление KPI и прочих метрик часто вынуждает продакт-менеджеров отдавать предпочтение широте использования продукта и росту этих самых метрик, а не глубине его использования (решения кросс-проблем, росту вовлечения и других прокси-метрик).Примеры – GoogleDocs и Notion. Notion отжал у Гугла существенный кусок пирога писателей именно за счет вертикального проникновения, сделав ставку на начальное позиционирование на узкой IT-аудитории.
Ссылка на пост - https://news.1rj.ru/str/ruspm/984
Хотите еще больше актуальных инсайтов и материалов по продакт-менеджменту? Подписывайтесь и перечитывайте канал https://news.1rj.ru/str/ruspm !
1. Вы должны фильтровать идеи своих продуктов по двум простым параметрам: могут ли они расти и есть ли у вас доступ к масштабируемому каналу распространения.
Не стесняйтесь иметь узкую целевую аудиторию в начале. Все большие вещи вырастали из небольших групп по интересам. Если вы не можете использовать своё приложение в туалете или во время отвлечения внимания, например, за рулем машины, то у ваших пользователей будет меньше возможностей сформировать привычку пользоваться им.
Ссылка на пост - https://news.1rj.ru/str/ruspm/925
2. Плохую продуктовую стратегию (или её отсутствие) можно обнаружить по следующим признакам:
- Постоянные и бесконечные войны в приоритетах фич (и команд, их продвигающих).
- Менеджеры по продукту ищут краткосрочные цели, а не идут по долгосрочным.
- Разработчики, дизайнеры, маркетинг и другие команды не понимают, зачем они работают над теми или иными вещами.
- Рассинхрон между дорожной картой, бизнес-целями и метриками, которые вы постоянно меняете.
Ссылка на пост - https://news.1rj.ru/str/ruspm/964
3. Ошибка № 4 при проведении исследований пользователей и аудитории от Рэнда Фишкина (основатель MOZ и SparkToro): Предполагать, что аудитория, которой вы еще не привлекли, будет реагировать так же, как и клиенты, которые уже купили. Из-за этой ошибки многие упускают возможности роста. Разные сообщения для разных людей в разных каналах часто лучше, чем один шаблон для всех.
Ссылка на пост - https://news.1rj.ru/str/ruspm/969
4. Большинство команд думают, что они работают в продуктовых командах, в то время, как они могут быть фиче-командами или командами доставки. Стоит понимать разницу. Команды по продуктам: решают, что они создают. Команды по продуктовой разработке помогают определить специфику функций, которые они создают. Команды доставки выполняют определенные функции. Пользователям требуется больше времени, если перед ними больший выбор. Не заставляйте пользователей тратить на время – помогайте им и максимально ограничивайте выбор.
Ссылка на пост - https://news.1rj.ru/str/ruspm/982
5. Массовость как порок. Как только продукт мегакорпорации достигает массового масштаба, давление KPI и прочих метрик часто вынуждает продакт-менеджеров отдавать предпочтение широте использования продукта и росту этих самых метрик, а не глубине его использования (решения кросс-проблем, росту вовлечения и других прокси-метрик).Примеры – GoogleDocs и Notion. Notion отжал у Гугла существенный кусок пирога писателей именно за счет вертикального проникновения, сделав ставку на начальное позиционирование на узкой IT-аудитории.
Ссылка на пост - https://news.1rj.ru/str/ruspm/984
Хотите еще больше актуальных инсайтов и материалов по продакт-менеджменту? Подписывайтесь и перечитывайте канал https://news.1rj.ru/str/ruspm !
Основные методики построения архитектуры предприятия
Работая как продакт-эксперт с разными компаниями, стараюсь не забывать и об общих цифровых трансформациях внутри компании. Данный пост про основные методики построения архитектуры предприятия:
1. Методика TOGAF предлагает способы и подходы для выстраивания, планирования, применения IT-архитектуры предприятия и, впоследствии, управления ею. Архитектура предприятия по TOGAF представлена четырьмя направлениями: Архитектура бизнеса, Архитектура приложений, Архитектура данных, Архитектура технологии.
Основной областью применения TOGAF является программная инфраструктура информационной системы (описание интеграционных компонентов). Данная методика довольно детально описывает процесс создания архитектуры, а также позволяет управлять требованиями заинтересованных лиц на каждом из этапов проработки.
2. Методика Gartner трактует понятие «архитектура предприятия» как процесс перевода видения и стратегии бизнеса в эффективное изменение компании посредством создания, обсуждения и улучшений ключевых требований, принципов и моделей, которые описывают будущее состояние компании. Общая идея Gartner включает создание «идеальной» картинки будущего в бизнеспредставлении и, на ее основе, определение изменений архитектуры (в приоритетном порядке) для достижения конечной цели. Цель данной архитектуры предприятия — стратегия, а не ее техническая реализация. Суть методики — создание процесса, который позволит развивать архитектуру в соответствии с высокоуровневой архитектурой бизнес-стратегии.
3. Методика META Group рассматривает архитектуру предприятия в интеграции с другими процессами, к примеру с процессом управления корпоративными IT-программами и проектами и процессом выработки стратегии и планирования. Основными этапами разработки архитектуры предприятия являются:
⁃ Видение общих требований, где осуществляется анализ вектора развития, определение требований к информационным системам.
⁃ Создание концептуальной архитектуры, где определяется перечень правил, который обеспечивает общий принцип для развития информационных систем предприятия и технологической инфраструктуры. При создании концептуальной архитектуры мы получаем набор принципов (правил), обеспечивающих развитие информационных систем предприятия и технологической инфраструктуры.
Хотите лучше понимать, как управлять корпоративной архитектурой? Начните подготовку с вебинара «Обоснованные структурные изменения организации в быстро меняющихся условиях» 4 апреля в 19:00 (мск).
Demo-занятие является частью онлайн-курса «Enterprise Architect». Не упустите возможность познакомиться с преподавателем и протестировать обучение в OTUS.
Зарегистрируйтесь на мероприятие, чтобы участвовать https://otus.pw/K5Ep/
Работая как продакт-эксперт с разными компаниями, стараюсь не забывать и об общих цифровых трансформациях внутри компании. Данный пост про основные методики построения архитектуры предприятия:
1. Методика TOGAF предлагает способы и подходы для выстраивания, планирования, применения IT-архитектуры предприятия и, впоследствии, управления ею. Архитектура предприятия по TOGAF представлена четырьмя направлениями: Архитектура бизнеса, Архитектура приложений, Архитектура данных, Архитектура технологии.
Основной областью применения TOGAF является программная инфраструктура информационной системы (описание интеграционных компонентов). Данная методика довольно детально описывает процесс создания архитектуры, а также позволяет управлять требованиями заинтересованных лиц на каждом из этапов проработки.
2. Методика Gartner трактует понятие «архитектура предприятия» как процесс перевода видения и стратегии бизнеса в эффективное изменение компании посредством создания, обсуждения и улучшений ключевых требований, принципов и моделей, которые описывают будущее состояние компании. Общая идея Gartner включает создание «идеальной» картинки будущего в бизнеспредставлении и, на ее основе, определение изменений архитектуры (в приоритетном порядке) для достижения конечной цели. Цель данной архитектуры предприятия — стратегия, а не ее техническая реализация. Суть методики — создание процесса, который позволит развивать архитектуру в соответствии с высокоуровневой архитектурой бизнес-стратегии.
3. Методика META Group рассматривает архитектуру предприятия в интеграции с другими процессами, к примеру с процессом управления корпоративными IT-программами и проектами и процессом выработки стратегии и планирования. Основными этапами разработки архитектуры предприятия являются:
⁃ Видение общих требований, где осуществляется анализ вектора развития, определение требований к информационным системам.
⁃ Создание концептуальной архитектуры, где определяется перечень правил, который обеспечивает общий принцип для развития информационных систем предприятия и технологической инфраструктуры. При создании концептуальной архитектуры мы получаем набор принципов (правил), обеспечивающих развитие информационных систем предприятия и технологической инфраструктуры.
Хотите лучше понимать, как управлять корпоративной архитектурой? Начните подготовку с вебинара «Обоснованные структурные изменения организации в быстро меняющихся условиях» 4 апреля в 19:00 (мск).
Demo-занятие является частью онлайн-курса «Enterprise Architect». Не упустите возможность познакомиться с преподавателем и протестировать обучение в OTUS.
Зарегистрируйтесь на мероприятие, чтобы участвовать https://otus.pw/K5Ep/
otus.ru
Курс Enterprise Architect: архитектор предприятия или корпоративный архитектор
Задачи Enterprise Architect — создавать, согласовывать и поддерживать целевое видение и траекторию развития компании, конкретизируя стратегию цифровизации и принимая обоснованные технологические решения на ее основе
Хорошие посты от Владимира Меркушева
Подсмотрел на канале https://news.1rj.ru/str/vladimir_merkushev
Про модель монетизации. Модель монетизации и ее эффективность, в свою очередь, определяют каналы, где у продукта может быть product/channel fit. Например, продукт с рекламной монетизацией не сможет окупить затраты на привлечение клиентов с помощью команды прямых продаж, которая отлично работает для B2B продуктов. Модель монетизации влияет на силу product/market fit. При определенной цене и структуре модели монетизации продукт уже не будет иметь добавочную ценность относительно других альтернатив на рынке. Например, модель монетизации с оплатой за каждое сообщение (то есть транзакционная модель) сведет к нулю ценность любого мессенджера. Модель монетизации влияет и на целевой рынок. С ростом стоимости продукта будет сокращаться количество потенциальных клиентов и их будет всё сложнее привлекать. Тот продукт, модель монетизации которого позволит привлекать их с положительным ROI, выиграет в долгосрочной перспективе.
Рост продукта возможен только при достижении баланса между всеми этими взаимосвязанными элементами. Помните об этом, уделяйте внимание всем факторам и смотрите на них как на систему.
Подробнее - https://news.1rj.ru/str/vladimir_merkushev/1331
Про разницу продуктовых команд в СНГ и Европе.
В большинстве компаний в СНГ за цель конкретной команды отвечает ее менеджер. Разработчики, дизайнеры, аналитики прямой ответственности за общую цель не несут. Им нужно писать хороший код, делать качественный дизайн, быстро находить ответы на вопросы в данных.
За результаты команды в Европе отвечает вся команда. Менеджер продукта accountable, but not only responsible person. Он говорит о результатах от имени команды и большинство решений принимает вместе с командой. Цели и их достижение регулярно обсуждаются на командных встречах. Управлять процессами на разных этапах работы могут разные члены команды. Это может быть дизайнер, разработчик, продакт или аналитик. Такой подход снимает с продакта большой объём операционки и помогает вовлечению всех в команде в тактические решения. Ключевая работа продакта – создать условия, в которых каждый участник команды будет четко понимать, что делает команда и куда хочет добежать, для чего и зачем это нужно. У каждой команды есть своя миссия — это одно предложение, где доносится, зачем существует команда. Миссия формулируется не с точки зрения интересов бизнеса, а с точки зрения интересов пользователя. Наличие публичного дашборда с метриками — обязательное условие работы. Каждый проект или эксперимент содержит в описании целевые метрики (которые хотим изменить) и health metrics (на которые можем повлиять и хотим контролировать это влияние). Подробнее - https://news.1rj.ru/str/vladimir_merkushev/1323
Про Уточняющий NPS
Медленная метрика, которая позволяет оценить отношение клиентов к продукту и желание его рекомендовать. А также получить понимание как изменения в продукте влияют на восприятие клиентами. Надеюсь, вы уже используете NPS и отслеживаете его изменение месяц к месяцу. Обычно NPS считают на базе опроса новых пользователей, которые провели в продукте определенное время и/или совершили целевые действия. Подробнее - https://news.1rj.ru/str/vladimir_merkushev/1292
Хотите больше постов - подписывайтесь на https://news.1rj.ru/str/vladimir_merkushev
Подсмотрел на канале https://news.1rj.ru/str/vladimir_merkushev
Про модель монетизации. Модель монетизации и ее эффективность, в свою очередь, определяют каналы, где у продукта может быть product/channel fit. Например, продукт с рекламной монетизацией не сможет окупить затраты на привлечение клиентов с помощью команды прямых продаж, которая отлично работает для B2B продуктов. Модель монетизации влияет на силу product/market fit. При определенной цене и структуре модели монетизации продукт уже не будет иметь добавочную ценность относительно других альтернатив на рынке. Например, модель монетизации с оплатой за каждое сообщение (то есть транзакционная модель) сведет к нулю ценность любого мессенджера. Модель монетизации влияет и на целевой рынок. С ростом стоимости продукта будет сокращаться количество потенциальных клиентов и их будет всё сложнее привлекать. Тот продукт, модель монетизации которого позволит привлекать их с положительным ROI, выиграет в долгосрочной перспективе.
Рост продукта возможен только при достижении баланса между всеми этими взаимосвязанными элементами. Помните об этом, уделяйте внимание всем факторам и смотрите на них как на систему.
Подробнее - https://news.1rj.ru/str/vladimir_merkushev/1331
Про разницу продуктовых команд в СНГ и Европе.
В большинстве компаний в СНГ за цель конкретной команды отвечает ее менеджер. Разработчики, дизайнеры, аналитики прямой ответственности за общую цель не несут. Им нужно писать хороший код, делать качественный дизайн, быстро находить ответы на вопросы в данных.
За результаты команды в Европе отвечает вся команда. Менеджер продукта accountable, but not only responsible person. Он говорит о результатах от имени команды и большинство решений принимает вместе с командой. Цели и их достижение регулярно обсуждаются на командных встречах. Управлять процессами на разных этапах работы могут разные члены команды. Это может быть дизайнер, разработчик, продакт или аналитик. Такой подход снимает с продакта большой объём операционки и помогает вовлечению всех в команде в тактические решения. Ключевая работа продакта – создать условия, в которых каждый участник команды будет четко понимать, что делает команда и куда хочет добежать, для чего и зачем это нужно. У каждой команды есть своя миссия — это одно предложение, где доносится, зачем существует команда. Миссия формулируется не с точки зрения интересов бизнеса, а с точки зрения интересов пользователя. Наличие публичного дашборда с метриками — обязательное условие работы. Каждый проект или эксперимент содержит в описании целевые метрики (которые хотим изменить) и health metrics (на которые можем повлиять и хотим контролировать это влияние). Подробнее - https://news.1rj.ru/str/vladimir_merkushev/1323
Про Уточняющий NPS
Медленная метрика, которая позволяет оценить отношение клиентов к продукту и желание его рекомендовать. А также получить понимание как изменения в продукте влияют на восприятие клиентами. Надеюсь, вы уже используете NPS и отслеживаете его изменение месяц к месяцу. Обычно NPS считают на базе опроса новых пользователей, которые провели в продукте определенное время и/или совершили целевые действия. Подробнее - https://news.1rj.ru/str/vladimir_merkushev/1292
Хотите больше постов - подписывайтесь на https://news.1rj.ru/str/vladimir_merkushev
Telegram
Продукторий Владимира Меркушева
Взгляд на мир глазами менеджера продукта. Работаю в управлении продуктами уже более 10 лет (Kolesa Group, Avito, Yandex, OLX). Пишу о собственном опыте, делюсь полезными ссылками, делаю фото-репортажи из офисов IT компаний. Живу в Лиссабоне. @mervlad
Когда стоит развивать In-house, а когда аутсорсинг разработки продуктов?
In-house разработка в компаниях существует на двух уровнях:
1. Продуктовая разработка — технологию рассматривают как готовый продукт, являющийся драйвером для бизнеса, и в процессе участвуют продуктовые команды;
2. Технологический in-house — компания изобретает технологическую платформу «под капотом», которая решает конкретную проблему, при этом продуктовая бизнес-логика на этом уровне не применяется.
Например: движок базы данных — это технология, а когда его дорабатывают, дополняют интерфейсом, бизнес-логикой и интегрируют с другими сервисами — это уже продукт
Можно выделить как минимум четыре недостатка технологических решений своими силами:
- зачастую это дорого, долго и трудозатратно;
- потребуется создать подразделение, которое будет заниматься проектом и обеспечивать его поддержку после запуска;
- апдейты и новые функции нужно интегрировать самостоятельно;
- есть риск «изобрести велосипед» — создать сложный и дорогой аналог платформы, которая давно существует на рынке и уже отлично справляется со своими задачами.
Но плюсов все же больше:
- вы создаете гибкую технологию и можете кастомизировать ее с учетом меняющихся запросов компании
- прокачивается экспертиза, а организация получает в распоряжение собственную проприетарную технологию — в последующем можно продать ее или выложить в открытый доступ
- сервис легко интегрируется с другими продуктами компании — подгонять одно под другое не приходится
- решение можно при необходимости масштабировать, дополнить или усовершенствовать
- есть возможность создать инструмент, аналогов которого просто нет на рынке. А собственная технология — это зачастую конкурентное преимущество на рынке. Однако in-house разработка не всегда целесообразна: многое зависит от задач и потребностей компании, поэтому нужна гибкость.
Аутсорсер точно помогает в следующих задачах:
- Аналитика (ТЗ, прототипы, UX)
- Разработка архитектуры
- Создание кода, код-ревью
- Обеспечение качества (тестирование, SDET, работа с инцидентами)
- Отработка новых идей, создание MVP
Если нужно быстро и недорого проверить гипотезу или сделать небольшой проект, можно работать с студией. Этот вариант также подойдет, если вы готовы тратить много времени на общение с подрядчиками и управление проектом. Если у вас масштабный и сложный проект со множеством этапов или проект, от которого напрямую зависит успех вашего бизнеса, проще и выгоднее обратиться в студию разработки.
Инхаус-команда отвечает за:
- Создание своей инфраструктуры
- Автоматизацию операций
- Метрики и отчетность по разработке
- Развитие методики разработки
- Сохранение экспертизы
- Постановка задач и контроль за их исполнением
Собрать отдел квалифицированных разработчиков внутри компании — вариант для большого бизнеса, который готов вкладывать в это миллионы рублей каждый месяц. А еще инхаус-разработкой занимаются те, кто делает приложение, критично важное для бизнеса.
Хотите еще экспертное мнение? Приходите 11 апреля на открытый вебинар «Заказная разработка vs In-house разработка» в OTUS, где преподаватель Иннокентий Бодров, ведущий аналитик в Stenn International, расскажет: в чем разница подходов: заказная разработка vs In-house разработка, какие подходы для чего популярны, как это соотносится с проектным и продуктовым подходами.
Еще больше полезной информации на онлайн-курсе «Системный аналитик. Basic» от OTUS. Программа рассчитана на людей без опыта в IT. На курсе предусмотрен пробный период — две недели с момента начала занятий можно обучаться бесплатно.
Записаться на открытый урок: https://otus.pw/GgtC/
In-house разработка в компаниях существует на двух уровнях:
1. Продуктовая разработка — технологию рассматривают как готовый продукт, являющийся драйвером для бизнеса, и в процессе участвуют продуктовые команды;
2. Технологический in-house — компания изобретает технологическую платформу «под капотом», которая решает конкретную проблему, при этом продуктовая бизнес-логика на этом уровне не применяется.
Например: движок базы данных — это технология, а когда его дорабатывают, дополняют интерфейсом, бизнес-логикой и интегрируют с другими сервисами — это уже продукт
Можно выделить как минимум четыре недостатка технологических решений своими силами:
- зачастую это дорого, долго и трудозатратно;
- потребуется создать подразделение, которое будет заниматься проектом и обеспечивать его поддержку после запуска;
- апдейты и новые функции нужно интегрировать самостоятельно;
- есть риск «изобрести велосипед» — создать сложный и дорогой аналог платформы, которая давно существует на рынке и уже отлично справляется со своими задачами.
Но плюсов все же больше:
- вы создаете гибкую технологию и можете кастомизировать ее с учетом меняющихся запросов компании
- прокачивается экспертиза, а организация получает в распоряжение собственную проприетарную технологию — в последующем можно продать ее или выложить в открытый доступ
- сервис легко интегрируется с другими продуктами компании — подгонять одно под другое не приходится
- решение можно при необходимости масштабировать, дополнить или усовершенствовать
- есть возможность создать инструмент, аналогов которого просто нет на рынке. А собственная технология — это зачастую конкурентное преимущество на рынке. Однако in-house разработка не всегда целесообразна: многое зависит от задач и потребностей компании, поэтому нужна гибкость.
Аутсорсер точно помогает в следующих задачах:
- Аналитика (ТЗ, прототипы, UX)
- Разработка архитектуры
- Создание кода, код-ревью
- Обеспечение качества (тестирование, SDET, работа с инцидентами)
- Отработка новых идей, создание MVP
Если нужно быстро и недорого проверить гипотезу или сделать небольшой проект, можно работать с студией. Этот вариант также подойдет, если вы готовы тратить много времени на общение с подрядчиками и управление проектом. Если у вас масштабный и сложный проект со множеством этапов или проект, от которого напрямую зависит успех вашего бизнеса, проще и выгоднее обратиться в студию разработки.
Инхаус-команда отвечает за:
- Создание своей инфраструктуры
- Автоматизацию операций
- Метрики и отчетность по разработке
- Развитие методики разработки
- Сохранение экспертизы
- Постановка задач и контроль за их исполнением
Собрать отдел квалифицированных разработчиков внутри компании — вариант для большого бизнеса, который готов вкладывать в это миллионы рублей каждый месяц. А еще инхаус-разработкой занимаются те, кто делает приложение, критично важное для бизнеса.
Хотите еще экспертное мнение? Приходите 11 апреля на открытый вебинар «Заказная разработка vs In-house разработка» в OTUS, где преподаватель Иннокентий Бодров, ведущий аналитик в Stenn International, расскажет: в чем разница подходов: заказная разработка vs In-house разработка, какие подходы для чего популярны, как это соотносится с проектным и продуктовым подходами.
Еще больше полезной информации на онлайн-курсе «Системный аналитик. Basic» от OTUS. Программа рассчитана на людей без опыта в IT. На курсе предусмотрен пробный период — две недели с момента начала занятий можно обучаться бесплатно.
Записаться на открытый урок: https://otus.pw/GgtC/
otus.ru
Курс Системный аналитик, базовый уровень
Курс рассчитан на людей без опыта в IT, которым интересно освоить профессию "Системный аналитик". Мы даем полное погружение в процесс разработки ПО с упором на системный и бизнес анализ
Типовые показатели, которые лежат в основе формул для анализа unit-экономики
Сохраняйте в закладки:
- Количество пользователей, которые недавно узнали о вашем бизнесе (предложении)
- Количество пользователей, которые обратились к вам после того, как узнали о предложении с любого из рекламных каналов
- Затраты на маркетинг и рекламу
- Себестоимость каждой продажи
- Стоимость одного привлеченного пользователя на сайт или посадочную страницу — точку входа в воронку продаж: затраты на маркетинг разделить на количество привлеченных пользователей.
- Стоимость привлечения покупателя - затраты на маркетинг разделить на количество пришедших покупателей.
- Стоимость регистрации - затраты на маркетинг разделить на количество регистрацией с рекламного канала — или нескольких, но учитывать это в дальнейших расчетах.
- Средний чек на одну покупку - Общую сумму совершенных покупок за определенный промежуток времени разделить на количество покупок за этот же промежуток времени
- Жизненная ценность клиента - Средний чек на покупку умножить на количество покупок за определенный промежуток времени, умножить на прибыль компании от покупки и затем на среднее время удержания клиента в числе покупателей.
- Среднее количество покупок - количество покупок одного и того же покупателя за определенный период времени.
- Стоимость проданного товара или услуги - запасы на начало исследуемого периода плюс издержки на производство минус запасы на конец исследуемого периода.
- Операционные расходы - операционные издержки за определенный период времени разделить на выручку от продаж за этот же период, затем умножить на 100%.
- Затраты на удержание клиента - совокупную стоимость удержания клиента разделить на число фактических покупателей.
- Издержки на обслуживание клиента - сколько тратится за определенный период на обслуживание 1 клиента компании.
- Месячная выручка от лида - сколько прибыли в денежном эквиваленте приносит 1 клиент за определенный промежуток времени.
- Сумма покупки клиента в магазине
А также важные настройки:
1. Дробите оценку по каналам. Если используете несколько рекламных каналов, оценивайте каждый в отдельности, а не как продвижение в целом. Так перед вами предстанет более четкая картина.
2. Дробите по продуктам. Предлагаете большой спектр продуктов? Оценивайте unit-экономику по каждому из них или сегментируйте по небольшим группам и анализируйте их.
3. Стремитесь к постоянному масштабированию рабочих моделей.
4. Смотрите на перспективу. Если по результатам анализа unit-экономики в первый месяц на окупаемость бизнес не выходит, не опускайте руки — рассчитывайте, когда это произойдет, и стремитесь всеми силами приблизить этот срок. Учитывайте, что некоторые виды бизнеса нацелены на регулярные покупки. Потому окупаемость одной из них может быть отрицательная или указывать на нулевую прибыль для компании. Но при анализе уже последующих покупок положительная динамика будет налицо.
Приглашаю поговорить на тему “Как продакт-менеджеру найти метрику роста и свести Unit-экономику?” на открытом вебинаре в OTUS от онлайн-курса «Product Manager IT-проектов» 13 апреля в 19:00 с моим участием.
За 1,5 часа на примерах реальных продуктов вы узнаете: почему успех продакт-менеджера — это рост главной метрики продукта, как определить метрику роста, как построить аналитику и продукт вокруг метрики роста, как провести расчет unit-экономики.
Для участия зарегистрируйтесь на вебинар https://otus.pw/QDR7/
Нужна консультация по продуктам - пишите автору канала @SKoloskov.
Сохраняйте в закладки:
- Количество пользователей, которые недавно узнали о вашем бизнесе (предложении)
- Количество пользователей, которые обратились к вам после того, как узнали о предложении с любого из рекламных каналов
- Затраты на маркетинг и рекламу
- Себестоимость каждой продажи
- Стоимость одного привлеченного пользователя на сайт или посадочную страницу — точку входа в воронку продаж: затраты на маркетинг разделить на количество привлеченных пользователей.
- Стоимость привлечения покупателя - затраты на маркетинг разделить на количество пришедших покупателей.
- Стоимость регистрации - затраты на маркетинг разделить на количество регистрацией с рекламного канала — или нескольких, но учитывать это в дальнейших расчетах.
- Средний чек на одну покупку - Общую сумму совершенных покупок за определенный промежуток времени разделить на количество покупок за этот же промежуток времени
- Жизненная ценность клиента - Средний чек на покупку умножить на количество покупок за определенный промежуток времени, умножить на прибыль компании от покупки и затем на среднее время удержания клиента в числе покупателей.
- Среднее количество покупок - количество покупок одного и того же покупателя за определенный период времени.
- Стоимость проданного товара или услуги - запасы на начало исследуемого периода плюс издержки на производство минус запасы на конец исследуемого периода.
- Операционные расходы - операционные издержки за определенный период времени разделить на выручку от продаж за этот же период, затем умножить на 100%.
- Затраты на удержание клиента - совокупную стоимость удержания клиента разделить на число фактических покупателей.
- Издержки на обслуживание клиента - сколько тратится за определенный период на обслуживание 1 клиента компании.
- Месячная выручка от лида - сколько прибыли в денежном эквиваленте приносит 1 клиент за определенный промежуток времени.
- Сумма покупки клиента в магазине
А также важные настройки:
1. Дробите оценку по каналам. Если используете несколько рекламных каналов, оценивайте каждый в отдельности, а не как продвижение в целом. Так перед вами предстанет более четкая картина.
2. Дробите по продуктам. Предлагаете большой спектр продуктов? Оценивайте unit-экономику по каждому из них или сегментируйте по небольшим группам и анализируйте их.
3. Стремитесь к постоянному масштабированию рабочих моделей.
4. Смотрите на перспективу. Если по результатам анализа unit-экономики в первый месяц на окупаемость бизнес не выходит, не опускайте руки — рассчитывайте, когда это произойдет, и стремитесь всеми силами приблизить этот срок. Учитывайте, что некоторые виды бизнеса нацелены на регулярные покупки. Потому окупаемость одной из них может быть отрицательная или указывать на нулевую прибыль для компании. Но при анализе уже последующих покупок положительная динамика будет налицо.
Приглашаю поговорить на тему “Как продакт-менеджеру найти метрику роста и свести Unit-экономику?” на открытом вебинаре в OTUS от онлайн-курса «Product Manager IT-проектов» 13 апреля в 19:00 с моим участием.
За 1,5 часа на примерах реальных продуктов вы узнаете: почему успех продакт-менеджера — это рост главной метрики продукта, как определить метрику роста, как построить аналитику и продукт вокруг метрики роста, как провести расчет unit-экономики.
Для участия зарегистрируйтесь на вебинар https://otus.pw/QDR7/
Нужна консультация по продуктам - пишите автору канала @SKoloskov.
Как архитектура помогает agile-продуктам достигать бизнес-целей
Быстрые и постоянные инновационные изменения и более информированные клиенты заставляют компании применять более гибкие бизнес-стратегии. Сроки выполнения теперь короче и требуют, чтобы компании стали более гибкими и научились меньше полагаться на разрозненную организационную структуру для реализации своей стратегии. Капитал необходимо перераспределить на инициативы и проекты, ориентированные на клиентов.
Финансовая система и определение приоритетов
Использование ориентированных на клиентов потоков создания ценности и измеряемых бизнес-возможностей - объективный и удобный способ определения уровней приоритета проектов. Потоки создания ценности и возможностей гораздо более стабильны во времени, чем организационные диаграммы, процессы, продукты или приложения. При правильном использовании, начиная с взаимодействия с клиентом, они могут гарантировать, что часто пересматриваемое определение человеческих и финансовых ресурсов, выделяемых на agile-проекты, синхронизируется с развивающимися стратегиями и целями организации, ориентированной на клиента.
Планирования проекта
Используя элементы своей модели enterprise architecture, корпоративные архитекторы могут ускорить определение требований, эпиков и пользовательских историй, необходимых для поставки и выполнения программ, проектов и спринтов. Кроме того, в крупных agile-программах часто будут дублирующиеся проекты и подпроекты. У корпоративных архитекторов есть необходимый опыт для их обнаружения.
Проверки выполнения проекта
Во время реализации agile-проекта корпоративные архитекторы должны участвовать в регулярных проверках со стороны ключевых членов группы гибкой поставки: продукт менеджеры должны сигнализировать, что следует делать дальше; системные архитекторы должны указать, как можно оптимально реализовать проект; инженерам по выпуску в SAFe необходимо указать лучший способ реализации проекта; а владельцы бизнеса должны стремиться к желаемому бизнес-результату и соответствующей цели, с которой должен быть согласован agile-проект.
Показатели успеха
Ваше недавно разработанное программное обеспечение может отлично работать в соответствии со спецификациями и быть доступным в 99,99% случаев; возможно, вы выполнили свою agile-программу и проекты вовремя и в рамках бюджета. Тем не менее, вы, возможно, не смогли достичь своих бизнес-целей, и соответствующие бизнес-возможности вашего проекта могут по-прежнему работать на слишком низком уровне. В таких случаях корпоративные архитекторы могут помочь выяснить, что пошло не так, и найти соответствующие решения, чтобы это происходило реже.
Еще больше инсайтов и кейсов по развитию архитектуры предприятия будет 11 апреля на вебинаре в OTUS «Прошлое, настоящее и будущее роли архитектора предприятия» в рамках онлайн-курса «Enterprise Architect». На открытом уроке будет возможность обсудить роль архитектора предприятия: кем были, кем стали, кем должны быть в обозримом будущем и почему. Поговорят о необходимых компетенциях агента изменений и базовых знаниях для позитивного влияния в организации.
Регистрация по ссылке - https://otus.pw/NYqR/
Быстрые и постоянные инновационные изменения и более информированные клиенты заставляют компании применять более гибкие бизнес-стратегии. Сроки выполнения теперь короче и требуют, чтобы компании стали более гибкими и научились меньше полагаться на разрозненную организационную структуру для реализации своей стратегии. Капитал необходимо перераспределить на инициативы и проекты, ориентированные на клиентов.
Финансовая система и определение приоритетов
Использование ориентированных на клиентов потоков создания ценности и измеряемых бизнес-возможностей - объективный и удобный способ определения уровней приоритета проектов. Потоки создания ценности и возможностей гораздо более стабильны во времени, чем организационные диаграммы, процессы, продукты или приложения. При правильном использовании, начиная с взаимодействия с клиентом, они могут гарантировать, что часто пересматриваемое определение человеческих и финансовых ресурсов, выделяемых на agile-проекты, синхронизируется с развивающимися стратегиями и целями организации, ориентированной на клиента.
Планирования проекта
Используя элементы своей модели enterprise architecture, корпоративные архитекторы могут ускорить определение требований, эпиков и пользовательских историй, необходимых для поставки и выполнения программ, проектов и спринтов. Кроме того, в крупных agile-программах часто будут дублирующиеся проекты и подпроекты. У корпоративных архитекторов есть необходимый опыт для их обнаружения.
Проверки выполнения проекта
Во время реализации agile-проекта корпоративные архитекторы должны участвовать в регулярных проверках со стороны ключевых членов группы гибкой поставки: продукт менеджеры должны сигнализировать, что следует делать дальше; системные архитекторы должны указать, как можно оптимально реализовать проект; инженерам по выпуску в SAFe необходимо указать лучший способ реализации проекта; а владельцы бизнеса должны стремиться к желаемому бизнес-результату и соответствующей цели, с которой должен быть согласован agile-проект.
Показатели успеха
Ваше недавно разработанное программное обеспечение может отлично работать в соответствии со спецификациями и быть доступным в 99,99% случаев; возможно, вы выполнили свою agile-программу и проекты вовремя и в рамках бюджета. Тем не менее, вы, возможно, не смогли достичь своих бизнес-целей, и соответствующие бизнес-возможности вашего проекта могут по-прежнему работать на слишком низком уровне. В таких случаях корпоративные архитекторы могут помочь выяснить, что пошло не так, и найти соответствующие решения, чтобы это происходило реже.
Еще больше инсайтов и кейсов по развитию архитектуры предприятия будет 11 апреля на вебинаре в OTUS «Прошлое, настоящее и будущее роли архитектора предприятия» в рамках онлайн-курса «Enterprise Architect». На открытом уроке будет возможность обсудить роль архитектора предприятия: кем были, кем стали, кем должны быть в обозримом будущем и почему. Поговорят о необходимых компетенциях агента изменений и базовых знаниях для позитивного влияния в организации.
Регистрация по ссылке - https://otus.pw/NYqR/
Что растит конверсию из просмотра резюме в собеседование?
⁃ Обязательно пишите о KPI и измеримых результатах. Для продакт-менеджера очень важно показать эффективность своей работы, так как именно на достижении поставленной цели и построена вся его работа. Результаты могут быть следующие: количество покупок и новых пользователей, маржинальность, ROI, CRR, сроки запуска, объемы продаж и т.д. Всех интересуют только цифры!
⁃ Указывайте только актуальный опыт. Делайте упор на том опыте, который будет полезен вам в роли product manager. Обязательно раскройте, насколько разбираетесь в экономике продукта
⁃ Подстройтесь под сферу компании. Работодатели обычно нанимают тех продакт-менеджеров, которые уже имеют опыт работы в той сфере, к которой относится их компания. Так происходит, потому что product manager должен очень хорошо разбираться в рынке и продукте, знать специфику сферы.
⁃ Название резюме должно быть "Product manager”. И все.
⁃ Место локации должно совпадать. 100% релокации и возможность приехать на собеседование в должна быть отражена.
⁃ Не больше трех мест работы в резюме. Важно подобрать кейсы под работодателя и при этом показать насмотренность
⁃ В списке регалий (курсы и награды) - максимум три пункта
⁃ Хорошее сопроводительное письмо не повышает конверсию в приглашение. Но мотивирует дать развернутую обратную связь на резюме.
⁃ В сопроводительном писать почему на 100% уверен, что подходишь - в идеале заранее посмотреть на продукт и предложить свой план работы над ним. Писать можно о мотивации работать именно в этой компании или именно в этой сфере, представить самые яркие результаты вашей работы без воды, проанализировать деятельность компании и рынок и набросать несколько предложений по продукту
⁃ Ключевые слова в резюме, по которым можно найти: стратегия кандидата - правильно определить и расставить эти ключевые слова.
⁃ Активный поиск не повышает конверсию в оффер
⁃ Резюме продакта должно быть не скромным: можно описать мечту, можно фокусировать на успехах в метриках.
6 из 10 IT-специалистов выбывают из претендентов на вакансию ещё на этапе отклика. Так плохо они упаковывают свой опыт. Ещё больше тонкостей в CV нужно учесть тем, кто выходит на зарубежный рынок.
21 апреля в 20:00 OTUS проведёт вебинар вместе с Язилей Насибуллиной, основательницей кадрового агентства Tech-Recruiter и HR консультантом в DONE!Berlin. Вы разберете нюансы резюме для российских и зарубежных компаний. Узнаете о площадках с вакансиями для IT-специалистов. Сможете задать вопросы и получить рекомендации по своему случаю. Ссылка для регистрации - https://otus.pw/yqjd/
А учебный пример своего резюме выложу на канале Вакансии для продакт-менеджеров (https://news.1rj.ru/str/productjobgo)
⁃ Обязательно пишите о KPI и измеримых результатах. Для продакт-менеджера очень важно показать эффективность своей работы, так как именно на достижении поставленной цели и построена вся его работа. Результаты могут быть следующие: количество покупок и новых пользователей, маржинальность, ROI, CRR, сроки запуска, объемы продаж и т.д. Всех интересуют только цифры!
⁃ Указывайте только актуальный опыт. Делайте упор на том опыте, который будет полезен вам в роли product manager. Обязательно раскройте, насколько разбираетесь в экономике продукта
⁃ Подстройтесь под сферу компании. Работодатели обычно нанимают тех продакт-менеджеров, которые уже имеют опыт работы в той сфере, к которой относится их компания. Так происходит, потому что product manager должен очень хорошо разбираться в рынке и продукте, знать специфику сферы.
⁃ Название резюме должно быть "Product manager”. И все.
⁃ Место локации должно совпадать. 100% релокации и возможность приехать на собеседование в должна быть отражена.
⁃ Не больше трех мест работы в резюме. Важно подобрать кейсы под работодателя и при этом показать насмотренность
⁃ В списке регалий (курсы и награды) - максимум три пункта
⁃ Хорошее сопроводительное письмо не повышает конверсию в приглашение. Но мотивирует дать развернутую обратную связь на резюме.
⁃ В сопроводительном писать почему на 100% уверен, что подходишь - в идеале заранее посмотреть на продукт и предложить свой план работы над ним. Писать можно о мотивации работать именно в этой компании или именно в этой сфере, представить самые яркие результаты вашей работы без воды, проанализировать деятельность компании и рынок и набросать несколько предложений по продукту
⁃ Ключевые слова в резюме, по которым можно найти: стратегия кандидата - правильно определить и расставить эти ключевые слова.
⁃ Активный поиск не повышает конверсию в оффер
⁃ Резюме продакта должно быть не скромным: можно описать мечту, можно фокусировать на успехах в метриках.
6 из 10 IT-специалистов выбывают из претендентов на вакансию ещё на этапе отклика. Так плохо они упаковывают свой опыт. Ещё больше тонкостей в CV нужно учесть тем, кто выходит на зарубежный рынок.
21 апреля в 20:00 OTUS проведёт вебинар вместе с Язилей Насибуллиной, основательницей кадрового агентства Tech-Recruiter и HR консультантом в DONE!Berlin. Вы разберете нюансы резюме для российских и зарубежных компаний. Узнаете о площадках с вакансиями для IT-специалистов. Сможете задать вопросы и получить рекомендации по своему случаю. Ссылка для регистрации - https://otus.pw/yqjd/
А учебный пример своего резюме выложу на канале Вакансии для продакт-менеджеров (https://news.1rj.ru/str/productjobgo)