Что делать компании-разработчику с поддержкой своего продукта сегодня и завтра?

Этим вопросом рано или поздно задаются все дальновидные компании-разработчики. Что не удивительно, ведь многие корпоративные клиенты не будут даже рассматривать продукт, если у него нет поддержки. Но поддержка значит гораздо больше, чем формальное соответствие требованиям заказчика. С одной стороны, правильно организованная служба технической поддержки выявляет, потом устраняет реальные, а иногда и воображаемые* проблемы, связанные с продуктом. И сглаживает раздражение клиента. С другой, — качественная масштабируемая техподдержка может дать разработчику гораздо больше, став важным конкурентным преимуществом, способным не только привлечь новых заказчиков, но и удержать текущих. Потому что после продажи продукта взаимодействие с клиентом не прекращается. На передовую как раз и выходит служба поддержки.

Но по той же самой причине сбои в её работе наносят очень большой репутационный ущерб. Ведь клиент уже столкнулся с проблемами (что и стало причиной обращения). Однако вместо быстрого решения получил новый негативный опыт! Больше ему идти некуда... И он начинает думать уже не о конкретной проблеме, а о том, не поменять ли ему продукт и компанию.

Как же предотвратить этот риск?

Думать заранее

К сожалению, исторически сложилось, что компетенции в разработке автоматически не идут в зачёт, когда мы говорим о поддержке. Разработка — это каждый раз создание чего-то нового, будь то продукт, версия, отдельная «фича». Развитие программного продукта — это серия проектов, для управления которыми сегодня применяется целый спектр подходов. От традиционного «водопада (waterfall)», который еще недавно доминировал безраздельно, до всё чаще применяемого Agile с реализациями в виде Scrum или, например, Extremeprogramming (XP).

Поддержка, в отличие от разработки — не создание нового, а многократно повторяющаяся повседневная деятельность, стабильный процесс. Поэтому здесь используются принципиально иные подходы к управлению. Для техподдержки в ИТ давно стал стандартом IT Service Management (ITSM), реализованный в ITIL, ISO 20000, COBIT, MOF. На небольшом масштабе их различия практически незаметны. Какая разница, какой подход применять, когда за полгода к вам приходит от силы десяток обращений?

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

• Готовы ли мы к тому, что число обращений быстро вырастет? Например, в 100 раз. После чего поток не восстановится, а будет только увеличиваться.
• Готовы ли мы к тому, что пользователи ожидают получить ответ в 5 раз быстрее, чем это происходит сейчас?

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

В результате, чтобы хоть как-то сдержать растущий вал обращений, приходится привлекать разработчиков, из-за чего горят планы сдачи новых версий, а дорогие специалисты вынужденно отвечают на множество совершенно разных вопросов, 80-90% которых не требуют их уровня квалификации. Усиливается раздражение и специалистов, и заказчиков, которые чувствуют, что взаимодействие с компанией не эффективно. А хаос всё возрастает.

Как же на практике своевременно и эффективно предотвратить эту ситуацию?

Не изобретать велосипед

Поддержка, наверное, самый распространённый вид деятельности в ИТ. За годы ее существования накоплен огромный опыт, выработаны «лучшие практики». Грех ими не воспользоваться. Для этого, как обычно, нужны люди, процессы и инструменты.

Люди — самое важное, без них всё остальное не имеет смысла.

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

Но если речь идет о зрелых программных продуктах для крупных предприятий, то можно ориентироваться на знакомое правило 80/20: пятая часть обращений приходится на баг-репорты, а 80% — на консультации, помощь в настройке, фич-реквесты.

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

Структура потока обращений «80/20» позволяет повысить эффективность службы технической поддержки, организовав её сотрудников в группы и выстроив последние по уровням или «линиям». Как правило, оптимальным оказывается 3 уровня поддержки:

