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

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

Почему ни одно ПО не остаётся «законченным»?

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

• Обновляются операционные системы. iOS и Android каждый год выпускают новую версию; магазины приложений могут требовать, чтобы приложения были нацелены на определённую версию.
• Меняются браузеры. Интерфейс, написанный несколько лет назад, в сегодняшнем браузере может вести себя иначе.
• Обновляются зависимости. В используемых библиотеках находят уязвимости и закрывают их; вы тоже должны установить исправления.
• Меняются сторонние сервисы. Когда платёжная система, служба доставки или картографический сервис обновляет свой интерфейс, ваше подключение может перестать работать.
• Меняется законодательство. Изменения в сфере счетов-фактур, налогов или защиты данных отражаются на программе.
• Меняется ваш бизнес. Новая услуга, новая структура цен, новый филиал.

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

Обслуживание — не одно, а четыре разных вида работ

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

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

Расходы, которые продолжаются после сдачи

Помимо услуг обслуживания, есть регулярные статьи, которые поддерживают продукт в рабочем состоянии:

• Хостинг сервера и базы данных — растёт с числом пользователей
• Домен и SSL
• Аккаунты разработчика в магазинах приложений (для мобильных приложений)
• Плата за использование сервисов уведомлений, SMS, email, карт и подобных
• Комиссии платёжной системы
• Инструменты отслеживания ошибок и резервного копирования
• Платные лицензии, если есть

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

Что должно быть прописано в договоре на обслуживание

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

• Объём: какие из четырёх видов выше включены?
• Определение ошибки: что считается ошибкой, а что — новым запросом.
• Уровни критичности: «система полностью остановилась» и «есть опечатка» не могут иметь одинаковую срочность. Для каждого уровня должно быть определено своё время реакции.
• Время реакции и время начала работ: через сколько после обращения вам ответят и через сколько начнут работать? Это разные вещи.
• Часы работы: поддержка в рабочие часы по будням или 24/7? Это оценивается совершенно по-разному.
• Включённые часы: сколько часов входит в ежемесячный пакет и что происходит при превышении?
• Канал обращений: куда направлять запросы? Это должен быть отслеживаемый канал, а не личный телефон.
• Резервное копирование: частота, место хранения, время восстановления и кто за это отвечает.
• Расторжение и передача: как будут переданы код, данные и аккаунты по окончании договора?

Обязателен ли договор на обслуживание?

Нет, но принимайте решение, зная, какова альтернатива. Есть три пути:

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

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

Как подавать запрос в поддержку?

Небольшой порядок с вашей стороны заметно сокращает время решения:

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

Часто задаваемые вопросы

Какой должна быть гарантия?

Единого стандарта в отрасли нет; распространена практика бесплатного исправления ошибок в течение определённого срока после сдачи. Важно, чтобы срок и то, что он покрывает, были прописаны в договоре.

От чего зависит стоимость обслуживания?

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

Что будет, если я начну работать с другой компанией?

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

Когда я захочу новую функцию, каждый раз нужно будет запрашивать предложение?

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

Нужно ли обслуживать программу, которой никто не пользуется?

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

Обсудим обслуживание вашего проекта

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