[Work] Как организовать команду сисадминов

Привет, %username%! Был в моей небольшой карьере период, когда в моих руках была вся власть! Ну или почти вся. Я был начальником отдела ИТ в компании с штатом сотрудников 400-500 человек. Около полутора десятков представительств по все стране и немного за бугром. Как только мне дали (вынужденно, ибо: «Ну, а кто ж кроме тебя?») должность и одобрили набор сотрудников я решил подойти основательно к руководству отделом. Собственно об этом и будет дальше.

Я не буду рассказывать о том, что я сделал для получения должности и каких нервов мне это стоило. Просто «Кроме тебя больше не кому» — именно с такой формулировкой меня объявили с начала исполняющим обязанности начальника отдела информационных технологий, а после и начальником. Это все лирика и статья не об этом. Получив немножко власти и одного сотрудника в подчинение я решил, что работать ручками и бегать в любимую бухгалтерию «включить процессор» я не хочу. Ну не люблю я так бегать, да и вообще хотелось развиваться как специалисту. Дальше я обсудив с руководством компании выбил себе разрешение на поиск сотрудников в отдел в центральный офис (ЦО). Поиски длились не очень долго и спустя примерно один месяц мне одоброили прием в отдел двух сотрудников на должности системного администратора и помощника системного администратора, плюс не забываем про еще одного сотрудника (так же системного администратора) в обособленном подразделении. Итого (путем сложных математических вычислений) получается три сотрудника в моем подчинении: два системных администратора и один помощник системного администратора.

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

1. Что умеют — по направлениям Windows и Linux;
2. С каким сетевым оборудованием работали — Интересовали Cisco, Zyxell, HP;
3. Какими языками программирования владеют — PowerShell/Bash/Python/Php;

Далее было предложено рассказать, что именно интересно и хочется изучить по сфере деятельности. Эта информация давала понимание того, как именно более эффективно распределить зоны ответственности и при этом не иметь «точки отказа» в лице одного сотрудника. На сто процентов сделать всех взаимозаменяемыми не получилось, но примерно на 60-70 процентов ребята перекрывали знания и зоны ответственности друг друга. После сбора анкет, на что было предоставлено два дня, мне понадобилось еще пару дней, чтобы распределить правильно между всеми членами нашей команды (именно командой я всегда называл отдел, который я сформировал) зоны ответственности по регионам, серверам и сервисам. Не могу сказать, что это был прорыв в работе отдела, но тоть факт, что количество заявок смогло сократиться с 5-10 в день, до 2-3 в неделю уже является аргументом для меня.

Следующим этапом для меня была отладка взаимодействия сотрудников компании и моей команды специалистов. И далее было предпринято следующее:

1. Установка системы ServiceDesk;
2. Обязать всех сотрудников компании подавать заявки через сервисдеск (было сложно, но мы этого добились — исключение составлял лишь директорат компании);
3. При постановке задачи руководством компании до обозначения сроков выполнения проводить мозговой штурм с членами нашей команды;
4. Все члены команды обязаны фиксировать свою работу в сервисдеске, даже если это замена картриджа в принтере;
5. Вместо занудных и расплывчатых отчетов и планов (которые требовало руководство компании от меня) предоставлялись только выгрузки из сервисдеска за период в неделю без планирования;

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

У нас в команде было два обязательных правила:

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

У нас не было дресс-кода и я не требовал от своей команды быть на работе строго с 9:00 до 18:00. Я просто сам такой же и не люблю строгие рамки, ну и ребят к себе в команду я подбирал таких же. Главное чего я хотел от них это соблюдения сроков выполнения. При этом я никогда не подходил к кому-либо и не говорил: «Надо развернуть новый сервер, который приедет через три дня, поставить на него ОС/софт/сервисы/ввести_в_домен и срок на все про все тебе до вечера». Любой новый сервис у нас всегда разворачивался примерно по одной и той же схеме:

1. Установка;
2. Настройка;
3. Проверка корректности работы;
4. Тестирование;
5. Запуск в бой;
6. Непрерывное наблюдение и мониторинг;

Да, были случаи когда новый сервис требовался «прямо здесь и сейчас» — во многих компаниях я сталкивался с таким — это не редкость. Но если нет аврального положения, то на запуск нового сервиса всегда озвучивается время с запасом: например на то чтобы развернуть и запустить новый VPN нам нужна неделя при условии, что площадка у нас уже есть и мы определились с тем где он будет размещен. Например VPN для удаленных сотрудников (которые часто в разъезадх/командировках) мы разворачивали сервис VPN и заняло это времени около двух недель. При этом на выходе была авторизация по учеткам в AD (что было очень желательным условием для меня т.к. я занимался еще и вопросами информационной безопасности), поддерживались все используемые платформы (Linux/Windows/macOS/iOS/Android) и для подключения использовались только стоковые клиенты (никаких дополнительных установок). В случае увольнения сотрудника нам надо было только отключить его учетку в домене и всё.

Проработав в должности руководителя отдела около одного года я понял, что мой дальнейший путь с этой компанией не совпадает и я их покинул. А спустя примерно полтора месяца и ребята ушли из компании. В общем на эту тему можно еще много чего рассказать, но самое главное что хочется донести до больших начальников и/или молодых начальников: С вами работают именно люди (спасибо, Кэп!) и работать надо с ними именно так, как хотите чтобы работали с вами.

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

Тем не менее на этом всё!

Опубликовано 28.07.2018 в 14:29 · Автор JTProg_ru · Ссылка
Рубрики: Рабочие моменты · Теги: , , , ,