Оптимизация работы IT-отдела

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

Самое большое богатство любого IT-отдела — это люди, сотрудники отдела. Их нужно беречь всеми силами, создавать комфортные условия, убирать грабли в работе. И когда они приходят к начальнику отдела с предложениями и проблемами, слушать их, стараться помочь. Относиться как к людям в первую очередь и потом уже как сотрудникам. Тогда всё будет хорошо. Это главное.

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

Если большая текучка, люди увольняются массово, то это прям беда-беда. Работа отдела разваливается. Начальник просит увольняющегося оставить фидбэк, но это никак не поможет. Совсем. К сожалению.

Российский менеджмент справедливо признается одним из худших в мире. Разговор конечно же про цивилизованный мир: Европа, Америка.. Интернет в помощь по данному факту. Есть множество статей, где красочно говорится об особенностях российского менеджмента.

Отдел IT висит не в вакууме, а подчиняется общим корпоративным нормам. Значит специфичный корпоративный маразм здесь тоже присутствует. Кроме этого многое определяет начальник IT-отдела.

---

Психология начальника

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

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

В одной из фирм, где я пробовал стажироваться (ещё будучи пионЭром), с началом каждого рабочего дня сотрудники собирались кружком перед начальником и сжав кулаки хором повторяли за ним: "Пусть нам повезёт!". Практически религиозный экстаз. Дичь? — Лютая. Но для того начальника, надо понимать, просто необходимая вещь, без которой вся работа встанет. Много лет прошло, до сих пор помню, видимо поразило мою детскую психику. Это конечно был не IT-отдел, а отдел продажников, смысл при этом однако не меняется.

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

---

Плюсы суперуниверсальности

Какие здесь плюсы? Во-первых, полная взаимозаменяемость внутри каждого направления. Если кто-то заболел, или в отпуске, или на обучении, любой сотрудник данного направления его заменит. Необходимо назначить задание? Нет проблем, дёргаешь первого попавшегося "китайского болванчика" из нужного направления, назначаешь ему работу. Остаётся только поторапливать: "Коллеги, прошу обновить результаты". Красота, время экономится, мозг сосредоточен на решении других вопросов.

Во-вторых, экономится фонд оплаты труда (ФОТ), так как суперуниверсальных сотрудников для выполнения какого-то объема работ нужно всегда меньше, чем при других подходах в организации работы.

---

(Не)Очевидный результат

В погоне за экономией ФОТ возникла глобальная мега-негативная тенденция на рынке труда. Она везде. Не только в IT. Всё чаще при приёме на работу от претендента требуют знать всё и уметь всё. Ну а как же? Ведь можно сэкономить и вместо команды, допустим, из 8-9 человек взять на работу 6 суперуниверсалов. И они затащат, полюбасу.

Иногда встречаются дичайшие сочетания обязанностей, в IT это, кстати, проявляется наиболее ярко. Типа "сетевой инженер/администратор 1С". Ну или просто: нам нужен павлино-утко-ёж. Не буду ничего специально искать, открываю буквально первую вакансию на hh:

Нормальный списочек? 🙂 А бывают и подлиннее. Ну вот, как раз ищут очередного бэтмена.

Конечно же они его не найдут и возьмут человека, который не сможет тянуть на себе все эти обязанности в полном объёме.

Что в результате? Оказывается что сотрудники отдела завалены работой, некоторые задания выполняются крайне медленно и неэффективно, дней так по 200. Почему? Да просто сотрудник не знает как выполнить это задание, это не его специализация, а поручили ему. И поскольку он "суперуниверсал", то помогать всерьёз никто не будет.

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

---

Оптимизация работы

Разберём что же нужно сделать, чтобы улучшить ситуацию. Адекватные начальники IT-отделов не редкость, пишу я эту инфу в первую очередь для них. Возможно кому-то пригодится. Верю всё-таки в победу разума, хотя бы где-то, хотя бы частично. 🙂

---

Классика — разделение труда

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

Итак, зачем это разделение нужно? Поговорим подробнее. Хотя отдел и разбит на отдельные группы-направления (хелп-деск, сервис-деск, серверное направление, сетевое, телефония, мониторинг), внутри каждой такой группы вся работа сваливается в "общий чан" и каждый делает-тащит что может на текущий момент. При этом все отвечают за всё и занимаются всем.

