Отсутствие выделенных групп поддержки — каковы преимущества?

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

А теперь представьте, что выделенной команды по эксплуатации/поддержке нет. Есть ли в этом смысл, и какие преимущества это может обеспечить? Своим опытом делятся соотечественники нашего финского друга Аале Рооса. Они пришли к выводу, что очень важно, чтобы вся команда разработки также занималась бы и поддержкой, и вот почему:

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

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

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

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

Впереди у ребят из Хельсинки, судя по всему, реагирование на вызовы и решение проблем, связанных с ростом числа обращений. Если их обработка станет занимать довольно много времени, стоит ли организовывать первую линию? Готового рецепта у них пока нет, скорее всего, это будет какой-то гибрид. А вот какой — обещали поделиться в своём блоге.

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Operational Support and Analysis

Учебный курс: эксплуатация и поддержка ИТ-услуг, Service Desk, инциденты, проблемы, операции и запросы пользователей — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Вячеслав

    Как мне видится, это соответствует модели, которую в некоторых источниках называют "Центрами компетенций".

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

    Безусловно этот подход даёт большие плюсы с точки зрения user experience, и service evolution.

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

    Прекрасно, когда удаётся совместить плюсы от обоих подходов

  2. Алексей

    Для маленькой компании и нескольких клиентов это выглядит вполне рабочим вариантом.

    А если разработчиков 50 человек (с тестерами), продукт (состоящий из 3 независимых частей, объединенных в одно целое, но работают разные команды в разработке) выпускается раз в квартал (новый релиз, не считая патчей), только инженеров внедрения и поддержи более 50 человек, и разных крупных клиентов 40+, не считая мелочи, и у каждого своя версия, и далеко не самая новая, то не совсем понятно, как можно вовлечь разработчиков в каждую проектную группу на постоянной основе для поддержки?   

    Если их как минимум 6 типов (по разработчику и тестеру на каждый участок системы, коих 3), а проектных команд 10, в каждой из которых несколько клиентов на внедрении/поддержке. Тут их не хватает даже на всех 🙂 

  3. Alexey Krasheninnikov

    К вопросу о "маленькой компании и нескольких клиентах":

    — По пути вовлечения разработчиков сервиса непосредственно в его поддержку пошел Microsoft в своих облачных сервисах Office365

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

АВГ
28