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

Меня зовут Ирина Колесникова — я тимлид в финтех-компании Точка. В этой статье расскажу, как мы столкнулись с «зоопарком» при переезде с Vue на React, и что помогло превратить хаос в систему. 

Почему мы меняем стек технологий

Смена технологии — не просто модный тренд. Чаще всего у бизнеса есть реальные причины: 

• Устаревший или неэффективный стек. Например, когда технологии больше не поддерживаются или не соответствуют современным требованиям. Типичные «симптомы» — плохая масштабируемость, низкая производительность и высокие затраты на обслуживание. 

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

Мы в команде столкнулась с обеими проблемами, когда переписывали сайт с Vue на React.

Наша история

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

В итоге спустя несколько лет мы оказались в ситуации «зоопарка». Все фронты Точки работали с React, а Vue использовала только наша команда бренда. Это привело к серьезным проблемам:

• Низкая производительность — влияла на лояльность пользователей, посещения, конверсию и позицию в поисковых системах.

• Сложность поддержки — из-за того, что React появился немного раньше, чем Vue, сообщество накопило больше опыта по оптимизации.

• Сложность с интеграцией — так как UI-kit банка поддерживал только React, интегрировать его в наше Vue-приложение было очень сложно.

• SEO-продвижение — предыдущая архитектура сайта использовала клиентский рендеринг: html-код сразу генерировался в браузере пользователя с помощью JS. Несмотря на то, что поисковики научились обрабатывать javascript, в начале двадцатых это работало не всегда хорошо, поэтому контент сайта не индексировался, индексировался не полностью или неправильно. 

Сравниваем технологии

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

Нужно было выбрать между Vue и React, и мы сравнили их по ключевым параметрам: 

• SSR: React предлагает хорошее коробочное решение next.js, у Vue оно тоже есть — nuxt.js.

• Производительность: оба фреймворка предлагают инструменты для улучшения производительности (код-сплиттинг, серверный рендеринг, кэширование). Хотя решение у next выглядело чуть более зрелым, a Vue был удобнее для разработчиков. 

• Доступность специалистов: изучили рынок и поняли, что обучить команду React будет проще, чем искать новых специалистов. К тому же развивать ещё и штат фронтов со стеком Vue не входило в наши планы.

В итоге React с его next.js победил. К счастью, нам не пришлось убеждать команду, что сайт нужно переписывать. Но мы столкнулись с другими проблемами.

Как мы переходили с Vue на React 

После запуска нового фреймворка все задачи по переходу с Vue на React превратились в техдолг. Команда работала по правилу 80 на 20, где 80% времени выделили на фичи, а 20% на техдолг. Но этого было недостаточно. 

Мы разрывались между двумя технологиями и бесконечным бэклогом. Представьте зоопарк, где нужно одновременно бегать между двумя львами (поддерживать две технологии), а ещё успокаивать разъярённых тигров (делать новые фичи и срочные задачи). Команда была перегружена, времени обучаться новым технологиям не хватало, как следствие — было выгорание и задержки проектов. 

Как мы с этим справились:

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

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

• Использовали конструктор для нефункциональных страниц. Перенесли на Tilda страницы, которые не используют сложный код. Таким образом разгрузили техдолг разработчиков и ускорили процесс избавления от Vue. На React мы стали переписывать только высококонверсионные страницы и мэтчили с ребрендингом, чтобы не переписывать код дважды. 

• Создали шеринг компонент. На всех страницах сайтов у нас есть форма заявки — по инструментарию она очень сложная и реализовать такое на Tilda невозможно. Мы создали библиотеку, которую можно использовать на разных платформах, и которая компилируется как в React component, так в JS-код. Таким образом, ещё больше решений смогли реализовывать с помощью конструктора.

• Провели воркшопы с фронтами. Стали привлекать более опытных специалистов из комьюнити для обучения и ревью — прокачали скиллы команды и повысили качество кода. 

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

Как мы адаптировали процесс оценки задач

Мы пробовали три методологии приоритезации задач:

1) Rice — учитывает охват, влияние, уверенность и трудозатраты на фичу. Когда мы применили его к нашему бэклог, то поняли, что:

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

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

2) Cost of Delay — оценивает, сколько бы мы могли заработать, если бы эта фича уже была, и сколько бы мы потеряли, если бы она была реализована с задержками. Здесь мы уже можем переводить бэклог в деньги, но всё равно оказалось, что:

• Не все задачи можно прозрачно сконвертировать.

• Стоимость часто определяется на приближённых данных, поэтому оценка искажена.

• Даже на искажённую оценку уходит много трудозатрат.

3) Weighted Scoring — позволяет самому выбрать критерии, которые важны для оценки задач. Это могут быть: охваты, пользовательский опыт, риски и т.д. Каждому критерию присваивают вес в процентах, а все они в сумме должны быть равны 100. В итоге оказалось, что:

• Не так просто настроить вес для каждого параметра. 

• Если у вас много факторов, сложнее оценить каждый из них справедливо и точно. 

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

• Охваты — сколько людей потенциально затронет фича в ближайший квартал;

• Конверсия — сколько заявок она принесёт; 

• Трудозатраты — на старте их оценить очень сложно, поэтому мы типизировали объёмы задач и дали им вес от 1 до 5;

• Влияние на продукт — функциональные требования;

• Ограничения системы — нефункциональные требования (несет ли задача новый функционал или существенные изменения кода);

• Наша уверенность в реализации — действительно ли мы сможем это сделать.

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

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

Факапы, которые мы допустили

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

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

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

А вот каких ошибок нам удалось избежать:

• Оценивать в одиночку. К оценке у нас привлечены и разработчики, и сеошники, и маркетологи — так мы минимизируем риск упустить важные детали или недооценить влияние задачи на другие аспекты продукта. При этом мы не собираемся большой компанией, чтобы оценить задачу, а типизировали все критерии, поэтому оценку может поставить один человек — маркетолог, продукт или project. 

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

• Вестись на «крикунов». Берем задачи не у тех, кто громче прокричит, а используем данные аналитики и метрики. 

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

Что делать, если вы тоже работаете в «зоопарке»?

Если ваш проект сейчас тоже похож на зоопарк — знайте, что это не приговор. 

С правильным подходом любой хаос можно превратить в систему:

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

• Держите фокус на бизнес-задачах: выбирайте технологии с учётом конкретных целей и задач компании, а не потому, что они сейчас в тренде.

• Регулярно пересматривайте приоритеты: анализируйте бэклог и адаптируйте планы в зависимости от текущих потребностей бизнеса. 

А какие «звери» живут в вашем «зоопарке»?