Привет. Сегодня поделюсь мыслями про стандартизацию процессов в нашей работе. Например, в компании предлагают стандартизировать доски и процесс в Jira, вводят новые отчеты и процедуры. От коллег по цеху часто слышу мнение, что все эти подходы - не по-агиловски, убивают творчество. Сам грешен - когда в компании 3 года назад решили стандартизировать процесс в Jira и сделать единый flow - я спорил больше всех😁.  Сейчас в стандартизации вижу в этом пользу и расскажу почему.
Правильная стандартизация - не убивает творчество и свободу выбора. Настоящее творчество может появиться только тогда, когда базовые, рутинные вещи отлажены и не требуют усилий. Когда не нужно каждый раз изобретать велосипед. Вот тогда в твоей коробочке появляется время на подумать, высвобождается энергия для создания чего-то действительно нового.В нашем цехе и своего рода мантра есть: «каждая команда — уникальна, у всех свой контекст, свои процессы, своя Jira-доска». Каждый - уникальная снежинка. Это все конечно так. Но что делать, если ты тратишь кучу времени на анализ метрик? Или когда чтобы вникнуть в новый процесс - нужно пройти 7 (или сколько их там) кругов ада.

✅ Где стандартизация может помочь?

Допустим, несколько команд работают над одним продуктом. У кого-то Done включает прод, а у кого-то — только передачу в тестирование. Один пишет user story по шаблону, другой — как попрёт. На небольшом масштабе одной команды свой уникальный процесс — это ок. Но когда таких команд десятки, ничего ты уже не проанализируешь. Вот примеры пользы, которые увидел из своей практики:

• Общий флоу в трекере даст возможность собирать метрики единообразно. Не для того, чтобы сравнивать 2 команды и шеймить отличившихся, а чтобы искать выбросы. Чтобы понимать, куда идти в первую очередь. При этом - важно добиться хотя бы единообразия в опорных статусах для сбора метрик. Решения на данных и аналитике все же эффективнее и проще “продаются” командам, чем идеи на чуйке.
• Артефакты продакта и аналитика. Поможет договориться о том, кто какую часть собирает. Структура внутри карточки Story - упрощает понимание. А когнитивную нагрузку на команду надо снижать - им и так непросто). Сейчас на консалтинговом проекте мы с продактом как раз перерабатываем бэклог и выравниваемся с командой по структуре. Это уже сокращает срок составления требований - меньше дублирующей работы, команде проще считывать и обсуждать схожие по структуре документы.
• Единый подход к диагностике команд. Я вводил это, когда работал Agile лидом 3 года назад. Тогда это дало прирост в актуальности артефактов диагностики, скорости их сбора. Дало возможность обсуждать идеи и наблюдения друг друга. VSM каждый все равно делали по-своему, но делали все. До сих пор агенты изменений мыслят категориями “гипотеза о проблеме”, “гипотеза о решении” - это здорово.
• Формирование базовых технических требований к развитию продукта для СТО. Гигиенический минимум, который основан на стратегии кластера/юнита (подставь свое название). Как говорит мой руководитель - это уровень “зубы чисти, жопку вытирай, тарелку за собой убирай и мусор выноси”. Дальше - простор фантазии, развивай продукт как считаешь нужным. Но сначала - сделай базу, чтобы все были спокойны. Мы кстати думали, что это - база и у всех все ок, но оказалось что нет:)
• Единые процессы и их описание (если оно не для галочки) - упрощают онбординг и ротацию. Представьте, что вы собеседуетесь в 2 продукта (и допустим, на собеседовании вам могут предоставить много внутренней информации. Например, внутренний найм или ротация). В первом говорят, что задачи классные, у нас куча изменений, все - вчерашнее завтра не актуально. Веселье🎉! Во втором - показывают, какая структура и роли, какие командные договоренности и процесс. У кого какая ответственность на этапе VSM. “Вот такие метрики смотрим, вот такое и вот так обсуждаем”. И задачи тоже интересные. Куда пойдете при равных условиях? Переход в другую команду в рамках своего продукта или вообще в другой продукт - уже проще.
• Подходы к найму и развитию команды. Мы сейчас у себя сильно загорелись этой идеей и пилотируем подход командного плана развития, который потом декомпозируется на ИПР. Увидели, что несистемная работа с ИПР не приносит пользы ни наставнику, ни наставляемому, ни продукту. После проверки гипотезы будет видно эффект, пока ожидаем повышение прозрачности и рост по метрикам производства, рост удержания.
• Профили ролей. Конечно, скользкая дорожка ( 5 лет назад мы так делали профили PO и дошли до таких глубин, что эксель навыков под все виды продкатов был больше 100 параметров. Идея, конечно же, не взлетела). Но мы сейчас находим много интересных данных по интервью с СТО и техлидами.
• Не самый очевидный плюс: для того, чтобы стандартизировать что-то и договориться о нормах - нужно договориться и хорошенько поисследовать. Пока проводил интервью по роли СТО - накопал много интересных идей, полезных не только одному человеку. Приходится погружаться больше. Как результат - участники лучше понимают процесс. И его проще менять в лучшую сторону, отходя от стандартов.

🧨 А где стандартизация всё портит?

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

Простое масштабирование стандартизации снизу вверх не работает. Требуется еще и объяснить пользу. Научить работать с этими подходами. Если просто сделать дашборд на основе единого флоу и потом всем давать по шапке за lead time > 14 дней, то он очень быстро станет выглядеть красиво, станет “арбузной метрикой” - зеленой снаружи и красной внутри.

🌱 Путь к мастерству: Шу-Ха-Ри (Shu-Ha-Ri)

В известной многим агилистам модели Шу-Ха-Ри тоже есть немного про эту тему. Прежде чем экспериментировать - научись хорошо делать базу:

• Шу (Shu) — Следуй правилу. На этом этапе команда осваивает базовый, стандартизированный процесс. Она учится говорить на общем языке и понимать «почему» так устроено.
• Ха (Ha) — Ломай правило. Поняв основы, команда начинает осознанно экспериментировать и адаптировать процесс под себя, нарушая правила там, где это приносит пользу.
• Ри (Ri) — Будь правилом. Команда достигает такого мастерства, что сама создает новые, эффективные практики. Ее «уникальность» — это уже не наивность новичка, а результат глубокого опыта.

Стандарт — это не тюрьма, а необходимая ступень «Шу», без которой невозможно прийти к осознанному мастерству «Ха» и «Ри». По крайней мере, я так это понял.

🛠️ Ящик инструментов

Мне нравится представлять это как общий ящик с инструментами. Компания предоставляет всем командам стандартизированный набор: вот Jira с базовым workflow, вот Confluence с шаблонами. Команда использует инструменты из этого ящика, но как именно она их будет комбинировать — ее дело. Никто не запрещает добавить в свой уголок пару уникальных «отверток», но основной набор остается общим. В книге Product Operations приводятся интересные примеры того, что теряет компания, избегая использования общих инструментов и разумной стандартизации.

🧩 Что делать с этой информацией

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

Мир не черно-белый. И анархия и бюрократия может быть и хороша и плоха

Интересно узнать твое мнение и примеры. Поделись своим опытом в комментах - давай обсуждать🤝.

Привет! После перерыва возвращаюсь к статьям. Сегодня - про пользу фриланс проектов.

Мой опыт

Мои первые проекты стали появляться 5 лет назад, в 2020 году. После моего перехода в новую компанию ко мне обратилась PO. У команды появились новые задачи, пришли новые люди, вместе с ними - конфликты. Нужно было актуализировать договоренности.

Это был проект с 1 командой, которую я вел около 6 месяцев.

После этого пришли из соседних продуктов по рекомендации от первого PO c похожим запросом. Затем - бывший коллега, с которым мы работали над SAP-решением крупного FMCG игрока. Тогда в 2017 году мы были по разные стороны: я со стороны консалтинга внедрения, а мой коллега - со стороны FMCG компании. Так получилось, что он перешел в ту компанию, из которой ко мне как раз приходили по фрилансу.

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

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

Польза от фриланс-проектов

