Legacy-проекты: правила выживания для интернет-маркетолога

Учим IT-терминологию вместе, или "мы ковырялись в legacy, когда еще не знали, что бывает по-другому"

С самого начала моей карьеры интернет-маркетолога (внезапно:)), я столкнулась с legacy-проектами и почти смирилась с этим. Эти проекты — настоящие хранилища старых технологий и решений, которые часто становятся головной болью для команд. В моей практике было всё: устаревшие библиотеки, проблемы с поисковыми системами, скрытые костыли, блокировки, и даже страшное "эта версия больше не поддерживается". Но, пожалуй, самым сложным было найти нового исполнителя работ для legacy без документации и "хранителя знаний", особенно с ограниченным бюджетом и огромным бэклогом задач.

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

Сейчас я снова иду в такой проект, с гордо поднятой головой, помня про грабли. Хотя новый проект написан с использованием современных технологий, некоторые признаки legacy присутствуют — например, отсутствие документации. Я сформулировала для себя такой список на первое время (*правила выживания в legacy, сформулированные маркетологом):
1. Документация
- Собрать, написать и актуализировать всю доступную информацию.
- Включить сюда описание архитектуры, использования библиотек, ключевых процессов и решений.
2. Узнать, где находятся "костыли"
- Определить места в системе, где использованы временные решения или обходные пути.
- Оценить, насколько они критичны и как можно улучшить или заменить их.
3. Понять архитектуру и технологии
- Исследовать архитектуру системы и используемые технологии.
- Оценить их совместимость с современными решениями.
- Подготовить план модернизации, если это необходимо.
4. Узнать про технический долг
- Оценить текущий уровень технического долга, включая устаревшие библиотеки и инструменты.
- Приоритизировать задачи по его снижению, учитывая их влияние на стабильность и производительность системы.
5. "Косяки" при релизах
- Собрать информацию о проблемах, возникающих при релизах.
- Создать чек-лист для релизов, чтобы минимизировать риски и обеспечить стабильность.

Этот список — мой стартовый план как ПМ, но, кстати, раньше мы уже с вами общались на эту тему - как улучшить зрелый продукт - глазами владельца продукта (ссылка на пост) Какие еще шаги стоит добавить в этот список? Поделитесь своими советами, буду благодарна за рекомендации!

#digital #project #it