Разработчикам лень работать: как компании выворачивают карманы за пересоздание своей ИТ-системы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— Окей…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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