Всем успешной доставки!
Давайте обсудим, какими инструментами пользуется Delivery Manager?.Данный пост поделю на несколько частей, чтобы затронуть все аспекты.

Часть 1.
На самом деле ни какого rocket science🚀 тут нет, инструменты обычные и всем вам знакомые.
Начнем с Task manager/Сервис для управления задачами:

Всемогущая Jira, наверное каждый из нас сталкивался с этим гигантом, кто-то любит jira, кто-то ее не ненавидит 😎

Jira удобна тем, что в ней можно визуализировать любой процесс доставки, сделать различную автоматизацию(хотя не без боли),отслеживать прогресс по крупным проектам/задачам(jira structure), есть встроенная отчетность которую можно анализировать(диаграмма Control Chart).
Так как Jira очень популярна, для нее есть различные jira плагины для браузера(Google Chrome), позволяющие добавлять новый функционал:

**Jira helper**
Имеет достаточно большой функционал:
-Настройка wip-лимитов для: значений полей с учетом их количества, значений полей с суммой величин (для примера Story Points), ячеек (пересечение Swimlanes и Колонок), индивидуальный лимит.
-Ограничение задач для нескольких колонок
-Размытие конфиденциальных данных
Есть канал в телеграм куда можно задавать вопросы https://news.1rj.ru/str/jirahelper

**Jira-extension** отслеживание прогресса подзадач,
возможность отслеживать прогресс по эпикам и сабтаскам прямо на карточке эпика или задачи с помощью наглядной визуализации: все подзадачи группируются по проектам и отрисовывается progressbar, в котором есть цветовая индикация прогресса.

**Jira metrics plugin** плагин для анализа процессных метрик, позволяет настраивать и смотреть различные метрики, у ребят есть телеграм канал https://news.1rj.ru/str/JiraMetrics где можно задать вопросы

Пишите в комментарии какие вы еще знаете крутые плагины для Jira ✍️
#deliverymanager #jira #metrics

Всем успешной доставки! Сегодня хочется поговорить про два этапа производства: discovery и delivery.

Этап 1: Discovery (Исследование)🪩
На данном этапе происходит выявление потребностей пользователя: это ключевой момент.
Нужно понять, для кого вы создаете продукт, какие у них болевые точки и как ваш продукт может помочь их решить.
Исследование целевой аудитории помогает выявить реальные потребности и делать только те фичи которые нужны клиенту.
После подтверждения, что данная фича нужна клиенту и вы сможете на ней заработать, необходимо сформировать требования к продукту(тз или спецификацию). Это может быть как функциональные, так и нефункциональные требования.

Этап 2: Delivery (Доставка)🚚
После того, как этап Discovery завершен и у вас есть четкое понимание того, что и как нужно разрабатывать, начинается этап Delivery. Этот этап фокусируется на реализации и доставке готового продукта. Delivery поделен на 4 подэтапа:
Разработка: команда разработки начинает работу над продуктом в соответствии с требованиями, определенными на этапе Discovery.
Тестирование: На этом этапе проводится тестирование, чтобы убедиться, что продукт соответствует требованиям и работает без ошибок.
Релиз: После успешного тестирования продукт выходит на рынок. Это может быть полное развёртывание или phased rollout (поэтапное развертывание), когда продукт доступен сначала для ограниченного числа пользователей.
Сбор обратной связи: Важно не только выпустить продукт, но и собрать обратную связь от пользователей. Это поможет оценить, насколько продукт соответствует ожиданиям, и выявить возможные улучшения.

Резюмирую: discovey и delivery очень важные, если какой-то из этапов пропустить или сделать не до конца, на выходе можем получить фичу которой никто пользоваться не будет. Если данные этапы у вас в компании/команде еще не визуализированы, то кажется, это первое, что надо сделать.
Пишите в комментариях, какие этапы у вас визуализированы, какие метрики смотрите на каждом этапе?

Всем успешной доставки! Мы уже с вами определили два этапа производства: discovery и delivery; на данных этапах ключевая роль для оптимизации процессов отводится метрикам, метрикам производства.

Метрики нужны, чтобы определить узкие места и неэффективности в производственном процессе. Как только мы понимаем, где у нас узкое горлышко, то пол работы уже сделано😂, осталось его только устранить.
Так же метрики позволяют принимать решения, основываясь на фактической информации(метрики собраны по завершенным задачам, и это факт, а не прогноз), а не на интуиции 😎.

Чтобы понять, как вы эффективно производите и доставляете ценность до клиента, я бы предложил сначала внедрить следующие метрики:
1.Time to market - показывает, сколько времени требуется для разработки продукта и его выхода на рынок. Быстрый вывод продукта позволяет компании занять лидирующие позиции в своей нише и оперативно реагировать на изменения в потребительских предпочтениях.

2.Lead time - это время, которое требуется для выполнения процесса (или ряда процессов) от момента принятия заказа до момента его доставки клиенту. В IT lead time в основном начинает считаться от момента принятия обязательства сделать эту задачу.