Во время первого проекта в 2020 году у меня было всего 2,5 года опыта в agile, небольшой технический бэкграунд и опыт проджекта. "Вроде рановато брать на себя такую ответственность, ты же не зрелый консультант", - думал я. Но оказывается, что не всем нужны зрелые (читай - дорогие) консультанты. Не все проблемы требуют 10+ опыта компетенций, иногда просто не хватает рук и взгляда со стороны. Иногда - просто нужен определенный стиль работы с изменениями. В общем - по моему опыту порог входа проще, чем я думал в начале. При этом отсутствие огромного опыта не является минусом, а иногда - даже плюсом для заказчика.

➕В фрилансе ты выходишь за рамки привычного тебе формата работы в компании. Это как съездить в отпуск без телефона и приехать со свежими идеями. Часто в фрилансе ты делаешь то, чего не стал бы делать на текущем месте.

➕ В фрилансе ты видишь разные реализации процессов разных уровней. Даже работая на уровне 1 команды - ты видишь структуру управления продуктовым портфелем или ИТ. Я не устану говорить, что агенту изменений крайне важна насмотренность, она не может быть избыточной. Чем разнообразнее и шире, тем на каком-то этапе лучше. Насмотренность очень хорошо лечит от праведной веры в один фреймворк, одну книгу, одного тренера/лектора. Очень часто собеседовал ребят, которые отказывались работать с чем-то, кроме LeSS потому что все остальное от лукавого (им так не сертификационном тренинге говорили).

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

➕ На фрилансе ты неизбежно будешь больше внимания уделять целям привлечения тебя как консультанта, ожиданиям заказчика, образу результата. При этом, работая на основном месте ты можешь "плыть по течению".

➕ В моем случае - я всегда обсуждал мое привлечение к фрилансу с текущим руководителем на основной работе. Если он был против - я не фрилансил. Все просто. Но отказ у меня был только 1 раз, на прошлом месте работы. Такие обсуждения учат смотреть со стороны пользы, а не потраченных часов. В таких обсуждениях помогало обсуждать цели и ожидаемые результаты вместо списка задач.

➕ Если ты сам руководитель и у твоего сотрудника появился фриланс - круто! Так, один из скрам-мастеров моей команды взял проект с командой data science и работы с канбаном. На тот момент на основном месте работы не было подобных проектов. Но после 6 месяцев у нас появилась потребность пробовать практики из канбана. Его опыт хорошо пригодился.

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

➕ Если ты сделал предыдущий пункт и поговорил с руководством - то ты начинаешь работать на текущем месте иначе. Более внимательно относишься к срокам, результатам. Я понимал, что мой руководитель мог и не давать согласие на мои фриланс проекты. Но раз уж дал - я не должен его подводить. Один раз у меня был такой уровень нагрузки на фрилансе, что он начал мешать основной работе. Я это понял сам, обговорил с внешним заказчиком рамки и результаты. Довел до этих результатов и мы завершили сотрудничество.

➕ Это своего рода предпринимательский опыт (с оговорками). Попробую расшифровать. Например, от PO часто ждут предпринимательского опыта. Под этим подразумевают:

• Опыт работы с целями и результатами.
• Опыт работы с пользователями и заказчиками, поиск реальных запросов.
• Опыт поиска быстрых результатов.
• Клиентоориентированность.

в 2014-2015 году у меня был предпринимательский опыт. Я ушел с работы и вместе с партнером мы разрабатывали тренинги под определенных заказчиков (retail) и делали консалтинг руководителей продаж в сети одежды. Когда ты понимаешь, что в любой момент твою работу могут не принять, не заплатить, докинуть новых целей - это сильно дисциплинирует и учит работать иначе. Фриланс на мой взгляд дает похожий опыт.

Вопрос к тебе:

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

Привет! в конце года я проводил стратегическую сессию с одной из компаний по их запросу. В предыдущем посте канала я как раз спрашивал советов по этой задаче. Часть удалось применить - спасибо тем, кто откликнулся. За вопросы "чтобы что?" , "какая цель?" - тоже спасибо, еще раз обдумал план сессии. Надо было думать, когда писал запрос в чат с коучами😏.Не получилось сделать фотографий, которые были бы не смазаны и на них не было бы NDA. Верьте на слово).Расскажу, что делал и какой получился результат.

Какой был запрос?

Начал с разговора с СТО компании.

🪢Стратегическая сессия нужна была для подготовки к сезону (у бизнеса есть выраженная сезонность, нужно было запланировать работы на "низкий" сезон).

🪢Важно было ближе познакомить людей друг с другом - многие из них только слышали друг друга на встречах и не всегда видели друг друга даже по камерам. После встречи договорились снять запрос с СРО и некоторых лидов.

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

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

На сессии присутствовали СТО, СРО, технические лиды команд, технические лиды функций, продакты. Всего 35 участников, других фасилитаторов не было.

Предварительный план

1 день

• Вводная часть

• Обзор результатов года

• Обзор планов на сезон

• Обед

• Знакомство и командообразование

• Сбор текущей проблематики (вводные по категориям, конфликты, процессы, инструменты)

2 день

• Отрисовка текущего процесса

• Связь проблем (1 день) и текущего процесса

• Выработка решений

⏱️Время и подготовка

Сессия была запланирована на 2 дня, в первой половине первого дня предполагалось обсуждение результатов за год и планы по продукту и компании на следующий год. Лидеры направлений и команд так же представили свои планы по задачам и улучшениям. Мне оставалось 1,5 дня на проведение. Мы уже заранее убрали много идей, так как лучше меньше и качественнее, чем больше и хуже. Конечно лучше и больше и качественнее, но я пока видимо к такому не пришел. Проще добавить по ходу новые блоки, чем убирать запланированные.

📚Проведение таких сессий научило меня, что нужно:

✅Обязательно готовиться.

✅Интервьюировать людей и собирать ожидания и потребности.

✅Делать фасилитационный план.

✅Заранее узнавать про помещение, флипчарты и прочее.

✅Быть готовым этот план выбросить и на ходу сформировать новый. Поэтому с СРО и СТО мы обсудили только верхнеуровневые шаги. И не зря.

Проведение

🎯1 день. Обзор результатов и целей

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

🤝1 день. Знакомство и командоообразование

В конце первого дня провели упражнение на знакомство. Проводил в формате мини-групп "путь от школы до текущего момента", его описывал тут.

Эта часть по времени заняла около 1,5-2 часов, но я который раз убеждаюсь - это время потрачено не зря. Упражнение точно выигрывает у стандартных "2 правды 1 ложь", в которых люди просто делятся некоторыми фактами. По сути мы так мало что узнаем друг о друге. В нашем упражнении каждый не просто рассказал, чем занимался до этого момента (а это уже огого какой контекст), но и показал, чем руководствовался при принятии решений о работе, переходе и так далее. Этот контекст очень важен.

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

а этом мы закончили первый день и пошли отмечать это дело на неофициальной части.

🍕🍻 1 день. Неофициальная часть

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

Еще - много спрашивал про роль техлида, СТО, тим лида, их отличия. Это мне очень пригодилось потом, когда я начал проводить большое исследование роли СТО на работе. Исследование еще не закончилось, но уже есть интересные выводы - опишу их как-нибудь в следующих статьях.

Думал как обычно никого не смущать, чуть-чуть посидеть и пойти в отель - в итоге ушел вместе с последними)

🕵️‍♂️2 день. Сбор проблем

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

Сразу начали со сбора идей по проблемам и зонам роста. Мне нравится делать такие вещи через представление будущего, а не настоящего. Подготовил для ребят простые формы на флипе. Легенда такая:

"Вы - судмедэксперт эксперты и криминалисты, но не в области людей, а в области компаний. На столе лежит дело о смерти компании. У вас есть все данные о компании, как будто вы и сами там работали (а они там и работают - вот совпадение). Вам необходимо установить, что привело к смерти. Составить список проблем, которые привели к смерти. Представьте, что вы проводите посмертный аудит"

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

Сформировали команды у флип-чартов и пошли обсуждать и собирать.

Так  как я был единственным фасилитатором, а такие обсуждения уже посложнее чем форматы знакомства - попросил СРО и СТО не быть в составе команд, а ходить по станциям и корректировать ход обсуждения. Мы заранее с ними выровнялись по ожидаемому результату. Периодически собирались с ними на короткий синк, обсуждали где кто буксует и какие уточняющие вопросы задают.

Это делали до обеда с периодическим чеком готовности. Собрали данные, потом каждая станция рассказала свои идеи.

🧙‍♂️🪄2 день. группировка идей

После обеда - по заветам Сэма Кейнера группировали и структурировали все в общий список и группы.

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

🧩Что делать с этой информацией?

Такой сценарий не будет работать везде по умолчанию. Но вот что можешь попробовать ты:

🧩Заложи больше времени на командообразование. Акцент - на качестве, а не на разнообразии и веселье.

🧩Будь готов поменять план - альтернативные сценарии полезны.

🧩Попробуй сбор не с текущей ситуации, а с взгляда из будущего.

🧩P.S. Музыка в перерывах и в начале - решает. Последние несколько лет я всегда приношу с собой колонку на очные мероприятия (запуски команд, сессии такого типа),

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

Зачем нужны оценки?

1️⃣ Первое (очевидное)

- для прогнозирования. Если вы набрали сколько набралось и сделали сколько сделалось - то это никак не поможет в оценке будущего.

2️⃣ Второе (неочевидное)

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

Кому нужны оценки?

1️⃣Первое (очевидное) - продакту. Он думает, что понимает, сколько они с командой могут взять, сколько сделать, какая точность планирования. Как планировать будущие большие фичи. Как общаться с стейкхолдерами.

2️⃣ Второе (очевидное) - скрам-мастеру. С ними он может смотреть тренды, прогнозы. Становится больше данных для анализа и улучшения процесса. Даже без цифр, на основе самого обсуждения оценок, можно вытащить очень много идей для улучшения.

3️⃣ Третье (менее очевидное) - команде. Если инструмент оценок используется - команда будет и декомпозировать, и обсуждать, и выравниваться, и пробовать реалистично оценивать свои силы. Команда сможет тормозить “активного” продакта или наоборот вытягивать в Спринт больше (да, такое тоже бывает).

4️⃣ Четвертое (неочевидное) - другим продуктам/командам и компании в целом. Появляется возможность показать наружу скорость, прогресс, точность планирования. Решение смежных задач и зависимостей становится проще, особенно с работающими приоритетами.

Что использовать?

❓Story points, часы, майки, попугаи, изяны, идеальные человеко-дни

Какой из способов правильный? Любой, который работает в этой команде.

❓Может команда работать без оценок?

Может, такие команды были в моей практике. И это либо команды, которые не оценивают и ничего не могут сказать про свой прогресс и скорость. Либо очень зрелые команды, которые настолько преисполнились в этой практике, настолько выровнены и круто декомпозируют, что могут считать в штуках, так как story у них +- одинаковые.

Почему story points?

Я работаю с любым форматом, но подход story points мне кажется более логичным.

Оценки в часах или “идеальных днях”- абсолютные.

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

Еще - у подхода в часах всегда есть “крышка” - условные 40 часов на человека в неделю минус встречи, обеды, перерывы, обсуждения и так далее. Это мало говорит о скорости. Фокус - не на получении результата, а на выполнении как можно большего количества работы.

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

Оценки в попугаях, изянах - относительные.

К тому же - они выражены количественно (2 попугая, 5 попугев). Как и SP. Некоторым командам проще начать с них или с маек. Правильного/неправильного нет - главное, чтобы была польза.

Оценки в майках

- относительные, как SP или попугаи. Но когда нам нужно понять емкость спринта - как сравнить например Спринт, в котором 3 XL, 1 L и 2 M, со Спринтом с 5 M? В каком спринте больше? Надо приводить к числам, например S -1 , L - 5, XL - 13. Иначе мы не посчитаем скорость, точность. Тогда проще сразу использовать SP. Поэтому дальше буду рассказывать про SP. Я не говорю, что только SP - рабочая тема. Используйте то, что удобно команде - лишь бы работало.

Важно, что SP - относительные оценки. Они оцениваются ОТНОСИТЕЛЬНО друг друга. Значит - для старта очень важно наличие эталонных задач. Также важно периодически сверяться с этими эталонами и с другими задачами. Пример сверки:

Команда провела оценку Story, провели аж три раунда. Большинством голосов выбрали 8 SP.

• Давайте сравним с другими 8 SP, которые уже были оценены? Похоже?

• Если сравнить эту Story на 8 SP с вот этими на 5 SP и этими на 13 SP - то она больше/меньше?

Иногда на этих вопросах команда может еще раз переоценить. Команды это не любят, бесятся. “Мы же уже сказали, мы так одну Story сейчас будем час обсуждать!”. Да, вот так в начале это и работает. Да, и потом тоже периодически надо сверяться. Но чем больше сверяетесь - тем потом быстрее оцениваете. Чем больше таких ситуаций возникает - тем больше идей для улучшений есть.

👀 Наблюдения по процессу

Практики scrum/agile/прочего - это комплекс. Например, Рождество или Новый Год - это комплекс. Если вы просто бросите носок у печки - ощущения Рождества не будет. Если вас никто не поздравит с днем рождения, не будет подарков и других атрибутов - тоже будет грустненько. А вот если елка в доме и наряжена, играет Frank Sinatra (у меня это он), украшения - тогда ощущение есть. С практиками так же. Если вы берете кусок - то вся практика может не взлететь. Конечно, не всегда есть возможность/необходимость сразу все подготовить, готовиться несколько месяцев, чтобы что-то попробовать. Но если пробуете и не получается - проверьте еще раз, а все ли вы делаете. Может у вас просто брошен носок у печки. Дальше расскажу свои наблюдения за время работы с командами.

💭 Нужно быть готовым больше разговаривать.

Любые практики в scrum и так далее - в первую очередь про поговорить, обсудить, выровняться, шарить экспертизу и понимание. Если не говорить - оценки работать не будут. Поэтому важно при оценке использовать слепой метод - когда выложили оценки, и если расхождения - говорим, почему такую оценку поставил и опять молча переоцениваем. И важно именно обсуждать, а не “Ну Толя сказал, тут 3 SP - значит 3”.

💭 Story points - это оценки Story.

Если у вас не Story или не около того - нормально может не работать.

❓Можно ли в SP оценивать таски и потом складывать в оценки? Можно конечно, но работать не будет.

❓Можно оценивать только фронтами story на фронт? Можно, но это не story и оценки работать не будут. И пространства для обсуждения там будет существенно меньше. Для того, чтобы оценки были полезны - может потребоваться пересобрать бэклог (не все PO это любят). Может потребоваться перестроить процесc PBR (у вас же он есть?), декомпозицию.

💭 Эталоны нельзя сделать 1 раз.

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

После этого попросил команду подготовить истории для эталонов:

🧩 Завершенные истории.

🧩 Разного размера.

🧩 Те, которые вы очень хорошо запомнили (было много проблем или наоборот решили очень просто. Запоминающиеся обсуждения и так далее). Чем ярче - тем проще потом.

Далее - мы сначала распределили их слева направо (потренировались в относительности). После этого - начали выборочно оценивать и формировать границы - оценили что-то на 13, потом что-то на 5. У же есть две границы - остальное сверяем. Получилось как на скриншоте ниже (еще не все эталоны оценены).

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

💭 “Я джун/новый сотрудник - как я смогу оценивать?”

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

💭 “Я дизайнер - как я смогу оценивать? я в вашем коде ничего не понимаю”.

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

💭 Definition of Done (a.k.a. DoD)

. При оценке в SP мы оцениваем какой-то объект работы - Story. В этот объект работы входят задачи. Story считается завершенной (а SP - “заработанными”, выполненными), когда она достигла понимания “Готово”. “Готово” - это DoD (definition of done) и Acceptance Criteria (критерии приемки). ❓Можно ли оценивать в SP, если в команде нет понимания DoD и не используются ни в каком виде критерии приемки? Можно, но оценки будут скакать. Если в течение Cпринтов вы видите постоянную потребность в переоценке, “а мы то думали, там другое надо сделать” - стоит обратить внимание на DoD и AC.

💭 Definition of Ready (a.k.a. DoR).

Чтобы оценивать этот объект работы, нужно понимать, о чем идет речь. Для этого можно использовать DoR. DoR - это фильтр на вход. Если пункты из DoR есть - нам достаточно информации, чтобы оценивать. Чем больше пунктов - тем проще оценить и тем дольше их выполнять. Чем меньше пунктов - тем сложнее оценить, но оценить и начать можно раньше. У зрелых команд может быть очень короткий список в DoR или его вообще может не быть. У малоопытных команд тоже может не быть DoR, но между ними будет большая разница - первые уже много чего переделали, хорошо разобрались в продукте и всем, что под капотом. И могут себе это позволить.

