Как я склеиваю большие проекты

 Публичный пост
29 июня 2022  1042

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

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

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

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

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

Only Jira

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

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

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

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

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

Итак, дано

  1. Команда внутри моей компании
  • релизы фронта

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

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

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

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


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

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

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

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

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

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

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

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

16 комментариев 👇

@airiney привет!

Можешь рассказать про свое видинье идеального Jira Flow?

И как научится таки готовить Jira ;) Что для этого нужно? Как училась ты??

  Развернуть 1 комментарий

@alekseisnuff, подумала, что это отличная тема для следующего поста=)
Но на пальцах использую в идеале так:
Эпик – это все, что требует по времени больше, чем 1 спринт разработки.
Эпик распадается на Стори (иногда сразу на таски, если проект технологический или эпик маленький). Каждая стори – распадается на Development tasks, analytic task, и другие активности.
У каждой задачи свой жизненный цикл, базовый, как правило, есть уже автоматически. Но его удобнее кастомизировать, зная процесс своей команды.
У меня на девеломпент тасках такой: open-in development-devdone-code review-in test-testdone-done

  Развернуть 1 комментарий

@airiney, оо, было бы здорово в след. посту про это ещё подробнее узнать ;)

  Развернуть 1 комментарий

для таймлайнов хорош mermaid

gantt
    title План П
    dateFormat  YYYY-MM-DD
    section 4.0.1
    Фича           :a1, 2022-08-01, 14d
    Деплой прод    :after a1  , 7d
    section 4.0.2
    Фича      :2022-08-12  , 14d
    Деплой демо     : 14d

из джиры можно доставать апишечкой через cli в текст

текст ИМХО лучше любого Notion (https://github.com/todotxt/todo.txt как пример) потому что правило 2g:

  1. g/re/p
  2. git

специализированные инструменты хорошо и нужно, но когда нужен репорт с перламутровыми пуговицами (а он нужен всегда) текст рулит.

  Развернуть 1 комментарий
Виктор Диктор , Руковожу разработкой 2 июля в 08:33

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

Механика была схожая. Есть проектный план и в него сводится вся цепочка из задач. Сами задачи могут находиться где угодно, главное чтобы был ответственный человек который может сообщать об изменениях за прошедшую итерацию.

Могу порекомендовать посмотреть на более специализированные программы чем Notion, например на Microsoft Project, Merlin Project, OmniPlan, ...

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

  Развернуть 1 комментарий

@kevit, да, по факту я всегда пишу репорт словами для менеджмента высшего и для своей собственной команды. Что делаем и в какие сроки на ближайшую неделю/спринт/месяц/год.
Но пишу руками=) так сильно не научилась пока запариваться с качеством репорта)

  Развернуть 1 комментарий

А теперь можно нахер выкинуть ноушн и оставить гугл таблицы или excel. А потом и джиру нахер выкинуть, потому что когда есть нормальные таблицы, то уже пофигу что за таск-трекер, хоть на глиняных дощечках. И будет уже матерый проджект ;)

  Развернуть 1 комментарий

Jira с Notion подружены на авто-загрузку, или все на ручках носится?

  Развернуть 1 комментарий

@akarpov, нет, руками пока=) автоматизация не думаю, что мне поможет. у меня многие задачи остаются без джиры, ссылаются просто на треды в слаке. И задачи на стороне партнера точно не автоматизировать, туда нет никакого доступа.
Быть может можно было бы бота в слаке настроить, но я не знаю, как

  Развернуть 1 комментарий

Не люблю Jira не потому что не умею готовить, а потому что почти для всего нужен какой-то дополнительный плагин, и в итоге стоимость в год выходит в десятки тысячи евро.
Хочешь чтобы какие-то поля при создании сабтаски копировались из родительской? Плагин, 2к евро в год
Хочешь чтобы виджет считал данные с учетом специфичного кейса? Из коробки не поддерживаем, но есть плагин, всего за 3к евро в год сделает это для вас.
И по итогу ты работаешь не так как хочешь, а так как смог собрать не желая платить тысячи евро :) Но работа заставляет, потому что "корпоративный стандарт"
Есть пример работы с YouTrack, параллельно с Jira, и там даже пакет на такое же количество пользователей в разы дешевле, и плюс любые "плагины" можно написать самому (или попросить разработчиков). Правда с Ютреком работал года 4 назад уже, возможно там все поменялось

  Развернуть 1 комментарий

@nopost, ну дп, понимаю вашу боль. Но работаю в корпорации, поэтому спокойно отношусь к этому, все плагины при мне=)

  Развернуть 1 комментарий

@nopost, у меня в жире основная проблема отключить всего по-максимуму, а не подключить нового))

  Развернуть 1 комментарий

@ganqqwerty, это и правильно. лишние поля, параметры, статусы, сбивают с толку. хорошо настроенный джира-флоу, уже полдела в коммуникации команды

  Развернуть 1 комментарий

@nopost, поля в сабтаски и без плагинов умеют копироваться :)

  Развернуть 1 комментарий

@airiney привет! А подскажи, пожалуйста, где ты рисуешь такой таймлайн?

  Развернуть 1 комментарий

@kkobylyanskiy, привет, это в Miro

  Развернуть 1 комментарий

😎

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

Что вообще здесь происходит?


Войти  или  Вступить в Клуб