• 1 линия — приём и регистрация обращений, консультации по использованию продукта, устранение сбоев в рамках инструкций, сбор необходимой информации для передачи обращения дальше. И разъяснение заблуждений. В идеале все стандартные обращения выполняются здесь.
• 2 линия — опытные сотрудники, но ещё не разработчики. Они знают намного больше хорошего специалиста 1-й линии. Например, могут проводить тонкую настройку серверов. И отрабатывать нестандартные обращения — за счет хорошего знания продукта и предметной области, опыта и личных качеств. Но обращения, требующие изменений кода, проходят дальше.
• 3 линия — разработчики продукта или (реже) специально обученные эксперты по продукту. В идеале до этого уровня должны доходить только обращения, выполнить которые без изменения исходного кода продукта нельзя. При правильной организации службы техподдержки этот идеал вполне достижим.

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

Процессы (настоящие, а не только по названию!) практически необходимы для организации работы сотрудников, стабильно приводящей к предсказуемым результатам. А также обеспечивающей соблюдение нормативов и всесторонний контроль. Просто набрать людей и сказать «Вперед!» недостаточно. Кстати, не стоит надеяться, что сотрудники организуются самостоятельно. Такого никогда не бывает.

Служба поддержки, наверное, самая проработанная область ITSM. Поэтому конкретные описания процессов можно смело брать, например, из ITIL или ISO 20000.

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

Есть минимум процессов, с которых стоит начать:

1. Управление инцидентами (Incident Management) и управление запросами на обслуживание (Request Fulfilment). Часто их объединяют в один процесс — управление обращениями. Его назначение — выполнять обращения клиентов в соответствии с текущими договоренностями. В рамках процесса описывается ход выполнения обращения — от момента его регистрации и до закрытия. В том числе в данном процессе определяются единые критерии того, в каком случае обращение считается закрытым.
2. Управление уровнем сервиса (Service Level Management). Выше я упоминал текущие договоренности, в соответствии с которыми обрабатываются заявки. Процесс управления уровнем сервиса как раз и предназначен для управления такими договоренностями: их фиксации, доведения до сведения заинтересованных лиц, изменения. Если у вас уже есть тарифы на поддержку для клиентов, то это сюда. Например, вы можете по умолчанию оказывать поддержку с 9 до 18 по будням, а за отдельную плату оказывать поддержку 24/7 некоторым заказчикам.

Кроме времени поддержки, рекомендуется установить крайние сроки для процесса управления обращениями. В идеале должны быть зафиксированы два срока: время реакции (от подачи обращения до принятия его в работу специалистом) и время решения(от подачи обращения до его выполнения). Без четких договоренностей о сроках вы не сформируете ясных ожиданий у ваших клиентов. Поэтому легко можете пострадать от завышенных. Все эти договоренности желательно зафиксировать в договоре об уровне обслуживания(Service Level Agreement — SLA).

Инструменты должны поддерживать процессы. Обычно это средства автоматизации.

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

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

1. У вас должны быть оперативные и развитые средства коммуникации с пользователями. Для контроля за обращениями только телефона и почты давно уже не хватает. Нужен еще и личный кабинет. Если его не будет или если он будет неинформативным, готовьтесь к лавине вопросов: «Что там с моей заявкой?». Крайне желательно, чтобы личный кабинет корректно отображался на всех устройствах, в том числе и на смартфонах. И чтобы в нем были реализованы оповещения о каждом изменении статуса заявки.
2. Использование информационной системы позволяет вам собирать статистику по обращениям. Это ценнейшие данные, несложный анализ которых позволяет принимать обоснованные решения по развитию продукта. Например, вы сразу увидите, что действительно является источником основного раздражения пользователей при работе с продуктом. И куда лучше направить усилия разработчиков. Желательно, чтобы в системе управления обращениями были инструменты для выявления и качественной визуализации подобных трендов.
3. Должен быть потенциал для роста. По мере развития компании меняются уже реализованные процессы и приходит понимание необходимости новых. Соответственно, меняются и требования к их автоматизации.

Способ сэкономить

