В предыдущей статье я рассказывал о том, как построить сервис и не наделать ошибок. Тема, конечно, объемная и многогранная. И много вопросов получил о том, что же такое сервисное мышление. Я думаю, «сервисность» в той или иной степени есть в каждом из нас. И если удается ее распознать, например, в инженере, то можно выстроить дальнейшую работу так, что все стороны – и заказчик, и работодатель, и сам специалист – будут получать и положительный результат, и удовольствие от работы. О том, как это сделать, я постарался рассказать с точки зрения своего управленческого опыта.



Прошу в детали.

Разберемся с понятиями

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

Проект – целенаправленное изменение, проводимое в четко поставленные сроки (это если очень кратко, чтоб не нудить).

Сервис – деятельность, позволяющая клиенту полноценно эксплуатировать некое ранее реализованное техническое решение.

Другими словами, в проекте мы должны доехать из точки А в точку В в определенный срок, а в рамках сервиса мы должны ехать из точки А в точку В с заданной скоростью.

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

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

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

Работа в сервисе. Быть или не быть

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

Итак, ни для кого не секрет, что большинство инженеров начинают свой путь из службы техподдержки. Тут «качать» людей гораздо легче, деление задач на простые и сложные очевидно, плюс есть возможность работать на старших курсах института, не отрываясь от учебы. А через год-два будущий профи оказывается перед выбором: остаться в сервисе или сделать шаг в сторону. И то и другое решение может принести пользу и компании-работодателю, и самому выбирающему. На мой взгляд, в большинстве случаев, этот выбор можно спрогнозировать и подготовиться к нему. Как правило, за год-два в хорошем коллективе, в котором работа с молодежью поставлена на поток, «сервисность» проявляется и взращивается сама собой. И, в большинстве случаев, молодое дарование смотрит в сторону перехода из первой линии поддержки во вторую в рамках той же команды.

Но есть и другой, не то чтобы редкий пример: осознал начинающий инженер, что не хочет он больше заниматься поддержкой, а видит себя разработчиком. Начинаем общаться. Как правило, оказывается, что если нежелание еще хоть чем-то подкреплено (причем, как правило, субъективно), то понимание того, чем хочется заниматься дальше, взято с потолка и приправлено большой порцией романтизации (про обязательность рутины в любой профессии, по молодости, думать не хочется). Вопрос – удерживать или нет такого инженера в сервисе? Если удерживать, то как? А если отпускать, то куда и как ему помочь? Уверен, что все мы понимаем ценность сохранения хороших отношений даже при уходе кого-то из команды. И вот тут важно понимать, заточен ли (заточился ли за год-два) человек под сервис, будет ли ему комфортно в другой области или нужно придумать под него новую нишу. Причем разбираться в момент, когда выбор сделан, иногда уже поздно. А вот желание и умение руководителя предвосхитить ситуацию и отклик найдет, и позволит сохранить хорошие отношения, и наверняка приведет к гораздо более осознанному выбору сотрудника.

Признаки «сервисности»

Итак, как же распознать «сервисность»?

Шаг первый – собеседование. Смотрим, как кандидат зашел, как сел, подвинулся ли, чтобы всем в комнате было удобно и т.п. Зачастую сразу понятно, что человек не просто вежливый, а думает о других, не теряя собственного достоинства. Дальше вопросы-ответы. В разговоре про хобби, опыт турпоходов – хороший признак, в командных видах спорта позиция в защите или полузащите — тоже близко. В профессиональных вопросах такие люди, обычно, очень тщательно выясняют, что их ждет (как в сервисе – нужно заранее проработать массу потенциальных рисков), какие задачи предстоит решать. Когда рассказывают о своем опыте, делают акцент на решении проблем в процессе выполнения тех или иных работ, а не о результате проекта. Многих за такой подход «фильтруют» на этапе анализа резюме, а зря. Я сталкивался с ситуациями, когда резюме было написано в стиле классического «достигатора», а на практике человек оказывался вполне себе сервисным. На вопрос «зачем?» звучал ответ, что иначе не получалось пробиться через первичный анализ, поменял акценты в резюме – сразу позвали на собеседование. К сожалению, это реалии нашего времени. На что еще обратить внимание – кандидат может интересоваться атмосферой в коллективе, может, рассказывая о том, от чего получает наибольшее удовольствие в работе, рассказать о довольных заказчиках. Это далеко не все признаки, идеальный рецепт дать трудно. Вот пишу, и в голове нет-нет да и возникает образ исключения из реальной жизни.

Шаг второй – текущая работа. Тут уже чуть проще отличить нацеленность на результат любой ценой и желание сделать хорошо для заказчика. И то, и другое нужно в меру. Просто в сервисе тем, кто ориентирован на конечный результат, нужно в списке задач подсвечивать важность удовлетворенности заказчиков, а тем, кто ориентирован на процесс – риски оказания бесплатных услуг. Другой триггер: нежелание уходить с работы, пока текущая задача не будет завершена или переведена в стабильное состояние. Тут имеет смысл убедиться, что это не проблема с управлением временем, а корневая причина именно в желании не оставлять на завтра проблему, которая может усугубиться. Еще признак, на который можно обратить внимание – погружение в детали. Чем больше сервиса в мозгу у инженера, тем больше он будет просчитывать возможные сценарии «что если». Важно отличить врожденное занудство (что тоже не плохо) от желания просчитать варианты негативных сценариев. Есть еще масса признаков, но все они сводятся к тому, что «сервисность» идет рука об руку с ожиданием (не просто с готовностью, а именно с ожиданием), что что-то пойдет не так.



