Приёмка сайта или портала по этапам: какие документы подписывают и что в них пишут

Корпоративный сайт, клиентский портал, личный кабинет или интернет-магазин почти никогда не сдают одним куском: проект делят на этапы, и каждый закрывают документом. В одном сценарии стороны смотрят результат, сверяют его со списком, составленным до начала этапа, и подписывают. В другом заказчику присылают акт «работы по этапу выполнены в полном объёме», и он подписывает: отказаться значит остановить проект и сдвинуть дату запуска.

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

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

Заказчики часто думают, что документ в проекте один — акт. Их несколько, и половина проблем от того, что части из них нет. Акт отвечает на вопрос «принято ли», но не говорит, что именно принималось и по какому признаку: за это отвечают приложения, и обычно отсутствуют именно они.

Сразу оговорка: ниже — общая практика проектов, где приёмка работает, а не регламент нашей студии и не то, что мы обязуемся подписывать. У разных подрядчиков документы называются иначе, часть объединена в один файл, часть вшита в договор. Смотреть нужно не на название, а на то, есть ли у этапа записанные заранее проверки и след от каждого изменения.

В такой практике документ с критериями подписывается до начала этапа, а не вместе с актом в день сдачи. Приложение, появившееся вместе с актом, написано под готовый результат и доказывает лишь его существование.

Критерий проверяем, если у него есть три части: кто проверяет, что делает и какой однозначный результат считается успехом. «Дизайн соответствует фирменному стилю» этих частей не имеет: можно только согласиться или нет. «Все типы страниц из утверждённой карты имеют макет в десктопной и мобильной версиях» проверит человек без дизайнерского образования за полчаса.

Второе требование — чтобы критерий измерял работу, а не её украшения. Пункт «использована утверждённая шрифтовая пара» не доказывает ничего: это вечер работы. И третье: критерий должен быть выполним в день приёмки силами вашей стороны. Проверка, требующая доступа, которого у вас нет, превращается в демонстрацию, а демонстрация приёмкой не является: показывают всегда то, что работает.

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

Как выглядит содержательный результат, видно по сайту логистической компании TagLex: пять офисов в России и агентская сеть более чем в полусотне стран. Структуру собрали из четырёх блоков — услуги, география, кейсы, компания, — а услуги описали не перечнем видов транспорта, а задачами клиента. Каждая стала отдельной страницей с описанием, сроками, документами и формой запроса на расчёт.

Из такого описания критерии выписываются почти механически: все сценарии из утверждённого перечня имеют свою страницу; на каждой есть сроки, перечень документов и форма запроса; для каждой роли описано, что она видит и что может делать; для каждой интеграции названы система, направление обмена и его способ. Указывайте и форму передачи: «карта разделов» может оказаться схемой в закрытом сервисе, доступ к которому заканчивается вместе с проектом.

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

В перезапуске GrandeBoutique.ru — сети магазинов с ассортиментом свыше 35 000 наименований — концепцию показывали видео-презентацией, и не только заказчику: материалы показали фокус-группе и успели внести функциональные улучшения до продуктивного релиза. Для приёмки важна последовательность: сначала принимается способ, которым продукт разговаривает с покупателем, и только потом число отрисованных экранов.

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

И лицензии на шрифты и изображения. Пункт выглядит формальностью ровно до письма правообладателя, которое приходит через год — не подрядчику, а вам, потому что сайт ваш. Критерий простой: на каждый шрифт и каждую фотографию передан документ с именем вашей компании. Ответ «мы брали бесплатные» проверяется до подписания акта, а не после письма.

Про мобильную версию пишите не «адаптивность», а то, что будете проверять руками: какие экраны и на каких устройствах. На TagLex её делали самостоятельной работой, а не сжатием десктопа, и проверяли на реальных устройствах и на скорости мобильной сети.

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

Лучше всего это видно на обмене данными. У GrandeBoutique.ru более 30 интеграций и свыше 35 000 товарных позиций, по которым ежедневно идёт обмен: цена, остатки, наличие в магазинах. Остатки обновляются в реальном времени, а изменение стоимости уходит не только на сайт, но и в рекламные фиды. Каждая такая связь — отдельная проверка: завести операцию в источнике и убедиться, что через оговорённое время она видна везде, где должна. Отсюда критерий для любого проекта с обменом: операция выполнена, результат зафиксирован на приёмной стороне, время прохождения записано. Считают при этом направления обмена, а не названия систем.

