4 заметки с тегом

перевод

Продвинутая таблица результатов getKanban для большей пользы

перевод статьи Improving GetKanban Scoreboards for Deeper Learning from the Game от Алексея Жеглова

Мой коллега Дейв Уайт (Dave White) и я получили благодарность за эту нескучную и креативную таблицу результатов, которую мы получили играя в ГетКанбан на одном из наших тренингов.

ГетКанбан ( https://getkanban.com/ )- это популярная игра-симуляция, которая была изобретена Расселом Хэйли (Russell Healy) почти 10 лет назад. С тех пор, она стала уже стандартным инструментом на тренингах, таких как Сertified Kanban System Design (KMP I). Очень много людей, по всему миру, играют в нее на своих региональных митапах, а так же используют ее, как обучающий инструмент внутри своих компаний.

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

Первое, Компании. Слово в верхнем левом углу. Рекомендуем не называть группы, играющими в игру, “командами”, особенно в контексте Северо-Американских корпораций. Четыре группы симулируют четыре компании. Их задача — это по шагам прийти к такому операционному решению, которое было бы направлено на достижение поставленной стратегической цели. Люди, которые описывают себя “участниками команды”, в Северо-Американском корпоративном английском, зачастую имеют недостаточно полномочий. Если вы нашли себя играющим в эту игру на платном Канбан тренинге, убедитесь, что с вами рядом правильные люди.

Второе, четыре колонки. У нас с Дейвом было на тренинге 26 студентов. Мы разделили их на четыре группы по 6 или 7 человек. Так как на каждые две группы нужен один тренер, то мы вели вдвоём. Если будет только один тренер, то увеличение нагрузки с трех до четырех увеличивает загрузку на треть, что означает нелинейное ухудшение реагирования на различные ситуации, проблемы и вопросы, которые возникают в процессе игры. Если вы проводите Канбан тренинг профессионально и собрали аншлаг, то возьмите себе второго тренера или разделите группу. Если вы заказчик Канбан тренинга, то ожидайте и требуйте стандартов и качества от ваших тренеров.

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

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

Четвертое, примеры графиков в строке “цель”. Требуемые значения (красные линии), нарисованы только в правой части графиков, так как их системы не выполняют поставленную цель в начале, но должны достичь ее постепенно, пока не закончилась игра.

Пятое, здесь нет результата на 9 день, когда симуляция началась. Мы начинаем GetKanban с игры в день 9 со всеми группами одновременно на одном столе, по шагам объясняем правила игры и сразу показываем их соответствующими действиями на поле. Мы предпочитаем не использовать презентации для объяснения правил.
Это занимает больше времени, но игроки делают больше ошибок и задают больше вопросов по игровой механике, чтобы потом уделить больше времени самой игре и получить больше знаний от нее. В конце Дня 9 мы делаем небольшой перерыв. Все остальные группы копируют расстановку карточек на свои доски. Таким образом, все группы заканчивают День 9 с одинаковым счетом в банке (обычно $200) и поэтому нет необходимости тратить место на доске для этого. Вот почему, наша таблица результатов начинается с отчета в 12 День.

Шестое, День 15 — это важная точка синхронизации. Группы играют в игру с разным темпом. Если это не контролировать, то к концу игры разрыв может быть огромным. Это плохо, так как в конце идет закрепление итогов в дополнительный обучающий материал. Группа, которая закончит первой, будет скучать в ожидании остальных. Чтобы этого избежать, мы планируем так, чтобы окончание 15 дня совпало с обедом. Это мотивирует быстрые группы замедлиться, а медленные — ускориться. Группы отправляются на обед раньше или позже, но вот возвращаются уже синхронно. Разброс, накапливаемый между Днем 15 и Днем 21 (заключение игры), незначительный, и все группы заканчивают более или менее одинаково. Могу себе представить, как Рассел Хейли (создатель игры GetKanban) за многие годы, делал многочисленные изменения по улучшению игры, чтобы снизить этот непродуктивный разброс во временах игры.

Седьмое, мы делаем одно важное изменение правил со старта игры. Начинаем с пополнения очереди каждые три дня, а не ежедневно. Первое пополнение происходит на День 10, потом в 13, 16 и т. д. (Забегая вперед, один из персонажей в игры Маргарита, менеджер по маркетингу, в конце концов понимает, что ее моделируемая компания ведет довольно динамичный бизнес, и внедряет определенные изменения в своем отделе, которые позволяют пополнять очередь ежедневно, начиная с 16 Дня). Это изменение бросает интересный вызов в выборе оптимальной даты начала работ по элементу F2 с фиксированной датой поставки. День 10 — это слишком рано — высокие косвенные потери, День 13 — оптимальный, День 16 — есть риски не успеть. Это также показывает, как большая частота пополнения очереди создает больше вариантов планирования и приводит к большей гибкости.

Сделанное изменение, имеет еще одно важное назначение. Пополнение очереди в Канбан системе — это не что-то такое, что случается только на утреннем стендапе команды. (“Я чувствую, что начну эту работу сегодня”). Это действие по принятию обязательств, которое добавляет копилку бизнес обязательств и оно требует присутствия лиц принимающих решения, достаточно высокого уровня, кто может взять на себя ответственность перед клиентом за оказание сервиса, продукта или проекта. Изначальная частота пополнения очереди показывает ситуацию в большинстве компаний: лица принимающие решение не часто встречаются для такого разговора.

Восьмое, перерыв после Дня 15. День 15 — это самый настоящий экватор игры. Большинство играющих групп осознают, что они не приближаются к достижению своей цели. Я делаю грубые наброски, как показано в строке День 15 на таблице с результатами, чтобы подсветить существующую разницу и мы возвращаемся к объяснению этого, сразу после перерыва.

Например, группа стремящаяся к самому низкому времени выполнения, на самом деле замедляется. Они начали с 6-8 днями времени выполнения, а сейчас у них 6-10. Группа играющая на максимальную предсказуемость получает ее ухудшение: с распределением от 2 до 10 дней. Группа, которая должна заработать больше всех денег, сейчас находится на третьем месте из четырех, но что более важно ее время цикла (в среднем 8 дней) — это слишком медленно, чтобы получить долю рынка. Смоделированная обратная связь от рынка (спасибо Расселу за внесенные изменения в 5-ю версию игры) показывает, что приемлемый уровень составляет 3-4 дня.

Эта разница — это не вина игроков. Это обычное состояние. Игроки осваивают механику до Дня 11 или 12 (Помогает великолепное описание событий на карточках от Рассела). Они продумывают и принимают множество ситуационных решений вплоть до Дня 15, например: обходят узкое место Николая, справляются с зависимостью от общего разработчика Пети, перемещают кости (временно ускоряя некоторые этапы за счет других), и переприоритезируют элементы работы в очередях. Но, они не думают о стратегии. И вот теперь они к ней готовы. С начала Дня 16, мы получаем важный вызов: Маргарита изменяет частоту пополнения очереди, какой размер буфера теперь вам нужен? И если они не поймут это на День 16, то в День 17 их цикл обратной связи сомкнется и поможет ли им это понять?

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

Девятое, отбираем данные в Гистограммы времени выполнения за День 21. Игроки разрабатывают свою новую систему до конца Дня 21. Данные предыдущих дней могут не отражать текущую производительность системы, поэтому я отбрасываю эти данные и составляю график только по последнему дню. Изредка я замечаю, что игроки выбирают к поставке в День 21 задачи с наименьшим временем выполнения. В таких случаях, я планирую поставки на День 22+, и добавляю их времена выполнения к набору данных, чтобы его наиболее реалистичным.

Мы можем видеть, что окончательные гистограммы для первой группы показывают достижение цели. Их среднее время выполнения самое короткое, но “хвост” времени выполнения короткий, и именно так они решили проблему предсказуемости лучше, чем группа Предсказуемости (столбец номер 4 на доске). Группа Пропускной способности (столбец 2) эффективно переключилась на денежную цель и так же сделала это хорошо. Они в значительной степени попали в порог поставки за 4 дня. Их непредсказуемость (парочка задач с временем выполнения 10+ дней) была умеренной, и как оказалось, несущественной.

Десятое, этот список не все, что вы можете узнать играя в GetKanban. Правильный анализ результатов (45 — 60 мин) откроет вам гораздо больше. Я написал только о нескольких важных вещах, которые были очевидны для меня из таблицы результатов.

8 ноября   dashboard   getKanban   score   Алексей Жеглов   перевод   Роман Петров

Как быть уверенным, что работаешь над самыми важными элементами бэклога?

«Когда Agile команды работают только над срочными элементами, результат чаще всего их не удовлетворяют»

Знакома ли вам такая ситуация:
Ваша команда поработала уже несколько спринтов и работала всегда над самым важным элементом бэклога, который был выбран владельцем продукта. Однако, после этих нескольких спринтов, вы оглядываетесь назад и смотрите на то, что команда сделала и вас это совсем не устраивает. Складывается такое впечатление, что команда перескакивала с одного срочного элемента на другой, туша один пожар за другим. Команда сделала много работы, но сделанное, не добавило особой ценности продукту.

Что же случилось?
Вы попали в ловушку приоритезации, которая основывается на том, что вначале спринта вы выбираете элемент бэклога, который вам кажется наиболее срочным, часто это побочный эффект итеративной и инкрементальной разработки, которая является ядром Agile. Однако, существует лучший способ приоритезации.

Ловушка Agile приоритезации: в начале каждого спринта выбираем что делать

Выбор того, что кажется важным в начале каждого спринта, в некоторых случаях, может привести к тому, что Владелец продукта расставляет приоритеты основываясь на том, что подгорает или уже вчера сгорело:

  1. критичная проблема, пришедшая от технической поддержки
  2. то, что вчера повлияло на продажи;
  3. последний каприз очень важного стейкхолдера

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

Приоритезация без цели — это как покорение вершины без карты

В Колорадо есть 53 вершины, высота которых достигает 14,000 футов (4,267 метров). Есть 2 способа покорить вершину.
Первый способ: вы просто едете к подножию горы и начинаете восходить к самой высокой точке, которую вы видите. Почти наверняка это будет ложная вершина, которая кажется только вершиной, потому что затеняет настоящую вершину.

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

Вы идете по этому пути, пока, наконец, не увидите настоящую вершину, но между вами и вершиной глубокая долина и чтобы достичь вершины в 14,000 футов, вы должны сначала спуститься на 10,000 футов, а потом подняться обратно.

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

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

Много-спринтовая цель: карта Владельца продукта (пример: User story mapping)

Для Владельца продукта эквивалент топографической карты — это большая, много-спринтовая цель.
Без много-спринтовой цели Владелец продукта попросту взбирается с одной ненастоящей вершины к другой.
Такой Владелец продукта и его команда в конечном счете достигнут конечной цели, но зачастую только после спуска и подъёма схожего с 10,000-футовой долиной.

И так заманчиво вместо этого заняться краткосрочными пожарами.

Во-первых, это дает Владельцу продукта чувство завершённости: что-то уже выполнено и может быть отмечено галочкой в ​​списке дел. Во-вторых, это успокаивает любого, кто просит немедленного решения. Большинству из нас нравится угождать другим людям, и это зачастую не ведёт нас к достижению более важной, значимой цели.

Когда приоритезируете помните, что срочное редко бывает важным

Президент Соединенных Штатов Эйзенхауэр знал, насколько важно различать важные и срочные вопросы.
Эйзенхауэра часто цитируют так:

«То, что важно, редко срочно, а то, что срочно, редко важно».

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

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

Владельцу продукта следует определять значимую цель ежеквартально

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

Всё это означает, что Владельцу продукта жизненно важно определить основную цель и, возможно, в перспективе на 3 месяца — это достаточный срок.

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

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

Это должно быть значительным. Для нового продукта это может быть минимально жизнеспособный продукт (MVP — minimum viable product), для существующего продукта — добавление минимальной рыночной функции  (MMF — minimum marketable feature), некоторые компании называют это чрезвычайно важной целью (WIG — wildly important goal)

Владея основной целью — будь то в форме MVP, MMF или WIG — Владелец продукта сможет лучше оценить срочные элементы. Если работа над срочным элементом более важна, чем работа по достижению основной цели, то все силы команды должны быть направлены на работу с ним.

Основная цель существует не для того, чтобы Владелец продукта рабски ей придерживался, а для того, чтобы смог эффективнее приоритезировать, потому, что без этого срочные элементы всегда победят.

Оригинал статьи: https://www.mountaingoatsoftware.com/blog/how-to-ensure-youre-working-on-the-most-important-items-each-iteration

6 рекомендаций, как сказать «нет» стейкхолдеру

Сказать «нет» может быть очень сложно. Большинство хочет удовлетворить других. И, когда мы говорим «нет», мы разочаровываем/расстраиваем обратившихся к нам.

Однако, говорить «нет» стейкхолдерам — важная часть работы Владельца продукта (далее — ВП). Задача ВП — оптимизировать ценность продукта, а не говорить «да» каждой просьбе стейкхолдеров.
Каждый раз, когда ВП говорит «да» какой-либо функциональности (далее — фиче) одного стейкхолдера, он говорит «нет» будущей фиче. Время команды ограничено и сказанное сегодня «да», потребует сказать «нет» следующей, более поздней, возможности.
Таким образом, умение говорить «нет» — это навык, который ВП надо развивать.

6 рекомендаций о том, как это сделать вежливо, но решительно.

1. Будьте предельно ясны со стейкхолдерами: это нет или на данный момент нет?
Когда ВП сообщает стейкхолдеру, что не отдаёт данной фиче приоритет, ВП должен чётко довести до стейкхолдера, что означает его «нет».
Если вы, как ВП говорите, что ваша команда никогда не будет работать над этой фичей, не сейте надежду у стейкхолдера, чтобы он ещё раз попросил об этом в будущем. Это пустая трата их времени и вас будет расстраивать постоянно говорить «нет», когда вы знаете, что никогда не будете работать над этой фичей. Важно не позволять стейкхолдеру уходить с мыслью, что он может прийти к вам через месяц в то время, как ваш ответ был, что вы никогда не собираетесь с работать с его фичей.
Если же, с другой стороны, вы говорите стейкхолдеру «на данный момент нет» — это означает, что позже вы, возможно, поработаете над этой фичей — будьте в этом предельно ясны.
Например, вы можете сказать так:
• К сожалению, мы не можем поработать над этим сейчас. Поверьте, я бы очень хотел, однако, мы уже договорились разработать (скажите, что именно) к Августу. Мне необходимо сохранить фокус команды или мы рискуем не выполнить наши договоренности. Вы можете напомнить мне о вашей фиче в Августе, и я обещаю рассмотреть возможность заняться ей.
Обратите внимание, я не обещал заняться сразу же этой фичей, а обещал рассмотреть возможность.
Также обратите внимание, что ответственность остаётся у стейкхолдера о том, чтобы напомнить вам о фиче. Я делаю это для того, чтобы быть уверенным, что к тому моменту фича ещё будет важна. Если стейкхолдер не захочет сделать такую маленькую вещь, как напомнить вам о фиче, у меня будет вопрос, была ли фича вообще важной или срочной.

2. Выражайте признательность/благодарность и проявляйте эмпатию к стейкхолдерам
Когда к ВП обращается стейкхолдер с просьбой, ему следует выразить признательность/благодарность и понимание почему данная фича для него важна.
Некоторые стейкхолдеры находят время, чтобы узнать о вашей команде. Это говорит о том, что они заинтересованы в вашем продукте. Выразите стейкхолдеру свою признательность за то, что он нашёл на это время. Вам достаточно сказать:
• Спасибо. Я благодарен, что вы думаете о том, как сделать наш продукт лучше
Помимо того, что ВП следует выражать признательность/благодарность, ему также следует проявлять эмпатию к ситуации стейкхолдера.
Вы собираетесь сказать «нет» фиче, которая очень важна для него. Фича, возможно, как минимум по мнению стейкхолдера, поможет достичь целей, поставленных перед его руководителем, или повлияет финансово.
Перед тем, как проявить эмпатию, будьте уверены, что Вы понимаете почему эта фича важна стейкхолдеру. Если же нет, постарайтесь это понять перед тем, как сказать «нет».
Пример выражения эмпатии:
• Я понимаю, что данная фича важна Вам для достижения (скажите чего)

Говорите искренне. Я не думаю, что я уникален в том, что был разочарован/расстроен неискренним проявлением эмпатии.

3. Предлагайте только одну причину вашего отказа.
Когда ВП говорит «нет» это лучше делать с указанием одной веской причины, а не целого списка. Когда вы предлагаете список, люди склонны находить самую сомнительную и начинать её оспаривать.
Представьте, что я Ваш стейкхолдер и я прошу Вас, чтобы Ваша команда отложила текущую работу и начала работать над моей фичей и Вы мне говорите.
• К сожалению, я не могу этого сделать. Мы уже запланировали спринт. Команде нужно будет другое планирование и им это не по- нравится. И я уверен, что мы сейчас работаем над важной фичей.
Как Вы думаете, какую причину я оспорю? То, что Вам нужно ещё одно планирование или то, что команда сейчас работает на более приоритетной фичей?
Я начну с того, что команде нужно будет провести ещё одно планирование и ей это не понравится. Я могу предложить сделать эту встречу более приятной и провести её за обедом, на котором я куплю всем пиццы.
Если Вы будете не согласны с моим планом, я изменю наш разговор: мы спорим о том, чтобы провести встречу или нет, а не о достоинствах моей фичи. А этот спор выиграть достаточно сложно и это не правильная почва для принятия решения.
Будьте решительными и предлагайте только одно самую вескую причину сказать «нет».
Если стейкхолдер убедит вас изменить мнение, аргументировав свою точку зрения, вполне возможно стоит подумать о достаточности вторичных причин. Если они недостаточны, возможно, Вам придется сказать этой фиче «да».

4. Напоминайте, что у вас у всех одна конечная цель
Если у ВП и стейкхолдеров одна и та же цель, ВП стоит об этом напоминать при получении нежелательных новостей.
Часто у ВП и каждого стейкхолдера много разных целей и, да, часто эти цели конфликтуют между собой.
Однако, обычно существует более высокая цель, продуктового уровня, которую разделяют все и на которую можно сослаться.
Это легче сделать, если ВП и стейкхолдер из одной компании. В таком случае можно сказать что-то такое:
• Как бы мне ни хотелось, чтобы моя команда работала над тем, что Вы хотите, мы должны сфокусироваться на (назовите большую общую цель)
• Я уверен Вы помните, что все мы получили цель (назовите большую общую цель)
Напоминание стейкхолдерам, что вы разделяете общую цель, поможет им понять почему Вы говорите «нет», даже если они до сих пор не согласны с Вами.

5. Объясните стейкхолдеру последствия ответа «да»
Говоря «нет» стейкхолдеру, ВП следует объяснить последствия ответа «да»
Например:
• Если мы будем вместо текущей работы работать над Вашей фичей, мы не сможем уложиться в основной срок.
• Команда уже работает сверхурочно. Я не могу добавить это к их работе, не удалив что-то уже обещанное (скажите кому).
Объяснение стейкхолдеру последствий поможет ему понять и, я надеюсь, проявить эмпатию к тому, почему Вы говорите «нет»

6. Предложите стейкхолдеру альтернативу
Вместо того, чтобы прямо сказать «нет» стейкхолдеру ВП может предложить альтернативу.
Вы можете предложить, например, такое:
• Мы, возможно, не сможем сделать всё, что Вы просите, однако, что-то мы можем сделать.
• Я не могу переключить команду на эту фичу прямо сейчас, что, если мы начнём над ней работать через 3 недели?
Будьте осторожны: предлагайте альтернативу только тогда, когда Вы действительно её имеете в виду.

Сказать «нет» не должно быть сложно.
ВП часто боится сказать «нет» и разочаровать стейкхолдера. Однако, сказать «нет» не должно быть сложно.
Я обнаружил, что, будучи предельно ясным, приводя одну вескую причину отказа, а не список, проявляя эмпатию и выражая признательность/благодарность, напоминая, что мы преследуем одну конечную цель, объясняя последствия ответа «да» и предлагая альтернативу, сказать «нет» намного проще.


Оригинал: https://www.mountaingoatsoftware.com/blog/six-guidelines-for-saying-no-to-a-stakeholder

Опыт компании Майлстор.ком

Открываем рубрику опыт.

Пример доски: Операционный портфель для внутренних проектов.

Что есть на доске:
В начале находится раздел ”Options”, здесь применяется принцип FIFO, если что-то является приоритетным, то есть «обгон». Столбец проверки ограничен и количество одновременно запущенных проектов ограничено, но лимит еще не достигнут.

Синие стикеры — это проекты. Далее в центре есть оранжевая область, которая показывает Epics/истории проектов (желтые стикеры), которые должны быть скоординированы. У каждой команды есть значок, количество которых ограничено. Необходимо сосредоточиться только на ограниченном количестве историй, и только после того, как что-то будет готово, значок команды можно будет повторно назначить.

В верхней части вы увидите розовый стикер, который показывает индивидуальные лимиты каждой команды.

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

Следующим шагом мы планируем начать делать CFD на еженедельной основе, чтобы измерить поток историй.


(перевод с немецкого, Роман Петров)

2018   дизайн доски   доска   опыт   перевод