💭 Проводи аналитику, сам и с командой.

Периодически я выгружаю оценки и смотрю их lead time. Это может и не канонично, но что поделать.

Запоминайте и разбирайте то, из-за чего пробуксовывают оценки.

Из-за чего происходит много этапов голосования? И из-за чего возникает сильный разброс в оценках? О чем долго не могли договориться эти двое (или трое)?

Можно ли выделить группу историй, по которым больше всего проблем с оценками и их точностью? (интеграции например).

Как проверить, что оценки работают?

🥷🏼 В процессе оценок нет дисфункций

(перечисленных выше или других, обнаруженных тобой. Знаешь другие - поделись с каналом🥺)

🥷🏼 Эталоны SP обновляются и актуальны.

Не один раз перед запуском оценок. Не когда пригорит. Каждый спринт оцениваете - посмотрите на эталоны. Они могут терять свою актуальность, появляться новые.

🥷🏼 Косвенно - переносов из Спринта в Спринт меньше.

Чаще всего в самой story будет отображено, в каких Спринтах она была задействована. Это всегда можно выдернуть и руками без сложных автоматизаций.

🥷🏼 Отчет “Диаграмма производительности” выглядит +- ровно.

Если скачки редкие - стоит посмотреть, что такого было в Спринте. Если они постоянны, тогда оценки точно стоит проверить. Этот график может выглядеть хуже просто потому, что Спринт в Jira стартуют раньше, чем положат и оценят в Спринт story🫠).

🥷🏼 Если выгрузить все Story и сгруппировать по оценкам (например, все 8), то можно:

🧩 посмотреть среднее/медианное значение lead time. Если по какой-то группе оценок среднее/медиана больше или равно длине спринта - нужно работать над декомпозицией и не брать в спринт большие.

🧩 Если волатильность (разброс) слишком большие - значит нужно обратить внимание на эталоны и свериться с ними. Например, если в группе 8 SP есть story, которые закрываются за 3 дня и те, которые закрываются за 83 дня - ваши оценки не работают.

Я просто выгружаю из Jira в excel и группирую, как удобно. В эталоны кстати тоже можно добавлять факт по lead time.

Как еще можно использовать?

Считать стоимость story. Да-да, это тоже не канонично, не точно. Но если нужно, а других подходящих вариантов нет - можно и попробовать.

Например, вы работаете спринтами 2 недели. Ваша прогнозируемость - понятна. Точность планирования +- стабильна.

Команда, например, делает за спринт 30 SP. Стоимость команды за спринт, например, 3 млн. Сколько будут стоить 5 SP? 500 тысяч рублей. Очень грубая и неточная оценка. Что она даст?

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

🧩 “Что мне с этим всем делать?”

💭Если только собираешься запускать оценки - эта статья может помочь справиться с некоторыми возражениями команды. При условии, что ты и еще кто-то знаете, зачем вы это делаете и какую пользу хотите получить).

💭 Если у тебя есть свои примеры дисфункций - пиши в канале, всем будет полезно увидеть опыт шире моего.

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

1️⃣ Тихая диагностика

Цель кейса - понять, как и что может узнать кандидат, не разговаривая с командой. Почему это важно? Ведь 1:1 тоже вполне себе инструмент. Мне важно понять, что из осязаемого и объективного кандидат может посмотреть. Как он может оценить текущее состояние. В ходе кейса какие-то ответы требуют большего погружения - тогда погружаемся.

✍🏻Контекст:

Ты только что устроился в компанию. У тебя первый день в новой роли. Тебе выдали технику. На ней настроены все доступы: Jira, Confluence, почта, zoom, рабочие мессенджеры - все, что нужно. У тебя уже подписаны все документы для кадров, пройдены все обучения по охране труда (предположим, что это возможно). В этот же день была установочная встреча, на которой тебя представили команде. Все с тобой поздоровались и попривествовали. Все теперь про тебя знают, твою роль тоже знают. Все чаты командных встреч уже у тебя в календаре - если ты туда придешь, то никто не удивится.

Через месяц твои СРО/СТО ждут от тебя рекомендации и выводы о работе команды. Куда полезешь, что будешь смотреть и для чего?

❓Вопрос:

Что будешь смотреть, чтобы по итогу месяца предоставить наблюдения?

🧱Ограничение:

Ты не можешь ни с кем разговаривать. Не можешь ставить 1:1, проводить командные встречи. Можешь только ходить на встречи (как и говорил ранее - ты уже добавлен в них, тебя представили). Срок - через 1 месяц. Ограничение по времени так же дает понять, насколько опыт кандидата позволяет оценить объем работы для диагностики. В ответе важно понять, что реально будет смотреть кандидат, а не что в целом было бы прикольно понаблюдать.

Что предлагают посмотреть кандидаты:

💬 "Посмотрю, как проходят командные мероприятия"

Важно, что именно кандидат на них смотрит.

Например:

💭"Как проводятся и проводятся ли мероприятия".

Это дает мало информации.

💭"Сколько длится дейли. Если больше 15 минут - все плохо"

Это тоже дает мало информации. Допустим - дейли 30 минут, но первые 15 минут говорят про бэклог Спринта, а вторые - про синхронизацию с другими командами. Плохо? Да не факт. До сих пор не могу понять, почему так цепляются за эти 15 минут без разбора причин. Можно и 15 минут провести абсолютно бесполезно.

💭"Есть ретро или нет. Если есть - в каком формате проводится"

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

💭"Сколько длится планирование?"

Тоже даст мало информации.

💬 "Посмотрю метрики в Jira"

Это предлагает не так много кандидатов. Хотя, с учетом ограничения на общение, может быть важным источником информации. Здесь я спрашиваю - что именно, как и для чего будет смотреть кандидат. Например, T2M сам по себе может быть менее ценным. То, как ведется доска, бэклог, гигиена Jira (прокликиваются ли статусы) - более ценным. Если на этом этапе спрашивать больше подробностей - можно узнать, работал ли кандидат с данными или только со стандартными графиками (на них есть далеко не вся полезная информация). Например, часть кандидатов говорит, что в работе использовали только дэшборды, созданные в компании. Но в другой компании даже если они и будут - скорее всего будут настроены по другому. На мой взгляд, важно уметь выгрузить все в excel и там при необходимости построить те срезы, которые нужно.

💬 "Посмотрю стратегию и видение развития продукта, продуктовые метрики"

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

💬 "Посмотрю деплои, CI/CD, процесс код ревью, покрытия тестами"  и прочие технические слова.

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

🧩 Почему я предлагаю этот кейс? И что с ним делать тебе?

Есть случаи, когда важно начать работать, но у команды прямо сейчас нет времени (пожар, релиз, что угодно лишь бы с нами не говорить). Я убежден, что много информации можно собрать из доступных источников. Гипотезы можно собрать из текущего состояния мероприятий как операционного ритма, процесса в Jira и метрик производственного процесса. Если ты опытный агент изменений - этого может быть более чем достаточно для старта. Ограничение в месяц - для того, чтобы ограничить “а еще можно вот это сделать”. Можно до бесконечности смотреть и искать, но зарплату не только за это платят). Опытный кандидат с меньшей вероятностью предложит то, что даст ему мало информации. Ну и углубляясь в ответы можно попробовать узнать, делал ли на самом деле кандидат то, что предлагает (как с предложениями по CI/CD). Можешь попробовать ответить на этот вопрос сам или предложить другому скрам-мастеру с соседнего продукта-команды сделать друг у друга такие тихие диагностики. Для команды будет минимум отвлечений, а вы сможете поделиться идеями.

2️⃣ Конфликт на ретро

Эта ситуация произошла со мной 5 лет назад. Тогда я не справился со своей задачей. Но этот опыт мне запомнился надолго, уроки я вынес). Ситуация нетиповая - тут не про правильно/неправильно. Больше - про то, как понимается ретро кандидатом.

✍🏻Контекст:

Ретро, ты его проводишь. Ретро проходит в очном формате. В углу переговорки шушукаются и о чем-то спорят senior-fullstack разработчик и frontend-разработчик. Ты пару раз обращаешь на них внимание и возвращаешь к теме ретроспективы. Через 5 минут frontend-разработчик выбегает в слезах за дверь. Fullstack - пожимает плечами. Гробовая тишина. Вся команда сидит и смотрит на тебя.