3.Throughput/Пропускная способность - метрика, которая показывает, какой объем работы ваша команда может выполнить за единицу времени(год, квартал, месяц).

4.Wiprate (Work In Progress Rate) - это метрика позволяет видеть долю времени, сколько задачи находились в работе, а так же смотреть эти задачам по типам работ и понимать, на какие типы работ больше всего тратится времени.

Конечно, есть еще и другие метрики, но начать внедрять метрики можно с вышеперечисленных.
В каждом task-менеджере есть внутренние инструменты, которые позволяют настраивать эти метрики, для той же jira есть отдельные плагины(про которые я писал в предыдущем посте), если у вашего task менеджера нет встроенных инструментов для подсчета метрик, наверное это первый сигнал, чтобы сменить его.

После настройки метрик их надо регулярно обозревать с командой, чтобы команда понимала как считаются метрики, на что эти метрики влияют, как команда может влиять на метрики.

Для команды метрики служат инструментом улучшения своих процессов, команда должна понимать, что за "плохие" метрики их не накажут и не будут сравнивать с другими командами.

Какие метрики вы уже считаете у себя в командах?✍️

Всем успешной доставки! Ранее я обсуждал два этапа производства: discovery и delivery. Сегодня сосредоточимся на этапе Discovery 🪩 и его важности.
Discovery представляет собой процесс выявления потребностей клиента, который является ключевым моментом.
Необходимо понять, для кого вы создаете продукт, какие у клиентов есть болевые точки и как ваш продукт может их решить.

Представьте, что вы разрабатываете фичу пол года, тратите ресурсы (деньги) аналитика, дизайнера, разработки и тестирования, а после релиза вашей фичей ни кто не пользуется или пользуется меньше клиентов чем вы планировали, выглядит не очень классно?

Поэтому этап Discovery это непрерывный процесс уменьшения неопределенности и рисков при принятии решений через проверку гипотез о проблемах и возможных решениях.

Есть интересная методология Triple diamond 🚀, которая ясно описывает, как продуктовая команда должна действовать на этапе Discovery:
1.Команда получает сигналы о возникшей проблеме - источником может быть: обращение в поддержку, аналитика продукта, интервью клиентов, анализ конкурентов и трендов, различные исследования (NPS, CSAT)
2.Формулирует суть проблемы
3.Проверяет, что проблема действительно есть
4.Приоритизирует проблему среди уже существующих проблем
5.Генерирует возможные решения этой проблемы
6.Валидирует решения проблемы - различные исследования, опросы, mvp, UX тестирование, A/B тесты

Только после этого начинается этап Delivery 🚚, где осуществляется разработка и внедрение выбранного решения для клиентов.

Чеклист, чтобы проверить, эффективен ли ваш процесс Discovery:
1.Решаете проблемы клиентов, а не выполняете задачи просто ради задач
2.Все решения принимаются на основе полученных данных, а не интуиции 🤣
3.Этапы discovery — delivery у вас непрерывны

Резюмирую: чтобы этот процесс функционировал эффективно и без сбоев, продуктовой команде необходимо находиться в постоянном цикле «discovery — delivery». Этот цикл способствует экономии ресурсов и предотвращает внедрение некорректных решений на клиентов.

Всем успешной доставки! Давайте обсудим Kanban и его роль в доставке ценности клиенту. Существует множество мифов о Kanban, включая:
-Это конвейер
-Он подходит только для команд поддержки
-Это всего лишь Kanban-доска.

В сети можно встретить различные определения Kanban, для себя выбрал следующее:
Kanban метод - способ улучшения производственных процессов, предусматривающих значительное использование умственного труда.

Как Kanban помогает в доставке ценности? Соблюдая основные принципы и практики Kanban, можно организовать полный процесс (discovery&delivery) доставки ценности, сосредоточиться на важных задачах и непрерывно улучшать процесс:

Принципы:
-Начните с того, что сейчас есть - уважайте результаты которые есть сейчас
-Договоритесь об эволюционном развитие - не делайте сразу много изменений
-Поощряйте проявление лидерства - терпимость к ошибкам

Практики:
-Визуализация процесса производства - отображайте работу и ее поток
-Ограничение количества незавершенной работы (wip лимиты) - перестаньте начинать, начните заканчивать
-Управление потоком - управляйте потоком, чтобы он был плавным и предсказуемым
-Делайте правила явными - создавайте согласованные правила работы, видимые для всех участников
-Использовать петли обратной связи - встречи по обзору вашего сервиса
-Совместное развитие на основании моделей и научного подхода - изменения основанные на гипотезах, проводите контролируемые эксперименты

Основные метрики Kanban:
Время выполнения - время за которое элемент проходит систему от точки принятия обязательства (комитмент) до полного завершения.
Пропускная способность - количество выполненных элементов за единицу времени
Wip (работа в процессе) - количество рабочих элементов в системе в конкретный момент времени
Существует и множество других метрик, но для начала используйте эти три.

Основной посыл который хочется донести в этом посте: рассматривайте для себя Kanban как набор инструментов для анализа и улучшения процессов!

