Заказать разработку или сделать всё самим?

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

На первый план выходят скорость, безопасность, опыт и способность сопровождать систему 24/7.

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

Сам решу-у-у. Или нет?

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

А если речь о крупной компании, то сразу мысль: неужели не могли сделать сами? Так вот, отвечаю: могли, но не стали. И вот по каким причинам.

Разношёрстные инструменты

Чаще всего к нам приходят компании, у которых внутри лежит целый пул разных систем. У бухгалтерии — одна база, у закупок — другая, у клиентов — третья. Где-то ведут в Excel, где-то в самописных модулях. И вроде всё работает, но собрать воедино сложно.

А мы такие задачи решали не раз и даже не два. Например, когда работали с одной компанией, то столкнулись с проблемой: у них было 11 разных баз данных. Часть в Excel, часть в старых системах, очень много дублей данных и ошибок. Цифровизация промышленности: текущая ситуация и перспективы, крупнейшие ИТ-поставщики. Обзор TAdviser 57.7 т Всё это нужно было почистить, причесать, свести в одну платформу и настроить работу так, чтобы данные обновлялись в реальном времени.

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

Прозрачность процессов

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

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

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

𝓲

Фото: VESNA

Нехватка внутренних ресурсов

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

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

И если вдруг что-то пойдёт не так, заказчика не бросят с проблемой один на один.

Безопасность и ответственность

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

По итогу все процессы происходят на серверах подрядчика. Он берёт на себя мониторинг, защиту и быстрое реагирование, если что-то пошло не по плану. А заказчик просто знает, что работа идёт. А всё остальное — не его зона ответственности.

Согласование требований

Самое сложное — состыковаться в понимании задачи. Если договариваться только словами, то заказчик часто соглашается: «Да-да, всё так, делаем».

И вот мы делаем, выкатываем в прод и слышим: «Так, стоп, мы же по-другому договаривались…». Когда-то мы обжигались из-за этого, поэтому теперь жёстко документируем все вводные и условия. Это защищает нас как от бесполезной работы, так и от возможных недопониманий.

Сопротивление изменениям

Люди не любят менять привычки. Особенно те привычки, которым 15–20 лет. Бухгалтерия привыкла работать в Excel, а руководство — ставить подписи руками. И ни в какую не хотят переучиваться на цифровые аналоги.

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

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

Несовпадение ожиданий

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

А иногда ожидания могут упираться в деньги. Небольшие компании приходят с запросом: «Сделайте биллинг за 200 тысяч рублей». А объективная стоимость проекта — от 15 миллионов. И мы бы и рады помочь, но чисто физически не сможем.

Чек-лист: стоит ли делать самим?

Я собрала несколько первостепенных вопросов. Если ответов «нет» больше половины — скорее всего, выгоднее заказать:

1. Есть ли у вас команда BA/QA/Dev/DevOps с опытом госинтеграций?
2. Готовы ли вы поддерживать процессы 24/7 и проходить проверки по ПДн?
3. Все ли процессы задокументированы и масштабируемы?
4. Есть ли экспертиза по Госуслугам, ГИС ЖКХ, СМЭВ?
5. У вас развит инцидент-менеджмент?
6. TCO in-house ниже, чем TCO заказной разработки?
   
   

Подытожу, In-house разработка работает, когда процессы зрелые, есть команда, бюджет и время.

А заказная выигрывает там, где важны скорость, безопасность, госинтеграции и тиражирование.

И иногда лучше всего прийти к гибридному формату: что-то оставить на локальном контроле, а что-то — отдать подрядчику. Например, нам, командам VESNA. Особенно, если продукт сложный и интересный — мы такое любим и точно не подведём.