Привет! Я Иван Воробьев, системный аналитик Далее. Часто нам приходится работать со сложными системами не только с нуля, но и на саппорте. И для аналитика это кардинально разные контексты, риски и косты ошибок. 

На поддержке каждый error стоит сильно дороже, а допустить его в разы проще. В этой статье расскажу, что точно повредит ваш прод при доработках и как этого избежать. 

Содержание:

• Разница между аналитикой с нуля и на поддержке

• Самые частые и критичные ошибки при «улучшении» системы

• Сценарий работы на саппорте с минимизацией рисков  

• Что важно для аналитика вне зависимости от типа проекта

Разница между аналитикой с нуля и на поддержке

Если кратко, то глобальные отличия между задачами с нуля и на поддержке наиболее заметны в трех местах:

• контексте и точке входа;

• количестве и типах ограничений;

• приоритизации и распределении времени.

В первом случае основная задача — создать логику, когда еще ничего нет и никто не знает, как будет. Здесь большая часть требований существует в виде идей и обсуждений, а работа стартует с формализации. Нужно: 

1. Собрать бизнес- и функциональные требования в единый док, включая правила валидаций и описания исключений. 

2. Спроектировать модели данных, бизнес-процессов и логики: BPMN-схемы, сценарии пользователей, дерево решений, статусные модели.

3. Обозначить нефункциональные требования: скорость отклика компонентов, ограничения по объему данных и безопасности, сценарии нагрузки.

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

Например:

Для проекта спортивного мероприятия я отрисовывал подробные схемы в Miro: все шаги, статусы, валидации и email-уведомления. Это позволило мне увидеть, что условие допуска к забегу (минимум 5 человек) и условие закрытия набора (максимум 10 человек) — разные состояния. Но бизнес называл их одним словом «Собрана». 

Статус «Собрана» звучал как финальный в обоих случаях, хотя по факту был таким только в последнем. Я предложил разделить эти понятия на:

• «Укомплектована» (5-9 участников): команда выполнила норматив и уже допущена к забегу, но все еще может принимать новых участников.

• «Собрана» (10 участников): команда достигла лимита, набор закрыт окончательно.

Это решение легло в основу логики личного кабинета капитана и сняло вопросы у пользователей. 

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

Сначала пришлось:

1. Разобраться в текущем поведении системы. 

2. Изучить внешнюю спецификацию.

3. Выделить только те методы, которые реально нужны. 

Отдельным вопросом стали крайние сценарии: как обрабатывать дубликаты пользовательских телефонов, если на сайте они допустимы, а в CRM — нет.

Я описал в ТЗ логику проверки на дубликаты перед созданием нового пользователя. После самостоятельно протестировал всю интеграцию через Postman, подготовив для этого необходимые коллекции запросов.

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

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

Самые частые и критичные ошибки при «улучшении» системы

Дорабатывая систему, мы обычно имеем дело с ее разными частями. Но нельзя мыслить в рамках только своего куска продукта. Любое, даже самое безобидное изменение тянет за собой хвост зависимостей: форматы экспорта/импорта, смежные модули, чужие API. Если вы меняете приемник, то обязаны кропотливо проверить источник. 

Вот список типичных «узких мест»:

1. Интеграции и форматы данных

В чем риск: Поменяли тип поля, добавили обязательный параметр или изменили структуру JSON, но забыли предупредить смежную систему. Или, наоборот, система-донор прислала данные, которые мы не ожидали.

Как ломает прод: Отваливаются оплаты, не загружаются товары, заявки улетают в пустоту.

2. Объем исторических данных (нагрузка на БД)

В чем риск: На тестовом стенде у нас 100 записей, и новый SQL-запрос или алгоритм фильтрации отрабатывает за миллисекунды. На проде — миллионы записей, и этот же алгоритм вызывает полное сканирование таблицы.

Как ломает прод: БД ложится от перегрузки, весь сайт зависает для всех пользователей.

3. Неочевидные зависимости

В чем риск: Удаляем «ненужное» поле в карточке или меняем логику перехода статусов в одном модуле, не проверив зависимости. А потом оказывается, что на это поле была завязана логика выгрузки отчетов для бухгалтерии или отправка триггерных email-рассылок.

Как ломает прод: Ломаются бизнес-процессы в других, не связанных с нашей доработкой частях системы.

4. Фоновые процессы и планировщики

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

Как ломает прод: Выкатили релиз днем — все работает идеально. Ночью запускается скрипт пересчета остатков, натыкается на измененную логику, падает с ошибкой, и утром бизнес просыпается с неактуальными данными.

5. Накатывание миграций на «грязные» данные

