Система управления продуктом в Notion + Jira

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

Так понимают скрам 90% людей. Говорить о том, что это не корректно думаю не нужно. Скрам для меня — это в первую очередь управление продуктом и созданием ценности. Когда смотришь на эту методологию с этой стороны, то все становится на свои места.

Ниже #LongRead о том, как в notion + jira выстроили систему управление продуктом. Если често, это выглядит колоссально.

Notion — это управление знанием и целями продукта. Jira — это управление процессом разработки. В Notion ведем управление на уровне больших задач, в Jira управляем процессом именно разработки.

Обычно, одна задача в Notion(мы их называем Epic) разбивается на 10 — 20 конкретных задач для разработчиков. Переключаясь между Notion и Jira можно вести управление на разных уровнях детализации.

У меня 9 команд в объекте управления. Не 9 человек, а 9 команд. Это вполне достаточно, что бы устроить хаос.. особенно когда у тебя продуктовая разработка.

Я решил визуализировать термин “Helicopter View” и как бы показать себе “как выглядит весь процесс управления с высоты”

Главная страница Notion состоит из основных разделов, каждый из которых доступен в один клик.

В быстром доступе в меню доступны все разделы и спейсы команд и кланов (это вообще отдельная история, расскажу об этом потом и сюда прикреплю ссылку)

Все эпики я могу посмотреть в разрезе всех команд. Тк у каждого эпика есть поле “Team” — то в целом очень легко это все фильтровать.

Я настроил несколько View для того, что бы работать с беклогом.

Last Added — Последние добавленные эпики. По сути просто список отсортированный по дате добавления.

By Priority — Есть поле “Priority” — и на отдельной странице задачи отсортированные по этому полю. Так же там отображаются только те задачи, которые еще не “закрыты”

Board — Канбан доска по статусу эпика. Кроме стандартых ToDo/InProgress/Done у нас есть анализ задачи и Demo. Каждая задача обязательно должна пройти демо.

Sprints — Все команды работают в рамках единых спринтов. Спринты начинаются в одно время и заканчиваются в одно время. Это помогает синхронизироваться и планироваться. И у каждого эпика есть поле

Sprint — можно добавить один эпик хоть в сотню спринтов.

Need Filling — Каждая задача/эпик должны быть качественно оформлены. Эта страница настроена фильтрами таким образом, что бы выводить только те Эпики, в которых есть не заполненные важные поля (типа статус задачи, спринт или команда)

Need Filling Sprint/Release — мы же тут про скрам и разработку, значит каждый эпик должен существовать в разрезе спринтов и в конечном итоге быть зарелизенным. Значит у задачи должны быть заполнены эти поля.

В результате, я могу разделить процесс grooming backlog’а, планирования спринта и синхронизацию между всеми командами прям визуально. Главное, мне не нужно копировать и вести отдельно задачи, которые ведутся в каждой команде. Каждый Project Manager ведет свои задачи в спейсе команды, но при этом он работает с теми же эпиками.

С Helicopter View мне стало очень удобно, но если 9 команд не будут работать со мной в одном backlog’е, то идею ждет провал.

Зачем видеть весь backlog Project Manager’у, который ведет один проект? Правильно, не нужно видеть. Нужно для каждой команды выстроить удобный и уютный мирок, в котором они будут работать, но при этом его синхронизировать с Helicopter View.

Внутри Epic’ов есть поле “Team”. Можно легко настроить фильтры и показывать только ту информацию, которая нужна команде.

Почему я говорил именно про Epic’и? Мы в вели у себя условие — все что находится на уровне продукта — это Epic.

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

Конечно, для управления разработкой мы используем Jira. Создаем задачу в notion, линкуем ее с Epic’ом в Jira и уже там детализируем.

То есть у нас есть два уровня управления: на уровне продукта и на уровне разработки.

Всегда можно провалиться в Jira и уже на уровне разработки увидеть как обстоят дела.

Для тех, кто хочет прям потыкать и посмотреть как это работает в “живую” — оставлю открытый пример в своем телеграм канале — https://t. me/when_ros