Разбирая разные анти-паттерны в исследовании продукта, мы нашли частые мнения о том, что Scrum-команда не должна быть отделена от технической поддержки клиентов. И это выражается не в том, чтобы работать как третья линия саппорта, когда первые две не смогли разобраться в проблеме.
В этой статье мы разберём Support-driven development — подход, который призывает разработчиков буквально работать на техподдержке.
Суть подхода
Техподдержка — это способ общения с клиентом, это тот рубеж, где происходит прямой контакт и от которого зависит дальнейшая реакция клиента. При этом команды техподдержки и команды разработки, как правило, это разные команды и отделы.
В Scrum владелец продукта полностью отвечает за него, но так ли это на самом деле? Может ли ваша команда ответить на вопрос: "Как сейчас построена поддержка продукта и можно ли сделать её лучше?"
В Support-driven development техподдержка воспринимается как источник запросов на улучшений и требует прямого участия команды в этом: в контакте с клиентом, обработке запросов и принятии решения о том, будет ли это пункт в бэклоге продукта.
Суть подхода "все на саппорте" выражается в следующем:
- поддержка клиентов (сохранение клиента) — главный приоритет компании,
- успех в бизнесе связан с удержанием клиентов,
- общение с покупателем — это не чья-то чужая проблема.
Концепцию можно разделить на образ мышления, процессы и инструменты. Вы можете выбрать какие-то детали для вашей ситуации, независимо от того, соберётесь внедрять всю идею или нет.
Если инструменты и процессы будут отличаться в зависимости от размера компании, то одно будет неизменно:
Принципы
- Качество поддержки — располагаем ли мы системой, которая гарантирует, что мы увидим все отзывы и обратную связь клиентов?
- Последовательность — все ли понимают, как нужно общаться, выдерживать тон общения, алгоритм действий и единые сценарии?
- Эффективность — получит ли клиент эффективное решение не зависимо от того, с кем он общается (не важно, стажёр это или директор компании)?
- Человечность — клиенты хотят разговаривать с людьми, так способна ли ваша поддержка говорить не только по скрипту, прикидываясь ботами?
Процессы
Здесь мы приведём несколько примеров того, как встроить концепцию в привычную работу команды.
1. Обучающий инструмент во время онбординга. Это действительно быстрый способ познакомить новичка со всей системой — дать ему отвечать на вопросы клиентов.
2. Ввести поочередное дежурство в течение спринта для всей команды без исключения (не важно, дизайнер это или тестировщик). В первоначальной концепции, это было 5% от рабочего времени. Конечно, это нужно учесть во время планирования спринта и подбирать остальные задачи пропорционально ёмкости команды.
3. Ввести участие в саппорте для команды разработки в те моменты, когда у отдельного человека идёт "простой". Да, мы не используем это понятие в Scrum и не боремся за 100%-ую утилизацию ресурсов, но на практике от этого тяжело уйти.
4. WIP обязателен.
5. Обязательно отслеживать документацию по всем исправлениям ошибок, запросам функций и жалобам клиентов.
- Если вы начинающий стартап, на старте нужно озаботиться системой для сбора почты и перевода ее в тикеты. Бесплатный инструмент — Streak, платная опция — Tout. Даже ресурсами обычной почты можно построить папки: "Отвеченное/неотвеченное", добавить ваши собственные лейблы и прочее, чтобы избежать публикации. Простейшую Тикет-систему можно построить в Trello.