Расскажите, как вы работали с изменением требований после начала разработки.

Шаг 4: Change Log в спецификации

В верхней части страницы требований появился раздел:

## Change Log
2024-03-15 | Added field inn_number for legal entities | Requested by: Sales (client ACME Corp) | Impact: DB schema, POST /users, registration form UI

Это стандартная практика, которую часто игнорируют, а потом теряются: «почему мы вообще это сделали?»

Ситуация

На третьей неделе двухмесячного спринта (да, бывают и такие) PO пришёл с новостью: крупный корпоративный клиент требует, чтобы в форме регистрации появилось поле «ИНН организации» — без этого он не подпишет контракт. Разработчики уже написали 60% фичи по старым требованиям.

Шаг 1: Остановиться и оценить масштаб изменения

Первым делом я попросил паузу в разработке и провёл Impact Assessment — структурированный анализ влияния изменения:

• Что уже готово и станет невалидным? — форма регистрации (UI + валидация), схема БД таблицы users, API контракт POST /users
• Что ещё не затронуто? — email-верификация, onboarding flow, настройки профиля
• Стоимость изменения сейчас vs. после релиза: сейчас — ~2 дня; после — миграция данных + повторное QA + координация с клиентом

Шаг 2: Уточнить требование до конкретики

«Поле ИНН» — это ещё не требование. Я задал уточняющие вопросы:

• ИНН обязателен для всех или только для корпоративных аккаунтов?
• Нужна ли валидация формата (10 или 12 цифр для физ/юр лиц)?
• ИНН отображается только в профиле или экспортируется в отчёты?
• Что происходит с существующими пользователями без ИНН?

Ответы сократили scope вдвое: ИНН нужен только юридическим лицам, только для внутренних отчётов, валидация — только длина.

Шаг 3: Обновить документацию до начала правок в коде

Я обновил user stories в Jira, добавил новые AC и пометил старые как superseded. В Confluence обновил раздел Data Dictionary с новым полем. Это заняло 40 минут, но предотвратило ситуацию, когда часть команды работает по старым требованиям.

Шаг 5: Ретроспектива процесса

После релиза я поднял на ретро вопрос: как этот запрос от клиента вообще попал к нам на третьей неделе, а не до старта? Выяснилось, что Sales знал об этом требовании клиента ещё месяц назад, но не передал в продукт. Мы ввели правило: Sales участвует в kick-off meeting для фич, связанных с enterprise-клиентами.

Подводные камни

• Принимать изменение требований без Impact Assessment: без оценки вы не знаете, стоит ли это 2 часа или 2 недели.
• Менять код до обновления документации: разработчики начинают работать по разным источникам истины.
• Не уточнять «а что именно?»: «добавь поле» может означать всё что угодно — от строки в форме до изменения биллинговой логики.
• Забывать про существующих пользователей: любое новое обязательное поле ломает данные всех, кто зарегистрировался до него.
• Не фиксировать, кто и почему запросил изменение: через месяц это станет неизвестно, и начнутся дебаты.
• Не адресовать системную причину: если изменения приходят поздно регулярно — это процессная проблема, а не разовый инцидент.

• Незаметно поменять spec без уведомления команды.
• Считать любое изменение ошибкой stakeholder.
• Не оценить impact на уже сделанную работу.

• Проводит impact analysis.
• Поддерживает актуальные артефакты.
• Помогает команде принять изменение без хаоса.