Как управлять инфраструктурными проектами против службы поддержки

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

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

• Создание хорошей документации для пользователей занимает много времени, но в долгосрочной перспективе вы сэкономите гораздо больше времени, особенно в разделах самостоятельной поддержки.
• Если у вас есть хорошая документация, создайте шаблоны для ответа на почту со ссылками на указанную информацию.
• То же самое относится и к телефонным звонкам: вместо того, чтобы идти по шагам звонящего, скажите ему, что вы отправите ему ссылку по почте. Сделай так.
• Если у вас его еще нет, настройте систему заявок на устранение неисправностей, такую ​​как RT или OTRS. Это поможет вам отслеживать ваши запросы поддержки и будет отправлять письма с подтверждением. Это хорошо для пользователей, потому что они знают, что их проблемы будут решены, даже если вы не ответите немедленно. Это также может помочь вам получить представление об общих проблемах с настройкой и о том, где вы можете улучшить документацию. Это также поможет вам документировать свою рабочую нагрузку для ваших начальников.
• Создайте политику о том, какие действительные запросы поддержки, и очистите это со своими боссами. Обеспечить соблюдение этой политики. Это облегчает отклонение запросов на помощь пользователям домашних линий DSL или настройке iTunes и т. Д.
• Создайте временные блоки "без звонков", в которых вы не обрабатываете поддержку, кроме как в реальных срочных случаях. Это должно быть частью вашей политики и строго соблюдаться. Опять же, вы, боссы, должны поддержать вас в этом.

Как я уже сказал, это всего лишь несколько случайных советов. Гораздо больше невероятных полезных советов вы получите от Тима Лимончелли и его книг "Практика системного и сетевого администрирования и управление временем для системных администраторов". Особенно первое, что нужно прочитать.

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

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

Судя по звукам, картина будет крайне безобразной. Это именно то, что вы хотите, потому что тогда пришло время сказать своему боссу: "Ну, если вы хотите, чтобы я доставлял больше, тогда мне нужно больше ресурсов. Конечно, если у ИТ не может быть больше ресурсов, тогда мы будем следовать ваши приоритеты, а это означает, что весь конец списка никогда не будет сделано ".

А теперь к вопросу о балансе между службой поддержки и инфраструктурными проектами: в любой инженерной дисциплине (и ИТ ничем не отличается от этого) есть хорошо проверенный девиз: исправляйте свои проблемы дважды.
Сначала вы решаете проблему, которая обычно является признаком того, что что-то не так. Это гарантирует, что пользователь счастлив и уходит.
Затем вы устраняете основную причину проблемы. Это гарантирует, что симптомы не вернутся.

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

Тайм-менеджмент и планирование являются ключевыми здесь. Раньше я просто выделял несколько часов каждый день для работы с HD (обычно днем, потому что тогда легче отправлять пользователей со своих ноутбуков на техническое обслуживание) и несколько часов каждый день или неделю для инфраструктуры, проектов, тестирования новых интересных способов. делать что-то и т. д.

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

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

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

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

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

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