Как выбрать подрядчика на 1С-Битрикс и не ошибиться

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

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

Почему выбор подрядчика — решение на годы

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

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

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

Цена ошибки складывается из трёх частей

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

• Прямые потери. Предоплата, ушедшая исполнителю, который не довёл проект, и деньги на переделку с нуля.
• Потерянное время. Месяцы до запуска, за которые магазин мог бы уже продавать, а конкуренты не стояли на месте.
• Технический долг. Кривой код и «костыли», за которые вы платите потом каждой доработкой, даже сменив команду.

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

С чего начать: поймите, что вам нужно

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

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

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

Типы исполнителей: обзор и сравнение

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

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

Фрилансер: плюсы, минусы, когда оправдан

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

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

Когда фрилансер оправдан:

• Небольшая понятная задача. Доработка, правка, отдельный модуль с чёткими границами.
• У вас есть свой технический контроль. Кто-то на вашей стороне может поставить задачу, проверить код и принять работу.
• Ограниченный бюджет при невысоких рисках. Проект, простой которого не критичен для выручки.

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

Веб-студия: баланс компетенций

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

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

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

Продуктовая команда и аутстафф

Продуктовая команда — это следующий уровень над студией: команда, которая не просто «делает сайт по ТЗ», а ведёт продукт вместе с вами, погружаясь в бизнес-логику и отвечая за результат, а не только за выполненные задачи. Разница тонкая, но важная: студия чаще мыслит проектами (сделали — сдали), продуктовая команда мыслит развитием (запустили — улучшаем на данных). Для крупного магазина или сложного B2B-портала, который живёт и растёт годами, такой подход нередко оказывается выгоднее.

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

Когда стоит смотреть в сторону продуктовой команды или аутстаффа:

• Крупный и долгий проект. Магазин, который развивается постоянно, а не запускается один раз.
• Нужна глубокая экспертиза. Нестандартная бизнес-логика, высокие нагрузки, сложные интеграции.
• Готовность платить за качество и вовлечённость. Такой формат дороже, и это оправданно только на серьёзных задачах.

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

Штатный разработчик или отдел

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

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

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

Компетенции и сертификаты 1С-Битрикс

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

Вендор поддерживает несколько уровней подтверждения компетенций, и их полезно понимать:

• Статус партнёра 1С-Битрикс. Компания официально зарегистрирована как партнёр, прошла обучение и ведёт проекты на платформе. Партнёры имеют доступ к партнёрским ресурсам и обновлениям.
• «Золотой сертификат» партнёра. Повышенный партнёрский статус, который подтверждает объём и качество работы компании на платформе. Это ориентир, что перед вами не случайный исполнитель, а команда с наработанной практикой на Битриксе.
• Сертифицированные разработчики. Конкретные специалисты, сдавшие экзамены вендора по администрированию и разработке. Это подтверждение квалификации не компании в целом, а живых людей, которые будут делать ваш проект.
• Компетенции по направлениям. У партнёров бывают отметки о специализации — например, на интернет-магазинах или на крупных проектах. Релевантная вашему проекту компетенция ценнее «универсальной».

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

Портфолио и релевантные кейсы

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

Что делает кейс релевантным вашему:

• Похожий масштаб каталога. Магазин на сто товаров и магазин на сто тысяч — разные по инженерным задачам. Ищите проекты вашего порядка.
• Тот же тип магазина. Розница, средний магазин или B2B-портал — у каждого своя логика. B2B-опыт особенно важен, если у вас цены по группам, личные кабинеты и документооборот.
• Совпадающие интеграции. Был ли обмен с 1С, связка с CRM, подключение оплаты и доставки — то есть решал ли подрядчик те же задачи, что предстоят вам.
• Близкая ниша. Не обязательна, но полезна: опыт в вашей отрасли означает понимание её специфики (маркировка, сложные единицы измерения, особенности логистики).

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

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

Как проверить репутацию подрядчика

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

1. Статус партнёра у вендора. Найдите компанию в официальном реестре партнёров 1С-Битрикс — это подтверждает и статус, и срок работы на платформе.
2. Юридическое лицо и возраст компании. Реальное ли ООО или ИП стоит за брендом, как давно работает, нет ли тревожных признаков. Долгая история на рынке — сама по себе аргумент.
3. Отзывы на независимых площадках. Не только те, что подобраны на сайте студии, а отзывы на сторонних ресурсах и в профессиональных сообществах.
4. Кейсы и живые проекты. Работают ли сайты из портфолио, можно ли соотнести их с реальными брендами.
5. Контакты клиентов. Попросите рекомендации и поговорите с реальными заказчиками — это самый ценный источник.
6. Присутствие команды. Публикации, доклады, статьи, участие в профессиональной жизни — признак, что за брендом стоят живые специалисты, а не только отдел продаж.

