Я набила много шишек, разбираясь с тем, каким инструментом удобнее вести проект. Когда-то мне казалось, что знание инструментов и умение построить хорошо Ганта – это супер важно для деливери менеджера. На деле, всем по фигу, в чем ты там это рисуешь. Важнее всего, чтобы ночью разбудили, и ты смог сказать:

• когда релиз,
• что мешает релизу организационно
• какие баги-блокеры есть в сборке

Однако, чтобы на эти вопросы отвечать, менеджеру нужно уметь разложить пасьянс из хаотичной информации, которая сыпется к нему со всех сторон. Команды бывают разные. Бывают продуктовые команды размером «на 4 пиццы», где все друг друга знают и деливерят по идеальному скраму, раз в две недели, делая регресс и выкладку на прод четко по расписанию.

Бывают проекты, которые делаются руками смежных команд, сложные, намешанные и очень трудно управляемые.

У меня бывали разные команды, во всех в них я успешно факапила в начале, потом как-то разбиралась и вырабатывала решение. И вот такие примерные решения у меня сложились для глобально двух разных типов управления проектом:

Only Jira

Jira идеальный инструмент, когда вам надо работать с бизнесовым и техническим беклогом, и вся команда находится в одном информационном пространстве.

Я обожаю идеальный Jira Flow, в котором задачка распадается от Business Feature до DevelopmentTask. Я убеждена, что те кто не любит Jira, просто не умеют ее готовить. Ну и отдельный труд – обратить всех участников процесса в верное понимание и работу с Jira, тогда она становится крутым облегчающим жизнь инструментом.

Jira и клей в виде Notion

Сейчас прохожу интересный опыт работы с большой разнородной командой, часть которой находится внутри моей компании, часть – в компании-партнере. В общей сложности нужно следить и увязывать между собой 3 основных команды разработки, в каждой из которых свой релизный цикл. И еще 2-3 команды периодически деливерят для нашего продукта, но их релизы не лежат на критическом пути выхода в продакшн.

Важный момент: команда моей компании и команда партнера не имеют доступа к Jira-трекерам друг друга по правилам политики безопасности, которые, к сожалению, пока не обойти.

Итак, дано

1. Команда внутри моей компании

• релизы фронта

• релизы бекенда

2. Команда партнера

• общий релиз продукта партнера, под который должны успеть отдать свои задачи остальные команды.

Первое что я делаю, это формирую скоуп проекта в Notion. Сразу скажу, что в Notion я новичок, не было особо времени научиться виртуозно использовать этот инструмент, поэтому пошла по наитию и делаю все максимально топороно. Собственно, за тем и пишу этот пост, чтобы услышать ваши мнения и советы.

Начинается все со вкладки Эпики, которая, по сути, состоит из продуктовых задач. Каждая из них нарезается на более мелкие задачки, которые распадаются по командам. Команды вы видите на скрине ниже во вкладке «Задачи по командам»:

«Партнер iOS» – это задачи, которые делаются силами разработчиков iOS в команде партнера. «Партнер Android» – аналогично задачи разработчиков Android. «SDK iOS» – задачи, которые разрабатываются внутри моей компании-производителя некоего SDK. На самом деле команд еще штук 5, помимо тех, что вы видите, просто я не стала их показывать, чтобы не путать вас. Команду бизнеса я выделяю в отдельную команду, там задачи готовятся к взятию в релиз, и я могу видеть, кого из продактов пора поторопить, если он хочет успеть выкатить фичу в прод.

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

Важнейшие «клеевые свойства» Notion проявляются в том, что я прикрепляю ссылки на Jira-таски партнеров и моей команды в данный беклог. Я вначале сильно этому сопротивлялась, но в итоге могу сказать, что поддерживать такую историю не так уж и трудно, стоит один раз навести в ней порядок. В итоге у нас получается искусственно созданное пространство, где есть задачи всех команд.

Далее можно переходить во вкладку «Релизы» и увидеть точную картину того, что попадает в определенный релиз продукта.

Но помимо Notion мне еще нужен Timeline, чтобы не запутаться в датах и планировать последовательность релизов.

Таймлайн я рисую примерно один раз в квартал. То есть я знаю, что в среднем одна команда релизится раз в три недели, другая – раз в неделю, третья – раз в две недели. Наношу даты релизов всех команд на таймлайн и начинаю собирать паззл будущего релиза в Notion.

Далее начинают вступать в силу различные факторы, которые даты релизов сдвигают, и я начинаю менять состав задач релиза. Повторять до готовности, как говорится.

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