Привет, Хабр! Меня зовут Амир Хусаинов. В ПСБ я руковожу системными администраторами Linux. Это распределенная команда специалистов, рассредоточенных от Новосибирска до Москвы. В ИТ я с 2007 года, а в ПСБ пришел тимлидом в сентябре 2022 года, когда компания была в авангарде импортозамещения. Меньше чем за год отдел вырос с 4 до 10 человек, а линукс-инфраструктура — с 400 серверов до 1500. Сейчас в отделе уже 35 человек и серверов более 11 000. При таком взрывном росте текущие процессы перестали функционировать и превратили работу в хаос и сплошную головную боль — несоблюдение сроков, бардак в документации, непрозрачная работа. Впрочем, эти болячки известны любой организации, и я знал, как их лечить.

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

Итак, что я увидел, когда пришел в команду.

Непрозрачная работа отдела. Заказчик не знал, когда будет взята в работу его заявка, что с ней происходит, и когда она будет исполнена. Настоящий черный ящик.

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

«Молодой и неслаженный» коллектив из 10 человек, где только 4 сотрудника работают в команде больше года.

Вместо Service Desk две системы работы с задачами Jira и Lotus, которые не приспособлены для работы как классический сервис деск.
 
Супердинамичная рабочая среда, события в которой сменяют друг друга с молниеносной скоростью. Заказчики бомбардировали сотрудников в попытках добиться внимания любым доступным способом: почта, телефон, мессенджер. Потому специалисты могли выполнять только текучку, о сосредоточении на ключевых и сложных задачах не могло быть и речи.
 
Кэл Ньюпорт в своей книге «Новые принципы делового общения» называет такие процессы гиперактивным коллективным разумом.
 
Гиперактивный коллективный разум — это рабочий процесс, в котором людей постоянно отвлекают и требуют их внимания через почту, чаты и другие способы коммуникации. Ньюпорт пишет, что для работников интеллектуального труда это губительно, и я с ним полностью согласен. Примеры, которые он приводит в книге, я видел лично. Вместо того, чтобы сосредоточиться на работе, люди находятся в постоянном хаосе и тушат пожары. Работают вроде много, как белки в колесе, а выхлоп небольшой, бэклог не уменьшается, долгосрочные задачи не решаются. Всем этим нужно было как-то управлять, контролировать и предоставлять заказчикам необходимый уровень сервиса.

Зона комфорта… А что это?

Понятно, что работать в таких условиях было крайне дискомфортно для бизнеса, для сотрудников и для меня. А что такое комфорт?

Для бизнеса комфорт — это понятные сроки и налаженные процессы, когда понимаешь, куда писать, и за какое время помогут.

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

Для меня комфорт — это процессы по Томасу Лимончелли — он системный администратор и писатель, которого я очень люблю и уважаю. Свой первый опыт работы в ИТ я получил в аутсорсинге в компании «Шорткат». Мой директор Кирилл и техлид Борис показали, как должна работать ИТ-служба для бизнеса, за что я им безмерно благодарен. Мы отстраивали ИТ-процессы в соответствии с заветами Лимончелли: автоматизация, стандартизация, этика, документация и многое другое. Его книга «Системное и сетевое администрирование» была у нас настольной, идеи из нее настолько меня зацепили, что я до сих пор их придерживаюсь. Больше всего меня тогда привлекла глава про кодекс системного администратора.

Прекрасно, ориентиры есть, помчали на всех парусах в зону комфорта! И не слушайте тех, кто говорит, что надо выходить оттуда, стремиться в нее — наша обязанность как профессионалов.

Мы с руководителем сформулировали задачи:

• Наладить операционную работу отдела и обеспечить поддержку проектов импортозамещения в части ОС.

• Организовать найм специалистов.

Service Desk видели? А если найду?

Отладку операционной деятельности начали с настройки работы со входящими заявками.

Служебные записки в Lotus. Система для работы с типовыми заявками, требующими согласования различных служб. Очень архаичная, в которой невозможно организовать соблюдение SLA. Но несмотря на технические ограничения, нам удалось реализовать прозрачную работу с заявками СЗ Lotus.

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

С какими проблемами мы столкнулись.

Хаотичное распределение в работу. Несколько недель без внимания — обычная история для заявки.

Отсутствие инструмента отчетности по СЗ Lotus. Увидеть СЗ в работе на конкретных сотрудниках невозможно.

