К бюрократии многие (как правило) настроены негативно: она замедляет процессы, замедляет решения, нужно возиться с каким-то документами, с заявками, условиями и т.д. Предлагаю на неё посмотреть под другим углом.

——— Жил был один латентный управленец Акакий.

Акакий был хорошим парнем. Он хотел стать настоящим управленцем. Он умел всё (или так ему казалось). И он никому не отказывал

Когда заказчик говорил: «Нам срочно нужна эта таблица/отчет/данные!» — Акакий отвечал: «Сделаем!» «Можно чуть изменить логику?» — «Конечно!» «А завтра будет готово?» — «Уже в работе!»

Но… • он не уточнял цели и эффекты • не согласовывал приоритеты и сроки • не фиксировал договорённости

Вместо этого он просто обещал — и шёл дальше.

А команда получала: • 10 «срочных» задач • противоречивые и изменчивые требования «на словах» • нулевое понимание, что важно, а что — шум • отсутствие времени на проверку результатов и документацию

В результате: • Релизы — как лотерея, никто не знает, что в них и какого качества • Код — превратился в «ком грязи» • Ценность — никто не понимал • Люди — выгорали и уходили

Акакий думал, что ведёт за собой. На самом деле — размывал границы, превращая команду в “универсальный сервис поддержки”

Когда он ушёл, остался только хаос. И вопросы:

«Что делать с накопленными обещаниями и негативом от невыполненных этих обещаний?»

«А что делать такой команде, условия в которой стали несопоставимы со здоровой работой?»

«А что если надо ещё и масштабировать этот хаос?» Масштабировать «комок грязи» точно не стоит (будет еще больше грязи), а тем более такими темпами будет и не с кем.

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

Масштабировать нужно только то, что можно автоматизировать, ручники - не масштабируемы

🚀На помощь приходит бюрократия

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

Что она предлагает здесь сделать:

• разобрать процесс на части как он есть сейчас и описать новый (как хотелось чтобы оно работало)

• описать типы задач, которые команда принимает и типы задач, которые находятся вне зоны ответственности команды с контактами к кому по этим задачам обращаться

• описать формат, в котором принимаются задачи (входные документы и чек-листы, данные и т.п.), и где (в почте, мессенджерах, джире и т.п.)

• описать сроки выполнения и реагирования в зависимости от типа задач

• описать критерии приоритизации по типу задач

• описать уровни критичности проблем (багов) в системе и сроки закрытия

• сделать прозрачным бэклог и «задачи в работе» для всех стейкхолдеров

• сделать общие встречи и в приоритезацию задач вовлекать всех стейкхолдеров

Благодаря этому подходу в команде появляются:

▫️ Чёткие правила приёма задач: «Если нет цели, фин.эффекта, заполненных чек-листов — задача не принимается»

▫️ Границы ответственности: «Мы делаем X. Всё остальное — не наша зона»

▫️ Прозрачные сроки и бэклог: «Высокий приоритет» = 1 день, «низкий» = 4 недели, а эту задачу не берём, так как не вмещается (но можете переприоретизировать)

Получается, что бюрократия — не враг (не всегда)😁 Это инструмент защиты для тех, кто хочет: — работать осмысленно и системно — масштабироваться без разрушения и не масштабировать разрушения

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

💬 А у вас в команде был такой Акакий или помогала ли вам бюрократия? Делитесь мыслями в комментариях без стеснения❤️