как я выбросил 10-месячный проект после 2 месяцев в должности / Хабр
Когда я принял управление командой, её участники находились на 8-м месяце реализации 3-месячного проекта по перезапуску коммерческого сайта компании. Спустя два месяца ведения этой команды, я решил отказаться от всего достигнутого и начать сначала. Это история о том, почему я это сделал, как, и что в итоге получилось.
Перезапуск нашего сайта преследовал одну цель: обеспечить быструю отрисовку на стороне сервера.
В удачное время размер нашего JS-бандла составлял 168 МБ. На топовом MacBook Pro среде разработки для начала быстрого реагирования требовалось 3 минуты. Приходя на работу, инженеры уже по привычке вводили npm run dev и шли пить кофе, пока кулеры их компьютеров изо всех сил пыхтели, обслуживая нагрузку, возложенную на них нашим раздутым проектом.
Где же всё пошло не так?
▍ Предыстория
Первым сайтом компании было одностраничное приложение на AngularJS. AngularJS не поддерживал отрисовку на стороне сервера (SSR, server-side rendering), поэтому первая загрузка страницы происходила медленно, и только потом уже всё начинало работать быстро.
А поскольку в интернете играют роль даже миллисекунды, особенно в случае сайтов электронной коммерции, нам нужно было уменьшить время первой отрисовки.
Команда подумывала об использовании Angular 2, и хотя этот фреймворк значительно отличался от AngularJS, он казался логической основой для нового сайта. Мы даже следили за экспериментальной веткой разработки этим проектом функциональности SSR. Естественно, к моменту готовности сайта она тоже должна была быть готова.
Команда создавала сайт, регулярно внося последние изменения из этой экспериментальной ветки в код и разбираясь с возникающими нестыковками.
Я присоединился к ней за две недели до завершения этой функциональности. На тот момент дедлайн нас уже нагонял, но большинство страниц были готовы, и все критические функции работали. Моей задачей было вывести проект в продакшен.
Команда Angular приблизилась к завершению функциональности SSR, и мы привносили последние штрихи в критические маршруты пользователей. Всё шло если не отлично, то по крайней мере… шло. Пока не встало.
У нас был рабочий сайт. Единственное, чего не хватало – это полноценной поддержки SSR. Отрисовка на сервере работала, но не при встряхивании дерева, а AOT-компилятор (критический этап в сборочном конвейере Angular) выдавал бандлы невероятного размера.
Три недели ушло на то, чтобы поставить «приятные бонусы» из списка отложенных задач, включая реально впечатляющее кэширование образов с помощью Nginx (это отдельная история). Мы каждый день проверяли репозиторий Angular в надежде, что там появится критическое исправление.
В итоге приятных бонусов для добавления не осталось, и мы две недели потратили на копание в SSR-ветке команды Angular, но раскидистая, незнакомая база кода и непоправимые ошибки всё сильно затрудняли. Поскольку проект был экспериментальным, толковой документации к нему не было.
Мы тратили время и ни к чему не приходили, хотя чувствовалось, что сдаваться сейчас, когда финиш так близок, будет глупо.
Спустя неделю без какого-либо значительного прогресса и ощутимых действий в апстриме, мои силы были на исходе. На меня всё больше давило руководство, а наши конкуренты определённо не дремали, так что бизнесу нужен был готовый проект.
У нас не было чёткого понимания, как мы сможем поставить имевшийся у нас на тот момент продукт, и встал вопрос: «Можем ли мы позволить себе начать его с нуля?»
Мы оказались в ловушке невозвратных затрат, вкладывая всё больше денег, времени и ресурсов в провальный проект из страха потерять уже вложенные средства.
Если ситуацию не исправить, она неизбежно приведёт ко всё большей потере.
Я не спал ночами, обдумывая решения, которые привели к этому раскладу. По собственному опыту я знал, что React & Redux имели полноценную поддержку SSR.
Я лично видел, как быстро мотивированная команда продвигалась, используя этот стек, но выбрасывание коту под хвост целого года работы очень сильно покачнуло бы дух команды и явно не понравилось бы руководству, которое ожидало от вложенных усилий результатов.
Кроме того, эта мысль противоречила всем инстинктам, которые у меня были относительно масштабных переделок.
▍ Начинаем заново
Самая большая сложность этой затеи заключалась не в технических аспектах, а в личностных. Первым делом нужно было получить одобрение от учредителей. Мне удалось добиться этого, пообещав две вещи:
- Что я буду продолжать следить за проектом Angular SSR, и в случае его выпуска мы тут же запустим сайт на Angular.
- Сайт на React будет доведён до работоспособного состояния за 6 недель, а через 10 мы его уже сможем запустить. Если мне это не удастся, то я пойду на понижение и найду себе замену.
Первое обещание было здравомысленным, а второе отражало мою уверенность, исходящую из личного опыта. Я уже создавал на React сайт с отрисовкой на сервере, и знал, что всё сработает. Если же смотреть с позиции учредителей, то у них имелся чёткий стоп-лосс на случай, если что-то пойдёт не так.
Но самым сложным всё же было получить одобрение от команды. Они провели много месяцев, трудясь над проектом ещё до моего прихода, и теперь я предлагал выбросить всю их кропотливую работу, притом ещё и устанавливая безумный дедлайн на новую. Им нужно было поверить в реалистичность этой затеи и, самое главное, в правильность этого выбора.
Мне требовалось убедить команду использовать стек React, и единственным способом для этого была платформа DevEx. Они должны были увидеть, насколько продуктивно можно работать, если не опираться на их текущие отсталые инструменты.
Я набросал схему проекта React с SSR и выбрал для реализации один поток, установив амбициозную цель создать нашу домашнюю страницу – полностью отзывчивую и с поддержкой SSR – в течение дня моб программирования.
В итоге все были поражены возможностями горячей замены модулей и повторного рендеринга в реальном времени. После проекта, в котором им приходилось ждать отображения изменений вплоть до минуты (в удачный день), это выглядело как магия. Среди команды ещё витал некий скептицизм относительно того, сохранится ли такое быстродействие после создания остальной части сайта, но этой демонстрации было достаточно, чтобы участники команды решили вложиться в реализацию идеи.
Все ценят быстрый цикл обратной связи. Даже короткое ожидание результата изменений может загубить весь рабочий поток.
Вложение усилий в ускорение вашего тестового набора или поиск более производительной системы сборки сокращает этот цикл, а также напрямую повышает вовлечённость и продуктивность команды.
Во второй день мы поделили сайт на 20-30 ключевых пользовательских историй – многие были взяты из первого проекта – приоритизировали их и начали поставлять.
Процесс создания нового сайта происходил онлайн, будучи открытым для всей компании, и к концу первой недели остатки скептицизма испарились, когда все увидели, как далеко продвинулась команда за столь короткий срок.
▍ Поставка
Новый сайт мы поставили, спустя 7 недель сосредоточенных усилий, как раз к одному из самых активных покупательских периодов года. Он был невероятно быстр, в нём использовалось меньше ресурсов, чем в оригинальном сайте на AngularJS, и написанный нами код, спустя несколько лет, до сих находится в продакшене, хотя с тех пор сайт сильно изменился.
Angular Universal с первоклассной поддержкой SSR в итоге был добавлен в Angular v5, вышедший в апреле 2018 года, где-то через шесть месяцев после завершения нашего сайта.
В этом проекте было нарушено два фундаментальных правила управления программными проектами:
1. Не создавайте рабочие приложения с помощью экспериментальных технологий
Версия сайта на Angular как раз создавалась на экспериментальной, неподтверждённой технологии и до сих пор находится в активной разработке.
Это был очень значительный внешний риск, который оставался полностью вне нашего контроля, поскольку мы никак не могли знать, когда никак не отвечавшая перед нами команда Angular поставит свой продукт.
Если бы мы решили продолжать ждать, то простаивали бы вхолостую, не обеспечивая никакой бизнес-ценности в течение 9 месяцев, удвоив продолжительность реализации проекта.
2. Не идите на масштабное переписывание проектов
Решение переписать сайт на Angular 2 без требования следовать поэтапным релизам завело команду в ловушку, вынудив создавать весь сайт до столкновения с основным риском.
Если бы в условиях реализации проекта было заложено требование выпускать поэтапные релизы, то понимание о том, как нужно создавать сайт, возникло бы гораздо раньше.
Здесь внимательный читатель может сказать: «Подождите-ка. Разве проект на React не стал масштабным переписыванием?»
Отвечу так: «Изучайте правила, чтобы знать, когда их можно нарушать».
Я пошёл на сознательное нарушение этого правила, чтобы сохранить мораль команды.
В этом случае я сделал ставку на то, что передовой проект на React сможет сохранить в её участниках мотивацию. Втискивание React в легаси-проект на AngularJS не привело бы к достижению цели, а возвращение к старому коду после нескольких месяцев создания нового нанесло бы сильный удар по духу команды.
Это было очень ситуативное решение. Если бы мы не переходили с провального проекта на Angular 2, то я бы с самого первого дня пошёл на использование одной из прослоек совместимости между React и AngularJS, чтобы перенести сайт постепенно.
Как менеджеру вам нужно играть с той рукой, которая вам выпала, а не с той, какую бы вы хотели получить. Каждая ситуация уникальна, и каждое принимаемое вами решение должно учитывать не только продукт, но и людей, его создающих.
Порой это означает, что вам нужно нарушить устоявшиеся правила. Но помните – у всяких правил есть свои причины, так что не стоит возводить это в привычку.
Telegram-канал с розыгрышами призов, новостями IT и постами о ретроиграх 🕹️
