☑️Бюрократия защищает и развивает команду / компанию. К бюрократии многие (как правило) настроены негативно: она замедляет процессы, замедляет решения, нужно возиться с каким-то документами, с заявками, условиями и т.д. Предлагаю на неё посмотреть под другим углом. 🔘🔘🔘🔘🔘🔘 Жил был один латентный управленец Акакий. Акакий был хорошим парнем. Он хотел стать настоящим управленцем. Он умел всё (или так ему казалось). И он никому не отказывал Когда заказчик говорил: «Нам срочно нужна эта таблица/отчет/данные!» — Акакий отвечал: «Сделаем!» «Можно чуть изменить логику?» — «Конечно!» «А завтра будет готово?» — «Уже в работе!» Но… • он не уточнял цели и эффекты • не согласовывал приоритеты и сроки • не фиксировал договорённости Вместо этого он просто обещал — и шёл дальше. А команда получала: • 10 «срочных» задач • противоречивые и изменчивые требования «на словах» • нулевое понимание, что важно, а что — шум • отсутствие времени на проверку результатов и документацию В результате: • Релизы — как лотерея, никто не знает, что в них и какого качества • Код — превратился в «ком грязи» • Ценность — никто не понимал • Люди — выгорали и уходили Акакий думал, что ведёт за собой. На самом деле — размывал границы, превращая команду в “универсальный сервис поддержки” Когда он ушёл, остался только хаос. И вопросы: «Что делать с накопленными обещаниями и негативом от невыполненных этих обещаний?» «А что делать такой команде, условия в которой стали несопоставимы со здоровой работой?» «А что если надо ещё и масштабировать этот хаос?» Масштабировать «комок грязи» точно не стоит (будет еще больше грязи), а тем более такими темпами будет и не с кем. Масштабировать нужно только то, что хорошо и стабильно работает, где выстроены процессы и есть регламенты. Масштабировать нужно только то, что можно автоматизировать, ручники - не масштабируемы 🚀На помощь приходит бюрократия Кто бы мог подумать, что такая нелюбимая ИТ-шниками вещь может стать им другом и защитником😁 Что она предлагает здесь сделать: • разобрать процесс на части как он есть сейчас и описать новый (как хотелось чтобы оно работало) • описать типы задач, которые команда принимает и типы задач, которые находятся вне зоны ответственности команды с контактами к кому по этим задачам обращаться • описать формат, в котором принимаются задачи (входные документы и чек-листы, данные и т.п.), и где (в почте, мессенджерах, джире и т.п.) • описать сроки выполнения и реагирования в зависимости от типа задач • описать критерии приоритизации по типу задач • описать уровни критичности проблем (багов) в системе и сроки закрытия • сделать прозрачным бэклог и «задачи в работе» для всех стейкхолдеров • сделать общие встречи и в приоритезацию задач вовлекать всех стейкхолдеров Благодаря этому подходу в команде появляются: ▫️ Чёткие правила приёма задач: «Если нет цели, фин.эффекта, заполненных чек-листов — задача не принимается» ▫️ Границы ответственности: «Мы делаем X. Всё остальное — не наша зона» ▫️ Прозрачные сроки и бэклог: «Высокий приоритет» = 1 день, «низкий» = 4 недели, а эту задачу не берём, так как не вмещается (но можете переприоретизировать) Получается, что бюрократия — не враг (не всегда)😁 Это инструмент защиты для тех, кто хочет: — работать осмысленно и системно — масштабироваться без разрушения и не масштабировать разрушения Когда процессы чёткие — люди дышат свободнее. Команда фокусируется на ценности, а не на пожарах. И хаос остаётся за дверью. 💬 А у вас в команде был такой Акакий или помогала ли вам бюрократия? Делитесь мыслями в комментариях без стеснения❤️