Недавно мы с коллегами обсуждали современные подходы к управлению проектами и финансами. И всё чаще в этих разговорах всплывает одна и та же идея — микро-степс.

Если делаем MVP — делаем итеративно, быстро, срезая углы. Микро-степс.

Если проектируем архитектуру — ограниченные контексты, домены, микросервисы. Микро-степс.

Если берём задачу — декомпозируем максимально мелко, желательно до дня. Микро-степс.

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

На первый взгляд это выглядит как гибкость. На практике — нет.

Такие модели почти не учитывают: — внешние ограничения — корпоративный контекст — реальную сложность системы

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

Самое неприятное здесь другое. Под лозунгом «гибкости» мы незаметно встраиваем waterfall в каждый шаг.

Каждый микро-степ — это инструкция. Каждая инструкция — это фиксированный путь. А стратегия исчезает.

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

Лично мы пока остаёмся в другой модели. Модель управления через цели и метрики.

Наверху: — опаздывающие показатели — целевые значения, связанные с бизнес-результатом

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

Метрики декомпозируются сверху вниз — до уровня команды и конкретного человека.

Но при двух условиях: — метрики считаются прозрачно и честно — цели выбраны осознанно, а не ради отчёта

Вывод Микро-степс — полезный инструмент. Но плохая стратегия.

Если дробление становится заменой мышлению, мы теряем способность развиваться и принимать сложные решения.

Гибкость — это не количество шагов. Гибкость — это понимание целей и свобода выбора пути к ним.

А вы что думаете? — О канале 👉 https://t.me/manager_dot_exe Про управление IT и продуктом: цели, метрики, архитектура и системные решения.