Меня зовут Константин Митин. 15 лет занимаюсь коммерческой IT-разработкой, прошёл путь от простого программиста до сооснователя и руководителя группы IT-компаний (АйТи Мегастар/АйТи Мегагруп). Успел побыть тим-лидом, руководителем филиала разработки крупной федеральной IT-компании. Являюсь одним из идеологов концепции IT~BP (партнёрство между IT и бизнесом).
Я не пишу продающие тексты и не являюсь копирайтером, в конце статьи не будет коммерческого предложения и призыва к действию. Мне более интересно делиться знаниями и опытом. Некоторым людям мои статьи кажутся слишком длинными, если вам более привычен формат небольших сообщений, то обратите внимание на telegram-канал Записки ITBP.
В первой части мы составили примерный список IT специалистов, который хотим рассмотреть. Список получился длинным, объёмным, но на полноту не претендующим. Там же мы рассмотрели эникейщиков и специалистов технической поддержки второй и третьей линии, а так же системных администраторов. Во второй части мы разобрали программистов, поняли чем младшие (junior), средние (middle) и старшие (senior) специалисты отличаются друг от друга, почему и как такое разделение распространяется не только на программистов, но и на многие другие специальности в IT.
В третьей части мы коснёмся руководящих и лидирующих специализаций. Стоит понимать, что в области информационных технологий руководитель — не всегда лидер, а лидер — не всегда руководитель. Здесь мы рассмотрим руководителя службы технической поддержки, технического лидера и лидера команды разработки.
Руководитель службы технической поддержки
Это интересная руководящая специализация. Именно этот человек отвечает за процессы управления инцидентами и управления проблемами. Инцидент — это когда система работает неожиданным образом для пользователя, из-за чего он не может выполнять свои рабочие функции. Проблема — это причина массового либо регулярного возникновения какой-то категории инцидентов.
Когда пользователь не смог самостоятельно разобраться, как и что должно работать — это инцидент. Когда система работает не так, как описано в инструкции пользователя — это инцидент. Если в системе происходят ошибки, то и это инциденты. А что такое проблема?
Если в системе происходят ошибки из-за дефекта кодирования, то это проблема. Иными словами дефект кодирования, из-за которого пользователи часто встречаются с инцидентами, это один из видов проблемы. А если это дефект кодирования в «мёртвой» (не используемой) части функционала, то это не проблема, там он никому не мешает. Либо когда инцидент из-за такой ошибки возникает 1 раз на 100 дней, а решение инцидента занимает 5 минут, то это тоже уже не проблема.
Если пользователи часто не могут разобраться в системе, и её поведение сильно отличается от описанного в инструкции, то, скорее всего, есть проблема в инструкции пользователя. То есть её нужно обновить либо дописать. Иногда решением проблемы может быть изменение интерфейса системы, чтобы он был более понятным для пользователей.
В идеальной картине мира система не требует ручных правок, ошибок в ней не происходит, пользователи не ошибаются. Но пользователи — люди интересные, они могут быть любыми и с любой компетенцией, и это — нормально. Когда им что-то непонятно либо у них что-то не получается, то они обращаются в службу поддержки. Когда у системы много пользователей и им что-то непонятно — это большая и важная проблема, из-за которой происходит много инцидентов. А техническая поддержка начинает испытывать высокую перегрузку, не смотря на всё техническое совершенство системы и её работу без сбоев.
Не стоит забывать, что пользователи, у которых произошёл инцидент, не могут выполнить какую-то часть своей работы, а штат технической поддержки вечно раздувать нельзя. Это всё затраты.
Иногда функции руководителя технической поддержки могут выполнять специалисты третьей линии, тогда к их навыкам придётся добавлять ещё и начальные навыки менеджмента и ведения переговоров. Но в какой-то момент процесс технической поддержки может разрастаться и усложняться, появятся новые системы и другие команды L2/L3. Здесь без руководителя технической поддержки уже не обойтись. Плюс может вставать задача маршрутизации.
Иногда проблема либо инцидент происходит в одной системе, а проявляется в другой системе, связанной с первой через другие системы. У каждой системы свои команды L2/L3. Могут возникать сложные маршруты разбора и решения инцидентов и поиска проблем.
При хорошей работе руководителя службы технической поддержки количество инцидентов постепенно снижается, а возникающие инциденты начинают решаться чуть ли не на лету. И такой человек препятствует проникновению на продуктив функционала с ошибками, хотя не имеет отношения к QA и QC специалистам.
Кроме этого, есть такое понятие, как SLA (Service Level Agreement — соглашение об уровне услуг), в нём прописываются сроки реакции и решения инцидентов в зависимости от их категории (срочности). Одно дело — человек просто не может понять, как и что работает, другое дело — случился отказ в работе центрального сервера. Это разные инциденты с разными сроками решения. Незначительные инциденты могут обрабатываться днями, а аварии требуют моментальной реакции и решения. SLA — это соглашение, которое заключается между бизнесом и IT-службой.
Так же необходимо понимать, что решение инцидента — это когда удалось снять проблему инициатора инцидента (пользователя), после чего инцидент закрывается. Этого можно добиться ручными правками, обходными путями либо ещё чем-нибудь. Перед закрытием инцидента должен происходить анализ причин возникновения, которые включаются в отчёт по инциденту.
Почему это именно руководящая специализация? Во-первых, специалисты технической поддержки второго уровня — это линейный персонал. Люди, которые должны быть легко заменяемыми (низкая стоимость и срок замены), для которых формируется база знаний и эффективные программы обучения. Такие специалисты не обладают редкими компетенциями и высокой квалификацией. Для управления процессом их воспроизводства и общим руководством над ними нужен руководитель в классическом понимании, а не лидер.
Специалисты третьей линии технической поддержки могут обладать редкими компетенциями и высокой квалификацией, но их обычно мало, поэтому в выделенном лидере либо руководителе они не нуждаются.
Во-вторых, SLA, SLM (Service Level Management — уровень оказания услуг) и прочее — это договорённости с внутренними и внешними заказчиками. Этими договорённостями тоже нужно управлять.
В целом, процесс технической поддержки уже хорошо стандартизирован, подробности можно посмотреть в ITIL/ITSM (IT Infrastructure Library / IT Service Management). Ну заглянуть в ISO 20 000 либо ГОСТ Р ИСО/МЭК 20 000-х-хххх.
Технический лидер (tech lead)
Иногда ещё можно услышать «техлид». Старшие программисты тоже продолжают расти и развиваться. Однако следующая ступень развития требует сделать выбор специализации. Нужно выбрать между более глубокими знаний технологий, управлением командой либо общей архитектурой.
Технический лидер — это старший программист, который на пути своего развития сделал выбор в пользу специализации на технологиях. Такой человек знает не только какую-то конкретную технологию в совершенстве, но и те технологии, что окружают выбранную им для специализации технологию.
Технический лидер — это не должность, это роль. Причём эта роль не является руководящей, у технического лидера даже нет подчинённых, но есть глубокое понимание области, в которой он работает.
Например, в компании Тензор мне довелось работать с Кирилом Боровиковым, который является техническим лидером по PostgreSQL, то есть очень глубоко понимает работу этой технологии, как внутри неё и почему именно так у неё работает. И как с её помощью эффективно, легко и красиво решать сложные прикладные проблемы. К слову сказать, кроме этого у Кирилла Боровикова была ещё и руководящая должность, но в её рамках он занимался несколько иной работой, нежели той, которую выполнял в роли технического лидера.
Для того чтобы быть техническим лидером по PostgreSQL, нужно понимать, как хранятся данные: в абстракции базы данных, на уровне файловой системы, на уровне жёсткого диска и его страниц памяти. Нужно понимать, как работают индексы, как они собираются, как хранятся, для чего какой вид индекса нужен. Нужно понимать, как работает оптимизатор запросов, а это весьма сложный статистический механизм. И ещё очень много иных вещей, требующих понимания как математики, так и системного программирования (внезапно).
Сам я был когда-то техническим лидером по Lotus Notes/Domino — это платформа разработки систем электронного документооборота для крупных корпораций на основе NoSQL базы данных. Исходя из своего уровня знаний, я хорошо понимаю принципы работы большей части документоориентированных баз данных, как работают географически распределённые вычислительные системы, процессы репликации и синхронизации данных, обеспечения их безопасности и многое другое.
Такая глубина знаний нужна для того, чтобы обходить острые углы и позволять технологиям полностью раскрываться. Именно поэтому технические лидеры могут запрещать производить какие-то действия либо рекомендовать к использованию конкретные подходы. В их присутствии начинают хорошо работать вещи, которые у других никогда даже запуститься не могли.
Без Кирилла Боровикова у компании Тензор ЦОД (центр обработки данных) был бы раз в десять больше, что стоило бы сколько-то десятков миллиардов рублей. У меня достижения несколько поскромнее, например, у одной крупной компании запустилась система управления доступами пользователей (сколько-то десятков миллионов пользователей) на интересной связке технологий OpenDJ/OpenAM, которая в иных руках не запускалась.
Понадобилось всего лишь понимание внутреннего устройства LDAP-каталога и процессов индексации в нём, а так же понимание репликации данных по логу транзакций (плохой, но часто используемый метод).
Технический лидер — это дорогой и редкий специалист, который нужен лишь большим командам. Конечно, если мы говорим не о должности, а об уровне компетенций. Так-то любого человека можно назвать кем угодно и присвоить произвольную должность.
И главное, такой человек должен быть способен и готов учить других людей. Технический лидер — один из наставников технической команды.
Лидер команды разработки (team lead)
Иногда ещё можно услышать «тимлид». Ими становятся старшие программисты, которые решили специализироваться на технологиях управления. Это сложный выбор: для инженера писать код всегда доставляет больше удовольствия, чем управление людьми. Денежная мотивация тоже не играет большой роли, технические лидеры и архитекторы получают не меньше.
В норме хороший инженер не хочет власти, ведь для него власть — это синоним ответственности, а управление — это всегда власть. Инженера в неё толкает желание навести либо сохранить порядок вокруг себя. Дело в том, что программисты с точки зрения технологий управления являются «ордой», если их много собрать в одном месте и оставить без управления, то они наворотят много дел, которые испортят жизнь как самим программистам, так и окружающим.
Если человеком движут амбиции, жажда власти и признания, а не безысходность, то, наверное, перед вами неудачный кандидат. Вместо сохранения гармонии в системе такой человек будет преследовать свои амбиции, усиливая негативные тенденции.
Беда этой «орды» ещё в том, что программисты люди циничные и устойчивые к давлению (смотрим книгу Дж. Рейнвотера «Как пасти котов. Наставление для программистов, руководящих другими программистами»). По-настоящему они слушать будут только того, кто заслужил у них авторитет, а для этого нужно быть инженером. Именно поэтому говорят о лидере либо предводителе, а не о руководителе. Административной власти не хватит — нужно социальное влияние.
Становясь лидером команды разработки, человек занимает начальную руководящую роль. То есть получает начальный уровень административной власти. И скорее всего, к этому моменту у него в руках будет находиться ещё и неформальная власть, причём выше, чем начального уровня.
Интересный момент. В области информационных технологий часто практикуются методы неявного управления руководителем. Лидер команды, скорее всего, уже это умеет. Желательно, чтобы он ещё умел не попадать под управление снизу.
Такому человеку приходится не только управлять командой, участвовать в найме, оценке, развитии и увольнении сотрудников, не только обеспечивать слаженную и эффективную работу команды разработки, которая состоит из разнородных специалистов. Ему ещё придётся научиться говорить на одном языке с бизнесом и правильно выполнять административные функции.
Если честно, то с точки зрения программистов многие административные функции выглядят бессмысленными и раздражающими. Лидеру команды придётся развить свой уровень осознанности, чтобы охватить не только технические системы, но ещё и разнообразные организационные процессы. В том числе и понять, почему они необходимы и именно такие.
Кроме того, именно такой человек является основной точкой контакта для бизнеса. Именно от него бизнес получает знания о технологиях, именно с ним ищутся пути реализации и организации общей деятельности. Человеку приходится не только обладать движущей силой в области разработки, но ещё и движущей силой в области процессов работы.
Наверное, стоит ещё оговориться, что лидер команды — это адаптер между традиционными технологиями управления и теми технологиями управления, которые могут использоваться в IT-среде. Например, если компания полностью находится в IT-среде, то она может иметь матричную структуру и у программистов вообще не будет руководителя, как такового. Плюс административная система управления будет несколько урезанная, чтобы не мешала инженерам работать. Главное, чтобы после такого компания достигала поставленные бизнес-цели.
Подводя промежуточные итоги
В третьей части статьи мы рассмотрели руководителя технической поддержки, технического лидера и лидера команды разработки. Это лидирующие и руководящие роли.
Технические лидеры обычно никуда не растут потому, что им и так неплохо. У них скорее рост в глубину и вширь (новые технологии). Человек осознанно ограничивает себя ролью технического эксперта, хотя зачастую может много больше.
Лидер команды разработки в будущем может стать системным аналитиком, архитектором, руководителем департамента разработки либо дорасти до CTO. Это человек, который начал соединять в себе административную власть, неформальную власть, технические знания и авторитет у разработчиков.
Если вы дочитали до конца, и написанное было для вас полезным, то спасибо вам.