
Всем привет! На связи Сергей Козлов, директор Мегаплана — системы управления бизнесом для небольших команд. В сентябре 2025 года мы выпустили масштабное обновление: улучшили интерфейс и пересобрали тарифы. Для нового старта нам не пришлось массово нанимать разработчиков. Сегодня расскажу о плюсах подхода «всё своими силами». А ещё дам 5 советов тем, кто тоже задумывается о глобальном изменении продукта, но пока по каким-то причинам на него не решается.
Предыстория
За годы работы бигтех-компании сформировали у пользователей определённые схемы поведения, связанные с интерфейсом. Всё стало практически одинаковым: заходя на сайт банка или в приложение маркетплейса, мы заранее знаем, что нас там ждёт, условно говоря, где будет находиться основное меню и как будут выглядеть кнопки.
А как у нас? У нашего продукта тоже длинная история — ему скоро 18 лет. Но со временем наш UX-дизайн стал радикально отличаться от того, что ожидают от него потенциальные пользователи. Например, в классической версии главное меню всегда находилось сверху, в нём было много интерактивных элементов, которые в 2010-х выглядели если не модно, то точно отличали нас от конкурентов.

Со временем мы поняли, что интерактивные иконки отвлекают пользователя и замедляют загрузку страниц, поэтому добавили минималистичный вариант меню. Так пользователь мог сам выбрать удобный формат.
Мы были уникальными, а значит, непривычными. Но чтобы идти в ногу со временем, нужно меняться.
Мы увидели падение интереса к продукту, путаницу в тарифах и снижение активности пользователей. Это стало основными причинами для масштабных перемен. Наша команда провела много исследований и опросов среди клиентов, чтобы понять, с чем это связано и как всё можно починить. Точечных изменений было недостаточно. Так появился проект глобальной перезагрузки, который продлился больше года.
Что поменялось
Новый продукт отличается от классического по нескольким параметрам.
Мы сделали интерфейс лаконичнее, рабочая область расширилась.
Главное меню теперь слева, а не сверху как раньше.
Поиск по системе и уведомления переехали снизу наверх.
Чистка устаревшего кода увеличила скорость работы.
Логика наполнения тарифов изменилась: от постановки задач вручную к шаблонам и полной автоматизации.

Мы приняли решение выпускать обновление только для новых пользователей — тех, кто с нами с сентября. А для ткущих оставить всё как есть. Отчасти это связано с тем, что мы давно на рынке и у наших пользователей сложились привычки. Некоторым не хочется тратить время на переучивание: пусть интерфейс не такой современный, но зато хорошо знакомый.
Между тем классическая версия тоже продолжает развиваться. Ещё в ноябре 2024-го, пока идеи перезагрузки превращались в техзадания, мы сделали доработки для классической версии и сейчас поэтапно их выкатываем. Также в наших ближайших планах — выпустить мигратор для тех, кто захочет перейти на новую версию.
Что происходило с командой
У нас небольшой, но дружный штат разработки и тестирования — всего 20 человек. Мы изначально были настроены практически полностью провести проект силами текущей команды. Почему так?
Во-первых, в этом запуске была очень важна экспертиза в работе с продуктом. Перед командой стояла задача не переписать код полностью, а обновить его — где-то оптимизировать, где-то облегчить, где-то навести красоту.
Во-вторых, у нас сформированный коллектив: мы хорошо знаем бэкграунд, сильные стороны и ограничения друг друга. Поэтому проджект-менеджеру проще найти подход к разработчикам и распределить нагрузку.
Все одинаково смотрят на цель продукта и понимают, что делают одно дело. Поэтому наши разработчики уже давно не ждут, пока на них упадёт новый тикет, а сами берут следующий в очереди.

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

5 советов, как пережить масштабный проект
Марш-броски мы совершаем нечасто, поэтому перезагрузка действительно стала большим вызовом для всей команды. Мы работали над проектом почти год. Вот что помогло справиться с диким стрессом.
Совет 1. Выдыхать, когда всё идёт не по плану
Иногда получалось так, что решение, которое мы изначально придумали, было технически невозможно реализовать. А это означало, что нужно было откатить все этапы назад, переписать требования и всё заново согласовать. Некоторые решения оспаривались в процессе работы. Например, если они ломали обратную совместимость, то есть для их реализации пришлось бы переписать половину кода.
Если проект длительный и объёмный, то изменений в процессе работы, увы, не избежать. Нужно сразу принять: что-то в любой момент может пойти не так, как было задумано изначально, в том числе из-за внешних обстоятельств. Раньше у Мегаплана были интеграции с мессенджерами, которых теперь нет на рынке, то есть наше решение уже не востребовано. К этому нельзя подготовиться на 100%, но нужно спокойно относиться к таким вещам.
Совет 2. Распределять нагрузку
Кто-то из нашей команды работал с интеграциями и телефонией, а другие к ней ни разу не прикасались. Менеджеру проектов было важно учесть опыт каждого, чтобы всем участникам команды задачи оказались по силам.
Чем меньше времени оставалось до релиза, тем больше была нагрузка. В последний месяц перед запуском пришлось прибегнуть к кранч-режиму — из-за аврала все работали больше и дольше обычного. Но скоро всё вернулось в норму.
Совет 3. Отказаться от временных решений
При старом дизайне наш бэкенд отдавал готовый HTML. Чтобы встроить новый дизайн в старую систему, нужно было либо полностью переписать модуль — а это долго и сложно, либо точечно заменить отдельные части интерфейса.
Мы выбрали второй путь. В результате новый и старый интерфейсы оказались тесно переплетены. Чтобы заставить их работать вместе, пришлось писать своеобразные хаки, которые распространились на многие части системы. Со временем эти решения забылись, что периодически вызывало проблемы.
В ходе рефакторинга мы перевели большинство модулей на новый интерфейс и изменили навигацию. Это позволило нам перейти на полноценный SPA, и эти хаки стали просто не нужны. В результате мы не только избавились от источников ошибок, но и добились роста производительности.
Совет 4. Инвестировать в инфраструктуру постоянно, а не по мере возникновения проблем
Внутренние сервисы и инструменты — это фундамент, на котором строится весь продукт. Многие из этих сервисов были разработаны давно и годами работали стабильно. Поскольку явных сбоев не было, их архитектуру не пересматривали.
Однако, когда потребовалось реализовать сложное изменение в бизнес-логике, мы оказались на грани коллапса. Задача, оценённая в несколько дней, превратилась в длительный рефакторинг, поиск скрытых зависимостей и постоянное «тушение пожаров». Хорошо, что у нас есть тестовый контур!
Совет 5. Держать базу знаний перед глазами
Все техтребования и регламенты лучше хранить в одном месте, чтобы команда всегда могла освежить их в памяти. Для этого хорошо подходит база знаний, которая находится внутри продукта.

Раньше всё записывалось в гугл-доках, но корпоративная библиотека оказалась куда удобнее. Не нужно искать документы на диске, удобно делиться ими с командой — всё уже выложено в одно место и настроено под запросы.
***
Главный итог перезагрузки продукта для команды разработки заключается в том, что мы научились упрощать, а не усложнять. Параллельно избавились от давно изживших себя «костылей», до которых в рабочей суете не доходили руки.
От этого даже дышится легче. Как наконец выбросить старую одежду, которая давно не носится, но по-прежнему пылится в шкафу. А на её место повесить новые красивые вещи, которые вам к лицу. Перемены к лучшему заметны и нам самим, и, надеюсь, всем остальным.
А как вы в команде переживаете масштабные проекты?