❓Вопрос:

Что будешь делать в этой ситуации? Не потом, не после ретро, а именно в моменте.

Этим кейсом просто смотрю, как кандидат относится к ретро.

💬"Остановлю ретроспективу"

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

💬"Попрошу вернуться frontend-разработчика, у нас ретро и люди сидят ждут.”

Звучит как: ”это проблема frontend-разработчика. Пусть разберется со своими эмоциями.” В таком контексте - исключает влияние проблемы на весь процесс команды. Не скрамненько.

💬"Попрошу fullstack-разработчика тоже выйти и решить конфликт"

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

💬"Продолжу ретро по намеченному сценарию"

Это говорит о том, что кандидат либо видит больше ценности в том, что он сделал и принес. Либо пока не готов так быстро перестраиваться

💬"Спрошу у команды, что делаем дальше"

Тут кандидат делает фокус на том, что это командная проблема. Что ретроспектива - это не “собственность” скрам-мастера, а общий инструмент.

🧩 Почему я предлагаю этот кейс? И что с ним делать тебе?

Это конечно не самое жесткое, что бывало, но в начале работы скрам-мастером было сложно в этой ситуации. Я 5 лет назад этого не осознавал и остановил ретроспективу. Вышел поговорить с frontend-разработчиком. После этого вернулся к команде и предложил разойтись. И решал конфликт уже в рамках 1:1. Конфликт был не только на уровне персоналий, но и на уровне процессов внутри и инструментов. Мог бы тогда на ретро затронуть важные вещи и возможно часть из них порешать. Как бы ты поступил? Может после этого вопросы ты переосмыслишь свое отношение к ретро.

3️⃣ Другие вопросы

Тут просто перечислю вопросы, которые иногда задаю на отвлечься, настроиться.

❓Если представить скрам-мастера как животное, вымышленного персонажа, героя Marvel и так далее - то кто это/что это на твой взгляд?

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

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

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

❓Команда приходит с предложением перейти на канбан. Твои действия.

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

❓Что на твой взгляд самое сложное/неприятное в работе скрам-мастера?

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

❓Расскажи определение продукта.

Задаю для того, чтобы выровняться. В некоторых продуктах неправильное понимание может очень негативно сказаться на взаимодействие с PO. На текущей работе например так обстоят дела с понятием “платформа”.

❓Кто получает больше всего пользы от работы скрам-мастера? почему?

Этим вопросом хочу понять, на каких уровнях мыслит канидидат. Говорит ли про уровень продукта и компании? говорит ли про уровень каждого из команды?

❓Может ли знание и применение коучинга мешать(!) в работе?

Один из моих любимых вопросов. Я сертифицированный коуч, но не разделяю позицию применения на работе этих навыков просто по умолчанию. Более того - работа скрам-мастера/agile-коуча в некоторой степени противоречит позиции коуча. В индивидуальном коучинге ты в первую очередь преследуешь цель своего клиента. Но что делать, если цель скажем PO явно противоречит целям компании? Этим вопросом пробую выловить “ярых адептов” коучинга везде и всем.

❓Как ты понимаешь слово “токсичность”? Что такое “токсичная команда” на твой взгляд? Что будешь делать, если увидел такие признаки в команде? Может ли токсичная команда быть эффективной?

Я часто работал с командами, которые по общим параметрам попадают под понятие “токсичность”. Плохо ли они работали? Не всегда. Сказывалось ли это на достижении их целей негативно? Не всегда. Вызывало ли это конфликты внутри команды? тоже не всегда. В команде просто может быть такой стиль общения. Мне обычно не составляет труда подстроиться и общаться в том формате, в котором комфортно в команде. Но есть скрам-мастера, кто уходит из команды потому, что там ругаются матом, говорят друг другу претензии и прочее. Этим вопросом и пытаюсь такое отловить.

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

Найм скрам-мастера, agile коуча в соседний продукт

✍️Контекст:

Ты работаешь скрам-мастером/Agile коучем и т.д. в своём продукте. Твои СРО и СТО очень довольны тобой, везде рассказывают про тебя и всячески хвалят. Даже детей собираются назвать твоим именем, вне зависимости от пола - так сильно тебя ценят.

Слава о тебе распространилась на другие продукты компании. К тебе пришли СРО и СТО из соседнего продукта и просят помощи:

1️⃣ Первая часть кейса

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

❓Вопрос:

какие вопросы нам задать на собеседовании, чтобы понять, что кандидат хороший?

🧱 Ограничение:

тебя позвать на собеседование не можем

Какие вопросы предложишь задать?

В ответах кандидаты делятся на два лагеря:

🏃‍♂️ Сразу дают варианты вопросов

Часть из них - рассказать ценности agile/scrum, теорию и так далее. Вопросы на culture fit (хрен знает, как это на русском написать. Типа свой или чужой).Часть вопросов - рассказать про кейсы с прошлых мест, результаты. Часть вопросов - предложить кейс для решения с текущего продукта. Очень много кандидатов предлагают вопросы про ценности scrum/agile, теорию и так далее. Возможно, это связано с тем, что и им в свое время чаще задавали именно такие вопросы.

🕵️ Спросить у СРО/СТО ожидания от кандидата, для чего им нужна помощь

Во втором лагере очень мало кандидатов. Большинство сразу стремится советовать. Возможно, это связано с контекстном вопроса: СТО и СРО не шарят в работе агента изменений. Но как по мне - это не повод пропустить прояснение задач. Кандидаты, которые все же задают этот уточняющий вопрос - более осознанно подходят к кейсу. И легче отвечают на вторую часть.

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

Например, кандидат предлагает вопрос: “спросите про опыт решения конфликтных ситуаций”. Ок, расскажи про такие кейсы в твоем опыте?

Польза кейса в том, что советовать всегда проще. Здесь кандидаты больше фантазируют и меньше осторожничают. Можно было бы спросить прямо - предложи сам, что у тебя спросить? Тогда кандидат выберет выигрышный для него вопрос. А метафора отвлекает и расслабляет.

Если кандидат предлагает абстрактные вопросы и про теорию скрама/аджайла - звоночек. Если предлагает кейсы и идёт запроса - хорошо.

Сначала я думал, что если у кандидата нет опыта найма - ему будет сложно. Но на этот вопрос хорошо отвечали с опытом найма и без.

После ответов на первую часть я предлагаю перейти ко второй.

2️⃣ Вторая часть

✍️ Контекст:

Прошло 3,5 месяца. За первый месяц те СРО и СТО нашли и даже успели вывести на работу человека (фантастика какая-то. Мне бы так быстро найм закрывать). Ещё 2,5 месяца новый агент изменений работал с продуктом.

СРО/СТО снова пришли к тебе за советом:

Привет. Нам снова нужна помощь. Сейчас продукт переживает не самые простые времена. Компания приняла решение немного урезать ФОТ (фонд оплаты труда), нам нужно попрощаться с 1-2 членами команды. А скрам-мастер/agile коуч как раз ещё на испытательном сроке.

❓Вопрос:

Как нам понять, был ли он полезен за эти 2,5 месяца или нужно прощаться?

🧱 Ограничение:

самому в команду идти нельзя, с скрам-мастером/ коучем самому говорить тоже нельзя.

Первое, что спрашивают - какие цели ставили перед ним? А никакие. CPO/СТО не шарят в работе агента изменений. Взяли, потому что у соседей тоже есть. И вот как раз тем, кто на первом этапе решил прояснить - дать ответ проще.

Разберём ещё несколько типовых ответов:

💬 “Спросить у команды”

Ок. 50% нейтралы, 25% оценили позитивно, 25% оценили негативно. Какой вывод нам это может дать? На мой взгляд - никакой. Конечно можно пойти спросить у тех 25% негативщиков. Но как говорил один мой коллега: “Скрам-мастер не сто долларов, чтобы всем нравиться”. Изменения - больно и неприятно, не везде можно соломку подстелить. Но если бы не ограничение на общение с командой - туда можно было бы покопать.

💬 “Посмотреть на продуктовые метрики”

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

💬 “Как изменились Lead Time, Time to Market (T2M), и другие процессные метрики”

