Всем успешной доставки!
🆘 Всю неделю буду в командировке и трудно будет писать новые посты.
Но я уже составил список следующих тем:
1.визуализация, wip лимиты и буферные статусы
2. Dor/Dod/Ac
3. 1 на 1 и ретро команды
Попытаюсь кратко описать какие проблемы помогают решать эти практики и как их внедрить у себя в командах.
Но я уже составил список следующих тем:
1.визуализация, wip лимиты и буферные статусы
2. Dor/Dod/Ac
3. 1 на 1 и ретро команды
Попытаюсь кратко описать какие проблемы помогают решать эти практики и как их внедрить у себя в командах.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤1🔥1
This media is not supported in your browser
VIEW IN TELEGRAM
Всем успешной доставки! Пока я в командировке, ловите мой любимый мем, который я честно украл из канала
🤣5❤1🔥1😁1
Всем успешной доставки! Сегодня обсудим практики Kanban: визуализацию, WIP-лимиты и буферные статусы.
Более детально про каждую практику:
1.Визуализация - помогает команде/заказчику видеть текущий статус работы.
Отображает нагрузку - команды могут увидеть, где возникают узкие места и как распределена работа между членами команды.
Повышает прозрачность - все участники команды/заказчики могут легко отслеживать прогресс выполнения любой задачи.
2.Wip лимиты -это ограничения на количество задач в каждой стадии рабочего процесса.
Они снижают многозадачность и позволяют команде сосредоточиться на завершении текущей работы.
Wip лимиты бывают:
-персональные
-на рабочий процесс CONWIP
-на команду
-на агрегированную доску сервиса
Запомните: "Перестаньте начинать, начните заканчивать."
3.Буферные статусы - обозначают промежуточные состояния задач (например, ожидание тестирования). Они помогают управлять переходами между стадиями (например, от завершения разработки к тестированию).
Если кто-то закончил работу-это не значит, что кто-то другой начал ее.
Начинать внедрять эти практики надо с визуализации, более детальная визуализация помогает видеть весь процесс производства.
Если у вас доска состоит из трех столбцов: готов к работе, в работе, выполнено, то такая визуализация не отвечает на вопрос, что происходит с задачей, но это все равно лучше, чем ничего 😄
В момент визуализации вашей работы, не забывайте про буферные статусы, они четко смогут подсветить, где у вас возникают узкие горлышки.
После визуализации определите WIP-лимиты. Начните с персональных лимитов для каждого участника, а по мере повышения зрелости команды пересмотрите их.
Вроде получилось кратко, не забывайте, визуализацию, wip лимиты и буферные статусы можно пересматривать вместе с повышение зрелости команды!🏐
Более детально про каждую практику:
1.Визуализация - помогает команде/заказчику видеть текущий статус работы.
Отображает нагрузку - команды могут увидеть, где возникают узкие места и как распределена работа между членами команды.
Повышает прозрачность - все участники команды/заказчики могут легко отслеживать прогресс выполнения любой задачи.
2.Wip лимиты -это ограничения на количество задач в каждой стадии рабочего процесса.
Они снижают многозадачность и позволяют команде сосредоточиться на завершении текущей работы.
Wip лимиты бывают:
-персональные
-на рабочий процесс CONWIP
-на команду
-на агрегированную доску сервиса
Запомните: "Перестаньте начинать, начните заканчивать."
3.Буферные статусы - обозначают промежуточные состояния задач (например, ожидание тестирования). Они помогают управлять переходами между стадиями (например, от завершения разработки к тестированию).
Если кто-то закончил работу-это не значит, что кто-то другой начал ее.
Начинать внедрять эти практики надо с визуализации, более детальная визуализация помогает видеть весь процесс производства.
Если у вас доска состоит из трех столбцов: готов к работе, в работе, выполнено, то такая визуализация не отвечает на вопрос, что происходит с задачей, но это все равно лучше, чем ничего 😄
В момент визуализации вашей работы, не забывайте про буферные статусы, они четко смогут подсветить, где у вас возникают узкие горлышки.
После визуализации определите WIP-лимиты. Начните с персональных лимитов для каждого участника, а по мере повышения зрелости команды пересмотрите их.
Вроде получилось кратко, не забывайте, визуализацию, wip лимиты и буферные статусы можно пересматривать вместе с повышение зрелости команды!
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤2
Всем успешной доставки! Вы визуализировали свою работу, внедрили wip-лимиты, но все еще бывают задачи, которые требуют уточнение после точки принятия обязательств? Тогда этот пост для вас 😏 , обсудим сегодня Definition of Ready (DoR), Acceptance Criteria (AC), Definition of done (DoD).
Начнем с определений:
1.DoR - это набор критериев, которые должны быть выполнены для для готовности задачи к работе. Он служит своеобразным "фильтром": если задача не соответствует DoR, команда может отказаться брать ее в работу
Зачем нужен DoR - не брать в работу не проработанные задачи, позволяет однозначно понимать, что нужно сделать команде.
2.АС - это критерии приемки конкретной задачи(этим отличается от Dod), которые определяют ожидаемое поведение и функционал, что дает представление о том, какие результаты должны быть достигнуты.
Зачем нужны AC - они помогают удостовериться, что конечный продукт соответствует требованиям заказчика и ожиданиям пользователей
3.DoD - это набор критериев, которым должна соответствовать задача, чтобы считаться завершенной, отличается от АС тем, что DoD одинаков для всех задач и в него включаются какие-то общие правила, например выполненное тестирование, документирование, код-ревью.
Зачем нужен DoD - позволяет команде повысить прозрачность и минимизировать риски незавершенной или некачественной работы.
Что нужно, чтобы внедрить DoR, DoD, AC?
1.Вовлеченность команды - организуйте совместные встречи с участниками команды (разработчики, тестировщики, аналитики и т.д.) для обсуждения и согласования подходящих критериев для DoD, DoR, AC.
2.Сформулируйте критерии - на основании обсуждений составьте списки для DoD и DoR, учитывающие практики и процессы вашей команды. Убедитесь, что формулировки критериев ясны и понятны всем.
3.Зафиксируйте договоренности - после согласования критериев, утвердите DoD, DoR и AC, зафиксировав их в виде документа или на доске (например в jira можно вынести их отдельным свимлейном).
4.Внедряйте в работу - договоритесь со всем участниками команды и заказчиками, что теперь без этих критериев вы не берете задачи в работу.
5.Регулярный пересмотр и улучшение - собирайте обратную связь от команды о том, насколько эффективно применяются DoD, DoR и AC, например на ретро команды.
Поздравляю, вы и ваша команда великолепны 🚀
#dor #dod #ac #delivery #discovery #jira
Начнем с определений:
1.DoR - это набор критериев, которые должны быть выполнены для для готовности задачи к работе. Он служит своеобразным "фильтром": если задача не соответствует DoR, команда может отказаться брать ее в работу
Зачем нужен DoR - не брать в работу не проработанные задачи, позволяет однозначно понимать, что нужно сделать команде.
2.АС - это критерии приемки конкретной задачи(этим отличается от Dod), которые определяют ожидаемое поведение и функционал, что дает представление о том, какие результаты должны быть достигнуты.
Зачем нужны AC - они помогают удостовериться, что конечный продукт соответствует требованиям заказчика и ожиданиям пользователей
3.DoD - это набор критериев, которым должна соответствовать задача, чтобы считаться завершенной, отличается от АС тем, что DoD одинаков для всех задач и в него включаются какие-то общие правила, например выполненное тестирование, документирование, код-ревью.
Зачем нужен DoD - позволяет команде повысить прозрачность и минимизировать риски незавершенной или некачественной работы.
Что нужно, чтобы внедрить DoR, DoD, AC?
1.Вовлеченность команды - организуйте совместные встречи с участниками команды (разработчики, тестировщики, аналитики и т.д.) для обсуждения и согласования подходящих критериев для DoD, DoR, AC.
2.Сформулируйте критерии - на основании обсуждений составьте списки для DoD и DoR, учитывающие практики и процессы вашей команды. Убедитесь, что формулировки критериев ясны и понятны всем.
3.Зафиксируйте договоренности - после согласования критериев, утвердите DoD, DoR и AC, зафиксировав их в виде документа или на доске (например в jira можно вынести их отдельным свимлейном).
4.Внедряйте в работу - договоритесь со всем участниками команды и заказчиками, что теперь без этих критериев вы не берете задачи в работу.
5.Регулярный пересмотр и улучшение - собирайте обратную связь от команды о том, насколько эффективно применяются DoD, DoR и AC, например на ретро команды.
Поздравляю, вы и ваша команда великолепны 🚀
#dor #dod #ac #delivery #discovery #jira
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7❤1🥰1👌1
Всем успешной доставки! Сегодня обсудим практики, не касающиеся напрямую доставки ценности, но влияющие на команду: 1:1 встречи и ретроспектива команды.
Раскрою каждую практику отдельно:
1.1:1- индивидуальные встречи между тимлидом (или любым менеджером) и членом команды для обсуждения различных тем, не обязательно связанных с работой.
Зачем нужно тимлиду: позволяет предоставить сотруднику конструктивную обратную связь, наладить доверительные отношения в команде.
Зачем нужно сотруднику: важно понимать как оценивается его работа, как и куда он может расти как профессионал (например составить ИПР), рассказать про свои проблемы, вынести какие-то предложения по своей работе.
Встреча должна быть регулярной и частой, например раз в 1 или 2 недели, обязательной с повесткой и документированием всех договоренностей
2.Ретроспектива - это встреча команды для анализа прошлых результатов: что сделано хорошо, что можно улучшить и какие есть препятствия.
Нужна для того, чтобы собрать обратную связь со всех участников команды, придумать идеи по улучшению работы в команде, вовлечь всех участников команды в работу над внедрением изменений.
Встреча должна быть регулярной, например раз в месяц, для встречи необходима какая-то онлайн доска (писал про доски отдельный пост ссылка на пост) где вы можете стикерами отмечать, что было хорошо и что можно улучшить, фасилитатором встречи может быть любой участник команды.
Обе встречи полезны для раннего выявления проблем в команде или у конкретного человека, что поможет избежать неожиданных увольнений😎
#ретро #1на1 #команда
Раскрою каждую практику отдельно:
1.1:1- индивидуальные встречи между тимлидом (или любым менеджером) и членом команды для обсуждения различных тем, не обязательно связанных с работой.
Зачем нужно тимлиду: позволяет предоставить сотруднику конструктивную обратную связь, наладить доверительные отношения в команде.
Зачем нужно сотруднику: важно понимать как оценивается его работа, как и куда он может расти как профессионал (например составить ИПР), рассказать про свои проблемы, вынести какие-то предложения по своей работе.
Встреча должна быть регулярной и частой, например раз в 1 или 2 недели, обязательной с повесткой и документированием всех договоренностей
2.Ретроспектива - это встреча команды для анализа прошлых результатов: что сделано хорошо, что можно улучшить и какие есть препятствия.
Нужна для того, чтобы собрать обратную связь со всех участников команды, придумать идеи по улучшению работы в команде, вовлечь всех участников команды в работу над внедрением изменений.
Встреча должна быть регулярной, например раз в месяц, для встречи необходима какая-то онлайн доска (писал про доски отдельный пост ссылка на пост) где вы можете стикерами отмечать, что было хорошо и что можно улучшить, фасилитатором встречи может быть любой участник команды.
Обе встречи полезны для раннего выявления проблем в команде или у конкретного человека, что поможет избежать неожиданных увольнений
#ретро #1на1 #команда
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5❤1
Друзья, совсем скоро я буду выступать на крутой IT-конференции UIC Dev в Ижевске.
UIC Dev - событие для специалистов из интернет-сферы: от HR-ов до IT-директоров. Да, оно не только для разработчиков, но и для аналитиков, тестировщиков, дизайнеров, маркетологов, SEO-шников, копирайтеров и т.д.
В этом году будетт:
6 направлений: разработка, управление и анализ, бизнес+IT, дизайн и контент, маркетинг и digital, UIC Talks
70+ докладов про инструменты, кейсы, "боли" IT-сообщества, AI и будущее
Обсуждение актуальных событий, разбор трендов из области IT и не только
Общение с единомышленниками, дискуссии, обмен опытом, новые идеи
Интерактивы и розыгрыши призов
Вечером первого дня пройдет афтепати с выступлением группы “Стихи на окнах подъезда №8”, дискотекой и развлечениями.
🎁 И у меня есть приятный бонус для подписчиков —
Просто используйте код
Приходите, будет интересно! Встретимся на конференции и пообщаемся лично 🙌
UIC Dev - событие для специалистов из интернет-сферы: от HR-ов до IT-директоров. Да, оно не только для разработчиков, но и для аналитиков, тестировщиков, дизайнеров, маркетологов, SEO-шников, копирайтеров и т.д.
В этом году будетт:
6 направлений: разработка, управление и анализ, бизнес+IT, дизайн и контент, маркетинг и digital, UIC Talks
70+ докладов про инструменты, кейсы, "боли" IT-сообщества, AI и будущее
Обсуждение актуальных событий, разбор трендов из области IT и не только
Общение с единомышленниками, дискуссии, обмен опытом, новые идеи
Интерактивы и розыгрыши призов
Вечером первого дня пройдет афтепати с выступлением группы “Стихи на окнах подъезда №8”, дискотекой и развлечениями.
🎁 И у меня есть приятный бонус для подписчиков —
TORGASHOV со скидкой 30% на покупку билетов! Просто используйте код
TORGASHOV при регистрации на сайте https://uic.dev/#tickets и получайте билет по супервыгодной цене.Приходите, будет интересно! Встретимся на конференции и пообщаемся лично 🙌
🔥7❤1
Оценка - это прогноз ваших работ, производственные метрики такие как lead time и troughput (пропускная способность), - это факт ваших работ. На этом можно закончить пост...Но я попробую раскрыть, что имеется ввиду.
Основная проблема, которую должна решать оценка задач, - это сроки их (задач) выполнения.
1.Но вот те же Story point это не про сроки.
SP - это единица измерения, отражающая усилия, необходимые для завершения элемента незавершенной работы по продукту.
SP включает три ключевых измерения:
-Объем работы (требуемое время для выполнения);
-Сложность (умственная нагрузка);
-Неопределенность (риски и сомнения в возможности выполнения).
Story points были придуманы, чтобы запутать оценки, чтобы "определенные менеджеры" не давили на команду по поводу оценок ©Рон Джеффрис (создатель Story points).
2.Оценка задач в часах — это прогноз времени, необходимого для выполнения задачи: джун справится за 10 часов, сеньор — за 5. Однако в процессе выполнения могут возникнуть непредвиденные обстоятельства, такие как отпуск, болезнь или увольнение, что может удлинить оценку с 10 до 20 часов. Оценка может работать в заказной разработке, когда вам надо перевести это все в деньги.
Если вы все еще сомневаетесь, проведите эксперимент, описанный Павлом Ахметчановым в этом докладе: возьмите все задачи, оцененные в SP, и сравните их фактическое время выполнения, выгрузив метрики из таск-менеджера. Скорее всего, вы не найдете закономерностей в оценках, так как разные задачи, оцененные в 1/3/5 SP каждая, выполнялись за разное время.
Что же тогда использовать? Метрики Lead time и Throughput (пропускная способность). Если вы условно сделали 100 задач по 85 перцентилю за 40 дней, то 101 задачу вы сделаете за 40 дней или раньше. Да, могут быть всплески больше 40 дней (каждый такой всплеск надо разбирать отдельно, по каким причинам вырос lead time?), которые уйдут за 85 перцентиль, это надо объяснить заказчику, когда будете озвучивать сроки.
Полезные ссылки про планирование на основе статистики и метрик:
Метод Монте-Карло
Статья Павла Ахметчанова про который писал выше
Видео про планирование на основе статистики, тоже от Паши
Может по холиварим в комментариях?
#sp #storypoints #оценка #прогноз #метрики
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5❤1
Всем успешной доставки! Давайте обсудим, как сосредоточиться на доставке ценности клиенту в целом, а не на ее отдельных частях.
Возьмем пример шавермы (привет, Денис). Когда мы заказываем шаверму в кафе, нам не нужны отдельно мясо или овощи — они не представляют ценности сами по себе. Нам нужна готовая шаверма, а для этого нужно собрать все ингредиенты вместе и только потом передать клиенту.
Теперь перенесем это на фичу (назовем это продуктовым эпиком), которую мы хотим реализовать.
У нас есть два этапа: discovery и delivery. После этапа discovery фича переходит в delivery, где появляется сущность ЗВК (запрос в команду).
ЗВК - это такая задача, с которой к нам пришел заказчик, без декомпозиции, ради организации процесса производства, т.е. ЗВК = шаверма.
ЗВК должен иметь ценность для заказчика/клиента/команды.
Сосредоточившись на ЗВК, команда фокусируется на доставке ценности, а не на её частях. Например, клиенту не нужно колесо от машины — ему нужна вся машина.
ЗВК может быть разбит на более мелкие задачи, которые сами по себе ценности не несут, но только выполнив все мелкие задачи, мы можем релизить ЗВК и доставить ценность клиенту.
Зачем нужно ЗВК?
-Фокус команды на доставки ценности.
-Видимость "налога на фичи", т.е. понимание количества задач и времени, которое команда тратит не только на фичи, но и на технические ЗВК.
-Отвечать на вопрос как быстро и стабильно мы доставляем ценность клиент, настроив метрики (lead time, пропускная способность) для ЗВК.
Как это выглядит в таск трекере (у нас jira):
1.Все ЗВК заводятся эпиком, у эпика есть поле "тип изменений", данное поле отображает вид работ которая делает команда, например: развитие функционала (фича), техническое развитие, технический долг, тестовый долг, ошибка. Для своей команды вы сами можете определить тип изменений.
2.Продуктовый эпик может жить в одном jira проекте (например так где у вас визуализирован e2e процесс), ЗВК может быть в другом jira проекте (где у вас живет продуктовая команда).
Надеюсь, хоть чуть-чуть стало понятней, с этой темой я выступал в понедельник в Ижевске на конференции #uicdev
Возьмем пример шавермы (привет, Денис). Когда мы заказываем шаверму в кафе, нам не нужны отдельно мясо или овощи — они не представляют ценности сами по себе. Нам нужна готовая шаверма, а для этого нужно собрать все ингредиенты вместе и только потом передать клиенту.
Теперь перенесем это на фичу (назовем это продуктовым эпиком), которую мы хотим реализовать.
У нас есть два этапа: discovery и delivery. После этапа discovery фича переходит в delivery, где появляется сущность ЗВК (запрос в команду).
ЗВК - это такая задача, с которой к нам пришел заказчик, без декомпозиции, ради организации процесса производства, т.е. ЗВК = шаверма.
ЗВК должен иметь ценность для заказчика/клиента/команды.
Сосредоточившись на ЗВК, команда фокусируется на доставке ценности, а не на её частях. Например, клиенту не нужно колесо от машины — ему нужна вся машина.
ЗВК может быть разбит на более мелкие задачи, которые сами по себе ценности не несут, но только выполнив все мелкие задачи, мы можем релизить ЗВК и доставить ценность клиенту.
Зачем нужно ЗВК?
-Фокус команды на доставки ценности.
-Видимость "налога на фичи", т.е. понимание количества задач и времени, которое команда тратит не только на фичи, но и на технические ЗВК.
-Отвечать на вопрос как быстро и стабильно мы доставляем ценность клиент, настроив метрики (lead time, пропускная способность) для ЗВК.
Как это выглядит в таск трекере (у нас jira):
1.Все ЗВК заводятся эпиком, у эпика есть поле "тип изменений", данное поле отображает вид работ которая делает команда, например: развитие функционала (фича), техническое развитие, технический долг, тестовый долг, ошибка. Для своей команды вы сами можете определить тип изменений.
2.Продуктовый эпик может жить в одном jira проекте (например так где у вас визуализирован e2e процесс), ЗВК может быть в другом jira проекте (где у вас живет продуктовая команда).
Надеюсь, хоть чуть-чуть стало понятней, с этой темой я выступал в понедельник в Ижевске на конференции #uicdev
👍8❤2
Всем успешной доставки!
Подвожу итог по каналу: в прошлое воскресенье (13.10) ему исполнилось 2 месяца, за это время набралось 95 подписчиков. Опубликовано 15 постов. Также настроен бот, который автоматически публикует посты на Дзене , но там ситуация с просмотрами и подписчиками печальная😁 .
Самые просматриваемые посты:
1.Про Kanban 278 просмотров, 5 репостов.
2.Про плагины для Jira 276 просмотров, 7 репостов .
3.Про DOR/DOD/AC 257 просмотров, 1 репост.
4.Про этап Discovery 225, 1 репостов.
Если вы еще не видели эти посты, то кажется они будут очень полезны вам.
Остальные посты набирали 100+ просмотров.
Радует, что пост про Kanban 🚀 на первом месте! Классно, что просмотров больше, чем подписчиков.
Ближайшая цель — достичь 100 подписчиков и заказать рекламу канала, но пока неясно, где и у кого.
Если есть идеи для новых постов, пишите в комментариях.
Подвожу итог по каналу: в прошлое воскресенье (13.10) ему исполнилось 2 месяца, за это время набралось 95 подписчиков. Опубликовано 15 постов. Также настроен бот, который автоматически публикует посты на Дзене , но там ситуация с просмотрами и подписчиками печальная
Самые просматриваемые посты:
1.Про Kanban 278 просмотров, 5 репостов.
2.Про плагины для Jira 276 просмотров, 7 репостов .
3.Про DOR/DOD/AC 257 просмотров, 1 репост.
4.Про этап Discovery 225, 1 репостов.
Если вы еще не видели эти посты, то кажется они будут очень полезны вам.
Остальные посты набирали 100+ просмотров.
Радует, что пост про Kanban 🚀 на первом месте! Классно, что просмотров больше, чем подписчиков.
Ближайшая цель — достичь 100 подписчиков и заказать рекламу канала, но пока неясно, где и у кого.
Если есть идеи для новых постов, пишите в комментариях.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8🫡3❤1
Всем успешной доставки!
Как я уже писал ранее Delivery Manager - это менеджер изменений, который приносит в компанию/команду новые изменения и внедряет их.
Сегодня обсудим, как осуществлять эти изменения
Когда вы пытаетесь внедрить какие либо изменения, то скорее всего вы сталкиваетесь с большим сопротивлением со стороны участников этих изменений.
Чтобы минимизировать это сопротивление, можно использовать популярную модель управления изменениями ADKAR, разработанную компанией Prosci.
ADKAR включает пять ключевых элементов для успешного внедрения изменений.
Каждая буква в акрониме обозначает одну из стадий:
A - Awareness (Осведомлённость): Понимание необходимости изменений и осознание причин, по которым они необходимы. Какую проблему решаем и какой профит получит команда/компания.
D - Desire (Желание): Стремление поддерживать изменения и участвовать в процессе.
K - Knowledge (Знание): Осознание того, как именно будут реализованы изменения и какие навыки нужны для этого.
A - Ability (Способность): Практическое применение знаний и навыков для реализации изменений.
R - Reinforcement (Подкрепление): Устойчивое внедрение изменений в организационную культуру и признание успехов.
Для внедрения изменений необходимо пройти три фазы:
1.Подготовка изменений: включает осведомлённость и желание.
2.Управление изменениями: включает знание и способность.
3.Закрепление изменений: включает окончательную стадию — подкрепление.
Чтобы начать процесс внедрения по модели ADKAR или другой, важно понять, какую проблему вы решаете, и вовлечь команду.
Этот путь проходит через: стресс (метрика, показывающая проблемы в команде) -> рефлексия (встреча для обсуждения решения проблемы) -> лидерство (инициатива действий).
Ну и самое главное, что нужно сделать перед внедрением любого изменения - определить спонсора изменения, если у вас нет спонсора , то у вас 30% на успех внедрения изменения.
Рассказывайте в комментариях по какой модели вы внедряете изменения?)
#adkar #изменения #deliverymanager
Как я уже писал ранее Delivery Manager - это менеджер изменений, который приносит в компанию/команду новые изменения и внедряет их.
Сегодня обсудим, как осуществлять эти изменения
Когда вы пытаетесь внедрить какие либо изменения, то скорее всего вы сталкиваетесь с большим сопротивлением со стороны участников этих изменений.
Чтобы минимизировать это сопротивление, можно использовать популярную модель управления изменениями ADKAR, разработанную компанией Prosci.
ADKAR включает пять ключевых элементов для успешного внедрения изменений.
Каждая буква в акрониме обозначает одну из стадий:
A - Awareness (Осведомлённость): Понимание необходимости изменений и осознание причин, по которым они необходимы. Какую проблему решаем и какой профит получит команда/компания.
D - Desire (Желание): Стремление поддерживать изменения и участвовать в процессе.
K - Knowledge (Знание): Осознание того, как именно будут реализованы изменения и какие навыки нужны для этого.
A - Ability (Способность): Практическое применение знаний и навыков для реализации изменений.
R - Reinforcement (Подкрепление): Устойчивое внедрение изменений в организационную культуру и признание успехов.
Для внедрения изменений необходимо пройти три фазы:
1.Подготовка изменений: включает осведомлённость и желание.
2.Управление изменениями: включает знание и способность.
3.Закрепление изменений: включает окончательную стадию — подкрепление.
Чтобы начать процесс внедрения по модели ADKAR или другой, важно понять, какую проблему вы решаете, и вовлечь команду.
Этот путь проходит через: стресс (метрика, показывающая проблемы в команде) -> рефлексия (встреча для обсуждения решения проблемы) -> лидерство (инициатива действий).
Ну и самое главное, что нужно сделать перед внедрением любого изменения - определить спонсора изменения, если у вас нет спонсора , то у вас 30% на успех внедрения изменения.
Рассказывайте в комментариях по какой модели вы внедряете изменения?)
#adkar #изменения #deliverymanager
👍5🔥4❤3😁1
Всем успешной доставки!
Несколько постов назад, я писал про Канбан метод.
Если вы планируете его внедрять, вам необходимо использовать подход STATIK. Сегодня расскажу подробней про него.
🟢 STATIK- подход, который упрощает внедрение Канбана в команды. Он включает совместные встречи для анализа и совершенствования процессов, что позволяет всем участникам команды работать более эффективно. Этот подход также акцентирует внимание на адаптации инструментов в зависимости от нужд команды.
Основные этапы:
1. Сбор информации:
-Определите ключевых участников и заинтересованных лиц.
-Соберите данные о текущем процессе, включая объем работы, детали задач и временные затраты.
- Определите источники неудовлетворенности
2. Определение текущих процессов:
-Проанализируйте, как работа выполняется в данный момент.
-Используйте визуализацию потоков работы, чтобы понять шаги, которые проходят задачи.
3. Выявление ограничений:
-Найдите и проанализируйте проблемы или узкие места в текущем процессе.
-Сосредоточьтесь на том, что можно улучшить для повышения эффективности.
4. Создание модели потока работы:
-Постройте визуальную карту вашего процесса (можно попробовать VSM), включая все этапы, от начала до завершения работы.
-Это поможет команде увидеть полную картину и принять более обоснованные решения.
5. Определение параметров управления:
-Установите лимиты на количество задач на каждом этапе (Work In Progress, WIP).
-Определите ключевые показатели эффективности (KPI) для мониторинга работы команды.
-Обсудите какие классы обслуживания есть в вашей команде
6. Реализация изменений:
-Запустите Канбан доску
-Обучите команду новым процессам и инструментам.
7. Мониторинг и корректировка:
-Периодически пересматривайте и корректируйте процессы на основании обратной связи и данных.
-Постоянное улучшение должно стать частью культуры команды.
STATIK можно проводить тремя способами:
1.Воркшоп - cоберите всю команду в одном месте (онлайн или офлайн) для обсуждения всех вопросов.
Плюсы: Полное вовлечение команды и обсуждение всех аспектов.
Минусы: Требует 10-16 часов работы всей команды, что может затормозить выполнение задач.
2.Персональный сбор информации через интервью - проводите индивидуальные интервью с участниками для сбора информации.
Плюсы такого способа: не отвлекает всю команду на длительное время
Минусы такого способа: участники могут не чувствовать вовлеченности и сопротивляться изменениям.
3.Персональное построение канбан-системы менеджером изменений/руководителем - информация собирается из документации и базы знаний без участия всей команды.
Плюсы такого способа: команда не отвлекается.
Минусы такого способа: не вся информация есть в документации и базе знаний, команда будет сопротивляться, так как не принимала участие в этих изменениях.
Не начинайте внедрение Канбан метода без проведения Statik!🍌
#Kanban #STATIK
Несколько постов назад, я писал про Канбан метод.
Если вы планируете его внедрять, вам необходимо использовать подход STATIK. Сегодня расскажу подробней про него.
Основные этапы:
1. Сбор информации:
-Определите ключевых участников и заинтересованных лиц.
-Соберите данные о текущем процессе, включая объем работы, детали задач и временные затраты.
- Определите источники неудовлетворенности
2. Определение текущих процессов:
-Проанализируйте, как работа выполняется в данный момент.
-Используйте визуализацию потоков работы, чтобы понять шаги, которые проходят задачи.
3. Выявление ограничений:
-Найдите и проанализируйте проблемы или узкие места в текущем процессе.
-Сосредоточьтесь на том, что можно улучшить для повышения эффективности.
4. Создание модели потока работы:
-Постройте визуальную карту вашего процесса (можно попробовать VSM), включая все этапы, от начала до завершения работы.
-Это поможет команде увидеть полную картину и принять более обоснованные решения.
5. Определение параметров управления:
-Установите лимиты на количество задач на каждом этапе (Work In Progress, WIP).
-Определите ключевые показатели эффективности (KPI) для мониторинга работы команды.
-Обсудите какие классы обслуживания есть в вашей команде
6. Реализация изменений:
-Запустите Канбан доску
-Обучите команду новым процессам и инструментам.
7. Мониторинг и корректировка:
-Периодически пересматривайте и корректируйте процессы на основании обратной связи и данных.
-Постоянное улучшение должно стать частью культуры команды.
STATIK можно проводить тремя способами:
1.Воркшоп - cоберите всю команду в одном месте (онлайн или офлайн) для обсуждения всех вопросов.
Плюсы: Полное вовлечение команды и обсуждение всех аспектов.
Минусы: Требует 10-16 часов работы всей команды, что может затормозить выполнение задач.
2.Персональный сбор информации через интервью - проводите индивидуальные интервью с участниками для сбора информации.
Плюсы такого способа: не отвлекает всю команду на длительное время
Минусы такого способа: участники могут не чувствовать вовлеченности и сопротивляться изменениям.
3.Персональное построение канбан-системы менеджером изменений/руководителем - информация собирается из документации и базы знаний без участия всей команды.
Плюсы такого способа: команда не отвлекается.
Минусы такого способа: не вся информация есть в документации и базе знаний, команда будет сопротивляться, так как не принимала участие в этих изменениях.
Не начинайте внедрение Канбан метода без проведения Statik!
#Kanban #STATIK
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7❤2👍1
Всем успешной доставки! Для эксперимента я решил сделать дайджест постов за октябрь.
В этом месяце вышло 5 постов:
1.Как мне кажется, самый холиварный и самый просматриваемый пост (200 просмотров) - Оценка задач в story pointах/часах/попугаях не нужна.
2.Интересная тема - ADKAR, как внедрять изменения.
3.Трудная для восприятия тема - ЗВК (запрос в команду) с которым я выступал на конференции в Ижевске.
4.Самая базовая информация - STATIK в Канбан методе.
5.Небольшой итог по каналу за 2 месяц, на момент написания поста было 95 подписчиков, а сегодня уже 116 🚀
Если вы еще не видели эти посты, то стоит обратить внимание 😎
Новые посты уже на подходе в ноябре, темы будут интересны!
В этом месяце вышло 5 постов:
1.Как мне кажется, самый холиварный и самый просматриваемый пост (200 просмотров) - Оценка задач в story pointах/часах/попугаях не нужна.
2.Интересная тема - ADKAR, как внедрять изменения.
3.Трудная для восприятия тема - ЗВК (запрос в команду) с которым я выступал на конференции в Ижевске.
4.Самая базовая информация - STATIK в Канбан методе.
5.Небольшой итог по каналу за 2 месяц, на момент написания поста было 95 подписчиков, а сегодня уже 116 🚀
Если вы еще не видели эти посты, то стоит обратить внимание 😎
Новые посты уже на подходе в ноябре, темы будут интересны!
🔥8👍2❤1
Всем успешной доставки! Давайте снова обсудим визуализацию end-to-end процесса.
Ранее уже писал пост про discovery и delivery , ЗВК и продуктовые эпики . Важно не только визуализировать процесс доставки ценности клиенту, но и грамотно с ним работать.
Сегодня хочу вам рассказать про "продуктовый эпик (ПЭ)", у вас в компании он может называться по другому.
ПЭ - это сущность, с которой работает продакт на всем end-to-end процессе, от discovery и до delivery, представляющая собой ценность (фичу), которую нужно доставить клиенту.
На этапе discovery ПЭ проходит этапы определение проблемы, валидация гипотез решения и защита 1 pagerа
ПЭ необходим для:
1. Фокусировки на потребностях клиента.
2. Отслеживания эффективности продукта:
* Мы доставляем то, что нужно клиенту.
* Скорость доставки ценности.
* Улучшение процессов доставки ценности.
3. Правильного распределения нагрузки среди команд разработки. Если у вас три команды, работающие над одним ПЭ, достаточно его декомпозировать на три подзадач
Основное правило ПЭ, он всегда должен быть один.
Нельзя делить ПЭ на платформы (например IOS и Android) или на части функционала, так как ценность надо доставить для всех клиентов, не зависимо от платформы.
У ПЭ могут быть разные типы работ, если вы как продукт делаете не только фичи, но и какую-то другую работу (например проводить качественные или количественные исследования), то можете отразить это в поле ПЭ и выбрать нужный тип работ.
Как внедрить:
1.Визуализировать весь end-to-end процесс
2.Определить флоу для этапов discovery и delivery
3.Определить типы работ для ПЭ, если такие имеются
4.Внедрить метрики на ПЭ, такие как ТТМ, пропускная способность.
Ранее уже писал пост про discovery и delivery , ЗВК и продуктовые эпики . Важно не только визуализировать процесс доставки ценности клиенту, но и грамотно с ним работать.
Сегодня хочу вам рассказать про "продуктовый эпик (ПЭ)", у вас в компании он может называться по другому.
ПЭ - это сущность, с которой работает продакт на всем end-to-end процессе, от discovery и до delivery, представляющая собой ценность (фичу), которую нужно доставить клиенту.
На этапе discovery ПЭ проходит этапы определение проблемы, валидация гипотез решения и защита 1 pagerа
ПЭ необходим для:
1. Фокусировки на потребностях клиента.
2. Отслеживания эффективности продукта:
* Мы доставляем то, что нужно клиенту.
* Скорость доставки ценности.
* Улучшение процессов доставки ценности.
3. Правильного распределения нагрузки среди команд разработки. Если у вас три команды, работающие над одним ПЭ, достаточно его декомпозировать на три подзадач
Основное правило ПЭ, он всегда должен быть один.
Нельзя делить ПЭ на платформы (например IOS и Android) или на части функционала, так как ценность надо доставить для всех клиентов, не зависимо от платформы.
У ПЭ могут быть разные типы работ, если вы как продукт делаете не только фичи, но и какую-то другую работу (например проводить качественные или количественные исследования), то можете отразить это в поле ПЭ и выбрать нужный тип работ.
Как внедрить:
1.Визуализировать весь end-to-end процесс
2.Определить флоу для этапов discovery и delivery
3.Определить типы работ для ПЭ, если такие имеются
4.Внедрить метрики на ПЭ, такие как ТТМ, пропускная способность.
🔥5👍2❤1
Всем успешной доставки!
Сегодня хочу рассказать вам про одну полезную практику, которую вы можете внедрить в свои команды, если, конечно, еще не внедрили.
Практика называется "3 Амиго" 😂, представляют собой подход к разработке, который фокусируется на тесном сотрудничестве между тремя ключевыми ролями:
-бизнес-аналитиком(у вас он может называться по другому, тот кто придумал фичу и написал тз),
-разработчиком
-тестировщиком
В основном это встреча на троих, где вышеперечисленные роли обсуждают фичу, которую планируют взять в работу; такие встречи проходят до точки принятия обязательств, чтобы найти все подводные камни и вести разработку без дополнительных вопросов.
Как это работает:
Совместные обсуждения требований: Все три роли собираются на встречи, чтобы обсудить требования, что способствует лучшему пониманию и выявлению неполных или противоречивых требований еще на начальном этапе.
Создание спецификаций: Вместе они могут разрабатывать Acceptance Criteria (критерии приемки), которые служат основой для тестирования и проверки готовности продукта.
Проверка понимания: Каждая роль может задавать вопросы и вносить предложения, что увеличивает шансы на окончательное согласование требований.
Обратная связь: Регулярные встречи позволяют участникам делиться обратной связью о процессе и достигнутых результатах, что способствует постоянному улучшению
Зачем нужно?
Нужно это для того, чтобы сократить количество недоразумений после взятия фичи в работу и повысить качество продукта, так как все участники процесса работают как единая команда, направленная на достижение общих целей.
#3amigo #3амиго
Сегодня хочу рассказать вам про одну полезную практику, которую вы можете внедрить в свои команды, если, конечно, еще не внедрили.
Практика называется "3 Амиго" 😂, представляют собой подход к разработке, который фокусируется на тесном сотрудничестве между тремя ключевыми ролями:
-бизнес-аналитиком(у вас он может называться по другому, тот кто придумал фичу и написал тз),
-разработчиком
-тестировщиком
В основном это встреча на троих, где вышеперечисленные роли обсуждают фичу, которую планируют взять в работу; такие встречи проходят до точки принятия обязательств, чтобы найти все подводные камни и вести разработку без дополнительных вопросов.
Как это работает:
Совместные обсуждения требований: Все три роли собираются на встречи, чтобы обсудить требования, что способствует лучшему пониманию и выявлению неполных или противоречивых требований еще на начальном этапе.
Создание спецификаций: Вместе они могут разрабатывать Acceptance Criteria (критерии приемки), которые служат основой для тестирования и проверки готовности продукта.
Проверка понимания: Каждая роль может задавать вопросы и вносить предложения, что увеличивает шансы на окончательное согласование требований.
Обратная связь: Регулярные встречи позволяют участникам делиться обратной связью о процессе и достигнутых результатах, что способствует постоянному улучшению
Зачем нужно?
Нужно это для того, чтобы сократить количество недоразумений после взятия фичи в работу и повысить качество продукта, так как все участники процесса работают как единая команда, направленная на достижение общих целей.
#3amigo #3амиго
🔥8❤1
Всем успешной доставки!
Давайте представим, что у вас уже зрелые команды: отличная визуализация, настроены WIP лимиты, написаны DOR/DOD/AC на каждом этапе производства.
Как еще можно ускорить доставку ценности?
Сегодня поговорим про работу с заблокированными задачами. Если задача заблокирована, она занимает больше времени, что увеличивает метрики Time to market и Lead time, снижает пропускную способность команды и в целом увеличивает время доставки до клиента.
Как анализировать заблокированные задачи?
1.Начните с указания причины блокировки. Если вы используете Jira, при блокировке задачи (когда добавляете флаг) всегда указывайте причину: блокировка другой командой, отсутствие ресурсов или технические ограничения (причины могут быть разные). Главное прийти к "jira гигиене", всегда пишем причину блокировки, обсудите это с командой на ретро, зафиксируйте в документации.
2.Когда команда научилась всегда ставить причину блокировок, надо проанализировать сколько блокировок у вас возникает в единицу времени (например месяц), это позволит понять, а есть ли у вас проблема с заблокированными задачами, может вы супер крутые и ничего у вас не блокируется.👍
3.Если проблема подтверждена, классифицируйте блокировки и найдите "низко висящие фрукты" — проблемы, которые можно решить быстро. Например, если вас часто блокирует соседняя команда, соберите факты (количество блокировок) и обсудите с ними, как избежать этого.
4.Регулярно обозревайте заблокированные задачи. Лучше всего делать это на отдельной встрече (например, на обзоре потока или метрик), но можно начать с дейли команды, выделяя заблокированные задачи и решая проблемы всей командой.
5.Автоматизируйте отчет, который собирает все заблокированные задачи и на основе ИИ (просто предложение) классифицирует причины блокировок. 😎
6.Стремитесь к процессу доставки, при котором задачи не блокируются, но это, похоже, из идеального мира.
Давайте представим, что у вас уже зрелые команды: отличная визуализация, настроены WIP лимиты, написаны DOR/DOD/AC на каждом этапе производства.
Как еще можно ускорить доставку ценности?
Сегодня поговорим про работу с заблокированными задачами. Если задача заблокирована, она занимает больше времени, что увеличивает метрики Time to market и Lead time, снижает пропускную способность команды и в целом увеличивает время доставки до клиента.
Как анализировать заблокированные задачи?
1.Начните с указания причины блокировки. Если вы используете Jira, при блокировке задачи (когда добавляете флаг) всегда указывайте причину: блокировка другой командой, отсутствие ресурсов или технические ограничения (причины могут быть разные). Главное прийти к "jira гигиене", всегда пишем причину блокировки, обсудите это с командой на ретро, зафиксируйте в документации.
2.Когда команда научилась всегда ставить причину блокировок, надо проанализировать сколько блокировок у вас возникает в единицу времени (например месяц), это позволит понять, а есть ли у вас проблема с заблокированными задачами, может вы супер крутые и ничего у вас не блокируется.
3.Если проблема подтверждена, классифицируйте блокировки и найдите "низко висящие фрукты" — проблемы, которые можно решить быстро. Например, если вас часто блокирует соседняя команда, соберите факты (количество блокировок) и обсудите с ними, как избежать этого.
4.Регулярно обозревайте заблокированные задачи. Лучше всего делать это на отдельной встрече (например, на обзоре потока или метрик), но можно начать с дейли команды, выделяя заблокированные задачи и решая проблемы всей командой.
5.Автоматизируйте отчет, который собирает все заблокированные задачи и на основе ИИ (просто предложение) классифицирует причины блокировок. 😎
6.Стремитесь к процессу доставки, при котором задачи не блокируются, но это, похоже, из идеального мира.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9❤3🔥1
Всем успешной доставки! До нового года осталось 25 дней, и многие, вероятно, начинают подводить итоги, для этого как раз есть одна полезная практика - ретроспектива 😎
Ретроспектива - это метод анализа и оценки завершённых процессов или проектов, который помогает командам осмыслить пройденный путь, выявить успешные моменты, а так же области для улучшения.
Виды ретроспектив:
Ретроспектива по завершении проекта: Проводится после завершения проекта для оценки его результатов и выявления успешных и проблемных аспектов
Итерационная ретроспектива: Используется для анализа завершенной итерации с целью улучшения будущих итераций.
OKR ретроспектива: Проводится для анализа и оценки результатов работы команды или организации в рамках метода OKR за определенный период, например за квартал.
Тематическая или фокусная ретроспектива: Сосредотачивается на конкретной теме, проблеме или аспекте работы команды, например разбор долгой фичи, которую вы делали больше чем планировали.
Зачем проводить ретроспективу:
Повышение эффективности: Выявление проблем и областей для улучшения позволяет сделать процессы более эффективными.
Обучение и развитие: Позволяет команде учиться на собственных ошибках и достигнутых успехах.
Оптимизация процессов: Помогает выявить неэффективные практики и заменить их более продуктивными.
Многие команды проводят ретроспективы онлайн, и большинство онлайн-досок предлагает шаблоны для этого, например, такой в Unidraw
#retro #unidraw #команда
Ретроспектива - это метод анализа и оценки завершённых процессов или проектов, который помогает командам осмыслить пройденный путь, выявить успешные моменты, а так же области для улучшения.
Виды ретроспектив:
Ретроспектива по завершении проекта: Проводится после завершения проекта для оценки его результатов и выявления успешных и проблемных аспектов
Итерационная ретроспектива: Используется для анализа завершенной итерации с целью улучшения будущих итераций.
OKR ретроспектива: Проводится для анализа и оценки результатов работы команды или организации в рамках метода OKR за определенный период, например за квартал.
Тематическая или фокусная ретроспектива: Сосредотачивается на конкретной теме, проблеме или аспекте работы команды, например разбор долгой фичи, которую вы делали больше чем планировали.
Зачем проводить ретроспективу:
Повышение эффективности: Выявление проблем и областей для улучшения позволяет сделать процессы более эффективными.
Обучение и развитие: Позволяет команде учиться на собственных ошибках и достигнутых успехах.
Оптимизация процессов: Помогает выявить неэффективные практики и заменить их более продуктивными.
Многие команды проводят ретроспективы онлайн, и большинство онлайн-досок предлагает шаблоны для этого, например, такой в Unidraw
#retro #unidraw #команда
🔥7❤1👍1
Всем успешной доставки!
Agile мертв🆘 Недавно в Linkedin (нужен VPN для доступа) появилось интересное обсуждение, которое собрало почти 72 тысячи лайков и 5 тысяч комментариев.
Основная идея поста заключается в том, что Agile мертв по следующим причинам:
1. Agile стал чек-листом вместо философии.
2. Масштабирование происходило без изменения культуры.
3. Ориентация на быструю реализацию проектов заменяет фокус на качестве и реальной ценности.
4. Сопротивление со стороны руководства.
5. Agile превратился в продукт.
6. Игнорирование человеческого фактора привело к выгоранию и снижению вовлеченности.
Некоторые тезисы кажутся справедливыми, но утверждение "Agile мертв" вызывает у меня сомнения.
Как дела обстоят в вашей компании или команде? Agile у вас мертв или все же жив? 😎
#agile #scrum #kanban
Agile мертв
Основная идея поста заключается в том, что Agile мертв по следующим причинам:
1. Agile стал чек-листом вместо философии.
2. Масштабирование происходило без изменения культуры.
3. Ориентация на быструю реализацию проектов заменяет фокус на качестве и реальной ценности.
4. Сопротивление со стороны руководства.
5. Agile превратился в продукт.
6. Игнорирование человеческого фактора привело к выгоранию и снижению вовлеченности.
Некоторые тезисы кажутся справедливыми, но утверждение "Agile мертв" вызывает у меня сомнения.
Как дела обстоят в вашей компании или команде? Agile у вас мертв или все же жив? 😎
#agile #scrum #kanban
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4🤔2❤1
This media is not supported in your browser
VIEW IN TELEGRAM
Не обижайте ДМов 🤣
мем украл из канала https://news.1rj.ru/str/OgileKambanScram
мем украл из канала https://news.1rj.ru/str/OgileKambanScram
😁5❤2👍1
Всем успешной доставки!
После подведения итогов разумно подумать о планах на следующий год, для чего поможет методология OKR (Objectives and Key Results).
OKR — это методология управления целями, которая помогает организациям и командам устанавливать и отслеживать амбициозные цели (Objectives) и ключевые результаты (Key Results), используемые для оценки прогресса и достижения этих целей. Этот подход обеспечивает фокус, прозрачность и согласованность в работе, мотивируя команды достигать значимых результатов.
Objectives (Цели): Это амбициозные, четко сформулированные цели, которые определяют, чего именно вы хотите достичь. Они должны быть вдохновляющими и понятными всей команде.
Например: Увеличить удовлетворенность клиентов в нашем онлайн-магазине.
Key Results (Ключевые результаты): Это конкретные и измеримые результаты, которые показывают, как будет оцениваться достижение каждой цели. Они должны быть количественными и четко определять, каков успех.
Например:
-Увеличить общий рейтинг клиентских отзывов с 4.2 до 4.7.
-Сократить среднее время ответа службы поддержки на обращения клиентов до 1 часа.
-Повысить уровень повторных покупок с 25% до 35% в течение квартала.
-Провести 3 опроса удовлетворенности клиентов и получить минимум 500 ответов на каждый.
Теперь совместим OKR и KR и получим:
Амбициозная цель: Увеличить удовлетворенность клиентов в нашем онлайн-магазине
Как мы эту цель будем достигать:
-Увеличить общий рейтинг клиентских отзывов с 4.2 до 4.7.
-Сократить среднее время ответа службы поддержки на обращения клиентов до 1 часа.
-Повысить уровень повторных покупок с 25% до 35% в течение квартала.
-Провести 3 опроса удовлетворенности клиентов и получить минимум 500 ответов на каждый.
OKR обычно планируется на определенные временные периоды, наиболее распространённые из которых:
1. Квартал: Это самый популярный срок для OKR. Четыре раза в год команда устанавливает новые цели и ключевые результаты, что позволяет оставаться гибкими и адаптироваться к изменениям.
2. Год: Некоторые компании устанавливают годовые OKR, особенно для стратегических целей, которые требуют более длительного времени для достижения.
3. Месяц: В некоторых случаях OKR могут быть установлены на месячный срок, особенно в динамичных или стартап-средах, где изменения происходят очень быстро.
В OKR существуют несколько регулярных каденций, которые помогают эффективно управлять процессом установки и отслеживания целей. Основные из них:
Квартальная каденция: Наиболее распространенный вариант, при котором команды устанавливают OKR на квартал. В конце квартала они оценивают достижения OKR и при необходимости корректируют цели на следующий квартал.
Месячная проверка (OKR Chek-in): Часто в рамках квартальных OKR команды проводят ежемесячные проверки для оценки текущего прогресса по KR и при необходимости корректировки действий.
Итоговая оценка: В конце цикла (квартал или год) команды подводят итоги, анализируют достижения и определяют что можно улучшить в будущих OKR.
Если хочется более детально погрузиться в OKR, то можно заказать книгу "Цели и ключевые результаты. Полное руководство"
Пройти курс обучения у таких ребят как ScrumTrek, Neogenda(советую, так как сам там проходил), Нетология и другие компании.
#OKR #KR #цель
После подведения итогов разумно подумать о планах на следующий год, для чего поможет методология OKR (Objectives and Key Results).
OKR — это методология управления целями, которая помогает организациям и командам устанавливать и отслеживать амбициозные цели (Objectives) и ключевые результаты (Key Results), используемые для оценки прогресса и достижения этих целей. Этот подход обеспечивает фокус, прозрачность и согласованность в работе, мотивируя команды достигать значимых результатов.
Objectives (Цели): Это амбициозные, четко сформулированные цели, которые определяют, чего именно вы хотите достичь. Они должны быть вдохновляющими и понятными всей команде.
Например: Увеличить удовлетворенность клиентов в нашем онлайн-магазине.
Key Results (Ключевые результаты): Это конкретные и измеримые результаты, которые показывают, как будет оцениваться достижение каждой цели. Они должны быть количественными и четко определять, каков успех.
Например:
-Увеличить общий рейтинг клиентских отзывов с 4.2 до 4.7.
-Сократить среднее время ответа службы поддержки на обращения клиентов до 1 часа.
-Повысить уровень повторных покупок с 25% до 35% в течение квартала.
-Провести 3 опроса удовлетворенности клиентов и получить минимум 500 ответов на каждый.
Теперь совместим OKR и KR и получим:
Амбициозная цель: Увеличить удовлетворенность клиентов в нашем онлайн-магазине
Как мы эту цель будем достигать:
-Увеличить общий рейтинг клиентских отзывов с 4.2 до 4.7.
-Сократить среднее время ответа службы поддержки на обращения клиентов до 1 часа.
-Повысить уровень повторных покупок с 25% до 35% в течение квартала.
-Провести 3 опроса удовлетворенности клиентов и получить минимум 500 ответов на каждый.
OKR обычно планируется на определенные временные периоды, наиболее распространённые из которых:
1. Квартал: Это самый популярный срок для OKR. Четыре раза в год команда устанавливает новые цели и ключевые результаты, что позволяет оставаться гибкими и адаптироваться к изменениям.
2. Год: Некоторые компании устанавливают годовые OKR, особенно для стратегических целей, которые требуют более длительного времени для достижения.
3. Месяц: В некоторых случаях OKR могут быть установлены на месячный срок, особенно в динамичных или стартап-средах, где изменения происходят очень быстро.
В OKR существуют несколько регулярных каденций, которые помогают эффективно управлять процессом установки и отслеживания целей. Основные из них:
Квартальная каденция: Наиболее распространенный вариант, при котором команды устанавливают OKR на квартал. В конце квартала они оценивают достижения OKR и при необходимости корректируют цели на следующий квартал.
Месячная проверка (OKR Chek-in): Часто в рамках квартальных OKR команды проводят ежемесячные проверки для оценки текущего прогресса по KR и при необходимости корректировки действий.
Итоговая оценка: В конце цикла (квартал или год) команды подводят итоги, анализируют достижения и определяют что можно улучшить в будущих OKR.
Если хочется более детально погрузиться в OKR, то можно заказать книгу "Цели и ключевые результаты. Полное руководство"
Пройти курс обучения у таких ребят как ScrumTrek, Neogenda(советую, так как сам там проходил), Нетология и другие компании.
#OKR #KR #цель
👍4🔥2❤1