Хуже придумать сложно. Почему? Да потому что:

ВСЕ = никто

Кто отвечает за эту работу? Все. Значит никто не отвечает. Неразбериха катастрофичная. Потом в один чудесный день падает суровый центровой сервис и при разборе оказывается, что хотфикс, который вышел ещё год назад не установлен, и загрузка CPU тоже почему-то не мониторилась.. Конечно будут розданы хорошие пинки во все стороны от высшего руководства и неисправность устранят. Это решает проблему, но не решает проблем.

Всё чаще сталкиваюсь с таким бестолковым подходом, причём в крупных, солидных компаниях. Причины озвучил выше — личное "вИдение" начальника отдела, ФОТ.

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

Точнее такие люди есть и их даже называют "мультитул": быстрая соображалка, профессиональная "всеядность", способность выполнять несколько дел одновременно. Только встречаются они нечасто. Это исключение, а не правило.

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

Применяется, кстати, такой подход везде. Начиная от состава мотострелкового отделения. Далеко от IT, да? 🙂 Заканчивая составом команды в какой-нибудь RPG. А принцип работает. Потому что он универсальный. Наверное немного непонятно, поэтому приведу конкретный пример из жизни.

Пример №1

Завал сотрудников непрофильной "бумажной" работой: разбор электронной почты по нескольку часов в день, отчёты какие-то непонятные и скорее всего никому не нужные, ведение странной документации из разряда "чтобы было" и бесконечные совещания. Совещание по этому вопросу, совещание по тому вопросу, совещание по результатам смены, ну и конечно же пятничное совещание.

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

Нужен отдельный сотрудник, сервис-менеджер, для бумажной работы. Возьмите стажёра, возьмите студента, пусть занимается. На удалёнку, на небольшую зарплату. Возможно ему это будет интересно (хотя в моём миропонимании работа с Word/Excel/Visio/Outlook неизбежное зло). Эффективность группы возрастает значительно. Подтверждается количеством обработанных заявок.

Пример №2

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

Пример №3

Ещё пример: если есть постоянная задача по отправке оборудования в ремонт, то лучше под это выделить отдельного сотрудника, который готов взять на себя эту задачу. Неразбериха исчезнет, эффективность увеличится.

Кто-то скажет: "Нууу, дружище.., да всё это очевидно". Оказывается нет. 🙂 Для начальников IT-отделов в крупных и известных компаниях. Им нужны обоснования увеличения расходов, документы с формулами и графиками, доказывающие необходимость изменений. Без этого они не хотят видеть очевидное. Вот оно у тебя, перед носом перед твоим. Вот, смотри. "Нет.., нужны обоснования".

Минусы разделения труда

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

Именно из-за этого же нужно организовывать сотрудников в пары и тройки, а значит размер группы неизбежно должен вырасти для такой реализации. Возрастает ФОТ, a это катастрофа для бизнеса. "Как так? Увеличить расходы? Да вы что?!". Но не забывайте: эффективность труда тоже возрастает, причём значительно, значит сбои и простой бизнес-систем снизятся — это главный аргумент "за".

Вообще зачем IT-служба? Какая первичная задача? Обеспечение непрерывности бизнес-процессов. От этого нужно отталкиваться. Скорее всего ФОТ можно оптимизировать, даже при увеличении количества сотрудников. Как это сделать? Вот здесь как раз нужно собрание и внимательное обсуждение каждой позиции отдела.

Обобщаем, тут 2 ситуации:

• Несчастные "суперуниверсалы", заваленные работой, недовольные своими обязанностями, да что там обязанностями, эти люди не рады своей жизни. Пашут не поднимая головы, низкая эффективность, глобальная неразбериха, полуночные совещания над "разбитым корытом", нерешаемые вопросы и бегство персонала. Зато экономия ФОТ;
• Каждый сотрудник занимается определённой специализацией, любит свою дело, в какой-то степени гордится собой и тем, что именно он делает вот эту уникальную для отдела работу, мотивирован, высокая эффективность, коллектив годами не меняется, но.. расход ФОТ возрастает.

