Приёмка проекта у большинства заказчиков выглядит одинаково. Разработчик присылает ссылку и пишет «готово». Заказчик открывает сайт или систему, минут двадцать нажимает на кнопки, находит пару опечаток, радуется, что главная страница выглядит как на макете, и подписывает акт. Через месяц выясняется, что при ста одновременных пользователях всё падает, что отчёт для бухгалтерии считает НДС неправильно, что в коде нет ни одного теста, а новый подрядчик, которого позвали на доработку, говорит: «Это проще переписать». Деньги уже заплачены, акт подписан, и разговор с первым исполнителем становится очень неловким.
Я много лет нахожусь по обе стороны этого процесса: и сдаю проекты, и принимаю чужие по просьбе клиентов. И могу сказать, что приёмка это не «потыкать в кнопки». Это последний момент, когда у Вас есть рычаг. После подписи акта рычага нет.
Приёмка как техосмотр, а не тест-драйв
Когда Вы покупаете подержанный автомобиль, тест-драйв говорит Вам очень мало. Машина заводится, едет, музыка играет, кондиционер дует. Всё, что действительно важно, находится под капотом и под днищем: состояние двигателя, ржавчина, следы ремонта после аварии. Поэтому разумные люди везут машину на станцию техосмотра, где механик поднимает её на подъёмник и смотрит туда, куда покупатель сам не заглянет.
Программная система устроена так же. Интерфейс это кузов и салон. Он может быть безупречным, а под ним может лежать архитектура, которая не выдержит роста, база данных без индексов, пароли в открытом виде и код, который не понимает даже его автор. Тест-драйв (щёлкнуть по экранам) нужен, но его недостаточно. Нужен ещё и техосмотр.
Три уровня проверки
Я делю приёмку на три уровня, и каждый отвечает на свой вопрос.
Первый уровень: приёмочные тесты, или UAT (User Acceptance Testing). Вопрос: делает ли система то, что было обещано? Здесь Вы берёте техническое задание и проходите сценарии один за другим. Не «посмотреть, как выглядит заказ», а «создать заказ на три позиции со скидкой, оплатить частично, вернуть одну позицию, проверить остаток на складе и сумму в отчёте». Хорошие сценарии пишутся заранее, ещё на этапе ТЗ, и тогда приёмка превращается в чек-лист, а не в импровизацию. Если сценариев в ТЗ нет, у меня для Вас плохая новость: принимать не по чему, и спор будет о вкусах.
Второй уровень: код-ревью. Вопрос: можно ли эту систему поддерживать и развивать? Здесь нужен внешний эксперт, не тот, кто писал код. Он смотрит на структуру проекта, на качество кода, на наличие тестов, на документацию, на безопасность. Он не будет придираться к стилю, если всё остальное в порядке, но он сразу увидит, если вся бизнес-логика живёт в одном файле на десять тысяч строк. Это стоит денег, но несравнимо меньше, чем переписывание через год.
Третий уровень: нагрузочное тестирование и проверка отказоустойчивости. Вопрос: выдержит ли система реальную жизнь? Двадцать пользователей на демо и тысяча в понедельник утром это разные системы. Нагрузочный тест имитирует реальный трафик и показывает, где узкое место. Сюда же относится проверка резервного копирования: не «бэкапы настроены», а «мы восстановили систему из бэкапа на чистом сервере, и она заработала».
Где теряются деньги
Бюджет на приёмке теряется не из-за злого умысла исполнителя, а из-за размытых договорённостей. Самые частые случаи из моей практики такие.
- Нет критериев готовности. Если в договоре написано «разработать модуль продаж», то любой модуль продаж формально готов. Критерии нужно фиксировать сценариями и цифрами: время отклика, количество пользователей, список отчётов.
- Оплата вперёд за всё. Поэтапная оплата с приёмкой каждого этапа даёт Вам рычаг на протяжении всего проекта, а не только в конце.
- Код и доступы у исполнителя. Если репозиторий, сервер и домен зарегистрированы на подрядчика, Вы принимаете не систему, а обещание.
- Гарантийный период не оговорён. Баги будут, это нормально (я подробно писал об этом в отдельной статье). Важно, чтобы было записано, кто и в какой срок исправляет ошибки, найденные после приёмки.
Акт приёмки это не благодарность исполнителю. Это документ, после которого Ваши претензии становятся просьбами.
Как принимать проект завтра
Если проект уже на финише, а Вы не закладывали ничего из перечисленного, не паникуйте. Сделайте минимум. Попросите у исполнителя список сценариев, по которым он сам проверял систему, и пройдите их лично. Добавьте к ним пять сценариев из Вашей реальной работы, особенно тех, где участвуют деньги. Убедитесь, что код лежит в Вашем репозитории и Вы можете войти на сервер. Закажите независимое код-ревью хотя бы на пару дней работы эксперта. И подписывайте акт только после того, как исправлено всё, что останавливает деньги, а остальное зафиксировано отдельным списком со сроками.
Мы в Ingello проводим такой аудит и для чужих проектов, и, честно говоря, это одна из самых полезных услуг, которые мы делаем: часто два дня проверки экономят клиенту месяцы будущих проблем. А в своих проектах мы закладываем приёмочные сценарии ещё на этапе проектирования, чтобы в конце не было сюрпризов ни у клиента, ни у нас. Принимайте с умом, коллеги, и пусть под капотом будет так же красиво, как в салоне.
