Свой программист или внешняя IT-команда: как выбрать и не переплатить

Пятница, восемь вечера, обмен с 1С встал. Цены на витрине вчерашние, менеджеры правят карточки руками, а единственный человек, который знает, как этот обмен устроен, второй день в отпуске и трубку не берёт. В такие вечера и появляется вопрос: держать разработку внутри или отдавать наружу.

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

Пять специальностей под капотом обычного сайта

Корпоративный сайт с каталогом и обменом с учётной системой требует как минимум пяти разных компетенций. Бэкенд — логика цен, заказов, прав доступа. Фронтенд — интерфейс, который не разваливается на телефоне и не тормозит на карточке с сотней фотографий. Инфраструктура — серверы, деплой, бэкапы, мониторинг. Интеграции — обмен с 1С, CRM, платёжными шлюзами, маркетплейсами. И тестирование, о котором вспоминают, когда клиент уже написал в поддержку.

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

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

Один сильный универсал закрывает два-три направления из пяти. Остальные превращаются в «посмотрю на выходных», а потом в технический долг, о котором знает он один.

Что штатный видит лучше, а что — хуже

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

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

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

Показательный пример из нашей практики — обмен с 1С. Схема, где сайт ходит в учётную систему напрямую, работает ровно до первого затяжного обновления в 1С: витрина тормозит вместе с ней, а в сезон это прямые потерянные заказы. Лечится разделением: обмен выносится в отдельный сервис, который держит у себя актуальный слепок данных и отдаёт его сайту, даже когда 1С недоступна. Мы так сделали на каталоге в 400 000 товаров, и это не наше изобретение — практика известная, просто изнутри к ней приходят редко, потому что там борются с симптомом и ускоряют очередной запрос.

Экономика: где проходит граница

Простое правило: считайте не оклад, а полную стоимость сотрудника — налоги, отпуск, больничные, оборудование, время руководителя на управление, месяцы поиска и испытательный срок. И сравнивайте с реальным объёмом задач, а не с ощущением, что «работы вроде много».

Час разработки у подрядчика в Москве стоит от 2 000 рублей и выше в зависимости от квалификации. Дальше арифметика простая: если проекту стабильно нужно 120–160 часов в месяц, то есть полная загрузка человека, штатный разработчик почти наверняка выйдет дешевле, и держать его внутри разумно. Если объём плавает — тридцать часов в тихий месяц и полторы сотни перед сезонной распродажей, — вы платите оклад за простой.

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

Отдельная строка — серверы. Свой системный администратор нужен не каждой компании, а бэкапы, мониторинг и обновления нужны всем. Это тот случай, когда аутсорс почти безальтернативен: держать в штате человека ради дежурства, которое требуется раз в квартал, дорого и скучно ему самому.

Доступы: риск есть с обеих сторон

«Отдадим данные на сторону» — разумное опасение, но оно смещает фокус. Утечки чаще происходят не из-за подрядчика, а из-за того, что доступами не управляет вообще никто:

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

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

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

Ответственность: договор против трудового

За уроненный прод штатный сотрудник по закону отвечает трудовым договором, то есть практически ничем — максимум неприятным разговором. У компании-подрядчика на кону деньги и репутация: сорванный срок стоит следующего контракта.

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

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

Что из этого следует

Спор «свой или внешний» чаще всего решается не выбором, а разделением. Свой человек внутри незаменим там, где нужен бизнес-контекст и быстрая реакция: контент, мелкие правки, постановка задач, приёмка работ. Наружу уходит то, что требует узкой квалификации и случается нерегулярно, — архитектура под нагрузку, интеграции, серверы, безопасность.

Прежде чем считать бюджеты, ответьте себе на три вопроса. Сколько часов работы проект съедает в спокойный месяц и сколько в пик. Сколько из пяти областей закрывает нынешний исполнитель, а какие просто не трогает. И что произойдёт с проектом, если завтра этот человек — свой или внешний — перестанет отвечать.

Ответы на них обычно и показывают, чего в конструкции не хватает. Это полезнее любого сравнения «аутсорс против штата» в общем виде.