Вакансия.
Мы ищем человека, который займется развитием открытых тренингов в OnAgile Academy.
Это и про улучшение клиентского опыта, и про развитие направления в целом.
Хочется проводить больше тренингов, обучать больше участников и все идеально организовывать 🙂
Важное условие - предпринимательский майндсет. Мы бы не хотели вам говорить, что и как нужно делать, но, конечно же, поможем видением, опытом и советом.
Понимание организации процесса обучения и наличие соответствующего опыта - обязательно.
Москва, м. Автозаводская, наш светлый и уютный офис с прекрасной кофемашиной.
Присылайте резюме и пару строк, почему вам эта вакансия интересна, будем рады познакомиться!
info@onagile.ru
Мы ищем человека, который займется развитием открытых тренингов в OnAgile Academy.
Это и про улучшение клиентского опыта, и про развитие направления в целом.
Хочется проводить больше тренингов, обучать больше участников и все идеально организовывать 🙂
Важное условие - предпринимательский майндсет. Мы бы не хотели вам говорить, что и как нужно делать, но, конечно же, поможем видением, опытом и советом.
Понимание организации процесса обучения и наличие соответствующего опыта - обязательно.
Москва, м. Автозаводская, наш светлый и уютный офис с прекрасной кофемашиной.
Присылайте резюме и пару строк, почему вам эта вакансия интересна, будем рады познакомиться!
info@onagile.ru
#разборкейса
Срочные задачи — бросать все и делать?
Ситуация, с которой сталкиваются почти все команды, особенно на этапе становления процесса по Канбан-методу: завели доску и все визуализировали, определили условия передвижения задач из столбца в столбец, определили WIP-лимиты. Согласовали с заказчиком приоритеты, чтобы понимать, в какой последовательности брать задачи. Все отлично, работаем.
И тут, уже после сессии расстановки приоритетов (replenishment meeting), от заказчика приходит новая срочная задача. А потом еще одна. Что обычно делает команда? Откладывает все и берется за новые задачи. И скорее всего, совершает ошибку.
Уже скоро выяснится, что запланированные задачи повисли незавершенными, и если новые команда тоже не успела доделать — сложится впечатление, что не сделано вообще ничего, хотя усилия затрачены. Команда расстроена, заказчик недоволен, и аргумент «Мы же переключились на новые срочные задачи», скорее всего, не сработает. Более того, все начинание по внедрению Agile может показаться неэффективным, хотя Канбан-метод просто сделал существующие проблемы видимыми.
Что делать? Вспомнить про принцип эволюционного развития и «вытягивания» новых задач по мере мере продвижения текущих. Прежде чем браться за любое внеплановое задание, стоит обсудить с заказчиком текущую ситуацию: что уже находится в работе, на какой стадии, действительно ли новая задача требует отставить все остальное в сторону или она сможет подождать до завтра/ послезавтра, когда будет завершена текущая?
В этот момент полезно еще раз проговорить правила взаимодействия заказчика с командой и порядок вытягивания задач из очереди — чтобы все понимали, почему делается так или иначе.
Срочные задачи — бросать все и делать?
Ситуация, с которой сталкиваются почти все команды, особенно на этапе становления процесса по Канбан-методу: завели доску и все визуализировали, определили условия передвижения задач из столбца в столбец, определили WIP-лимиты. Согласовали с заказчиком приоритеты, чтобы понимать, в какой последовательности брать задачи. Все отлично, работаем.
И тут, уже после сессии расстановки приоритетов (replenishment meeting), от заказчика приходит новая срочная задача. А потом еще одна. Что обычно делает команда? Откладывает все и берется за новые задачи. И скорее всего, совершает ошибку.
Уже скоро выяснится, что запланированные задачи повисли незавершенными, и если новые команда тоже не успела доделать — сложится впечатление, что не сделано вообще ничего, хотя усилия затрачены. Команда расстроена, заказчик недоволен, и аргумент «Мы же переключились на новые срочные задачи», скорее всего, не сработает. Более того, все начинание по внедрению Agile может показаться неэффективным, хотя Канбан-метод просто сделал существующие проблемы видимыми.
Что делать? Вспомнить про принцип эволюционного развития и «вытягивания» новых задач по мере мере продвижения текущих. Прежде чем браться за любое внеплановое задание, стоит обсудить с заказчиком текущую ситуацию: что уже находится в работе, на какой стадии, действительно ли новая задача требует отставить все остальное в сторону или она сможет подождать до завтра/ послезавтра, когда будет завершена текущая?
В этот момент полезно еще раз проговорить правила взаимодействия заказчика с командой и порядок вытягивания задач из очереди — чтобы все понимали, почему делается так или иначе.
В крупных компаниях нередки встречи и совещания, на которых одновременно присутствуют 20 человек, при этом в течение часа или двух обсуждаются вопросы, для принятия решений в которых достаточно всего четырех человек.
Ну, вы знаете, наверняка в таких участвовали 🙂
Подслушали недавно у клиента забавный термин, описывающий такие мероприятия, — togethering (тугезэринг, буквально: делание чего-то вместе)
А как у вас называются встречи, на которых переговорка битком, но при этом половина людей сидит в ноутбуках и телефонах?
Ну, вы знаете, наверняка в таких участвовали 🙂
Подслушали недавно у клиента забавный термин, описывающий такие мероприятия, — togethering (тугезэринг, буквально: делание чего-то вместе)
А как у вас называются встречи, на которых переговорка битком, но при этом половина людей сидит в ноутбуках и телефонах?
Возможно ли организовать эффективную работу распределенной команды, и на что при этом обратить внимание? Несколько полезных практик из нашего опыта➡
https://vc.ru/hr/77384-ofis-vs-udalennaya-rabota-v-agile-komande
https://vc.ru/hr/77384-ofis-vs-udalennaya-rabota-v-agile-komande
vc.ru
Офис vs удаленная работа в Agile-команде — Карьера на vc.ru
Плюсы и минусы удаленной работы. И 5 практик, которые помогут запустить распределенные Agile-команды, от консультантов OnAgile Consulting.
Обратная связь внутри команды
Для всесторонней оценки работы команды мнения только руководителя или Scrum-мастера может быть недостаточно. Много ценной информации также способна дать обратная связь от коллег по команде — они, в отличие от руководителя, наблюдают за работой друг друга каждый день. К тому же такие комментарии сопровождаются меньшим стрессом, чем когда работу оценивает человек, принимающий решение о размере премии.
Регулярная практика обратной связи с коллегами (peer feedback) помогает процессу постоянного улучшения. Вот несколько простых правил, которые помогут наладить фидбэк без лишнего стресса:
🔹 Базовые принципы обратной связи — обсуждение один на один, и только когда коллега готов ее услышать.
🔹Анонимная обратная связь — «часть нашей команды считает, что...» — работает хуже. Гораздо полезнее для всего рабочего процесса создать среду, в которой возможны открытые и честные отзывы.
🔹Контекст: обратная связь всегда относится к ситуации, а не к человеку. Описывая ситуацию со своей точки зрения, мы улучшаем взаимопонимание.
🔹Наблюдения вместо простого перечисления фактов. «Я заметил, что...»
🔹Чувства важны: описывая, как ситуация влияет на нас, мы даем понять, чем мотивирован фидбэк, и фокусируем разговор на важности изменений.
🔹Предложения: как можно улучшить ситуацию? как избежать повторения подобных сценариев? Даже если коллега не воспользуется ими буквально, это хорошая возможность еще раз сверить ориентиры.
🔹Диалог: обратная связь не должна превращаться в монолог, который неизбежно поставит одного члена команды выше другого. Важно узнать, как сам коллега видит ситуацию, с чем согласен, а с чем — нет.
🔹Для формулирования обратной связи можно воспользоваться акронимом OSCAR (observed, situation, consequence, alternative, resulting): «Я наблюдал.., особенно в этой ситуации…, возможные последствия… Я предлагаю следующую альтернативу… В результате...»
А в вашей команде принято делиться мнениями о работе друг друга? С какими сложностями при этом сталкивались?
Для всесторонней оценки работы команды мнения только руководителя или Scrum-мастера может быть недостаточно. Много ценной информации также способна дать обратная связь от коллег по команде — они, в отличие от руководителя, наблюдают за работой друг друга каждый день. К тому же такие комментарии сопровождаются меньшим стрессом, чем когда работу оценивает человек, принимающий решение о размере премии.
Регулярная практика обратной связи с коллегами (peer feedback) помогает процессу постоянного улучшения. Вот несколько простых правил, которые помогут наладить фидбэк без лишнего стресса:
🔹 Базовые принципы обратной связи — обсуждение один на один, и только когда коллега готов ее услышать.
🔹Анонимная обратная связь — «часть нашей команды считает, что...» — работает хуже. Гораздо полезнее для всего рабочего процесса создать среду, в которой возможны открытые и честные отзывы.
🔹Контекст: обратная связь всегда относится к ситуации, а не к человеку. Описывая ситуацию со своей точки зрения, мы улучшаем взаимопонимание.
🔹Наблюдения вместо простого перечисления фактов. «Я заметил, что...»
🔹Чувства важны: описывая, как ситуация влияет на нас, мы даем понять, чем мотивирован фидбэк, и фокусируем разговор на важности изменений.
🔹Предложения: как можно улучшить ситуацию? как избежать повторения подобных сценариев? Даже если коллега не воспользуется ими буквально, это хорошая возможность еще раз сверить ориентиры.
🔹Диалог: обратная связь не должна превращаться в монолог, который неизбежно поставит одного члена команды выше другого. Важно узнать, как сам коллега видит ситуацию, с чем согласен, а с чем — нет.
🔹Для формулирования обратной связи можно воспользоваться акронимом OSCAR (observed, situation, consequence, alternative, resulting): «Я наблюдал.., особенно в этой ситуации…, возможные последствия… Я предлагаю следующую альтернативу… В результате...»
А в вашей команде принято делиться мнениями о работе друг друга? С какими сложностями при этом сталкивались?
Product owner и скрам-мастер: почему важно разделять эти роли
Когда компания начинает внедрять Scrum, две новые роли — владелец продукта и скрам-мастер — часто решают назначить одному человеку. Обычно это менеджер проекта или тимлид. Но это так не работает.
Скрам-мастер — это не только тот, благодаря кому встречи команды наконец-то начинают укладываться в отведенное для них время. Его задача — помогать команде придерживаться правил фреймворка и, главное, самоорганизовываться: понимать, как прийти к заданной цели, вовремя обнаруживать проблемы и находить их решения.
Product owner в это время должен развивать продукт, чтобы тот удовлетворял потребности потребителей и приносил прибыль компании. Он отвечает за видение продукта, за понимание потребностей клиентов, обеспечивает коммуникации между стейкхолдерами и командой и формирует бэклог, над которым будет работать команда.
По сути, product owner говорит команде, что нужно делать, но не навязывает свое видение, как этого добиться. А скрам-мастер помогает команде научиться работать максимально эффективно, постоянно улучшая процесс своей работы. И если обе этих роли соединить в одном человеке, мы вернемся к модели работы классического менеджера, и наши Agile и Scrum превратятся в просто наклеивание стикеров и постоянные встречи.
Когда компания начинает внедрять Scrum, две новые роли — владелец продукта и скрам-мастер — часто решают назначить одному человеку. Обычно это менеджер проекта или тимлид. Но это так не работает.
Скрам-мастер — это не только тот, благодаря кому встречи команды наконец-то начинают укладываться в отведенное для них время. Его задача — помогать команде придерживаться правил фреймворка и, главное, самоорганизовываться: понимать, как прийти к заданной цели, вовремя обнаруживать проблемы и находить их решения.
Product owner в это время должен развивать продукт, чтобы тот удовлетворял потребности потребителей и приносил прибыль компании. Он отвечает за видение продукта, за понимание потребностей клиентов, обеспечивает коммуникации между стейкхолдерами и командой и формирует бэклог, над которым будет работать команда.
По сути, product owner говорит команде, что нужно делать, но не навязывает свое видение, как этого добиться. А скрам-мастер помогает команде научиться работать максимально эффективно, постоянно улучшая процесс своей работы. И если обе этих роли соединить в одном человеке, мы вернемся к модели работы классического менеджера, и наши Agile и Scrum превратятся в просто наклеивание стикеров и постоянные встречи.
Анализ продуктов конкурентов
Когда product owner задумывается о развитии продукта и повышении его ценности для клиентов, сравнение обычно идет с тем, что предлагают конкуренты. И вот почему этого недостаточно:
Клиент не делает буквальный выбор между продуктами А и Б — он хочет решить свою задачу. И для этого у него может оказаться гораздо больше возможностей, чем кажется при анализе текущей ситуации на рынке.
Простой пример. Допустим, наша компания производит сушилки для обуви: мы много работаем над дизайном, бьемся за снижение энергопотребления и делаем провод, который не перегрызет собака. Мы смотрим на сушилки конкурентов и стараемся сделать лучше.
А теперь представьте, что вы попали под дождь. Не впервые за это лето, и в этот раз пообещали себе точно не забыть купить сушилку. Но тут вам на глаза попадается газета, из тех что вечно оказываются в почтовом ящике, — и это тоже способ решить вашу проблему. И вот уже бесплатная газета становится конкурентом сушилок производителя А, и Б, и С. А еще можно поставить обувь к батарее — не самый бережный метод, но и это тоже конкурентный способ решить проблему клиента.
Поэтому мы рекомендуем при разработке стратегии развития продукта, помимо анализа текущего поведения пользователей и сравнения с предложениями конкурентов, учитывать любые альтернативы, которые позволят клиенту решить свои задачи.
❓ А какие неочевидные альтернативы есть у вашего продукта?
Когда product owner задумывается о развитии продукта и повышении его ценности для клиентов, сравнение обычно идет с тем, что предлагают конкуренты. И вот почему этого недостаточно:
Клиент не делает буквальный выбор между продуктами А и Б — он хочет решить свою задачу. И для этого у него может оказаться гораздо больше возможностей, чем кажется при анализе текущей ситуации на рынке.
Простой пример. Допустим, наша компания производит сушилки для обуви: мы много работаем над дизайном, бьемся за снижение энергопотребления и делаем провод, который не перегрызет собака. Мы смотрим на сушилки конкурентов и стараемся сделать лучше.
А теперь представьте, что вы попали под дождь. Не впервые за это лето, и в этот раз пообещали себе точно не забыть купить сушилку. Но тут вам на глаза попадается газета, из тех что вечно оказываются в почтовом ящике, — и это тоже способ решить вашу проблему. И вот уже бесплатная газета становится конкурентом сушилок производителя А, и Б, и С. А еще можно поставить обувь к батарее — не самый бережный метод, но и это тоже конкурентный способ решить проблему клиента.
Поэтому мы рекомендуем при разработке стратегии развития продукта, помимо анализа текущего поведения пользователей и сравнения с предложениями конкурентов, учитывать любые альтернативы, которые позволят клиенту решить свои задачи.
❓ А какие неочевидные альтернативы есть у вашего продукта?
Управление проектами в Agile - наш новый сертификационный курс для руководителей проектных офисов и менеджеров проектов.
🔹Как совместить Agile с классическим управлением проектами?
🔹Как развивать продукт и планировать проект в гибридной среде
🔹Как взаимодействовать с Agile-командами в классическом проекте и как работать с подрядчиками в Agile-среде
🔹Как управлять стоимостью проектов и выстраивать проектную отчетность в Agile.
Тренинг подготовлен на базе Delivery Management Track и PMI Agile Practice guide и дает знания, необходимые для сдачи экзамена PMI Agile Certified Practitioner (PMI-ACP).
Приходите к нам за новыми знаниями и сертификатом от ICAgile (ICP-APM).
Москва, 24-25 сентября 2019.
Забронировать участие ➡️ https://onagile.ru/trainings/agile-project-management
🔹Как совместить Agile с классическим управлением проектами?
🔹Как развивать продукт и планировать проект в гибридной среде
🔹Как взаимодействовать с Agile-командами в классическом проекте и как работать с подрядчиками в Agile-среде
🔹Как управлять стоимостью проектов и выстраивать проектную отчетность в Agile.
Тренинг подготовлен на базе Delivery Management Track и PMI Agile Practice guide и дает знания, необходимые для сдачи экзамена PMI Agile Certified Practitioner (PMI-ACP).
Приходите к нам за новыми знаниями и сертификатом от ICAgile (ICP-APM).
Москва, 24-25 сентября 2019.
Забронировать участие ➡️ https://onagile.ru/trainings/agile-project-management
Сколько новых идей для своего продукта вы получаете каждую неделю? Уверены, что немало.
Запросы бизнеса всегда превышают возможности команд по их реализации. Как следствие — бэклог постоянно растет, а команда не знает, за что хвататься.
Практика, которая помогает контролировать ситуацию, называется backlog refinement. Что это такое и как ей пользоваться ➡️ https://onagile.ru/trends/lean-startup/backlog-refinement
Запросы бизнеса всегда превышают возможности команд по их реализации. Как следствие — бэклог постоянно растет, а команда не знает, за что хвататься.
Практика, которая помогает контролировать ситуацию, называется backlog refinement. Что это такое и как ей пользоваться ➡️ https://onagile.ru/trends/lean-startup/backlog-refinement
О роли менеджера в Agile
С приходом Agile в компанию менеджеры задаются вопросом, как изменится их роль в новых условиях. В самом Agile роль менеджера детально не рассматривается, поэтому стоит обратиться к более широкому понятию Business Agility, или Гибкость бизнеса. Оно охватывает все сферы управления организацией, в том числе дает понимание процесса эволюции менеджера в лидера.
В новой реальности менеджеру предстоит перейти от директивного управления к созданию среды для эффективной работы сотрудников. В которой они могут сами принимать решения, берут на себя ответственность и ставят цели. Хотим поделиться с вами переводом постера «Обеспечение гибкости бизнеса», который содержит соответствующие принципы лидерства.
Как создать такую среду — тема для отдельного большого разговора, и мы к нему непременно вернемся. А пока: Don’t manage people, manage system.
Скачать постер➡️ onagile.ru/tools
С приходом Agile в компанию менеджеры задаются вопросом, как изменится их роль в новых условиях. В самом Agile роль менеджера детально не рассматривается, поэтому стоит обратиться к более широкому понятию Business Agility, или Гибкость бизнеса. Оно охватывает все сферы управления организацией, в том числе дает понимание процесса эволюции менеджера в лидера.
В новой реальности менеджеру предстоит перейти от директивного управления к созданию среды для эффективной работы сотрудников. В которой они могут сами принимать решения, берут на себя ответственность и ставят цели. Хотим поделиться с вами переводом постера «Обеспечение гибкости бизнеса», который содержит соответствующие принципы лидерства.
Как создать такую среду — тема для отдельного большого разговора, и мы к нему непременно вернемся. А пока: Don’t manage people, manage system.
Скачать постер➡️ onagile.ru/tools
Практика Scrum: как создать бэклог продукта
Итак, у нас есть классная идея для нового продукта, мы знаем наших будущих пользователей и их потребности, которые закроет наш продукт. Можно приступать к работе😉
Но прежде чем Scrum-команда начнет работу в первом спринте, предстоит создать бэклог продукта. Записали для вас пошаговый алгоритм:
https://onagile.ru/trends/lean-startup/how-to-create-product-backlog
А с какими сложностями вы сталкивались при создании бэклога?
Итак, у нас есть классная идея для нового продукта, мы знаем наших будущих пользователей и их потребности, которые закроет наш продукт. Можно приступать к работе😉
Но прежде чем Scrum-команда начнет работу в первом спринте, предстоит создать бэклог продукта. Записали для вас пошаговый алгоритм:
https://onagile.ru/trends/lean-startup/how-to-create-product-backlog
А с какими сложностями вы сталкивались при создании бэклога?
Интересно, как дискуссия иногда обнаруживает ловушки мышления🙂 Например, идея для новой фичи или нового продукта кажется нам абсолютно логичной. Мы готовы всячески обосновать ее полезность для пользователей, и руки так и чешутся приступить к реализации. Но стоит начать проверять гипотезу и вдохновленному владельцу продукта открывается много интересного😏
У продуктологов для таких идей есть ёмкий термин — галлюцинации. Потому что все гипотезы, какими бы стройными они не казались, важно сверять с реальными пользователями. Это поможет избежать ошибок в видении продукта и расходов на то, что в итоге не принесет ценности.
#AgileProductManagement
У продуктологов для таких идей есть ёмкий термин — галлюцинации. Потому что все гипотезы, какими бы стройными они не казались, важно сверять с реальными пользователями. Это поможет избежать ошибок в видении продукта и расходов на то, что в итоге не принесет ценности.
#AgileProductManagement
Может ли скрам-мастер быть частью команды?
Недавно в одном из банков нам снова задали этот животрепещущий вопрос. Scrum-гайд не дает однозначного ответа, однако наш опыт показывает, что такое совмещение ролей сопровождается значительными трудностями.
Скрам-мастер (SM) фокусируется:
🔹на команде: фасилитирует встречи, помогает конструктивно решать конфликты и вырабатывать командные договоренности.
🔹на Владельце продукта: помогает ему в работе с бэклогом продукта и в общении со стейкхолдерами и командой.
🔹на организации в целом: выявляет системные проблемы и становится инициатором необходимых изменений, которые помогают скрам-командам работать эффективнее в компании.
Это большой объем работы, который сложно совмещать с другой деятельностью без ущерба качеству. О чем еще важно знать, выбирая SM, поговорим в следующий раз.
#scrum
Недавно в одном из банков нам снова задали этот животрепещущий вопрос. Scrum-гайд не дает однозначного ответа, однако наш опыт показывает, что такое совмещение ролей сопровождается значительными трудностями.
Скрам-мастер (SM) фокусируется:
🔹на команде: фасилитирует встречи, помогает конструктивно решать конфликты и вырабатывать командные договоренности.
🔹на Владельце продукта: помогает ему в работе с бэклогом продукта и в общении со стейкхолдерами и командой.
🔹на организации в целом: выявляет системные проблемы и становится инициатором необходимых изменений, которые помогают скрам-командам работать эффективнее в компании.
Это большой объем работы, который сложно совмещать с другой деятельностью без ущерба качеству. О чем еще важно знать, выбирая SM, поговорим в следующий раз.
#scrum
Выбор Скрам-мастера
Senior’ы и менеджеры обычно сами выбирают Скрам-мастера из числа сотрудников. А между тем важно учитывать желание выбранного кандидата. В этом вопросе лучше вообще уйти от директивного стиля принятия решений к более Agile стилю: прислушаться к людям, дать возможность развиваться в том, что им интересно.
Возможно, желающие стать Скрам-мастером найдутся за пределами команды. Можно подключить HR и устроить «ярмарку вакансий» внутри компании. Или воспользоваться схемой с голосованием стикерами ⬆️
По нашему опыту, SM, у которого горят глаза, будет активно развиваться в новой роли и станет проводником Scrum в компании. С большей вероятностью такие ребята будут проактивными и покажут собственным примером целевую модель взаимодействия в команде: взятие ответственности за общий результат, взаимопомощь и тд.
#scrum
Senior’ы и менеджеры обычно сами выбирают Скрам-мастера из числа сотрудников. А между тем важно учитывать желание выбранного кандидата. В этом вопросе лучше вообще уйти от директивного стиля принятия решений к более Agile стилю: прислушаться к людям, дать возможность развиваться в том, что им интересно.
Возможно, желающие стать Скрам-мастером найдутся за пределами команды. Можно подключить HR и устроить «ярмарку вакансий» внутри компании. Или воспользоваться схемой с голосованием стикерами ⬆️
По нашему опыту, SM, у которого горят глаза, будет активно развиваться в новой роли и станет проводником Scrum в компании. С большей вероятностью такие ребята будут проактивными и покажут собственным примером целевую модель взаимодействия в команде: взятие ответственности за общий результат, взаимопомощь и тд.
#scrum
Как сделать по-настоящему классный продукт, который будет пользоваться успехом? Ответов на этот вопрос почти столько же, сколько книг по маркетингу🙂
На практике работают подходы, ориентированные на решение задач пользователей. Это тоже, кажется, знают все, но когда доходит до реализации, фокус смещается к анализу портрета пользователей. В то время как важны не демографические характеристики, а контекст, в котором наш продукт нужен пользователям.
Подробнее об этом рассказываем в блоге➡️ https://onagile.ru/trends/lean-startup/jobs-to-be-done
#productmanagement
На практике работают подходы, ориентированные на решение задач пользователей. Это тоже, кажется, знают все, но когда доходит до реализации, фокус смещается к анализу портрета пользователей. В то время как важны не демографические характеристики, а контекст, в котором наш продукт нужен пользователям.
Подробнее об этом рассказываем в блоге➡️ https://onagile.ru/trends/lean-startup/jobs-to-be-done
#productmanagement
Классный кейс к разговору о том, насколько важно фокусироваться на решении задачи клиента в контексте, и какую пользу компании приносит такой подход.
Представьте, что вам нужно прямо сейчас посадить за руль своей машины другого человека (а для этого он должен быть вписан в полис ОСАГО).
Путь с обычной страховой: взять документы, поехать в офис страховой компании в рабочие часы, подождать пока менеджер освободится, займется вами и внесет данные в систему, оплатить услуги и получить распечатанный полис. Примерно час-два потраченного времени.
А что, если такой сервис встроить в путь клиента (customer journey)?
Путь «АльфаСтрахования»: сели в авто, зашли в приложение, внесли данные второго водителя — через секунду на email пришел обновленный полис. 2-3 минуты, и можно спокойно ехать.
И не важно, кто пользователь, какой марки его машина и почему он хочет добавить в страховку еще кого-то. Есть контекст — сделать это быстро и без необходимости ехать в офис компании. Сервис эту задачу решает. В итоге компания получает лояльного клиента, деньги за оказанную услугу и положительные рекомендации (=новых клиентов).
#productmanagement
Представьте, что вам нужно прямо сейчас посадить за руль своей машины другого человека (а для этого он должен быть вписан в полис ОСАГО).
Путь с обычной страховой: взять документы, поехать в офис страховой компании в рабочие часы, подождать пока менеджер освободится, займется вами и внесет данные в систему, оплатить услуги и получить распечатанный полис. Примерно час-два потраченного времени.
А что, если такой сервис встроить в путь клиента (customer journey)?
Путь «АльфаСтрахования»: сели в авто, зашли в приложение, внесли данные второго водителя — через секунду на email пришел обновленный полис. 2-3 минуты, и можно спокойно ехать.
И не важно, кто пользователь, какой марки его машина и почему он хочет добавить в страховку еще кого-то. Есть контекст — сделать это быстро и без необходимости ехать в офис компании. Сервис эту задачу решает. В итоге компания получает лояльного клиента, деньги за оказанную услугу и положительные рекомендации (=новых клиентов).
#productmanagement
Расписание программ обучения на октябрь — декабрь, созданных в партнерстве с International Consortium for Agile.
Мы разработали полный курс обучения, состоящий из трех уровней погружения в Agile, Scrum и Kanban.
От понимания, как работает Agile и что нужно сделать для внедрения Scrum в команде, до детального изучения подходов к созданию востребованных продуктов.
👨🎓 Международный сертификат от консорциума ICAgile каждому участнику.
Посмотреть программу и зарегистрироваться можно здесь
➡️ www.onagile.ru/trainings
Мы разработали полный курс обучения, состоящий из трех уровней погружения в Agile, Scrum и Kanban.
От понимания, как работает Agile и что нужно сделать для внедрения Scrum в команде, до детального изучения подходов к созданию востребованных продуктов.
👨🎓 Международный сертификат от консорциума ICAgile каждому участнику.
Посмотреть программу и зарегистрироваться можно здесь
➡️ www.onagile.ru/trainings
Очень интересная статья с кучей примеров от Dodopizza про их путь к проведению полезных Sprint Review (обзоры спринтов)
https://habr.com/ru/company/dodopizzaio/blog/452202/
https://habr.com/ru/company/dodopizzaio/blog/452202/
Хабр
Sprint Review: Днище — Огнище
«Мы легли на дно, мы зажгли огни, во Вселенной только мы одни». Кажется, эту строчку из песни группы Сплин смело можно признать саундреком внедрения практики Spr...
Следует ли менять лимит на количество одновременно выполняемой работы (Work in Progress Limit)? #практика_Канбан
Введение лимита на количество рабочих элементов на разных этапах процесса — один из ключевых принципов Канбан метода. Он помогает команде сосредоточиться в первую очередь на более быстром завершении уже взятых в работу задач. Насколько постоянно значение WIP лимита, и стоит ли его менять?
Да, если мы говорим об изменениях с течением времени. Установление ограничения WIP — часть процесса постоянного улучшения, и значение лимита нужно пересматривать, если параметры Канбан-системы изменились: например, поменялась численность команды, устранено очередное узкое место в системе или изменилась структура запросов на входе в систему.
Нет, если речь о сиюминутном увеличении лимита ради добавления в систему нового элемента (задачи, проекта) с высоким приоритетом, который, как это часто бывает, появился неожиданно, и требуется взять его в работу «прямо сейчас, а лучше вчера».
В этом случае увеличение WIP лимита просто замаскирует проблему, тогда как гораздо полезнее разобраться 1) почему новый элемент появился сверх ограничения 2) в причинах возникновения узкого места — и попытаться решить эти проблемы.
Это одно из преимуществ применения лимита — он выявляет недостатки и ранее скрытые слабые места в системе (процессе).
Что делать, если появилась срочная задача с высоким приоритетом?
Необходимо заранее (на этапе проектирования Канбан-системы) выделить часть пропускной способности на высокоприоритетные задачи — так называемый ускоренный класс сервисов (expedite items).
На доске это выглядит как отдельная полоса со своим ограничением на количество элементов, как правило, в размере одного срочного элемента в один момент времени.
В противном случае, достаточно быстро все элементы системы станут «срочными» в глазах стейкхолдеров и перейдут в этот класс сервиса, что, в свою очередь, катастрофически снизит пропускную способность всей нашей системы.
Подробно разбираем Канбан метод и практики выстраивания Канбан-систем в различных сферах бизнеса на нашем тренинге Kanban Method Professional.
Ближайший пройдет в Москве 21-22 ноября, приходите: https://onagile.ru/trainings/kanban-method-professional
Введение лимита на количество рабочих элементов на разных этапах процесса — один из ключевых принципов Канбан метода. Он помогает команде сосредоточиться в первую очередь на более быстром завершении уже взятых в работу задач. Насколько постоянно значение WIP лимита, и стоит ли его менять?
Да, если мы говорим об изменениях с течением времени. Установление ограничения WIP — часть процесса постоянного улучшения, и значение лимита нужно пересматривать, если параметры Канбан-системы изменились: например, поменялась численность команды, устранено очередное узкое место в системе или изменилась структура запросов на входе в систему.
Нет, если речь о сиюминутном увеличении лимита ради добавления в систему нового элемента (задачи, проекта) с высоким приоритетом, который, как это часто бывает, появился неожиданно, и требуется взять его в работу «прямо сейчас, а лучше вчера».
В этом случае увеличение WIP лимита просто замаскирует проблему, тогда как гораздо полезнее разобраться 1) почему новый элемент появился сверх ограничения 2) в причинах возникновения узкого места — и попытаться решить эти проблемы.
Это одно из преимуществ применения лимита — он выявляет недостатки и ранее скрытые слабые места в системе (процессе).
Что делать, если появилась срочная задача с высоким приоритетом?
Необходимо заранее (на этапе проектирования Канбан-системы) выделить часть пропускной способности на высокоприоритетные задачи — так называемый ускоренный класс сервисов (expedite items).
На доске это выглядит как отдельная полоса со своим ограничением на количество элементов, как правило, в размере одного срочного элемента в один момент времени.
В противном случае, достаточно быстро все элементы системы станут «срочными» в глазах стейкхолдеров и перейдут в этот класс сервиса, что, в свою очередь, катастрофически снизит пропускную способность всей нашей системы.
Подробно разбираем Канбан метод и практики выстраивания Канбан-систем в различных сферах бизнеса на нашем тренинге Kanban Method Professional.
Ближайший пройдет в Москве 21-22 ноября, приходите: https://onagile.ru/trainings/kanban-method-professional
Как декомпозировать продукт и элементы бэклога
Сделать все и сразу — обычный запрос от клиентов и заказчиков. Но как бы мы ни старались, «все и сразу» сделать невозможно. Зато можно ускорить поставку результата, если выделить из общей идеи главное и сфокусироваться на реализации этой части. А остальное несколько отложить.
Понимание, что нужно сделать прямо сейчас, дает декомпозиция. Существуют два уровня: уровень самого продукта (MVP, MLP) и уровень элементов бэклога — требования/функции/задачи (MMF).
О ключевых паттернах декомпозиции читайте в новом посте ➡️ https://onagile.ru/trends/lean-startup/backlog-decomposition
Сделать все и сразу — обычный запрос от клиентов и заказчиков. Но как бы мы ни старались, «все и сразу» сделать невозможно. Зато можно ускорить поставку результата, если выделить из общей идеи главное и сфокусироваться на реализации этой части. А остальное несколько отложить.
Понимание, что нужно сделать прямо сейчас, дает декомпозиция. Существуют два уровня: уровень самого продукта (MVP, MLP) и уровень элементов бэклога — требования/функции/задачи (MMF).
О ключевых паттернах декомпозиции читайте в новом посте ➡️ https://onagile.ru/trends/lean-startup/backlog-decomposition