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

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

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

Термины

Для начала, рассмотрим основные термины. Очень быстро, чтобы не терять на этом много времени. Если не хотите читать, можно сразу перейти к решению.

Бизнес-требования – это это ключевые способности или возможности, которые необходимы организации для достижения стратегических целей. Например, для достижения стратегической цели “Увеличение доли рынка на Х процентов” может возникнуть бизнес требование “Возможность реализации товаров с помощью сайта”.

Продуктовые задачи – функционал программного обеспечения, который позволяет реализовать бизнес-требования. Для предыдущего примера это может быть “Подключить он-лайн оплату” или “Добавить линейку товаров YYY”.

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

Подготовка

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

Второе, что потребуется – это создать в организации проект (Project) для управления представлениями issues. Мне нравится работать с табличным видом для создания и редактирования issues и канбан – для отслеживания прогресса.

Настраиваем Sub-Issues

1. Создаём типы задач

Для начала добавим типы issues. Они понадобятся для разделения issues по уровням. Создаём следующие типы:

• `Business` – для бизнес-требований;

• `Product` – для продуктовых задач;

• `Development` – для задач разработки.

2. Добавляем бизнес-требования

Создадим первый слой, который будет содержать бизнес-требования к продукту. Для этого создаём issue и назначаем ему тип Business.

3. Добавляем продуктовые задачи

Теперь, чтобы создать следующий слой, состоящий из продуктовых задач, внутри issue типа Business создадим sub-issue с типом Product.

4. Добавляем задачи разработки

Повторяем операцию из пункта 3, но уже для следующего слоя – задач разработки. Их создаём внутри продуктовых задач и задаём тип Development.

5. Настраиваем представления

В качестве финального аккорда настраиваем несколько досок для работы с различными слоями. У меня их пять:

1. Таблица со всеми issue с разбивкой по типам

2. По одной таблице для каждого типа задач отдельно.

3. Канбан для задач разработки.

Что получилось

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