Как ускорить выпуск новых фич: гибкая разработка спасёт ваш проект

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

Нас никто не спрашивал, но мы сделаем вид, что получили такой вопрос: «У меня свой интернет-магазин. Разработчики делают каждое обновление сто лет, что с этим делать?» Ответ: внедрять гибкий подход к задачам.

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

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

При этом гибкость важна не только в решениях, но и в самих процессах. Например, лучше отказаться от методологий вроде «водопада», где сначала пишется километровая документация и только потом начинается разработка. Это должно происходить параллельно, например аналитики формируют требования, а разработчики уже пишут код — Agile даёт свободу и скорость.

Чтобы разработка была предсказуемой и управляемой, можно использовать гибридный подход: как только базовая функциональность описана, её начинают разрабатывать. Этот метод «маленьких водопадов» помогает одновременно ускорять процесс и сохранять контроль над качеством.

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

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

Гибкость в разработке — это не только методология, но и выбор архитектурных решений. Для примера разберём монолитную архитектуру и микросервисы:

Гибкость — это не про «давайте делать микросервисы, потому что сейчас все так делают». Это про выбор архитектуры под задачи и проект с учётом масштаба, нагрузки и частоты обновлений. Приведём пример из нашей работы. Для MR Group — крупного девелопера недвижимости — мы использовали гибридную архитектуру: монолит на «Битриксе» для хранения объектов (квартир, парковок, офисов) и два микросервиса.

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

Чтобы код как можно быстрее попадал в продакшен, помогут DevOps-практики и несколько тестовых сред:

Чтобы упростить выпуск обновлений и избежать ошибок, настраивают CI/CD — систему, которая сама проверяет и загружает код. GitLab CI/CD делает это автоматически, снижая вероятность сбоев.

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

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

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

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

Задача

Когда к нам пришёл «Магнит», у него не было систем, готовых к e-commerce. Нам нужно было создать всё с нуля и интегрировать системы во внутренние процессы компании.

Решение

Мы выбрали монолитную архитектуру на базе «Битрикса», дополнив её фреймворком Symfony и поисковым движком Elasticsearch для работы с большими объёмами данных. Это позволило нам за четыре месяца запустить полностью функционирующий сервис, который принимал заказы, работал с большим каталогом (больше 300 тысяч товаров) и поддерживал стабильную производительность.

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

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