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

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

Автор: Вадим Нечунаев

Руководитель отдела реализации проектов ГК «Солар»

В одном из прошлых блогов мы уже рассказывали про схему ролевой модели архитектора комплексной кибербезопасности. Если кратко, то под каждый интеграционный ИБ‑проект набирается команда, в ней выделяется группа управления проектом в составе руководителя проекта (РП), который отвечает за организационную часть проекта, и главного инженера проекта (ГИП), которому при необходимости подключают технических ответственных (ТО).

ГИП и ТО отвечают за техническую часть проекта, их задачи варьируются от проекта к проекту, но если их попробовать унифицировать, получится примерно такой список:

• Техническое видение и архитектура: подготовка требований, формирование HLD‑архитектуры комплексной системы обеспечения ИБ (КСОИБ) — в том числе в условиях неопределенности, недостаточности исходных данных и в сжатые сроки, — определение подхода к реализации КСОИБ для проектной команды, контроль соответствия проектного решения требованиям ТЗ, договора и требованиям нормативно-правовых актов;

• Организация работы проектной команды: участие в планировании и организации выполнения работ, декомпозиция и постановка конкретных задач инженерам и подрядчикам, входящим в проектную команду, контроль качества работ и изменений в проекте;

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

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

Чего не хватает техлиду?

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

Большинство техлидов — это «штучные» эксперты, выросшие из инженеров. Опыт технического руководства на проектах получается не в университетах и не на курсах, а нарабатывается годами от проекта к проекту, в том числе через боль.

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

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

• работает вместе с РП и должен уметь говорить с ним на одном языке для синергетического эффекта;

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

• формулирует задачи участникам проектной команды и отвечает за общий результат команды;

• в работе сталкивается с проблемами, решение которых не всегда возможно в рамках проекта и вообще зависит от множества факторов.

Нужные для этой работы знания легли в план первой части обучения.

Что надо понимать и знать техлиду?

Стандартные функции управленческой деятельности

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

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

В этом блоке обучения мы осветили задачи РП, техлидов и ресурсных менеджеров в разрезе функций управленческой деятельности в терминах матрицы RACI: кто выполняет работу, принимает ее, консультирует или информируется о результатах.

Квалификации ресурсов согласно модели ситуационного лидерства

Техлиду важно понимать разницу между мотивированным экспертом, которому можно смело делегировать задачу «под ключ», и джуном с горящими глазами, за которым присматривает куратор.

Модель Херси-Бланшара описывает, как ставить задачи в зависимости от квалификации и мотивации подчиненных и как техлиды могут адаптировать свой стиль управления к конкретной ситуации.

Постановка целей и задач

Руководитель должен ясно представлять цель, то есть какие результаты команда планирует получить, а также уметь ставить задачи, то есть сформулировать, что необходимо сделать, чтобы эти результаты получить.

Знакомим техлидов с принципом SMART — без него никак (мы решили, что не стоит импортозамещаться на принцип ВОДКИ).

Командообразование

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

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

Механизм использования эскалаций

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

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

Как строится работа на проекте?

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

Что такое проект?

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

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

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

Наконец, убедились, что техлиды, ГИП и ТО, хорошо понимают свои роли на проекте и роль РП.

Как управлять проектами?

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

Чтобы сформировать это понимание у техлидов, мы обратились к модели «Кеневин», которая делит проектов на типы: простые, сложные, комплексные и хаотические. Определив тип проекта, мы выходим из зоны неопределенности в одну из этих областей и выбираем, согласно той же модели, подходящие тактики управления.

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

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

Стандарт управления проектами PMBOK

Международный стандарт PMBOK (Project Management Body of Knowledge) — это свод лучших практик и инструментов, благодаря которому управление проектом перестает казаться rocket science и перекладывается в понятные «измерения», или области знаний. Это управление содержанием, сроками, стоимостью, качеством, ресурсами, коммуникациями, рисками, закупками, заинтересованными сторонами и интеграцией.

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

Управление коммуникациями и заинтересованными сторонами

• Что следует знать про типы совещаний

  • «Дейлики» (daily) в начале проекта или этапа работ — быстрые совещания, которые организуются для мозговых штурмов и запуска процесса работ в целом: что сделано, что буду делать, какие есть проблемы.

  • «Статусы» — регулярные еженедельные совещания с РП

  • Технические совещания —организуются по запросу для обсуждения конкретных технических вопросов в более узком инженерном составе, без РП.

  • «Дейлики» в конце проекта или этапа работ организуются для быстрого решения проблем.

  Для всех совещаний заблаговременно формируется перечень вопросов для обсуждения.

• Заинтересованные стороны (стейкхолдеры), зачем это надо знать?

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

  • РП не может знать всех стейкхолдеров, техлид может помочь с этим для определения правильной стратегии взаимодействия.

  Пример 1. Сложная организационная структура Заказчика может потребовать учесть некоторые особенности при планировании работ. Так, если географически распределенное оборудование, настройки которого будут изменяться в ходе проектных работ, эксплуатируется разными подразделениями, то необходимо закладывать дополнительное время для согласования архитектурных схем и планов проведения работ со всеми ответственными подразделениями.

  Пример 2. При подготовке опросных листов потребуется учесть особенности организационной структуры Заказчика: например, нужен единый файл опросного листа, но отдельные вкладки с вопросами по ИТ-оборудованию и ИБ-оборудованию, потому что будут заполнять разные подразделения.

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

Управление рисками

• Риск — это дело благородное

  • ВЕРОЯТНОСТЬ * УЩЕРБ

  • Зона ответственности РП

• Типы рисков:

  • Технические;

  • Организационные;

  • Юридические;

  • Финансовые и т.д.

• Технические риски может и должен подсвечивать техлид.

Например, использование нетиповых трансиверов для NGFW несет за собой риск — не подойдут, проектное решение не заработает. Как можно минимизировать риск? Возьмем трансиверы в долг с соседнего проекта и проверим на стенде перед массовыми выездами на площадки проведения работ.

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

Как приумножить положительный эффект от обучения?

Итак, эту программу обучения мы испытали сразу на большой группе — пригласили всех техлидов, которые работают у нас в Центре кибербезопасности государственных сервисов. Это был двухдневный интенсив, каждая часть примерно на 1 час: 30 минут материала и 15–30 минут обсуждения в формате вопросов и ответов. Лектором выступил я сам, опираясь на собственный опыт работы инженером, РП, техлидом, и ресурсным менеджером. Чтобы можно было возвращаться к обучению для восполнения копилки знаний, мы зафиксировали материалы в виде презентации и видеозаписи на внутреннем ресурсе.

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

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

В настоящий момент мы успели реализовать пару идей, родившихся в процессе обучения и в результате обратной связи. В частности, мы уже системно оцифровали опыт работы РП и техлидов – разработали методический документ, в котором постарались описать опыт работы техлидов на всех этапах работ классического интеграционного ИБ-проекта, от пресейла до закрытия проекта. По нему мы тоже успели провести обучение. В дальнейшем будем актуализовывать эту методику в рамках внутренних процессов производства.

Вывод

Чтобы успешно реализовать проект с технической точки зрения, техлиду нужно уметь видеть его глазами руководителя. Обучение, построенное на реальном опыте управления ИБ-проектом, позволяет наслоить базовые навыки менеджмента на техническую базу, не скатившись в «корпоративный булшит» и не оставив без ответа вопрос, как применить теорию на практике.