Сотрудники работали с задачами бессистемно и непрозрачно. Сроки исполнения отсутствуют, комментарии в задаче невнятные или их нет вообще.

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

Как решили эти проблемы:

• Построили процессы согласования и распределения заявок.

• Придумали форму стандартного отчёта по задачам.

• Написали правила работы с задачами.

Работа со служебными записками ведется в несколько этапов.

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

Процесс согласования ведется по принципу FIFO (first in, first out) — первым пришел, первым ушел в отдел согласования ДИБ. Это линейный процесс. Распределение на четвёртом этапе ведется по принципу карусели на всех инженеров. Все инженеры умеют выполнять типовые заявки.

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

Поступающие за день задачи в Jira распределял я как руководитель, это особенности работы Jira. Я садился в пять вечера и не уходил с работы, пока не отдам всё сотрудникам. Поначалу задерживался, потом научился делать за час. В день поступало до 60 задач. Сейчас это делают тимлиды.

Теперь переходим ко второй проблеме – отсутствие технической возможности получить статус по СЗ Lotus на отделе. Мы придумали стандартную форму отчета, которую сотрудник заполняет каждое утро и отправляет тимлиду по e-mail вместе со скриншотом служебных записок в работе. Когда люди слышат про ежедневную отчетность, то относятся к этой идее скептически. Но наш отчет заполнить несложно, в нем ничего сверхъестественного нет.

По задачам в Jira отчитаться тоже несложно, у нас есть таблица в Confluence, которая собирает необходимые статусы по задачам. И сотрудник, глядя в эту таблицу, понимает проблемные зоны, и тут же их исправляет, в отчет идут уже правильные статусы.

С помощью формы отчета мы мотивируем сотрудника внимательно разобрать свои заявки, планировать рабочий день, не упустить важное, контролируем количество заявок в Lotus, даем возможность указать на проблемы.

Во время дейли я открываю отчет, параллельно открываю таблицу в Confluence и смотрю скриншот СЗ Lotus, сверяя правильность заполнения. Если цифры в таблице и в отчете не бьются, я понимаю, что сотрудник сегодня не смотрел задачи. Тут же задаю ему вопросы.

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

Внимательно прочитать описание новой заявки. Убедиться в том, что она по адресу.

Запросить срок исполнения. Это правило действует исключительно для Jira. Так как в Jira нет SLA, то мы запрашиваем срок. Сотрудники вставляют в форму запроса срока сообщение: «Добрый день! Прошу сообщить желаемый срок исполнения и критичность задачи».

Уточнить информацию. Если в описании не всё понятно, то нужно задать в заявке вопросы. Часто в описании происходит что-то непотребное.

Определить следующий шаг. Если понятно, что делать, то сотрудник делает первый шаг или записывает его в план на день или неделю. Это практика из «GTD» Дэвида Аллена и «Пути Джедая» Максима Дорофеева.

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

Во время жизненного цикла заявки обязательно писать комментарии, что сделал, что собираешься сделать, о чем договорился на встрече с заказчиком и так далее.

Об этих правилах мы говорим периодически со всеми сотрудниками на персональных встречах one-on-one, особенно с новичками. Также мы оцениваем работу сотрудников по соблюдению этих правил.

Пожарный отряд

Описанное выше — хорошо для стандартной работы. Но есть заявки с очень коротким SLA или просто очень срочные. А есть аварии.

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

Состав группы: дежурный по согласованию заявок в инфраменеджере и Lotus, дежурный по инфраструктуре, два дежурных по почте. На еженедельной основе мы составляем график дежурств. Закрепляем в общем чате.

Дежурный по инфраструктуре доступен 24/7, поддерживает инфраструктуру в нерабочее время, а в рабочие часы отрабатывает стандартные алармы. Что делают дежурные по почте? В день мне могут написать в мессенджер человек 20-30 с вопросами разной степени сложности. Я заготовил ответы в Excel, где прошу написать письмо на группу «Администраторы Linux». То есть отправляю заказчика в единую точку входа.

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

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

Потомки не простят нам беспорядок в документации

Что мы хотели получить от документации:

• Ускорить адаптацию новых сотрудников. Благодаря инструкциям и чек-листам к концу испытательного срока все сотрудники должны уметь выполнять типовые задачи.

• Сделать предсказуемыми реакции сотрудников на задачи.

• Создать шпаргалку для заказчика, которая позволяла бы разобраться в наших процессах.

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

