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

Предыстория

За годы работы бигтех-компании сформировали у пользователей определённые схемы поведения, связанные с интерфейсом. Всё стало практически одинаковым: заходя на сайт банка или в приложение маркетплейса, мы заранее знаем, что нас там ждёт, условно говоря, где будет находиться основное меню и как будут выглядеть кнопки. 

А как у нас? У нашего продукта тоже длинная история — ему скоро 18 лет. Но со временем наш UX-дизайн стал радикально отличаться от того, что ожидают от него потенциальные пользователи. Например, в классической версии главное меню всегда находилось сверху, в нём было много интерактивных элементов, которые в 2010-х выглядели если не модно, то точно отличали нас от конкурентов. 

Меню в классической версии
Меню в классической версии

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

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

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

Что поменялось

Новый продукт отличается от классического по нескольким параметрам.

  • Мы сделали интерфейс лаконичнее, рабочая область расширилась.

  • Главное меню теперь слева, а не сверху как раньше.

  • Поиск по системе и уведомления переехали снизу наверх.

  • Чистка устаревшего кода увеличила скорость работы.

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

Классический и новый интерфейс
Классический и новый интерфейс

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

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

Что происходило с командой

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

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

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

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

Изменения произошли в организационной структуре: разработчики разделились на две команды
Изменения произошли в организационной структуре: разработчики разделились на две команды

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

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

Мы изначально были настроены практически полностью провести проект силами текущей команды
Мы изначально были настроены практически полностью провести проект силами текущей команды

5 советов, как пережить масштабный проект

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

Совет 1. Выдыхать, когда всё идёт не по плану 

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

Если проект длительный и объёмный, то изменений в процессе работы, увы, не избежать. Нужно сразу принять: что-то в любой момент может пойти не так, как было задумано изначально, в том числе из-за внешних обстоятельств. Раньше у Мегаплана были интеграции с мессенджерами, которых теперь нет на рынке, то есть наше решение уже не востребовано. К этому нельзя подготовиться на 100%, но нужно спокойно относиться к таким вещам. 

Совет 2. Распределять нагрузку 

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

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

Совет 3. Отказаться от временных решений

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

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

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

Совет 4. Инвестировать в инфраструктуру постоянно, а не по мере возникновения проблем

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

Однако, когда потребовалось реализовать сложное изменение в бизнес-логике, мы оказались на грани коллапса. Задача, оценённая в несколько дней, превратилась в длительный рефакторинг, поиск скрытых зависимостей и постоянное «тушение пожаров». Хорошо, что у нас есть тестовый контур!

Совет 5. Держать базу знаний перед глазами

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

Наша база знаний
Наша база знаний

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

***

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

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

А как вы в команде переживаете масштабные проекты?

Комментарии (0)