Как принимать разработку: чек-лист приёмки IT-проекта из 30 пунктов

Как принимать разработку — тема, которая определяет успех IT-проекта. Подрядчик показал финальное демо. Всё работает, кнопки нажимаются, дизайн совпадает с макетом. Вы подписываете акт приёмки — а через две недели начинается: сайт падает под нагрузкой в 50 пользователей, форма обратной связи теряет заявки, а в коде обнаруживается SQL-инъекция, через которую можно слить всю базу клиентов.

Знакомый сценарий? По нашему опыту работы с 50+ проектами, около 60% заказчиков принимают разработку «на глаз» — проверяют только визуальную часть и несколько основных сценариев. В результате стоимость поддержки и доработок после запуска оказывается в 2-3 раза выше, чем если бы проблемы нашли на этапе приёмки. В контексте как принимать разработку выделяется несколько ключевых факторов.

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

Чек-лист приёмки IT-проекта: 6 категорий и 30 пунктов

• Функциональность (8 пунктов) — все сценарии из ТЗ работают, формы валидируют, письма доставляются
• Качество кода (6 пунктов) — Git-репозиторий с историей, автотесты, нет секретов в коде
• Безопасность (5 пунктов) — HTTPS, защита от SQL-инъекций и XSS, хэширование паролей
• Производительность (4 пункта) — загрузка менее 3 секунд, выдерживает 100 одновременных пользователей
• Документация (4 пункта) — README, API-документация (Swagger), инструкция по деплою
• Инфраструктура (3 пункта) — автобэкапы, мониторинг, staging-среда

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

При выборе как принимать разработку это определяет итоговый результат.

Категория	Кол-во пунктов	Что проверяет	Риск без проверки
Функциональность	8	Работает ли всё по ТЗ	Баги в продакшене, потеря клиентов
Качество кода	6	Поддерживаемость и масштабируемость	Технический долг, невозможность доработок
Безопасность	5	Защита от взлома и утечек	Утечка данных, штрафы, репутационный ущерб
Производительность	4	Скорость и стабильность под нагрузкой	Сайт падает при росте аудитории
Документация	4	Возможность сменить подрядчика	Vendor lock-in, зависимость от одной команды
Инфраструктура	3	Готовность к эксплуатации	Потеря данных, простой сервиса

Теперь разберём каждую категорию детально. Для каждого пункта указана критичность: блокирующий (без него не принимайте), важный (исправить до запуска) или желательный (можно добавить после).

Категория 1: Функциональность — 8 пунктов

Самая понятная категория. Здесь вы проверяете, что продукт делает то, что было описано в техническом задании. Однако даже опытные заказчики часто упускают пограничные сценарии.

Вопрос как принимать разработку здесь приобретает практическое значение.

Пункты 1-4: основные сценарии

1. Все страницы/экраны из ТЗ существуют и открываются (блокирующий). Пройдите по каждому разделу. Если в ТЗ 15 экранов — откройте все 15. Нередко подрядчик «забывает» про страницу настроек или профиля.
2. Основные пользовательские сценарии проходят от начала до конца (блокирующий). Регистрация, авторизация, оформление заказа, оплата — проверьте полный путь пользователя, а не отдельные кнопки.
3. Формы валидируют ввод и показывают понятные ошибки (важный). Введите в поле телефона буквы, в email — цифры, оставьте обязательные поля пустыми. Некорректные данные не должны попадать в базу.
4. Уведомления и письма отправляются и доставляются (важный). Зарегистрируйтесь с реальным email, оформите тестовый заказ. Проверьте, что письма не попадают в спам и содержат правильные данные.

Пункты 5-8: пограничные сценарии

5. Работа с пустыми состояниями (важный). Что видит новый пользователь, у которого нет заказов, товаров в корзине, сообщений? Пустая белая страница — плохо. Заглушка с подсказкой — правильно.
6. Корректная работа при медленном интернете (желательный). Включите режим Slow 3G в DevTools браузера. Страницы должны загружаться (пусть и медленно), а не зависать навечно.
7. Адаптивность под мобильные устройства (блокирующий). Откройте сайт на телефоне. Все элементы должны быть кликабельны, текст читаем без зума, формы удобны для заполнения.
8. Кроссбраузерность (важный). Проверьте в Chrome, Firefox и Safari. Особенно Safari — он чаще других рендерит CSS по-своему.

Совет из практики: попросите 3-5 знакомых (не разработчиков) выполнить основные сценарии без инструкций. Если они застрянут — значит, пользователь тоже застрянет. Это самый дешёвый и эффективный способ найти UX-проблемы до запуска.

Категория 2: Качество кода — 6 пунктов

Эту категорию заказчик обычно не может проверить самостоятельно. Поэтому мы рекомендуем нанять независимого эксперта на 2-4 часа (10-20 тысяч рублей). Вот что он должен проверить.

Грамотный подход к как принимать разработку экономит бюджет и сроки.

