Пятница, восемь вечера. Сайт перестал получать цены из 1С: на витрине вчерашние, менеджеры правят карточки товаров руками. Единственный человек, который знает, как это устроено, второй день в отпуске и трубку не берёт. В такие вечера и появляется вопрос: держать программиста в штате или отдавать работу внешней команде.
Однозначного ответа нет. Зато есть несколько вещей, которые можно посчитать и проверить — включая те, где свой сотрудник выигрывает у подрядчика.
Обычный сайт — это пять разных профессий
За корпоративным сайтом с каталогом и обменом данными с 1С стоят как минимум пять непохожих специальностей:
- невидимая часть — расчёт цен и скидок, оформление заказов, права доступа;
- видимая часть — страницы, кнопки, корзина: чтобы не разъезжалось на телефоне и не тормозило там, где у товара сотня фотографий;
- серверы — место, где сайт живёт: обновления, резервные копии, слежение за тем, что он вообще работает;
- связки с другими программами — 1С, CRM, приём оплаты, маркетплейсы;
- проверка перед выпуском, о которой вспоминают, когда клиент уже написал в поддержку.
Это правда разная работа. Человек, который аккуратно пишет расчёт скидок, чаще всего не умеет разбираться, почему ночью захлебнулся сервер. Дело не в уровне, а в специализации.
Размер бизнеса добавляет требований резко, не постепенно. Каталог из трёхсот позиций живёт на любом дешёвом хостинге. А на каталоге в 400 000 товаров и трафике в несколько тысяч человек в сутки вдруг выясняется, что ежедневная выгрузка товаров для маркетплейса роняет сайт, а обновление цен раз в пятнадцать минут означает: четверть часа на витрине висит старая цена — и клиент кладёт товар в корзину по ней.
Один сильный универсал закрывает два-три направления из пяти. Остальные превращаются в «посмотрю на выходных», а потом в накопленные проблемы, о которых знает он один.
Что свой видит лучше, а что хуже
Сначала о сильной стороне, про которую в спорах забывают. Штатный IT-специалист знает бизнес изнутри: почему у этой категории клиентов особые цены, зачем в форме заказа странное поле, которое просил коммерческий директор. Внешнему это придётся объяснять, и часть деталей потеряется по дороге.
Слабая сторона — та же самая близость к проекту. Свой разработчик редко приходит к директору со словами «то, что я собирал три года, больше не тянет, надо переделывать». Дело не в нечестности: человек просто не критикует собственную работу. Спорные решения со временем становятся «так исторически сложилось» и выпадают из обсуждения.
Отсюда вывод: проверять систему стоит у того, кто её не строил. И необязательно у будущего исполнителя — независимому специалисту не нужно продавать вам следующий этап работ.
Пример — тот самый обмен с 1С. Схема, где сайт запрашивает данные у 1С напрямую, живёт до первого долгого обновления в учётной системе: тормозит она — тормозит и сайт, а в сезон это потерянные заказы. Лечится посредником: отдельная программа держит свежую копию цен и остатков и отдаёт её сайту, даже когда 1С недоступна. Решение известное, просто изнутри к нему приходят редко — там борются с симптомом и ускоряют очередной запрос.
Деньги: где проходит граница
Считать надо не оклад, а полную стоимость сотрудника: налоги, отпуск, больничные, техника, время руководителя, месяцы поиска и испытательный срок. И сравнивать с реальным объёмом задач, а не с ощущением, что «работы вроде много».
Час разработки у подрядчика в Москве стоит от 2 000 рублей. Дальше арифметика простая. Если проекту стабильно нужно 120–160 часов в месяц, то есть полная загрузка человека, свой разработчик почти наверняка выйдет дешевле. Если объём плавает — 30 часов в тихий месяц и 150 перед распродажей, — вы платите оклад за простой.
Третий случай самый частый у среднего B2B: работы стабильно немного, но она каждый раз разная. Сегодня правки в каталоге, через месяц переезд на новый сервер, к осени подключение маркетплейса. Нанимать под это пятерых невозможно, а один человек половину задач сделает плохо. Здесь и появляется внешняя команда — абонентская поддержка с фиксированным числом часов или разовые работы по задачам.
Отдельная строка — серверы. Свой системный администратор нужен не каждому, а резервные копии и обновления нужны всем. Держать в штате человека ради дежурства, которое требуется раз в квартал, дорого — и скучно ему самому.
Доступы: риск есть с обеих сторон
«Отдадим данные на сторону» — опасение понятное, но смотрит оно не туда. Проблемы чаще возникают не из-за подрядчика, а из-за того, что доступами не управляет вообще никто:
- пароль от рабочего сервера лежит в переписке трёхлетней давности;
- один общий пароль на всех, кто когда-либо трогал проект;
- у сотрудника, уволившегося год назад, вход в панель управления до сих пор работает;
- никто не знает, есть ли живые резервные копии: их ни разу не восстанавливали.
Внешний исполнитель добавляет свои риски — просто другие. Проверить здесь можно ровно одно: письменный договор с обязательством о неразглашении, отдельный доступ каждому специалисту вместо общего входа и отключение доступов после работ.
Знания о проекте теряются одинаково: и когда уходит свой сотрудник, и когда уходит подрядчик. Спасает только записанное — как устроен сайт, где что лежит, что делать при аварии. Требовать этого стоит от любого исполнителя, включая штатного; порядок приёмки чужого проекта мы разбирали в статье как берут сайт на поддержку.
Кто отвечает, если сайт лёг
Первое отличие — характер ответственности. Штатный сотрудник отвечает по трудовому праву: дисциплинарно (вплоть до увольнения) и материально — но только за прямой действительный ущерб и по общему правилу в пределах среднего месячного заработка. Упущенную выгоду от простоя с него взыскать нельзя, полная материальная ответственность наступает лишь в отдельных случаях, прямо названных в законе. Подрядчик отвечает по договору: неустойка за нарушение сроков реакции, возмещение убытков, а при систематических срывах — расторжение и потеря контракта. Это не «отвечает или не отвечает», а разный масштаб последствий: у сотрудника потолок ответственности установлен законом, у подрядчика — тем, о чём вы договорились.
Отсюда следует главное: договор работает ровно настолько, насколько он конкретен. Строчка «оказание услуг по технической поддержке сайта» без перечня работ, времени реакции на аварию и порядка приёмки не защищает никого — предъявить по ней нечего. И репутация служит аргументом лишь там, где исполнителя можно найти и проверить: у компании с портфолио и отзывами цена ошибки очень высока.
Второе отличие — непрерывность. Заболевший или уволившийся сотрудник уносит с собой то, что было только у него в голове: пароли, логику доработок, историю решений. В команде подрядчика это записано и передаётся — работа не останавливается, а новый человек включается по документации, а не по устным рассказам.
Что из этого следует
Спор «свой или внешний» чаще решается не выбором, а разделением. Свой человек незаменим там, где нужен бизнес-контекст и быстрая реакция: контент, мелкие правки, постановка задач, приёмка работ. Наружу уходит то, что требует узких знаний и случается нерегулярно: серверы, безопасность, связки с другими программами, переделка сайта под возросшую нагрузку.
Прежде чем считать бюджеты, ответьте себе на три вопроса:
- сколько часов проект съедает в спокойный месяц и сколько в пик?
- сколько из пяти направлений закрывает нынешний исполнитель, а какие просто не трогает?
- что будет, если завтра этот человек — свой или внешний — перестанет отвечать?
Ответы обычно и показывают, чего в конструкции не хватает.
