Кто принимает потребность, где её описать и как передать коллегам. Пройдите путь на учебном примере — даже если вы впервые открываете Jira.
Для Delivery и смежных командСхема + пример + тренажёр
Процесс готовится к согласованиюЗдесь показана предлагаемая схема взаимодействия. Владельцы этапов, обязательные поля Jira и сроки проверки ещё должны быть подтверждены Юлией и Максимом. Пилот пока не запущен.
Что нужно понять сначала
Запрос может прийти в письме, на встрече или в чате. Задача Delivery — превратить его в понятное описание работы и сопровождать до результата. Для каждого перехода нужны ответственный, материалы и подтверждение, что следующий участник принял работу.
Одно место для задачи
Собираем контекст в Jira
Описание, ссылки на первичный запрос, оценки и решения должны быть связаны между собой. Коллега должен понимать задачу без поиска по личным перепискам.
Понятный следующий шаг
Передаём готовый результат
Перед оценкой нужны требования. Перед запуском — согласование. Перед уведомлением клиента — подтверждённый состав и дата выпуска.
Это роли в предлагаемой схеме. Один сотрудник может совмещать несколько ролей, но для конкретного запроса должно быть понятно, кто отвечает за каждый результат.
Потребность клиента
Delivery
Команда внедрения и сопровождения клиентов. Выясняет, что нужно клиенту и зачем, собирает материалы, оформляет запрос и сообщает клиенту результат.
На выходе: понятная постановка и связь с клиентом на всём пути.
Техническое решение
IT и разработка
Аналитики, дизайнеры, разработчики и тестировщики. Определяют, как реализовать запрос, оценивают трудоёмкость, разрабатывают и проверяют изменения.
На выходе: техническая оценка, проверенное изменение и готовность к выпуску.
Проверка передачи
Юлия · проверяющий на пилоте
Предлагаемая роль: проверить полноту запроса и связи задач, помочь направить его нужным специалистам и проконтролировать сбор оценок.
Нужно согласовать: участие в пилоте, границы проверки и заместителя.
Решение о расходах
Уполномоченный руководитель
Подтверждает, какую работу делаем, кто её оплачивает, какой бюджет принят и с каким приоритетом можно запускать разработку.
На выходе: зафиксированное решение о запуске или отказе.
А где в процессе клиент и Sales?
Клиент объясняет потребность, подтверждает согласованные с ним требования и участвует в приёмке. Условия оплаты согласуются отдельно.
Sales — продажи. Если нужна предварительная оценка для предложения клиенту, Sales передаёт сценарий и границы запроса. Предварительные часы ещё не являются обещанием цены и даты выпуска.
03 / Рабочие инструменты
Где всё это оформляется
Карточка и история работы
Jira — «Джира»
Система учёта задач. У задачи есть название, описание, номер, ответственный, статус и комментарии. По номеру или ссылке коллеги открывают одну и ту же карточку.
Понадобится корпоративный доступ. Если он не выдан, обратитесь к своему руководителю.
Обсуждение и передача
Slack — рабочий чат
Каналы объединяют обсуждения по теме. Тред — ответы под одним сообщением. В канал оценки передаётся ссылка на запрос, а итоговые решения фиксируются в Jira.
Канал #estimate используется для координации оценок. Правила передачи на пилоте ещё согласуются.
Пять терминов, которые встретятся в Jira
Проект
Раздел Jira, объединяющий задачи определённой команды или направления.
Epic
Крупная головная задача, которая связывает общую потребность и отдельные работы. Для клиентских доработок предлагаем использовать её как общую карточку запроса.
Task / Bug
Задача на работу / задача об ошибке. Тип и нужный проект выбираются по содержанию запроса.
Estimate
Оценка трудоёмкости, обычно в часах. Количество часов и календарная дата готовности — разные величины.
Релиз
Выпуск изменений. Release ticket — техническая задача выпуска; Release Notes — понятное описание изменений для пользователей.
Посмотрите реальные экраны JiraВ главе «Создаём первый запрос» показаны форма, названия полей и заполнение. Снимки обрезаны до нужных элементов; клиентские данные вымышлены.
04 / Общая схема
Как запрос становится результатом
На схеме — этапы работы, а не названия статусов Jira. Желаемая дата клиента становится подтверждённым сроком только после проверки плана командой.
Понять потребностьDelivery · клиент и сценарий
Описать запросDelivery + IT · границы и критерии
Получить оценкуIT · часы, допущения и риски
Согласовать запускРуководитель · объём и бюджет
Разработать и проверитьIT · реализация и тестирование
Выпустить и принятьIT + Delivery · выпуск и клиент
Выберите, с чем к вам пришли
Клиент просит новую возможность
Соберите проблему, сценарий, границы и критерии приёмки. Предлагаемый маршрут: головная задача → аналитика при необходимости → оценка → решение о финансировании → разработка → релиз и приёмка.
Клиентская доработка: действия по шагам
1. Получить запрос и уточнить, что нужно
Кто
Ответственный Delivery.
Что сделать
Сохранить первичное сообщение. Уточнить пользователя, проблему, текущий сценарий, ожидаемый результат и причину срока.
Результат
Понятная потребность и контакт для уточнений. Если данных мало — перечень конкретных вопросов клиенту.
2. Оформить карточку и связать материалы
Где
Предлагаемое место — головной Epic в DEV. Точный проект и обязательные поля подтверждаются до пилота.
Что сделать
Заполнить шаблон из тренажёра ниже, приложить ссылки. IT помогает определить, нужны ли отдельные задачи на аналитику (BAN), дизайн (DESIGN) и платформы.
Результат
Одна головная ссылка. Неизвестные условия отмечены явно, а материалы относятся к одной версии требований.
3. Проверить полноту и запросить оценку
Кто
Delivery, проверяющий на пилоте и технический специалист.
Что сделать
Проверить сценарий, границы, критерии приёмки и открытые вопросы. Передать ссылку в #estimate после подтверждения готовности пакета.
Результат
Версия оценки по компонентам, итог часов, риски и допущения. Предварительная оценка помечена как предварительная.
4. Зафиксировать решение о запуске
Кто
Уполномоченный по бюджету; Delivery фиксирует решение.
Что сделать
Подтвердить объём, плательщика, стоимость и приоритет. Записать согласовавшего, дату и источник решения.
Результат
Явное разрешение на запуск. Согласие с количеством часов само по себе такого разрешения не заменяет.
5. Разработать, протестировать и подготовить выпуск
Кто
IT разрабатывает и тестирует; Delivery проверяет бизнес-сценарий в согласованном порядке.
Что сделать
Связать работы с выпуском. Подтвердить состав релиза, ограничения и техническую готовность. Подготовить клиентский текст.
Результат
Проверенная работа, решение о выпуске и понятное описание изменений для клиента.
6. Сообщить клиенту и завершить работу
Кто
Delivery и IT; для платных работ — финансовый ответственный.
Что сделать
Зафиксировать уведомление, результат приёмки и замечания. Ошибки связать с исходной задачей. Проверить документы и оплату, если применимо.
Результат
Известно, что получил клиент, что принято и кто ведёт оставшиеся вопросы.
05 / Работа в Jira
Создаём первый запрос
От кнопки «Создать» до заполненной карточки. Ниже — реальные фрагменты Jira Домопульта, проверенные 09.09.2026. Текст примера вымышлен; задача не сохранялась.
Что подтверждено, а что ещё согласуетсяНазвания кнопок и полей проверены в интерфейсе. Использование Эпика в DEV как единого входа для всех клиентских доработок остаётся проектом процесса. Сначала согласуйте этот маршрут для пилота.
Шаг 1 · Открыть форму
Зайдите в Jira и нажмите «Создать»
Откройте Jira Домопульта под своей корпоративной учётной записью. Кнопка «+ Создать» находится в верхней панели рядом с поиском. На странице «Для вас» не нужно сначала открывать чужую задачу.
1. Кнопка в верхней панели открывает форму. Она ещё не создаёт задачу.
Если Jira не открывается или кнопка недоступна, запросите доступ у своего руководителя. Конкретного администратора доступа нужно добавить в инструкцию после подтверждения.
Шаг 2 · Выбрать место и тип
Проверьте DEV (DEV1) и «Эпик»
В верхней части формы откройте выбор раздела и убедитесь, что выбран DEV (DEV1). Рядом откройте тип и выберите «Эпик». В проверенной форме были доступны «Задача», «История», «Баг» и «Эпик»; первоначально стояла «История».
2. Сокращённая форма после выбора Эпика. Значок с диагональными стрелками вверху справа — «Развернуть».
Нажмите «Развернуть», чтобы увидеть остальные поля. Jira запоминает часть выбора, поэтому перед каждым запросом проверяйте раздел и тип заново. Если сразу открылась полная форма, переходите к заполнению.
Шаг 3 · Описать потребность
Заполните «Резюме», описание и имя эпика
Резюме — название задачи. Предлагаемый формат: «Клиент — действие и результат». Например: «УК Учебная — выгрузка заявок в Excel».
Описание — поле сразу под названием. Вставьте сюда подготовленную постановку: инициатор и источник, проблема, результат, границы, материалы, срок, плательщик и критерии приёмки.
Имя эпика — отдельное поле в развёрнутой форме. Нажмите его и задайте короткую подпись, например «Выгрузка заявок». Это не поле описания.
На снимке — сокращённый пример для демонстрации интерфейса. Полный шаблон находится в следующем разделе.
3. Полная форма с учебным содержанием. Нажмите снимок, чтобы открыть его крупнее.
Шаг 4 · Проверить остальные поля
Материалы, связи и планирование
Вложение: перетащите файл или нажмите «просмотр». Прикладывайте только необходимые материалы: ТЗ, обезличенный пример, макет. Ссылку на первичный запрос укажите в описании.
Привязанные задачи: используйте для существующих связанных работ, когда понятен тип связи. Наличие ссылки не равно правильной связи с Epic — конкретный способ привязки дочерних задач ещё проверим отдельно.
Исполнитель: в форме стояло «Автоматически». Уточните, кто должен вести задачу по согласованному процессу. Не считайте, что это значение автоматически назначает менеджера Delivery.
Приоритет: в форме стоял Medium. Опишите влияние и срочность в постановке; изменение приоритета должно опираться на согласованный порядок.
Дата релиза и срок исполнения: не переносите сюда желаемую дату клиента как уже подтверждённый план. Пока даты не согласованы, зафиксируйте пожелание и его основание в описании.
Компоненты, версии, спринт, разработчик и особенности реализации: заполняются по технической маршрутизации. Если значения неизвестны, не подбирайте их наугад.
4. Дополнительные поля полной формы. Список может отличаться в других проектах или при других правах доступа.
«В работу» уже стоит в форме — что это значит?В проверенной форме такой статус выбран до создания. Он сам по себе не подтверждает бюджет, назначенного разработчика и фактический старт. Отдельное решение о запуске нужно зафиксировать по согласованному процессу.
Шаг 5 · Сохранить рабочий запрос
Проверьте содержание перед нижней кнопкой «Создать»
Когда оформляете настоящий согласованный по маршруту запрос, проверьте раздел, тип, название и постановку. Затем нажмите нижнюю кнопку «Создать». В отличие от кнопки в верхней панели, это действие сохраняет задачу.
Если Jira укажет недостающие обязательные поля, заполните их по смыслу. Точный набор обязательных полей на сохранении в этой демонстрации не проверялся: учебная задача не создавалась.
После сохранения откройте созданную карточку, скопируйте её ссылку и убедитесь, что описание, материалы и ответственный указаны верно. Передавайте в Slack ссылку на карточку вместе с конкретной просьбой: проверить полноту, провести аналитику или собрать оценку.
Для тренировки используйте форму ниже. Если открыли в Jira несохранённый учебный пример, закройте его крестиком. В проверенном диалоге «Изменения не будут сохранены» кнопка «Отменить» отбрасывает введённое, а «Вернуться назад» возвращает к заполнению.
06 / Оценка
Передаём запрос на оценку и следим за результатом
После сохранения Jira-задачи Delivery передаёт одну ссылку в #estimate, помогает устранить вопросы и получает сводную оценку. Часы — ещё не разрешение начинать разработку.
Граница между фактом и пилотомИспользование #estimate, ответы по компонентам и последующая сводка подтверждены рабочими тредами. Единые критерии готовности запроса, срок ответа и формальная роль Delivery пока не утверждены — ниже они обозначены как предлагаемый порядок для пилота.
Jira готоваКонтекст, границы, критерии, материалы
Тред в #estimateОдна ссылка и конкретная просьба
Оценки частейКоманды фиксируют часы и допущения
Сводная оценкаИтог, риски и версия
РешениеПлательщик, приоритет и запуск
Шаг 1 · Подготовить передачу
Проверьте, что оценщикам есть что оценивать
Откройте сохранённую Jira-задачу. В ней должны быть понятны клиент и пользователь, проблема, ожидаемый результат, границы первой версии, критерии приёмки и ссылки на материалы. Неизвестное запишите как открытый вопрос.
Не назначайте технические команды наугад. Если неясно, нужны ли аналитика, дизайн, BACK, FRONT, iOS, Android, QA или работы по выпуску, попросите технического координатора подтвердить состав оценщиков.
Когда рано запрашивать итоговые часыЕсли неизвестен основной сценарий, нет границ работы или от результата ждут разные вещи, сначала нужна аналитика или уточнение требований. Можно запросить предварительный диапазон, но его следует явно так и назвать.
Шаг 2 · Создать один тред
Напишите в #estimate и приложите ссылку на Jira
Создайте одно родительское сообщение на одну доработку. Дальнейшие уточнения и отметки собирайте в его ответах, чтобы история не распалась на несколько каналов и личных переписок.
Шаблон передачи на оценку
Коллеги, нужна оценка клиентской доработки: [ссылка на Jira].
Клиент / контур: [название]
Что оцениваем: [краткий результат и границы]
Тип оценки: [предварительная / итоговая]
Желаемый срок ответа и основание: [дата или «не задан»]
Открытые вопросы: [перечень или «нет»]
Просьба подтвердить состав оценщиков и зафиксировать оценки, допущения и риски в Jira.
Имена конкретных специалистов и групп добавляйте после подтверждения технической маршрутизации. Сообщение «посмотрите задачу» без ожидаемого результата передачи недостаточно.
Шаг 3 · Сопровождать оценку
Следите не за количеством ответов, а за полнотой результата
Ответ «оценил» подтверждает действие одного участника, но не означает, что собрана вся оценка. Сверяйте нужные компоненты с полученными часами: что уже оценено, что не применимо, что ждёт уточнения и кто должен ответить.
Рабочая формулировка
Что она означает и что делать Delivery
На уточнении
Оценщикам не хватает конкретных данных. Получить вопросы, обновить Jira и сообщить в том же треде, какая версия постановки изменилась.
На компонентной оценке
Состав оценщиков понятен, но получены не все части. Перечислить ожидаемые и полученные компоненты; не складывать неполный итог.
Оценка собрана
Есть версия, состав работ, оценки частей, итог, допущения, риски и исключения. Передать на коммерческое и управленческое решение.
Согласовано к запуску
Отдельно подтверждены объём, плательщик, стоимость, приоритет, согласовавший и дата решения. Только после этого передавать в план разработки.
Это понятные формулировки для коммуникации, а не подтверждённые названия статусов Jira.
Шаг 4 · Вернуть на уточнение
Не пересоздавайте запрос и не начинайте новый тред
Соберите вопросы оценщиков, уточните их у клиента или владельца сценария и внесите ответы в Jira. В треде коротко перечислите, что изменилось. Если изменились границы, назовите новую версию постановки и попросите пересмотреть затронутые оценки.
Шаблон ответа после уточнения
Обновил(а) постановку в Jira: [ссылка].
Уточнено:
— [ответ на вопрос];
— [изменившаяся граница];
— [добавленный материал].
Версия требований: [дата / номер]. Просьба подтвердить, какие оценки нужно пересмотреть, и зафиксировать обновлённые часы и допущения.
Шаг 5 · Зафиксировать результат
Сведите оценку так, чтобы её можно было согласовать
В Jira должны остаться: версия и дата оценки; оцениваемый объём; часы или диапазон по компонентам; правило суммирования; общий итог; допущения, риски и исключения; кто выполнил техническую проверку. Если оценки пересматривались, сохраните причину и обе версии.
Шаблон сводной оценки
Версия оценки: [дата / номер]
Объём: [что входит в эту версию]
Оценки по компонентам:
— Аналитика: [часы / не требуется / ожидается]
— Дизайн: [часы / не требуется / ожидается]
— BACK: [часы / ожидается]
— FRONT: [часы / ожидается]
— iOS / Android: [часы / не требуется / ожидается]
— QA и выпуск: [часы / включены в другую оценку / ожидаются]
Итого: [часы или диапазон]
Допущения и риски: [перечень]
Не входит: [перечень]
Технически проверил(а): [имя, дата]
Следующий шаг: согласовать плательщика, стоимость, приоритет и запуск.
Часы не равны сроку и ценеКалендарная дата зависит от очереди, доступности специалистов, зависимостей и релизного плана. Стоимость рассчитывается только по подтверждённой ставке и затем согласуется отдельно.
На каких реальных примерах основана глава?
Подтверждённый факт · 17.08.2026: в треде по DEV1-2555 запрос на оценку был опубликован со ссылкой на Jira; участники отмечали выполненные оценки, после чего отдельно запрашивалась фиксация оценки в задаче. Открыть тред в Slack ↗
Подтверждённый факт · 28.08.2026: в сводке по нескольким функциям были перечислены оценки по компонентам, общие часы и риски, а затем запрошено отдельное решение — что брать в работу и с каким приоритетом. Открыть сводку в Slack ↗
Ограничение: единый норматив передачи Delivery → #estimate и обязательный SLA в доступных материалах не подтверждены. Поэтому шаги проверки готовности и формулировки статуса являются предложением для пилота.
07 / Решение и запуск
Согласовываем стоимость и передаём в разработку
Сводная оценка отвечает на вопрос «сколько труда потребуется». Чтобы начать работу, нужно отдельное решение: какой объём делаем, кто оплачивает, на каких условиях и с каким приоритетом.
1. Какой объём?Ссылка на конкретную версию требований и оценки.2. Кто платит?Клиент, Домопульт или иной согласованный бюджет.3. Сколько?Внутренняя стоимость и клиентские условия не смешиваются.4. Кто разрешил?Имя уполномоченного, решение, дата и источник.
Стоп-сигналЕсли хотя бы одного ответа нет, задача остаётся на согласовании. Статус Jira «В работу», готовая оценка или устное «давайте делать» сами по себе не заменяют запись решения.
Шаг 1 · Зафиксировать версию
Заморозьте предмет согласования
Перед запросом решения сверьте scope и оценку. В сообщении и Jira должна быть одна и та же версия: что входит, что не входит, итоговые часы, допущения и риски. Если оценивается диапазон, нельзя использовать только нижнюю границу без объяснения условий.
Не переписывайте старую оценку без истории. При изменении требований создайте новую версию, укажите причину пересмотра и перечислите затронутые компоненты.
Шаг 2 · Определить тип финансирования
Сначала классификация, затем плательщик
Классификация
Как действовать
Ошибка / гарантия
IT подтверждает, что фактическое поведение не соответствует принятому результату или обязательству. Не выставляйте работу клиенту автоматически только из-за наличия часов.
Общий продукт
Запрос полезен нескольким клиентам или развивает платформу. Решение о бюджете Домопульта принимает уполномоченный руководитель.
Клиентская доработка
Scope создаётся для конкретного клиента. Delivery или коммерческий владелец подтверждает с клиентом необходимость, цену и условия до запуска.
Технический долг
Работа нужна для устойчивости или сопровождаемости, но не является обещанной клиентской функцией. Требуется отдельный владелец бюджета и техническое обоснование.
Не определено
Поставьте отметку «требуется классификация» и вынесите вопрос IT и уполномоченному по бюджету. Не выбирайте плательщика по ощущениям.
Кто первым попросил — не всегда тот, кто платитЕсли клиент сформулировал общепродуктовую потребность, это ещё не основание переносить на него всю стоимость продукта. И наоборот, внутренняя польза не отменяет согласованных платных условий конкретной клиентской работы.
Шаг 3 · Подготовить решение
Разделите трудоёмкость, внутреннюю стоимость и предложение клиенту
Трудоёмкость — подтверждённые часы или диапазон. Внутренняя стоимость — расчёт по действующей ставке или условиям подрядчика. Клиентская цена — коммерческое условие, которое может отличаться от внутренней стоимости. Не подменяйте одно другим.
Ставку, НДС, порядок оплаты, аванс, акт и договор берите из действующих финансовых документов или подтверждения ответственного. В инструкции намеренно нет универсальной ставки: её актуальность и применимость должны проверяться для каждой работы.
Карточка решения
Запрос: [Jira-ссылка]
Клиент / контур: [название]
Версия scope и оценки: [дата / номер]
Что входит: [кратко]
Что не входит: [кратко]
Трудоёмкость: [часы или диапазон]
Основание внутренней стоимости: [ставка / договор / смета]
Внутренняя стоимость: [сумма и НДС, если применимо]
Классификация: [ошибка / гарантия / продукт / клиентская работа / техдолг / требуется решение]
Предлагаемый плательщик: [клиент / Домопульт / иной бюджет]
Клиентская цена и условия: [сумма / требует согласования / не применимо]
Желаемый приоритет и основание: [влияние, обязательство, дата]
Риски и зависимости: [перечень]
Решение требуется от: [роль / имя]
Шаг 4 · Получить явное решение
Попросите выбрать действие, а не просто «посмотреть»
Шаблон запроса согласования
Нужно решение по доработке [название и Jira-ссылка].
Согласуемая версия: [дата / номер]
Scope: [кратко]
Оценка: [часы]
Стоимость и плательщик: [сумма, условия, источник]
Приоритет и основание: [кратко]
Риски: [кратко]
Просьба подтвердить один вариант:
1) делать — scope, плательщик, сумма и приоритет согласованы;
2) не делать;
3) вернуть на уточнение — указать, какой вопрос нужно закрыть.
Если работа платная для клиента, внутреннего разрешения недостаточно: коммерческий владелец должен зафиксировать, что клиент согласился с ценой и условиями. Не обещайте старт или дату до этого подтверждения.
Шаг 5 · Записать решение
Оставьте в Jira проверяемый след
В головной задаче зафиксируйте решение, дату, согласовавшего и ссылку на первичный источник. Добавьте утверждённый scope, итоговую трудоёмкость, плательщика, внутреннюю стоимость, клиентские условия, приоритет и открытые ограничения.
Если решение принято в устной встрече или личном чате, перенесите краткий протокол в Jira и попросите подтвердить его у уполномоченного. Это не новое согласование, а фиксация уже принятого решения.
Запись решения в Jira
РЕШЕНИЕ О ЗАПУСКЕ
Статус решения: [согласовано / отклонено / вернуть на уточнение]
Версия scope и оценки: [дата / номер]
Плательщик: [значение]
Согласованная сумма и условия: [значение]
Приоритет: [значение и основание]
Ограничения: [значение]
Решение принял(а): [имя и роль]
Дата и источник: [дата, ссылка]
Следующее действие и ответственный: [что, кто]
Шаг 6 · Передать в план разработки
Получите подтверждение, что работа действительно принята
После согласования IT создаёт или актуализирует связанные платформенные задачи, назначает ответственных, определяет зависимости и место в плане. Delivery передаёт ссылку на запись решения и запрашивает календарный ориентир.
Шаблон передачи после согласования
Запуск согласован: [Jira-ссылка].
Решение и согласованная версия зафиксированы в головной задаче: [ссылка на запись].
Просьба подтвердить:
— состав связанных задач;
— ответственных по компонентам;
— зависимости и блокеры;
— плановый слот / календарный ориентир;
— способ контроля готовности к тестированию и релизу.
Ответственный Delivery за клиентскую коммуникацию: [имя].
Что ещё не считается запускомСозданные платформенные задачи без исполнителей и контрольной даты; статус «В работу» по умолчанию; согласованная сумма без приоритета; обещание клиенту без подтверждённого плана IT.
Почему нужен отдельный шлюз решения?
Подтверждённый факт · 28.08.2026: после публикации сводных оценок и рисков был отдельно запрошен выбор задач для запуска и их приоритет. Значит, завершение Estimate и разрешение на разработку фактически разделены. Открыть сводку в Slack ↗
Подтверждённое наблюдение · 01.09.2026: в проверенной выборке пять крупных Jira-задач имели статус «В работу», но не имели исполнителя, срока и release. Поэтому сам статус не доказывает фактический старт.
Исторический документ · 15.06.2026: в описании процесса оценки упоминались коммерческие пороги и порядок оплаты. Их актуальность на 09.09.2026 не подтверждена, поэтому конкретные пороги не перенесены в рабочую инструкцию. Открыть документ ↗
Предлагаемый контроль: считать задачу согласованной только при наличии четырёх ответов — scope, плательщик, сумма и уполномоченный, разрешивший запуск. Персональный список согласующих и место обязательных полей в Jira нужно утвердить перед пилотом.
08 / Разработка
Контролируем разработку и держим Delivery в курсе
После согласования задача не исчезает внутри IT. Delivery контролирует клиентское обязательство и понятность статуса, а IT — технический план, исполнителей, зависимости, качество и прогноз.
Роли не подменяют друг другаDelivery не назначает разработчиков и не оценивает технический процент готовности. IT не должен восстанавливать клиентский контекст по личным чатам. Оба контура работают через один головной запрос и связанные Jira-задачи.
Шаг 1 · Подтвердить фактический старт
Проверьте четыре признака, а не только статус
Связанные задачиПонятно, какие компоненты реализуют согласованный scope.ОтветственныеУ каждой активной части есть исполнитель или владелец.Следующая датаЕсть контрольное событие: старт, результат, проверка или пересмотр.ЗависимостиЗафиксированы блокеры, внешние решения и порядок частей.
Когда эти признаки подтверждены, Delivery может сообщить, что работа принята в план. До этого корректный статус — «запуск согласован, ожидаем подтверждение технического плана», а не «разработка началась».
Подтверждение старта
Фактический старт по [Jira-ссылка]
Согласованная версия scope: [дата / номер]
Связанные активные задачи: [ссылки]
Ответственные по компонентам: [имена / роли]
Текущий этап: [аналитика / дизайн / разработка / интеграция]
Следующее контрольное событие и дата: [что / когда]
Зависимости и блокеры: [перечень или «нет известных»]
Технический владелец прогноза: [имя]
Ответственный Delivery: [имя]
Шаг 2 · Читать комплект задач
Смотрите на цепочку, а не на одну карточку
Головной Epic хранит согласованный результат и клиентский контекст. Связанные BAN и DESIGN показывают готовность аналитики и макетов; BACK, FRONT, iOS, Android и другие компонентные задачи — ход реализации; release ticket — состав и готовность выпуска.
Что проверяем
Какой вопрос задаём
Scope
Все ли активные задачи относятся к утверждённой версии? Не появилась ли работа вне согласованных границ?
Ответственные
Кто отвечает за каждую активную часть и за общий технический прогноз?
Зависимости
Что должно завершиться раньше: аналитика, дизайн, API, интеграция, доступ или решение клиента?
Следующее событие
Какой проверяемый результат ожидается дальше и когда прогноз будет пересмотрен?
Готовность клиента
Нужны ли данные, макеты, доступ, согласование или окно работ со стороны клиента?
Не считайте процент по количеству закрытых карточекОдна критичная незавершённая зависимость может блокировать весь сценарий. Для статуса используйте пройденные контрольные события и оставшиеся условия, а не среднее арифметическое статусов.
Шаг 3 · Давать проверяемый статус
Каждое обновление должно отвечать: где мы, что дальше и что мешает
Оперативное обсуждение может идти в Slack и на daily, но управленческий итог переносится в Jira. Обновляйте статус при изменении прогноза, появлении блокера, изменении scope и перед заранее согласованной точкой связи с клиентом.
Внутренний статус разработки
Статус на [дата]: [Jira-ссылка]
Согласованный scope: [версия]
Текущий этап и выполненный результат: [факт]
Что сейчас в работе: [задачи и ответственные]
Что осталось до следующей точки: [перечень]
Блокеры / зависимости: [перечень, владелец, действие]
Изменение прогноза: [нет / новый ориентир и причина]
Следующее контрольное событие: [что, дата, ответственный]
Что нужно от Delivery / клиента: [действие или «ничего»]
Источник: [Jira-ссылки]
Единый норматив частоты обновления не подтверждён. На пилоте нужно утвердить интервал для обычных задач и отдельный порядок для критичных обязательств.
Шаг 4 · Управлять блокером
У блокера всегда должны быть владелец и следующее действие
Фраза «ждём» недостаточна. Зафиксируйте, что именно остановлено, с какого момента, кто может снять ограничение, что уже сделано, когда будет следующая проверка и как блокер влияет на клиентский прогноз.
Карточка блокера
БЛОКЕР по [Jira-ссылка]
Что заблокировано: [задача / результат]
Причина и подтверждающий источник: [факт и ссылка]
Возник: [дата]
Владелец снятия блокера: [имя / команда / клиент]
Следующее действие: [что сделать]
Контрольная дата: [дата]
Влияние на объём / срок / стоимость: [описание или «оценивается»]
Кого уведомили: [роли]
План обхода: [если есть]
Если блокер влияет на обещанный клиенту результат, Delivery сообщает клиенту подтверждённый факт и следующий шаг. Новую дату можно называть только после пересмотра технического плана.
Шаг 5 · Контролировать изменение scope
Новое пожелание не добавляется в работу молча
Сначала определите: это уточнение уже согласованного результата, исправление ошибки или новый объём. Запишите изменение и его источник. IT оценивает влияние на архитектуру, часы и план; уполномоченный повторно согласует затронутые условия.
Запрос на изменение
ИЗМЕНЕНИЕ SCOPE по [Jira-ссылка]
Текущая согласованная версия: [дата / номер]
Что предлагается изменить: [описание]
Источник и причина: [клиент / IT / тестирование, ссылка]
Классификация: [уточнение / ошибка / новый объём / требуется решение]
Какие задачи затронуты: [ссылки]
Влияние на часы, стоимость и срок: [оценка / ожидается]
Решение: [принять / вынести в следующую версию / отклонить / уточнить]
Кто и когда согласовал: [значение]
Историю сохраняемЕсли изменились часы, дата или плательщик, не заменяйте исходную запись. Свяжите новую версию с прежним решением и укажите причину повторного согласования.
Шаг 6 · Сообщать клиенту
Переведите технический статус на язык результата
Delivery сообщает не названия внутренних компонентов, а состояние обещанного сценария: что подтверждено, что выполняется, что требуется от клиента, есть ли изменение прогноза и когда будет следующее обновление.
Клиентское обновление
Статус по доработке [название] на [дата].
Что уже подтверждено / выполнено: [понятный результат]
Что происходит сейчас: [этап без внутренних деталей]
Что требуется от вас: [действие и срок / «ничего»]
Есть ли изменение согласованного объёма: [нет / описание]
Прогноз: [подтверждённая дата / ориентир / дата следующего пересмотра]
Следующее обновление: [дата или событие]
Контакт по вопросам: [имя / канал]
Перед сообщением новой даты или технического ограничения попросите IT подтвердить формулировку. Не пересылайте клиенту внутренний тред целиком.
Шаг 7 · Подготовить переход к тестированию
Завершите этап проверяемым пакетом
Перед передачей в QA должны быть понятны версия scope, реализованные связанные задачи, ограничения, тестируемая среда или сборка, критерии приёмки и известные дефекты. Delivery заранее готовит бизнес-сценарии, но техническую готовность подтверждает IT.
Следующая глава подробно разберёт техническое тестирование, бизнес-приёмку и условия перехода к релизу.
На каких наблюдениях основана глава?
Подтверждённое наблюдение · 01.09.2026: пять крупных задач выборки имели статус «В работу», Medium, но не имели assignee, due date и release. Это не статистика всего бэклога, однако показывает, почему один статус нельзя считать доказательством старта. Примеры: DEV1-2553 ↗ и DEV1-2555 ↗.
Подтверждённое наблюдение · 01.09.2026: головная DEV1-2530 показывала 0%, хотя связанная BAN-180 находилась в Quality Control и имела исполнителя. Это подтверждает, что агрегированный процент и фактическая готовность клиентского сценария могут расходиться. Открыть Epic ↗
Документ · 20.07.2026: отсутствие единого backlog, сроков, отчётности и владельца результата было зафиксировано как системная проблема; ежедневная координация компенсирует пробелы процесса. Открыть документ ↗
Предлагаемый порядок: четыре признака фактического старта, структура статусного обновления, карточка блокера и change request. Их обязательность, периодичность и персональные владельцы должны быть утверждены перед пилотом.
09 / Качество и приёмка
Тестируем и подтверждаем результат
«Разработка закончена» означает только готовность начать проверку. До выпуска нужно отдельно подтвердить техническое качество, соответствие бизнес-сценарию и — когда это предусмотрено — принятие результата клиентом.
Техническое QAРаботает ли изменение, не сломало ли соседние функции.Бизнес-проверкаРешён ли согласованный пользовательский сценарий.Клиентская приёмкаПодтвердил ли клиент результат или замечания.Решение о выпускеДостаточно ли доказательств и приняты ли риски.
Одна проверка не заменяет другуюQA не принимает коммерческое обязательство клиента, Delivery не подтверждает техническую регрессию, а публикация приложения не доказывает клиентскую приёмку.
Шаг 1 · Подготовить вход в QA
Передавайте не фразу «готово», а тестовый пакет
Технический владелец указывает версию согласованного scope, реализованные Jira-задачи, доступную для проверки среду или сборку, необходимые данные и роли, известные ограничения и ответственного за исправления.
Нужно передать
Зачем
Версия scope
Чтобы проверять именно согласованный результат, а не последнюю устную трактовку.
Среда и сборка
Чтобы результат можно было воспроизвести и отличить от другой версии.
Критерии приёмки
Чтобы у проверки были ожидаемые результаты, а не субъективное «вроде работает».
Данные и роли
Чтобы проверить права, клиентский контур и пограничные сценарии безопасно.
Известные ограничения
Чтобы отделить принятые ограничения от новых дефектов.
Передача в тестирование
ГОТОВО К ПРОВЕРКЕ: [Jira-ссылка]
Версия scope: [дата / номер]
Реализованные задачи: [ссылки]
Среда / сборка / версия: [значение]
Роли и тестовые данные: [где получить безопасным способом]
Критерии приёмки: [ссылка]
Известные ограничения: [перечень или «нет»]
Что не входит в эту проверку: [перечень]
Ответственный за исправления: [имя / команда]
Срок или контрольная дата проверки: [значение]
Не помещайте пароли, токены и реальные персональные данные в Jira или шаблон. Ссылайтесь на утверждённый безопасный способ доступа.
Шаг 2 · Провести техническую проверку
QA фиксирует не только итог, но и доказательства
Проверка включает целевой сценарий, затронутые компоненты и необходимые regression/smoke-проверки. Результат может быть: пройдено; пройдено с принятыми ограничениями; не пройдено; заблокировано.
В Jira или связанном тестовом артефакте должны остаться дата, среда и версия, набор проверок, фактический результат, найденные дефекты, проверивший и ссылка на evidence. Если используется Qase, добавьте ссылку на соответствующий run, а не только название инструмента.
Результат технического QA
ТЕХНИЧЕСКОЕ QA по [Jira-ссылка]
Дата, среда и версия: [значение]
Проверенные сценарии / test run: [ссылка]
Результат: [пройдено / с ограничениями / не пройдено / заблокировано]
Regression / smoke: [результат и ссылка]
Найденные дефекты: [ссылки и критичность]
Известные ограничения: [перечень]
Что не проверено: [перечень и причина]
Проверил(а): [имя / роль]
Следующее действие: [что, кто, дата]
Шаг 3 · Оформить дефект
Дефект должен воспроизводиться и быть связан с исходной работой
Создайте Bug или используйте согласованный тип задачи. Свяжите его с головным Epic, реализацией и тестовой версией. Критичность описывайте через влияние на пользователя и возможность обхода, а не только словами «срочно» или «не работает».
Карточка дефекта
ДЕФЕКТ: [краткое фактическое поведение]
Связанный запрос / задача: [ссылки]
Среда, сборка и версия: [значение]
Роль пользователя и предусловия: [значение]
Шаги воспроизведения:
1. [шаг]
2. [шаг]
3. [шаг]
Фактический результат: [что произошло]
Ожидаемый результат и источник: [критерий / ссылка]
Влияние и масштаб: [кто не может что сделать]
Обходной путь: [есть / нет, описание]
Материалы: [обезличенный скрин / видео / лог / ссылка]
Нашёл(ла): [имя, дата]
Не маскируйте новый scope под багЕсли результат соответствует утверждённым критериям, а новое ожидание в них отсутствует, сначала оформите change request. Классификацию спорного случая подтверждают IT и владелец бизнес-сценария.
Шаг 4 · Провести бизнес-проверку
Delivery проверяет пользовательский результат, а не внутреннюю реализацию
Назначенный бизнес-проверяющий проходит согласованные критерии от лица пользователя: роль, исходные данные, действие, результат и ограничения. Он не должен исследовать код, Jenkins или технические логи.
Если сценарий зависит от клиента, заранее согласуйте, кто предоставляет данные, доступы или подтверждение макета. Формулировка «менеджер проверит по возможности» не создаёт ответственного результата.
Протокол бизнес-проверки
БИЗНЕС-ПРОВЕРКА: [название и Jira-ссылка]
Версия scope / сборки: [значение]
Роль пользователя: [значение]
Проверенные критерии:
— [критерий] — [пройден / не пройден];
— [критерий] — [пройден / не пройден].
Результат пользовательского сценария: [описание]
Замечания / дефекты: [ссылки]
Принятые ограничения: [перечень]
Решение: [подтверждено / вернуть на исправление / требуется решение]
Проверил(а): [имя, роль, дата]
Шаг 5 · Организовать клиентскую приёмку
Заранее определите, когда и каким способом клиент принимает результат
UAT — пользовательская приёмка клиентом или его представителем. Для части работ она проходит до общего выпуска на доступном тестовом контуре, для других — после контролируемой публикации. Порядок зависит от риска, среды и договорённостей и должен быть записан заранее.
Клиенту передают понятный сценарий проверки, версию результата, известные ограничения, срок обратной связи и канал замечаний. Возможные исходы: принято; принято с согласованными ограничениями; не принято с перечнем замечаний; приёмка не требовалась; результат не получен к контрольной дате.
Запрос клиентской приёмки
Готова к проверке доработка «[название]».
Что изменилось: [понятный результат]
Где и как проверить: [контур / инструкция]
Сценарии проверки: [краткий список или ссылка]
Известные ограничения: [перечень или «нет»]
Просьба до [дата] подтвердить один вариант:
— результат принят;
— принят с указанными ограничениями;
— есть замечания — приложить описание и материалы.
Контакт по вопросам: [имя / канал]
Молчание клиента не превращайте автоматически в приёмку, если такое правило заранее не установлено договором или подтверждённым порядком.
Шаг 6 · Зафиксировать приёмку
Свяжите решение клиента с Jira и коммерческим контуром
Запись результата приёмки
РЕЗУЛЬТАТ ПРИЁМКИ по [Jira-ссылка]
Клиент / представитель: [роль или согласованное обозначение]
Проверенная версия: [значение]
Дата и способ проверки: [значение]
Результат: [принято / с ограничениями / не принято / не требовалось / ожидается]
Подтверждённые критерии: [ссылка]
Ограничения и замечания: [перечень]
Связанные дефекты / доработки: [ссылки]
Источник подтверждения: [письмо / протокол / Jira-ссылка]
Ответственный Delivery: [имя]
Следующее действие: [выпуск / исправление / акт / повторная проверка]
Для платной работы передайте ссылку на подтверждение финансовому владельцу. Приёмка функциональности, акт и факт оплаты — связанные, но разные события; не отмечайте одно вместо другого.
Шаг 7 · Подготовить решение о релизе
Соберите доказательства для go/no-go
Перед выпуском технический владелец подтверждает состав версии и риски. В пакете должны быть: связанный scope; готовые компоненты; QA evidence; результат бизнес-проверки; статус критичных дефектов; принятые ограничения; необходимые UAT-решения; план выпуска, наблюдения и отката.
Решение
Когда применяем
Go
Обязательные проверки пройдены, критичные блокеры отсутствуют, ограничения приняты, владелец выпуска и план наблюдения определены.
Conditional go
Есть известные ограничения, но уполномоченные владельцы явно приняли риск и записали условия выпуска.
No-go
Не пройден обязательный сценарий, есть критичный дефект, нет необходимого подтверждения или безопасного плана выпуска.
«Опубликовано» не равно «принято»Готовность компонента, публикация мобильной версии, закрытие QA, общий релиз и клиентская приёмка могут произойти в разное время. Следующая глава разберёт release ticket, уведомление и сопровождение после выпуска.
На каких наблюдениях основана глава?
Подтверждённый факт: в рабочем контуре используются QA, Qase, regression и smoke; старый технический checklist содержит эти проверки, но его обязательность как стандарта 2026 года не подтверждена.
Подтверждённый разрыв · документы 15.06 и 08.07.2026: клиентский менеджер должен участвовать в проверке, однако его участие описано как «по возможности». Персональный business acceptor и обязательное UAT-evidence в Jira не найдены. Открыть документ Delivery ↗
Подтверждённое наблюдение · 02.09.2026: в кейсе МОЕ компонентные задачи были выполнены, мобильные версии опубликованы в stores, а общий DEV1-2569 оставался в QA in Progress; клиентская приёмка не была найдена. Это показывает, что один компонентный статус не доказывает общую готовность. Открыть DEV1-2569 ↗
Предлагаемый порядок: обязательный входной пакет QA, отдельная бизнес-проверка, фиксированный результат UAT и evidence pack для go/no-go. Точные обязательные тесты, системы хранения evidence и владельца решения о выпуске нужно утвердить перед пилотом.
10 / Выпуск и сопровождение
Выпускаем изменение и следим за результатом
Релиз — не момент нажатия кнопки, а управляемый переход от проверенной версии к работающему клиентскому сценарию. До начала нужно знать, что выпускаем, кому, когда, кто наблюдает за результатом и что делать при проблеме.
Паспорт релизаСостав, версии, клиенты, зависимости и решение go/no-go.Понятное уведомлениеЧто изменится для клиента, когда и требуется ли действие.Контролируемая выкладкаОкно, последовательность, ответственные и подтверждение результата.Наблюдение и закрытиеПроверки после запуска, инциденты, откат и итоговый статус.
У одного релиза несколько статусовМобильная версия может быть опубликована, backend — ещё не развёрнут, а клиентский сценарий — не принят. Поэтому сообщайте готовность всего результата, а не одного компонента.
Шаг 1 · Создать паспорт релиза
Свяжите технический состав с клиентским обещанием
В release ticket или другом согласованном основном артефакте соберите компоненты и версии, связанные задачи, клиентов и контуры, миграции и зависимости, результаты обязательных проверок, известные ограничения, окно выпуска и владельцев. Delivery добавляет понятный клиентский результат и ссылку на обязательство, если оно существует.
Паспорт релиза
РЕЛИЗ: [название / Jira-ссылка]
Клиентский результат: [что станет доступно]
Клиенты / контуры: [перечень]
Компоненты и версии: [перечень]
Связанные задачи / MR: [ссылки]
Миграции и зависимости: [перечень или «нет»]
QA / business check / UAT: [результаты и ссылки]
Известные ограничения: [перечень]
Договорное обещание / срок: [ссылка или «нет»]
Окно выпуска: [дата, время, часовой пояс]
Технический владелец: [имя / команда]
Delivery-владелец: [имя]
План наблюдения и отката: [ссылки]
Не объединяйте разные клиентские контуры словом «production», если они обновляются отдельно. Для white-label приложений укажите конкретные приложения и версии.
Шаг 2 · Принять и записать решение
Go/no-go — это решение с основаниями, а не новый статус «на глаз»
Перед окном выпуска уполномоченный владелец проверяет evidence pack из предыдущей главы. Если риск принимается условно, записываются ограничение, ответственный, срок устранения и критерий остановки. При no-go клиенту не обещают новую дату, пока технический план не пересмотрен.
Решение о выпуске
РЕШЕНИЕ ПО РЕЛИЗУ: [Jira-ссылка]
Дата и версия пакета: [значение]
Решение: [GO / CONDITIONAL GO / NO-GO]
Основания: [QA, бизнес-проверка, UAT — ссылки]
Открытые дефекты и ограничения: [перечень]
Принятый риск: [кто принял и на каких условиях]
Критерии остановки / отката: [перечень]
Окно выпуска: [значение]
Владелец решения: [имя / роль]
Следующая контрольная точка: [дата / событие]
Роль требует утвержденияВ исследованных материалах не найден единый действующий accountable-владелец go/no-go. До утверждения процесса решение нельзя приписывать Delivery, QA или разработчику автоматически.
Шаг 3 · Подготовить коммуникацию
Сначала техническая точность, затем понятный текст для клиента
Технический release ticket не пересылают клиенту без обработки. Delivery выбирает изменения, относящиеся к конкретному клиенту, переводит их в пользовательский результат и подтверждает точность у IT. В уведомлении нужны дата и окно, влияние, возможный перерыв, необходимые действия, ограничения и контакт.
Подтверждённый рабочий порядок 2026 года предусматривает сообщение в #releases за 2–3 дня, после чего готовится клиентская рассылка. Это не заменяет проверку списка получателей и применимости релиза к каждому контуру.
Сообщение в #releases
ПЛАНИРУЕТСЯ РЕЛИЗ: [дата и окно]
Release ticket: [ссылка]
Клиенты / контуры: [перечень]
Что меняется для пользователя: [кратко]
Влияние / возможный перерыв: [описание или «не ожидается»]
Что требуется от клиента: [действие или «ничего»]
Известные ограничения: [перечень]
Статус go/no-go: [решение и ссылка]
Технический контакт: [имя / канал]
Delivery-контакт: [имя]
Предварительное уведомление клиента
Здравствуйте!
[Дата] в период [время и часовой пояс] планируется обновление [сервис / приложение].
Что изменится: [пользовательский результат]
Как это повлияет на работу: [влияние / перерыв / «не повлияет»]
Что нужно сделать: [действие или «ничего»]
Известные ограничения: [описание или «нет»]
Когда сообщим результат: [контрольная точка]
По вопросам: [имя и канал]
Шаг 4 · Провести выкладку
Фиксируйте фактическую последовательность и результат каждого контура
Техническая команда выполняет утверждённый runbook: проверяет зависимости, развёртывает компоненты в заданной последовательности, выполняет миграции и контрольные проверки. Delivery не управляет командами развёртывания, но следит, чтобы клиентский статус опирался на подтверждённые факты.
Журнал выпуска
ЖУРНАЛ РЕЛИЗА: [Jira-ссылка]
Фактическое начало: [дата и время]
Контур / клиент: [значение]
Компонент и версия: [значение]
Действие: [что выполнено]
Результат проверки: [успешно / ошибка / остановлено]
Материалы / лог без секретов: [ссылка]
Отклонение от плана: [описание или «нет»]
Решение: [продолжить / остановить / откатить]
Ответственный: [имя / команда]
Фактическое завершение: [дата и время]
Технические секреты, ключи, внутренние адреса и персональные данные в клиентское сообщение и открытую карточку не переносятся.
Шаг 5 · Проверить здоровье релиза
После выкладки начинается период наблюдения
Ответственный технический владелец проверяет доступность, ошибки, ключевые интеграции и согласованный smoke-сценарий. Владелец бизнес-сценария подтверждает, что пользовательский результат доступен именно нужному клиенту. Продолжительность наблюдения и пороги реакции должны зависеть от риска и быть заданы до выпуска.
Проверка после выпуска
POST-RELEASE CHECK: [Jira-ссылка]
Период наблюдения: [начало — конец]
Контуры и версии: [перечень]
Технические сигналы: [что проверено и результат]
Smoke-сценарий: [результат и ссылка]
Бизнес-сценарий: [результат и проверивший]
Новые ошибки / обращения: [ссылки или «нет»]
Известные ограничения: [актуальный статус]
Итог: [стабильно / наблюдаем / инцидент / откат]
Владелец наблюдения: [имя / команда]
Следующая проверка: [дата / событие]
Слово «стабильно» должно иметь проверяемое основание. В исследованных материалах единый release health dashboard и обязательный период наблюдения не подтверждены — это нужно определить перед пилотом.
Шаг 6 · Обработать сбой или откат
Сначала ограничьте влияние, затем выясняйте причины
При достижении заранее установленных критериев остановки технический владелец запускает утверждённый rollback или другой безопасный план. Delivery оперативно сообщает клиенту подтверждённое влияние, доступный обходной путь и время следующего обновления — без неподтверждённых причин и обещаний.
Статус сбоя после релиза
ИНЦИДЕНТ ПОСЛЕ РЕЛИЗА: [ссылка]
Начало и способ обнаружения: [значение]
Затронутые клиенты / функции: [подтверждённые данные]
Фактическое влияние: [что недоступно]
Текущий статус: [локализуем / исправляем / откатываем / восстановлено]
Обходной путь: [описание или «нет»]
Принятое решение: [остановка / rollback / hotfix]
Технический владелец: [имя / команда]
Следующее обновление: [точное время]
После восстановления: [контрольная проверка / разбор]
Наличие hotfix-пути не доказывает готовность откатаДо релиза должны быть понятны применимый runbook, полномочия на решение, способ проверки восстановления и влияние отката на данные.
Шаг 7 · Закрыть релиз и обязательство
Завершайте по результату, а не по факту выкладки
После периода наблюдения обновите release ticket и связанные клиентские задачи: фактические версии и контуры, результат smoke и бизнес-проверки, дефекты, итоговое уведомление, UAT или принятые ограничения. Для платной работы отдельно передайте подтверждение приёмки в процесс акта и оплаты.
Итог релиза
РЕЛИЗ ЗАВЕРШЁН: [Jira-ссылка]
Фактические дата и время: [значение]
Выпущенные контуры и версии: [перечень]
Клиентский результат: [подтверждён / частично / не подтверждён]
Post-release check: [результат и ссылка]
Клиент уведомлён: [дата и источник]
Приёмка / ограничения: [результат и ссылка]
Новые дефекты / follow-up: [ссылки]
Договорное обязательство: [выполнено / частично / открыто]
Акт и оплата: [отдельный статус / ответственный]
Итоговый владелец: [имя / роль]
Закрытие технической задачи не должно скрывать открытый клиентский результат, неподписанный акт или невыполненное договорное обещание. Эти статусы связаны ссылками, но ведутся раздельно.
На каких наблюдениях основана глава?
Исторический технический источник · обновлён 18.07.2023: в Confluence найден release checklist с MR, зависимостями, миграциями, QA, regression, smoke, Jenkins, версиями, cloud/МОЕ и hotfix-сценариями. Его обязательность и актуальные владельцы в 2026 году не подтверждены.
Подтверждённый порядок · 08.07.2026: клиенты просили предупреждать о релизах за 2–3 дня; договорённость предусматривает публикацию в #releases и подготовку клиентской рассылки. Открыть документ Delivery ↗
Рабочий пример · 15–25.05.2026: DEV1-2499 и Slack-тред использовались как технический manifest, но у Delivery не было готового клиентского списка изменений; применялось ручное выделение релевантных пунктов и перевод формулировок. Открыть технический тред ↗
Подтверждённый разрыв · срез 02.09.2026: компонентные задачи МОЕ и store-публикации были готовы раньше общего DEV1-2569, который оставался в QA in Progress. Это подтверждает необходимость раздельных статусов. Открыть DEV1-2569 ↗
Предлагаемый порядок: обязательный паспорт, запись go/no-go, журнал выкладки, период наблюдения, критерии rollback и итог релиза. Владельцев, сроки, каналы и пороги необходимо утвердить до пилота.
11 / Специальные маршруты
Запросы БМП и Sales: что делать иначе
Основной процесс остаётся тем же: зарегистрировать потребность, собрать контекст, оценить, отдельно согласовать деньги и запуск. Но БМП требует управления брендом и несколькими мобильными платформами, а Sales до договора часто нужна предварительная оценка — ещё не обещание разработки.
БМПКонкретный клиент, бренд, дизайн, платформы и store-публикации.Sales pre-estimateКоммерческая возможность, неполный scope и диапазон с допущениями.Общее правилоОдна головная Jira-задача и ссылки на все подтверждения.ЗапретНи макет, ни оценка сами по себе не разрешают запуск.
Вопрос
БМП
Sales pre-estimate
Для кого
Новый или действующий клиент с брендированным мобильным продуктом.
Потенциальный клиент или новая возможность у действующего.
Что нужно на входе
Клиент, tenant, платформы, бренд-материалы, сценарий и контакт согласующего.
Клиент/сегмент, задача, use cases, масштаб, интеграции, срок решения и коммерческий контекст.
Первый технический результат
Подтверждённая структура Epic + DESIGN + платформенные задачи.
Решение: достаточно данных для диапазона или сначала нужна аналитика.
Что получает бизнес
План подготовки и выпуска конкретного БМП.
Предварительный диапазон с допущениями, неучтёнными работами и сроком действия.
Главный риск
Разные версии, потеря подтверждения макета, задержка store review.
Продать срок или стоимость до уточнения scope и технической применимости.
Маршрут выбирают по цели запросаЕсли Sales уже договорился о конкретной платной доработке, после квалификации это обычная клиентская доработка. Если БМП требует новой продуктовой функции, сама функция проходит отдельную оценку, а не растворяется в задаче брендирования.
Маршрут А · Sales · Шаг 1
Сначала выясните, какое решение нужно продажам
Sales указывает, на какой стадии находится возможность и что нужно сейчас: проверить наличие штатной функции, получить грубый диапазон для разговора, подготовить коммерческое предложение или оценить уже согласованный scope. Delivery не начинает с вопроса «сколько часов», пока не понятны задача клиента и границы решения.
Входящий запрос Sales
SALES-ЗАПРОС
Клиент / сегмент: [значение]
Ответственный Sales: [имя]
Стадия: [первичный интерес / демонстрация / КП / переговоры / договор]
Какое решение требуется: [проверка продукта / pre-estimate / точная оценка]
Проблема и пользовательский сценарий: [описание]
Ожидаемый результат: [что должен получить клиент]
Масштаб: [пользователи / объекты / объём / частота]
Интеграции и исходные системы: [перечень]
Материалы клиента: [ссылки]
Срок ответа Sales и основание: [значение]
Что уже обещано клиенту: [только подтверждённые факты / «ничего»]
Открытые вопросы: [перечень]
Маршрут А · Sales · Шаг 2
Отделите штатный продукт, аналитику и предварительную оценку
Delivery вместе с IT проверяет, решается ли сценарий текущим продуктом или настройкой. Если нет, определяет число самостоятельных работ, затронутые продукты и необходимость BAN/дизайна. Неполный запрос возвращается с конкретными вопросами; срочность сделки не заменяет исходные данные.
В подтверждённом примере формулировка «оцените интеграцию» после уточнения распалась на пять самостоятельных интеграций. Поэтому единая цифра до декомпозиции была бы недоказанной.
Маршрут А · Sales · Шаг 3
Выдайте диапазон, который невозможно принять за обещание
Pre-estimate содержит версию входных данных, диапазон, допущения, исключения, риски и дату пересмотра. Если нужна точная стоимость, запрос переводится в полноценный scope и обычный цикл оценки. Sales сообщает клиенту только согласованную формулировку.
Результат Sales pre-estimate
ПРЕДВАРИТЕЛЬНАЯ ОЦЕНКА: [Jira-ссылка]
Версия входных данных: [дата / ссылка]
Рассмотренный сценарий: [кратко]
Диапазон: [часы / стоимость / календарный ориентир]
Допущения: [перечень]
Не входит: [перечень]
Главные риски: [перечень]
Что нужно для точной оценки: [данные / аналитика / дизайн]
Действительна до: [дата или событие]
Технически проверил(а): [имя / роль]
Разрешение на разработку: НЕ ДАНО
Формулировка для клиента согласована: [кем / дата]
Оценка не равна коммерческому обязательствуНельзя обещать клиенту срок или цену только по предварительному диапазону. До запуска нужны утверждённый scope, плательщик, стоимость, приоритет и уполномоченное решение.
Маршрут Б · БМП · Шаг 1
Определите, что именно создаётся или меняется
Зафиксируйте: новый это БМП или изменение действующего; клиент и tenant; iOS, Android или обе платформы; какие пользовательские сценарии отличаются от стандартного продукта; требуется ли новая функция или только брендирование; кто у клиента подтверждает макеты и итог.
Карточка БМП
БМП: [новый / изменение действующего]
Клиент и tenant: [значение]
Ответственный Delivery: [имя]
Платформы: [iOS / Android / обе]
Текущее приложение и версии: [если существует]
Пользовательский сценарий: [что должен делать житель / сотрудник]
Отличия от стандартного продукта: [перечень или «только бренд»]
Название и бренд-материалы: [ссылки]
Макеты: [ссылка / ещё не готовы]
Контакт, подтверждающий от клиента: [имя / роль]
Желаемая дата и основание: [значение]
Коммерческие условия: [ссылка / не определены]
Открытые вопросы: [перечень]
Не прикладывайте секреты аккаунтов магазинов и доступы. Указывайте только согласованное место их безопасного хранения.
Маршрут Б · БМП · Шаг 2
Соберите одну структуру задач и подтверждений
Delivery создаёт головной Epic с бизнес-контекстом. К нему привязываются DESIGN и необходимые платформенные задачи; BAN и другие компоненты добавляются, если без них нельзя определить или реализовать поведение. Все задачи ссылаются на одну версию scope и макета.
Подтверждение клиента в чате не должно оставаться единственным доказательством: в Jira сохраняется ссылка, дата, версия макета, подтвердивший и ограничения. Изменение после подтверждения оформляется новой версией и при необходимости переоценивается.
Реестр подтверждений БМП
ПОДТВЕРЖДЕНИЕ БМП: [Epic-ссылка]
Версия scope: [дата / номер]
Версия макета: [ссылка / номер]
Что подтверждено: [экраны / тексты / сценарии / бренд]
Что не подтверждено: [перечень]
Клиент подтвердил: [роль / дата / ссылка на источник]
Delivery проверил(а): [имя / дата]
Связанные DESIGN / IOS / ANDROID / другие задачи: [ссылки]
Изменения после подтверждения: [нет / ссылка на новую версию]
Следующий шаг: [оценка / коммерческое решение / разработка]
Маршрут Б · БМП · Шаг 3
Планируйте платформы и публикации как связанные, но отдельные результаты
Оценка и план должны показывать работу по каждой платформе, общие backend/интеграционные зависимости и внешний lead time магазинов приложений. Готовность одной платформы не означает готовность БМП целиком, если клиенту обещаны обе.
Перед выпуском в паспорте релиза перечисляются конкретные приложения, версии и клиентские контуры. После публикации Delivery фиксирует, что доступно пользователю, а не только факт отправки версии на review.
Общий handoff
Передавайте дальше одну ссылку и явный тип результата
Передача специального запроса
ПЕРЕДАЧА: [БМП / SALES PRE-ESTIMATE]
Головная Jira-задача: [ссылка]
Ответственный Delivery: [имя]
Требуемый результат этого этапа: [что нужно получить]
Версия scope / входных данных: [значение]
Связанные материалы и задачи: [ссылки]
Что уже подтверждено: [перечень]
Что не подтверждено: [перечень]
Коммерческий статус: [не обсуждался / на согласовании / подтверждён — ссылка]
Клиентский срок: [запрос / обязательство / отсутствует + источник]
Кому передано: [имя / команда]
Контрольная дата ответа: [дата или согласованный ориентир]
После handoff применяются общие главы инструкции: оценка, коммерческое решение, разработка, тестирование и релиз. Специальный маршрут меняет состав входа, но не отменяет контрольные точки.
Быстрая проверка перед передачей
Для Sales: известно требуемое решение; описан use case и масштаб; отмечены обещания; понятна полнота данных; предварительный характер результата виден в заголовке и тексте.
Для БМП: указан клиент и tenant; определены платформы; отделён бренд от новой функциональности; есть версия scope и макета; назначен подтверждающий со стороны клиента; платформенные задачи связаны с Epic.
Для обоих: есть одна головная ссылка, ответственный Delivery, источник срока, коммерческий статус и следующий владелец.
На каких наблюдениях основана глава?
Предлагаемая схема · пакет процесса 09.09.2026: БМП определён как новый или изменяемый брендированный мобильный продукт с Epic, дизайном, подтверждением клиента и платформенными задачами; Sales pre-estimate — как предварительный диапазон без обещания запуска.
Рабочий пример Sales · 10–28.07.2026: запрос на оценку интеграции оказался набором пяти самостоятельных интеграций, а разбор начался после задержки. Это подтверждает необходимость квалификации до цифры. Открыть тред ↗
Рабочий пример БМП · 29.07–24.08.2026: в процессе использовались Epic, дизайн, клиентское подтверждение и связанные платформенные задачи; найден риск, когда подтверждение остаётся в чате без надёжной связи с Jira. Открыть сообщение ↗
Подтверждённый технический контекст · срез 30.08.2026: white-label-контур включает множество iOS/Android приложений и неоднородные версии, поэтому платформу, приложение и версию нельзя сворачивать в один статус «БМП готов».
Требует утверждения: обязательные Jira-поля, типы задач, владелец квалификации, срок ответа на Sales pre-estimate, состав бренд-пакета, store-владельцы и точный набор клиентских подтверждений.
12 / Пример заполнения
Превратим сообщение в запрос
Попробуйте заполнить карточку или сначала откройте готовый пример. Все названия и условия кейса вымышлены. Введённое остаётся на странице и исчезнет после её перезагрузки.
Сообщение от учебного клиента
«Можно добавить выгрузку заявок в Excel? Диспетчер тратит много времени на еженедельный отчёт».
Этого недостаточно для оценки: неизвестны поля выгрузки, фильтры, права доступа, срок и критерии результата.
Карточка запросаТренажёр · без связи с Jira
Как выглядит передача в Slack после проверки?
«Коллеги, подготовлен запрос на выгрузку заявок: [ссылка на головную задачу]. Сценарий, границы и критерии приёмки описаны. Просьба проверить техническую полноту и определить состав оценщиков. Плательщик пока не определён; разрешение на разработку не запрашиваем».
Учебный пример. Замените текст на фактический статус проверки. Открытые вопросы могут потребовать аналитики до итоговой оценки.
13 / Самопроверка
Готовы провести запрос по процессу?
Восемь коротких ситуаций проверяют не знание терминов, а решения, которые сотрудник принимает в реальной работе. Результат остаётся только на этой странице и исчезает после перезагрузки.
Практическая проверка
Выберите один лучший следующий шаг в каждой ситуации.
Итоговая памятка: восемь контрольных точек
01 · ВходЕсть клиент, инициатор, дата и ссылка на первичный запрос.02 · ScopeПонятны проблема, результат, границы и критерии приёмки.03 · ОценкаЕсть версия, компоненты, допущения, риски и срок действия.04 · РешениеЗафиксированы плательщик, стоимость, приоритет и разрешивший запуск.05 · РаботаЕсть исполнитель, технический план, связи и следующий проверяемый шаг.06 · ПроверкаРазделены QA, бизнес-проверка, UAT, дефекты и ограничения.07 · РелизЕсть passport, go/no-go, уведомление, rollout, наблюдение и откат.08 · ЗакрытиеЗаписаны клиентский результат, приёмка, follow-up, акт и оплата.
Контроль перед передачей следующему участнику
ПРОВЕРКА ПЕРЕД ПЕРЕДАЧЕЙ
Головная Jira-задача: [ссылка]
Текущая версия scope: [дата / номер]
Что завершено на этом этапе: [проверяемый результат]
Доказательства: [ссылки]
Что ещё открыто: [вопросы / риски / ограничения]
Коммерческий статус: [значение и источник]
Клиентский срок: [запрос / обязательство / прогноз + источник]
Следующий результат: [что должно появиться]
Следующий владелец: [имя / роль]
Передано: [дата, канал, ссылка]
Контрольная точка: [дата или событие]
Главный принцип всей инструкцииКаждый переход должен оставлять один понятный результат, ссылку на доказательство, следующего владельца и контрольную точку. Если одного из четырёх элементов нет, запрос ещё не передан управляемо.
14 / Частые ситуации
Если следующий шаг неясен
Я не знаю, кто должен платить
Укажите «Не определён» и приложите найденные договорённости. Ответственный руководитель должен принять решение. Техническая оценка и коммерческое предложение клиенту оформляются отдельно.
Не понимаю, это ошибка или новая возможность
Опишите фактическое и ожидаемое поведение, добавьте шаги воспроизведения и источник ожидания. Передайте на техническую классификацию. Не назначайте платность только по формулировке клиента.
Клиенту уже обещали срок
Зафиксируйте дату, кем и где она обещана. Сообщите ответственному за планирование. Сопоставьте обязательство с техническим планом до нового обещания клиенту.
У запроса изменилась оценка
Сохраните обе версии, причину пересмотра и изменившийся объём. Запросите повторное согласование, если изменились принятые условия. Не заменяйте первоначальную оценку без истории.
Инструкция уже завершена?
Содержательная структура завершена: показан весь путь от входа до сопровождения релиза, специальные маршруты, учебный пример и самопроверка. Перед рабочим запуском остаётся согласовать незакрытые роли, поля, каналы и сроки, проверить страницу в Tilda и провести пилот на новых кейсах.