Если вы еще не перешли на Kanban, то это фатальная ошибка 🤣

При подготовке поста использовал:
Книга Алексея Пименова Канбан Метод. Базовая практика
Официальное руководство по Канбан-методу

Всем успешной доставки! Продолжая тему Kanban и доставку ценности, хочу поделиться полезными ссылками на материалы, каналы и конференции, связанные с Kanban.

Конференции, где можно послушать про Kanban/Agile/Прости господи Scrum 🤔
Flow Days  проходит с 2019 года. В прошлом году была отдельная секция про Kanban, следующая конференция состоится 13 сентября 2024.✅
Agile Days  проходит с 2008 года, предлагает свежие кейсы, мини-тренинги и возможность сетевого общения с экспертами.✅

Телеграм-каналы о Kanban и смежных темах:
Kanban Talks самый популярный канал про Kanban в СНГ
Алексей Пименов канал о Kanban и внедрении изменений.
T-Process Improvement про внедрение изменений от Т-Банка
Kanban Events анонсы платных и бесплатных Канбан-событий

Компании, проводящие обучение Kanban:
Neogenda
Scrumtrek

Что еще полезного можно было добавить в пост?

Всем успешной доставки!
🆘Всю неделю буду в командировке и трудно будет писать новые посты.
Но я уже составил список следующих тем:

1.визуализация, wip лимиты и буферные статусы
2. Dor/Dod/Ac
3. 1 на 1 и ретро команды

Попытаюсь кратко описать какие проблемы помогают решать эти практики и как их внедрить у себя в командах.

Всем успешной доставки! Сегодня обсудим практики Kanban: визуализацию, WIP-лимиты и буферные статусы.
Более детально про каждую практику:

1.Визуализация - помогает команде/заказчику видеть текущий статус работы.
Отображает нагрузку - команды могут увидеть, где возникают узкие места и как распределена работа между членами команды.
Повышает прозрачность - все участники команды/заказчики могут легко отслеживать прогресс выполнения любой задачи.

2.Wip лимиты -это ограничения на количество задач в каждой стадии рабочего процесса.
Они снижают многозадачность и позволяют команде сосредоточиться на завершении текущей работы.
Wip лимиты бывают:
-персональные
-на рабочий процесс CONWIP
-на команду
-на агрегированную доску сервиса
Запомните: "Перестаньте начинать, начните заканчивать."

3.Буферные статусы - обозначают промежуточные состояния задач (например, ожидание тестирования). Они помогают управлять переходами между стадиями (например, от завершения разработки к тестированию).
Если кто-то закончил работу-это не значит, что кто-то другой начал ее.

Начинать внедрять эти практики надо с визуализации, более детальная визуализация помогает видеть весь процесс производства.
Если у вас доска состоит из трех столбцов: готов к работе, в работе, выполнено, то такая визуализация не отвечает на вопрос, что происходит с задачей, но это все равно лучше, чем ничего 😄
В момент визуализации вашей работы, не забывайте про буферные статусы, они четко смогут подсветить, где у вас возникают узкие горлышки.

После визуализации определите WIP-лимиты. Начните с персональных лимитов для каждого участника, а по мере повышения зрелости команды пересмотрите их.

Вроде получилось кратко, не забывайте, визуализацию, wip лимиты и буферные статусы можно пересматривать вместе с повышение зрелости команды!🏐

Всем успешной доставки! Вы визуализировали свою работу, внедрили 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:1 встречи и ретроспектива команды.

Раскрою каждую практику отдельно:

1.1:1- индивидуальные встречи между тимлидом (или любым менеджером) и членом команды для обсуждения различных тем, не обязательно связанных с работой.
Зачем нужно тимлиду: позволяет предоставить сотруднику конструктивную обратную связь, наладить доверительные отношения в команде.
Зачем нужно сотруднику: важно понимать как оценивается его работа, как и куда он может расти как профессионал (например составить ИПР), рассказать про свои проблемы, вынести какие-то предложения по своей работе.
Встреча должна быть регулярной и частой, например раз в 1 или 2 недели, обязательной с повесткой и документированием всех договоренностей

2.Ретроспектива - это встреча команды для анализа прошлых результатов: что сделано хорошо, что можно улучшить и какие есть препятствия.
Нужна для того, чтобы собрать обратную связь со всех участников команды, придумать идеи по улучшению работы в команде, вовлечь всех участников команды в работу над внедрением изменений.
Встреча должна быть регулярной, например раз в месяц, для встречи необходима какая-то онлайн доска (писал про доски отдельный пост ссылка на пост) где вы можете стикерами отмечать, что было хорошо и что можно улучшить, фасилитатором встречи может быть любой участник команды.

Обе встречи полезны для раннего выявления проблем в команде или у конкретного человека, что поможет избежать неожиданных увольнений 😎
#ретро #1на1 #команда

🆘Оценка задач в story pointах/часах/попугаях не нужна, всем успешной доставки! Давайте поговорим про оценку задач и почему она не работает 🔥
Оценка - это прогноз ваших работ, производственные метрики такие как 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 #оценка #прогноз #метрики