«Капитан, мы тонем!»: Как спасти релиз еще на этапе его подготовки

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

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

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

Как мы «собираем» релиз: объясняю на кубиках 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. Отмечаем релиз

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

Вывод

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

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