Что именно нужно передать?
Когда приложение запущено, код — лишь часть того, чем должен владеть бизнес. Составьте список всего, от чего зависит продукт: репозитории с исходным кодом, инструкции по сборке, хостинг, домены, аккаунты разработчика в магазинах приложений и внешние сервисы — почтовые рассылки, платежи, карты. Напротив каждого пункта запишите, на кого он оформлен и у кого сейчас есть к нему доступ. Такой список стоит вести с первого дня разработки приложения на заказ.
Такой список нередко преподносит неприятные сюрпризы: аккаунт в магазине зарегистрирован на личную почту подрядчика, домен продлевается с чьей-то частной карты, а ключ к важному сервису знает только один разработчик. Всё это гораздо проще исправить до запуска, чем во время аварии.
Заранее решите, как доступы будут передаваться безопасно. Пароли и ключи хранят в менеджере паролей или в защищённом хранилище хостинга, но ни в коем случае не в общем документе, не в репозитории и не в рабочем чате. Отдельно решите, как отзываются доступы, когда люди уходят из проекта: доступ, оставшийся у бывших участников команды, — уязвимость, которую легко устранить заранее. Если продукт хранит данные клиентов, опишите, как эти данные выгрузить и как восстановить систему из резервной копии.
Проверить качество передачи просто: смогут ли владелец или другая квалифицированная команда собрать, выпустить и обслуживать продукт с тем, что они получили? Архив с кодом без инструкций по сборке, доступов и документации такую проверку не проходит.
Работает ли релиз там, где им будут пользоваться?
Сборка, которая прошла все тесты на тестовом стенде, в рабочей среде всё равно может сломаться: там другие настройки, настоящие права доступа, а какого-нибудь ключа может просто не оказаться. Поэтому после выпуска сами пройдите основной сценарий в рабочей среде — на тех устройствах и версиях операционных систем, поддержку которых вы обещали, и под учётной записью обычного пользователя, а не администратора.
Затем проверьте, что происходит при сбое. Попадают ли ошибки туда, куда команда действительно смотрит? Если резервное копирование входит в услугу, восстанавливал ли кто-нибудь копию на деле и работает ли восстановленная система? Можно ли откатить неудачную версию и сколько времени это займёт? У приложений из магазинов «откат» обычно означает выпуск исправленной версии, поэтому рискованные обновления разумно сначала выпускать постепенно, на часть пользователей.
Решите, кто получает оповещения о сбоях и что этот человек вправе сделать сам: перезапустить сервис, отключить функцию или обратиться к хостинг-провайдеру. И наконец, запишите известные ограничения и результаты приёмки на момент запуска. Иначе вашей поддержке придётся заново выяснять, что умеет продукт, по жалобам клиентов. Хорошо помогает и короткая памятка «что делать, если…» для самых вероятных сбоев: она экономит время именно тогда, когда его меньше всего.
Что должно входить в поддержку?
Большинство споров после запуска сводится к одному вопросу: это ошибка или новая работа? Ответьте на него заранее и разделите задачи на три вида. Исправление ошибок — это случаи, когда перестало работать то, что было принято при запуске. Работы по совместимости нужны, чтобы продукт продолжал работать после обновлений операционных систем, браузеров, требований магазинов и внешних API. Новые функции — всё, что выходит за рамки принятого объёма.
Для каждого вида запишите, как подаётся запрос, в какой срок команда на него реагирует, в какие часы работает поддержка и как оцениваются и утверждаются изменения. Это не бюрократия: когда платёжный сервис меняет свой API, обе стороны должны уже знать, чья это задача.
Ведите учёт текущих расходов и зависимостей — хостинга, платных сервисов, сертификатов, библиотек — и назначьте человека, который следит за изменениями и сроками продления. Каждое обновление продукта должно повторять нужные проверки приёмки и сохранять совместимость с уже накопленными данными пользователей. Поддержка — постоянная обязанность, и, как у любой обязанности, у неё должен быть записанный объём: заранее зафиксируйте, что входит в поддержку, а что считается новой работой. Если поддержку потом возьмёт на себя другая команда, передайте ей этот документ вместе с историей известных проблем.
Чек-лист: запуск и поддержка
- Составьте список исходников, аккаунтов, хостинга, доменов и сервисов и укажите, на кого оформлен каждый пункт.
- До передачи проекта перенесите пароли и ключи в защищённое хранилище.
- Пройдите основные сценарии в рабочей среде и, если это входит в услугу, проверьте восстановление из копии и откат версии.
- Запишите, что входит в поддержку, как быстро она реагирует и как утверждается новая работа.
- Держите в актуальном виде список известных ограничений, текущих расходов и обновлений зависимостей.
Пример: передача проекта, с которой заказчик может работать сам
Заказчик получает репозиторий в аккаунте своей компании, инструкцию по сборке, с которой справится другой разработчик, и чек-лист выпуска. Аккаунты разработчика в магазинах и хостинг оформлены на компанию, а в команде назначено, кто следит за мониторингом и кто проверяет резервные копии.
Через какое-то время после запуска приходят два запроса. В первом просят новый экран с отчётами — его оценивают и утверждают как отдельное изменение. Во втором сообщают, что оформление заказа, принятое при запуске, перестало работать после обновления операционной системы, — этот запрос идёт по процедуре исправления ошибок. Границы были записаны заранее, поэтому ни один из запросов не превращается в спор, а заказчик не зависит от одного разработчика: всё нужное для работы продукта оформлено на компанию и описано.
