Какие документы должны передаваться после завершения проекта?

Что важно проверить перед приёмкой выполненных работ:

• Документы должны фиксировать, что именно было разработано и принято

• Доступы важны не меньше актов: без них заказчик не контролирует результат

• Документация должна объяснять только значимые особенности сайта, а не дублировать весь код

• Права на результат, лицензии и учётные записи нужно разделить и оформить отдельно

• Передачу лучше проверять до финальной приёмки, а не после подписания документов

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

В Ameton рекомендуем рассматривать передачу проекта как часть разработки, а не как формальность после запуска. Заказчик должен получить не набор файлов, а возможность управлять сайтом, поддерживать его и передавать другой команде без восстановления контекста с нуля

Главная цель передачи — сохранить контроль над сайтом

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

Базовый комплект обычно включает:

• договор, приложения и согласованные изменения к ним

• акт или иной документ о приёмке результата

• техническое задание, прототипы, макеты и перечень реализованных функций

• доступы к сайту, домену, хостингу, репозиторию и связанным сервисам

• исходный код и инструкции по его развёртыванию, если это предусмотрено договором

• сведения о лицензиях, платных модулях и сроках их продления

• документацию по нестандартным компонентам, интеграциям и критичным сценариям

• список известных ограничений и незавершённых задач, если они есть

Документы не обязаны быть одинаково подробными для каждого проекта. Небольшому сайту-визитке обычно не нужна объёмная техническая документация. Интернет-магазин, B2B-портал или сайт с несколькими интеграциями требует более полного комплекта, потому что без него невозможно безопасно менять связанные процессы

Какие документы подтверждают состав выполненных работ

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

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

Мы рекомендуем хранить согласованные материалы вместе с договорными документами. Через время именно они помогают отличить гарантийное исправление от новой доработки

Какие технические материалы нужны после запуска

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

Для проекта необходимо передать:

• адреса рабочих и тестовых контуров, если тестовый контур предусмотрен

• порядок развёртывания изменений

• сведения о репозитории исходного кода и актуальной ветке проекта

• карту внешних систем, с которыми связан сайт

• описание обмена данными: что передаётся, в каком направлении и как обрабатываются ошибки

• перечень критичных пользовательских сценариев

• порядок резервного копирования и восстановления

• список нестандартных модулей, доработок и известных ограничений

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

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

Какие права, лицензии и учётные записи нужно оформить

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

Особое внимание нужно уделить:

• условиям передачи прав на дизайн, код, тексты, фотографии и другие материалы

• лицензиям на CMS, платные модули, шрифты, изображения и внешние сервисы

• регистрации домена на компанию или уполномоченное лицо заказчика

• доступам к хостингу, корпоративной почте, аналитике и сервисам рассылок

• аккаунтам платёжных, логистических и других подключённых сервисов

• порядку оплаты и продления лицензий

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

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

Чем отличается комплект передачи для разных сайтов

Чем сильнее сайт связан с операционными процессами компании, тем важнее подробная передача. Простому информационному сайту достаточно компактного комплекта, а для магазина или портала документация становится частью устойчивости бизнеса. Корпоративный сайт и интернет-магазин могут выглядеть одинаково сложными по количеству страниц, но их комплект передачи будет разным. У магазина ключевое значение имеют сценарии заказа и правила работы с данными. У B2B-портала — логика ролей и документов, которую нельзя восстановить по интерфейсу

Как проверить, что передача проекта проведена качественно

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

Для всех проектов команда проводит короткую передачу вместе с представителем заказчика: не отправляет архив документов, а проверяет, что получатель понимает, где находятся материалы и как ими пользоваться

Почему недостаточно передать только сайт и доступ администратора

Доступ к административной части сайта позволяет менять контент, но не заменяет доступ к инфраструктуре, коду и связанным сервисам. Если компания может отредактировать страницу, но не может восстановить резервную копию, продлить домен или передать проект новой команде, контроль остаётся неполным

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

Когда нужно обновлять документацию

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

Не каждую правку нужно оформлять отдельным документом. Но стоит фиксировать изменения, которые:

• затрагивают интеграции и источники данных

• меняют роли и права пользователей

• добавляют нестандартные компоненты

• влияют на порядок развёртывания

• создают новый критичный сценарий

• изменяют состав лицензий или внешних сервисов

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

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

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