Сайт, CRM, внутренний сервис — чаще всего это не разовая сделка, а долгие отношения с подрядчиком. Неудачный выбор оборачивается переделками, срывами сроков и ситуацией «никто не знает, как это устроено». Удачный — предсказуемый результат, понятная поддержка и возможность развивать систему годами. Ниже — на что смотреть при выборе ИТ-партнёра и какие ошибки лучше не повторять.
Почему выбор партнёра важнее «просто сделать проект»
Разработка — это не только код. Это понимание ваших процессов, умение сформулировать требования, вовремя реагировать на изменения и поддерживать то, что уже работает. Через год вам понадобится доработка, обновление или исправление — и вы снова обратитесь к тем, кто делал систему. Если партнёр исчез, не отвечает или не оставил документации, вы остаётесь один на один с «чёрным ящиком». Поэтому критерии выбора должны учитывать не только цену и сроки первого этапа, но и то, как вы будете жить с этим партнёром дальше.
Критерии выбора
Универсальной формулы нет, но есть набор вещей, которые стоит проверить до подписания договора.
| Критерий | На что смотреть |
|---|---|
| Опыт в вашей сфере или типе задач | Похожие проекты в портфолио, понимание вашей отрасли. Иначе много времени уйдёт на вникание, а риски неверных решений выше. |
| Кейсы и контакты | Реальные проекты с описанием задачи и результата. По возможности — отзывы или возможность связаться с заказчиками. Осторожность с «коммерческой тайной» без единого кейса. |
| Коммуникация и процессы | Как ставят задачи, как отчитываются, кто ваш контакт. Хаотичные ответы «когда успеем» и отсутствие статусов — плохой знак для долгосрочной работы. |
| Поддержка после сдачи | Есть ли услуга сопровождения, SLA, как быстро реагируют на срочные проблемы. Проект «сдали и забыли» подходит только если вы уверены, что будете дорабатывать сами или через других. |
| Документация и передача | Кто владеет кодом, где хранятся доступы, есть ли описание архитектуры и как запускать проект. Иначе при смене подрядчика или уходе ключевого человека вы оказываетесь в вакууме. |
Типичные ошибки при выборе
- Ориентация только на цену. Самый дешёвый вариант часто означает упрощения, урезанный функционал или отсутствие нормальной поддержки. Сравнивайте полный цикл: разработка + внедрение + сопровождение на год-два.
- Нет чёткого ТЗ. «Сделайте как у конкурентов» или «нужен хороший сайт» — путь к бесконечным переделкам. Чем яснее техническое задание, тем проще оценить предложение и результат.
- Игнорирование модели поддержки. Сделали проект, а кто будет править баги, обновлять CMS, реагировать на сбои? Если это не обсудили заранее, после сдачи может оказаться, что поддержка не входит или стоит неадекватно дорого.
- Нет проверки репутации. Хотя бы поиск по названию компании и ключевым людям, отзывы на профильных площадках, судебная практика (открытые базы). Иногда за полчаса можно увидеть красные флаги.
Что уточнить до подписания договора
Помимо сроков и суммы стоит зафиксировать:
- Этапы и приёмка. Что считается выполненным на каждом этапе, кто принимает, как фиксируются доработки.
- Права на результат. Код, дизайн, контент — кому принадлежат, можно ли перенести проект к другому подрядчику без юридических рисков.
- Гарантии и ответственность. Срок гарантии на работы, что происходит при срыве сроков или существенных дефектах.
- Поддержка после запуска. Входит ли в проект или оформляется отдельно, SLA на реакцию, стоимость часа доработок.
- Передача знаний и доступов. Документация, репозитории, доступы к хостингу, CMS, домену — когда и в каком виде передаются заказчику.
Если подрядчик уклоняется от чётких ответов на эти пункты или всё «по договорённости» — лучше уточнить до подписания, иначе потом разбираться сложнее.
Когда нужен именно партнёр, а не разовая разработка
Разовая работа (например, лендинг под кампанию) может быть выполнена и без долгосрочных обязательств. Партнёрство имеет смысл, когда:
- Система будет развиваться: новые функции, интеграции, масштабирование
- Критична стабильность: сайт или сервис — лицо компании или канал заявок
- Вы не планируете держать свою ИТ-команду и хотите опереться на внешних специалистов
В таких случаях выбор «сделать и забыть» или подрядчик без модели сопровождения создаёт риски. Подробнее о том, когда бизнесу нужен кастомный подход и серьёзная разработка, — в статье про кастомный и шаблонный сайт.
Красные флаги
Повод насторожиться и задать дополнительные вопросы:
- Нет портфолио или кейсов, всё «под NDA»
- Обещания «сделаем быстрее и дешевле всех» без обоснования
- Не готовы дать контакты прошлых заказчиков для рекомендаций
- Неясно, кто именно будет вести проект и как с ним связаться
- Отказ фиксировать в договоре права на код и передачу документации
- Поддержка «по возможности» или не обсуждается вообще
Когда обращаться в ADES
Мы занимаемся разработкой и сопровождением сайтов и веб-систем: от кастомной разработки до долгосрочной поддержки. Если важны предсказуемые процессы, передача документации и доступов, а также возможность развивать проект после запуска — можно обсудить задачу с нами. Услуги сопровождения включают обновления, мониторинг, доработки и реакцию на инциденты — то, что нужно, чтобы через год не искать «кого-то, кто разберётся в старом коде».
Часто задаваемые вопросы
Как проверить подрядчика, если нет публичных отзывов?
Запросите контакты 2–3 заказчиков из кейсов и свяжитесь с ними. Уточните, как прошёл проект, соблюдались ли сроки, как обстоят дела с поддержкой. Проверьте открытые судебные базы и профили ключевых людей в соцсетях и на профессиональных площадках.
Что важнее — большая компания или маленькая команда?
Зависит от задачи. Крупная компания даёт процессы и ресурсы, но ваш проект может вести джуниор. Небольшая команда часто даёт прямой контакт с теми, кто реально делает, но риски при уходе ключевого человека выше. Важнее не размер, а релевантный опыт, прозрачность и наличие договора с понятными условиями.
Стоит ли платить за аудит или консультацию перед большим проектом?
Если проект сложный или бюджет существенный — да. Небольшая предпроектная работа (аудит текущего состояния, уточнение требований, оценка рисков) помогает и заказчику понять объём, и подрядчику дать адекватную оценку. Это снижает риск «оказалось сложнее» уже в процессе.
Можно ли сменить подрядчика в середине проекта?
Юридически — по условиям договора (расторжение, переход прав). Технически — если есть доступ к коду, документации и окружению, новый подрядчик может подхватить проект. Отсюда важность фиксации прав на результат и передачи артефактов по этапам, а не «всё в конце».
Читайте также
- Техническое задание при создании сайта: почему это важно — как формулировать требования к проекту
- Почему бизнесу нужен кастомный сайт, а не шаблонное решение — когда нужна серьёзная разработка
- Чек-лист: что проверить на сайте в начале года — регулярная проверка и поддержка