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

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

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

Ловушка здесь одна: новые требования ложатся на фундамент, которого никто не видел. Предлагаю несколько принципов, которые уже помогли мне и, возможно, смогут помочь и вам.

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

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

3. Размечать документацию, а не переписывать Переписать полсотни устаревших страниц в горящие сроки невозможно. Поэтому каждой странице ставим один из трех статусов: подтверждено (трафиком и есть примеры), опровергнуто (есть наглядные примеры), не проверено. Переписываем потом и только опровергнутое. Разметка занимает день-два и сразу снимает главный риск: люди перестают верить неверному.

4. Собрать открытые вопросы в один документ То, что не удалось восстановить, идет в список вопросов поставщику. Одним документом, а не по одному вопросу в переписке. По каждому вопросу сразу пишем, что без ответа заблокировано. Так вопрос перестает быть обычным любопытством аналитика и становится блокером с зафиксированной ценой.

5. Сделать блокеры видимыми для руководства Фраза «нам нужно больше времени» не работает. Работает таблица: требование, что мешает его реализовать, от кого ждем ответ и с какого числа. Задача не отбиться от сроков формальной таблицей, а показать, из чего этот срок состоит. Дальше решение принимает тот, кто за срок отвечает, и обычно это уже не аналитик.

6. Принимать новые требования письменно и с критерием приемки Особенно касается требований к сертификации: по каждому требованию должно быть записано, как проверяется, что оно выполнено, и что должно быть в результате. Устной договоренности с поставщиком на сертификации не существует.

Немного про давление с двух сторон: Аналитик в такой ситуации стоит посередине, и это ощущается как личная проблема. Фактически она не личная, а структурная: две стороны принимают решения, не видя ограничений друг друга. Все шаги выше сводятся к одному - сделать невидимое видимым. Когда обе стороны смотрят в один список, разговор переходит с "почему так долго" на "что убираем из первой волны".

Чем закончилась моя история? К сожалению, срок сертификации все-таки пришлось сдвинуть. Но не потому, что мы попросили это сделать, а потому, что стало видно, из чего он состоит. Часть требований ушла за пределы сертификации, и это оказалось "ок" для всех.

А вам приходилось восстанавливать требования к тому, что уже работает? Интересно, откуда вы брали правду: логи, код или людей.

Открыта к предложениям, если вашей команде нужен аналитик.

#системныйаналитик #бизнесаналитик #интеграции #требования