Передача проекта заказчику по договору: что включить в акт, кроме кода

MAATRIX

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

Почему короткий акт работает против вас, а не против заказчика

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

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

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

Доступы и учётные данные: конкретный перечень, а не фраза «доступы переданы»

Строка «доступы переданы» в акте не защищает никого: она не говорит, какие именно системы имеются в виду, какие логины использовались, переданы ли они полностью, и не фиксирует момент времени. Если через три месяца заказчик заявляет «а от панели мониторинга доступа у меня нет», единственный способ ответить по существу — иметь перед глазами перечень, а не вспоминать, что вы вроде бы отправляли пароль в чате.

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

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

Отдельно стоит указать, какие доступы вы закрываете за собой после подписания — временные учётные записи, тестовые SSH-ключи, личные токены в переменных окружения. Это работает на вас: если через полгода в базе найдут забытый доступ, пункт «все временные и тестовые доступы закрыты на дату передачи» — готовый ответ на претензию, а не повод для разбирательства, кто и что забыл.

Сторонние сервисы и лицензии: кто платит дальше и на чьё имя оформлено

В процессе почти любого проекта появляются подписки и лицензии, которые по инерции остаются на аккаунте исполнителя: SSL-сертификат, купленный отдельно от бесплатного Let's Encrypt, лицензия на коммерческую CMS или платный плагин, подписка на API рассылок, платёжный шлюз, платный тариф мониторинга. У каждого пункта есть владелец аккаунта и способ оплаты — если это ваша карта, через несколько месяцев вы либо незаметно платите за чужой проект, либо сервис отключается в неожиданный момент, а виноватым в переписке окажетесь вы.

В акте (или в приложении к нему) стоит явно перечислить каждый такой компонент по одной и той же схеме:

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

Формулировка вроде «использован платный тариф сервиса email-рассылок, аккаунт оформлен на исполнителя, оплата до [дата], после этой даты переоформление и дальнейшая оплата — зона ответственности заказчика» закрывает сразу две проблемы: заказчик точно знает, что делать дальше и когда, а вы получаете письменную границу ответственности — если аккаунт отключится позже, потому что заказчик не переоформил его на себя, это прописанная в акте не ваша зона.

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

Документация: конкретный список переданного, а не общая фраза

«Документация передана» так же бесполезна в акте, как и «доступы переданы» — неясно, что именно имеется в виду. Через полгода, когда у заказчика сменится администратор или он наймёт другого подрядчика на поддержку, единственным подтверждением вашей работы по документации будет конкретный список файлов, а не воспоминание о том, что вы «вроде бы что-то присылали».

Стоит перечислить в акте пофайлово или хотя бы по категориям то, что реально передано на момент подписания:

- Схема архитектуры (диаграмма компонентов и их связей)
- Список установленного ПО и версий на момент сдачи
- Инструкция по деплою / обновлению кода
- Инструкция по восстановлению из бэкапа
- Файл переменных окружения (шаблон, без реальных секретов)
- README репозитория с описанием запуска локально
- Финальная версия технического задания со всеми согласованными изменениями
- Список известных ограничений и незакрытых задач (см. следующий раздел)

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

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

Статус тестирования и приёмки на момент передачи

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

Практический формат — короткая таблица покрытия тестирования, приложенная к акту:

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

Отдельно стоит перечислить открытые на момент сдачи задачи — мелкие доработки, которые стороны договорились доделать после, или найденные, но не критичные баги. Формулировка «известные незакрытые пункты: [список], срок устранения — [дата]» превращает их из потенциального повода не подписывать акт в согласованный план.

Почему подробная фиксация в акте защищает именно вас как подрядчика

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

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

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

Как собрать такой акт на практике, не увеличивая проект на неделю

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

Практический порядок для последнего дня перед подписанием:

1. Соберите реестр доступов и сторонних сервисов с лицензиями — по каждому: что передано, кому принадлежит аккаунт, кто платит дальше.
2. Составьте список переданной документации и таблицу тестового покрытия — по факту, а не по намерению; если чего-то не хватает, честно допишите план устранения со сроком, а не молчите.
3. Отправьте черновик заказчику заранее, за день-два до подписания — это даёт время на вопросы и снижает риск, что акт подпишут не глядя, а потом вернутся с претензией «не успели прочитать».
4. Подпишите с приложениями, а не одним листом текста — так данные читаются заказчиком внимательнее, чем растворённые в сплошном абзаце.

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

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

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