Вторая половина этапа — админка, и принимает её не руководитель проекта, а тот, кто будет ею пользоваться. Критерий звучит как задание: создать материал, опубликовать, изменить, снять — без участия подрядчика. Интернет-маркетолог GrandeBoutique Ульяна Оржеховская описывает админку словами «двигаешь что хочешь и куда хочешь»: это оценка человека, который работает в ней ежедневно, а не смотрел демонстрацию.

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

В перечень проверок запуска входит то, что невозможно доделать потом по-тихому: учётные записи у хостинга, регистратора домена, платёжного провайдера и магазинов приложений оформлены на вашу компанию; переданы права на дизайн и код с перечнем сторонних компонентов и лицензий; старые адреса страниц перенаправлены на новые по сверенному списку. Про перенаправления скажем прямо: сохранение видимости в поиске никто гарантировать не может, но проверяемая часть есть — список старых адресов, карта соответствия и факт, что каждый адрес ведёт на свою страницу, а не на главную. Для GrandeBoutique.ru переезд со старой платформы был отдельной задачей, и в документе это сверка по списку, а не обещание результата.

Проще всего объяснить через то, что заказчик видит, когда пункта в приёмке не было. Домен продлевает подрядчик — и однажды просто не продлевает: сайт пропадает целиком, обычно в выходной, а вернуть его вы не можете, потому что в карточке домена не ваша компания. Платёжный провайдер оформлен на его юрлицо — деньги покупателей идут на его счёт, а выписку по возвратам вы просите письмом. Приложение лежит в его учётной записи разработчика — чтобы выпустить обновление, нужен человек, с которым вы уже расстались, а перенос между учётными записями идёт через поддержку магазина месяцами.

Поэтому в приложении к запуску пишется не «доступы переданы», а поимённый перечень: сервис, на какое юрлицо оформлена запись, кто у вас владелец, и отметка, что вы вошли своими учётными данными и смогли изменить права другого сотрудника. Полдня на приёмке против месяцев переписки потом.

Если продукт распространяется через магазины приложений, добавляется ещё один предмет приёмки — канал раздачи. В проекте «Центра Сопровождения Бизнеса» приложение раздаётся как корпоративный продукт по закрытой ссылке, и заказчик сам управляет подключениями. Принимают такую схему действием: доступ пользователю вы выдаёте и отзываете сами, в день приёмки.

Это снова общая практика, а не наш порядок работы, но практика дорогая. Любой проект меняется по ходу: бизнес пересматривает направления, появляется новая система, юрист требует переписать согласие на обработку данных. Вопрос не в том, будут ли изменения, а в том, остаётся ли от каждого след.

Когда документа об изменении объёма нет, изменения не исчезают — они растворяются в сроке. Подрядчик соглашается на просьбу в переписке, дата сдачи сдвигается без объяснения, а через два месяца вы не можете ответить руководству, почему этап на три недели идёт седьмую: проверяемого ответа нет ни у одной стороны. Бумага на каждое изменение решает это механически: что меняется, на сколько сдвигается план, что из принятого переделывается. Даже если подрядчик делает изменение без пересчёта, запись нужна — она объясняет срок.

Та же история с замечаниями. Переписка в мессенджере вместо реестра кончается одинаково: часть замечаний теряется, по второй половине стороны спорят, звучало ли это вообще, а к последнему акту приходит список из сорока пунктов разной давности, где никто не отличает невыполненное от передуманного. Реестр — одна таблица на проект: дата, статус, пометка «замечание или новое требование». Заводят его с первого этапа: на четвёртом месяце восстанавливать историю по чатам некому.

Половина конфликтов на приёмке не про качество работы, а про процедуру, которую никто не описал. Здесь тоже речь о практике, а не о нашем регламенте: ниже четыре вопроса, ответы на которые ищут в договоре подрядчика, а если их нет — задают до подписания.

Отговорить тоже честно. Если проект небольшой, решение принимает один человек и он же будет работать с результатом, формальная приёмка каждого этапа только тормозит. Достаточно перечня проверок на старте и разговора в конце этапа. Не стоит дробить приёмку и внутри дизайна по каждому экрану: макеты, принятые поштучно, перестают быть системой — каждый согласован, а вместе они не складываются.

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

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

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