9. Код хранится в Git-репозитории с историей коммитов (блокирующий). Без версионного контроля вы получаете «чёрный ящик». У вас должен быть доступ к репозиторию с первого дня разработки — это стандартная практика, описанная в нашем гайде по договору с подрядчиком.
10. Есть автоматические тесты (unit и integration) (важный). Минимальный порог — покрытие тестами критических бизнес-сценариев. Спросите подрядчика: «Какой процент покрытия тестами?» Ниже 40% — это повод для разговора.
11. Код проходит линтер без ошибок (желательный). Линтер — автоматический инструмент, который проверяет стиль и типичные ошибки. Если линтер выдаёт сотни предупреждений — значит, команда не следила за качеством.
12. Нет захардкоженных паролей, ключей API и секретов (блокирующий). Пароли от базы данных, ключи от платёжных систем, токены API не должны быть в коде. Для этого существуют переменные окружения (.env-файлы). Утечка секретов — прямой путь к взлому.
13. Архитектура разделена на слои (важный). Бизнес-логика отделена от интерфейса, база данных — от API. Без этого любое изменение в одном месте ломает три других. Спросите эксперта: «Можно ли заменить базу данных, не переписывая фронтенд?»
14. Нет дублирования кода (DRY-принцип) (желательный). Если одна и та же логика скопирована в 5 местах — при исправлении бага нужно менять все 5. А про два из них забудут.

Результаты code review оформляйте в протокол приёмки с конкретными замечаниями. Подробнее о том, как организовать заказную разработку с системным контролем качества, мы разбирали в отдельной статье.

Категория 3: Безопасность — 5 пунктов

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

Именно как принимать разработку влияет на успех на этом этапе.

15. SSL-сертификат установлен, все страницы работают по HTTPS (блокирующий). Откройте сайт — в адресной строке должен быть замочек. Без HTTPS браузеры помечают сайт как «небезопасный», а поисковики понижают в выдаче.
16. Защита от SQL-инъекций и XSS (блокирующий). Попробуйте ввести в поле поиска: <script>alert('test')</script>. Если появилось всплывающее окно — у вас XSS-уязвимость. Для полной проверки нужен специалист по безопасности.
17. Пароли хранятся в хэшированном виде (блокирующий). Спросите подрядчика: «Как хранятся пароли пользователей?» Правильный ответ — bcrypt, argon2 или аналогичный алгоритм хэширования. Если пароли хранятся в открытом виде — это критическая уязвимость.
18. Настроены заголовки безопасности (важный). Content-Security-Policy, X-Frame-Options, X-Content-Type-Options — набор HTTP-заголовков, которые защищают от типовых атак. Проверить можно бесплатно на securityheaders.com.
19. Есть разграничение прав доступа (важный). Обычный пользователь не должен видеть админ-панель. Проверьте: можно ли через URL попасть на страницы, к которым у вас нет доступа? Измените ID в адресной строке — увидите ли чужие данные?

Важный нюанс: полный аудит безопасности (пентест) стоит от 100 000 рублей и для MVP избыточен. Тем не менее 5 пунктов выше — это бесплатный минимум, который закрывает 80% типовых уязвимостей. Не пренебрегайте им.

Категория 4: Производительность — 4 пункта

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

При выборе как принимать разработку это определяет итоговый результат.

20. Время загрузки главной страницы < 3 секунд (блокирующий). Измерьте через Google PageSpeed Insights. Оценка мобильной версии должна быть выше 50 баллов, десктопной — выше 70. Каждая секунда задержки снижает конверсию на 7%.
21. Проведено нагрузочное тестирование (важный). Попросите подрядчика показать результаты нагрузочного теста: сколько одновременных пользователей выдерживает система, какое время отклика при пиковой нагрузке. Для MVP минимум — 100 одновременных пользователей без деградации.
22. Запросы к базе данных оптимизированы (важный). Спросите: «Есть ли медленные SQL-запросы (slow queries)?» Если API-ответ приходит дольше 500 мс — значит, есть проблема. Неоптимизированная база данных — бомба замедленного действия.
23. Статика отдаётся через CDN или кэш (желательный). Изображения, CSS, JavaScript должны кэшироваться браузером и (в идеале) раздаваться через CDN. Без этого каждый посетитель грузит все файлы заново, что увеличивает нагрузку на сервер.

Категория 5: Документация — 4 пункта

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

24. README с инструкцией по запуску проекта (блокирующий). Новый разработчик должен запустить проект на своей машине за 30 минут, следуя README. Если для запуска нужны «тайные знания» — документация неполная.
25. API-документация (Swagger/OpenAPI) (важный). Если в проекте есть API — должна быть интерактивная документация, где можно увидеть все эндпоинты, параметры и примеры запросов. Стандарт — Swagger UI.
26. Описание архитектуры и ключевых решений (важный). Почему выбрали PostgreSQL, а не MongoDB? Почему микросервисы, а не монолит? Эти решения нужно зафиксировать, иначе следующая команда будет гадать — и может принять неправильные решения.
27. Инструкция по деплою (блокирующий). Как выкатить новую версию на сервер? В идеале — это одна команда или автоматический CI/CD-пайплайн. Если деплой требует 15 ручных шагов — это проблема, которую нужно решить до приёмки.

