|
|
June 26
Здесь я привожу текст своей статьи "Практические рекомендации по организации службы поддержки в малых и средних проектах" опубликованной на сайте GotDotNet.ru - http://www.gotdotnet.ru/LearnDotNet/Misc/481321.aspx
Введение
Всем известно, что для эффективной работы службы технической поддержки эта служба должны быть многоуровневой. В этой статье я привожу ряд уроков и практических рекомендаций, которые я извлек из работы службы поддержки проекта, которым я руковожу. Эти рекомендации призваны помочь тем руководителям, которые только собираются организовать подобную службу в своих проектах и не имеют необходимого опыта.
Работа службы
Итак, как я уже упомянул выше, для эффективной работы служба технической поддержки она должна быть многоуровневой. Управляя в данный момент проектом среднего объема (10-20 человек в команде проекта и несколько сотен клиентов по всему миру), я использовал разделение службы поддержки на три уровня. Вы можете видеть эти уровни на диаграмме.
|
| Условные обозначения
|
| - Клиенты
|
| - Региональные офисы поддержки
|
| - Центральный офис поддержки
|
| - Команда разработки |
На первом уровне, самом близком к клиентам, находятся региональные офисы поддержки, обслуживающие своих локальных клиентов. На втором находится центральный офис поддержки и на третьем, самом последнем уровне, находится команда разработки. Причем, центральный офис поддержки находится в непосредственной близости от команды разработки, составляя с ней единое целое.
Рассмотрим вопросы, связанные с функционированием каждого из этих уровней.
Региональный уровень.
Первый (региональный) уровень необходим по нескольким причинам:
- Сотрудники региональных офисов хорошо знакомы с местной спецификой работы, культурными и языковыми особенностями и т.п. Это является очень важным моментом, особенно когда региональные офисы находятся в разных странах или обеспечивают поддержку на разных языках. Плохое знание местных нюансов делового общения, которое могут демонстрировать сотрудники центрального офиса поддержки, может отрицательно сказаться на имидже продукта и компании.
- Сотрудники регионального офиса работают в том же часовом поясе, что и клиенты. В этом случае вам не придется держать круглосуточный штат сотрудников в центральном офисе.
- Сотрудники регионального офиса обладают возможностью выезда или длительных телефонных переговоров, что часто бывает невозможно для сотрудников центрального офиса.
- Сотрудники регионального офиса способны быстро отреагировать на типичные затруднения клиентов, которые, в большинстве своем, связаны с вопросами по использованию продукта, а не с проблемами в его работе. Тем самым региональный офис позволяет существенно разгрузить работу центрального офиса, взяв на себя основной поток простых вопросов.
- Клиентам удобней работать с местной службой поддержки, так как в этом случае они ощущают большую заботу о себе со стороны компании, особенно если они имеют личного регионального менеджера.
Таким образом, региональные офисы поддержки берут на себя основную нагрузку по работе с пользователями. Они отвечают на основные вопросы, разъясняют особенности использования продукта и т.д.
Однако, в работе региональных офисов существует ряд сложностей, на которые необходимо обратить внимание.
- Квалификация сотрудников. Это проблема, пожалуй, основная. Не имея соответствующей подготовки, местные сотрудники могут сами быть недостаточно осведомлены о продукте, могут не знать всех его особенностей. Это может приводить к тому, что они будут давать неверные ответы клиентами или же просто служить передаточным звеном между клиентов и центральным офисов поддержки. И то и другое отрицательным образом сказывается на процессе поддержки. В первом случае клиенты получают неверную информацию, во втором случае излишне нагружается центральный офис, а региональный офис не выполняет свою основную функцию. Для решения этой проблемы я рекомендую предварительное обучение и стажировку сотрудников региональных офисов в центральном офисе, даже если они находятся в разных странах.
- Оторванность от процесса разработки. Поскольку в любом продукте происходят изменения, а клиенты получают обновления этих продуктов, может создаться такая ситуация, при которой сотрудники региональной службы будут не в курсе последних обновлений в продукте. Для решения такой проблемы необходимо уведомление всех сотрудников всех офисов поддержки списком изменений при каждом новом выпуске продукта. При этом, чем более детальной будет информация об обновлении, тем лучше.
- Неспособность решить сложные вопросы. Эта проблема перекликается с проблемой квалификации, но имеет свою особенность. Дело в том, что вопросы, которые подаются на рассмотрение, могут быть связаны со сбоями в работе продукта, которые региональный офис решить не в состоянии. В этом случае, вопрос поступает на рассмотрение в центральный офис поддержки, а затем, возможно, в команду разработчиков, что увеличивает время решения проблемы. Однако, если продукт достаточно стабилен, то проигрыш по времени в таких случаях обычно не значителен.
В случае успешного решения всех этих проблем, работа регионального офиса достаточно эффективна и приносит ощутимый эффект. Есть еще несколько вопросов, связанных с работой региональной службы поддержки, на которые я бы хотел обратить внимание.
- Доступ к продукту. Очень часто клиенты не в состоянии четко объяснить проблему или ситуацию, которая у них происходит. Для того, чтобы понять, с чем именно столкнулся пользователь, для службы поддержки будет очень эффективно, если она будет иметь доступ к продукту и данным клиента. Конечно, здесь возникает вопрос конфиденциальности клиентских данных, но если это не является проблемой или если этот вопрос решен, например, юридически, то предоставление доступа для службы поддержки весьма оправдано. Например, если речь идет о предоставляемой интернет-системе, то служба поддержки должна иметь возможность получить в нее доступ и проанализировать какие действия пользователь совершал и в чем состоит его затруднение. Это также необходимо и для того, чтобы предоставить полные объем информации в центральный офис, если возникнет такая необходимость. Центральный офис и команда разработки могут ощущать такой же недостаток информации, описывающей проблему, поэтому, имея подобный доступ, региональные сотрудники смогут собрать такую информацию.
- Протоколирование всех действий и изменений. Для работы службы поддержки будет очень полезно, если продукт будет обладать возможностью протоколирования всех действий и всех изменений, совершаемых пользователями, либо самими сотрудниками службы. Особенно это важно, когда продукт используется для управления какими-либо данными, содержащимися у клиента. Кроме того, если продукт предоставляет возможность автоматизированного управления такими данными, то все эти изменения, а также их причины, также должны быть запротоколированы. Наличие подобных протоколов позволяет решить сразу несколько проблем:
- Сотрудники службы поддержки могут точнее проанализировать какие именно действия совершал пользователь до того, как у него возникла некоторая ситуация. Если продукт предоставляет возможность автоматизированного управления пользовательскими данными, то такие протоколы смогут показать изменения сделанные в автоматическом режиме.
- Протоколы могут использоваться в качестве доказательства того, что какие-либо изменения были совершены самим пользователем, либо же продуктом. Периодически возникает ситуация, когда необходимо выяснить, кто именно внес те или иные изменения и почему. Такие протоколы позволяют решить эту проблему.
- Протоколы могут дать возможность восстановления ошибочно измененных данных, если такие изменения были внесены пользователями или продуктом.
- Ведение базы запросов. Весьма полезно, если в региональной службе поддержки будет организована база задаваемых вопросов. Такая база позволит сохранить информацию о том, какие вопросы задавались различными клиентами и какие ответы были на них получены. Здесь также будет известно кто именно отвечал на вопрос и сколько времени это потребовало. В последствии эта информация может служить для анализа того, сколько и какие именно вопросы задает каждый клиент, какие вопросы обрабатывает каждый специалист службы, оценить общий объем и эффективность работы офиса и т.п. Также эта база может использоваться для списка часто задаваемых вопросов или для анализа удобства работы с продуктом и качества продукта. Идеально, если база вопросов будет общей для всех офисов поддержки всех уровней.
Центральный офис.
Центральный офис является промежуточным звеном между региональными офисами и командой проекта. Этот офис необходим для решения следующих задач:
- Оградить команду проекта от потока вопросов региональных офисов. Не смотря на то, что вопросы, поступающие от региональных офисов, могут требовать непосредственного вмешательства команды разработки, практика оказывает, что большинство из них все-таки могут быть решены на уровне поддержки. Такие вопросы могут быть связаны, например, с особенностями внутренних алгоритмов работы продукта.
- Упорядочить поток вопросов, которые все же требуют участия разработчиков. При наличии непосредственного доступа регионального уровня поддержки к команде разработки есть риск того, что команда разработки будет вынуждена постоянно отвлекаться на решение их вопросов, что отрицательно скажется на производственном процессе. Для решения такой проблемы предназначен центральный офис, который организует упорядоченный процесс обращения к команде проекта.
- Работа с особыми клиентами. Некоторые клиенты, которые обладают особыми привилегиями, могут иметь доступ непосредственно к центральному офису поддержки, минуя региональный уровень. Это может быть связано, например, с выполнением ряда дополнительных задач непосредственно для данного клиента. Такой доступ позволит им быстрее получать ответы на свои специфические вопросы, так как центральный офис находится в непосредственной близости от команды разработчиков. Однако, в общем случае, такого подхода стоит избегать.
- Подготовка и рассылка описаний обновлений. При каждом выпуске обновлений продукта, центральный офис поддержки должен подготавливать и рассылать во все региональные офисы подробное описание всех изменений, проведенных в продукте. Он также должен оказывать консультации сотрудникам региональных офисов и особо важных клиентов по сути проведенных изменений.
Так же, как и офис регионального уровня, центральный офис должен обладать централизованной базой вопросов и проводить ее анализ. Кроме того, центральный офис должен иметь доступ к документам производственного процесса команды разработки – к базе ошибок, планам проекта, планам выпусков и т.п. Это позволит им наладить эффективную работу с командой разработчиков.
Проблемы, которые могут возникать в данном офисе, в большинстве своем аналогичны проблемам регионального уровня – это квалификация, излишнее вовлечение команды разработки, оторванность от процесса разработки и т.п. Однако, в общем случае, эти проблемы меньше проявляются, так как, еще раз повторюсь, этот отдел находится в непосредственной близости от команды разработки.
Команда проекта.
Команда проекта, насколько это возможно, должна быть ограничена от общения с клиентами по поводу возникающих у них вопросов. В большинстве случаев клиентам нравится иметь непосредственный доступ к команде разработки, так как это дает им возможность влиять на разрабатываемую функциональность и быстро получать ответы по их конкретным ситуациям. Однако, несмотря на это, такой способ коммуникаций отвлекает разработчиков от их основных задач и крайне отрицательно сказывается на процессе разработки. Поэтому, команда разработки должна проявить некоторую твердость в этом вопросе и даже при поступлении вопросов от важных клиентов не принимать их к рассмотрению, а направлять в соответствующий офис поддержки.
Задачи, которые должна выполнять команда проекта для обеспечения процесса поддержки, следующие:
- Предоставить центральному офису доступ к документам, позволяющим сформировать описание изменений, протекающих в проекте.
- Обеспечить уведомление сотрудников центрального офиса поддержки о результатах решения вопросов, поступивших от них.
- Обеспечить центральному офису помощь в решении тех вопросов, которые требуют вмешательства разработчиков.
Обобщение
На следующей диаграмме показано как уменьшается поток вопросов от клиентов до команды разработки.
Основная задача такой организации – минимизировать нагрузку на команду разработчиков и позволить клиентам получать поддержку как можно быстрее. Цветом на диаграмме обозначено, насколько желательными должны быть коммуникации по поддержке. Зеленым выделен региональный уровень – здесь коммуникации являются наиболее желательными. Желтым цветом – уровень центрального офиса поддержки – к нему должны поступать только сложные вопросы. Красным цветом – команда разработчиков – к ней проблемы поддержки должны поступать в исключительных случаях. Все это позволяет распределить нагрузку по поддержке клиентов оптимальным образом.
Я с радостью рассмотрю любые комментарии и вопросы по данной тематике.
Мои координаты доступны на сайте www.msmirnov.ru
Михаил Смирнов
Руководитель проектов. April 16 Общаясь с коллегами по цеху их разных компаниях, я замечаю, насколько разные понятия вкладываются в слова "Руководитель проектов".
Где-то считают что это тоже самое, что самый опытный разработчик и требует от своих руководителей проектов наилучшего знания технологий. Где-то наоборот, считают, что руководитель не должен иметь отношения к разработке и если он имеет к ней отношение, то считают это минусом.
Где-то с презрением в голосе говорят о "каких-нибудь RUP или MSF" и считают, что использование методик - это ничегонеделание (или руко-водство). Где-то наоборот, желают говорить исключительно об организации процесса, и никак не об "низкоуровневых" вещах.
Замечаю, что первая точка зрения больше присуща мелким компаниям и проектам, а вторая - крупным. Первая в основном преобладает там, где нет промышленного производства ПО, где ИТ выполняет роль, поддерживающую основной бизнес. В компаниях, ориентированных исключительно на ИТ, имеет место вторая позиция. March 17
Управление ошибками на практике
В этой статье я расскажу о своем опыте внедрения формализованного процесса управления ошибками.
Основная задача статьи – показать важность организации такого процесса и дать начинающим руководителям разработки набор рекомендаций по его построению.
Обычно потребность в формализованном процессе управления ошибками не возникает при выполнении небольших проектов. Проект длительностью в 1-2 человеко-месяца вполне может обойтись и без него.
Однако проекты большего объема, особенно если продукт развивается постоянно, нуждаются в подобном процессе. Начиная с некоторого момента, отсутствие формализации в управлении ошибками начинает существенно влиять на ход разработки.
В данный момент я руковожу проектом, штат которого с течением времени вырос от 2 человек до 12 человек. В начале, когда основными работами по проекту была разработка концепции и архитектуры, в формализованном подходе к управлению ошибками не было необходимости. Затем, на фазе кодирования, он стал необходим. Именно на эту фазу приходится наибольший объем кодирования и тестирования, и именно поэтому необходимость управления ошибками становится столь очевидной.
В фазе кодирования стало ясно, что отсутствие формализованного подхода приводит к следующим проблемам:
- Разработчики начинают забывать об ошибках. Такое часто бывает, если ошибок достаточно много. Двигаясь вперед, устраняя эти ошибки, он может пропустить некоторые из них, посчитав их низкоприоритетными, а потом забыть к ним вернуться.
- Тестировщики забывают проверять качество устранения ошибок. Если разработчик исправил ошибку и попросил тестировщика проверить это, то, во-первых, тестировщик уже может не помнить, в чем она состояла (или забыть детали) и, во-вторых, также может забыть выполнить проверку, переключившись на ошибки других разработчиков.
- Разработчики устраняют ошибки «не в том порядке». Довольно часто такое может быть, когда разработчику хочется устранять не те ошибки, которые являются важными с точки зрения заказчика или руководителя проекта. Если в команде мало разработчиков (1-2), то, в принципе, они могут напрямую контактировать с пользователями, чтобы выяснять приоритет ошибок, но даже в этом случае они могут не знать всей полноты картины.
- Руководитель не знает, сколько ошибок ждут устранения, и сколько исправлено. Очевидно, что если информация об ошибках поступает в устном виде, то очень трудно отследить прогресс их устранения. Руководителю проекта в такой ситуации очень трудно понять, что происходит. Ему неизвестно, сколько еще ошибок ждут своей очереди, какие из них являются важными, а какие – нет, какие из них можно отложить, а каким надо уделить первоочередное внимание.
Внедрение формализованного процесса помогло решить подобные проблемы.
Основными участниками такого процесса являются:
- Тестировщик.
- Руководитель команды.
- Разработчики.
Проще всего описать процесс управления ошибками через последовательность действий, выполняемых над ошибкой в рамках такого процесса.
| Шаг
| Участник
| Действие
| Результат
|
| 1.
| Тестировщик
| Обнаруживает ошибку и вносит ее в систему управления ошибками.
|
|
| 1.
| Заказчик или пользователь.
| Сообщает об ошибке и вносит ее в систему управления ошибками.
|
|
| 1.
| Разработчик
| Замечает ошибку у себя или у другого разработчика и вносит ее в систему управления ошибками.
| Ошибка внесена в систему управления ошибками.
|
| 2.
| Руководитель команды и иногда тестировщик
| Определяет приоритет ошибки и назначает разработчика, ответственного за ее устранение.
| Ошибка поступает к разработчику.
|
| 3.
| Разработчик
| Устраняет ошибку и помечает ее как исправленную.
| Ошибка поступает к тестировщику на проверку.
|
| 4
| Тестировщик
| Проверяет правильность устранения ошибки и, если ошибка не устранена или устранена неверно, то вновь направляет ее к разработчику, а если все в порядке, то закрывает ошибку.
| Ошибка прекращает свое существование или отправляется на повторную доработку. |
Здесь видно, как ошибка от обнаружения до устранения переходит от одного члена команды к другому.
Центральным звеном является система управления ошибками (Bug Tracking). Без нее эффективное внедрение такого процесса невозможно.
Описанные выше процесс является упрощенной моделью, в его организации могут быть изменения, например:
- Пользователи не обязательно должны сами вносить ошибки в базу. За них это могут осуществлять специалисты службы поддержки. Кроме того, сам продукт в процессе работы может автоматически вносить сообщения в базу ошибок. Это, конечно, возможно при условии, что система управления ошибками имеет API.
- Необязательно именно Team Leader должен заниматься распределением ошибок. Если команда работает достаточно тесно, то тестировщик должен знать, кто из разработчиков отвечает за компонент системы, содержащий данную конкретную ошибку. В этом случае он может самостоятельно провести назначение.
- Некоторые ошибки могут оказаться трудными для проверки тестировщиком – например, ошибки времени исполнения в Windows-сервисах. Такие ошибки можно проверять, используя unit-тестирование или привлекая других разработчиков. При unit-тестировании также может происходить автоматическое наполнение базы ошибок.
- Ошибкам не обязательно должен быть назначен ответственный за их устранение разработчик. Team Leader может посчитать некоторые ошибки несущественными и отложить их исправление на потом, пометив специальным образом.
Для организации подобного процесса следует также соблюдать следующие условия:
- Каждый отчет об ошибке должен содержать необходимый набор свойств. Это поможет всем членам команды ориентироваться в списке ошибок. Как мне кажется, следующего набора свойств достаточно для начала организации процесса:
- Приоритет – Низкий, Средний, Высокий, Критический.
- Тип ошибки – Exception, Дизайн, Неверная функциональность и т.п.
- Компонент продукта – сайт, база данных и т.п.
- Версия компонента.
- Чтобы разработчикам не требовалось тратить время на повторение ошибок, тестировщикам необходимо описывать ошибки как можно более подробно. Желательно, каждую ошибку должны сопровождать:
- Снимок экрана (если возможно).
- Информации о пользователе (например, логин для сайта), сообщившем об ошибке.
- URL, если речь идет о сайте.
- Стек, если речь идет об ошибке времени выполнения.
- Последовательность действий, приводящая к ошибке.
- Файлы отчетов об ошибках, письма пользователей, тексты ошибок и т.д.
- Необходимо заранее обеспечить каждому разработчику возможность просмотра списка ошибок, назначенных ему, а также общего списка, создав специальные отчеты и т.п. Тестировщикам следует обеспечить быстрый доступ к списку ошибок, ожидающих проверки.
- Хорошо зарекомендовала себя практика давать возможность разработчикам назначать других разработчиков ответственными за ошибки. В этом случае разработчики смогут передавать ошибки друг другу на рассмотрение, если в устранении задействовано несколько человек.
- Следует ограничить возможность разработчиков удалять или закрывать ошибки. Такое право должно быть только у тестировщика и руководителя. Это следует сделать, чтобы исключить возможность умышленного сокрытия ошибки.
- Разработчики при отметке об исправлении ошибки должны указывать время, потраченное на ее устранение. В дальнейшем это поможет получать разнообразные аналитические отчеты, например:
- процент времени, затрачиваемый на устранение ошибок;
- средние затраты времени на устранение ошибки;
- среднее время жизни ошибки.
- Если пользователи продукта хотят самостоятельно составлять отчеты об ошибках и отслеживать их устранение, то им стоит предоставить web-интерфейс системы управления ошибками. Для внутреннего использования обычно удобнее Windows-интерфейс. Поэтому при выборе системы управления ошибками стоит обратить внимание на то, чтобы она предоставляла оба способа доступа.
Подобный процесс управления ошибками очень хорошо согласуется с идеей ежедневных сборок всей системы. При этом после сборки и тестового развертывания:
- Тестировщики получают новую порцию устраненных ошибок для верификации.
- Проводя регрессионное тестирование продукта, тестировщики проверяют, не повлияло ли устранение ошибок на работу продукта. Если в работе продукта появились проблемы – помещают их в базу ошибок. Опять же это может быть автоматизировано.
- Руководитель разработчиков знает, какая порция ошибок была исправлена в текущей сборке продукта. Иногда это может служить некоторой формой отчетности перед заказчиком.
- Оценивая критичность ошибок, которые в данный момент устраняются разработчиками, их руководитель может отложить тестовую сборку до устранения этих ошибок.
При выборе системы управления ошибками (bugtracking-системы), стоит обратить внимание на следующие характеристики:
- Интерфейс. Система должна предоставлять как web-, так и windows-интерфейс. Обычно для работы внешних пользователей лучше подходит web-интерфейс, а для внутренних – windows.
- Наличие API. Используя API, вы сможете помещать новые ошибки в базу при автоматизированном тестировании.
- Возможности конфигурации. Скорее всего, ваш процесс управления ошибками будет иметь свои нюансы и будет отличаться от того, который предлагается по умолчанию системой. Поэтому системы должны предоставлять богатые возможности по настройке последовательности процесса, его шагов, прав разработчиков и т.п.
- Первоначальный опыт показал, что не стоит использовать MS Project Server в качестве подобной системы. Его предназначение состоит в управлении более объемными задачами, чем мелкие ошибки.
В этой статье я дал ряд рекомендаций по организации процесса управления ошибками. Конечно, это только схематичное описание процесса. Каждый конкретный случай, скорее всего, будет иметь существенные отличия. Однако такой подход показал свою эффективность в моем опыте управления разработкой.
Я с радостью рассмотрю любые комментарии и вопросы по данной тематике. Мои координаты доступны на сайте www.msmirnov.ru или по электронной почте msmirnov@msmirnov.ru
|
Tools 
