"Что будет, если взять Канбан, смешать его с Гантом и весь этот соус вылить на релизную политику? Давайте разбирать на практике!"
Привет!
Меня зовут Сергей Павлов, и я отвечаю за разработку продуктов в ИТ-экосистеме «Лукоморье».
Это российская ИТ-компания в контуре «Ростелекома», которая разрабатывает цифровые продукты для управления бизнес-процессами и проектной деятельностью. В состав экосистемы входят 15 решений, в том числе no-code платформа, собственная ESM-система, а также инструменты для полного цикла разработки и управления проектами.
В нашей команде сейчас работает более 350 крутых спецов из разных областей, которые умеют делать классные штуки и добиваться результатов. У нас есть разработчики на любой вкус – от новичков до профи, аналитики, тестировщики и другие ниндзя, которые помогают нам делать продукты и поддерживать решения.
Да и в целом ИТ-команда «Лукоморья» – организованный коллектив профи, которые умеют решать сложные задачи в разработке и управлении релизами. Это ключевой фактор успеха наших проектов.
Итак! Релизы, Канбан, Ганты… юзер стори, таски и всё такое. Предлагаю попробовать намотать эти все понятия на процесс выпуска релизов программных продуктов.
Какие проблемы у нас были
В ходе исследования управления проектами (в условиях, когда их параллельно ведется несколько) мы выявили основные проблемы. Оказалось, что сложно организовать и синхронизировать спринты разной продолжительности и с разной датой выпуска. Дополнительно осложняло ситуацию то, что команды используют многочисленные подходы к планированию тех самых релизов, и не существует общего стандарта. Это мешало точному прогнозированию и совместной работе.
● Релизный процесс напоминал «чёрный ящик» – то есть было непонятно, как он устроен изнутри. Нет списка участников деплоя, поэтому сложно управлять этим этапом и готовиться к обновлениям стендов. Также неясно, кто и за что отвечает, в каком статусе находятся задачи и сколько ресурсов на это выделено. Все это снижало эффективность и увеличивало сроки выполнения работ.
● Информация по релизам хранилась в отдельных Excel-файлах, из-за чего сложно было собрать полную картину происходящего. История развития проекта никак не визуализировалась, и это мешало анализу и принятию решений. Кроме того, подготовка отчетов по группе релизов требовала сбора данных из различных источников вручную, что делало процесс трудоемким и неудобным.
● Итого: каждый проект вел спринты по-своему, ресурсы эксплуатации планировались хаотично, а во время релизов не была сформирована (полностью) рабочая группа.
Мы поняли, что нам необходимо внедрение более структурированных и прозрачных подходов к управлению проектами. Это включало в себя разработку единой методологии ведения карты релизов, создание списка участников (рабочей группы) и стандартизацию статусов подготовки к обновлению. А ещё – внедрение инструментов для визуализации истории развития проекта, что позволило бы улучшить отчетность и повысить эффективность управления. Звучит неплохо, правда?
Да-да-да! Слышу уже твои мысли и советы: возьми MS Project и радуйся, ты что?
Кип калм, май френд, вейт э минут perfavore! Сейчас всё будет ??
Take it easy. © Фридрих Энгельс
Давайте пробовать
Гант, ты нам нужен
Представь, что ты управляешь проектом и хочешь всё держать под контролем. Для этого ты как раз и взял тот самый MS Project – программу, которая помогает организовать работу.
В MS Project ты создаешь визуальную модель проекта. То есть, представляешь все задачи и этапы в виде «отрезков» (полоски, которые показывают, сколько времени займет каждая задача). Т.к. эти «отрезки» распределены в хронологическом порядке, сразу видно, что и когда нужно сделать.
Это классика, и тут, казалось бы, даже добавить нечего.
Наверняка у тебя уже появилась мысль: «Серёг, а зачем что-то менять? Работает – не трожь! Расходимся».
И вот тут мы плавно подходим к той самой идее «гибкого Ганта». Гибкий Гант, о_О, звучит весьма интригующе. Этот термин вызвал у меня живой интерес, и я намерен использовать его в дальнейшем.
Как мы знаем, Jira ушла, громко хлопнув дверью, а на её место пришла наша православная Яга (если что тут ссылка)! Первое, на что я обратил внимание, собственно, это и есть то, про что я хочу сегодня рассказать, — это гибкость Яги. Она позволяет кастомизировать систему практически под любые бизнес-процессы, запросы и задачи. Ограничения в ней определяются не функциональными возможностями, а исключительно пределами вашей фантазии.
Поясню: придумай, какую задачу ты хочешь решить, и попробуй сделать это в Яге. Конкретно сейчас мы обсуждаем ведение карты релизов разных проектов в одном месте, с указанием зон ответственности и исполнителей.
Как решаем проблему
Если кратко — выделяем несколько глобальных пунктов
Все проектные инициативы должны быть визуализированы на единой информационной платформе, что обеспечит прозрачность для всех заинтересованных сторон.
Для каждого релиза необходимо сформировать специализированные группы участников и назначить конкретных исполнителей, чтобы повысить эффективность распределения задач и улучшить координацию между членами команды.
Каждый релиз должен быть ассоциирован с определенным статусом, отражающим его текущее положение в процессе разработки. Кроме того, следует внедрить систему статусов, которая позволит осуществлять мониторинг и контроль за ходом выполнения проектов на всех этапах.
ТРИ – счастливое число. Думаю, можно пробовать реализовать.
Как мы видим, перечень типов карточек практически неограничен и зависит исключительно от креативных возможностей пользователя. Настройка бизнес-процесса в целом выглядит вполне себе стандартно – указываем, какие статусы могут быть, а также указываем, как этой штуке можно переходить из статуса в статус, а как нельзя.
Я думаю, нет смысла рассказывать, как настраивать бизнес-процесс, особенно для профессионалов, читающих Хабр. Лайк и подписка вам за это!
Этим я хотел показать саму идею – создаём сущность “Релиз”, добавляем ей статусы.
Планирование -> В разработке -> Регресс -> Демо -> Установлено -> Архив
Далее накидываем необходимые поля:
Дата релиза
Участники релиза (причастные именно к поставке)
Статус сборки пакетов backend
Статус сборки пакетов frontend
Ссылка на changelog
Статус смоук тестирования
Статус регресс тестирования
Статус НТ тестирования
Ссылка на отчет о тестировании
Ссылка на отчет об НТ тестировании
Ответственный за бэкапирование перед релизом
Ответственный за работы в БД
Ответственный за установку пакетов
Ссылка на план отката
Состав релизной команды со стороны разработки и тестирования
Вуаля! Мы сделали кучу дел с помощью метода «двух кликов»!
Разложив эти карточки в виде Ганта перед глазами, мы получаем полную картину, какие релизы за какими идут. Видим статусы релизов, участников, да и в целом пересечения по проектам (если такие имеются). Дополнительно появляется масса функций в виде обсуждений, заметок и прочих таск-трекинговых интересностей, что помогает лучше управлять проектами и работать всей командой эффективнее.
А ещё есть «приколы» вида валидаций заполненности необходимых полей, без которых релиз – не релиз. Б – бюрократия, но в приятном виде.
Not P.S. пока реализовывали идею с релизами, по аналогии сделали сущность «хотфикс» и всё это объединили вместе (релиз, является родительским элементом хотфикса).
Раз, два, три, четыре, пять – я иду объяснять:
В каждой карточке релиза, как было упомянуто ранее, предусмотрены обязательные поля для идентификации участников проекта. В частности, указываются лица, ответственные за различные аспекты разработки и внедрения, такие как поставка бэкенда/фронтенда, разработка технического задания, проведение тестирования, а также выполнение или планирование установки на прод. Эти данные обеспечивают доступ к ключевой информации о задействованных лицах, что позволяет оперативно устанавливать контакты и взаимодействовать с ними при необходимости.
Все поля являются обязательными для заполнения, что исключает возможность возникновения ситуации информационного вакуума в критический момент. Таким образом, обеспечивается непрерывность и прозрачность процессов управления проектом.
Дополнительно в карточке релиза фиксируются зависимости, метки, названия релизов и другие данные, которые играют важную роль в визуализации и анализе информации на общем дашборде. Эти элементы способствуют более глубокому пониманию структуры и динамики проекта, а также его интеграции в общую экосистему разработки.
И штош у нас в итоге. Проблему решили?
Вот, что мы получили:
БАМ ? – Внедрение карты релизов с интуитивно понятным интерфейсом, устраняющим необходимость в сложных процедурах, таких как «толкание плечами». Это позволяет эффективно прогнозировать и планировать релизы в рамках совместной работы.
БАМ ? – Разработка детальных пошаговых процессов для заведения и планирования релизов с акцентом на удобство использования и минимизацию бюрократических процедур. А интуитивно понятный интерфейс избавил нас от скучных инструкций-лонгридов.
БАМ ? – Прозрачность и доступность информации о статусе подготовки и исполнения релиза для всех участников. Группировка хотфиксов относительно главного релиза и предоставление исторических данных о развитии продукта позволяют более эффективно управлять процессами и принимать обоснованные решения. Следует отметить, что release notes также должны быть интегрированы в карточку релиза для обеспечения полноты информации.
БАМ ? – Расширение списка участников релиза способствует повышению его качества за счет увеличения скорости коммуникации и повышения уровня ответственности. Это способствует более слаженной работе команды и достижению поставленных целей.
БАМ ? – Адаптация к современным требованиям и отказ от устаревших методов работы, никаких эксель-таблиц! Достаточно даже телефона, чтобы можно было получить информацию по релизам, тем самым обеспечивается гибкость и оперативность в управлении процессами.
Думаю, теперь моя мысль гибкого Ганта понятна: Яга – это не просто инструмент управления, а действительно гибкая платформа, которую можно подстроить под уникальные процессы. Она объединяет структурность и наглядность с возможностью глубокой кастомизации, благодаря чему команды работают в удобной для себя логике, не подстраиваясь под жесткие рамки чужого продукта.
Вы не любите котиков? … вы просто не умеете их готовить ;)
У меня всё!
Adios!