Как отличить ошибку в модуле от нового требования

Подготовлено 23 октября 2026 года

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

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

Вернитесь к согласованному примеру

В учебной постановке модуль принимает один тип заявки — запрос на расчёт. Для него согласованы поля, результат передачи и несколько проверочных примеров. После показа поступает просьба: «Добавьте ещё заявки на обслуживание».

Сначала найдите прежний состав и его версию. Возможно, обслуживание уже было включено в согласованные примеры, а в описании использовали общее слово «заявки». В другом случае явно обсуждался только расчёт. Ответ нельзя получать только из последней фразы переписки.

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

Опишите наблюдение без диагноза

Запишите фактическое поведение. Например: «Заявка на расчёт с заполненными обязательными полями не появляется у получателя; подтверждения приёма нет». Это наблюдение ещё не определяет причину, но его можно воспроизвести и сопоставить с ожидаемым результатом.

Не подменяйте наблюдение выводом «адаптер сломан» или «заказчик поменял правила». Для вывода могут понадобиться исходные данные, результат на стороне получателя и версия модуля. Укажите, какие сведения подтверждены и каких пока нет.

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

Сопоставьте просьбу с прежним составом

Это способ подготовить разговор об объёме. Он не решает спор за стороны и не назначает автоматически платность любой просьбы. Важны действующие договорённости, факты и согласованное решение по конкретному расхождению.

Зафиксируйте изменение и его зависимости

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

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

Исходное условие и версия:
Согласованный проверочный пример:
Фактическое наблюдение:
Какого отличия хочет пользователь:
Что уже подтверждено:
Чего не хватает для вывода:
Какие данные и действия меняются:
Затронутые участки и их владельцы:
Нужная оценка влияния:
Решение уполномоченных участников:
Новые принятые условия и способ проверки:

Не вписывайте в карточку выдуманную стоимость. Сначала нужно понять состав и возможность работы, затем получить оценку и согласовать её. Обещание «добавим между делом» не делает влияние на соседние части известным.

Согласуйте повторную проверку

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

Для исправления выберите пример, на котором найдено расхождение, и связанные проверки, на которые влияет правка. Для нового состава добавьте новые ожидаемые результаты. Назовите, кто предъявляет свидетельство и кто принимает изменение.

Успешная проверка на одном примере не означает принятия неизвестного дополнительного объёма. Если повторная проверка невозможна из-за отсутствующего внешнего входа, сохраните промежуточный результат и конкретную зависимость. Не записывайте ожидание как выполненную приёмку.

Граница обещания АИС

УТП АИС Сокол: «До результата — без доплат за наши ошибки.» Оно относится к согласованной задаче. Изменённые требования оцениваются отдельно; обещание не означает бесплатную реализацию любого нового результата.

При обсуждении полезно принести прежнее условие, наблюдение и желаемое отличие. Если основания пока неполны, сначала уточним их. Так вопрос об изменении отдельного участка системы остаётся предметным, а не превращается в спор по ярлыкам.