30 человек в команде, новый домен и адский срок

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

Как-то раз я взял в работу сложную, гигантскую задачу. Я бы даже сказал эпик по нашей системе исчисления задач. У неё был гигантский плюс - мне было всё понятно. Задача хоть и огромная, но логичная, как ходьба.

Приключение на 20 минут...

Новый бизнес-домен, абсолютно неизведанная территория. Но корпоративные пользователи ждали решения вчера и готовы были заплатить🤑. На пике разработки над задачей работало 30 человек — фронт, бэк, мобила на двух платформах, девопсы, аналитики, архитекторы, PM, PO. Красиво звучит, да?

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

Что было дальше? Грусть, боль, печаль и бесконечные доработки. Один раз даже большая переделка. У команды нет сил. Каждый день что-то правим, топчимся на месте, а в проде без особых изменений.

Знакомо?

Сели думать вместе с командой, что пошло нет так

Стандартные проблемы больших проектов:

➖Непонимание общих целей между разработчиками, аналитиками и бизнесом

➖Конфликты видения - как должна выглядеть архитектура, где рисовать границы между сервисами

➖Документация устаревает на ходу разработки, а онбординг новичков становится кошмаром

➖Интеграция между командами - кто за что отвечает, где точки пересечения (интеграции, события, контракты)

Задача была простой и понятной, но «каждый понимал по-своему». Отсюда и результат.

Решение: Solution Concept

До чего додумались: не совершать прыжки веры перед большой работой.

Перед стартом разработать верхнеуровневый "Концепт решения". Solution Concept - документ, который станет источником истины для всей команды.

Что это даёт?

1. Непонимание → Общее видение

Solution Concept заставляет все причастные команды сесть рядом и договориться: что мы вообще делаем, какие микросервисы интегрируются, какие API создаем, что за технологии используем, кто за какой домен отвечает.

2. Хаос архитектуры → Структура

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

3. Устаревающая документация → Вечно актуальный документ

Документ не устаревает, потому что строится на высоком уровне абстракции. Детали меняются, но архитектурные решения остаются.

А изменения очень легко почти без траты времени отразить.

Что включить в документ Solution Concept?

Два уровнея диаграмм C4

🔹 Context (Контекст)

Система «с высоты птичьего полёта». Как она взаимодействует с пользователями и другими системами. Практически не устаревает.

🔹 Container (Контейнеры)

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

Для создания использовать: обычный draw.io, Miro, PlantUML или даже PowerPoint - главное, что визуально и всем понятно.

Почему это сработало у нас?

Когда мы применили этот подход для расширения домена, жизнь стала проще:

➖Наглядность - диаграмма стоит тысячу часов встреч

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

➖Гибкость - подход работает на любом этапе, не нужны навороты

➖Мотивация команды - люди видят большую картину и понимают зачем они что-то делают

От MVP к Production и сразу к масштабированию — без боли и переделок.

Внимание ВОПРОС

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

Минутка саморекламы на тему поста: На осенней конференции МТС в 2024 году я делал детальный разбор этого подхода - со всеми диаграммами, примерами и ошибками, которые мы совершили:

➖RuTube

➖YouTube

➖VK Video