В мире продакт-менеджмента есть одна из самых важных метрик на стыке продукта и техники - SL или Service Level. Кто-то считает, что Service Level - скорее техническое понятие, но он существует только в рамках SLA (Service Level Agreement) как контракта между бизнесом и его пользователями. Так что продакту очень важно хорошо понимать, какой уровень сервиса предлагается в его продукте, какие в нём ограничения и как на него влияют инциденты.

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

Миф 1: SL отражает аптайм конкретных сервисов В целом так оно и есть, но не совсем. SL должен базироваться на том, сколько времени в месяц/год/пр. ваш продукт реально доступен и может приносить ценность. Например, техническая ценность любого PaaS-решения в том, сколько времени платформа функционирует и позволяет выполнять бизнес-задачи. Если у вас есть какой-то сервис, отвал которого не приводит к недоступности функционала - он не должен учитываться в SLA (например, бьютификатор в онлайн-IDE). Если у вас есть сервис, деградация или недоступность которого влияет только на скорость работы решения - стоит отдельно выделять его в SLA (мы замедлимся, но всё ещё функционируем и приносим ценность). Он не должен облагаться теми же требованиями, что ключевые сервисы. В то же время, SLA должен действительно жёстко ограничиваться своей инфраструктурой и сервисами. Если у пользователя 2 дня не было интернета на компьютере, и он не мог пользоваться нами - мы не должны пострадать.

Миф 2: Инженеры знают, как писать SLA, и валидировать его не нужно На самом деле нужно, ещё и как. Представьте: приходит к вам инженер и говорит, что в SLA надо писать 99,9999999% доступность, потому что наши сервера работают всегда и бесперебойно. Если одна машина отвалится - другая её заменит, и всё будет в порядке. На проверку этих слов надо призвать архитектора: 1. Архитектор знает, как размещены сервисы по железу и может посчитать точные цифры по доступности каждого с учётом рисков; 2. Продакт должен докопаться до архитектора, какие из сервисов (см. миф 1) должны быть включены в SLA - и указать их аптайм для корректного управления ожиданиями пользователей. Это упражнение критично важно - если транслировать в SLA цифры без валидации, то они будут очень красивыми и бесполезными в реальности. Особенно сильно это стреляет в продуктах в b2b и b2g сегментах - с плохим SLA вы в целом не дойдёте до сделок/контрактов.

Миф 3. SLA невозможно подогнать под всех клиентов А вот это - чистая правда, но миф тут в другом. Это упражнение вообще не нужно делать. Как только у бизнеса появляются первые последователи, то они сразу активно дают обратную связь о том, что им важно увидеть в SLA. Задача продакта тут: послушать -> донести это до архитектора и инженеров -> договориться о способе подсчёта и фиксации в контракте -> дисконтировать ожидания заказчиков и отразить в договоре. После этого SLA будет малоизменчив. Останется всего 4 причины его дополнять: 1. Сделки с ключевыми клиентами, которые требуют наличия определённых гарантий; 2. Добавление новых сервисов; 3. Изменение инфраструктуры продукта; 4. Обслуживание новых бизнес-задач, требующих новых гарантий.

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

📝 А какие мифы об SLA известны вам? Хотите ли больше узнать об этой форме контракта и типовых ошибках, которые негативно аффектят продукт? Пишите в комментариях 👇

P.S. Не забывайте оставлять ❤️😃

Делитесь этим постом, давайте соберём больше мифов и развенчаем их 🤓