Блог
Как не надо делать проект
Разработка IT-проекта - это тонкое искусство, где каждый элемент требует внимания, планирования и технической грамотности. Однако, как в любом искусстве, есть и свои темные стороны. В новой статье приоткроем тайну, как не следует делать IT-проекты. Мы расскажем реальную историю и подскажем, как избежать ошибок. Добро пожаловать в мир уроков из неудач и важных наставлений по созданию проектов!
avatar user
Кондратенко Сергей
CIO
31 января 2024 г.
#Разработка
#Логистика

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

Команда NooSoft столкнулась именно с этой проблемой.

Почему просто не начать с нуля?

Почему просто не начать с нуля?
Почему просто не начать с нуля?

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

История этой статьи связана с проектом, активно работающим уже несколько лет. Скорее он “пытается работать”, ведь итоговый продукт оказался далек от идеала.

Что произошло?

Давайте начнем с фактов. Около 3х лет назад, теперь уже наш клиент заказал разработку портала, чем-то напоминающего “BlaBlaCar”, только для бизнеса.


 

Рабочий стол портала
Рабочий стол портала

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

Информация о заказе
Информация о заказе

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

Документооборот внутри портала
Документооборот внутри портала

Однако, предыдущая команда выпустила в продакшн версию, которая, мягко говоря, была сырой и недоработанной. Пользователи постоянно сталкивались с многочисленными неудобствами и багами. Но никто не исправлял возникающие проблемы, разработчики находили постоянные отговорки: “У нас все работает” или “Починить нельзя”. Баги копились, недовольство росло.

Постоянные ошибки системы
Постоянные ошибки системы

Тогда клиент обратился в NooSoft, чтобы мы “реанимировали” этот проект.

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

Итого мы имеем две причины, почему нельзя просто взять и переделать:

  1. Активное использование платформы. Если отключаем “неработающую” часть, то деньги теряют все: и заказчик, и пользователи.
  2. Нужны инвесторы, чтобы привлечь дополнительные средства на новую разработку.

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

Какие проблемы нас поджидали?

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

И тут мы поняли, что починить проект - это второстепенная задача. Приоритетом стало разобраться, как в принципе он работает. Но в чем загвоздка, спросите вы? Открываете документацию и разбираетесь.

Нас поджидал главный сюрприз - документации нет! Вы пробовали разбирать чужой проект без документации? А ребята из NooSoft теперь в этом профи.

Код представлял из себя настоящую “свалку”, потому что предыдущая команда выбрала определенный паттерн кода, но не стала следовать ему. Однако, хотим отметить, что это не всегда является проблемой квалификации, а, скорее, следствием отсутствия дисциплины и организованности в работе.

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

Когда делаешь проект без плана
Когда делаешь проект без плана

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

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

В проекте множество багов и шероховатостей возникало из-за хаотичной логики и неоправданного использования технологий. Например, данные хранились в "local storage", что ограничивало память до 5 МБ, приводя к переполнению и возвращению значения "null". Система вела себя непредсказуемо - открывала данные из других разделов или не выводила на странице ничего, создавая сюрпризы при каждом открытии.

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

База данных проекта
База данных проекта

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

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

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

Как в итоге решали проблемы проекта?

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

  1. Провели тщательный анализ текущего состояния проекта и предложили несколько вариантов решения проблем:
    - сделать множество экземпляров приложения для распределения данных между ними;
    - переписать фронтенд и доработать под него бэкенд;
    - переписать всё с нуля.
  2. С учетом сложности и ограничений существующей системы, клиент согласился с нашим предложением переписать большую часть проекта. Это позволит избежать накопления ошибок, устранить проблемы и сэкономить бюджеты на поддержку. Ведь выгоднее отдавать на плановое ТО новый автомобиль, чем не вылезать из автосервиса на старой машине.
  3. Мы разработали детальную дорожную карту, определив этапы и сроки выполнения проекта. Клиент получил четкий план действий и смог понимать, как будут решаться текущие проблемы.
  4. Создание документации и тестирование стали ключевыми этапами для обеспечения качества проекта, включая подробное описание его структуры, функционала и процессов работы.
  5. Провели аудит безопасности и внедрили меры защиты данных. Для предотвращения несанкционированного доступа были укреплены интеграции с приложениями.
  6. Оптимизировали производительность системы, учитывая огромное количество данных и интеграцию с DaData. Это позволило системе работать более эффективно и масштабироваться.
  7. Внедрили новые процессы разработки, включая использование современных инструментов управления проектом и систем контроля версий.

Совместно с клиентом мы разработали стратегию для решения проблем и  начали воплощать ее в жизнь. Несмотря на сложности и объем работ, наша цель оставалась неизменной - построить надежную и современную систему, которая будет служить интересам клиента на протяжении долгого времени.

Рекомендация от разработчиков NooSoft

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

Их можно было бы решить быстрее и эффективнее, если бы у проекта была документация!

Если вы работаете над разработкой больших платформ, не забывайте про её создание. Лендинги и небольшие сайты могут обойтись без описаний работы, но не сложные системы.


 

Следовать правилам или забить?
Следовать правилам или забить?

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

Самый главный совет, который даёт команда NooSoft: “Подходите к созданию проекта системно, сосредоточившись на архитектуре, безопасности и документации.” 

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

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

Читайте также
Контакты
свяжитесь с нами, мы это любим!
Скачать презентацию