Каждый третий проект, который приходит к нам на поддержку, — это проект, который предыдущий подрядчик не довёл до конца или довёл так, что проще переписать. Почти всегда проблемы можно было увидеть на этапе выбора. Вот что стоит спросить.
12 вопросов подрядчику
1. Кто конкретно будет работать над проектом? Попросите познакомить с командой, а не с продажником. Если в штате 5 человек, а проектов 20 — работать будут фрилансеры.
2. Покажите похожий проект и дайте контакт заказчика. Кейсы на сайте — это картинки. Разговор с реальным клиентом — правда.
3. Как проходит discovery-этап? Если подрядчик готов назвать цену без погружения в задачу, он назовёт её наугад и потом «уточнит».
4. Как часто я буду видеть результат? Правильный ответ — каждые 1–2 недели рабочее демо. Неправильный — «покажем через три месяца».
5. Кому принадлежат исходники и когда я их получу? Только вам и после каждого этапа. Не в конце проекта и не «после полной оплаты».
6. Что входит в стоимость, а что нет? Тестирование, документация, деплой, обучение, гарантийные исправления — всё это должно быть в смете, а не всплыть потом.
7. Что произойдёт, если сроки сорвутся? Штрафы, компенсации, план действий. Если ответ «у нас не срываются» — это красный флаг.
8. Какой стек и почему? Ответ должен опираться на вашу задачу, а не на то, что умеет команда. Экзотический стек — риск не найти разработчиков потом.
9. Как организовано тестирование? Автотесты, ручное QA, нагрузочное. «Разработчики сами проверяют» — плохой ответ.
10. Как выглядит поддержка после запуска? SLA, время реакции, стоимость часа доработок.
11. Как вы работаете с изменениями требований? Они будут. Нужен понятный процесс оценки и согласования, а не «это не входило в ТЗ».
12. Что будет, если мы захотим сменить подрядчика? Документация, передача доступов, помощь в переходе. Компания, которая не боится этого вопроса, уверена в себе.
Красные флаги
- Цена в 2–3 раза ниже рынка. Кто-то заплатит разницу — скорее всего, вы, позже.
- Отказ показать команду или дать контакты клиентов.
- Оценка «под ключ» без вопросов о задаче.
- Договор без приложения с составом работ и критериями приёмки.
- Хостинг и домен оформлены на подрядчика.
- «Мы работаем без ТЗ, по agile» как оправдание отсутствия плана.
Что проверить в договоре
- Состав работ и критерии приёмки каждого этапа.
- Передача исключительных прав на код и дизайн.
- Сроки и ответственность за их нарушение.
- Порядок изменения объёма работ и его стоимости.
- Гарантийный срок и что в него входит.
- Конфиденциальность и порядок работы с персональными данными.
Фрилансер, студия или продуктовая команда
Фрилансер — для лендинга или небольшого сайта с понятным ТЗ. Риск — исчезновение и отсутствие замены.
Студия — для корпоративных сайтов и типовых магазинов. Отлаженный процесс, но часто конвейер и слабая инженерия.
Продуктовая команда — для сложных продуктов, интеграций, highload, приложений. Дороже, но результат живёт годами и его можно развивать.
Итог
Хороший подрядчик задаёт больше вопросов, чем вы, показывает результат каждые две недели, отдаёт исходники сразу и не боится вопроса о расставании. Всё остальное — детали.
Мы в OSNOVEL готовы ответить на все 12 вопросов на первой встрече. Проверьте нас →