Категория 6: Инфраструктура — 3 пункта

Последняя, но критически важная категория. Инфраструктура определяет, выживет ли ваш продукт в продакшене. Три пункта — и все три блокирующие.

28. Настроены автоматические бэкапы базы данных (блокирующий). Ежедневные бэкапы с хранением минимум 7 дней. Проверьте: попросите подрядчика восстановить вчерашний бэкап на тестовом сервере. Если не может — бэкапов нет или они не работают.
29. Настроен мониторинг и алертинг (блокирующий). Вы должны узнавать о падении сервера раньше, чем клиенты. Минимум — уведомление в Telegram или email при недоступности сайта. Проще всего — бесплатный UptimeRobot.
30. Есть staging-среда для тестирования (важный). Staging — копия продакшена, где можно тестировать изменения без риска сломать рабочий сайт. Без staging каждое обновление — русская рулетка.

Таблица критичности: какие баги блокируют приёмку

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

Уровень	Название	Описание	Действие	Примеры
S1	Блокирующий	Невозможно использовать продукт	Не подписывать акт	Сайт не открывается, оплата не проходит, данные теряются
S2	Критический	Основной сценарий нарушен	Исправить до запуска	Регистрация ломается на мобильном, поиск не работает, формы не отправляются
S3	Важный	Второстепенная функция не работает	Исправить в течение 1 недели	Фильтр сбрасывается, уведомления не приходят, PDF-отчёт генерируется с ошибкой
S4	Незначительный	Косметический дефект	Исправить в гарантийный период	Опечатка, неровные отступы, кнопка на 2 пикселя не по макету

Правило приёмки: акт подписывается, если нет ни одного бага S1, не более 2 багов S2 (с обязательством исправить в течение 3 рабочих дней), и все баги S3-S4 зафиксированы в протоколе. Это конкретные acceptance criteria, которые стоит прописать в договоре с подрядчиком ещё до начала разработки.

Шаблон протокола приёмки: как оформить результаты проверки

Протокол приёмки — юридический документ. Устные замечания подрядчик может «забыть», а протокол — нет. Вот структура, которую мы рекомендуем использовать при приёмке проектов разработки MVP.

Структура протокола

1. Общая информация: дата проверки, номер договора, перечень проверяющих
2. Перечень проверенных модулей: список функциональных блоков из ТЗ с отметкой «принят / не принят»
3. Таблица замечаний: для каждого бага — ID, описание, шаги воспроизведения, уровень критичности (S1-S4), скриншот
4. Сроки исправления: S1 — до подписания акта, S2 — 3 рабочих дня, S3 — 1 неделя, S4 — гарантийный период
5. Решение: принято / принято с замечаниями / отклонено
6. Подписи: заказчик и подрядчик

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

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

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

Стандартные гарантийные условия

Параметр	Минимум рынка	Prime IT
Гарантийный период	2 недели	2 недели
SLA на критические баги (S1-S2)	1 рабочий день	4 часа
SLA на прочие баги (S3-S4)	3-5 рабочих дней	1 рабочий день
Что входит	Исправление багов	Баги + консультации по эксплуатации
Что НЕ входит	Новая функциональность	Новая функциональность, изменение ТЗ

Три условия, которые нужно зафиксировать

1. Определение «бага» — отклонение от согласованного ТЗ и acceptance criteria. Без чёткого определения подрядчик может классифицировать ваш баг как «новую фичу» и выставить счёт.
2. Канал коммуникации — куда сообщать о багах (таск-трекер, email, Telegram). Устные сообщения не фиксируются. В идеале — Jira или аналог с отслеживанием статуса.
3. Последствия нарушения SLA — если подрядчик не исправляет критический баг в течение SLA, вы вправе привлечь другого специалиста за счёт подрядчика. Прописывается в договоре.

Итог: 5 правил системной приёмки

Вот главное, что нужно помнить, когда будете принимать разработку в следующий раз:

1. Не подписывайте акт в день демо. Возьмите 3-5 рабочих дней на проверку по чек-листу из 30 пунктов.
2. Наймите независимого эксперта для проверки кода и безопасности. 10-20 тысяч рублей на code review — это страховка от сотен тысяч на переделках.
3. Используйте таблицу критичности S1-S4. Не все баги равны — отделите блокирующие от косметических.
4. Оформите протокол приёмки. Устные замечания забываются. Подписанный документ — юридическое основание для требования исправлений.
5. Проверьте гарантийные условия до начала приёмки, а не после. Гарантия должна быть в договоре, с конкретными SLA и определением «бага».

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

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