Аутсорс или свой отдел разработки для магазина

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

Эта статья — не про то, что «аутсорс всегда лучше» или «свой отдел надёжнее». Обе крайности ошибочны. Мы разберём три модели поддержки и развития магазина на Битрикс по трём осям — стоимость, скорость, риски — и покажем, при каком объёме и этапе бизнеса какая модель выигрывает. Материал — выжимка из практики поддержки и сопровождения магазинов на 1С-Битрикс, где мы видим обе стороны: и как компании набирают штат, и как приходят к нам, когда штат не взлетел.

Задача, а не мода: что вы на самом деле выбираете

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

Чтобы решение было осознанным, полезно сначала честно описать свою ситуацию по нескольким параметрам. Сколько часов доработок вам реально нужно в месяц и насколько ровно они распределены? Насколько задачи предсказуемы или это поток срочных «горит»? Какие компетенции требуются — только верстка и правки контента или интеграции с 1С, платёжными системами, оптимизация под нагрузку? Насколько для бизнеса критичны простои сайта? Есть ли у вас кому ставить задачи разработчику и принимать работу? Ответы на эти вопросы почти всегда сами подсказывают модель — до того, как вы начнёте считать деньги.

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

Три модели поддержки и развития магазина

На практике вариантов не два, а как минимум три — и именно третий, гибридный, чаще всего оказывается рабочим для магазинов среднего размера. Разберём каждый.

• Свой отдел (in-house). Разработчики, а иногда и тимлид с тестировщиком, в штате компании. Максимальная вовлечённость и знание бизнеса, мгновенный доступ, но постоянные издержки вне зависимости от загрузки и ответственность за найм, удержание и рост людей.
• Аутсорс (студия или подрядчик). Разработку ведёт внешняя команда по договору. Вы платите за результат или за оговорённые часы, не несёте кадровых издержек и получаете доступ к разным компетенциям, но погружение в ваш проект и вовлечённость нужно выстраивать через процессы и SLA.
• Гибрид. Штатный продакт-оунер или техлид держит контекст, приоритеты и приёмку, а объём разработки закрывает аутсорс-команда. Узкие компетенции (интеграции, highload, безопасность) берутся у подрядчика точечно. Сочетает вовлечённость штата с масштабируемостью аутсорса.

Есть и промежуточные формы: фрилансер на подряде (по сути «аутсорс из одного человека» со всеми рисками), выделенная команда подрядчика под ваш проект (dedicated team — почти как свой отдел, но без кадровой нагрузки), staff augmentation (усиление вашей команды внешними разработчиками). Но если убрать нюансы, все они укладываются в спектр между «полностью свои» и «полностью внешние», и логика выбора одинаковая.

Стоимость: сравниваем честно, с полными издержками

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

Полная стоимость штатного разработчика складывается не только из оклада. К нему добавляются:

• Налоги и взносы с фонда оплаты труда — это заметная надбавка сверх оклада «на руки».
• Оплачиваемый простой. Разработчик получает зарплату и в те недели, когда критичных задач нет. На неровном потоке это прямой убыток.
• Отпуска и больничные. Оплачиваются, но работа в это время не идёт, а срочное «горит» некому подхватить.
• Рабочее место и инфраструктура: техника, лицензии на софт, оборудованное место, административная нагрузка на бухгалтерию и кадры.
• Наём и удержание: стоимость подбора, адаптации, обучения, риск текучести и повторного найма.
• Управление. Разработчику нужно ставить задачи, ревьюить код, растить его — это время руководителя или отдельная роль тимлида.

Подрядчик в своей ставке уже учитывает налоги, простой между проектами, отпуска своих сотрудников, инфраструктуру и управление командой. Поэтому корректно сравнивать полную месячную стоимость штата (оклад со всеми накрутками плюс доля издержек на управление) с реальным чеком подрядчика за тот же объём закрытых задач. И тут решает загрузка: если задач хватает, чтобы штатный разработчик был занят по-настоящему полный месяц из месяца в месяц, штат может стать дешевле в пересчёте на час. Если же реальная потребность — условные 30–50 часов разработки в месяц, вы платите полную зарплату за неполную загрузку, и аутсорс почти всегда выгоднее.

Отдельно стоит помнить про скрытую стоимость незакрытых компетенций. Один штатный универсал не закроет одновременно верстку, backend на Битрикс, интеграцию с 1С, платёжные системы и оптимизацию под нагрузку на экспертном уровне. Либо вы нанимаете несколько специалистов (и стоимость штата резко растёт), либо всё равно докупаете узкие компетенции на стороне. У подрядчика с командой эти роли уже собраны, и вы платите за них только когда они реально нужны.

Скорость и реакция на задачи

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

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

