Многим нашим читателям знакома проблема взаимодействия команд разработки и эксплуатации. Зачастую, задача первых сводится к пропихиванию созданного решения в продуктивную среду, чтобы успеть к дедлайну проекта. Вторые, естественно, сопротивляются, поскольку им с "этим" жить, а "это", к сожалению, не полностью задокументировано, не оттестировано, не всегда совместимо с боевым окружением, не очень-то и производительно и т.д. Проблема решаема – командам эксплуатации нужно подключаться на этапе проектирования, где закладывать эксплуатационые требования, и в ходе разработки следить за претворением их в жизнь.
А теперь представьте, что выделенной команды по эксплуатации/поддержке нет. Есть ли в этом смысл, и какие преимущества это может обеспечить? Своим опытом делятся соотечественники нашего финского друга Аале Рооса. Они пришли к выводу, что очень важно, чтобы вся команда разработки также занималась бы и поддержкой, и вот почему:
1. Ощущение потребностей пользователей.
Когда вся команда не только разрабатывает, но и поддерживает пользователей, возникает удивительный полезный эффект – общее понимание. Споры о том, что нужно реализовать в следующей версии, возникают редко, поскольку вся команду уже просто знает, какие функции наиболее востребованы пользователями.
2. Прямой контакт.
При возникновении проблемы по какой-либо функции пользователь решает её непосредственно с экспертами – теми людьми, кто, собственно, эти функции разрабатывал. В этом случае обычно отсутствует делегирование, переназначение. Отзывы показывают, что пользователям это очень нравится.
3. Чат как система багтрекинга.
Много копий сломано в спорах о необходимости иметь отдельную систему багтрекинга. Можно сказать, что её ценность со временем уменьшается – количество багов растёт, выбирать среди них те важные, что нужно исправлять в первую очередь и прямо сейчас, становится проблематично. Поскольку команда разработки является и командой поддержки, сообщения от пользователей об ошибках, пришедшие, например, в твиттере, сразу же рассматриваются, классифицируются, приоритизируются. В общем потоке обращений от пользователей сообщения, имеющие признак "баг", видны команде всегда.
4. Перевод обращений в другую группу – плохой тон.
Если вы выстраиваете систему поддержки пользователей таким образом, что предусматриваете в ней возможность перевода обращений, то вы закладываете фундамент для разочарования пользователей. В дополнение ко времени ожидания решения каждое переназначение разрушает чувство взаимного доверия и симпатии, которое возникло шаг за шагом, постепенно между пользователем и сотрудником, оказывающим поддержку. Конечно, бывает, что без переназначения не обойтись. Но можно, например, договориться о том, что тот, кто переназначает обращение, находит того, кто возьмётся за решение вопроса целиком.
Впереди у ребят из Хельсинки, судя по всему, реагирование на вызовы и решение проблем, связанных с ростом числа обращений. Если их обработка станет занимать довольно много времени, стоит ли организовывать первую линию? Готового рецепта у них пока нет, скорее всего, это будет какой-то гибрид. А вот какой – обещали поделиться в своём блоге.
Как мне видится, это соответствует модели, которую в некоторых источниках называют "Центрами компетенций".
Имея наблюдения за обоими подходами одновременно, видно что есть как пллюсы, так и минусы.
Безусловно этот подход даёт большие плюсы с точки зрения user experience, и service evolution.
С другой стороны может начать давать сбои в случае кросс-функциональных проблем. А так же грозит размытием понимания у пользователей входной точки для обращений.
Прекрасно, когда удаётся совместить плюсы от обоих подходов