Как развивать сайт банка без редизайна и перезапуска

Сайт банка нельзя просто обновить за один день: он должен всегда работать без сбоев, соответствовать требованиям ЦБ РФ, стандартам информационной безопасности, нормам раскрытия финансовой информации, а также выдерживать атаки. При этом продукт необходимо регулярно обновлять и актуализировать.

Рассказываем, как команда Nutnet более четырёх лет участвует в развитии сайта Датабанка без полного перезапуска: от UX‑аудита и переработки форм до интеграций, автоматизации и защиты от DDoS.

Как было устроено развитие сайта на старте

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

К моменту начала работы с Nutnet сайт уже выполнял свои задачи, но нагрузка на него постепенно росла и количество доработок увеличивалось.

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

В такой ситуации разовые доработки уже не решали задачу — нужен был системный подход к развитию продукта.

Почему банк выбрал эволюционное развитие вместо полного редизайна

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

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

Кроме того, продукт должен соответствовать требованиям регулятора и информационной безопасности. Это накладывает ограничения на скорость и формат изменений: часть задач требует согласований и поэтапного внедрения.

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

Работа ведётся уже более четырёх лет. За это время удалось выстроить предсказуемый процесс: вместо нерегулярных доработок — постоянный поток задач с понятными сроками и приоритетами.

Формат работы — с фиксированным объемом часов в месяц. Это позволяет банку планировать затраты, а нам — равномерно распределять нагрузку и не перегружать команду.

Как приоритизировали задачи

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

На первом месте — безопасность. Мы учитывали рекомендации ЦБ РФ и ФСТЭК, 152‑ФЗ, отслеживали уязвимости в проектах на 1С‑Битрикс и оперативно закрывали потенциальные риски. Для банковского сайта это базовый уровень, без которого невозможно двигаться дальше.

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

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

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

Работу выстроили по спринтам. В каждом из них сочетали три типа задач:

1. Техническая поддержка и исправление ошибок.
2. Аналитика и дизайн (подготовка решений для следующих итераций).
3. Внедрение уже проработанных изменений.

Так удавалось одновременно поддерживать стабильность и регулярно выпускать обновления.

Что именно меняли на сайте

Привели формы к единому стандарту. На сайте было более 50 форм, которые создавались в разное время под разные задачи. В результате они отличались по логике, внешнему виду и поведению: элементы выглядели по‑разному, часть полей работала некорректно, а валидация либо отсутствовала, либо была реализована не везде.

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

Постепенно обновили интерфейсы и ключевые страницы. Мы переупаковали некоторые продуктовые разделы и сервисные страницы: страницы офисов и банкоматов, РКО, слайдер для страницы «Датабанк Онлайн». Отдельное внимание уделили навигации: переработали меню, баннеры и ключевые переходы, чтобы упростить доступ к нужным разделам и сократить путь до целевого действия.

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

Запустили закрытый раздел для совета директоров. Одной из значимых задач стал закрытый раздел для совета директоров. После авторизации члены совета директоров получили доступ к материалам заседаний. В дальнейшем функциональность была расширена до онлайн‑голосования с автоматической фиксацией результатов.

Это решение позволило банку упростить внутренние бизнес‑процессы, отказаться от офлайн‑встреч и сократить бумажный документооборот.

В этом разделе пользователи в удобном формате получает всю информацию о предстоящем заседании: описание, ссылку на онлайн‑встречу, документы для ознакомления. Там же доступно голосование — оно принимается только один раз, без возможности изменения выбора. Итоги автоматически направляются секретарю.

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

Дополнительно доработали авторизацию через Госуслуги. Это позволило пользователям быстрее заполнять формы за счёт автоподстановки данных и упростило сценарий подачи заявки.

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

Адаптировали сайт под новые требования безопасности. Отдельный блок работ был связан с соответствием регуляторным требованиям и внутренним стандартам безопасности банка.

Совместно с командой банка мы пересмотрели подход к обработке данных и используемым сервисам в рамках 152‑ФЗ: перешли на российские решения, включая Яндекс Метрику и Яндекс Капчу. Это позволило привести сайт в соответствие с актуальными требованиями по работе с персональными данными.

Отдельно проработали политики доступа: вход в административную часть ограничили по IP‑адресам, а для разработки и тестирования выделили отдельный закрытый контур. Такие решения помогли снизить риски и чётко разграничить рабочие среды.

Усилили безопасность и инфраструктуру. Параллельно мы усиливали техническую устойчивость сайта. Провели аудит и устранили уязвимости, характерные для проектов на 1С‑Битрикс, обновили модули и используемые библиотеки.

Оптимизировали инфраструктуру: пересобрали отдельные части системы и обновили стек, чтобы повысить стабильность работы и упростить дальнейшую поддержку.

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

Как мы справились с DDoS‑атаками

В процессе работы сайт столкнулся с DDoS‑атаками: под нагрузкой он периодически становился недоступным. При этом атака была целенаправленной — после смены IP‑адреса она возобновлялась.

Совместно с командой банка мы оперативно перестроили инфраструктуру: за три дня перенесли сайт на защищённую среду и настроили его работу с учётом новых требований безопасности.

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

Дополнительно усилили контроль за входящим трафиком и уязвимыми точками. В результате удалось стабилизировать работу сайта и снизить влияние внешних атак на его доступность.

С какими ограничениями пришлось работать

Проект развивался в условиях жёстких требований к безопасности и работе с персональными данными. Любые изменения нужно было соотносить с 152‑ФЗ, внутренними политиками банка и актуальными стандартами защиты.

Дополнительные ограничения задавали требования ЦБ РФ и ФСТЭК. Это влияло на выбор технологий, архитектурные решения и скорость внедрения: часть задач требовала предварительных согласований и дополнительной проверки.

Также мы учитывали особенности инфраструктуры. Не все решения можно было внедрить «как есть» — приходилось адаптировать их под существующую систему и ограничения по доступам.

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

Как принимали решения и общались с клиентом

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

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

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

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

Что это дало бизнесу

Интерфейсы стали более понятными и удобными, а ключевые процессы — частично автоматизированы. Это снизило нагрузку на сотрудников банка и сократило долю ручной обработки заявок.

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

Наши выводы об эволюционном подходе

1. Подходит, когда нельзя или нецелесообразно останавливать продукт ради масштабного редизайна: позволяет обновлять интерфейсы и процессы без риска для текущей работы сайта.
2. Эффективен при ограниченных ресурсах: фиксированные спринты и приоритизация задач помогают планировать изменения и получать заметный результат без увеличения команды и бюджета.
3. Актуален в условиях строгих регуляторных требований: упрощает адаптацию к новым нормам, обновление авторизации, процессов обработки данных и систем безопасности без длительных пауз.
4. Оправдан при работе с legacy‑системами: постепенные UI/UX‑улучшения, стандартизация форм и интеграций снижают риск поломок и позволяют развивать продукт без масштабного рефакторинга.
5. Позволяет одновременно поддерживать стабильность продукта, снижать операционную нагрузку и развивать функциональность без резких затрат.