IT для неайтишников: Какими бывают IT-шники? Часть 3

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

Меня зовут Константин Митин. 15 лет занимаюсь коммерческой IT-разработкой, прошёл путь от простого программиста до сооснователя и руководителя группы IT-компаний (АйТи Мегастар/АйТи Мегагруп). Успел побыть тим-лидом, руководителем филиала разработки крупной федеральной IT-компании. Являюсь одним из идеологов концепции IT~BP (партнёрство между IT и бизнесом).

Я не пишу продающие тексты и не являюсь копирайтером, в конце статьи не будет коммерческого предложения и призыва к действию. Мне более интересно делиться знаниями и опытом. Некоторым людям мои статьи кажутся слишком длинными, если вам более привычен формат небольших сообщений, то обратите внимание на telegram-канал Записки ITBP.

В первой части мы составили примерный список IT специалистов, который хотим рассмотреть. Список получился длинным, объёмным, но на полноту не претендующим. Там же мы рассмотрели эникейщиков и специалистов технической поддержки второй и третьей линии, а так же системных администраторов. Во второй части мы разобрали программистов, поняли чем младшие (junior), средние (middle) и старшие (senior) специалисты отличаются друг от друга, почему и как такое разделение распространяется не только на программистов, но и на многие другие специальности в IT.

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

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

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

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

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

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

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

Иногда проблема либо инцидент происходит в одной системе, а проявляется в другой системе, связанной с первой через другие системы. У каждой системы свои команды L2/L3. Могут возникать сложные маршруты разбора и решения инцидентов и поиска проблем.

Кроме этого, есть такое понятие, как SLA (Service Level Agreement - соглашение об уровне услуг), в нём прописываются сроки реакции и решения инцидентов в зависимости от их категории (срочности). Одно дело - человек просто не может понять, как и что работает, другое дело — случился отказ в работе центрального сервера. Это разные инциденты с разными сроками решения. Незначительные инциденты могут обрабатываться днями, а аварии требуют моментальной реакции и решения. SLA - это соглашение, которое заключается между бизнесом и IT-службой.

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

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

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

Во-вторых, SLA, SLM (Service Level Management — уровень оказания услуг) и прочее — это договорённости с внутренними и внешними заказчиками. Этими договорённостями тоже нужно управлять.

В целом, процесс технической поддержки уже хорошо стандартизирован, подробности можно посмотреть в ITIL/ITSM (IT Infrastructure Library / IT Service Management). Ну заглянуть в ISO 20000 либо ГОСТ Р ИСО/МЭК 20000-х-хххх.

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

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

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

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

Сам я был когда-то техническим лидером по Lotus Notes/Domino - это платформа разработки систем электронного документооборота для крупных корпораций на основе NoSQL базы данных. Исходя из своего уровня знаний, я хорошо понимаю принципы работы большей части документоориентированных баз данных, как работают географически распределённые вычислительные системы, процессы репликации и синхронизации данных, обеспечения их безопасности и многое другое.

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

Без Кирилла Боровикова у компании Тензор ЦОД (центр обработки данных) был бы раз в десять больше, что стоило бы сколько-то десятков миллиардов рублей. У меня достижения несколько поскромнее, например, у одной крупной компании запустилась система управления доступами пользователей (сколько-то десятков миллионов пользователей) на интересной связке технологий OpenDJ/OpenAM, которая в иных руках не запускалась. Понадобилось всего лишь понимание внутреннего устройства LDAP-каталога и процессов индексации в нём, а так же понимание репликации данных по логу транзакций (плохой, но часто используемый метод).

Технический лидер — это дорогой и редкий специалист, который нужен лишь большим командам. Конечно, если мы говорим не о должности, а об уровне компетенций. Так-то любого человека можно назвать кем угодно и присвоить произвольную должность.

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

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

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

Беда этой «орды» ещё в том, что программисты люди циничные и устойчивые к давлению (смотрим книгу Дж. Рейнвотера «Как пасти котов. Наставление для программистов, руководящих другими программистами»). По-настоящему они слушать будут только того, кто заслужил у них авторитет, а для этого нужно быть инженером. Именно поэтому говорят о лидере либо предводителе, а не о руководителе. Административной власти не хватит - нужно социальное влияние.

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

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

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

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

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

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

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

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

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

Если вы дочитали до конца и написанное было для вас полезным, то спасибо вам.

Полезные материалы по теме: