Управление запросами на изменение (ЗНИ) ПО GetMark

1. Область применения и цели

1.1. Настоящий Регламент устанавливает единый порядок обработки запросов на изменение (далее — ЗНИ) программного обеспечения «GetMark», поступающих от Пользователей и иных заинтересованных лиц.

1.2. Цели Регламента:

• Обеспечить прозрачный и понятный процесс для всех участников.
• Снизить хаос и неопределенность при поступлении новых идей и предложений.
• Обеспечить объективную оценку каждого запроса с точки зрения бизнес-ценности и трудозатрат.
• Дать Пользователям четкий и обоснованный ответ по каждому запросу.

1.3. Настоящий Регламент является дополнением к "Регламенту взаимодействия участников при осуществлении технической поддержки" и вступает в силу для всех ЗНИ, зарегистрированных после его утверждения.

2. Термины и определения

• Запрос на изменение (ЗНИ) - официально зарегистрированное предложение от Пользователя или внутреннего инициатора о модификации существующего функционала, добавлении новой функции, улучшении производительности или адаптации ПО к новым условиям, которое не является критическим инцидентом и не требует немедленного исправления в рамках технической поддержки.
• Инициатор: Пользователь или сотрудник компании, подавший ЗНИ.
• Владелец продукта (Product Owner): Роль, ответственная за стратегическое развитие продукта, управление бэклогом и принятие решений о включении/исключении запросов.
• Бэклог (Backlog): Упорядоченный по приоритету список всех известных требований, функций, улучшений и исправлений, запланированных к реализации в будущем.
• Группа оценки: Коллегиальный орган, проводящий оценку и приоритезацию ЗНИ. Включает Владельца продукта, Технического лида (архитектора), Руководителя разработки и, при необходимости, Руководителя службы технической поддержки (для оценки операционного влияния и приоритетов клиентов).

3. Порядок подачи Запроса на изменение (ЗНИ)

3.1. Все ЗНИ регистрируются исключительно через Систему управления заявками путем создания обращения с типом "Запрос на изменение".

3.2. При подаче ЗНИ Инициатор обязан заполнить следующие поля:

• Краткое и понятное название запроса.
• Подробное описание предлагаемого изменения, его цели и ожидаемой пользы для бизнеса.
• Четкое описание бизнес-задачи или проблемы, которую решает данное изменение. Почему это важно для Пользователя или компании?
• Описание того, как данное изменение улучшит текущие бизнес-процессы (например, ускорит маркировку, снизит количество ошибок, позволит работать с новым типом товаров).

3.3. Специалист первой линии технической поддержки проверяет полноту заполнения обязательных полей. В случае неполного заполнения запрос возвращается Инициатору на доработку с комментарием о необходимых уточнениях. После принятия запроса, ему автоматически присваивается статус "Новый" и он направляется в очередь на рассмотрение Группе оценки.

4. Процесс оценки Запроса на изменение

4.1. Первичный анализ

• Группа оценки проводит первичный анализ всех поступивших ЗНИ еженедельно.
• В ходе оценки запрос анализируется:
  • не является ли данное предложение дубликатом уже существующего запроса в бэклоге или уже реализованной функции.
  • соответствует ли запрос общему видению и стратегии развития продукта.
  • решает ли запрос реальную бизнес-проблему.
• На основе этого анализа ЗНИ может быть:
  • Отклонен с обоснованной причиной (см. п. 5).
  • Переведен в статус "На оценке" для детального анализа.

4.2. Детальная оценка и расчет стоимости

• Для запросов, прошедших первичный анализ, проводится детальная оценка. 
• Срок проведения детальной оценки и формирования бизнес-кейса не должен превышать 10 рабочих дней с момента перевода запроса в статус "На оценке".
• Технический лид (или команда разработки) оценивает необходимые ресурсы, трудозатраты в человеко-часах/днях, техническую сложность и потенциальные риски реализации.
• Владелец продукта совместно с Инициатором (при необходимости) оценивает потенциальную бизнес-ценность. Она может выражаться в:
  • Привлечении новых клиентов.
  • Снижении операционных затрат пользователей.
  • Увеличении скорости работы.
  • Соответствии новым требованиям регуляторов.
