Не меняйте команду будто перчатки! Как мы обновили взрослый ИТ-продукт без масштабного найма разработчиков

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

