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

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

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

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

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

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

Всё это верно, но этого далеко не достаточно. Важно понимать, что при передаче техподдержки аутсорсеру привычная схема взаимодействия «клиент аутсорсера — аутсорсер» принимает более сложный вид «клиент разработчика — аутсорсер — разработчик». Это особенно важно, если речь идет о промышленной поддержке новых типов ПО — например, российского. Или программного обеспечения на базе Open Source. Такое взаимодействие имеет ряд важных особенностей, которые необходимо учитывать при выборе поставщика услуг т.н. вендорской техподдержки, чтобы обеим сторонам в итоге не было мучительно больно.

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

Люди

Во-первых, обращаем внимание на людей и на их знание продукта.

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

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

Вторая линия должна обладать глубокими знаниями продукта и его функций, чтобы решать нетиповые вопросы («Мы сделали все, как предписано, программа все равно не работает так, как должна!») Без глубоких знаний такие вопросы вместо решения будут неоправданно передаваться на третью линию — на разработчиков. Результат: разработчики завалены непрофильной работой, а нанятый аутсорсер сидит без дела.

Главное, на что нужно обратить внимание — это на то, как аутсорсер управляет компетенциями сотрудников.

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

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

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

Процессы

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

И тут очень важно понимать, что в этой сфере разработчики и аутсорсеры мыслят разными сущностями. У первых в приоритете «баг-репорты» (отчеты об ошибках), «фич-реквесты» (запросы на доработку функционала), «релизы» (плановый выпуск обновлений продукта).

У вторых — запросы на обслуживание, инциденты и проблемы, запросы на обслуживание, запросы на изменение. И эти сущности нужно уметь связать в едином информационном пространстве и правильно управлять ими, чтобы можно было говорить о постоянном росте качества ИТ-сервиса. Как именно это лучше сделать, зависит от конкретной ситуации. Поэтому вопрос о связи основных понятий из «двух миров» обязательно стоит задать ИТ-аутсорсеру. Чтобы проверить, насколько хорошо он понимает специфику разработки. И насколько глубоки и современны его компетенции в управлении процессами. Отсутствие внятных ответов — явный признак, что аутсорсер нетвердо знает, как лучше организовать поддержку. А здесь нужны только устойчивые знания и хорошо проработанные процессы.

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

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

Инструменты

В-третьих, смотрим на инструменты, которые использует аутсорсер. А именно — на систему учета обращений/ITSM-решение.

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

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

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

Итого

В идеале, сервисная компания, которая «забирает» у разработчиков программного обеспечения функцию его технической поддержки, должна уметь работать и с людьми (точнее, с их компетенциями), и с процессами, и с современными ИТ-инструментами. Чтобы разработчики российских программных продуктов могли со спокойной душой делать основную работу — постоянно развивать и улучшать их, наращивать количество внедрений. И при этом не опасаться, что внедренное ПО «не взлетит» или будет плохо работать у корпоративных пользователей. Используя «индикаторы» из этой статьи (глубокое знание продуктов, соответствующая стандартизация, система наставничества, сертификация специалистов; наличие базовых и высокоуровневых процессов; специализированная ИТ-система, в которой ежедневно отрабатывает заявки сервисная компания, инновационные, но доступные сегодня инструменты мониторинга «здоровья» ИС), любая компания-разработчик может правильно выбрать ИТ-партнера и не пожалеть о последствиях. не пожалеть о последствиях