IT-разработка - это искусство, требующее планирования, координации и технической экспертизы. Если заказчик меняет команду, то это происходит по разным причинам: от невыполнения работы до "не сошлись характерами". Одной из сложных ситуаций для новой компании является исправление “нерабочего” проекта.
Команда NooSoft столкнулась именно с этой проблемой.
Логичный вопрос, который всплывает сразу. Но в любой работе не всё идет гладко. И всегда хочется довести начатое до конца, ведь уже потрачено много сил, времени и денег.
История этой статьи связана с проектом, активно работающим уже несколько лет. Скорее он “пытается работать”, ведь итоговый продукт оказался далек от идеала.
Что произошло?
Давайте начнем с фактов. Около 3х лет назад, теперь уже наш клиент заказал разработку портала, чем-то напоминающего “BlaBlaCar”, только для бизнеса.
Система позволяет заказчикам размещать запросы на перевозку, а исполнителям откликаться на них и участвовать в аукционе. Долгий отклик на запрос приводит к снижению стоимости выполнения работы, что стимулирует исполнителей принимать решения быстро и даёт заказчикам выбрать наиболее выгодный вариант.
Одна из особенностей проекта - внутренний документооборот. Система автоматически формирует все необходимые документы: договор и талон заявки, путевой лист, товарно-транспортная накладную, акт сверки. Это обеспечивает юридическую прозрачность и эффективное управление перевозками, что отличает платформу от конкурентов, где такой функционал отсутствует или реализован частично.
Однако, предыдущая команда выпустила в продакшн версию, которая, мягко говоря, была сырой и недоработанной. Пользователи постоянно сталкивались с многочисленными неудобствами и багами. Но никто не исправлял возникающие проблемы, разработчики находили постоянные отговорки: “У нас все работает” или “Починить нельзя”. Баги копились, недовольство росло.
Тогда клиент обратился в NooSoft, чтобы мы “реанимировали” этот проект.
Для понимания, что предстоит исправлять, был проведен аудит и выявлено множество проблем. Напрашивалось одно решение - начать разработку с нуля, но система уже активно используется около полутора лет. Заказчики не согласились с таким кардинальным вариантом, ибо это требовало больших финансовых вложений и поиска новых инвесторов.
Итого мы имеем две причины, почему нельзя просто взять и переделать:
Перед нами стала задача быстро исправить ряд технических и функциональных проблем.
После проведенного аудита команда была в шоке. Как сказал один из наших разработчиков: “Проект можно представить как гигантскую паутину, которая связывается с другой паутиной. В этой паутине не паук создает новый блок, а паутина сама это делает, все настолько автоматизированно”.
И тут мы поняли, что починить проект - это второстепенная задача. Приоритетом стало разобраться, как в принципе он работает. Но в чем загвоздка, спросите вы? Открываете документацию и разбираетесь.
Нас поджидал главный сюрприз - документации нет! Вы пробовали разбирать чужой проект без документации? А ребята из NooSoft теперь в этом профи.
Код представлял из себя настоящую “свалку”, потому что предыдущая команда выбрала определенный паттерн кода, но не стала следовать ему. Однако, хотим отметить, что это не всегда является проблемой квалификации, а, скорее, следствием отсутствия дисциплины и организованности в работе.
Проект страдал от отсутствия четких шаблонов и не имел устойчивого фундамента. Практически весь функционал генерировался динамически, что затрудняло понимание структуры и делало его поддержку и расширение невозможными. Множество зависимостей между компонентами создавало риск поломок при изменениях и замедляло процесс исправлений, вызывая непредсказуемые проблемы.
Мы решили запросить техническое задание, на основе которого создавался проект, но выяснилось, что его тоже не было. Отсутствие прописанного ТЗ создавало еще большую неопределенность и затрудняло понимание требований.
Из-за отсутствия документации наша команда предоставляла клиенту детальные отчеты о проделанной работе. Каждое изменение было описано: что изменялось, как и почему. Эти отчеты стали отправной точкой для формирования документации.
В проекте множество багов и шероховатостей возникало из-за хаотичной логики и неоправданного использования технологий. Например, данные хранились в "local storage", что ограничивало память до 5 МБ, приводя к переполнению и возвращению значения "null". Система вела себя непредсказуемо - открывала данные из других разделов или не выводила на странице ничего, создавая сюрпризы при каждом открытии.
Еще одним вызовом стало то, что вся бизнес-логика была реализована непосредственно в базе данных. Да, это увеличивало скорость работы, но создавало сложности в поддержке и контроле версий.
Проект содержал уязвимости в безопасности, интеграции с сервисами никак не были защищены. Злоумышленники могли получить несанкционированный доступ и повредить данные. Учитывая, что в системе формируются документы, это было особенно критично.
И хотя работу системы можно было поддерживать, доработка и развитие вызывали определенные риски из-за сложной архитектуры и не всегда соответствующих стандартам решений.
Возникшие трудности делали работу над проектом непростой, но нам предстояло разработать стратегию для пошагового устранения проблем и реанимирования системы.
После года активной поддержки, мы поняли, что развитие в текущей форме невозможно. Долгосрочное поддерживание обернулось финансовыми затратами для клиента и выгоранием команды. Мы предприняли следующие шаги, чтобы стабилизировать обстановку:
Совместно с клиентом мы разработали стратегию для решения проблем и начали воплощать ее в жизнь. Несмотря на сложности и объем работ, наша цель оставалась неизменной - построить надежную и современную систему, которая будет служить интересам клиента на протяжении долгого времени.
В процессе работы над проектом, который был абсолютно нерабочим, мы столкнулись с множеством трудностей и вызовов.
Их можно было бы решить быстрее и эффективнее, если бы у проекта была документация!
Если вы работаете над разработкой больших платформ, не забывайте про её создание. Лендинги и небольшие сайты могут обойтись без описаний работы, но не сложные системы.
Около года мы, как слепые котята, пытались найти что и как чинить и исправлять, а проект разваливался на глазах. В результате произошло выгорание у всех причастных к нему, как с нашей стороны, так и со стороны клиента.
Самый главный совет, который даёт команда NooSoft: “Подходите к созданию проекта системно, сосредоточившись на архитектуре, безопасности и документации.”
Проведя такую большую работу, мы не просто “реанимировали” проект, но и проверили собственные процессы разработки и внедрили более эффективные правила, которые исключают возникновение подобных ситуаций в NooSoft.
Мы надеемся, что наш опыт будет полезен, и вы не допустите таких грубых ошибок у себя.