В чем риск: Решили сделать старое поле обязательным not null или значения в нем уникальными. Но в БД уже лежат тысячи старых записей, где это поле пустое или дублируется.

Как ломает прод: Релиз просто не может выкатиться на бой, миграция БД падает с ошибкой, деплой останавливается.

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

Сценарий работы на саппорте с минимизацией рисков

На поддержке мы ⅔ времени тратим именно на изучение, что и как реализовано, а только потом аккуратно внедряем изменения. При этом не стоит надеяться на документацию, если она вообще есть. В любом случае копаться придется в самой системе и перепроверять, как решение отрабатывает в действительности.

Весь процесс включает 5 основных этапов.

1. Разбор текущего поведения — нельзя описывать решение, пока неясно, что происходит внутри системы. Обычно это означает:

• изучить, где и как хранятся данные и их вариации;

• понять, какие модули завязаны друг на друга;

• посмотреть, как это работало в предыдущих релизах;

• поднять логи, чтобы узнать о возможных сбоях; 

• собрать реальные кейсы поведения пользователей.

Глубокий анализ «Как есть» особенно важен при интеграциях, когда появляется зависимость еще и от внешнего вендора. Нужно хорошо разбираться в своей системе и стороннем продукте, чтобы отладить их взаимосвязь. 

2. Работа с ограничениями и наследием. На поддержке аналитик не создает правила, а подстраивается под уже существующие:

• технические ограничения — валидаторы, уникальности, API;

• UX-наследие — что пользователь привык видеть;

• административные процессы — как контент-менеджеры работают сейчас;

• архитектурные решения, которые менять нельзя.

Не экономьте силы на изучение всех нюансов. Узнайте, какие еще были варианты реализации и почему их отклонили. В живой системе любое изменение несет риски, которые стоит предусмотреть заранее.

3. Анализ рисков и ревью. При создании решений мы оцениваем не только их логику, но и стоимость возможной ошибки: 

• какие сущности затрагивает изменение, 

• можно ли быстро откатить последствия, 

• есть ли риск порчи или перезаписи данных, 

• на какое количество пользователей это потенциально повлияет. 

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

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

Например, на моем проекте в карточках товаров производителя питания были ссылки на точки продаж — аптеки. Они управлялись в админке: контент-менеджеры вручную правили HTML-поле, что было неудобно и приводило к ошибкам. 

Мне на проверку передали макет нового решения, но и в нем я увидел недостаток: сопоставление аптек и ссылок на них шло по порядковому номеру. Это было рискованно, так как случайное изменение порядка аптек в списке сломало бы все ссылки в товаре — привет, ошибка 404! 

4. Описание изменений на уровне «что затронет» — ТЗ на поддержке должно быть предельно точным. Мы не просто описываем доработку как фактический итог, но и указываем: 

• где именно и для каких ролей и статусов вносятся изменения,

• какие модули могут быть затронуты,

• какие сценарии должны остаться прежними,

• что нужно проверить после релиза.

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

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

• авторизация, 

• поиск пользователя, 

• создание, 

• обработка ошибок. 

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

Главное правило на поддержке: если задача кажется «маленькой» — проверь ее вдвое тщательнее.

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

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

Что важно для аналитика вне зависимости от типа проекта

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

1. Фокус на бизнес-задаче, а не на формулировке. В обоих сценариях аналитик пытается понять не «какую кнопку нарисовать», а что именно хочет решить клиент. Это помогает избежать ситуации, когда команда выполняет задание буквально, но реализация не приносит пользы.

2. Работа с рисками и крайними сценариями. Аналитик всегда отвечает на вопрос «что может пойти не так». Разница только в источниках риска:

• в новом проекте это неопределенность и недосказанность,

• в поддержке — скрытые зависимости и исторические решения.

Но подход одинаковый: рассматривать альтернативные пути, ошибки, спорные ситуации.

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

4. Фокус на пользователе. Всегда идет проектировка решения для кого-то. Это может быть как внешний клиент, так и внутренний сотрудник. Все, что создается, должно быть максимально упрощено, удобно и логично. 

5. Фиксация разговоров. Устная договоренность — не договоренность. И там, и там важно быстро переводить обсуждения в документы, схемы и требования. Это снижает количество спорных ситуаций и ошибок.

Сравнение роадмапов системной аналитики в проектах с нуля и продуктов на поддержке

^{Аналитика проектов на старте и продуктов на сопровождении}

Да, наша работа меняется в зависимости от того, создается ли продукт с чистого листа или развивается существующий. Но в любой модели цель одна — сделать так, чтобы система была предсказуемой, не ломалась и приносила пользу тем, для кого она создана.

Лично мне больше нравится работать с проектами на старте. Но не из-за рисков, а из-за свободы в решениях. А вам?