Привет! Меня зовут Дмитрий Панькин, я основатель компании Resolventa. Мы создаем сложные ИТ-продукты для клиентов: сайты маркетплейсов, B2B-порталы, личные кабинеты, приложения, кастомные CRM- и ERP-системы.

Когда компания хочет обновить свою ИТ-систему, ее ждет куча вредных советов от программистов: удалить, выкинуть, написать заново на другом языке. Этот подход в 99% выгоден только самим разработчикам, бизнесы из-за него разоряются. А теперь подробнее.

Почти ни одна ИТ-система не может работать вечно только на одной техподдержке — ни интернет-магазин, ни CRM-система, ни личный кабинет. Вот почему сервису рано или поздно потребуется полное обновление или замена.

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

• не используют автоматизированные тесты;
• не строят устойчивую архитектуру;
• не проводят перекрестное код-ревью;
• не следят за чистотой кода.

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

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

Мы в Resolventa используем PHP, поэтому в статье будем говорить именно о нем. Например, мы настоятельно рекомендуем обновить сервис, если версия PHP ниже, чем 7.0. То же касается устаревших фреймворков, например: Yii, CodeIgniter, CakePHP, Symfony 2.0.

Чтобы понять, поддерживается ли версия языка, которую вы используете, загляните в список релизов на официальном сайте. В случае с PHP нужно зайти на php.net, а для фреймворка Symfony — на symfony.com.

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

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

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

Итак, если что-то из перечисленного выше про ваш сервис, значит, его нужно обновить.

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

С вероятностью 90% в агентстве состоится следующий диалог:

— На каком стеке сейчас написан ваш сервис?

— Разработчики говорят, что на PHP…

— Отсюда и проблемы. Давайте напишем всё с нуля на современном Node.js. Это позволит использовать единый язык JavaScript, чтобы писать код как на стороне клиента, так и на сервере. В итоге получится намного быстрее, а разработчикам на фронтенде и бэкенде будет проще сотрудничать друг с другом.

— А точно нет никакого способа сохранить то, что есть?

— Это будет вам самим невыгодно. Поверьте нашему опыту.

— Окей…

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

Объясню, почему вообще программисты дают такие советы.

У каждой компании свой технологический стек: одно агентство специализируется на PHP, другое — на Python, третье — на Node.js. Если у заказчика другой стек, разработчики просто не могут погрузиться в его проект, потому что у команды нет специалистов, которые работают на этом языке программирования.

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

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

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

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

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

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

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

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

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

Используемые технологии безнадежно устарели. Проект придется создавать заново, если технологии не просто морально устарели, а умерли. Так бывает, если версия языка, на котором написан ваш сервис, уже давно не поддерживается. Например, когда продукт написан на PHP 5.0, который устарел еще в 2008 году.

↑ Если код вашего сервиса выглядит так — модернизировать его не стоит. Лучше похоронить и писать с нуля

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

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

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

Если руководство выбирает тактику поэтапной модернизации, можно будет расширять и наращивать эффективность бизнеса параллельно с воссозданием ИТ-системы. Не придется ставить процессы на паузу на пару лет, пока пишется новая программная платформа для компании.

Руководству бизнеса может показаться, что модернизировать сервис дороже, чем разработать заново. Это не всегда так. На окончательную цену влияют несколько факторов. Рассмотрим сначала те, что повышают цену поэтапного восстановления:

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

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

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

Но есть моменты, которые снижают цену работ по модернизации:

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

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

• Обновляйте сервис, если бизнес сильно вырос или изменился, технологии морально устарели или, например, прошло 10 лет с последней модернизации.
• Поэтапно модернизировать проект — самое выгодное решение для компании в большинстве случаев. Так вам не придется удваивать расходы, терять прибыль и клиентов, а также замораживать рост бизнеса.
• Переписывайте сервис с нуля, если он сделан на PHP 5.0 и более ранних версиях или написан с помощью CMS. В этих случаях модернизировать сервис будет сложнее, чем писать заново, — а значит, это займет много часов у программистов и обойдется чересчур дорого.

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

Пишите в личку — разберем проблему и назначим дату консультации по вашему ИТ-проекту.