Документ описывает организацию бизнес-процесса работы с требованиями в продуктовой компании с использованием Jira, акцентируя внимание на опыте автора в бизнес-анализе и управлении проектами. Представлены ключевые этапы создания структуры задач в системе, включая деление на epics, stories и subtasks, а также стратегию работы с требованиями и координацией между командами. В документе также указаны контакты автора для дальнейшего взаимодействия.

1. Организация бизнес-процесса работы
с требованиями в продуктовой
компании с помощью JIRA
Гулик Людмила

2.  в ИТ с 1999 года
 прошла путь от программиста до руководителя
отдела бизнес-аналитиков
 на позиции бизнес-аналитика с 2006 года
 большой опыт успешного внедрения как небольших
доработок по изменению существующих систем, так
и больших технически сложных проектов “с нуля”
 большой опыт анализа различных бизнес-
процессов в IT-компаниях и их успешной
оптимизации
 опыт организации с нуля отделов:
 сопровождения ПО
 тестирования ПО
 разработки требований к ПО
Мой опыт

3.  Создание с нуля отдела по разработке требований к ПО при
невозможности нанимать “дорогих” опытных аналитиков:
 Систематизация бизнес-процесса работы по требованиям к ПО
 Определение взаимосвязей между требованиями различных
продуктов
 Подготовка к совещаниям с Заказчиком
 Обработка результатов проведенных совещаний (как с Заказчиком,
так и с командами разработки и поддержки продуктов)
 Фиксирование связей между отдельными изменениями требований и
соответствующими задачами на корректировку ПО
 Организация работы по приемочному тестированию
 Фиксирование идей для будущих продуктов
 Необходимость быстрого переключения между задачами
 Оценка текущего объема работы по различным продуктам и
планирование работ по требованиям в рамках итерации
 Оперативная отчетность по статусу отдельных задач по запросу
руководства
 Ежемесячная отчетность о выполненных отделом задачах
Первоначальные вопросы:

6. Исходя из возможностей построения трехуровневой структур подчиненности
задач в JIRA: epics->stories->subtasks далее была разработана следующая
концепция общей структуры:
1. По каждому из проектов, с которыми работают аналитики, создавался свой epic
2. В рамках каждого epica создавались отдельные stories по отдельным блокам
функциональности проекта (по каждому из проектов деление было свое)
3. Для каждой из story создавались subtasks по работе с документом по
соответствующему блоку функциональности.
4. Дополнительно были созданы epics "Совещания", "Приемочное тестирование"
и "Планируемые доработки". Об их назначении расскажу немного позднее.
Product 1
Product 2
Functional
Module 1
Functional
Module 2
Functional
Module 3

11. Вопросы

12. Контакты
https://www.facebook.com/lyudmyla.gulik
https://www.linkedin.com/in/lyudmyla-gulik-a042b637/
gulik.lyuda@gmail.com