Лично я 2 руками за второй подход, кроме этого:

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

---

Классика — адекватные объёмы работ

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

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

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

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

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

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

Какая же загрузка сотрудников будет оптимальной? Сложно сказать, но это не 100 и даже не 80% на постоянной основе. Вы не нагружаете процессоры в своих серверах на 100%? Нет, это так не работает. Здесь абсолютно такая же ситуация. Возможны спайки, они должны быть кратковременными.

Что делать, если сотрудники отдела загружены по максимуму?

• Пересматривать штатное расписание. Возможна банальная нехватка персонала;
• Перераспределять обязанности и роли;
• Оптимизировать подходы к работе чтобы повысить эффективность процессов;
• Автоматизировать рутинные задачи.

---

Классика — обучение

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

Хорошая возможность для работодателя — предоставить сотруднику внутреннее обучение. А ещё лучше внешнее от специфичных вендоров, используемых в компании. Это позволит значительно поднять эффективность работы.

Во многих компаниях такое обучение уже есть, во многих других жабят деньги на внешнее обучение, на разработку внутреннего обучения. И там где жабят, люди учатся самостоятельно по видео с Youtube, статейки на хабре читают.. Что в результате? Когда приходит сложный траблшутинг, а он обязательно придёт, начинаются гадания на кофейной гуще, начинается в гостях у сказки, начинается басня про лебедя, рака и щуку.

Понятно что открывается тикет у вендора и возможно его техподдержка подскажет. Возможно вывезут старожилы отдела. А если нет? Тогда "километровые" ленты переписок, которые даже открывать не хочется, не то что читать. Люди пытаются разобраться в проблеме, не знают как и всё сводится к этой переписке. Эффективность такой работы околонулевая, зато громадная потеря человеко-часов.

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

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

---

ITIL

Вторая фундаментальная концепция — ITIL или как правильно организовать работу именно в IT-отделе. Концепция всесторонняя, разобраться самому будет тяжело. Поэтому если есть финансовая возможность, желательно нанять на проектную работу специалиста по ITIL. Проект тут как раз — оптимизация работы IT-отдела (от 3-6 месяцев до полутора лет).

Такой спец стоит недешево, но оно того стоит. За это время он выработает нужный регламент по всем процедурам: от приёма звонка и правил написания письма, до методики выполнения работы. Заведет регламенты в базу знаний и научит/проконтролирует сотрудников. Видел живой пример подобной реализации на своей практике. Это действительно работает.

Описывать концепции ITIL здесь не предполагаю. Пока во всяком случае. Может позже. Скажу ток пару моментов.

ITIL — отработка недостатков

В работе IT-отдела практически всегда будут присутствовать недостатки. Почему? Потому что IT-отдел нагруженная, разветвлённая структура, реализовать её без ошибок сложно. Кроме этого работа отдела всё время меняется, непрерывно. И даже если на какой-то момент времени видимых недостатков нет, они появятся.

Что здесь главное? Недостатки в работе IT-отдела не являются проблемой, это нормальная ситуация. Недостатки нужно выявлять, проговаривать на собраниях, определять пути исправления. Работа с недостатками — плановая работа.

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

Итого: отработку недостатков нужно обязательно проводить на постоянной основе. Иначе всё будет печально и текучка коллектива обеспечена.

ITIL — Best Practices

Связанная тема. Не стоит выдумывать велосипед, всё лучшее уже придумано и хорошо документировано. Нужно брать и пользоваться. Брать обязательно, брать именно лучшее.

Типичная тут ситуация нежелание брать. Как пример нежелание создавать корпоративную базу знаний. Отмазки: некому создавать, заполнять, нет на это времени, никто не будет ею пользоваться, мы нормально работаем и без неё. Ребята, это ересь (выжигать калёным железом).

В сотнях статей рассказано какая польза от базы знаний и как она улучшит, облегчит работу. Любой IT-отдел должен вести такую базу. Должен. Без вариантов. Это аксиома:

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

---

Программные средства

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

---

Автоматизация и сбор событий

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

