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

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

Приёмка программного обеспечения: что проверяете вы, а не подрядчик

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

Проверка состоит из нескольких действий, и каждое делаете вы или ваш человек:

  • Сверить версию. Версия на сервере должна совпадать с коммитом в вашем репозитории. Это видно, а не обещано: если подрядчик не может показать, какой именно код сейчас работает, принимать пока нечего.
  • Запустить тесты у себя. Тесты должны проходить в вашем CI, а не на ноутбуке разработчика. Попросите два прогона: зелёный на рабочей ветке и красный на специально сломанной. Так мы сдаём автотесты, и так видно, что тесты вообще способны упасть.
  • Пройти главный сценарий на своих данных. Не по плану демонстрации, а так, как работа идёт у вас: ваш сотрудник делает настоящую задачу от начала до конца.
  • Проверить передачу. Выкатку, откат и восстановление из бэкапа выполняет ваш человек; что именно в неё входит — ниже.

Такую проверку называют приёмочным тестированием, и смысл её в том, кто проверяет. Если всё перечисленное делает только подрядчик, а вы смотрите на экран, приёмки по сути не было.

Что обязано входить в передачу

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

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

Инструкция по выкатке и откату. Как выпустить изменение и как вернуть предыдущую версию. Проверенная при вас, а не описанная.

Восстановление из бэкапа, выполненное на ваших глазах. Бэкап, из которого ни разу не восстанавливались, — это надежда по расписанию.

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

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

Как проверить заранее, а не в конце

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

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

Как выглядит передача, которая прошла хорошо

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

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

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

Что записать в акт приёмки программного обеспечения

Итоговый акт полезнее писать не как «работы выполнены в полном объёме», а как перечень того, что вы проверили. В нём стоит назвать четыре вещи:

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

Перечень замечаний — не формальность. Если ваш договор на разработку оформлен как подряд, статья 720 части второй Гражданского кодекса РФ обязывает заказчика в сроки и в порядке, которые предусмотрены договором, осмотреть и принять работу с участием подрядчика, а обнаруженные недостатки немедленно ему заявить. Сослаться на недостатки, найденные при приёмке, заказчик вправе, если они оговорены в акте или ином документе, удостоверяющем приёмку, либо там оговорена возможность потребовать их устранения позже. Кто принял работу без проверки, теряет право ссылаться на явные недостатки, если договор не говорит иного. О скрытых недостатках, которые обычной приёмкой не найти, подрядчика извещают в разумный срок после того, как они обнаружились. Здесь пересказана только сама статья; формулировки договора — с юристом.

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

Пять вопросов до подписания договора

Задайте их до начала работ, а не в конце: в конце у вас нет рычага.

  • На кого оформлены аккаунты? Домен, хостинг, платёжный провайдер, аккаунты разработчика в сторах, почта. Правильный ответ — на вас, с первого дня.
  • Где лежит репозиторий? В вашей организации, а не «у нас, потом перенесём».
  • Что будет в инструкции? Хороший ответ перечисляет: как развернуть с нуля, как выкатить, как откатить, что делать, если упало ночью.
  • Есть ли тесты и запускаются ли они у нас? Сьют, который живёт только у подрядчика, — не ваш актив.
  • Что происходит, если мы расходимся на середине? Ответ «у вас остаётся работающий кусок и все доступы» и ответ «придётся начинать заново» — это два разных типа подрядчика, и узнать это лучше сейчас.

Почему мы делаем это частью цены

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

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

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

Вопрос, который стоит перед этим: своя разработка или готовая коробка: как выбрать за неделю.