Что должно настораживать при проверке репутации: полное отсутствие следов в сети (компания как будто возникла вчера), только идеально-восторженные отзывы без единого нейтрального (живая практика так не выглядит), нежелание называть реальные проекты и клиентов, а также расхождение между тем, что говорят на встрече, и тем, что удаётся проверить. Ни один из этих признаков сам по себе не приговор, но каждый — повод копнуть глубже, а не закрывать глаза ради красивой презентации.

Процессы: ТЗ, оценка, спринты

То, как подрядчик организует работу, важнее обаяния менеджера и даже отдельных строчек портфолио. Выстроенные процессы — это то, что превращает «талантливых людей» в предсказуемый результат. Компания с сильными процессами доводит проект до конца в срок даже на сложной задаче; компания без процессов способна провалить простую. Поэтому на этапе выбора стоит разобраться, как именно подрядчик работает.

Ключевые элементы здорового процесса разработки на Битриксе:

• Работа от ТЗ. Хороший подрядчик начинает не с кода, а с фиксации требований. Либо помогает вам составить ТЗ, либо превращает ваш бриф в понятный обеим сторонам документ. Разработка «на словах» — источник конфликтов.
• Внятная оценка. Оценка разбита на задачи с трудозатратами, а не выдана одной цифрой «под ключ». Детализация показывает, что подрядчик действительно продумал объём.
• Итеративность (спринты). Работа идёт короткими циклами с промежуточными результатами, которые можно посмотреть и скорректировать, а не «уходит в тишину на три месяца, а в конце покажем».
• Демонстрации. Регулярный показ того, что уже сделано, — вы видите прогресс своими глазами и вовремя ловите расхождения с ожиданиями.
• Управление изменениями. Понятный порядок, как оформляются новые хотелки и правки объёма, чтобы они не превращались в бесконечные споры «а я думал, это входит».

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

Коммуникация и отчётность

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

Признаки здоровой коммуникации:

• Единый канал и понятные правила. Есть выделенный менеджер или руководитель проекта, понятно, где ведётся переписка и в какие сроки отвечают.
• Регулярная отчётность. Вы получаете обновления о прогрессе по договорённому ритму, а не выпрашиваете статус.
• Прозрачность по задачам. Видно, что в работе, что сделано, что впереди, — например, через доступ к трекеру задач.
• Честность про проблемы. Подрядчик сообщает о сложностях и срывах заранее, а не в последний момент. Умение признавать проблему — признак зрелой команды.

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

Тестирование и контроль качества

Тестирование — этап, который слабые подрядчики режут первым, потому что заказчик его не видит и не понимает, за что платит. А между тем именно QA отделяет магазин, который надёжно принимает заказы, от магазина, где покупатель на полпути к оплате натыкается на ошибку и уходит к конкуренту. В e-commerce каждый баг в корзине или оформлении заказа — это напрямую потерянные деньги, поэтому отношение подрядчика к тестированию — важный критерий выбора.

О чём спросить и на что смотреть:

• Тестирование как отдельный этап. QA заложено в план и смету явной строкой или «предполагается само собой»? Второе обычно означает, что его толком не будет.
• Что именно тестируют. Функционал (корзина, оформление, оплата, обмен с 1С), адаптивность на разных устройствах, кроссбраузерность, нагрузка на пиках.
• Приёмочное тестирование. Как устроена приёмка на вашей стороне, есть ли понятные критерии, по которым работа считается сделанной.
• Гарантийные правки. Что происходит с ошибками, которые всплывают после запуска, в течение гарантийного периода.

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

Договор: этапы, сроки, гарантия, ответственность

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

Что обязательно должно быть в договоре на разработку магазина:

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

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

Права на код и доступ к Git с первого дня

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

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

Доступ к Git с первого дня — практический вопрос: видите ли вы код по мере его написания. Здоровая практика — разработка ведётся в репозитории (Git), к которому у вас есть доступ с самого начала, а не «покажем в конце». Это даёт сразу несколько выгод:

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