• Syslog-серверы;
• SNMP-серверы;
• NetFlow коллекторы;
• AAA серверы;
• APIC/DNA Center.

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

Специальные системы мониторинга, где впереди планеты всей Zabbix, само собой разумеющееся дело. Глобальный по компании, обязательный сервис. Можно было и не говорить про него, скажу всё-таки чтобы не оставалось белого пятна.

Если система умеет отсылать сообщения в группу Telegram, Zabbix понятно умеет, то это оптимальный вариант. Создаётся несколько групп, в каждую подключаются нужные специалисты, профит.

Автоматизация. Выполняется как на базе отдельных скриптов, так и на базе различного ПО. Подходов тут много, в каждой организации свой. Так в одной, где я работал, для генерации конфигов устройств использовали виртуальную машину на дебиане с апачом и MySQL, а непосредственно конфиг генерился через вебку на основе PHP. На другой работе все прикалывались по автоматизации в файлах Excel, цепляли туда API-шки разные. И так может быть тоже.

Чем больше средств по автоматизации используется, тем работать проще и комфортнее. Задачи выполняются быстрее, с меньшей затратой человеко-часов.

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

---

Траблшутинг и решение проблем

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

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

---

Управление инцидентами и изменениями

Это уже "высший пилотаж", применяется в единичных компаниях. Лично я встречал такое только в одной. Построено было на базе Microsoft SCSM (System Center Service Manager). Штука очень крутая, но требует постоянного документирования изменений, а значит дополнительных затрат времени. Зато какие-то незапланированные изменения просто невозможны при таком подходе. Обязан сказать об этом подходе, хотя бы вот так, вкратце.

---

Оптимизация коллектива

Как отбирать целевых кандидатов, заинтересованных именно в вашей работе? Как сделать чтобы сотрудники работали долго не увольняясь?

Главное что тут нужно: взять лист бумаги, ручку и написать все специфические особенности работы — честно и подробно. Затем открыть текст вакансии, сравнить. Профит.

Какая тут задача? Максимально ясно донести до кандидата чем ему предстоит заниматься. Возможно кандидатов станет меньше, но все они будут целевыми. Снова пример.

Пример №4

Просматриваю вакансии на сетевого инженера и многие из них шаблонные. Обычно так:

Ожидания от кандидата:
- Знание архитектуры и программных особенностей Nexus 9k, Cisco ASR1k, ASR99k, ISR;
- Опыт работы с IOS XR, NX OS, IOS XE;
- DC Networking - STP, OSPF, MLAG, BGP EVPN, VXLAN;

Первая строка — прям действительно нужен человек, который знает устройство "девятитонника", где какой ASIC и за что отвечает? Серьёзно? В реале скорее всего это не нужно, 99%.

Вторая строка — вода водой. Все IOS отличаются: 12 версия от 15/16, IOS ASA от IOS ISR, IOS XR от IOS XE, но при этом IOS'ом каждая из них быть не перестаёт. Работал с классической IOS? Значит разберешься с любой из них. Да, нужно время. Так для меня работа в CatOS не стала проблемой, хотя это и не IOS даже. Структура CLI, команды — довольно похоже.

Третья строка — ребята, а вы уверены что знание OSPF и BGP главное для кандидата? И основное в работе? Точно? Ну тогда к вам придёт человек, заинтересованный в расширении практического опыта в OSPF/BGP. И если потом окажется, что эти протоколы давно отстроены на оборудовании и по BGP заявка приходит раз в неделю в связи с флапнувшим соседом, а по OSPF и вообще нет заявок, то человек так же быстро уйдёт как и пришёл.

Другой момент: называйте вещи своими именами, а вот чего не надо делать, так это выдавать желаемое за действительное. Если вам нужен NetOps, который по сути специалист поддержки, то не надо писать в названии вакансии "Сетевой инженер". Да понимаю, звучит круче и люди потянутся. Но после раскрытия этого лукавства, на этапе собеседования или уже после приёма человека на работу, эффект будет крайне отрицательный.

- .. нам срочно нужен дворник.
- Тогда напиши в названии вакансии "Заместитель президента компании по уборке территории".

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

Ну вот так. Возможно со временем дополню.