Рассказываем, как бороться с техдолгом на примере сайта «Едим дома»

Что может пойти не так?

Цифровые продукты требуют внимания, как и любой бизнес.

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

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

Чаще всего за разработку и поддержку отвечает технический директор, но его может не быть, если цифровой продукт — не источник прибыли. Как в случае с проектом «Едим Дома» — сайт в их случае работал как канал продвижения бренда, поэтому большого IT-департамента не было. Из-за этого началась неразбериха в управлении разработкой, а потом, как следствие, технические сложности.

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

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

Исправляем ошибки в цифровом продукте

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

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

В случае с «Едим дома» аутсорс отлично подошел — решение нужно было срочно, ведь пользователи уходили каждый день, когда сайт не работал. Они оценили нашу экспертизу в Ruby и опыт работы с другими клиентами, мы заключили договор. Исправление ошибок на проекте началось уже на следующий день.

Сначала мы провели аудит проблем и локализовали их до трех крупных блоков:

• сайт падает от нагрузок;
• сайт открыт для атак;
• некому заниматься поддержкой сайта после решения проблем.

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

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

Бэкенд продукта остался на Ruby, но мы обновили его до актуальной версии. База данных — PostgreSQL, Sphinx использовался для полнотекстового поиска по сайту (по рецептам, ингредиентам и так далее), memcached — для кэширования. На каждом этапе работы мы готовили документацию, которая пригодилась бы при поддержке в будущем.

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

Подводим итоги

Выбор между аутсорсом/аутстаффом и наймом собственной команды может стать решающим для цифрового проекта. Допустить ошибку на старте очень легко, а в будущем она может стоить не только денег, но и ставить под вопрос существование бизнеса.

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

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

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