Передача проекта и защита от вендор-лока

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

Что должно быть у вас на руках, чтобы вы не оказались в ловушке:

• Доступ ко всем ресурсам. Хостинг, домен, лицензия 1С-Битрикс, репозиторий, панели управления — всё оформлено на вас или доступно вам, а не только подрядчику.
• Актуальный код в вашем репозитории. Не «последняя версия у нас», а полный доступный вам код в любой момент.
• Документация. Хотя бы базовое описание архитектуры, интеграций и нестандартных решений, чтобы новая команда могла разобраться.
• Прописанный порядок передачи. Договор описывает, как и в какие сроки передаются код, доступы и документация при завершении сотрудничества.

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

Поддержка после запуска

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

Что выяснить про поддержку заранее:

• Форматы поддержки. Разовые работы по часам, абонемент с пулом часов в месяц или выделенная команда — что предлагает подрядчик и что подходит вам.
• Скорость реакции (SLA). За какое время реагируют на обращение, особенно на критичные проблемы вроде «магазин не принимает заказы».
• Что входит. Обновления платформы и безопасности, мониторинг, резервные копии, мелкие правки, развитие функционала.
• Прозрачность учёта. Как считаются и как отчитываются потраченные на поддержку часы.

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

Как читать смету подрядчика

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

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

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

Красные флаги и хорошие знаки

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

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

Вопросы на первой встрече

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

1. Есть ли у вас опыт с магазинами нашего масштаба и ниши? Ждём конкретные кейсы, а не «да, конечно, делали всякое».
2. Кто именно будет работать над проектом? Ждём понятные роли и команду, а не «наши лучшие специалисты».
3. Как вы оцениваете проект и ведёте работу? Ждём описание процесса по этапам, а не «сделаем и покажем».
4. Будет ли у нас доступ к коду и Git с самого начала? Ждём «да, конечно», а не уклончивость.
5. Как устроено тестирование? Ждём QA как отдельный этап, а не «мы и так проверяем».
6. Что в договоре по срокам, гарантии и правам на код? Ждём готовность всё это прописать.
7. Как передаёте проект, если мы решим сменить команду? Ждём спокойное объяснение, а не напряжение.
8. Как устроена поддержка после запуска? Ждём понятные форматы и условия.
9. Можете дать контакты клиентов для отзыва? Ждём готовность, а не отговорки.

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

Частые ошибки заказчика

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

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

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

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

1. Определили задачу. Понимаете масштаб, тип проекта, горизонт и свои ресурсы; есть хотя бы черновое ТЗ или бриф.
2. Выбрали тип исполнителя. Фрилансер, студия, команда или штат — под вашу задачу, а не «как получилось».
3. Проверили компетенции. Статус партнёра и сертификаты сверены на официальном сайте 1С-Битрикс.
4. Изучили портфолио на релевантность. Есть проекты вашего масштаба, типа и с похожими интеграциями; сайты живые.
5. Проверили репутацию. Юрлицо, срок работы, независимые отзывы, контакты клиентов.
6. Разобрались в процессах. Работа от ТЗ, внятная оценка, спринты, демонстрации.
7. Оценили коммуникацию. Отвечают быстро и по существу, есть отчётность и прозрачность.
8. Уточнили про тестирование. QA — отдельный этап, а не «само собой».
9. Прочитали договор. Этапы, сроки, гарантия, ответственность, оплата по этапам.
10. Зафиксировали права на код и доступ к Git. Доступ с первого дня, права переходят к вам, порядок передачи прописан.
11. Обсудили поддержку. Форматы, скорость реакции, что входит.
12. Прочитали смету по строкам. Детализация, состав интеграций, наполнение, резерв — а не одна цифра.
13. Проверили на красные флаги. Нет доступа к коду, «за неделю», 100% предоплата, нет договора, нет QA — отсутствуют.

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

Вывод

Выбрать подрядчика на 1С-Битрикс и не ошибиться — значит сместить фокус с цены на то, что действительно определяет успех проекта: компетенции, процессы и договорные гарантии. Начните с честного ответа на вопрос, что вам нужно, — от этого зависит тип исполнителя. Проверьте компетенции и сертификаты у первоисточника, изучите портфолио на релевантность, а не на красоту, поговорите с реальными клиентами. Разберитесь, как подрядчик работает: от ТЗ и оценки через спринты и тестирование к запуску и поддержке.

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