📜 Пост: УПРАВЛЕНИЕ ИЗМЕНЕНИЯМИ: КАК НЕ ПОТЕРЯТЬ ТРЕБОВАНИЯ Привет, коллеги! 👋 Знакомая ситуация: в середине разработки приходит «срочное» изменение от бизнеса. Вы его приняли, разработчики переделали, а через месяц выясняется, что забыли поправить связанные модули. Система стала работать несогласованно. Как этого избежать? Ответ — трассируемость требований и автоматические проверки. 🔍 📌 Кейс: «Новый тип клиента — VIP» В CRM появилось требование: «VIP-клиентам давать скидку 15% вместо стандартных 5%». Аналитик добавил новое поле customer_type в карточку, разработчики поправили модуль расчёта скидок. Через неделю обнаружилось, что: В отчётах по выручке VIP-клиенты считались по старой ставке. Сервис рассылок отправлял VIP-клиентам стандартные предложения. Поддержка видела в интерфейсе старый тип клиента. Что пошло не так? Никто не отследил, где ещё используется тип клиента. Как код помогает аналитику управлять изменениями? 1. Создаём единый контракт данных (схему) Вместо разрозненных полей в разных системах, аналитик описывает общую структуру: # shared_schema.py from pydantic import BaseModel class Customer(BaseModel): id: int name: str type: str # "regular" или "vip" 2. Пишем тесты на согласованность Тест проверяет, что все сервисы работают с одной и той же схемой: def test_customer_schema_consistency(): from crm import get_customer from billing import get_discount test_cust = Customer(id=1, name="Test", type="vip") # CRM должен отдавать тот же формат assert get_customer(1) == test_cust.dict() # Биллинг должен распознать VIP assert get_discount(test_cust) == 15 3. Автоматизируем трассировку В требованиях аналитик заводит теги (например, @customer_type). Каждый сервис, зависящий от типа клиента, обязан иметь тест, который падает при изменении контракта. CI/CD не пропустит изменение, пока не будут обновлены все зависимости. 📌 Кейс: «Автоматическая проверка на CI» В одном проекте при изменении статуса заказа аналитик создал тест, который запускался на каждом PR: def test_order_status_traceability(): # Список мест, где используется статус заказа dependencies = [ "notifications/service.py", # отправляет уведомления "reporting/generate.py", # формирует отчёты "warehouse/stock.py" # обновляет склад ] for file in dependencies: # Проверяем, что в файле есть обработка нового статуса with open(file) as f: content = f.read() assert "status == 'new_status'" in content, f"{file} не поддерживает новый статус" Когда бизнес попросил добавить статус "awaiting_manual_check", этот тест указал, какие сервисы нужно доработать. Ничего не забыли, релиз прошёл гладко. 🎯 Что даёт такой подход? Ничего не выпадает из поля зрения — все зависимости под контролем. Изменения безопасны — тесты не дадут забыть про связанные модули. Прозрачность для команды — видно, где и что используется. Быстрая адаптация — новые члены команды видят связи через код. Совет: Начните с малого — для самых критичных сущностей (заказ, клиент, платёж) создайте тесты на согласованность. Со временем они сэкономят часы отладки. #REQUIREMENTS