Раз уж пошло такое обсуждение метрик, закину ещё холиварную тему.

Есть мнение, что считать T2M нужно от попадания фичи в бэклог продукта до выкатки на прод. Какие мнения за? Какие против?

Я сторонник считать с момента принятия в работу до момента доступности пользователю. Раньше начинать смысла нет - может уйти в помойку, а выкатка на прод != доступность (фиче-тоглы и проч).

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

Если попало и лежит месяцами, то не факт, что вопрос качества именно планирования. Там ещё других причин может быть вагон. Ты же сам говоришь про понимание бизнес/клиентской потребности. Попало - (пере)осмыслили потребность - выкинули.

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

Как ты предлагаешь учитывать то, что попало, но было решено не делать? Оно на общую картину влияет, а до прода никогда не доедет.

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

Очень просто. Считай все попало в статус типа "зарелижено"

это самый управляемый подход и простой в смысле реализации, но мне не нравится что он не учитывает именно путешествие бизнес-потребности до бэклога и до реализаци, так как иначе этам метрика фокусируется не на бизнесе в целом а только на стороне ИТ

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

Было бы славно с момента появления идеи. Вот только как ты это посчитаешь? Бизнес потребность перед этим может полгодика полежать во всяких Миро и эксельках

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

Один не хочет так же, как и ты. Другой только с бэклогом и работает, потому что потерял уже два блокнота с идеями на 100500 мильёнов. Вот и как быть?

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

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

Тут я ехидно замечу. А это разве не ВАТЕРФОЛ!?

неее, это по определению разнеы штуки - ТЗ и проработка для бэклога спринта - это вопрос декомпозиции и детализации а не бизнес ценности. Вопрос именно в проработке бизнес-ценности

это несерьёхзно) что значит потерял блокнот))) Бэклог - это не записная книжка. Ну и весли ты такой лопух, то ты и бэклог потеряешь)

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

А как же (с) "Бэклог Продукта является единственным полным источником знаний о Продукте"? 😱🙈

Ага

Ситуации бывают разные, всех под одну гребёнку чесать - так себе занятие.

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

Именно поэтому и не хочется превращать его в мусорку

А как же тогда прозрачность? Как планировать работу тех, кто эти исследования будет проводить? Как же единый источник?

Так может тогда писать туда всё, но периодически убивать в нем карточки, которые сначала казались хорошей идеей, а потом оказались мусором?)

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

Владелец продукта и команда проверки гипотез (автор из бизнеса +маркетинг +финотдел)

И где будет записано все то, чем и в каком порядке они занимаются?

Так реальный t2m у тебя как раз когда ты видишь как лежат фичи в бэклоге месяцами

Да где угодно. Регламент работы рабочей группы по исследованию бизнес ценности гипотезы например

Предполагается, что они будут заниматься исследованиями только по одному продукту или по всем входящим запросам типа "свободная касса"?

смотри, мы можем процесс разложить на две части. В первой части мы ищем ответ на вопрос "Это надо делать?" и там проходят разные анализы, подсчеты экономики, всякие райсы, айсы, скоринги и т.п. до конца этой части доживают только запросы по которым ответ на вопрос "Это надо делать?" однозначный "Да!". И эти запросы прилетают к точке процесса, которая называется "Точка принятия обязательств" или Commitment point. Вторая часть процесса - это реализация, где ищется ответ на вопрос "Как это сделать?" и вот запрос из первой во вторую часть переезжает когда у второй части есть возможность взять что-то еще в работу, т.е. пересечение точки принятия обязательств - это handshake (рукопожатие) между теми кто нашел ответ на вопрос "Это надо делать?" где они говорят, что это самая важная на данный момент работа и ее обязательно надо реализовать и теми кто будет реализовывать в момент, когда у этих реализаторов появляется возможность взять что-то в работу. Вернемся к временам. Для первой части процесса официального названия я не встречал, но кулуарно его часто называют Time to Decision (Время на принятие решения), время во второй части часто называют Lead Time (Время производства), ну а совместно это пресловутый Time-to-Market

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

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

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

Верно. Я к тому, что это все равно один единый список, элементы которого находятся на разных стадиях единого сквозного процесса.

Мне кажется, что в этой картине мира не хватает третьей части, находящейся после завершения LT, но до завершения T2M. Фича, которую анализировали, потом декомпозировали на отдельные Стори, каждую из сторей брали в разработку отдельно, у каждой свой LT. Но целиком фича не реализована, пока все (или почти все) стори не будут реализованы и только после этого фичу можно выпускать на клиентов. Вот только в этот момент можно заканчивать считать T2M.

Есть понятие "минимальный распознаваемый заказчиком элемент" измеряете ЛТ на него, а не на технические таски, из которых он состоит.... Profit)

Верно. Главное: 1. Шкаф есть и он один. 2. Полочки есть в принципе. 3. Все знают правила, по которым каждая вещь перемещается с полочки на полочку.

Нет, я говорю не про технические тапки, а про User Story. Каждая из них имеет business value, но по одиночке их выпускать не всегда целесообразно.

Они считаются одной фичей. Не то, чтобы было невозможно их выпускать отдельно, но, например, PO хочет их выпустить комплектом. Либо таково свойство продукта. Либо так устроен релизный цикл, на который команда не может повлиять. Кстати, ещё вопрос, что означает "релизить" - попало в прод или работает в прод. Вы выше обсуждали вроде, но что-то не нашел, к чему пришли.

Так это и есть по сути "наладить работу" и закрепить в корпоративной культуре культуру чистоты на полу

Точно!

"Релизить" я нигде не обсуждал. Тут уж как вам самому нравится)) Я имел ввиду конечную точку для ЛТ или ТТМ Если ПО хочет - значит говорим "ну вот такое у нас ЛТ, потому что Продакт так хочет")

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

Ещё раз спасибо

О, Артем, а как вы статус "зарелижено" трекаете? Он вне скрам-доски получается? У нас же стори доходят до состояния Done (что != зарелижено). Вы потом после релиза перекидаваете стори в released в уже прошедших спринтах, а сама колонка не является финальной в скрам процессе?

Вне доски. Доска заканчивается на статусе протестировано или пререлиз. Дальше магия - там у нас точка роста, релизы вообще проблема Есть просто статус Done куда все валится после релиза.

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

А может и нет 🤷‍♂️ Может он нашёл тонкое различие, которое не ухватили в Agile манифесте Вот и развивает, глядишь что ценное привнесут на своём уровне