Привет, это Антон Павлов — Head of Products в ITSM 365. 

Релизы помогают компаниям повысить лояльность клиентов —  у пользователей появляется ощущение, что продукт развивается, завтра никуда не исчезнет. Добавление новых фич по просьбе клиента создаёт впечатление, что компания слышит пользователей. 

Однако во время релиза легко совершить ошибки и обрушить надолго сервис всем пользователям. Это может перечеркнуть все позитивные аспекты релизов. 

Рассказываю на пятилетнем опыте выпуска релизов для сложных B2B-клиентов, какие меры предосторожности нужно предпринять, чтобы ничего не чинить после обновления.  

Из чего состоит у нас релиз: объясняю на кубиках Lego

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

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

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

Как мы собираем релиз

Редко, но метко

В случае с B2C-продуктами клиент не сильно зависит от сервиса — не доставляет «Пятёрочка», значит, доставит «Самокат». Это даёт компании свободу обновлять свои приложения часто, привнося минимальные изменения. 

Мы же работаем с B2B-клиентами, это привносит свои особенности: 

• Цена некорректных изменений

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

• Цена остановки работы системы

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

• Сложность интерфейса

В B2C-приложениях всё относительно просто — вот корзина, вот магазин, вот окошко оплаты. В B2B сервисах всё сложнее — есть большое количество разных процессов, подпроцессов и их взаимодействие. 

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

С разделением на тарифы

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

Сразу и для всех

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

Возможности отказаться от обновления у нас нет, мы просто предупреждаем, что в такое-то время сервис будет недоступен. 

Этапы релизов

Обеспечивать качество релизов нам помогают следующие этапы: 

Этап №1. Планирование и распределение задач

С одной стороны, процесс планирования и распределения задач может быть понятен. В B2B вес клиента большой, может показаться, что самый логичный выход — реализовывать все запросы пользователей. 

На самом деле всё гораздо сложнее. Как этот процесс проходит у нас, расскажем уже в следующей статье.

Этап №2. Выбор версии платформы

Мы работаем на базе конструктора, он привносит новые инструменты и технологии. Они касаются администрирования сервиса и интерфейса. 

Когда мы выбираем версию конструктора, то мы здесь учитываем следующие моменты: 

• Продуктовая составляющая — ориентируемся на те фичи, которые помогут улучшить нашу систему;

• Инфраструктурная составляющая — DevOps команда убеждается, что сервис будет работать в облаке;

• Сама платформа — мы выступаем потребителями другого продукта. У него есть свои релизные процессы, которые тоже важно учитывать. 

На стыке этих трёх процессов мы выбираем самую подходящую версию платформы. 

Этап №3. Тест версии

Здесь мы погружаемся в тестирование новой версии платформы на нашей текущей конфигурации: обновление не должно сломать базовые настройки системы. 

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

Тестирование также помогает нашей команде лучше узнать продукт и найти его недостатки, которые мы не замечали раньше. 

Кейс, после которого появился этап теста версии

Как-то у всех клиентов после обновления перестала работать входящая почта, а в нашем продукте это основной канал подачи заявок пользователями. Большинство клиентов не могли воспользоваться сервисом, а это значит убытки и простои. Мы исправили ситуацию за пару часов в тот же день, повторять опыт бы не хотелось. 

Этапы №4, 5 и 6. Аналитика и реализация и тестирование задач

Обдумывание ценности всего продукта 

Наш продукт построен на платформе, которая даёт новые инструменты. Они позволяют взглянуть на процессы по-новому, внести изменения в работу системы. 

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

Это позволяет нам сделать зум-аут — посмотреть на продукт на расстоянии — создать цельное и масштабируемое решение, которое закроет сразу много потребностей клиента. 

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

Круговорот знаний в команде

Затем идут этапы реализации и тестирования задач. Для нас важно, чтобы аналитикой, реализаций и тестированием задач занимались разные сотрудники из команды. 

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

• Во-вторых, взгляд одного человека «замыливается», «свежим взглядом» можно найти ошибки там, где раньше их не замечали.

Этап №7, 8. Перенос на предэталонный стенд и повторный тест задачи

У нас есть три стенда, которые участвуют в подготовке релиза: 

• Develop-стенд — на этом стенде мы тестируем работу продукта на новой версии платформы, проектируем и тестируем изменения в продукте;

• Предэталонный стенд (Prototype) — внутренний стенд с актуальной версией продуктовой конфигурации;

• Эталонный стенд — внешний стенд, с которого и запускаются клиенты. На него мы переносим обновления, только когда релиз полностью готов.  

На этом этапе мы тестируем уже не просто разрозненные задачи — как мы делали на Dev стенде, а их взаимодействие между собой. Делаем мы это на предэталонном стенде. 

Тестирование на предэталоне помогает не трогать лишний раз эталонную версию продукта. Если что-то пойдёт не так, то эталонная конфигурация не сломается. 

Этап №9. Написание инструкций и готовых ответов

Когда продукт простой, то, конечно, он должен быть интуитивно понятным и не требовать инструкций и готовых ответов. Однако когда мы говорим про сложный бизнесовый продукт, то части новых механик нужно обучать, часть из них нужно обосновать для клиентов. Для этого мы и готовим инструкции. 

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

Инструкции и ответы помогают службе поддержки — мы заранее готовы к наплыву заявок от клиентов. Готовые ответы к тому же помогают команде чувствовать себя более спокойно — после релиза клиентов одномоментно может одновременно обратиться более 50 человек. Понимание, что смотреть и где, снимает тревогу.

В конце мы подготавливаем документацию — конечно же, вручную — и вывод подсказок для клиентов в интерфейс

Этап №10. Повторное тестирование версии

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

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

Наш продукт — настройка платформы, в каждом релизе мы можем делать очень много изменений. Минус этого подхода в том, что автоматическое тестирование становится очень долгим и дорогим. Повторным тестированием мы и покрываем автотесты. 

Этап №11. Update-стенды

Update-стенды — копии стендов крупных клиентов. Заказчики делают пробное тестирование их копий в течение двух недель для нашего и их спокойствия. 

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

Этап №12. Перенос на эталон

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

Этап №13. Подготовка вебинара релиза

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

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

Этап №14. Массовое обновление 10% стендов

Мы начинаем обновление всего с 10%, чтобы убедиться, что всё работает корректно. 

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

Этап №15. Массовое обновление пользователей на младших тарифах

Через неделю мы обновляем младшую конфигурацию на всех младших тарифах.

Этап №16. Массовое обновление всех стендов

Если обновление на младших тарифах прошло успешно, то мы обновляем все стенды. 

Этап №17. Сбор обратной связи

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

Этап №18. Сбор аналитики

На этом этапе мы собираем количественные данные, которые решили замерять ещё до запуска релиза. Здесь мы определяем, пользуются ли клиенты фичами, если нет, то почему. 

Этап №19. Отмечаем релиз

… а дальше начинаем всё по новой. 

Вывод

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

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