Предлагаю кандидатам на этот вопрос такой ответ - T2M увеличился на 15%, Lead Time - на 10%. Точность планирования (соотношения запланированного к выполненному в спринте) выросла с 60 до 78%. О чем нам это говорит? Ни о чем. Только по точности планирования мы можем сделать предположение, что качество планирования и/или выполнения выросло. Может, стали меньше брать Спринт.

💬Метрики продукта и метрики роста и связь с процессом

В продуктовом управлении есть разделение на метрики тщеславия (продукта) и метрики роста. Метрики тщеславия - верхеуровневые метрики (количество скачиваний, доход), которые говорят о конечном результате продукта, а не о том, как он работает на самом деле . Метрики роста - те, что говорят о реальной работе (retention, время в сервисе и так далее в зависимости от продукта). T2M больше похож на метрику тщеславия. Пример: Команда стала быстрее проходить ревью, расширила DoD для снижения дефектов. Еще - наконец-то стали отслеживать полное время аналитики и все возвраты с бизнесом. То есть внутри - стали работать лучше. Снаружи - T2M увеличился.

В работе с процессами важно понимать и работать с метриками роста - точностью планирования, временем цикла, временем ожидания (потерями), возвратами, качеством. А T2M оставить для красивых “арбузных” дашбордов 🤐.

💬 “Посмотреть на его активности, его бэклог, результаты диагностики”

Так отвечает меньше всего кандидатов. И именно этот ответ мне кажется наиболее верным. За 2,5 месяца можно сделать хорошую диагностику, выявить и приоритизировать проблемы, достигнуть первых результатов. По настоящему сильные изменения - сложные и долгие и могут иметь отложенный эффект. Само по себе изменение T2M (даже сокращение) нам мало о чем скажет.

🧩 Почему я предлагаю этот кейс? И что с ним делать тебе?

Через то, как кандидат предлагает оценить эффективность работы героя из кейса, можно понять, как он оценивает свою. Ограничение в 2,5 месяца может тоже выявить опытного агента от читателя. Первый здраво оценивает возможный объем работ. Второй - фантазирует про все сразу.

С каждым кандидатом кейс проходит по разному. Но после большого количества собеседований стали проявляться схожести. Возможно ты найдешь в них себя. Возможно у тебя был бы иной ответ (если написать его в комментариях - он может сохранить кому-то много времени).

Уверен, не всем нравятся такие вопросы, кому-то кажутся странными. Вместе с тем, многие говорили, что такие собесы и вопросы заставляют думать по-другому, после есть о чем подумать в плане своего опыта.

Если нанимаешь сам или менторишь - попробуй задать этот кейс и посмотри ответы. Или отправь тому, кто собеседует).

Привет. Я активно провожу собеседования с 2017 года на разные позиции. За период с 2022 по 2024 год провел больше 250 собеседований с scrum-мастерами, agile коучами и руководителями agile трансформации в кластерах. На текущем месте работы кластер - это группа продуктов/платформ/сервисов. Они объединены вокруг пользовательского сегмента/индустрии или еще по какому-либо принципу. В кластере - от 300 до 1500 человек.
После такого количества собеседований я решил сместить фокус с вопросов по хардам (хотя их тоже спрашиваю при необходимости), отказаться от вопросов про ценности скрама и прочее. На мой взгляд, знание фреймворка само по себе не дает уверенности в том, как будет работать кандидат. Когда на собеседованиях были вопросы про сам фреймворк и его составляющие от меня или коллег - я начал задавать уточняющие вопросы на понимание и опыт применения. Большинство кандидатов при ответах демонстрировали теоретические знания и не могли применить это к практическим задачам.
Вместо этих вопросов у меня сформировались другие: либо кейсовые (разбор реальной или вымышленной ситуации), либо блиц-опрос на выравнивание. Многие кандидаты говорили, что такие вопросы как минимум интересны, а так же заставляют подумать, а не отвечать на автопилоте. Ниже я приведу примеры этих вопросов и расскажу, для чего их спрашиваю. Правильных ответов - нет. Важно понять, как думает кандидат и почему делает тот или иной выбор.

Блиц-опрос

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

У кандидатов всегда есть искушение ответить: “ну все зависит от ситуации, контекста” и так далее. Это понятно, но такой ответ ни о чем не говорит.

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

Вот список этих вопросов:

❓️Скрам или канбан?

Важен не сам выбор (хотя если на продукте есть особенности процесса - то это может быть критично), а то, почему ответ такой. Был ли опыт с этими подходами. Правильно ли они понимаются.

💭 Подробнее:

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

❓️Скрам-мастер или аджайл коуч?

Смотрю на то, за счёт чего отдаёт предпочтение: амбиции и рост, следование скрам-гайду (нет там коуча), или отсылки к уровням (команда, продукт, компания)и карьерному/зарплатному росту.

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

💭 Подробнее:

❓️скрам-мастер (коуч, в зависимости от выбранного) или владелец продукта?

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

💭 Подробнее:

❓️SAFE или LESS?

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

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

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

❓️Продукт на 50 или продукт на 150 человек? при условии, что твоя нагрузка не меняется (всегда не более 3 команд).

Варианты ответов:

•

50 человек. Меньше -лучше. Проще видеть свой результат, меньше комплексность.

•

150 человек - больше связей, зависимостей, кросс-командного взаимодействия.

•

Без разницы.

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

❓️конюшня или ювелирный завод?

Попробуй представить два вида продукта/команд в виде метафор.

1️⃣ Ты работаешь на конюшне. Там всегда много работы, но у тебя нет лопаты, даже нет перчаток. А лошадки активно подбрасывают тебе работу. Это как прийти в команду/продукт, где нет вообще ничего с точки зрения процессов. Нет прогнозируемости, анализа, процесс работает по воле случая и удачи. В таком продукте легче видеть результат изменений, можно начинать с базовых вещей и проще показать результат.

2️⃣ Ты - сотрудник ювелирного завода. Перед тобой на черной тряпочке красиво разложены под лампами бриллианты. Они уже ценные, их уже можно продавать. Ты каждый день смотришь на них и иногда можешь обнаружить в каком-то из них что-то, что может повысить ценность этого камня. Но это очень сложный навык. Это как прийти в команду/продукт, где процесс уже настроен, daily и ретро проведут и без тебя, причем на вполне хорошем уровне. Запланируются тоже. Даже доску шарить не нужно - команда делает все сама. Могут рассказать свою предсказуемость. Тут вызов - найти то самое полезное, что можно дать команде.

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

💭 Почему такие метафоры:

Этим вопросом я хочу выявить предрасположенность. Мне например ближе первый тип. К тому же - никто не мешает на месте конюшни открыть и маленькую ювелирную мастерскую:)

❓️стартап или корпорат?

Я все реже задаю этот вопрос, но иногда он помогает. Что ты выберешь:

1️⃣ работу в стартапе с рисками, неопределенностью, высокой скоростью изменений (что не всегда хорошо для построения процессов)

2️⃣ работу в корпорате с высоким “корпоративным налогом” (работой, которую нужно делать вне зависимости от ее необходимости в этом конкретном продукте. Стандартизация и масштабирование не только из плюсов состоят).

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

❓️запуск команды с нуля или работа с уже действующей командой со своими процессами?

Есть кандидаты, уставшие от постоянных запусков/перезапусков, рассказа базовых вещей. Чаще такие кандидаты хотят команду/продукт с имеющимися процессами.

Другие, наоборот, либо никогда не делали запуск с нуля и хотят получить такой опыт, либо хотят сразу настроить “под себя”.

Ответ на этот вопрос (с доп. вопросами конечно) может сформировать предположение о том, как стартует скрам-мастер. Какой продукт и на какой стадии может подойти больше.

🧩 Что делать с этими вопросами?

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

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

Сегодня рассмотрим модель эффективности команды Дрекслера-Сиббета. На ее основе вместе с моим бывшим напарником 🎸Димой Исаевым (@etozheisaev)

делали мероприятие по перезапуску команды.

У нас была задача от PO - встряхнуть команду. Ребята работали вместе достаточно давно. Есть и старички и новенькие, но все мероприятия проходят тухло. Люди не вовлечены в процесс. Не было чувства локтя, общие цели не были ясны. С этими вводными мы взяли запрос в проработку. Практически всю работу по проработке мероприятия Дима сделал сам.

