Шаг 1. Source Map — карта источников проекта.
Если честно, еще полгода назад я не понимал, насколько это вообще важная вещь. Казалось, что Source Map — это просто реестр документов. Ну есть список файлов, ссылок и репозиториев. И что?
Но стоит один раз попасть в ситуацию, когда два документа противоречат друг другу, и отношение меняется моментально.
Возьмем простой пример. По кейсу Acme Pay у нас есть четыре источника:
• acme-pay-api-contract.pdf — 47 страниц, обновлен 12.03.2026, актуальный;
• Confluence Acme Pay v1 — написана в октябре 2025 года, помечена как deprecated;
• Git-репозиторий integration-acme-poc — proof of concept, последний коммит в октябре 2025;
• email-тред с поддержкой Acme — пять писем за март 2026 года.
Если просто открыть самый свежий PDF и начать писать постановку, кажется, что всё необходимое уже есть.
Но Source Map заставляет сначала ответить на другой вопрос: каким источникам вообще можно доверять?
И тут выясняется самое интересное. В переписке с поддержкой есть изменение, которого пока нет в публичной документации: после релиза v2.1 время жизни авторизационного токена сократили с 24 часов до 4 часов. Документация ещё не обновлена, а интеграция уже работает по новым правилам.
Если не знать о существовании этого письма, можно совершенно спокойно написать корректную с точки зрения PDF постановку… которая не будет работать в продакшене.
Именно поэтому я перестал воспринимать Source Map как ещё одну таблицу для аналитика.
Это карта доверия к информации. Она помогает понять, какие источники актуальны, какие уже устарели, где есть противоречия и чего ещё не хватает для принятия решения.
И только после этого имеет смысл открывать документы и начинать анализировать требования.
Потому что проблема редко заключается в том, что аналитик не умеет читать документацию. Гораздо чаще проблема в том, что он читает не ту документацию.