Капитан Зеленый и м/ф «Тайны третьей планеты». Помните такого?)

Еще вариант определения «сервисности» – тимбилдинги. Я в эти мероприятия, как способ объединения команды, не особо верю, но полезную информацию из них вынести можно. Если вдруг совместный выезд, например на шашлыки, то тут сразу будет понятно, кто готов помочь, кто готов организовать, ну дальше вы поняли. Опять-таки то, что кто-то хочет жарить мясо, кто-то без напоминания накрывает на стол, вовсе не означает, что остальные «какие-то не те». Кто-то здорово умеет увлечь за собой, чем бы он ни был занят, кто-то здорово координирует остальных и так далее. Просто все мы хороши в разных вещах и, соответственно, ко всем нам нужен разный подход.

Как использовать

Теперь назревает резонный вопрос. Вот набрали мы или осознали, что у нас в команде есть несколько таких сервисно мыслящих коллег. И что нам теперь с этой информацией делать?

Вариантов масса:
Можно безбоязненно поручать им самостоятельные задачи, можно быть уверенным, что рутинные или регулярные работы будут выполнены ими без излишнего негатива. А вот с проектами в условиях сжатых сроков и отсутствия информации, если речь не про аварийно-восстановительные работы, я был бы осторожен. Сроки точно соблюсти не получится.
В идеале, при формировании проектных команд хорошо бы включать в состав хотя бы одного такого сервисного человека, который будет несколько сдерживать креатив и безоглядность, а в сервисную команду хорошо срабатывает добавление координатора, нацеленного на достижение результата. Понятно, что командообразование – сложный и очень ответственный процесс. Одно неверное действие, например неправильно введенный в команду игрок, и можно получить массу конфликтов на пустом месте. Но если руководитель все сделал правильно, то результат порадует всех участников. Остается правильно поставить задачу.

Как ставить задачи

В любой обслуживаемой системе рано или поздно требуется что-то поменять. Конечно, это стресс и для системы, и для тех, кто ее обслуживает. Не случайно управление изменениями в практиках управления IT – один из основных процессов, очень детально описываемый в сервисных процессах и никогда не выполняющийся в должной мере). Отдельная песня, конечно. И тут лично я постоянно сталкиваюсь с противоречием: вроде с одной стороны люди, которым перед тем, как что-то делать нужна масса инструкций, а с другой — они же не хотят заполнять «бесконечные бумажки».

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

А не заточенным на сервис сотрудникам нужно формулировать цели и триггеры. Например, необходимо проговорить, что проверяться работа будет так-то, оцениваться так-то. Человек, ставящий задачу, в этом случае может немного абстрагироваться и не навязывать своего участия. Стоит перепутать подход – и задача, хоть и будет выполнена, но удовольствия от ее исполнения инженер не получит. Значит и заказчик может почувствовать поверхностность или формализм. А это не поможет нам в развитии отношений и улучшении качества обслуживания. Тут вспомнился пример из жизни. Один и тот же менеджер проекта, заточенный на результат, управлял двумя разными командами с примерно одинаковой экспертизой. В первой команде были инженеры, заточенные на проектный подход, а во второй – чисто сервисные инженеры. Формулировки задачи для обеих команд были четкие, ориентированные на мейл стоуны, но без деталей. «Проектной» команде такой стиль управления зашел на 100% и отзывы по итогам работ в сторону проджект менеджера были самые позитивные. А вот «сервисным» инженерам работалось, мягко говоря, без огня в глазах. С задачей справились, сделали даже чуть больше, чем требовалось, но глаза не горели и негатива в сторону менеджмента была масса. И тут звучали комментарии и про непродуманность действий, и про отсутствие четкого взаимодействия со смежными командами. Выводы на будущее сделали, но у команды осадочек остался.

Как мотивировать

Еще важный момент – как мотивировать? А действительно, как? Про деньги умолчим ?. Предположим, что деньги мы платим справедливые. Именно так, не много или мало, а справедливо. На сколько работает — столько получает (ни в коем случае не наоборот). Но этого мало. Для сервисно мыслящих очень важна благодарность по делу. Это прям обязательно. Особенно здорово работает прямая речь от заказчика. На начальном уровне очень критично подчеркивание полезности и четкая постановка задачи. Чувство локтя (ощущение защищенности) и понимание, что рядом есть кто-то, кто точно поможет и подстрахует – обязательно. А на уровне опытного инженера должно быть осознание, что он выполняет задачу самостоятельно и не стоит дергать его по мелочам. Вот, казалось бы, совсем разных людей описал)). Но тут речь не столько про перемены в характере, сколько про смену акцентов в процессе повышения экспертизы.

Выводы

До какого-то момента своей профессиональной деятельности я считал, что те, кто руководит людьми, не должны раскрывать свои инструменты, чтобы соблюсти свою модель неприкосновенной. Но с опытом начало приходить понимание того, что искренне рассказать о своих методах и ожиданиях (пусть иногда и ошибочных) – это способ гораздо быстрее расставить приоритеты и выстроить отношения с коллегами. Работа с «сервисностью» – это одна из граней моих будней. И один из «секретов», почему в моих командах текучка происходит крайне редко. Буду рад, если кто-то попробует использовать в своей работе то, о чем я тут написал. Еще в большей степени буду рад обратной связи.