Сначала коротко расскажу про саму модель. Она состоит из 7 этапов.

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

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

1️⃣ФАЗА: ОРИЕНТАЦИЯ. “Почему я здесь?”

Почему каждый здесь?

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

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

Мы делали так - расскажи, что с тобой было (коротко) от момента, когда ты закончил школу, до того как ты пришел сюда.

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

В первые разы на этот этап уходило слишком много времени - нужно контролировать тайминг.

2️⃣ ФАЗА: «СОЗДАНИЕ ДОВЕРИЯ». “Кто вы?”

Кто мы? С кем работаем рядом? На что должна быть похожа совместная работа? Какими навыками и компетенциями мы обладаем?

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

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

3️⃣ ФАЗА: «ПРОЯСНЕНИЕ ЦЕЛЕЙ». «Что мы делаем?»

Что делает команда? Какова предыстория проекта/продукта/компании? Каковы наши цели? Каковы убеждения? Каковы ограничения? Каковы наши задачи и роли?

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

На этой фазе:

🔎 Рассмотрели текущий CJM с командой

Даже если PO давно строит CJM, даже если он уже показывался/скидывался - точно будет много инсайтов от совместного обсуждения. Проверено много раз.

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

🎯 Составление Цели(-ей)

Нужно для фокусирования всей команды, а не только PO. Хорошо ложится после просмотра CJM. Как и обычно с целями - меньше лучше.

🎨 Составить Герб

Дима добавил этот пункт, но у меня он вызывал вопросы. В итоге я сам теперь топлю за эту активность. Драфт логотипа потом в работу взял дизайнер команды. Его разместили в лого проекта jira и в другие связанные с командой объекты. Помогает с точки зрения образа команды и сплоченности.

4️⃣ ФАЗА: «ПРИВЕРЖЕННОСТЬ». «Как дальше нам это делать?»

Как мы собираемся работать вместе? Есть ли у нас временная шкала? Бюджет? Ресурсы? Давайте сделаем все возможное!

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

5️⃣ ФАЗА: «ВЫПОЛНЕНИЕ». Внедрение «Кто, как, что, когда и где это делает?»

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

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

6️⃣ФАЗА: «ВЫСОКАЯ ПРОИЗВОДИТЕЛЬНОСТЬ». «Ура!»

Это состояние, когда команда работает как единое целое, не требует особого руководства, уважает и поддерживает друг друга и фокусируется на достижении общей цели.

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

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

7️⃣ ФАЗА: «ОБНОВЛЕНИЕ».  Обновление «Нужно ли нам продолжать?»

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

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

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

🧩 Что делать с этой информацией?

💎 Если ты планируешь делать запуск/перезапуск команды - можно взять этот сценарий за основу или его переделать. На мой взгляд - стоит разделять запуск с теорией про scrum евенты, передачи монеток и построение башен из зефирок и запуск с настройкой команды. Для второго я использую формат из статьи.

💎 Каждый из этих пунктов можно использовать отдельно. В рамках ретро или отдельного мероприятия.

💎 Перед тем, как решить это делать в своей команде - подумай, а надо ли. Может у тебя и так все отлично в команде. Стоит сначала убедиться, что есть проблемы, которые этот шаблон может закрыть.

Прошлый пост был про Value Stream Mapping (VSM). Там уже были затронуты потери и их виды. В этом не буду описывать сами виды и их историю. Это например хорошо описано ~тут~ и во многих других статьях. Приведу из своих наблюдений по основным видам.

🗑️ Излишняя обработка

• RnD(исследования). “Нам надо поресёрчить”. Нет границ у RnD, если их не ставить заранее. Когда вы поймете, что хватит? Какой ожидаемый результат? Такие исследования могут тянуться из спринта в спринт и потом выбрасываться в мусорку.
• Бесконечные совещания. Постоянные встречи без четкой цели и плана могут стать излишней обработкой, отнимая время у команды, которое могло бы быть использовано более продуктивно.
• Анализ безрезультативных метрик: Сбор большого объема данных, метрик и опросов, которые не приводят к конкретным действиям или улучшениям в работе команды, становится излишней обработкой информации.
• Очень подробные ТЗ. Особенно если в ходе разработки делается не по ТЗ :) Например, user story взяли в спринт. Не успели закончить - перенесли в следующий, потом еще раз. Когда вернулись к ее выполнению, оказалось, что ТЗ уже не везде актуально и его как минимум нужно проверить.
• Тестирование без граничных условий: Проведение избыточных тестов без учета граничных случаев и реальных потребностей продукта.

🗑️ Излишняя функциональность

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

• Работа без гипотез и прототипов. Если вы каждый раз делаете как в последний, то растет вероятность ненужной функциональности на проде. Выстроенный Discovery процесс, настроенные PBR и обсуждения с командой, приоритизация на основе метрик - все это поможет отсеивать ненужное.

Один известный писатель как-то сказал:

Художник понимает, что достиг совершенства, не тогда, когда уже нечего добавить, а тогда, когда нечего убрать.

• Очень сложно настроенный процесс в Jira. Или в другом трекере. Много статусов, правил, которыми не пользуются.
• Сложный фасилитационный дизайн встречи. Попытка решить все за раз с жетским таймингом.
• Большие сложные презентации. Которые никто не читает.

🗑️ Лишние движения

• Анализ безрезультативных метрик. Сбор большого объема данных, метрик и опросов, которые не приводят к конкретным действиям или улучшениям в работе команды, становится излишней обработкой информации.
• Избыточные смены приоритетов. Частые изменения приоритетов и задач в ходе спринта могут вызвать лишние движения и потерю эффективности.
• Частые переносы встреч. Неоправданные переносы встреч и совещаний, вызванные отсутствием решения.
• Частые изменения процесса. Внесение частых изменений в процессы работы команды без явных преимуществ, что может вызвать дополнительные трудности в адаптации. Об этом и была первая статья в канале.

🗑️ Неиспользованный творческий потенциал

Если вы хотя бы раз слышали что-то подобное: «Я не могу выполнять свои основные задачи - мне постоянно нужно делать какие-то выгрузки из Excel, презентации. Работать то когда?», то вы уже знакомы с этим видом потерь 😁.

• Несоответствие опыта и задач.Высококвалифицированный сотрудник тратит бOльшую часть времени на низкоквалифицированные задачи.
• Неиспользование смежного опыта. Обратная сторона предыдущего пункта - сотрудник со смежным опытом (разработчик, который умеет в QA, дизайнер, который умеет в верстку) не подключается к этим смежным задачам, особенно в критические для продукта моменты. Недостаток вовлеченности сотрудников смежных специализаций в работу над проектом может привести к упущению ценных идей и оптимизации процессов.
• Работа с командой в формате “заказчик-исполнитель”. Игнорирование предложений и идей от членов команды по улучшению процесса разработки и продукта. Приносить команде готовые требования без обсуждения. Не спрашивать/не слышать предложения команды по фичам, улучшениям в процессе и т.д.
• Игнорирование идей от новичков. Невозможность новичков внести свой вклад и предложить инновационные идеи из-за стереотипов их неопытности. В моей практике частое наблюдение - я новенький, зачем мне участвовать на PBR? При этом часто вопрос "новенького" ставит опытных в тупик (в хорошем смысле) и даже иногда приводит к пересмотру изначального решения.
• Отсутствие вовлеченности дизайнера в решение проблем. Не вовлечение дизайнера в решение проблем, связанных с пользовательским опытом, что приводит к упущению ценных идей.
• Скрам-мастер - невнимание к обратной связи команды. Неучтенные предложения и замечания от членов команды по улучшению процесса работы, что может привести к упущению возможностей оптимизации.

🗑️ Геройство

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

• Молчание о проблемах. На Дейли каждый день говорить «нет, у меня все в порядке, помощь не нужна», а потом ночами пытаться победить задачу. И так ее и не выполнить.
• Взятие обязательства без возможности выполнения/обсуждения с командой. «Я уже пообещал стейкхолдерам, давайте сделаем максимум!», не обсудив с командой.
• Неспособность говорить «нет». Это не всегда происходит из-за геройства, но отнесу сюда. «Нет - продакта ответ».
• Бесполезное планирование. Взятие на планировании сильно больше, чем можно сделать. Это отлично видно в Jira на графике Velocity Chart - когда серый столбец всегда существенно больше зеленого. Это еще и формирует иллюзию по возможностям команды, порождает другие виды потерь (незавершенная работа из-за переноса в следующий спринт, переключение между задачами).