Аутсорс в первый период проигрывает в контексте: новой команде нужно погрузиться в проект, разобраться в доработках предыдущих подрядчиков, изучить структуру. Зато у студии есть запас рук: пиковую нагрузку можно распараллелить, а на время отпуска одного специалиста подключить другого. Ключевой инструмент скорости здесь — SLA (соглашение об уровне сервиса) с зафиксированным временем реакции и решения по категориям задач. Хороший подрядчик гарантирует, что критичная авария будет взята в работу в оговорённый срок, — и это надёжнее устного «сделаю сегодня» от загруженного штатного разработчика.

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

Риски: bus-фактор, вендор-лок, знания

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

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

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

Потеря знаний. Каждая доработка магазина — это накопленный контекст: почему сделали так, какие есть подводные камни, как связаны обмен с 1С, оплата и склад. Если этот контекст живёт только в голове исполнителя, любая смена людей обнуляет его, и новая команда наступает на старые грабли. Риск потери знаний одинаков для штата и аутсорса и снимается одинаково — документацией, код-ревью и понятной структурой проекта.

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

Сравнительная таблица моделей

Сведём три модели в одну таблицу по ключевым параметрам. Это не «оценки», а характер поведения модели — чтобы приложить к своей ситуации.

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

Компетенции: чего требует именно Битрикс

Магазин на 1С-Битрикс — это не «просто сайт», и набор компетенций для его поддержки шире, чем кажется на старте. Именно широта требований часто становится аргументом в пользу аутсорса или гибрида: собрать всё это в одном штатном человеке практически невозможно.

• Ядро и API Битрикса: инфоблоки, торговый каталог, D7-компоненты, события ядра, агенты, работа с composite и управляемым кэшем. Это база, но её мало.
• Обмен с 1С: настройка и отладка обмена товарами, ценами, остатками и заказами, разбор ошибок выгрузки — отдельная и капризная область.
• Интеграции: платёжные системы, службы доставки, CRM, системы аналитики. Каждая со своими протоколами и краевыми случаями.
• Производительность: оптимизация каталога и фильтра под нагрузку, настройка кэширования, работа с медленными запросами к базе.
• Безопасность и обновления: своевременная установка обновлений платформы, закрытие уязвимостей, настройка проактивной защиты, бэкапы.
• Frontend и UX: вёрстка, адаптив, работа над конверсией карточки и оформления заказа.

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

Гибрид: штат + аутсорс как рабочая норма

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

Типичное разделение ролей в гибриде выглядит так:

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

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

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

Когда пора заводить свой отдел

Свой отдел — не признак зрелости, а инструмент под конкретные условия. Он оправдан, когда сходится несколько факторов сразу:

1. Стабильно высокий объём. Поток задач уверенно и надолго загружает нескольких разработчиков на полный день. Не «иногда много», а ровно и постоянно.
2. Разработка — часть продукта, а не обслуживание. Ваш сайт или платформа — конкурентное преимущество, и скорость развития напрямую влияет на выручку. Тогда контроль и вовлечённость команды окупаются.
3. Есть кому управлять. В компании есть техлид или сильный продакт, который выстроит процессы, наймёт и вырастит людей. Без этой роли отдел превращается в дорогой хаос.
4. Критична конфиденциальность и контроль. Есть причины держать разработку строго внутри — чувствительные данные, специфические требования безопасности.
5. Готовность к кадровой работе. Компания принимает, что найм, адаптация, удержание и рост разработчиков — это постоянная работа, а не разовое действие.

Если хотя бы половина этих условий не выполняется, свой отдел, скорее всего, будет дороже и рискованнее аутсорса или гибрида. Особенно опасен сценарий «наняли одного разработчика, чтобы был свой» — он даёт иллюзию контроля при худшем bus-факторе и узком наборе компетенций.

Когда аутсорс — правильный выбор

Аутсорс — это не «пока не выросли до своей команды», а полноценная модель, оптимальная в широком диапазоне ситуаций. Он особенно уместен, когда:

• Объём задач неровный или умеренный. Вам не нужна постоянная полная загрузка разработчика — платить за факт выгоднее.
• Нужны разные компетенции по требованию. Сегодня интеграция с 1С, завтра оптимизация каталога, послезавтра платёжка — команда подрядчика закрывает всё это без раздувания штата.
• Разработка — обслуживающая функция. Сайт важен, но не является ядром продукта; вам нужен стабильный результат, а не собственная R&D-команда.
• Нет ресурса на кадровую работу. Вы не хотите или не можете заниматься наймом, удержанием и ростом разработчиков.
• Нужна предсказуемость по SLA. Договор с зафиксированным временем реакции и объёмом надёжнее устных договорённостей с одним человеком.

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

Реализация в 1С-Битрикс: как устроить работу

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

