Стоит ли оценивать задачи всей командой?
Когда команда начинает внедрять Scrum, порой возникает возражение, касающееся совместной оценки работы на будущий спринт.
Нам говорят: смотрите, в команде много разных специалистов — iOS разработчик, специалист по Android, back-end, тестировщик. Каждый занимается своей задачей в рамках своих компетенций и не сможет верно оценить трудозатраты не по своей задаче.
Это действительно так: когда каждый работает в обычном формате — в рамках своих задач, — конечно, никто не в курсе про задачи остальных и не может нормально оценить работу коллег.
Scrum хорош тем, что ребята в команде работают максимально тесно друг с другом над общей целью (спринта) и каждый день синхронизируются: у кого как дела, какие есть сложности. Помогают друг другу в тестировании и код-ревью.
Через 2-4 недели работы в таком формате каждый человек уже более-менее легко и точно сможет оценить работу коллеги – потому что очень глубоко в курсе подробностей задачи.
Что дает совместная оценка задач?
- Точность оценки: мы учитываем опыт не одного-двух специалистов, а всей команды.
- Рост экспертности команды: менее опытные сотрудники получают опыт прогнозирования сложности и сроков выполнения задач, в том числе за пределами своей основной специализации.
- Рост вовлеченности команды: мы выстраиваем культуру совместной работы над общей целью и помогаем сотрудникам брать на себя отвественность за результат всей команды.
Когда команда начинает внедрять Scrum, порой возникает возражение, касающееся совместной оценки работы на будущий спринт.
Нам говорят: смотрите, в команде много разных специалистов — iOS разработчик, специалист по Android, back-end, тестировщик. Каждый занимается своей задачей в рамках своих компетенций и не сможет верно оценить трудозатраты не по своей задаче.
Это действительно так: когда каждый работает в обычном формате — в рамках своих задач, — конечно, никто не в курсе про задачи остальных и не может нормально оценить работу коллег.
Scrum хорош тем, что ребята в команде работают максимально тесно друг с другом над общей целью (спринта) и каждый день синхронизируются: у кого как дела, какие есть сложности. Помогают друг другу в тестировании и код-ревью.
Через 2-4 недели работы в таком формате каждый человек уже более-менее легко и точно сможет оценить работу коллеги – потому что очень глубоко в курсе подробностей задачи.
Что дает совместная оценка задач?
- Точность оценки: мы учитываем опыт не одного-двух специалистов, а всей команды.
- Рост экспертности команды: менее опытные сотрудники получают опыт прогнозирования сложности и сроков выполнения задач, в том числе за пределами своей основной специализации.
- Рост вовлеченности команды: мы выстраиваем культуру совместной работы над общей целью и помогаем сотрудникам брать на себя отвественность за результат всей команды.
Как найти нужных людей в команду?
Последнее время наши клиенты часто просят помочь им подобрать персонал. Нужно наполнять команды, а еще нанимать людей на специфичные роли: Скрам-мастеров, Владельцев продуктов, Менеджеров поставок.
Ключевой вопрос не «где найти сотрудников», а «как захантить "своих" людей».
Возникающие сложности можно условно поделить на 2 типа:
❎ Нет четкого понимания, кого ищем — или это понимание неточное.
❎ Недостаток специалистов нужного уровня, находящихся в поиске новой работы.
Написали в блог, как можно обойти эти сложности: https://onagile.ru/trends/talents/headhunting
А как у вас сейчас обстоят дела с пополнением команды?
Последнее время наши клиенты часто просят помочь им подобрать персонал. Нужно наполнять команды, а еще нанимать людей на специфичные роли: Скрам-мастеров, Владельцев продуктов, Менеджеров поставок.
Ключевой вопрос не «где найти сотрудников», а «как захантить "своих" людей».
Возникающие сложности можно условно поделить на 2 типа:
❎ Нет четкого понимания, кого ищем — или это понимание неточное.
❎ Недостаток специалистов нужного уровня, находящихся в поиске новой работы.
Написали в блог, как можно обойти эти сложности: https://onagile.ru/trends/talents/headhunting
А как у вас сейчас обстоят дела с пополнением команды?
Мотивирующий кейс о том, как успешно инициировать изменения в компании «снизу»
Сразу оговорюсь, что речь все же про мидл-менеджмент. Тем не менее, это отличный пример, как инициатива одного человека способна изменить 6 производств внутри огромной международной компании (бренд не называю по условиям NDA).
К нам обратился менеджер, курирующий ряд производственных направлений. Задача состояла в том, чтобы увеличить скорость реализации инициатив на производстве.
Поскольку на скорость влияет сразу множество факторов, решением виделось внедрение проектного подхода, построенного на agile-принципах:
- Инициативы перестают быть фоновой работой сотрудников: проекты считаются ключевыми активностями для улучшения производства.
- Под каждый проект собирается небольшая, но фиксированная команда. Из ежедневной загрузки каждого участника выделяется определенный % времени для работы над проектом в команде.
- Каждая проектная команда сфокусирована на конкретный результат в конце месяца, с еженедельными точками контроля по результатам очередного спринта.
К масштабной трансформации компания была не готова, но руководство дало добро на обучение 1 группы. Поэтому мы собрали самых заинтересованных руководителей — на тренинг пришли люди с десятка производств. Примерно вдвое больше, чем помещается в переговорку;)
Мы провели 8-часовой тренинг: разобрали механику Scrum, прошлись по всем этапам процесса и наметили, в каких частях их проектов будет полезно применить инструменты Agile.
После тренинга менеджеры вернулись к себе на производства, начали пробовать что-то делать по-новому… и через пару месяцев уже целых 6 команд на заводах в разных городах России применяли Scrum!
Ребята из той нашей первой группы поддерживали связь друг с другом, обмениваясь best practices, опытом и результатами. Мы оказывали лишь небольшую консультационную поддержку.
Вслед на первыми scrum-командами, опираясь на их опыт и результаты, гибкие подходы начали внедрять в другие команды внутри производства.
Конечно, гораздо проще, когда измения драйвят или хотя бы активно поддерживают несколько менеджеров уровня СЕО-1. Но и инициатива из «середины» с опорой практически на одни на морально-волевые качества способна привести к впечатляющим результатам.
Со своей стороны мы стараемся найти оптимальный вариант поддержки в условиях клиента. Здорово, когда есть понимание и ресурсы на масштабную трансформацию, но важно помнить, что даже локальные улучшения дают ощутимый результат.
Сразу оговорюсь, что речь все же про мидл-менеджмент. Тем не менее, это отличный пример, как инициатива одного человека способна изменить 6 производств внутри огромной международной компании (бренд не называю по условиям NDA).
К нам обратился менеджер, курирующий ряд производственных направлений. Задача состояла в том, чтобы увеличить скорость реализации инициатив на производстве.
Поскольку на скорость влияет сразу множество факторов, решением виделось внедрение проектного подхода, построенного на agile-принципах:
- Инициативы перестают быть фоновой работой сотрудников: проекты считаются ключевыми активностями для улучшения производства.
- Под каждый проект собирается небольшая, но фиксированная команда. Из ежедневной загрузки каждого участника выделяется определенный % времени для работы над проектом в команде.
- Каждая проектная команда сфокусирована на конкретный результат в конце месяца, с еженедельными точками контроля по результатам очередного спринта.
К масштабной трансформации компания была не готова, но руководство дало добро на обучение 1 группы. Поэтому мы собрали самых заинтересованных руководителей — на тренинг пришли люди с десятка производств. Примерно вдвое больше, чем помещается в переговорку;)
Мы провели 8-часовой тренинг: разобрали механику Scrum, прошлись по всем этапам процесса и наметили, в каких частях их проектов будет полезно применить инструменты Agile.
После тренинга менеджеры вернулись к себе на производства, начали пробовать что-то делать по-новому… и через пару месяцев уже целых 6 команд на заводах в разных городах России применяли Scrum!
Ребята из той нашей первой группы поддерживали связь друг с другом, обмениваясь best practices, опытом и результатами. Мы оказывали лишь небольшую консультационную поддержку.
Вслед на первыми scrum-командами, опираясь на их опыт и результаты, гибкие подходы начали внедрять в другие команды внутри производства.
Конечно, гораздо проще, когда измения драйвят или хотя бы активно поддерживают несколько менеджеров уровня СЕО-1. Но и инициатива из «середины» с опорой практически на одни на морально-волевые качества способна привести к впечатляющим результатам.
Со своей стороны мы стараемся найти оптимальный вариант поддержки в условиях клиента. Здорово, когда есть понимание и ресурсы на масштабную трансформацию, но важно помнить, что даже локальные улучшения дают ощутимый результат.
⚡️Ближайшие тренинги
1️⃣ Фундаментальный Certified Agile Professional — основной курс по гибким подходам, включающий Scrum и Kanban.
👉 28-30 июля, 6-8 сентября, 4-6 октября
2️⃣ Продвинутый курс для Скрам-мастеров и всех, кому важны развитие команды, командный коучинг и фасилитация.
👉 7-9 июля, 20-22 октября
3️⃣ Продвинутый курс для Владельцев продуктов Advanced Product Ownership — проектирование и развитие продукта, управление ожиданиями заказчиков, работа в agile-команде.
👉 25-27 августа, 24-26 ноября
4️⃣ Управление проектами и их эволюционирование в гибкой среде — Agile Project Management.
👉 22-24 сентября
5️⃣ Agile in HR — развитие HR-сервисов, мотивационной стратегии и организационной структуры с использованием agile-подходов.
👉15-17 сентября
Вас ждут:
- Разбор актуальных проблем, с которыми сталкиваются команды
- Реальные практические навыки от экспертов, проводящих agile-трансформации в топовых российских и международных компаниях.
- Адаптация программы тренинга с учетом ваших ожиданий
- Международный сертификат от консорциума ICAgile.
Тренинги проходят онлайн: в zoom и miro. Три дня по 4-4,5 часа.
Количество мест ограничено: мы работаем группами до 16 человек.
👉Бронируйте участие заранее
1️⃣ Фундаментальный Certified Agile Professional — основной курс по гибким подходам, включающий Scrum и Kanban.
👉 28-30 июля, 6-8 сентября, 4-6 октября
2️⃣ Продвинутый курс для Скрам-мастеров и всех, кому важны развитие команды, командный коучинг и фасилитация.
👉 7-9 июля, 20-22 октября
3️⃣ Продвинутый курс для Владельцев продуктов Advanced Product Ownership — проектирование и развитие продукта, управление ожиданиями заказчиков, работа в agile-команде.
👉 25-27 августа, 24-26 ноября
4️⃣ Управление проектами и их эволюционирование в гибкой среде — Agile Project Management.
👉 22-24 сентября
5️⃣ Agile in HR — развитие HR-сервисов, мотивационной стратегии и организационной структуры с использованием agile-подходов.
👉15-17 сентября
Вас ждут:
- Разбор актуальных проблем, с которыми сталкиваются команды
- Реальные практические навыки от экспертов, проводящих agile-трансформации в топовых российских и международных компаниях.
- Адаптация программы тренинга с учетом ваших ожиданий
- Международный сертификат от консорциума ICAgile.
Тренинги проходят онлайн: в zoom и miro. Три дня по 4-4,5 часа.
Количество мест ограничено: мы работаем группами до 16 человек.
👉Бронируйте участие заранее
Матрица выбора подхода к проектному управлению
Как понять, какая форма проектного управления поможет достичь наилучших результатов в вашем случае? И классическое проектное управление по PMBook’у, и гибридные решения могут работать лучше Agile — все зависит от условий.
Собрали самые показательные критерии в единую матрицу: анкетируйте свой проект и оцените, с каким видом проектного управления больше совпадений.
Остались вопросы? Будем рады обсудить в комментариях)
Как понять, какая форма проектного управления поможет достичь наилучших результатов в вашем случае? И классическое проектное управление по PMBook’у, и гибридные решения могут работать лучше Agile — все зависит от условий.
Собрали самые показательные критерии в единую матрицу: анкетируйте свой проект и оцените, с каким видом проектного управления больше совпадений.
Остались вопросы? Будем рады обсудить в комментариях)
Эффективна ли передача роли Scrum-мастера по очереди каждому участнику команды?
Такой вопрос нам недавно задали на тренинге, и вообще вопросы о Скрам-мастере одни из самых часто задаваемых. Действительно, найм отдельного человека на эту роль — вариант скорее для больших компаний. Обычно такой Скрам-мастер сопровождает до 3 команд.
Но и передавать роль по очереди внутри команды не лучший вариант. Это приведет к тому, что нормального Скрам-мастера у команды в итоге вообще не будет.
Как и любой профессионал, Scrum-мастер должен развиваться, фокусироваться, у него должен быть долгосрочный план. Со «сменным» Скрам-мастером так не получится.
Хороший вариант — когда кто-то из участников команды разработки дополнительно берет на себя роль Скрам-мастера. Главное, не забыть соотвественно уменьшить объем его задач;) И не совмещать роли Скрам-мастера и Владельца продукта.
Вот, например, простая механика, помогающая выбрать Скрам-мастера внутри команды
Такой вопрос нам недавно задали на тренинге, и вообще вопросы о Скрам-мастере одни из самых часто задаваемых. Действительно, найм отдельного человека на эту роль — вариант скорее для больших компаний. Обычно такой Скрам-мастер сопровождает до 3 команд.
Но и передавать роль по очереди внутри команды не лучший вариант. Это приведет к тому, что нормального Скрам-мастера у команды в итоге вообще не будет.
Как и любой профессионал, Scrum-мастер должен развиваться, фокусироваться, у него должен быть долгосрочный план. Со «сменным» Скрам-мастером так не получится.
Хороший вариант — когда кто-то из участников команды разработки дополнительно берет на себя роль Скрам-мастера. Главное, не забыть соотвественно уменьшить объем его задач;) И не совмещать роли Скрам-мастера и Владельца продукта.
Вот, например, простая механика, помогающая выбрать Скрам-мастера внутри команды
Как оценить производительность новой команды?
Для планирования первого спринта нам нужно понимать, какой объем работы команда сможет сделать за итерацию — и соответственно, сколько и каких элементов бэклога мы сможем взять в работу.
На этот случай в SAFe есть отличная практика для оценки производительности команды:
- Например, команда работает в циклах двухнедельных спринтов: берем количество участников команды и умножаем на 8 — получаем ориентировочную производительность команды.
- Если спринт трехнедельный — умножаем на 13.
- Если у кого-то из команды предполагается отпуск или отгул, вычитаем по единице за каждый такой день.
- Затем выбираем из бэклога небольшой элемент, работа над которым по нашим оценкам займет 1 рабочий день (с учетом тестирования). Будем считать этот элемент “единицей”.
- Оцениваем все остальные элементы бэклога относительно этой “единицы”.
Для планирования первого спринта нам нужно понимать, какой объем работы команда сможет сделать за итерацию — и соответственно, сколько и каких элементов бэклога мы сможем взять в работу.
На этот случай в SAFe есть отличная практика для оценки производительности команды:
- Например, команда работает в циклах двухнедельных спринтов: берем количество участников команды и умножаем на 8 — получаем ориентировочную производительность команды.
- Если спринт трехнедельный — умножаем на 13.
- Если у кого-то из команды предполагается отпуск или отгул, вычитаем по единице за каждый такой день.
- Затем выбираем из бэклога небольшой элемент, работа над которым по нашим оценкам займет 1 рабочий день (с учетом тестирования). Будем считать этот элемент “единицей”.
- Оцениваем все остальные элементы бэклога относительно этой “единицы”.
Например, у нас есть команда из 7 человек (не включая Владельца продукта), которая будет работать 2-недельными спринтами, отпусков и отгулов в первом спринте не планируется. Получаем 7 х 8 = 56. Если кто-то из членов команды совмещает свою роль с ролью Scrum-Mastera, можно еще немного уменьшить общую производительность.
Таким образом получаем предполагаемую производительность команды на первый спринт. Для начала этого достаточно, а дальше команда начнет накапливать собственную статистику.
Таким образом получаем предполагаемую производительность команды на первый спринт. Для начала этого достаточно, а дальше команда начнет накапливать собственную статистику.
А отслеживать статистику команды помогает Burndown Chart. На первых этапах он очень полезен для прогресса команды, но и развитым командам рекомендуем не забывать про него и отслеживать динамику своих показателей;)
Друзья, привет! Внезапно освободилось 1 место на завтрашнем тренинге Agile Project Management.
Отличный шанс детально разобраться в особенностях управления проектами в Agile и гибридной среде и получить сертификацию ICAgile. По этому случаю сделаем приятную скидку;)
Тренинг будет проходить 22-24 сентября, с 9.00 до 13.00 (мск). Чтобы забронировать место, напишите на почту olga@onagile.ru
Отличный шанс детально разобраться в особенностях управления проектами в Agile и гибридной среде и получить сертификацию ICAgile. По этому случаю сделаем приятную скидку;)
Тренинг будет проходить 22-24 сентября, с 9.00 до 13.00 (мск). Чтобы забронировать место, напишите на почту olga@onagile.ru
Как учитывать User Story, которую не успели доделать за спринт?
Стоит ли изменить ее оценку перед возвращением в бэклог, ведь часть работы мы уже сделали?
Не нужно: оценка остается такой же. В текущем спринте будет падение Velocity (потому что, если задача не сделана до конца и не соответствует Критериям готовности, мы не можем засчитать ее сторипойнты). Но в следующем спринте мы снова возьмем в работу эту задачу, доделаем, и в итоге к спринту добавятся все те сторипойнты, которые были заложены в задаче.
На показатели производительности команды это не повлияет, потому что для их оценки используется среднее значение по спринтам, которое нивелирует эти скачки.
Стоит ли изменить ее оценку перед возвращением в бэклог, ведь часть работы мы уже сделали?
Не нужно: оценка остается такой же. В текущем спринте будет падение Velocity (потому что, если задача не сделана до конца и не соответствует Критериям готовности, мы не можем засчитать ее сторипойнты). Но в следующем спринте мы снова возьмем в работу эту задачу, доделаем, и в итоге к спринту добавятся все те сторипойнты, которые были заложены в задаче.
На показатели производительности команды это не повлияет, потому что для их оценки используется среднее значение по спринтам, которое нивелирует эти скачки.
Когда стоит выполнить переоценку User Story?
В прошлый раз мы обсуждали сценарий, когда команда не успевает завершить за спринт историю и не засчитывает в свою velocity баллы за выполненную ее часть. Обычно мы рекомендуем использовать именно этот подход, но есть исключения. О ситуациях, когда переоценка полезна, отлично пишет Майк Кон в книге «Agile: Оценка и планирование проектов».
Бывает, что команда не может завершить незаконченную часть User Story в следующем спринте. В этом случае лучше позволить команде получить баллы за завершенную часть истории: на основе новых знаний об объеме и сложности истории мы оцениваем, сколько баллов назначить за завершенную часть, и учитываем эти данные в velocity спринта.
Оставшуюся часть истории мы:
1. Переформулируем с учетом реализованного функционала.
2. Оцениваем на основе полученных в этом спринте знаний.
Суммарная оценка завершенной части истории и оставшейся не обязательно должна быть равна первоначальной оценке, ведь теперь мы знаем об истории больше и можем оценить точнее.
В прошлый раз мы обсуждали сценарий, когда команда не успевает завершить за спринт историю и не засчитывает в свою velocity баллы за выполненную ее часть. Обычно мы рекомендуем использовать именно этот подход, но есть исключения. О ситуациях, когда переоценка полезна, отлично пишет Майк Кон в книге «Agile: Оценка и планирование проектов».
Бывает, что команда не может завершить незаконченную часть User Story в следующем спринте. В этом случае лучше позволить команде получить баллы за завершенную часть истории: на основе новых знаний об объеме и сложности истории мы оцениваем, сколько баллов назначить за завершенную часть, и учитываем эти данные в velocity спринта.
Оставшуюся часть истории мы:
1. Переформулируем с учетом реализованного функционала.
2. Оцениваем на основе полученных в этом спринте знаний.
Суммарная оценка завершенной части истории и оставшейся не обязательно должна быть равна первоначальной оценке, ведь теперь мы знаем об истории больше и можем оценить точнее.
2 хороших способа приоритизации элементов бэклога
Обсуждали с клиентом PI-планирование и зашла речь о способах приоритизации элементов бэклога. Есть два метода, которые мы часто рекомендуем — они хорошо работают даже у команд, у которых пока мало опыта в приоритизации.
Первый вы наверняка знаете, но все же напомним;) Это приоритизация по трем категориям, или MoSCoW.
Акроним MoSCoW включает в себя следующую классификацию элементов бэклога:
- Must Have — эпики/ истории/ фичи, которые обязательно должны быть поставлены. Обычно они касаются решения существующщих проблем бизнеса или требований внешних регуляторов.
Например, мы делаем финасовый продукт, и чтобы не получить штраф, должны к 1 декабря поставить протокол безопасности.
Элементы, отнесенные к Must, составляют минимум того, что мы должны поставить в ближайшие итерации.
- Should Have — эпики/ истории/ фичи, имеющие решающее значение для успеха релиза.
Такие элементы бэклога не менее важны, чем элементы категории Must, но могут быть несрочными.
- Could Have — «желательные» эпики/ истории/ фичи: они представляют собой значительную ценность для релиза или продукта в целом, но не являются критичными, как Must и Should.
- Дополнительная категория — Won't Have: эти элементы бэклога хорошо бы реализовать, если останется время, но, скорее всего, часть из них или даже все не войдут в ближайший релиз.
Метод приоритизации MoSCoW не слишком точный, но достаточно интуитивный и подойдет даже начинающим командам.
Более точный, но и сложный метод — Weighted Shortest Job First, основанный на соотношении ценности элемента бэклога для бизнеса к «размеру» работы, которую нужно совершить для поставки этого элемента.
Подробно об этом методе читайте в блоге.
А какими методами приоритизации чаще пользуетесь вы?
Делитесь опытом в комментариях — соберем все методы в отдельный пост: будет полезно для новичков и не только;)
Обсуждали с клиентом PI-планирование и зашла речь о способах приоритизации элементов бэклога. Есть два метода, которые мы часто рекомендуем — они хорошо работают даже у команд, у которых пока мало опыта в приоритизации.
Первый вы наверняка знаете, но все же напомним;) Это приоритизация по трем категориям, или MoSCoW.
Акроним MoSCoW включает в себя следующую классификацию элементов бэклога:
- Must Have — эпики/ истории/ фичи, которые обязательно должны быть поставлены. Обычно они касаются решения существующщих проблем бизнеса или требований внешних регуляторов.
Например, мы делаем финасовый продукт, и чтобы не получить штраф, должны к 1 декабря поставить протокол безопасности.
Элементы, отнесенные к Must, составляют минимум того, что мы должны поставить в ближайшие итерации.
- Should Have — эпики/ истории/ фичи, имеющие решающее значение для успеха релиза.
Такие элементы бэклога не менее важны, чем элементы категории Must, но могут быть несрочными.
- Could Have — «желательные» эпики/ истории/ фичи: они представляют собой значительную ценность для релиза или продукта в целом, но не являются критичными, как Must и Should.
- Дополнительная категория — Won't Have: эти элементы бэклога хорошо бы реализовать, если останется время, но, скорее всего, часть из них или даже все не войдут в ближайший релиз.
Метод приоритизации MoSCoW не слишком точный, но достаточно интуитивный и подойдет даже начинающим командам.
Более точный, но и сложный метод — Weighted Shortest Job First, основанный на соотношении ценности элемента бэклога для бизнеса к «размеру» работы, которую нужно совершить для поставки этого элемента.
Подробно об этом методе читайте в блоге.
А какими методами приоритизации чаще пользуетесь вы?
Делитесь опытом в комментариях — соберем все методы в отдельный пост: будет полезно для новичков и не только;)
Нужен ли вам аудит команд и чем его заменить
В последнее время нам приходит много запросов на аудит команд и процессов. Поскольку к концу года вопрос особенно актуальный, давайте разбираться, как получить максимум пользы и сэкономить драгоценное время и деньги.
Первое, на что стоит ориентироваться — как устроена работа в вашей компании сейчас.
1. У вас есть команды, которые уже работают по Scrum. Задача: найти дисфункции и потенциальные риски, выявить точки роста и составить план по развитию команды.
С этим отлично справляется аудит. Причем, если у нас есть 10 команд, нет необходимости оценивать их все — достаточно оценить 1-2 команды, в остальных будет плюс-минус такая же ситуация. А деньги, которые вы не потратите на избыточный аудит, целесообразнее направить на улучшение работы команд.
2. У вас пока нет команд, которые используют agile. В этом случае аудит как отдельная активность по сути не требуется, поскольку планируется значительное изменение всех процессов. Нам предстоит постоить работу над проектом или продуктом заново, и эффективнее сосредоточиться именно на этом: на подготовке и обучении людей, на формировании договоренностей с бизнесом.
Слабые места в работе команд обнаружатся в процессе подготовки к внедрению изменений, и мы сможем их пофиксить во время обучения и отладки процессов.
Если у вас много команд, рекомендуем выбрать в качестве пилота 1-2 и запустить сначала их, а через 2-3 месяца масштабировать опыт на остальные команды.
Масштабная трансформация всей компании сразу — по-своему хороший вариант, но требует гораздо больших ресурсов и более тщательной и долгой подготовки, что не всегда целесообразно в условиях, когда изменения уже назрели и нужны бизнесу здесь и сейчас.
—
Если вам нужна консультация по Agile, обучение, помощь с запуском команд или поддержка Agile-трансформации компании, напишите или позвоните нам, будем рады поделиться опытом и помочь.
info@onagile.ru, +7 495 221 87 39
В последнее время нам приходит много запросов на аудит команд и процессов. Поскольку к концу года вопрос особенно актуальный, давайте разбираться, как получить максимум пользы и сэкономить драгоценное время и деньги.
Первое, на что стоит ориентироваться — как устроена работа в вашей компании сейчас.
1. У вас есть команды, которые уже работают по Scrum. Задача: найти дисфункции и потенциальные риски, выявить точки роста и составить план по развитию команды.
С этим отлично справляется аудит. Причем, если у нас есть 10 команд, нет необходимости оценивать их все — достаточно оценить 1-2 команды, в остальных будет плюс-минус такая же ситуация. А деньги, которые вы не потратите на избыточный аудит, целесообразнее направить на улучшение работы команд.
2. У вас пока нет команд, которые используют agile. В этом случае аудит как отдельная активность по сути не требуется, поскольку планируется значительное изменение всех процессов. Нам предстоит постоить работу над проектом или продуктом заново, и эффективнее сосредоточиться именно на этом: на подготовке и обучении людей, на формировании договоренностей с бизнесом.
Слабые места в работе команд обнаружатся в процессе подготовки к внедрению изменений, и мы сможем их пофиксить во время обучения и отладки процессов.
Если у вас много команд, рекомендуем выбрать в качестве пилота 1-2 и запустить сначала их, а через 2-3 месяца масштабировать опыт на остальные команды.
Масштабная трансформация всей компании сразу — по-своему хороший вариант, но требует гораздо больших ресурсов и более тщательной и долгой подготовки, что не всегда целесообразно в условиях, когда изменения уже назрели и нужны бизнесу здесь и сейчас.
—
Если вам нужна консультация по Agile, обучение, помощь с запуском команд или поддержка Agile-трансформации компании, напишите или позвоните нам, будем рады поделиться опытом и помочь.
info@onagile.ru, +7 495 221 87 39
❤1
Итак, подарки открыты, все новогодние фильмы посмотрены, а впереди еще несколько дней каникул.
Предлагаем начать использовать их так, чтобы заложить фундамент продуктивного года, при этом не слишком отвлекаясь от отдыха.
Команда OnAgile подготовила для вас небольшой адвент🎁 с рекомендациями, которые помогут подготовиться к первому рабочему дню и начать 2022-й максимально продуктивно.
Каждый день мы будем публиковать по одной карточке с небольшим заданием на 3-5 минут. Не забывайте пересылать друзьям и коллегам.
Начинаем!
Предлагаем начать использовать их так, чтобы заложить фундамент продуктивного года, при этом не слишком отвлекаясь от отдыха.
Команда OnAgile подготовила для вас небольшой адвент🎁 с рекомендациями, которые помогут подготовиться к первому рабочему дню и начать 2022-й максимально продуктивно.
Каждый день мы будем публиковать по одной карточке с небольшим заданием на 3-5 минут. Не забывайте пересылать друзьям и коллегам.
Начинаем!
Мысленная ретроспектива 2021 года
Отвлеченный от рабочих будней контекст долгого праздника — самое время ненадолго вернуться в 2021 год и спросить себя:
🔹 Чем из того, что я (или моя команда) сделали в ушедшем году, мы действительно можем гордиться?
🔹 Какие из проблем, с которыми мы столкнулись, можно было решить гораздо проще и быстрее?
🔹 Что из сделанного оказалось не очень полезным и можно было не тратить свои силы и время на это?
Для того чтобы ответить на эти вопросы, вам не нужно собирать команду — просто подумайте об этом в свободное время и новые идеи не заставят себя ждать.
Отвлеченный от рабочих будней контекст долгого праздника — самое время ненадолго вернуться в 2021 год и спросить себя:
🔹 Чем из того, что я (или моя команда) сделали в ушедшем году, мы действительно можем гордиться?
🔹 Какие из проблем, с которыми мы столкнулись, можно было решить гораздо проще и быстрее?
🔹 Что из сделанного оказалось не очень полезным и можно было не тратить свои силы и время на это?
Для того чтобы ответить на эти вопросы, вам не нужно собирать команду — просто подумайте об этом в свободное время и новые идеи не заставят себя ждать.
Новые идеи по продукту
🔹 Попробуйте посмотреть на продукт, которым занимается ваша команда, свежим взглядом: что может дать значимый толчок в его развитии и что для этого следует сделать сразу после праздников?
Например, можно протестировать несколько интересных на ваш взгляд гипотез, которые могут дать ценные данные и подтолкнуть к новым идеям.
🔹 Также рекомендуем лишний раз посмотреть продукты/сайты конкурентов: на что они делают упор, что появилось интересного в этих продуктах за последнее время, что конкуренты говорят клиентам о себе и о своем сервисе?
Для того чтобы сделать вышеперечисленное, не обязательно быть менеджером продукта. Вне зависимости от вашей роли в команде, это небольшое упражнение поможет увидеть интересные идеи, которые можно будет взять в работу после праздников.
🔹 Попробуйте посмотреть на продукт, которым занимается ваша команда, свежим взглядом: что может дать значимый толчок в его развитии и что для этого следует сделать сразу после праздников?
Например, можно протестировать несколько интересных на ваш взгляд гипотез, которые могут дать ценные данные и подтолкнуть к новым идеям.
🔹 Также рекомендуем лишний раз посмотреть продукты/сайты конкурентов: на что они делают упор, что появилось интересного в этих продуктах за последнее время, что конкуренты говорят клиентам о себе и о своем сервисе?
Для того чтобы сделать вышеперечисленное, не обязательно быть менеджером продукта. Вне зависимости от вашей роли в команде, это небольшое упражнение поможет увидеть интересные идеи, которые можно будет взять в работу после праздников.
Клиенты и конверсия
В продолжение темы развития продукта полезно также запустить мыслительный процесс в сторону клиентов, их потребностей и того, как они взаимодействуют с нашим продуктом/сервисом/компанией.
Например:
🔹 Кого из конкретных клиентов (или представителей определённого сегмента) можно было бы кратко проинтервьюировать в первые рабочие дни, чтобы лучше понять, что им сейчас нужно, как они взаимодействуют с нашим продуктом, что у них не совсем получается?
🔹 Как выглядит конверсия на разных этапах пути клиента: какой процент людей возвращается, какой процент делает полезное действие, на каком этапе уходит больше всего клиентов и с чем это может быть связано?
🔹 Какой ещё сегмент клиентов мы могли бы привлечь, чтобы протестировать их интерес к нашему продукту? И как это обернуть в высококонверсионное ценностное предложение?
Безусловно, для всего этого есть стандартные отчеты, каникулы же дают возможность попробовать посмотреть отвлечённым от рабочей рутины взглядом и увидеть что-то новое.
В продолжение темы развития продукта полезно также запустить мыслительный процесс в сторону клиентов, их потребностей и того, как они взаимодействуют с нашим продуктом/сервисом/компанией.
Например:
🔹 Кого из конкретных клиентов (или представителей определённого сегмента) можно было бы кратко проинтервьюировать в первые рабочие дни, чтобы лучше понять, что им сейчас нужно, как они взаимодействуют с нашим продуктом, что у них не совсем получается?
🔹 Как выглядит конверсия на разных этапах пути клиента: какой процент людей возвращается, какой процент делает полезное действие, на каком этапе уходит больше всего клиентов и с чем это может быть связано?
🔹 Какой ещё сегмент клиентов мы могли бы привлечь, чтобы протестировать их интерес к нашему продукту? И как это обернуть в высококонверсионное ценностное предложение?
Безусловно, для всего этого есть стандартные отчеты, каникулы же дают возможность попробовать посмотреть отвлечённым от рабочей рутины взглядом и увидеть что-то новое.