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

Сегодня я хочу рассказать вам о том, как нам в Одобрим.ру удалось совместить несовместимое, а точнее, как команда разработки может поддерживать продукты. То есть быть 2-3 линией поддержки одновременно.

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

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

Процесс работы с обращениями построен следующем образом



1. О наших клиентах заботится «Служба заботы о клиентах» — первая линия поддержки. Да-да, в хороших местах она существует :))

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

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

2. Мониторинг обращений пользователей осуществляется регулярно.
Дежурный инженер вызывается добровольно на недельное дежурство по обращениям.
Доска по обращениям похожа на Kanban доску.
На ней все очень удобно настраивается:



3. Первичная классификация обращения производится дежурным инженером и по ее результатам создается отдельно Bug (баг со ссылкой на документацию/требования) или Story (задача). Они привязываются к обращению. У нас есть сроки исправления ошибок и дежурный всеми силами пытается в них успеть.

4. На следующем этапе зафиксированный Bug исправляется разработчиками (Blocker, Critical). Затем проводится проверка и подтверждение исправления дежурным инженером

5. Story (задача) передается PO (владелец продукта) для приоритезации.

За 2 года командой разработки было обработано больше 270 обращений разного приоритета от нашего бизнес подразделения и пользователей из числа тех, с которыми не смогла справится первая линия поддержки.

Плюсы данного подхода

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

Минусы данного подхода

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

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