• Результатом этапа является формирование "бизнес-кейса" — краткого обоснования, сопоставляющего ценность и стоимость реализации.

4.3. Планирование релиза

• На основе детальной оценки Владелец продукта принимает решение о включении ЗНИ в бэклог.
• Запросу может быть присвоен один из следующих статусов:
  • Принят в работу (запрос получает приоритет в рамках бэклога продукта)
  • Отложен (запрос признан ценным, но его реализация не является первоочередной в текущем квартале/году. Он будет пересмотрен на следующем плановом заседании)
  • Отклонен (см. п. 5).

5. Причины для отклонения Запроса на изменение

Инициатор получает мотивированный отказ в следующих случаях:

• Запрос дублирует уже существующую функцию или другой открытый ЗНИ
• Запрос противоречит стратегическому направлению развития продукта
• Запрос является единичным, узкоспециализированным и не приносит ценности для широкой аудитории пользователей
• Реализация запроса экономически нецелесообразна (затраты многократно превышают потенциальную выгоду)
• Запрос требует изменений, выходящих за рамки архитектуры ППО, и по сути является запросом на создание нового продукта
• Запрос, по которому Инициатором не были предоставлены запрашиваемые уточнения по бизнес-обоснованию или техническим деталям в течение 10 рабочих дней, может быть отклонен без дальнейшей оценки как неполный.

6. Коммуникация и статусы ЗНИ

6.1. Инициатор получает уведомления об изменении статуса его ЗНИ через выбранный им канал (email, уведомление в системе) на каждом ключевом этапе.

6.2. Статусы ЗНИ и шаблоны для ответов:

Статус ЗНИ	Значение	Шаблон ответа пользователю
Новый	Запрос зарегистрирован, ожидает первичного анализа.	"Ваш запрос на изменение зарегистрирован под номером [Номер]. Мы проведем его первичный анализ и сообщим о решении в течение 5 (пяти) рабочих дней."
На оценке	Проводится детальная оценка трудозатрат и ценности.	"Ваш запрос принят к детальной оценке. Мы анализируем его техническую сложность и потенциальную пользу для продукта. О результатах мы сообщим дополнительно."
Принят в бэклог	Запрос одобрен и внесен в план работ.	"Ваше предложение признано ценным и принято в бэклог разработки. Планируемый релиз для его реализации ориентировочно — [Квартал/Версия]. Мы уведомим вас о начале работ."
Отложен	Запрос признан ценным, но не для ближайших релизов.	"Ваше предложение признано ценным, но в данный момент не может быть запланировано к реализации. Мы пересмотрим его в следующем плановом периоде и сообщим вам о решении."
Отклонен	Отказ с обоснованием.	"К сожалению, мы вынуждены отклонить ваш запрос по следующей причине: [Причина]. Благодарим за ваше предложение и будем рады рассмотреть другие ваши идеи."
Реализован	Изменение успешно разработано и выпущено.	"Изменение, предложенное вами в запросе [Номер], успешно реализовано и доступно в версии [X.X]. Благодарим вас за вклад в развитие продукта!"

7. Роли и ответственность

Роль	Ответственность
Инициатор	Корректно заполняет форму ЗНИ, предоставляет всю необходимую информацию для оценки, отвечает на уточняющие вопросы.
Специалист 1-й линии	Принимает и регистрирует ЗНИ, проверяет полноту данных, перенаправляет на оценку.
Группа оценки	Проводит регулярный анализ всех ЗНИ, оценивает их бизнес-ценность и техническую сложность, принимает решение о включении в бэклог/отказе/отсрочке.
Владелец продукта	Управляет бэклогом, определяет приоритеты, несет окончательную ответственность за принятые решения.
Технический лид	Проводит техническую оценку трудозатрат и рисков, консультирует группу оценки по технической реализации.