Просьба «добавить ещё одного согласующего» выглядит маленькой, пока не выясняется, что у него свои права, сроки, заместитель и правила возврата. Изменение затрагивает сообщения, отчёты, старые заявки и тесты. Если решение принято устно, через месяц никто не помнит, почему срок сдвинулся.
Рабочая процедура изменения нужна для видимости последствий. Она не должна превращать каждое уточнение текста в многостраничный документ. Достаточно короткой карточки, сопоставленной с согласованным сценарием, и общего журнала решений.
Определите, что именно меняется
Сначала найдите исходное основание: историю пользователя, критерий приёмки, макет, правило расчёта или согласованный пример данных. Без него нельзя понять, появилось ли новое требование или обнаружена ошибка реализации.
Разделите обращения:
- Дефект: система не выполняет ранее согласованное поведение.
- Уточнение: описание становится однозначным без изменения результата.
- Изменение: добавляется или меняется результат, условие либо ограничение.
- Исследование: влияние пока нельзя оценить без проверки.
Например, запрет согласовать собственную заявку уже записан в критериях, но система разрешает действие. Это дефект. Если такого запрета раньше не было и заказчик вводит его после демонстрации, нужно оценить новое правило и последствия для существующих документов.
Пограничные случаи разбирают вместе. Не стоит назначать категорию только по тому, сколько часов займёт работа: короткое изменение остаётся изменением, а сложный дефект не становится новой функцией.
Опишите потребность через рабочий результат
Начните не с расположения кнопки, а с причины. «Начальник участка должен видеть заявки своей смены, чтобы передавать незавершённые работы» объясняет задачу лучше, чем «добавить фильтр справа».
В руководстве GOV.UK о пользовательских историях роль, потребность и цель связываются с проверяемыми результатами. Для карточки изменения достаточно сохранить эту связь и показать отличие от текущего согласованного поведения.
Укажите, что произойдёт, если изменение отложить. Иногда причина действительно блокирует запуск. Иногда пользователь предлагает удобство, которое можно получить существующей настройкой или простым изменением рабочего порядка. Эти варианты заслуживают сравнения до программирования.
Заполненная карточка запроса
Представим условную систему заявок на закупку. Сейчас руководитель подразделения утверждает заявку единолично. Компания хочет дополнительную проверку финансового специалиста для сумм свыше установленного порога.
- Номер: ИЗМ-014, инициатор — владелец процесса закупки.
- Причина: перед передачей поставщику нужно подтверждать доступный бюджет.
- Текущее правило: после согласования руководителя заявка готова к исполнению.
- Новое правило: при сумме свыше 300 000 рублей после руководителя требуется финансовое согласование.
- Граница суммы: ровно 300 000 рублей остаётся в прежнем маршруте; это условие примера.
- Валюта: пример относится только к рублёвым заявкам.
- Старые заявки: новый маршрут применяется к созданным после согласованной даты; изменение действующих заявок рассматривается отдельно.
- Исключение: увеличение суммы после согласования возвращает заявку на проверку по согласованным правилам.
- Результат: исполнитель получает заявку только после необходимого набора согласований.
- Владелец решения: руководитель закупки; бюджет подтверждает заказчик проекта.
Такая карточка сразу выявляет вопросы, которых не видно в формулировке «ещё один согласующий». Например, можно ли финансовому специалисту быть автором заявки и кто заменяет его во время отсутствия.
Оцените влияние по шести направлениям
Поведение. Какие текущие сценарии изменятся? Проверьте создание, редактирование, возврат, отмену и повторное согласование. Не ограничивайтесь счастливым маршрутом.
Данные. Появляются ли новые состояния, даты и ответственные? Нужно ли преобразовать старые записи или сохранить прежнюю интерпретацию?
Доступ. Кто видит сумму и комментарий, кто вправе изменить решение? Может ли пользователь обойти правило другим экраном или способом обращения к системе?
Связи. Какие уведомления, выгрузки и внешние системы зависят от состояния заявки? Важно не отправить поставщику ещё не утверждённый документ.
Проверка. Какие прежние проверки необходимо повторить и какие новые примеры данных подготовить?
Эксплуатация. Нужно ли обучение, изменение инструкции, мониторинг ошибок или поддержка переходного периода?
По каждому направлению записывают либо конкретную работу, либо «влияния нет» с кратким основанием. Пустая строка означает, что вопрос ещё не рассмотрен.
Пример оценки и влияние на общий план
Условная оценка изменения: анализ — 4 часа, реализация — 12, проверки — 8, подготовка выпуска — 2. Итого 26 часов. При единой условной ставке 3 000 рублей стоимость составляет 78 000 рублей в одной согласованной налоговой базе.
Но 26 часов не означают автоматически перенос запуска на три дня. Аналитик, разработчик и проверяющий могут работать последовательно или частично параллельно; специалист по внешней системе может быть доступен только в определённое окно.
Поэтому рядом укажите календарное влияние: например, два дополнительных рабочих дня при получении решений до среды. Если ответы приходят позже, прогноз пересматривается. Это условие расчёта, а не обещание скорости команды.
В журнале уже согласованы изменения на 42 000 и 60 000 рублей. Вместе с новым запросом получается 180 000 рублей. При исходном бюджете этапа 900 000 рублей это 20%. Отдельная просьба выглядела небольшой, а накопленное влияние уже требует решения владельца бюджета.
Сводка должна различать согласованную сумму, выполненную работу и оплаченные расходы. Эти значения могут не совпадать.
Сравните минимум две альтернативы
Для нашего примера возможны три решения:
- реализовать новый маршрут сейчас и изменить план выпуска;
- сохранить дату, исключив сопоставимый второстепенный объём;
- временно организовать внешнюю проверку, если владелец процесса подтвердил её допустимость, и доработать систему позже.
У каждой альтернативы есть ограничения. Временная ручная проверка требует ответственного, регистрации результата и даты окончания. Она не становится безопасной только потому, что не требует разработки.
Нельзя одновременно добавить объём, сохранить прежний бюджет и срок, если у команды нет подтверждённого способа этого добиться. Руководство по контрактам гибкой разработки полезно как методический источник для обсуждения ограничений и приоритетов; конкретные обязательства фиксируются отдельно.
Короткий шаблон решения
После оценки заполните заключительную часть карточки:
- Варианты: основной, упрощённый и отложенный.
- Выбранный вариант: содержание решения и причина.
- Стоимость: диапазон либо согласованная сумма с допущениями.
- Срок: влияние на ближайший выпуск и зависимости.
- Замещаемый объём: что исключается, если сохраняется лимит.
- Проверка: новые и изменённые критерии.
- Согласовал: человек с полномочиями, дата, версия.
- Статус: предложено, оценивается, согласовано, выполнено, проверено или отменено.
Подтверждение получения сообщения не считается согласованием расходов. Начало реализации должно опираться на понятное решение. Для срочных обращений можно определить сокращённую процедуру, но после неё остаются причина, ответственный и итоговое влияние.
Проверяйте накопление раз в неделю
На встрече показывайте исходный объём, принятые изменения, исключённые задачи, прогноз стоимости и ближайшие решения. Обсуждайте причины повторяющихся запросов: если каждый раз меняется маршрут, вероятно, сам процесс ещё не согласован.
Для подготовки исходных сценариев пригодится статья о техническом задании, а для проверки бюджета — сравнение предложений. На обсуждение разработки приносите одну заполненную карточку: она полезнее длинной переписки без решения.
Закройте карточку после проверки результата
Согласование изменения разрешает работу, но ещё не подтверждает её завершение. После реализации свяжите карточку с конкретной версией системы и результатами приёмки. Владелец процесса должен увидеть именно новое поведение на подготовленных примерах, включая условия, которые раньше не существовали.
Если выбран упрощённый вариант, сохраните его ограничения рядом с решением. Иначе через несколько недель сокращённый объём будут воспринимать как забытый дефект. Отложенную часть оставьте отдельной задачей с приоритетом; не обещайте автоматически включить её в следующий выпуск.
Полезно также указать, какие инструкции и учебные примеры изменились. Новый маршрут согласования без обновления рабочего порядка создаёт противоречие между системой и действиями сотрудников. Карточка закрывается, когда проверен результат, переданы необходимые сведения и понятна ответственность за оставшиеся ограничения.