Разрабатывая ПО на заказ, в какой-то момент мы начали очень плотно взаимодействовать с клиентом. У нас организованно все управление проектами в Jira. С одной стороны, заинтересованный в результате, вовлеченный заказчик — это всегда хорошо, с другой — отсутствие единой платформы для коммуникации создавало новые проблемы:
- множество разрозненных каналов обмена информацией — лишнее время на систематизацию данных;
- произвольное изменение приоритетов — сломанный график команды разработчиков, паузы из-за вынужденного переключения между задачами;
- нечеткие требования в постановке задач — потеря времени на запрос конкретики;
- «туманный» статус задач (закрыта, открыта, тестируется, дорабатывается) — сложности с прогнозированием сроков работ и разделением ответственности.
В этой статье мы расскажем о том, как с помощью Jira упрощали и автоматизировали процесс, преодолевали эти и другие, возникающие по ходу, трудности, и к чему в итоге пришли.
Забегая вперед: всего было четыре варианта воркфлоу, все с бэкапом. Такой подход позволяет в любой неприятно-неожиданной ситуации откатить изменения, вернувшись к стабильной версии, и безопасно начать трансформацию сначала.
Дисклеймер: В марте 2022 года компания Atlassian прекратила поддержку юридических лиц на территории РФ. Однако эти ограничения не распространяются на уже приобретенные версии Jira, а также на юридические лица, зарегистрированные вне РФ. Так или иначе, найти выход, который позволит пользоваться привычным инструментом, как прежде, несложно.
Первая версия
Изначально задачи ставились через службу Jira Servise Desk, создавая тикет (кстати, клиент пользуется этим инструментом до сих пор — сообщает о багах). В этой статье рассказали как за 10 шагов настроить первую рабочую версию в Jira Servise Desk.
При всех плюсах метод имел существенный недостаток: заказчик узнавал об изменениях, когда с нашей стороны задача была уже завершена. Это лишало нас возможности обсудить детали в процессе: приходилось возвращаться к закрытым задачам. Понимая управление проектами в Jira, да и целом, как все мы знаем, это бывает затруднительно, особенно, когда ты занят другим делом.
Естественным решением стало подключение ответственных со стороны заказчика к воркфлоу проекта, чтобы те могли отслеживать и корректировать прогресс в реальном времени.
Первая версия была сделана на скорую руку, как временный инструмент. Однако с течением времени обе команды отметили, что такой подход значительно облегчает взаимодействие. Было принято решение о дальнейшей оптимизации воркфлоу.
Вот так выглядела постановка задач изначально
Данный вариант помог решить первую актуальную проблему — отсутствие промежуточных статусов, которые были необходимы для своевременного согласования процессов с заказчиком, из-за чего воркфлоу ломался и выглядел нелогичным.
Вторая версия
Рост проекта (программный продукт по ходу разработки усложнялся и масштабировался) параллельно с увеличением уровня взаимодействия команд, закономерно требовал модернизации рабочих процессов. И она произошла. (Это естественный процесс для понимания управление проектами в Jira)
На этом этапе заказчик попросил добавить новые статусы — «Готово к тесту на DEV» и «Тест на DEV», поскольку у него добавился новый стенд, и это нужно было отразить в воркфлоу. Спустя время возникла необходимость упростить отслеживание исполнителя задачи, в зависимости от ее статуса.
Третья версия
Оптимизировали схему уже привычно, так как у команд появились новые предложения.
Звучало это так:
“Мне одной кажется не интуитивным, что задачи, которые еще не залиты на “прод”, отправляются в “готово”? Кейс: вот сейчас на мне задача, которая прошла мой тест и далее будет теститься только на “проде” заказчиком. По нашему флоу я ее должна перевести в “готово”. Хотя, по сути, она не прошла колонку “тестирует заказчик”, так как эта колонка для дева. Сорри, у меня уже наболело в этом месте и я каждый раз не знаю, как поступать с задачами после тестов. Надо что-то менять. У кого был опыт, очень интересно ваше мнение, как улучшить флоу.”
Если перевести с человеческого на протокольный, проблема прежних итераций была в следующем:
- статус задачи не давал понимания, на каком стенде она задепроена;
- в результате задача уходила в «готово», хотя не прошла приемку заказчиком.
В итоге из-за отсутствия статуса клиент попросту не понимал, на какой стадии реализации находится задача и что по ней осталось сделать.
Четвертая версия
По итогам комментария (смотри выше) была предложена следующая схема воркфлоу:
А здесь уже более наглядно представлено, какие действия происходят после каждой стрелки.
Четвертая (окончательная) версия воркфлоу
Почему именно такой флоу статусов?
Он учитывает наличие трех стендов (dev, test, prod). Это важно, так как задачи деплоятся постепенно, проходя все стенды (c dev на test, c test на prod). С помощью статусов мы точно знали, на каком стенде находится задача. Подробнее про типы задач в Jira рассказали в статье.
Что дала наглядность тестировщику и клиенту?
Теперь по колонкам можно легко оценить, заблокирован ли деплой стенда или нет. Обычно это происходило так:
- клиент спрашивает, когда ждать фичу на проде;
- тестировщик смотрит, какие задачи есть на стенде;
- анализирует, что протестировано, а что нет;
- и выносит решение — деплоим или нет, а если не деплоим, то говорит, какая задача блокирует деплой.
Сложность такого подхода в огромном количестве задач, которые невозможно было отследить без колонок, да еще на трех стендах.
Варианты действий при переходе в статус «готово»
На скрине видно, как срабатывают внедренные функции (1 и 2) при переносе задачи из «готово в прод» в «готово», но на всякий случай расшифруем:
- Resolved — у задачи автоматически появляется галочка, означающая, что она выполнена. Обычно ее ставят руками, а если забывают, то задача считается невыполненной и в статистику не попадает — это проблема. Теперь она решена.
- Primary — у задачи меняется исполнитель в зависимости от того в каком столбце/статусе она находится. Еще одна полезная функция, позволяющая автоматически менять ответственного, исключая фактор человеческой ошибки (забыли поменять).
- дефолтная опция — меняет статус на готово;
- дефолтная опция — добавляет возможность комментировать задачу;
- дефолтная опция — добавляет запись в историю;
- дефолтная опция — синхронизирует запись с базой данных;
- дефолтная опция, которая отвечает за автоматическое оповещение об изменениях в карточке задачи.
Настройки подключения клиента на нашу доску Jira суммарно заняли около трех дней (фидбэк от заказчика поступал с задержками), хотя при необходимости, весь процесс можно сократить до одного дня.
Итоги: какие выводы мы сделали в процессе трансформаций воркфлоу, зная управление проектами в Jira?
Если измерять результаты оптимизации в цифрах, по нашим оценкам работа над проектом ускорилась на 10-15%.
По ощущениям, эти цифры можно увеличить как минимум вдвое, но для этого необходимо донести всем участникам проекта важность изменений.
Например, чтобы локализовать канал коммуникаций до Jira, нужно отучить сотрудников взаимодействовать (в рамках проекта) через почту и мессенджеры. Практика показывает, это сложнее, чем кажется на первый взгляд.
Увы, но без контроля не обойтись. Придется системно отслеживать все отклонения от процедуры и заставлять делать правильно. Здесь очень помогает периодический общий сбор для получения обратной связи от участников.
Результаты в тезисах:
- у нас появился постоянный эффективный (для всех сторон) инструмент взаимодействия;
- коммуникация с заказчиком стала более системной, улучшилось взаимопонимание, течение проекта стало прозрачным;
- снизился показатель ТТМ (Time to Market) — увеличилась скорость перехода от идеи к реализации;
- локализация общения в одном канале помогла устранить информационный шум.
Если вам нужна помощь в профессиональной организации рабочих процессов, оставьте заявку на внедрение или поддержку Jira. Мы разберем вашу проблему и расскажем, что можем предложить, исходя из нашего понимания управление проектами в Jira за последние 15 лет и реализации более 40 проектов.
