В этой статье я хочу поделиться опытом в формате поддержки: рассказать, как удалось построить отдел сопровождения с нуля до 70 человек, разделить его на различные направления, а также разобрать ошибки и проблемы, с которыми мы сталкивались. Отдельно расскажу про проекты и крупные сопровождения, которые заходили тяжело и проблемно, с какими ошибками мы столкнулись и какие выводы сделали на будущее: как опережать ошибки и заходить в сопровождение проще.
Что такое техническая поддержка? Мы все знаем, что это комплекс мероприятий, который обеспечивает корректность и работоспособность IT-систем как внутри компании, в которой мы работаем, так и у заказчика, которого мы сопровождаем и которому предоставляем сервис услуг.
Построение отдела: ключевые элементы
Начнем с опыта построения отдела. На что обратить внимание и во что вложить основные силы. Далее перечислю ключевые, на мой взгляд, критерии.
Регламенты и документация
С этого я всегда начинаю. Когда мы переходим к подбору персонала и найму сотрудников, должны быть дорожные карты. Когда человек выходит в отдел, мы предоставляем их либо в виде файла, либо в виде welcome-письма со ссылками на ресурсы.
В первую очередь это регламент самой технической поддержки: как мы работаем и чем пользуемся. Если есть внутренний сервис-деск, который мы предоставляем заказчику, мы описываем его и правила работы с ним. Если его нет, описываем общий порядок работы.
Далее – документация. В рамках регламентов это регламент технической поддержки и регламент доработок, то есть запросов на изменения. Здесь важна процессная схема, потому что, как правило, при начале работы с заказчиком возникает ситуация: «У нас есть большое количество доработок, возьмите их и начните делать». В этот момент начинаются стычки, недомолвки и множество вопросов. Поэтому мы стараемся заранее заходить со своим шаблоном, который затем дорабатывается под процессы заказчика.
Также важны должностные инструкции и профайлы должностей. Каждый сотрудник, работающий в отделе, должен знать свой стек обязанностей, навыков и функциональности в рамках должности. Он должен понимать, куда может расти – как горизонтально, так и вертикально, – и видеть свой профайл. Должно быть понимание грейда, в рамках которого он находится: что он может делать сейчас и как вырасти дальше.
Подбор управленческого состава
Следующий этап – подбор управленческого состава. Если брать мой опыт, на старте я как руководитель беру эту обязанность на себя и начинаю постепенно нанимать сотрудников. Либо, если есть небольшой стартовый стек, сразу происходит подбор управленческого состава. Под управленческим составом я понимаю разделение на направления: развитие систем и стандартная техническая поддержка – два отдельных блока.
Кроме того, в управленческий состав входят сервис-менеджеры. На каждый сопровождаемый проект должен быть выделен сервис-менеджер, который управляет проектом, коммуницирует с заказчиком и ведет команду. По сути, это мини-руководитель проекта, но уже в рамках сопровождения.
Найм и перевод сотрудников
Найм и перевод сотрудников – отдельная история. Мы выходим на рынок, исходя из своих потребностей, понимаем, что начинают появляться первые проекты и мы готовы. Либо нанимаем собственных сотрудников, либо сначала привлекаем подрядчиков.
Что касается перевода сотрудников, как правило, сопровождение появляется уже после этапа внедрения, когда есть команда внедренцев, которые внедряют систему у заказчика. Если внедрение прошло удачно и заказчика все устраивает, он говорит, что хочет продолжить сопровождение. В этот момент возникает спорный вопрос: сопровождение нужно, а отдельного отдела еще нет, и предлагается использовать тех же сотрудников, которые вели внедрение.
Для заказчика это удобно, потому что он уже знает этих людей и доверяет им. Но есть и обратная сторона: сопровождение по ставке обычно ниже, а сотрудники внедрения могут иметь внутреннюю ставку выше, чем продажная ставка сопровождения. Из-за этого возникают серьезные несостыковки. Бывают и ситуации, когда сотрудники из внедрения оказываются слабоваты для сложных внедренческих задач, но их можно взять в тяжелое сопровождение, где они прокачиваются и затем, уже набрав опыт, переходят обратно во внедрение, но на более легкие проекты.
Цели и показатели
Цели и показатели – обязательная точка. Каждый сотрудник должен понимать, куда он движется, какие цели и показатели ему нужно выполнять для дальнейшего роста и развития.
Мотивация
Мы поощряем сотрудников за их работу, и они должны понимать, что именно нужно выполнить и как работать, чтобы получить определенный бонус. В каждой компании система мотивации разная: где-то это денежное вознаграждение, где-то – баллы, бонусы или другие внутренние поощрения.
Структура отдела сопровождения
Перейдем к структуре отдела сопровождения. Я сделал небольшую схему того, как это выглядит. Наверху находится руководитель отдела, ниже – сервис-менеджеры, которые находятся в его подчинении. История с сервис-менеджерами обычно стартует с одного-двух человек. По мере прокачки скиллов сотрудника, в рамках целевых показателей и профайлов должностей, у него появляется дальнейшее развитие до старшего менеджера. Появляется тяжелый проект, мы понимаем, что готовы вывести туда этого сотрудника, и повышаем ему грейд.
Отдельно стоит история со стажером и менеджером. Когда отдел разрастается и проекты начинают заходить, становится понятно, что даже небольшие проекты, где задействован один аналитик, консультант или разработчик, требуют внимания. По ним нужно следить, предоставлять отчетность заказчику и проводить мини-встречи для сбора задач и планирования. Такой сотрудник может быть загружен на проект на 10–15 процентов, но, так как он стажер, мы полностью погружаем его в проект. Мы считаем его фуллтайм-сотрудником: у него низкая ставка, он не бьет бюджет, но прокачивается на небольших проектах. Следующий этап для него – рост до менеджера, который уже берет стандартные целевые проекты сопровождения.
Ниже указаны направления работы. Обычно они делятся на корпоративное сопровождение и развитие информационных систем. В корпоративном сопровождении сотрудники работают с заказчиком в формате стандартной технической поддержки: небольшие доработки, небольшое развитие системы, обновления и другие типовые задачи.
Направление развития информационных систем – отдельная история. Часто заказчик приходит с уже давно работающей, полноценной системой, но с большим пулом доработок. Ему нужно кардинально менять процессы, и здесь требуются сотрудники более высокого уровня, которые давно и продуктивно работают на проектах, понимают и уже видели, как перестраиваются процессы у заказчика. Эти сотрудники выделяются в отдельную группу. У них выше ставка, заказчик понимает, что это более опытные специалисты с большим количеством сертификатов, а их резюме содержит пул реализованных проектов. Внутри этого направления я объединил роли от младшего аналитика до ведущего. В реальности в каждом отделе это разные позиции, но здесь они объединены, чтобы не усложнять структуру.
Когда отдел уже полноценно работает, появляется идея стажерской программы. На рынке возникает дефицит специалистов, и становится сложно набирать сотрудников под сопровождение стандартных систем. Существующие сотрудники вырастают, и за низкую оплату работать никто не хочет. В этот момент запускается стажерская программа.
По моему опыту мы набирали сотрудников, которые только закончили вуз, получили диплом или еще находились в процессе защиты. В течение полугода они обучались, проходили сертификацию 1С и выходили помощниками на проекты сопровождения. Сначала они работали без оплаты, а затем постепенно начинали брать задачи на себя. Дальнейший рост строился по стандартной цепочке: младший аналитик, аналитик, ведущий.
Работа с удаленными сотрудниками
Отдельно стоит организация работы с удаленными сотрудниками. Это более сложный момент. С сотрудниками в офисе работать проще: ежедневная коммуникация, живое общение, совместные обеды. Если возникают проблемы, сотрудники подходят лично, ловят в коридоре или приходят в кабинет.
С удаленными сотрудниками я для себя зафиксировал четкие правила.
Обязательные личные встречи онлайн. Нужно регулярно собираться, проговаривать проблемы, уточнять, все ли хорошо, все ли устраивает, нет ли на проекте сложных или конфликтных ситуаций. У меня был случай, когда отдел вырос примерно до 70 человек, и я, признаюсь, забыл про одного сотрудника. Он три месяца работал на проекте, у него все было хорошо, он не появлялся в общем поле, и в какой-то момент я получил от него заявление на увольнение. На вопрос, что произошло, он ответил, что чувствует себя изолированным: он живет во Владивостоке, никто ему не пишет, никто с ним не разговаривает, и он даже не знает, как выглядят коллеги из отдела. Это стало для меня триггером, после которого регулярные личные встречи с удаленными сотрудниками стали обязательной практикой.
Вовлеченность сотрудника. Мотивация\проект\команда. Со временем я понял, что подход «бросить человека и забыть» полностью нерабочий и должен быть исключен. Я старался слушать сотрудников и подбирать им проекты. Проектов было много, и бывали ситуации, когда сотрудник приходил и говорил: «Я знаю регучет и много с ним работал, но при трудоустройстве просил сменить контур, потому что сейчас развиваюсь, например, в производстве и хочу работать именно с такими проектами». Мы это подхватывали, перераспределяли нагрузку, переставляли людей между проектами, иногда даже с негативной реакцией со стороны заказчика. В результате удавалось удержать сотрудника, который позже, в сложной ситуации, сам шел навстречу и говорил, что готов временно подхватить проект, пока мы ищем другого специалиста, потому что помнит, как к нему отнеслись и как спокойно шли навстречу при смене проекта.
Тимбилдинги – важная часть работы с командой. Неважно, где находятся сотрудники: в разных городах России или за рубежом. Важно иметь возможность собираться хотя бы раз в полгода. Если не получается раз в полгода, то хотя бы раз в год. Мы стараемся собрать команду по максимуму, всех, кто откликается, и провести общее мероприятие. Обычно я провожу опрос, кому что было бы интереснее, и исходя из этого организуется общая встреча.
Командировки также играют важную роль. Я всегда понимаю, какой сотрудник на каком проекте работает. Если это, например, московский или петербургский проект, и есть офис, куда можно приехать, я через руководителя проекта или сервис-менеджера прошу оформить командировку. Сотрудник приезжает, общается с заказчиком, а для меня это возможность лично встретиться и обсудить, все ли у него на проекте хорошо. Онлайн-общение важно, но личный контакт всегда глубже. В неформальной обстановке, за кофе или в коридоре, часто всплывают моменты, о которых в онлайне не говорят.
Человечность и субординация – базовые принципы. Я стараюсь относиться к людям с пониманием: все мы люди, и у каждого может случиться форс-мажор. В большинстве случаев, даже если ситуация произошла на важном проекте, я стараюсь найти замену, перераспределить нагрузку и отпустить человека. Это всегда работает в обратную сторону. Когда возникает сложная ситуация и нужно срочно подхватить проект, сотрудник, как правило, идет навстречу. В подавляющем большинстве случаев он отвечает: «Да, без проблем».
Отдельная тема – активность внутри компании. Я сталкивался с двумя противоположными ситуациями. В одном случае сотрудника пытаешься вовлечь в активность, а он упирается и не хочет участвовать. В другом – сотрудник, наоборот, активно предлагает выступить, что-то рассказать, а ты вынужден его притормозить, потому что тема уже обсуждалась или сейчас неактуальна. Мы это прорабатывали через опросы и ввели регулярную практику: раз в две недели проходят выступления на уровне департамента. Есть перечень тем и возможность заявиться с докладом. Если желающих нет, в целевых показателях у сотрудников появляется пункт про выступление. Я лично писал сотрудникам, что у них в показателях стоит выступление и его нужно закрыть к аттестации.
Ошибки при построении команды
Первая ошибка – это игнорирование сотрудников. Когда про человека забывают или не обращают внимания на его желание проявить себя в компании или на проекте.
Отсутствие субординации. Человечность может перерастать в дружеские отношения, и это опасно. Когда люди долго работают вместе, проходят сложные проекты, активно участвуют в тимбилдингах, а потом начинают общаться семьями и ездить вместе отдыхать, это нормально с человеческой точки зрения. Но на работе субординация должна соблюдаться жестко. Если коллеги начинают замечать, что кому-то уделяется больше внимания и проявляется симпатия, то возникают вопросы: почему одному выплатили премию, а другому нет. Здесь необходим строгий контроль.
Цели и мотивация, которые не были обсуждены. Их обязательно нужно формулировать, чтобы сотрудник понимал, куда он идет и к чему стремится.
Отсутствие должностных инструкций, профайлов и регламентов также приводит к проблемам: человек не понимает, по каким правилам он работает, за что отвечает и как может расти дальше.
Важно:
-
Помнить о своих сотрудниках и соблюдать субординацию,
-
Ставить четкие планы и цели,
-
Не забывать про мотивацию.
Каждый сотрудник должен понимать, что о нем помнят, что он развивается, что его ценят. Похвала важна, но конструктивная критика также должна присутствовать.
Как управлять сервисом при команде до 70 человек
Немного про управление командами, когда их численность превышает базовый уровень. Речь идет о проектах, где команда составляла от 30 до 70 человек и сопровождала большое количество систем у одного заказчика. С какими ошибками мы столкнулись и как их решили.
Были ситуации, когда я заходил в такие проекты, назначал сервис-менеджера, но он не справлялся. Я подключался, чтобы помочь, и видел одну и ту же картину:
-
Отсутствуют регламенты и устав проекта.
-
Статусы с командой проходят раз в неделю в формате «Все ли у вас окей?» – «Да, все нормально» – «Супер, идем дальше».
-
Не контролировались SLA-показатели, в конце месяца выставлялись штрафные санкции, в результате акт оказывался не тем, который был заложен в бюджете. Штрафные санкции сильно влияют на дальнейшую пролонгацию контракта на следующий год и на дополнительные входящие активности от заказчика.
Поэтому при запуске крупных проектов я стараюсь заходить туда сначала сам. Объем большой, и проще сначала выстроить процесс: четко прописать регламенты и все схемы работы с задачами, установить ежедневные встречи по всем блокам. На этих встречах контролируются SLA-показатели. Бывали ситуации, когда сотрудник говорил, что у него осталось шесть часов на выполнение задачи, а на следующий день на утренней встрече оказывалось, что осталось тридцать минут. На вопрос, почему задача не выполнена, ответ был простой: переключился на другую и забыл. Такой контроль позволял вывести проект из состояния неопределенности в управляемый процесс. Мы могли предоставлять заказчику полноценную отчетность, понимали, какие задачи выполнены, какие нет, по какой причине и сколько времени требуется на устранение инцидентов.
Почему так важны регламент и устав проекта. Есть личный опыт, когда мы взяли заказчика, ничего не прописали, не зафиксировали регламенты, работали на дружественных отношениях, потому что ранее сами внедряли систему. В один момент сменилось руководство, пришли новые люди и задали простой вопрос: где это зафиксировано? Где договоренности? Ответа не было. Вся конструкция рассыпалась. Дружественные отношения, на которые рассчитывали, перестали работать мгновенно.
Управление внутри отдела при масштабировании
Далее – управление внутри отдела, когда команда начинает активно расти. Что делать, чтобы ее контролировать?
Первое – назначение руководителей по специализациям, то есть тимлидов. Когда собирается группа специалистов по определенным контурам – ЗУП, оперконтур, регламентированный учет, – выбирается самый сильный и активный сотрудник. Под него собирается команда, он занимается обучением, прокачкой и подготовкой к аттестации.
Второй момент – разделение на корпоративное сопровождение и развитие информационных систем. При численности отдела около 70 человек часть сотрудников – сильные специалисты, которых можно направлять на развитие систем. Это выгоднее и для компании, и для проектов. Сотрудников, которые только начинают и еще не набрали достаточный уровень, мы направляем в корпоративное сопровождение. В каждом направлении назначаются свои руководители.
С этими руководителями мы встречаемся на еженедельной основе. Они управляют своими командами и отчитываются мне. Используются шаблоны по загрузке сотрудников: кто на каком проекте работает, насколько загружен, с какими проблемами сталкивается проект, какие цели стоят у сотрудника. Бывают ситуации, когда сотрудник загружен на 100–120 процентов, а в целях у него стоит сдача нескольких сертификатов, выступление и участие в конференции. В таких случаях мы пересматриваем цели, обсуждаем перегрузку, вызываем сотрудника и проговариваем, комфортен ли ему текущий режим. Иногда ответ бывает простой: все нормально, мне комфортно, мне нравится такой темп.
Аттестация и обратная связь
При большой численности команды появляется системная аттестация сотрудников раз в полгода. На аттестацию приходят сам сотрудник и руководитель направления. Если в направлении есть тимлиды по отдельным блокам, они также участвуют в аттестации.
Для меня, как руководителя, важно понимать, как сотрудник развивается в своем блоке, какие у него знания, что нужно прокачивать дальше и в каком направлении двигаться. Важно видеть, как он развивается на проектах, и получать обратную связь от руководителя направления. Все это дополняется оценкой по методу 360 градусов: сотрудник может дать обратную связь о своем руководителе и тимлиде, а коллеги по проектам и по отделу – дать обратную связь о самом сотруднике.
Подстройка под бизнес заказчика
Далее немного расскажу про кейсы работы с заказчиками. Важный момент, который хочу отметить, – необходимость подстраиваться под специфику бизнеса заказчика и его процессы. Были ситуации, когда мы приходили с позицией «так написано в стандартах, процесс должен быть выстроен именно так, везде говорят, что это правильно». Заказчик отвечал: «Я понимаю, что это правильно, но у нас это работать не будет, служба безопасности такой процесс не пропустит». Мы настаивали на своем, говорили, что это единственно верный вариант. В результате было много поражений, вплоть до того, что заказчик отказывался от работы и говорил, что найдет команду, которая его услышит и действительно поможет.
Из этого я сделал простой вывод: при входе в проект важно слушать и слышать заказчика. Он приходит за помощью, а не за штампованной отработкой кейсов. Часто описывают подход, при котором на типовые вопросы используются шаблоны: закинули готовый ответ – и все. На практике в большинстве случаев это не работает. Я неоднократно сталкивался с ситуацией, когда на еженедельной встрече заказчик спрашивал: «У вас там бот отвечает или кто? Мы пришли с вопросом, потому что не понимаем, как это работает, а в ответ получаем «посмотрите страницу 5 инструкции такой-то». Я посмотрел и все равно ничего не понял».
В итоге мы выстроили другой подход: дается полноценный ответ с созвоном, все подробно объясняется, дополняется скриншотами, а в конце прикладывается ссылка на документ, где это можно посмотреть. Мы полностью рассказали и объяснили, а в следующий раз заказчик уже может не ждать ответа, а сразу обратиться к материалу.
Предложение корректировок и ответственность
Предложение корректировок – еще одна важная тема. Речь не о том, чтобы прийти и сказать: «Давайте все полностью переделаем, это будет стоить сотни тысяч или миллионы, нам хорошо и вам будет классно». На практике такие предложения редко выстреливают. Чаще заказчик отвечает, что ничего переделывать не нужно.
Рабочий вариант – когда мы показываем конкретную пользу. Например, заказчик ведет два отчета в одной системе, что-то выгружает, дополнительно работает в Excel, сводит данные вручную. Мы показываем проблему и предлагаем решение: сделать единый отчет, который будет собирать все данные в одном месте. Это стоит определенных денег, но польза понятна. В таких случаях договоренности достигаются проще.
Важно всегда смотреть на шаг вперед и понимать последствия своих действий. Не стоит делать шаблонные решения, не задумываясь о том, что будет дальше. Бывали ситуации, когда задача формально закрыта, но последствия оказываются хуже исходного состояния. В итоге звучит позиция «Я свою задачу выполнил, дальше это не моя зона ответственности». Такой подход недопустим.
Единое окно поддержки
В завершение хочу отметить результат, к которому мы пришли, – единое окно поддержки. Даже если системы заказчика развернуты, например, в нашем облаке, а техническую поддержку оказывает другой отдел, для заказчика это не должно выглядеть как перекладывание ответственности. Нет истории «это не к нам, идите в поддержку». Сервис-менеджер отвечает за все целиком.
Если заказчик приходит и говорит, что у него все упало, сервис-менеджер принимает это на себя. Он сам идет к нужному подразделению, подключает облако, инфраструктуру или поддержку. Для заказчика снимается негатив, его не перекидывают между отделами. Есть единое окно, которое отвечает за весь предоставляемый сервис.
В завершение хочу сказать: при погружении в проект используйте накопленный опыт, помните, на какие грабли уже наступали. Заказчик первым скажет о своей боли – не нужно додумывать за него. Важны контроль и своевременная отчетность. Заказчики ценят прозрачную, регулярную и детализированную отчетность.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAMLEAD&CIO EVENT
Вступайте в нашу телеграмм-группу Инфостарт