Путь самурая: как прокачать навыки управления техлиду

Наверняка вам знакома ситуация: продакт-менеджер, вчерашний студент, в свои 23 года хочет любой ценой «затащить» на рынок сервис, пусть и сырой, лишь бы схватить внимание аудитории. В это же время техлид с двадцатилетним стажем смотрит на код и требует кропотливой доработки ради стабильности. Два подхода сталкиваются в лоб, и высока вероятность конфликта, когда молодой специалист уйдёт в себя, а техлид останется непонятым. А это прямой шаг к выгоранию обоих.

Поэтому успех любого интеграционного ИБ-проекта зависит от подбора команды, где у руля — руководитель проекта, который отвечает за организационную часть, а также техлиды — главный инженер проекта и/или технический ответственный. Управлять задачами и технической командой — не менее важный хард-скилл, чем экспертные знания. Как навык «Лидерство» в «Героях 3» позволяет объединить разных существ в одной армии и даёт дополнительные ходы, так и для техлида умение грамотно организовывать технические работы на проекте снимает лишнюю головную боль и экономит время всех без исключения участников команды.

Задачи техлида отличаются от проекта к проекту, но если попробовать их унифицировать, то получим примерно такой список:

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

Что должен понимать техлид, приступая к реализации проекта:

Как работает производственный конвейер проектов

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

R (Responsible) — исполнитель задачи или подзадачи.
A (Accountable) — ответственный за результат (утверждает работу).
C (Consulted) — эксперт-консультант, чьё мнение учитывают.
I (Informed) — участник, которого информируют о ходе выполнения.

RACI определяет границы ответственности техлида по основным функциям управления: планирование, организация, мотивация, контроль.

Уровень кадров

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

Цели и задачи

При планировании проекта важно разделять цели и задачи. Цель — формулирует планируемый результат. Задача — описывает действия, необходимые для его получения. Для последовательного достижения цели и выполнения задач на Западе придумали схему SMART, а на постсоветском пространстве её адаптировали под более привычный принцип ВОДКИ.

Как формируется команда, умеющая делать работу

Даже правильно поставленная цель по ВОДКИ (SMART) может забуксовать, если не учесть состояние и готовность команды. К примеру, для техлида может казаться нелогичным, что на этапе «шторма» производительность команды закономерно падает. Кажется, что проект буксует, но на деле именно так формируется рабочая группа согласно модели Такмана, по которой во время шторма конфликты воспринимаются как неизбежная составляющая жизненного цикла команды.

Типы проектов (Cynefin)

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

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

Что делать, если проблема на проекте не решается

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

База проектного управления

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

Управление сроками — зона ответственности руководителя проекта, который определяет время исполнения задач, собирая информацию со всех направлений. Обычная практика, когда при реализации конкретных задач, отдельных этапов работ и проекта в целом, под возможные риски закладываются управленческий резерв времени. На этом этапе техлид может помочь рассчитать правильный тайминг проекта, чтобы не вылететь за рамки проектного треугольника. Классический проектный треугольник «время-стоимость-объём работ» работает жёстко: изменение одного параметра неизбежно влияет на остальные. Критический путь, границы и допущения проекта — техлид должен понимать эти ограничения, чтобы не уйти в совершенство там, где нужно было сдать результат вчера. Ведь лучшее, как известно, это враг хорошего.

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

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