Польза в стандартизации

Привет. Сегодня поделюсь мыслями про стандартизацию процессов в нашей работе. Например, в компании предлагают стандартизировать доски и процесс в 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 приводятся интересные примеры того, что теряет компания, избегая использования общих инструментов и разумной стандартизации.

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

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

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

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