Ошибка в выборе подрядчика на 1С-Битрикс обходится дороже, чем кажется на этапе подписания договора: проблема обнаруживается не сразу, а через несколько месяцев, когда сайт уже запущен, а исправлять архитектурные решения приходится на живом проекте с реальными продажами. Ниже — на что реально стоит смотреть, помимо красивого сайта студии и цены в коммерческом предложении.
1С-Битрикс — гибкая платформа, на которой можно построить и очень качественный, и очень посредственный сайт — разница почти целиком зависит от команды, которая его реализует. Одну и ту же задачу можно решить аккуратно, с продуманной архитектурой каталога и правильно настроенным кэшированием, а можно — набором костылей, которые формально работают в момент сдачи, но превращают любую следующую доработку в дорогостоящий квест. Поэтому вопрос «на какой платформе делать сайт» на практике вторичен по сравнению с вопросом «кто именно будет это делать».
1С-Битрикс присваивает студиям партнёрские статусы за подтверждённую экспертизу и объём успешных проектов — это не гарантия идеального результата, но разумный фильтр на входе: партнёрский статус означает, что компания прошла определённую проверку разработчиком платформы, а не только заявляет о работе с CMS в портфолио. Кроме формального статуса, стоит спросить, сколько лет команда работает именно с 1С-Битрикс (не с вебом вообще, а конкретно с этой платформой) — специфика инфоблоков, модуля «Интернет-магазин» и композитного режима требует накопленного опыта, а не общих знаний PHP.
Красивые скриншоты в портфолио ничего не говорят о качестве кода под капотом. Попросите показать 2–3 реальных проекта, максимально похожих на ваш по масштабу (размер каталога, наличие интеграций с 1С, нагрузка), и задайте конкретные вопросы: как устроен каталог, включён ли композитный режим, как решена интеграция с учётной системой. Если подрядчик может внятно ответить на технические вопросы о собственных проектах — это хороший знак. Уклончивые общие ответы («всё индивидуально», «сложно объяснить не специалисту») — повод насторожиться.
Для проекта с чётко описанным техническим заданием фиксированная стоимость (fixed price) даёт предсказуемость бюджета. Для проектов, где требования заведомо будут уточняться по ходу разработки, честнее модель time & material — оплата по фактически затраченным часам с регулярной отчётностью. Проблема возникает, когда подрядчик называет фиксированную цену на нечётко описанный проект — это почти всегда означает, что цена вырастет на этапе «доработок», которые на самом деле были частью изначальной задачи, просто не зафиксированы в ТЗ.
Хороший договор на разработку фиксирует не только сроки и стоимость, но и: детальный состав работ по этапам (а не общую фразу «разработка сайта»), порядок приёмки и внесения правок, гарантийный период после запуска, в течение которого исправление найденных ошибок бесплатно, и — важный, но часто упускаемый пункт — передачу прав на исходный код и административный доступ к сайту заказчику после оплаты. Без последнего пункта вы рискуете оказаться «привязаны» к одному подрядчику без возможности передать проект другой команде.
Сайт не заканчивается на релизе — нужны обновления модулей безопасности, мониторинг работоспособности, доработки по мере роста бизнеса. Если подрядчик вообще не предлагает вариантов технической поддержки и развития после запуска или уклоняется от разговора об этом — вероятно, для него ваш проект закончится в день сдачи, а дальше вы останетесь с сайтом, в устройстве которого никто, кроме этой команды, толком не разбирается.
Не обязательно разбираться в коде, чтобы отличить компетентную команду от той, что работает по шаблону. Попросите объяснить простыми словами, как будет устроена структура каталога именно для вашего бизнеса, какие модули 1С-Битрикс будут использованы и почему, как организовано резервное копирование и что произойдёт, если сайт станет недоступен в нерабочее время. Внятные, конкретные ответы про ваш конкретный случай — хороший индикатор. Общие фразы про «современные технологии» и «индивидуальный подход» без конкретики — нет.
Часть компаний сознательно разделяет разработку и последующую поддержку между разными подрядчиками, рассчитывая на независимую оценку качества кода. На практике это оправдано не всегда: команда, которая сдала проект и передала его на поддержку другому подрядчику, часто оставляет документацию и комментарии в коде в объёме, достаточном для сдачи, но не для полноценной работы стороннего специалиста дальше. Если вы планируете доверить поддержку той же команде, что разрабатывала сайт — это не хуже и часто даже эффективнее, при условии, что договорные гарантии и условия поддержки прозрачно прописаны заранее.
Если подрядчик спокойно и конкретно отвечает на все эти вопросы — с ним можно предметно обсуждать проект. Мы в TruWeb с 2011 года занимаемся именно разработкой сайтов на 1С-Битрикс и всегда фиксируем состав работ, гарантии и условия передачи проекта в договоре до старта, а после запуска предлагаем техническую поддержку и развитие на понятных условиях — без сюрпризов через полгода после сдачи проекта.