Можно ли использовать Jira не только для управления разработкой, но и для управления всей “машинерией” организации - от страт. целей, портфеля проектов, рисков до повседневной работы команд? Я называю такой подход джирократией. Это концепция единого бесшовного технологичного пространства, в котором стратегия и исполнение связаны между собой в виде привычного Jira-инструментария.

Какие вообще есть подходы?

1. “Салфеточный менеджмент”: стратегия на салфетке Стратегия обсуждается на встречах, архитектура - на доске, планы - в Excel, поручения - устно, а риски - в головах руководителей и экспертов. У такого подхода есть преимущества: простота, гибкость и минимум адм. нагрузки. Для небольшой команды этого может быть вполне достаточно. Но по мере роста организации информация расползается по разным местам. Возникает зависимость от конкретных людей, а целостная картина становится всё менее понятной.

2. ИТ-классика (“полуджирократия”): операционка в Jira, стратегия отдельно Здесь Jira уже стала привычным рабочим инструментом. В ней живут задачи, Kanban-доски, спринты, инциденты и техническая документация. Но стратегический уровень по-прежнему находится отдельно: OKR - в презентациях, портфель проектов - в бухгалтерии, риски - в Excel, распределение ответственности - в должностных инструкциях и устных договорённостях. Связь между стратегией и работой команд поддерживается вручную: совещаниями, отчётами и постоянной синхронизацией. Jira отлично показывает, чем заняты разработчики, но не всегда отвечает на вопрос, как эта работа связана с целями организации.

3. “Полная джирократия”: единое пространство стратегии и исполнения Это подход, о котором я и хочу поговорить. Идея в том, чтобы связать управленческие страт. сущности с операционкой в одной бесшовной системе.

Что это даёт на практике? - Портфель проектов. Видно, какие проекты реализуются, каковы их статусы, приоритеты, совокупные риски и потребности в ресурсах. - OKR и стратегические инициативы. Цели и измеримые результаты связаны с инициативами, проектами и конкретными задачами. - Риск-менеджмент. У рисков есть владельцы, оценки, планы реагирования, связи с проектами, на которые они влияют, с конкретными задачами митигации, а также наглядная историческая динамика. - Планирование и исполнение. Диаграмма Ганта и Kanban становятся разными представлениями одного пространства работ, привычным и для топ-менеджмента, и для технарей. - Ответственность. Обязанности и зоны ответственности фиксируются и связываются с конкретными людьми. - Развитие сотрудников. Компетенции, планы обучения и проф. развития можно можно точно так же планировать в Kanban и связывать с практическими инженерными задачами.

В результате появляется сквозная цепочка: Стратегическая цель Goal -> ключевой результат OKR -> инициатива -> проект -> риски -> этапы -> задача -> исполнитель -> результат

Можно двигаться по ней в обе стороны: от стратегии к конкретной работе или от выполненной задачи к цели, ради которой она была поставлена.

Jira - не волшебная таблетка

Конечно, сама по себе Jira этого не обеспечивает. Нужна глубокая кастомизация Jira: продуманная модель кастомных типов тикетов, доп. поля, ЖЦ workflows, автоматизации, плагины. Здесь важен баланс: не нужно усложнять систему ради самой системы, не пытаться превратить каждую управленческую мысль в тикет. Хорошая модель управления должна помогать принимать решения и выполнять работу, а не создавать дополнительную бюрократию. Вполне можно построить эффективное управление и на Excel. А Jira превратить в неудобное нагромождение сотен полей и статусов. Всё определяется не инструментом, а качеством процессов и зрелостью организации.

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

А как у вас выстроена связь между стратегией и повседневной работой команд?

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