1. Разделите окружения. Заведите как минимум prod (боевой) и dev/stage (тестовый) контуры. Правки на Битриксе никогда не выкатываются сразу в бой — сначала на тестовом сайте с копией данных. Это снимает половину рисков независимо от того, кто разработчик.
2. Держите код в Git. Кастомные компоненты, шаблоны, обработчики событий и правки ядра (через local/ и события, а не хаки в bitrix/) должны лежать в вашем репозитории. Это снимает вендор-лок и делает смену подрядчика штатной операцией.
3. Настройте деплой. Выкладка изменений — через понятный процесс (миграции, деплой из репозитория), а не ручной правкой файлов на боевом сервере по FTP. Так любой новый разработчик поймёт, как обновляется сайт.
4. Внедрите трекер задач. Все задачи, баги и доработки живут в одном месте (таск-трекер) с историей. Это и есть значительная часть документации проекта — по нему видно, что и зачем делали.
5. Зафиксируйте регламент обновлений и бэкапов. Обновления платформы, проверка безопасности и резервные копии идут по расписанию, а не «когда вспомним». Кто именно это делает — штат или подрядчик — вопрос модели, но сам регламент обязателен.
6. Опишите архитектуру. Держите короткий актуальный документ: где что лежит, как настроен обмен с 1С, какие есть интеграции и нестандартные решения. Это спасает контекст при любой смене людей.

Ключевая мысль: этот контур принадлежит вам, а не исполнителю. Лицензия Битрикс, хостинг, домен, репозиторий, доступы, трекер — на вашей стороне. Тогда любая модель работает безопасно, а переход между моделями (например, от аутсорса к гибриду) не превращается в переезд с потерями.

Как безопасно передать проект и не зависеть

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

• Все доступы у вас. Лицензия Битрикс, панель хостинга, SSH, база данных, административный доступ к сайту, DNS домена — оформлены на вашу компанию, а исполнителю выданы отдельные учётные записи, которые можно отозвать.
• Код в вашем репозитории. Не «пришлём архив по запросу», а постоянно актуальный Git, к которому у вас есть доступ. Смена команды — это смена того, кто в него коммитит.
• Документация и трекер. История задач, описание архитектуры и нестандартных решений позволяют новой команде войти в проект за дни, а не недели.
• Порядок передачи в договоре. Пропишите обязанность передать дела, доступы и документацию при завершении сотрудничества и разумный срок сопровождения на переходный период.
• Отсутствие «тайных знаний». Требуйте, чтобы решения не жили только в голове одного человека: код-ревью, парная работа, комментарии в коде и трекере.

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

Частые ошибки при выборе модели

• Сравнивают оклад штатного разработчика с чеком подрядчика напрямую, забывая про налоги, простой, отпуска и управление — и делают вывод в пользу штата на неверных цифрах.
• Нанимают одного разработчика «чтобы был свой» и получают bus-фактор, равный единице, и узкий набор компетенций вместо надёжности.
• Считают, что свой отдел безопаснее по умолчанию, — тогда как безопасность даёт команда и документация, а не форма найма.
• Отдают проект на аутсорс, но оставляют доступы, лицензию и код у подрядчика — и попадают в вендор-лок, из которого дорого выходить.
• Не фиксируют SLA ни со штатом, ни с подрядчиком и полагаются на устное «всегда на связи», которое рушится на первом отпуске.
• Держат знания о проекте в голове одного человека без документации — и теряют контекст при любой смене исполнителя.
• Выбирают модель один раз и цепляются за неё, когда бизнес уже вырос: держат раздутый штат при спаде задач или мучаются с аутсорсом, когда пора завести продакта.
• Экономят на продакте/техлиде в гибриде — берут только руки на аутсорсе без того, кто ставит задачи, и получают разработку без направления.

Чек-лист выбора и внедрения

Сведём решение к практическому списку. Пройдите его сверху вниз — и модель проявится почти сама собой.

1. Оцените объём. Зафиксируйте стабильную месячную потребность в часах разработки и её ровность. Это главная входная цифра.
2. Посчитайте полную стоимость. Для штата — оклад со всеми накрутками, простоем и управлением; для аутсорса — реальный чек за тот же объём. Сравнивайте сопоставимое.
3. Определите нужные компетенции. Выпишите, что реально требуется: ядро, обмен с 1С, интеграции, оптимизация, безопасность. Оцените, закроет ли их один человек.
4. Проверьте риски. Каков bus-фактор в каждом варианте? Как защищены от вендор-лока и потери знаний? Есть ли SLA?
5. Решите про управление. Есть ли у вас кому ставить задачи и принимать работу? Если нет — это первый найм независимо от модели.
6. Выстройте контур. Доступы, лицензия, репозиторий, окружения, трекер, регламенты — всё на вашей стороне до начала работ.
7. Зафиксируйте договорённости. SLA, порядок передачи проекта, документирование — в договоре или регламенте, а не на словах.
8. Заложите пересмотр. Раз в полгода-год сверяйте выбранную модель с реальным объёмом и этапом бизнеса и корректируйте.

Вывод

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