Организация службы поддержки в географически распределенных проектах

Всем известно, что для эффективной работы службы технической поддержки эта служба должны быть многоуровневой. В этой статье я привожу ряд уроков и практических рекомендаций, которые я извлек из работы службы поддержки проекта, которым я руковожу. Эти рекомендации призваны помочь тем руководителям, которые только собираются организовать подобную службу в своих проектах и не имеют необходимого опыта. Управляя в данный момент проектом среднего объема (10-20 человек в команде проекта и несколько сотен клиентов по всему миру), я использовал разделение службы поддержки на три уровня. Вы можете видеть эти уровни на диаграмме.

	Условные обозначения
	- Клиенты
	- Региональные офисы поддержки
	- Центральный офис поддержки
	- Команда разработки

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

Рассмотрим вопросы, связанные с функционированием каждого из этих уровней.

Региональный уровень.

Первый (региональный) уровень необходим по нескольким причинам:

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


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


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


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


5. Клиентам удобней работать с местной службой поддержки, так как в этом случае они ощущают большую заботу о себе со стороны компании, особенно если они имеют личного регионального менеджера.

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

Однако, в работе региональных офисов существует ряд сложностей, на которые необходимо обратить внимание.

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


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


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

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

1. Доступ к продукту. Очень часто клиенты не в состоянии четко объяснить проблему или ситуацию, которая у них происходит. Для того, чтобы понять, с чем именно столкнулся пользователь, для службы поддержки будет очень эффективно, если она будет иметь доступ к продукту и данным клиента. Конечно, здесь возникает вопрос конфиденциальности клиентских данных, но если это не является проблемой или если этот вопрос решен, например, юридически, то предоставление доступа для службы поддержки весьма оправдано. Например, если речь идет о предоставляемой интернет-системе, то служба поддержки должна иметь возможность получить в нее доступ и проанализировать какие действия пользователь совершал и в чем состоит его затруднение. Это также необходимо и для того, чтобы предоставить полные объем информации в центральный офис, если возникнет такая необходимость. Центральный офис и команда разработки могут ощущать такой же недостаток информации, описывающей проблему, поэтому, имея подобный доступ, региональные сотрудники смогут собрать такую информацию.


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

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


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


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

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

Центральный офис.

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

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


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


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


4. Подготовка и рассылка описаний обновлений. При каждом выпуске обновлений продукта, центральный офис поддержки должен подготавливать и рассылать во все региональные офисы подробное описание всех изменений, проведенных в продукте. Он также должен оказывать консультации сотрудникам региональных офисов и особо важных клиентов по сути проведенных изменений.

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

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

Команда проекта.

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

Задачи, которые должна выполнять команда проекта для обеспечения процесса поддержки, следующие:

1. Предоставить центральному офису доступ к документам, позволяющим сформировать описание изменений, протекающих в проекте.


2. Обеспечить уведомление сотрудников центрального офиса поддержки о результатах решения вопросов, поступивших от них.


3. Обеспечить центральному офису помощь в решении тех вопросов, которые требуют вмешательства разработчиков.

Обобщение

На следующей диаграмме показано как уменьшается поток вопросов от клиентов до команды разработки.

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

Автор: Михаил Смирнов Руководитель проектов.