Узкие горлышки в процессах🔁

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

Что такое узкие горлышки?
Это те места в процессе системы, которые ограничивают производительность всей системы.

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

Инструмент идентификации узких горлышек

Один из инструментов для определения узких места - это Кумулятивная диаграмма (CFD). В большинстве таск-трекинг системах ее можно найти. (Например Jira)

Диаграмма показывает как движется работа от 1 этапа до последнего накопительным итогом.

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

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

В примере который находится в 1 комментарии грязно зеленые и салатовые линии явно отстают от красных.
Коричневые, красные, синие отстают от самого верхнего бордового.

Как работать с узкими горлышками ?

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

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

Подборка моих последних статей на habr, читайте, комментируйте, задавайте вопросы 👇

Как победить хаос в команде и управлять ожиданиями заказчиков с помощью Kanban:
https://habr.com/ru/companies/otus/articles/864608/

Фасилитация стратегической сессии по методике Уолта Диснея
https://habr.com/ru/companies/otus/articles/861986/

Run, change, disrupt или как эффективно управлять различными видами деятельности в организации
https://habr.com/ru/companies/otus/articles/861852/

Всем новеньким, привет, нас уже больше 400, спасибо вам🙏

Формат менторства.

Друзья, всем привет!

Кто не знал, напоминаю что у меня есть формат менторства, где я помогаю в развитии в профессии:
- Project и Delivery менеджерам,
- Agile коучам, Scrum мастерам,
- Руководителям разного уровня по адаптации agile подходов и развитии процессов в организации/ команде
- C-level менеджменту в менторинге в процессе трансформации.
- Основателям компаний, предпринимателям по вопросам построения команды и процессов

До нового года могу взять одного человека.

По всем запросам пишите @Agileguru

Немного юмора 😊

Всем привет в 2025! Напомню, что мы, с своими партнерами из Yandex, Sber, МТС, VK делаем крутой консалтинг по процессам, чтобы построить быстрые и гибкие команды в вашем бизнесе.

Мы все реальные практики из ТОП компаний России

Если вы сталкиваетесь с:

📌Долгим Time to market
📌Непрозрачным процессом разработки
📌Непредсказуемыми циклами поставки и постоянным фейлом сроков
📌Плохим взаимодействием и конфликтами бизнеса и ИТ

🚀То мы можем вам помочь:

🔵 Настроить квартальные циклы планирований и регулярного Delivery результата
🔵 Организовать работу 200+ человек с помощью фреймворков масштабирования (SAFe, LeSS)
🔵 Внедрить практики продуктового подхода оценки и проверки гипотез
🔵 Организовать быстрые процессы работы над разработкой продукта в условиях неопределенности и сжатых сроков с помощью Agile, Scrum, Kanban
🔵 Внедрить прозрачные метрики эффективности работы команд в виде наглядных дашбордов ( как раз запустили новый продукт под это - Aimger )
🔵 Провести обучения для команд и менеджеров в компании (да, мы делаем классные тренинги под запрос)

Если хочешь также как в Yandex, Sber, VK, МТС, пиши свой запрос @agileguru, организуем первую бесплатную консультацию и подберем оптимальный формат сотрудничества.

4 года за 1

Каждый год я ставлю цели и описываю что хочу сделать в новом году. Также как и вы скорее всего.

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

Вместо этого я начал использовать подход 4 года за 1.

То есть при постановке целей нужно рассматривать Новый год - не как год, а как квартал.

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

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

Всем успехов и крутых целей, а самое главное мотивации на их достижение 🚀

Делитесь также в комментариях как вы справляетесь с целеполаганием и личным планированием💬

Ловушка продуктовой разработки

Современные компании – от Яндекса до ВК – давно научились принимать решения, опираясь на данные:

🔵Строить гипотезы на основе данных и моделирования сценариев
🔵Принимать решения на основе A/B-экспериментов.

И другие полезные инструменты.

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

Когда продуктовая разработка становится исключительно data-driven, мы рискуем упускать реальные потребности клиентов.
Да, метрики могут расти, но понимаем ли мы, чего на самом деле хочет клиент?
Какие у него боли? Какие задачи он решает с нашим продуктом?

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

Поэтому я вижу идеальную продуктовую разработку как баланс двух мощных инструментов:

1️⃣ Данные. Метрики, тесты, A/B-эксперименты — всё это даёт объективную картину происходящего.

2️⃣ Исследования. Регулярные исследования, глубинные интервью, наблюдения — позволяют понять настоящие потребности клиентов. Выход в поля и общение с пользователем face to face - вот что ничего не заменит никакие цифры.

Без данных мы рискуем строить продукт на догадках.
Без исследования пользователей — упускать реальные потребности пользователей.

Обе составляющие важны, и только вместе они дают результат. Согласны?💬

Как строить разработку через Swarming? 🐝

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

Альтернатива — Swarming , когда вся команда работает над одной задачей одновременно

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

Ключевые принципы:

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

Почему это эффективно?
Задачи часто "стоят" из-за ожиданий (ответов, ревью, тестирования). Swarming устраняет эти паузы, так как все вопросы решаются сразу, а работа движется параллельно.

Где использовать Swarming?

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

А вы пробовали Swarming? Как вам работа в таком подходе?

Всем привет! Ищу менеджера продуктовых процессов в VK к себе в команду, кто возьмет на себя сложные и амбициозные задачи развития процессов большой компании:

https://team.vk.company/vacancy/42317/

Welcome отклики в личку или напрямую в вакансию🚀

Также буду рад рекомендациям🤝