И еще дополнительные выгоды:

• набор инструкций помогает оценить технические навыки сотрудника на испытательном сроке в дополнение к моей оценке по правилам работы;

• документация позволяет бизнесу не беспокоиться о том, что будут какие-то уникальные сотрудники, потеря которых замедлит процессы;

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

Scrum для эксплуатации? Лучше бы пошли поработали!

Мы внедряли кусочек методологии Scrum летом 2023 года по совету одного из коллег из Сбера. Мне понравилась идея трех вопросов на дейли, на которые сотрудник отвечает за две минуты:

• Что сделал вчера?

• Есть ли проблемы?

• Чем будешь заниматься сегодня?

 Изначально мы планировали 30 минут на команду из 13 человек. Но часто обсуждали и насущные вопросы — порой это могло затянуть дейли до полутора часов. Я не до конца понимал, как проводить их эффективно, и с ростом команды до 20 человек они превратились в ежедневные большие планерки.

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

С учетом прошлого опыта и новых знаний мы выстроили работу следующим образом. Разбили отдел на четыре команды. Внедрили практику тихого часа. Тихий час начинается в 9 утра и заканчивается в 10 перед дейли. Практику я подсмотрел у Максима Дорофеева в его книге «Путь джедая». В это время я прошу сотрудников сосредоточиться на планировании дня. Я сам надеваю наушники, слушаю музыку и прошу меня не беспокоить.
 
  Что я делаю в первые 60 минут рабочего дня:

• просматриваю календарь и планирую встречи;

• согласовываю сроки задач в Jira, или это делают тимлиды;

• бегло просматриваю почту.        

У инженеров другой распорядок. Что делает сотрудник за первые 60 минут:

• рассматривает новые задачи;

• заполняет стандартную форму отчета, о которой я говорил выше;

• отправляет отчет руководителю.                                

Благодаря этому наши встречи стали короче и продуктивнее. Теперь дейли длится 20 минут. Проводится в каждой команде в удобное время до 11:00. И у нас есть окно для помощи после дейли. Если сотрудник запрашивает помощь, то для тимлида встреча с ним в тот же день становится приоритетной.

Все эти меры помогли наладить предсказуемую работу отдела и обуздать хаос. Давайте перейдем ко второй задаче — организации найма сотрудников.

Как мы построили конвейер для найма администраторов Linux

Все два года команда росла очень быстро. И вместе с настройкой процессов внутри нам нужно было удовлетворить потребности проектов в сотрудниках.

Первичный отбор у нас проводит HR. Мы подготовили шпаргалку — опросники для джунов, мидлов и синьоров. Если кандидат на большую часть вопросов отвечает положительно, то HR просто ставит в календаре собеседование.

Так выглядит наш опросник:

Задокументировали рассказ об отделе и задачах — первые 15 минут мы пересказываем это кандидату, чтобы сориентировать, в какой команде он будет работать, и чего мы от него хотим.

Дальше просим кандидата рассказать, какую функцию он выполняет, описать свою зону ответственности и инфраструктуру. После этого задаем вопросы на софт и хард скиллы. Список вопросов тоже задокументирован.

Так как у нас всё есть в тексте, мы обучили тимлидов и технических специалистов проводить собеседования. Благодаря такому подходу смогли проводить до семи собеседований в неделю. С июня по ноябрь прошлого года мы приняли в штат 15 человек, что позволило закрыть KPI по подбору. 

Вместо заключения 

В качестве финала приведу список книг, которые помогли мне выстроить комфортную работу для команды:

• Томас Лимончелли «Системное и сетевое администрирование». Это одна из моих настольных книг, и я всегда её всем советую.

• Максим Дорофеев «Путь Джедая». Здесь я подсмотрел много интересных идей, в частности, практику тихого часа. Также он пишет о том, что для концентрации на сложных задачах человеку нужно мыслетопливо. И как поддерживать его высокий уровень для отдельно взятого человека.

• Кэл Ньюпорт «Новые принципы делового общения». Поможет справиться с гиперактивным коллективным разумом :)

• Дэвид Аллен «Getting Things Done». Помогает научиться декомпозировать и решать сложные задачи, планировать свое время.

• Стивен Кови «Семь навыков успешных людей». В представлении не нуждается. 

Спасибо за интерес к статье! Приходите в комментарии задавать вопросы, делиться своим опытом лидирования команды и советовать хорошие книги для тимлидов.