Люди, процессы и инструменты в совокупности составляют компетенции. Такие компетенции требуют значительных денежных затрат и времени на создание/накопление. А также полномасштабной реализации сервисной модели бизнеса и ее грамотной управленческой «обвязки». Причем эта модель кардинально отличается от организации основной деятельности компании-разработчика. Все это создает риски. Но ведь компетенции можно наращивать не только самостоятельно, их можно передать на аутсорсинг.

Если же компания-разработчик делает ставку только на свои силы, это автоматически приводит к тому, что она должна будет конкурировать на рынке труда с остальными ИТ-компаниями за сотрудников поддержки. И эта конкуренция становится всё более и более жесткой.

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

Всех этих (и многих других сложностей) можно избежать, передав на аутсорсинг первые две линии техподдержки поддержки и оставив у себя 3-ю, где участие разработчиков необходимо. Разумеется, в такой схеме важно следить за уровнем качества работы всех трёх линий. Это непросто, если вам надо предоставлять территориально распределённый сервис техподдержки и если вы опираетесь на нескольких партнеров. В таких случаях особенно велик риск большого разброса уровня качества и, как следствие этого, —снижения удовлетворенности ваших клиентов. Что отразится на вашей репутации, ведь клиенту абсолютно не интересно, что это плохая работа вашего партнера, а вы сами — супер-молодцы.

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

Партнерствовать с умом

Выбирая партнера, надо очень внимательно относиться к рекомендациям. Если ваши коллеги по цеху уже передали поддержку на аутсорсинг и довольны сотрудничеством, пообщайтесь с ними, узнайте как всё организовано. Это позволит избежать большинства проблем. И получить весомые преимущества:

• К разработчикам попадает ~10-20% обращений, причем действительно требующих их квалификации. Остальные обращения закрывает партнер, который тоже занимается тем, что умеет делать лучше всего.
• Сэкономленное время разработчиков используется для ликвидации причин обращений. Что не только сокращает их поток и затраты на техподдержку, но иисключает одну из главных причин разочарования пользователей продукта и связанных с этим репутационных издержек и снижения лояльности. В работе с потребителем проактивность всегда лучше реагирования. Особенно сейчас, когда российскому ПО еще только предстоит завоевать его доверие.
• Резко упрощается масштабирование службы техподдержки. Так компания-разработчик занимается только поиском и подготовкой специалистов третьей линии. Т.е. хорошо знакомой областью.
• У компании появляются готовые инструменты, с помощью которых можно объективно контролировать качество поддержки. А также строить аналитику и совершенствовать технологию работы.
• Всё это проявляется особенно отчетливо, если сервис техподдержки охватывает несколько регионов. Или даже всю территорию страны.

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

Но остаётся ещё проблема взаимодействия служб техподдержки разных компаний, продукты которых часто используются совместно. Здесь нередко возникает крайне мучительная для пользователя ситуация, когда компании «отфутболивают» его друг к дугу. Время идет, а его проблема не решается. Десятилетиями это считалось нормой. Но это совсем не нормально. И сегодня на отечественном ИТ-рынке уже есть эффективное решение этой проблемы, которое также можно применить на практике. Но эту тему мы рассмотрим в другой раз.

* Воображаемые проблемы могут быть связаны со многими причинами, например, с неверным пониманием назначения продукта или его отдельных функций. А также с устойчивыми заблуждениями относительно целых классов ИТ-решений. Особенно много таких заблуждений окутывает свободное ПО (Open Source). И хотя реального основания нет, ложные ожидания и стереотипы могут сокрушительно влиять на оценку ИТ-решения пользователем, принося вполне реальный ущерб. Если такие заблуждения широко распространены, они могут стать главным препятствием, сдерживающим рост продаж не только конкретного продукта, но и целых классов ИТ-решений.

Источник: CRN.ru
Дата публикации: 15 июня 2017
Автор: Дмитрий Толоконников, бизнес-аналитик департамента ИТ-аутсорсинга ALP Group