• Бережливость времени: Работа в режиме "геройства", когда команда постоянно трудится сверх нормы, приводит к беспокойству, и из-за этого могут возникнуть более серьезные ошибки и потери. У меня был пример, когда работал в консалтинге проджектом у крупного заказчика на проектах SAP. В компании была своя первая линия поддержки - запросов было очень много, а сотрудников было всего трое. Для того, чтобы выполнить объем, им всегда приходилось работать в режиме аврала, перерабатывать и т.д. Это так же сказывалось и на качестве решения инцидентов. Команда поддержки могла бы сказать о нехватке ресурсов руководству, но руководство даже не знало об этих проблемах. После того, когда я поднял этот вопрос и обсудил с руководителями - им без проблем выделили дополнительные ресурсы.

🗑️ Дефекты

• Баги. Особенно - большое количество ошибок без последующего анализа. В моей практике еще не было продукта, в котором каждый баг был бы уникальным и не было бы возможности решить часть их возникновения через новые договоренности, документацию и пр. Каждый баг делает разработку функциональности дороже - команде рано или поздно придется его исправлять или продукту придется испытывать последствия от неисправления.
• Возвраты с ревью. Если возвраты с ревью - частая история, то этот процесс точно нужно исследовать. Практически в каждой команде, с которой я работал, проводили ревью. Практически в каждой команде никто не мог сказать, что именно смотрится на ревью. Тем более - не могли описать это одинаково. Часть проверок можно автоматизировать, тем же SonarQube или любым другим подходящим инструментом.
• Сделали не то. На обзоре спринта PO/бизнес говорит, что ожидал не того. Такое может случаться, если в вашей команде нет критериев приемки (acceptance criteria), критериев готовности (definition of ready). Несколько лет назад я работал в команде, в которой проблемы с приемкой повторялись практически каждый спринт. Там мы договорились - ни одна user story не может быть взята в спринт без критериев приемки и без прохода через этап PBR. Потом мы развили эту тему подстроили процесс под это, но в начале такой блок позволил готовить только нужные user story. Это кстати помогло снизить количество «влетов» в спринт.

🗑️ Ручная (лишняя) работа

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

• Отсутствие автоматизированных инструментов проверки, деплоя и пр. Сапожник без сапог. Каждой команде нужно давать время на автоматизацию своей работы. У них всегда найдутся идеи на этот счет.
• Нет автоматизации в трекере на переходы по статусам,связи. Можно настраивать автоматические переводы из одного статуса в другой по триггерам, автоматическую сортировку, представления, фильтры. Сообщения в slack/tg/прочие мессенджеры об изменении статуса. И изменения статусов задач в трекере через чаты.
• Сбор метрик продукта/процесса по запросу вручную. Раньше для более глубокого анализа я выгружал все данные в excel, там убирал выбросы, приводил в порядок данные и уже после искал идеи. Сейчас - большую часть гипотез можно проверить или найти через стандартные графики в Jira. К тому же - у нас в компании организован дашборд производственных метрик, это очень упрощает работу агенту изменений.

🗑️ Ожидание

• Аналитик написал БТ/ТЗ, которое ожидает взятия в работу (а возможно туда и не попадет - это еще одна потеря).
• Ожидание правок после ревью. Часто вижу следующее - разработчик передал задачу/user story на review. Берет новую задачу - в это время приходят правки с ревью. “Переключаться же плохо? Плохо. Доделаю то, что начал - посмотрю правки на ревью. Я же предыдущую задачу уже почти сделал!” Тем самым забивая поток вместо того, чтобы вытаскивать дальше то, что правее.
• Изменение состава бэклога спринта. То, что уже запланировано в спринт, может попасть в ожидание из-за срочных влетов.
• Зависимости внутри/вне команды/продукта. В результате таких зависимостей задачи ждут.
• Ограничение циклом планирования (в этот квартал не брали, может возьмем в следующий. но поймем это на планировании в конце этого квартала).

🗑️ Незавершенная работа

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

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

🗑️ Переключение между задачами

• "Посмотри вот это, тут 5 минут". На одном проекте на фрилансе в команде было правило - если ты не знаешь, что где искать - иди к Роме. Рома отвечал на все вопросы и в этом плане выдерживал отличный SLA, но каждый дейли он не мог сказать ничего нового по своей задаче - ему просто некогда было к ней приступить.
• Возвраты с ревью. Но теперь проблема в другом. Разработчик сделал задачу, передал на ревью. Он же не будет сидеть без дела, пока задача проходит проверку? Конечно нет! Поэтому он берет следующую задачу из бэклога. Вроде нормально. Но через какое-то время с ревью возвращается задача. Часто в таком случае приоритет отдается новой задаче. Но задача после ревью - уже была «правее», прошла больше этапов, у нее больше шансов закрыться раньше - ей и стоит отдать приоритет. Это пример, когда переключение между задачами неизбежно - выбирать стоит наиболее подходящую сейчас.

🧩 Что делать с этой информацией?

На одном из прошлых мест работы я делал ретроспективу по видам потерь. Удалось найти несколько неочевидных проблем, с которыми в дальнейшем мы с командой поработали. Что можешь сделать ты?

• Попробуй найти похожие пункты в своей команде. Если ты дочитал до конца - скорее всего у тебя в голове уже возникли похожие ситуации и примеры. Их можно просто зафиксировать для дальнейшего анализа.
• Проведи ретро с командой на тему потерь. Расскажи кратко (а не как я) про виды потерь и предложи команде набросать примеры. После этого можно сгруппировать/приоритизировать проблемы и составить action plan.
• Поищи подтверждения в метриках. Многие виды потерь можно проверить через метрики. Часто меняется состав спринта? Это видно по отчету о спринте в Jira. Много задач в ожидании? ты можешь найти их посмотреть среднее время нахождения. И так далее.

В дальнейшем, если к статье будет интерес, подумаю над чек-листом по видам потерь.

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

Value Stream Mapping (VSM)- способ анализа процесса (разного рода и масштаба). Я использую его как обязательный инструмент диагностики.

Сам по себе VSM включает в себя много правил по типу значков, связей и уровней. Мы с командой делаем его в более упрощенном виде, оптимизируя под себя. Наши VSM могут сильно отличаться друг от друга:) Использую VSM, чтобы разобраться в текущем процессе, при необходимости смоделировать новый или оценить результаты от изменений. Для создания использую Miro.

💪 Преимущества работы с VSM:

💎 Фиксация as is процесса. Спустя несколько месяцев и изменений полезно взглянуть на первоначальную картину.

💎 Можно делать до нужной глубины: отрисовать только процесс релиза или весь производственный процесс команды. А можешь зафиксировать все, что только найдешь.

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

💎 Карта процесса на ОДНОМ экране. Это важно. Чем проще информация отображена, тем проще ее понять. Меньше сил на обработку - больше сил на идеи для улучшений:)

👣 Шаги для создания VSM:

1️⃣ Определи контур исследования. Сквозной процесс нескольких команд/отделов,VSM по эпику, истории и т.д. Я начинаю с истории/эпика, если нет других вводных. Так же определи источники этих элементов (заказчики, команды, продукты). Иногда полезно определить вес каждого источника.

2️⃣ Определи ключевых участников и системы (Jira, Kaiten, notion), из которых будешь собирать информацию. В трекинговой системе смотрю фактическую длительность этапов и порядок создания сущностей. Бывает, что часть работы фиксируется в почте, презентациях, на словах. Это стоит учитывать при анализе метрик.

3️⃣ Отрисуй этапы и связи. Лучше создать как есть, а не срисовывать из Jira:).

4️⃣ Отрисуй возвраты, проблемы и вопросы. На этом этапе возникнет много идей по улучшению.

5️⃣ Определи время на этапе/между этапов, лучше из метрик. Если нет возможности - со слов. Но позже в любом случае нужно будет перепроверить.

6️⃣ Определи потери на этапах. Тут так же будет много идей по улучшениям (о потерях я напишу в следующих постах).

7️⃣ Сформируй гипотезы по изменениям процесса и to be VSM. Пока это только гипотезы:) Их еще предстоит проверить и убедиться в необходимости внедрения.

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