Как принимать работу у подрядчика по этапам, если вы не программист

Коротко. Этап разработки принимают по сценариям, которые записаны до его начала, и на своих данных. Демонстрация подрядчика показывает, что система работает на его примерах, и для приёмки этого мало. Замечания делят на блокирующие и остальные: только первые мешают подписать акт, вторые уходят в следующий этап. Принимать должен человек, который потом будет работать с системой. По нашим проектам это 20–30% его рабочего времени на весь срок разработки.

Ниже порядок, который помогает принять этап за несколько дней и без технических знаний.

Сценарии записывают до начала этапа

Перед стартом этапа заказчик и подрядчик записывают, что должно работать в конце. Записывают действиями: «менеджер находит клиента по ИНН, видит его заказы за год, создаёт новый заказ с тремя позициями, заказ появляется в 1С». Таких сценариев на этап обычно 5–15.

Сценарии нужны обеим сторонам. Подрядчик знает, что именно будут проверять. Заказчик не придумывает требования в момент приёмки, когда менять что-то уже дорого.

Проверка на своих данных

Подрядчик показывает систему на тестовых данных, которые сам и создал. На них всё работает. Ошибки появляются на ваших данных: длинные названия, клиент с двумя юрлицами, товар без артикула, заказ на тысячу строк.

Поэтому для приёмки нужна копия ваших реальных данных или хотя бы выборка из них. Если в данных есть персональные, подойдёт обезличенная копия. Попросите подрядчика заранее, чтобы к приёмке тестовый сервер был заполнен.

Что проверять кроме экранов

Ошибки ввода. Что будет, если оставить поле пустым, ввести буквы вместо цифр, нажать кнопку дважды. Система должна объяснить, что не так, и не создать два заказа.

Права. Зайдите под разными ролями. Менеджер не должен видеть чужих клиентов, если так договаривались.

Обмен с другими системами. Если этап включает интеграцию, проверьте, что данные дошли и в другую сторону: заказ появился в 1С, статус вернулся обратно.

Старое после нового. Работает ли то, что приняли на прошлом этапе. Новый код иногда ломает старый, и это видно только если проверить.

Код и документация. Если в договоре передача кода по этапам, убедитесь, что код этого этапа лежит в вашем репозитории. Это проверяется за пять минут, даже без программиста: дата последних изменений видна в интерфейсе.

Замечания с приоритетами

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

• блокирующее: сценарий не проходит, данные теряются или искажаются;
• важное: сценарий проходит, но с обходным путём или неудобно;
• пожелание: работает как договорились, но хочется иначе.

Акт не подписывают, пока есть блокирующие замечания. Важные исправляют в рамках этапа или переносят в следующий с записью в протоколе. Пожелания оценивают отдельно как изменение объёма.

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

Кто принимает

Принимать должен человек, который будет работать с системой каждый день. Руководитель или ИТ-отдел видят, что система запускается, но не заметят, что менеджеру нужно шесть кликов там, где раньше было два.

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

Частые вопросы

Сколько дней нужно на приёмку этапа? При готовых сценариях и заполненном тестовом сервере обычно хватает трёх-пяти рабочих дней. Если сценарии придумываются на ходу, дольше.

Что делать, если подрядчик спорит с приоритетом замечания? Вернуться к записанному сценарию. Если сценарий не проходит, замечание блокирующее. Если сценария не было, это пожелание, и его оценивают отдельно.

Нужен ли нам свой тестировщик? Для большинства проектов нет: хватает сотрудника, который знает процесс, и записанных сценариев. Тестирование внутри этапа делает подрядчик, и это стоит проверить в смете.

Правило

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