Pull to refresh

Отдел поддержки: ожидание vs реальность

Reading time 7 min
Views 11K
Добрый день. Хотелось бы поведать небольшую историю, которая произошла со мной не так давно и связана как с карьерными ожиданиями, так и с ошибочным восприятием того, что происходит в реальности. Как работодатель может вводить в заблуждение или неосознанно вредить мотивации команды.

image

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

Подробности под катом.

Специально не отвлекался на вакансии трансформеры, когда компании нужен “и спец, и жнец, и на дуде игрец”(это когда человек должен и платы паять и 1С-конфигурации писать) я терпеливо ждал хорошего предложения. Через 2 месяца на меня вышел зам.начальника управления, с предложением, на которое трудно было не согласится. Направление только появилось, компания федерального масштаба, создающая отдел поддержки и разработки в регионе, планы были грандиозные и вполне соответствовали моим ожиданиям. Можно было построить команду и процессы с нуля, оптимизировать и встроить их в существующие процессы. Все называли должность с функциями «координатора\начальника Техподдержки». Что ж, я был готов в бой.

Первоначальные цели:


  1. Поддержка на первой и второй линии.
  2. Создание базы знаний
  3. Создание документации пользователей
  4. Вникнуть в бизнес-процесс для осуществления “бизнес консультаций”
  5. Подготовить регламент взаимодействий подразделений в рамках методологии ITIL Service Desk(планировал взять оттуда только процесс прохождения заявок и инцидентов + написание SLA, потому как знаю, что в тупую внедрять полностью формализованный процесс никто не даст, да и это не заработает)
  6. Нанять сотрудников поддержки.

Создание документации


Что хотелось: Так как поддерживать предстояло купленную информационную систему, а я раньше больше имел дело с аппаратной инфраструктурой, я решил входить в курс дела постепенно и с той стороны, какая была для меня самой очевидной – я попросил регламенты процессов, автоматизируемых системой, и документацию к ней. И столкнулся с первым сюрпризом – документации у купленной за “деньги” системы не было. Были набросанные компанией-разработчиком на коленке слайды, как определённые роли участвуют в процессе и на этом всё. У компании было ещё 4 месяца поддержки по договору, когда к ним можно было обращаться с вопросами по работе системы. Внутреннего проекта по внедрению системы не было, сроки устанавливались соглашением и excel-документом, в котором были указаны сроки внедрения определённых доработок. Да, после моего найма система дописывалась ещё 5 месяцев.

Что получилось: С грехом пополам, описаны несколько процессов в виде схем Visio. Частично описаны модули системы. Из-за срыва сроков коммуникация с разработчиками купленной системы стала ещё хуже. Насколько я понял, обязательность документации при покупке не оговаривалась.

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

Создание базы знаний


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

Что получилось: Создан документ, позволяющий покрывать первоначальный объем бизнес-консультаций. Порядок работы с бизнесом регламентировать не удалось. На новый вопрос «не из списка» бизнес мог забыть ответить. Приходилось повторно запрашивать, держа на контроле. На базе docuwiki создана база знаний с описанием вопросов, архитектуры системы, основных действий второй линии поддержки и администраторов. Не получилось описать настройку создания нового продукта в системе, т. к. он создавался полупрограммируемым способом и описывать надо было совместно с программистами.

Вывод: Создавать базу знаний жертвуя лояльностью клиента неправильный шаг. Если бизнес на это идет, то на поддержку ложится дополнительная нагрузка в виде оправданий недоработок и сдерживания дополнительного негатива клиентов.

Подбор персонала


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

Таблица компетенций первой линии:

image

Данный шаблон был отправлен на согласование с руководством, но отклика «применять-не применять» не вернулось.

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

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

Вывод: готовьте для нового замотивированного сотрудника объем работы. Иначе это плохо влияет на лояльность к работодателю и к системе. Понимайте процесс мотивации персонала — как материальный, так и не материальный.

Процесс работы


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

Что получилось: После очередного указания на проблемы руководству оно все-таки дало разрешение на внесение правок и поток звонков уменьшился втрое.

Вывод: налаживайте процесс приоритизации задач, обсуждая порядок взаимодействия с группой разработки.

Сталкиваясь с каждой из вышеназванных задач я каждый раз приходил к руководству с предложениями оптимизации процессов и попыткой скоординировать своё видение с видением компании, но всегда натыкался или на занятость руководителя(системная проблема) или получал ответ «пока так» и «мы не хотим излишней формализации». Также я знал, что планируется расширение отдела до 5 человек и видел, что надо понять как будет происходить управление процессом поддержки и ресурсами. Я уже начал подозревать, что начальство изменило планы насчёт меня из-за моих постоянных попыток внедрить изменения. Меня уже не называли координатором или начальником, я не участвовал в митингах, связанных с развитием системы.

image

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

Вывод: Проанализируйте стратегию подразделения. Определите краткосрочные и долгосрочные планы. Обсудите видение с руководством.

Вторая часть «марлезонского балета»


После вышеописанного эпизода со мной практически прекратил общаться прямой начальник. И я начал подумывать об уходе. Изначально я видел интересный проект, который после преодоления определённых трудностей при правильном взаимодействии всех участников процесса можно было успешно завершить, получив крепкий мотивированный отдел поддержки с правильными KPI и с чёткими показателями на выходе, понятными безнесу. Сейчас же, я увидел, что отдел сваливается в рутину еще толком не развившись. В приоритете стали две задачи — ответы на звонки и описание багов(не доработок) системы посредством gitlab, которые исправляли разработчики.
Отдельная история — процесс «тестирования», как его называл руководитель, который тоже предлагалось выполнять нам. Понимания этих процедур ни у кого не было, как и отдельного тестировщика. Функциональное тестирование «черного ящика» без каких-либо показателей эффективности всей командой перед релизом. Никаких других методов не применялось. Набранный персонал не мог эффективно участвовать в тестировании из-за нехватки как бэкграунда в сфере разработки, так и из-за отсутствия процесса обучения. Даты релизов постоянно фейлились или релизы выкатывались без тестирования.

Вывод: отдел не может эффективно заниматься двумя крупными процессами параллельно. Будет два процесса идущих кое-как.

Конфронтация продолжалась. Руководитель умудрился зафейлить все элементы менеджмента, которые я считал важным:

  1. стратегическое видение
  2. контроль
  3. управление
  4. мотивация

Также были озвучены такие волшебные пункты, как «лояльность к компании в виде прихода на работу раньше и ухода позже»

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

Что получилось: опыт, опыт и еще раз опыт.

Вывод: Какие ошибки я для себя зафиксировал:

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


Также хотелось бы услышать от коллег ваши истории внедрения и нюансы, на которые я, по неопытности, не обратил внимания.
Tags:
Hubs:
+10
Comments 51
Comments Comments 51

Articles