редакции
Когда IT-подрядчики говорят «переписать с нуля» — проверьте их мотивы
Привет! Меня зовут Дмитрий Панькин, я руковожу компанией Resolventa. Уже более 10 лет мы занимаемся сложными IT-продуктами: создаем маркетплейсы, B2B-порталы, корпоративные системы и мобильные приложения.
За годы работы я заметил закономерность: когда владелец бизнеса обращается к подрядчикам с проблемами в существующей системе, в 90% случаев ему предлагают один и тот же «волшебный» рецепт — выбросить все и написать заново. Причем аргументируют это так убедительно, что отказаться просто невозможно.
Но правда в том, что такой подход почти всегда выгоден только самим разработчикам, а бизнес от него страдает. Расскажу, как это работает и что делать, чтобы не попасться на удочку.
Когда система действительно нуждается в серьезном обновлении
Начнем с того, что иногда IT-системы действительно требуют кардинальных изменений. Вот основные сигналы:
Масштабы бизнеса кардинально изменились. Представьте: стартап создавал простой интернет-магазин для продажи самодельных украшений. Система справлялась с десятком заказов в день. Но за пять лет компания выросла в федеральную сеть с тысячами товаров и сотнями заказов в час.
Изначально никто не планировал такого роста, поэтому:
- архитектура не рассчитана на высокие нагрузки
- отсутствуют автоматизированные тесты
- код писался «на коленке» без долгосрочного планирования
В результате система начинает «сыпаться»: тормозит, выдает ошибки, не справляется с объемом данных.
Технологическая база безнадежно устарела. Каждый язык программирования периодически выпускает новые версии. Старые постепенно теряют поддержку — их больше не обновляют, не исправляют уязвимости.
Мы специализируемся на PHP, поэтому приведу пример из нашей области. Если ваша система написана на PHP версии 5.6 или старше — это серьезный повод задуматься об обновлении. Аналогичная ситуация с устаревшими фреймворками: старые версии Symfony, Yii первой версии, CodeIgniter. Система создавалась неопытной командой. Бывает, что на старте у компании просто не было денег на квалифицированных разработчиков. Заказали у тех, кто дешевле. Пока бизнес был маленьким, проблемы не были критичными, но с ростом они превратились в катастрофу. Или другая ситуация: менеджеры ставили нереальные сроки, заставляя программистов работать в аврале. В таких условиях качественный код написать практически невозможно. Теперь представим типичную ситуацию. Руководитель логистической компании «Быстрая доставка» замечает: корпоративная система начала тормозить, нужно добавить мобильную версию, а текущие технологии этого не позволяют. Он обращается в IT-агентство, и там происходит примерно такой диалог: Знакомо? Именно так обычно и происходит. Но почему разработчики так часто предлагают именно полную переделку? Несовпадение технологических стеков. У каждой IT-компании есть своя специализация. Одни работают с PHP, другие с Python, третьи с Java. Если у заказчика другой стек, команда физически не может в него погрузиться — нет нужных специалистов. Поэтому проще предложить переписать все на знакомых технологиях, чем искать разработчиков под конкретный проект. Недостаток экспертизы. Разобраться в чужом коде — задача на порядок сложнее, чем написать новый проект. Требуется глубокий опыт, умение анализировать архитектурные решения, находить узкие места. Если в команде нет сильных сениор-разработчиков, гораздо проще сказать: «Давайте сделаем все заново» — чем браться за сложную модернизацию. Финансовая выгода. Полная переработка системы — это большой проект на много месяцев. Для подрядчика это означает стабильный и крупный заказ. Модернизация ПО обычно идет поэтапно, объемы работ меньше, контролировать процесс сложнее. С точки зрения бизнеса подрядчика полная переделка просто выгоднее. На создание новой системы обычно требуется примерно столько же времени, сколько ушло на разработку первой версии. Если интернет-магазин делали год, то и новый появится не раньше чем через год. Но бизнес не может просто остановиться и ждать. Приходится выбирать между двумя плохими вариантами: Вариант 1: заморозить развитие старой системы. Год или два вы работаете с теми же багами, тем же неудобным интерфейсом, теми же ограничениями. За это время можете потерять клиентов, которых раздражают проблемы с сайтом или приложением. У нас был заказчик с B2B-порталом по продаже подписок. Пока мы разрабатывали новую версию, пользователи продолжали работать со старой. Многих не устраивали постоянные глюки и отсутствие мобильной версии — они просто уходили к конкурентам. Вариант 2: параллельно поддерживать две системы. Нужны две команды разработчиков — одна поддерживает старую систему, другая создает новую. Расходы удваиваются, а управленческая нагрузка возрастает в разы. Плюс высок риск конфликтов: разработчики старой системы понимают, что их проект «хоронят», и могут саботировать взаимодействие с новой командой. По моему опыту, ситуации, когда система не подлежит восстановлению, встречаются крайне редко. Но они все же есть: Нужны специалисты, которые знают устройство конкретной CMS изнутри и умеют переписывать ее ядро. Таких на рынке единицы. Во всех остальных случаях гораздо выгоднее модернизировать существующую систему постепенно, чем создавать новую с нуля. Основные преимущества: Да, модернизация требует более квалифицированных специалистов, что может увеличить стоимость часа разработки. Но общие затраты обычно получаются меньше за счет экономии времени и переиспользования существующего кода. Чтобы принять обоснованное решение, рекомендую провести независимый технический аудит. Опытные специалисты оценят состояние системы, просчитают затраты на оба варианта и дадут объективные рекомендации. Что должен включать качественный аудит: Обновляйте систему своевременно — если видите, что технологии устаревают, бизнес растет быстрее возможностей IT, или прошло больше 5-7 лет с момента создания. Поэтапная модернизация выгоднее в большинстве случаев. Не нужно удваивать расходы, терять клиентов или замораживать развитие бизнеса на годы. Переписывайте с нуля только в крайних случаях — если система на мертвых технологиях (PHP 4.x и старше) или сделана на CMS, которую невозможно кастомизировать. Не доверяйте слепо первому встречному подрядчику. Если вам сразу предлагают все переписать — это повод насторожиться и получить второе мнение. Если сомневаетесь, что делать с вашей системой — давайте разберемся вместе. Честно скажем, стоит ли ее спасать или лучше похоронить.
Откуда берутся «вредные» советы разработчиков
— На чем написана ваша система? — Программисты говорили что-то про PHP и MySQL... — Понятно. Эти технологии уже морально устарели. Предлагаем переписать все на современном Python с использованием микросервисной архитектуры. Получится намного быстрее и надежнее. — А нельзя как-то улучшить то, что есть? — Технически можно, но это будет дороже и менее эффективно. Доверьтесь нашему опыту.
Почему полная переделка — плохая идея для большинства случаев
В каких случаях переписывание действительно оправдано
Почему поэтапная модернизация — оптимальное решение
Как понять, какой путь выбрать
Практические выводы
В Resolventa мы помогаем компаниям принимать обоснованные решения о судьбе их IT-систем с 2012 года. Проводим технические аудиты, модернизируем сложные проекты и — да, иногда переписываем с нуля, но только когда это действительно оправдано.
