Введение, оно же заключение
Прежде чем перейти к основному материалу, традиционно отвечу на вопросы, которые были заданы в комментариях и которые считаю важными.
Начну с казуса – в прошлой статье я мимоходом пнул Сталина, написав про его мнимую аскетичность на фоне множества дач (порядка 20 штук). Отношение у меня к сей персоне вполне банальное – как к обычному людоеду. «Пнул» я его вполне сознательно – считается, что в ИТешной среде данная личность трактуется неоднозначно – есть широкий круг почитателей и поклонников.
Исходя из этого стереотипа, я, честно сказать, решил «активизировать» дискуссию за счет «обиженных» – не очень честный подход, о котором я вначале пожалел (мало ли у кого какие травмы), но реальность оказалась достаточно любопытной – сторонники «культа личности» нашлись, но в штучных экземплярах. На 5 тысяч читателей статьи таких оказалось трое, и только один из них активный, который стал отрабатывать ожидаемое мной поведение – рассуждать о том, что все вокруг заблуждаются. При этом, как принято среди людей фанатично убежденных, не приводя взамен никаких доказательств своей точки зрения. В общем хайп не получился, чему я рад – быть поклонником людоедов для взрослого образованного человека - это странное поведение. А то, что таких фанатичных людей у нас в обществе штучное число, повод к еще большей радости – культура растет, а она единственный залог будущего социального и экономического процветания страны (почему так – можно обсудить в комментариях).
Теперь к вопросам предметным – спор вызвал мой тезис о том, что лучше не афишировать свой достаток перед подчиненными. Тут, наверное, я неправильно расставил акценты – я не предлагаю юродствовать в стиле «Нам хлеба не надо – работу давай». Такой подход – глупый, который работает от обратного – юродивого будут жалеть, возможно им могут гордиться, уважать, но вряд ли кто-то из взрослых квалифицированных специалистов захочет сознательно ему подчиняться. Это если речь идет об искреннем юродствовании, а если этот человек еще и лжет (прикидывается) – тут подчиненные могут и разозлиться.
То есть, если Вы зарабатываете прилично – не нужно рядиться в рубища, но и блистать «брильянтами» тоже не нужно: скромность – это общечеловеческое положительное качество, которое хорошо работает не только на работе. Ну а если уж так сильно хочется «блистать» – найдите себе в компанию равных – Вы, скорее всего, не один руководитель в вашей фирме, кроме того существуют всякие клубы – например, клубы ИТ руководителей, где вполне можно продемонстрировать свой финансовый потенциал – от этих людей Вы, в общем случае, не зависите, и их зависть Вам никак не навредит.
Важный вопрос о том, где баланс между скромностью и юродствованием, к сожалению, не имеет простого ответа – это дело вкуса и культуры. В принципе, внутри нас всегда есть те весы, которые этот баланс отмерят – другое дело, что не всегда мы этим воспользуемся.
Следующий вопрос был о том, что если у общества нет цветовой дифференциации штанов, то нет цели мы исключаем сдельную зарплату, то сотрудники быстро забьют на работу. Вот здесь я уже расскажу о своей практике.
Эффективность работы своих подчиненных нужно регулярно и подробно оценивать, но премировать или депремировать за это не нужно
Звучит как парадокс, но им не является. В прошлой статье я написал о критичности для большинства людей финансовых потерь – существуют даже научные исследования по социальной психологии, которые показывают, что одна и та же сумма денег, найденная человеком и им же потерянная, воспринимается совершенно по-разному. В случае находки, для нас это легкие деньги, которые не воспринимаются всерьез, потеря же воспринимается как вещь глубоко личная – которую человек так или иначе переживает. Можете поставить мысленный эксперимент на себе – выберите небольшую сумму денег (например, которую Вы тратите на обед в офисе) и предположите, что Вы их случайно нашли или также случайно потеряли – прочувствуйте свои ощущения в обоих случая и легко поймете, о чем речь.
Человек, который сидит на мотивации с большой премиальной частью, постоянно сильно переживает из-за возможных потерь – переживает в ущерб основной работе, я писал об этом подробно уже несколько раз. То есть вводить некие KPI для расчета премии сотрудника контрпродуктивно.
Но вот использовать их для регулярного контроля над работой сотрудника – нужно. Я в прошлый раз писал о ситуации, где на предприятии была комплексная система оценки работы персонала через комплект из KPI и SMART-задач сотрудника (что это такое, опишу ниже) и как эта система мешала работать, до тех пор, пока от неё зависела зарплата людей. Но как только удалось отвязать её от финансового вознаграждения – она превратилась в совершенно рабочий инструмент.
Что это значило на практике – у сотрудника был набор из постоянных показателей эффективности – KPI. Варианты таких показателей следующие:
- Для системного администратора – это, например, количество и длительность критичных сбоев оборудования, от которых зависит работа важных бизнес-процессов предприятия – та же отгрузка товара клиенту. Здесь простои и срывы в общем нежелательны, а иногда и смерти подобны – те, кто отгружал товары в сети, знает какие штрафы клиенты предъявляет за недопоставку даже малой партии товара.
- Для разработчика – это такие же критические простои, но вызванные сбоями в работе программного обеспечения.
- Для консультанта – это скорость отработки запросов, поступивших от критичных отделов предприятия.
Таких KPI не должно быть слишком много – не нужно распылять внимание персонала, но они должны комплексно отражать устойчивую работу всех важных процессов предприятия. Здесь главную роль играете Вы как руководитель ИТ отдела – Ваша задача грамотно «оцифровать» эти процессы. Для этого нужно в первые же дни работы на новом месте активно общаться с сотрудниками и руководителями всех служб – причем лучше идти сверху вниз – поговорить с главными «боссами» (собственники бизнеса, генеральные-исполнительные директора) – выявить их головную боль от качества работы ИТ службы, затем перейти просто к директорам и так дойти до уровня рядовых менеджеров отделов. Нужно спрашивать о том, какие критичные участки работы зависят от ошибок ИТ службы. Всё это нужно сводить в единый документ. Я, в своё время, назвал его «Картой критичных сбоев», по сути это разновидность SLA. Пример своей карты я приложил в конце статьи – там я поместил несколько подобных документов, которыми пользовался в работе ИТ директором.
KPI Вы должны контролировать наиболее «плотно» - не дожидаясь реальных сбоев. Здесь важным также является выстраивание механизмов быстрой обратной связи, так чтобы при возникновении проблемы Вы как можно быстрее о ней узнали. В случае администрирования есть, например, автоматизированные средства мониторинга доступности ИТ ресурсов предприятия – их множество, от достаточно простых, которые просто «пингуют» сеть, до достаточно изощренных и дорогостоящих. Я пользовался и теми и другими – нравился Observer от Network Instruments, еще была какая-то штука на Linux (сейчас уже не помню), что-то сейчас есть у Microsoft – подобрать подобное решение Вам поможет ваш системный администратор, если же ему не доверяете – пообщайтесь на форумах железякщиков, попросите платно проконсультировать и настроить – ничего сложного здесь нет. Выводите обратную связь сразу на мобильные устройства – сделать сейчас работающий SMS шлюз дело одного-двух часов, зато Вы сразу узнаете что и где у Вас «упало» - и это гораздо лучше, чем если Вам неожиданно позвонит Шеф с вопросом – а что это за фигня у нас происходит с интернетом, почему я не могу досмотреть свой любимый сериал.
Второе – получив обратную связь, как можно быстрее оповестите всех «пострадавших» в процессе инцидента. Не нужно скрывать проблему – это Вам вылезет боком – всегда найдутся «доброжелатели», чтобы вовремя упомянуть, что «принтер опять не печатал – машины с грузом стояли и ждали», а так Вы сразу отбираете у них инструмент для шантажа.
Для информирования подойдет обычная почтовая рассылка – желательно сразу сделать группы рассылки по вариантам возможных инцидентов и в случае их возникновения рассылать письмо по группе – что-то вроде «О проблеме знаем, срок исправления ситуации 15 минут». В моем случае такие группы рассылок были прописаны в карте сбоев.
Третье – у Вас должен быть готовый план быстрого исправления сбоя: что сотруднику отдела ИТ делать, если что-то пошло не так. Вы не всегда можете быть в доступе, Вы можете заболеть, уйти в отпуск, просто находиться на совещании – отдел должен устойчиво продолжать работать, даже (особенно) если произошел форс-мажор.
В моем случае план исправления также был прописан в карте сбоев. Кроме этого, под критичные участки всегда делались резервы – у меня на мясопереработке таким критичным участком была, например, экспедиция, место где комплектуют грузы клиентам. Под неё всегда стоял в резерве новый предустановленный комп и принтер – резервное оборудованием находилось упакованное в пленку в подсобке экспедиции, в случае сбоя устанавливалось в течение 10-15 минут. Раз в месяц оборудование проверялось.
Резервы максимально ДОЛЖНЫ БЫТЬ – если на них не дают денег, значит регулярно пишите письма на эту тему руководству – добивайтесь, или хотя бы прикрывайте себя и свой отдел. Я такие письма писал раз в месяц, меня за это не любили, но денег давали – особенно после первого критичного сбоя, который я предсказал.
Работать по KPI Вы и ваши подчиненные должны не за страх, а за совесть – депремирование Вам вряд ли поможет, если за сорванную отгрузку предприятие будет оштрафовано на несколько миллионов – Вас просто выгонят – по статье. И работу Вы после этого найдете только несложную – например ИТС разносить. Это должны знать Вы, это должны отчетливо понимать ваши подчиненные.
В статье я сделал акцент на «железных» KPI, связанных с оборудованием и системным администрированием. Аналогию для софта и программирования сделать несложно, более того в случае программирования можно работать проактивно – не допускать ошибки до пользователей – сейчас множество всяких инструментов (включая встроенные) для тестирования кода – это и сценарное тестирование и тестирование на качество кода – этим НУЖНО пользоваться. Писать об этом детально я не буду – материалов на эту тему на Infostart множество.
Далее SMART задачи – что это за зверь?
Начну с аббревиатуры – SMART означает Specific, Measurable, Achievable, Relevant, Time bound. В переводе на русский конкретная, измеримая, достижимая, доступная для исполнителя, ограниченная по времени задача. Что это значит:
- Задача ставится на конкретный срок – например, сделать в этом месяце.
- Задача ставится конкретному исполнителю, который её может выполнить (есть соответствующие ресурсы и компетенции).
- Прогресс по задаче можно контролировать – Вы можете обговорить с исполнителем план работ по задаче и контролировать текущее исполнение плана.
Как ставятся такие задачи – в моем случае за неделю до начала следующего месяца я собирался с коллегами (включая функциональных заказчиков) и обсуждал возможный перечень их смартов для ИТ отдела – что мы должны и можем сделать в следующем месяце. Если задача в месяц не умещалась – разбивали её на части. Приоритет по задачам был такой – вначале те задачи, которые могут улучшить работу по KPI (что мы сделаем чтобы нас не уволили в следующем месяце), далее задачи на развитие – какие новые инструменты мы можем/должны создать для бизнеса.
Список задач обсчитывался в плановой трудоемкости (дни), так чтобы плюс/минус покрывались все рабочие дни месяца. Плюс зазор на возможные форс-мажоры.
Понятно, что не всегда все задачи можно расписать до начала месяца – бывает срочно набегают комерсы и просят сделать что-то необычное и вчера. И это нужно делать – это жизнь. Но план работы ДОЛЖЕН быть – форс-мажор кончится, и сотрудник должен спокойно продолжить работать дальше. Пусть и не все по плану успеет сделать. Единственное предложение из практики – собирайте статистику таких внезапных набегов и ходите с ней жаловаться к своему шефу. Большинство руководителей понимает важность системной работы, поэтому скорее всего посодействуют Вам в упорядочении потока «хотелок».
Механизм SMART задач столь же важен, как и механизм KPI – если в первом случае мы системно боремся с форс-мажором, то в случае смартов мы осознанно и регулярно контролируем работу подчиненных. Вы в любой момент можем оценить текущий прогресс по задаче (помните про Measurable), таким образом не допустите долгосрочных проблем – если общий прогресс сотрудника по его смартам несколько дней стоит на одной и той же величине, значит есть какая-то проблема, с которой человек не может справиться – повод Вам ему оперативно помочь. Для автоматизации этой контрольной функции рекомендую Вам пользоваться инструментами подобными Redmine с комплектом плагинов для Scrum (я часто критикую Agile методы, но в основном за их некорректное применение в работе). У меня есть архив с моим преднастроенным комплектом Redmine+Agile – если будет интересно, пишите в комментариях – я напишу отдельную статью, сделаю обучающее видео и выложу архив на скачивание.
Последний инструмент контроля, кроме KPI и SMART задач – это оценка работы ИТ отдела от других служб предприятия. Оценка проставляется каждой службой отдельно, по итогам месяца, по десятибалльной шкале (пятибалльная не пойдет, в силу школьных стереотипов). Чем выше оценка – тем лучше. Оценка ниже 6 баллов требует обязательного пояснения от оценщика – почему он её снизил.
Такая интегральная оценка всегда носит отчасти субъективный, эмоциональный характер – чаще всего, при нормальном исполнении KPI и смартов, оценка будет колебаться в диапазоне 7-9 баллов – и это значит, что все нормально. Но вот если ставят 5 баллов – значит нужно быстро идти и разбираться с проблемой – кто-то кого-то сильно обидел и если запустить ситуацию, то проблема быстро эскалируется на руководство предприятия.
Любое планирование бессмысленно без анализа результатов. В случае регулярного контроля за KPI и отслеживания прогресса по смарт задачам, такой анализ ведется непрерывно, что снимает еще одну проблему финансовой мотивации – её запаздывание: накосячил человек сегодня, а премии он лишится в конце месяца. Но кроме такого постоянного контроля полезным будет также проведение совещаний по итогам месяца – что-то подобное тому, то что в Scrum называется ретроспективой. На таких итоговых встречах можно абстрагироваться от текучки и с определенной высоты посмотреть на ситуацию в целом – что систематически препятствует эффективной работе отдела. Здесь не нужно «пинать» людей – если Вы регулярно контролируете их работу, то проблемы будут и так понятны – не будет понятен их объем – его Вы увидите, проанализировав итоговую результативность по KPI и смартам. И тут можно уже обоснованно принимать корректировочные действия – менять значения KPI, их приоритет, менять объем смарт задач, которые сотрудник может планово «переварить» за месяц. Ретроспектива крайне полезна, если у Вас в подчинении несколько однотипных специалистов – например, программистов. Обсуждая проблемы одного сотрудника можно получить перекрестную связь от других специалистов – люди могут как-то увязать свои проблемы и обсудить общий путь их решения.
Лучший план ретроспективы следующий:
- Общее обсуждение проблем всех Ваших ПРЯМЫХ подчиненных.
- Тематические обсуждения проблем отдельных направлений – отдельно с сисадминами, отдельно с программерами, отдельно с консультантами и т.д..
Если Вы правильно выстроили иерархию подчиненности в своем отделе, то первую встречу ведете Вы (я специально выделил слово ПРЯМЫХ подчиненных), на остальных Вы просто присутствуете и смотрите как ретроспективу проводят ваши ведущие специалисты со своими подчиненными. Это в случае большого отдела ИТ. Если он небольшой, то можно ограничиться только первой встречей и пригласить на неё всех.
Ну вот я и описал ту систему менеджмента, которую в том или ином виде использовал в свою бытность начальником / директором ИТ. Как видно – система достаточно комплексная, учитывающая различные аспекты работы отдела. Придумал я её не сам – помогли грамотные руководители и коллеги, за что я им благодарен. То, что я внес в неё важного – это отвязал результаты от финансовой мотивации – чтобы не нервировать людей в процессе работы. Потому что такая система не требует большой привязки к финансовой мотивации подчиненных – Вы всегда держите руку на пульсе и можете разрулить проблему еще до её появления – здесь крупный косяк ваших подчиненных – это скорее всего Ваш косяк, когда Вы забили на управление отделом. Ну можете себя сами наказать – если хочется.
Если к этой системе оценок подходить серьезно - без лишнего формализма и лени, то она гарантирует Вам по крайней мере спокойную жизнь – когда Вы знаете, что у Вас все более-менее подконтрольно и Вас не ждет какая-то неожиданная катастрофа в том, что зависит от качества Вашей работы и работы ваших подчиненных.
Да это требует регулярного менеджмента, да вначале Вы будете тупить над, тем что можно считать смартом, а что нет, да через какое-то время Вы впадете в депрессию от необходимости регулярно что-то назначать/проверять. Но через недолгое время (месяца через три) – это станет для Вас такой же обыденностью как чистка зубов. А где-то через год-два Вам станет скучно на своем месте работы – все будет слишком тихо и предсказуемо – а это и есть хороший результат работы ИТ службы и её руководителя.
Заключение
Чтобы не заканчивать статью на столько «ванильной» ноте заранее отвечу на вопрос «а что делать, если подчиненный не хочет работать?». То есть Вы выстроили грамотную систему контроля и теперь отчетливо понимаете, что Ваш программист тупо не делает свою работу.
Вариант на самом деле один – увольнять сотрудника и искать нового. Вы не переделаете другого человека – он такой и таким будет, пока его жизнь не исправит, а может вообще не исправит. Вам ненужно с ним нянчиться – штрафовать его, убеждать его и пр. пр. Вы ему не мать и не отец. Если есть желание обучать и работать над квалификацией кого-то – найдите себе лучше достойную кандидатуру. Может специалиста молодого и неопытного, но того, который разделяет Ваши убеждения делать работу качественно.
Лентяев НУЖНО увольнять – они плохи не только потому, что не делают свою работу, но и потому что они демотивируют сотрудников вокруг и подрывают Ваш авторитет. Поэтому с вещами и на выход.
Второй вопрос – «Не возникнет ли иллюзия ложного контроля, когда за правильными значениями KPI до поры до времени скрывается большая проблема?». Такой риск есть – поэтому контроль должен быть не формальный – посмотрели на цифры и пошли дальше. Вы должны отчетливо понимать, что делают Ваши подчиненные в текущий момент – хорошо разбираться в этом. Если в силу масштаба отдела ИТ Вы не можете охватить все задачи, значит выстраивайте иерархию руководства – назначайте замов, кураторов, ведущих специалистов (называйте как угодно). Работайте с этими людьми, разбирайтесь в их проблемах, контролируйте что они также «плотно» работают со своими подчиненными – это называется культура управления и ей тоже нужно учиться – чаще всего на опыте своих и чужих ошибок.
Самое главное тут – не нужно ждать сразу каких-то сверхрезультатов, нужно просто вести систематическую работу со своими коллегами. А потом, через полгода, можно для интереса взять и сравнить текущие значения KPI с начальными.
К статье добавлен архив с моими рабочими документами с прежних мест работы – можно воспользоваться в качестве образца для разработки своих. Состав архива:
- Карта критических сбоев.
- Карта оценок службы ИТ.
- Карта KPI сотрудника.
- SMART карта сотрудника.
Все документы – это Excel таблицы. Также есть программа на 1С 7.7, в которой пункты 2.3.4 были автоматизированы (в этой программе работало все предприятие «Группа Компаний «Добрый Колбасник» – с подобными же правилами игры, но для всех служб и отделов в течение 6 лет), выкладывать я её постеснялся, наверное, перепишу под УФ и выложу отдельно.
Ну и с Новым Годом, коллеги! Всем всех благ, а также рекомендую посетить выставку Васи Ложкина в ЦДХ в Москве. Его картинами я люблю иллюстрировать свои статьи.
Памятка руководителя: Базовые компетенции
Памятка руководителя: Уволь HRа и найди себе хороших сотрудников
Памятка руководителя: В одиночку здесь не выжить
Памятка руководителя: Будьте оптимистичным или на крайний случай злым
