Мы выпустили нашу LMS в прод. И этот релиз ещё раз напомнил мне одну вещь: Успешный релиз - это момент, когда команда понимает, что уже все - время нет, а спринт забит выше потолка и что-то нужно резать, а где-то сжимать булки и доделывать, чтобы уложиться в дедлайн.

Большую часть разработки мы находились в условиях постоянно меняющихся бизнес требований (точнее, постоянно уточняющихся) по проектируемым фичам. Бизнес-требования ещё уточнялись. ADR были не до конца согласованы. API-контракты продолжали меняться. Часть инфраструктуры, включая production-контур, появилась прямо перед релизом. При этом очевидно, что остановить разработку и ждать, пока всё окончательно согласуют, мы не могли. Поэтому одну из ключевых вещей пришлось делать не по границам фич, а по степени определённости и зависимостям. Хороший пример - страница результатов. Мы начали реализацию ещё до того, как ADR и API-контракт были полностью консолидированы.

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

UI и presentation-слой можно было двигать независимо. Недосогласованные части бизнес-логики и контракта просто оставались лежать в холде до момента закрытия бэкендом своей задачи, чтобы фронт мог протестировать интеграцию. Как правило, мы сходились, благодаря четко зафиксированному API интерфейсу. Такой подход хорошо работал, пока у нас ещё оставался некоторый запас по срокам. А потом наступила последняя неделя перед релизом.

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

Вопрос уже был не: Как сделать самое красивое архитектурное решение? А: Что прямо сейчас не дает нам выкатить прод на юзеров?

Мы убрали всё второстепенное, разложили оставшуюся работу на независимые куски, распределили её внутри frontend-команды и явно отмечали блокировки там, где задачи зависели от ещё неготового layout, API или инфраструктуры.

Для меня это был важный момент: заблокированная задача не должна просто молча висеть в работе. У зависимости должен быть владелец, а её снятие должно становиться частью release-плана. Параллельно всё равно нужно было оставлять место под баги, ревью и неожиданные проблемы. И они, конечно, появились.

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

При примерно 4× от обычной нагрузки любой такой сайдквест уже начинает стоить очень дорого. Этот темп помог нам дойти до релиза, но это скорее инструмент аварийного реагирования, чем прирост производительности команды😅.

Как frontend lead я при этом оставался hands-on: участвовал в архитектурных обсуждениях и ADR, декомпозиции, писал код, ревьюил MR, разбирал интеграционные проблемы, управлял блокерами и участвовал в production rollout. Это эта самая часть технического лидерства, что нравится нравится мне больше всего: сохранять достаточно гибкости, пока решение ещё не определено окончательно, и жёстко защищать critical path, когда дата релиза становится реальной.

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