Не кодом единым. Кто такие менеджеры в ИТ и что от них ждёт работодатель

Сегодня буквально из «всех утюгов» и с каждого второго рекламного баннера транслируются призывы вроде: «войди в ИТ», «научиться кодить за неделю – реально» и прочие заманчивые клише. Желающие стать айтишниками принимаются кодить, полагая, что только так можно попасть в самую востребованную профессиональную сферу последних лет. Однако, ИТ – это не только про код, но и про грамотный менеджмент. Директор дивизиона в digital-интеграторе Notamedia Илья Юрасов рассказал, какова роль руководителей в ИТ, какими качествами они должны обладать и почему ценность таких специалистов на рынке ничуть не ниже, чем у разработчиков.

С чего начинается ИТ-менеджмент

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

В Notamedia действует следующая иерархия:

• Руководитель проекта  –  человек, в задачи которого входит планирование, управление, выстраивание взаимоотношений с заказчиком. В целом,  отвечает за успешность проекта.

• Менеджер проекта – больше сконцентрирован на операционной деятельности изнутри. У него есть какая-то определенная задача (обычно большая) или контур, за который он отвечает (например, разработка модулей и их интеграция с внешними системами). В зоне его ответственности – своевременное и качественное исполнение конкретно этой задачи, а также следование указаниям/целям руководителя проекта. 

• Администратор проекта – человек, который только хочет войти в менеджмент. Обычно обладает набором необходимых софт-скиллов и выполняет функцию помощника менеджера, который в свою очередь делегирует небольшие операционные задачи, контролирует их выполнение и в процессе обучает.

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

Что интересует работодателя на собеседовании: софт-скиллы

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

«Давайте смоделируем ситуацию. Вот у вас, день сдачи этапа контракта. Вы приходите к заказчику, показываете ему макеты, а он говорит, нет, все не так. А у вас все, последний день. Какие ваши действия?»

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

И вот у него есть новые вводные, которые он не планировал. Какие он действия совершит для перестройки работы? Что будет делать дальше? Он может просто прийти и сказать команде: «Срочно все делайте». Но, опять же, заказчик сказал, что это надо завтра, а у нас, допустим, день заканчивается. То есть, коллектив надо как-то мотивировать делать это в нерабочее время (достаточно сложный момент).

У руководителя/менеджера проекта лидерские качества должны быть на достаточно высоком уровне, так же, как и эмпатия. В условиях ограничений ему потребуется находить баланс между «надо» и здоровой атмосферой в коллективе. Метод «кнута и пряника» в таком режиме не работает (или работает, но недолго).

Что интересует работодателя на собеседовании: хард-скиллы

Большое преимущество у соискателей, которые работали по каким-то методологиям, вроде PMBOK, PRINCE2 и т.д.. Либо, как минимум, дошли до такого уровня профессионального развития, когда им стало это интересно.

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

Взять хотя бы ведение реестра рисков и управление рисками. Это достаточно важный момент, с точки зрения проекта, на который очень многие просто закрывают глаза, потому что не понимают, что это такое. Допустим, у нас есть риск, что инопланетяне захватят Землю. Мы не можем быть точно уверены, что такое не случится, но оценка этого риска будет очень низкая, а его влияние на проект высокое, потому что, скорее всего, будет конец света. В свою очередь, риск того, что техлид уволится – имеет шанс выше, но его влияние будет ниже. В обоих случаях, для каждого риска, помимо оценки, необходимо запланировать, что делать, чтобы не его не допустить или как минимизировать последствия. Например, в случае с увольнением, заранее прописываем: техлида гладить по головке, приносить ему печеньки, не дергать в выходные и т.д. (условно). Это огромный пласт работы, таких рисков может быть бесконечное множество. Понятно, что в реестр рисков попадает только наиболее критичный процент, но, тем не менее, взвешивать их нужно еще до того, как проект стартовал, потому что, если мы поймем, что этот проект слишком рискованный, то, возможно, имеет смысл его не начинать.

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

Простые вопросы «на засыпку»

Есть вопрос, который я задаю всем: «Что такое проект?» Необязательно зачитывать справку из Википедии или какой-либо методологии, важно как человек ответит своими словами. Иногда в процессе уточняю, что такое критический путь проекта и подобные базовые термины.

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

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

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

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

Red flags: кто не подходит для руководящей позиции в ИТ

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

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

Третий – зашоренность. Как мы уже говорили, отлично, если человек работал по РМВОК, но странно, если он не знает основ, к примеру, Agile-методологии и «даже не стал читать». Если тебе не приходилось ее применять, если просто не нравится, стоит все же выяснить, почему полмира по ней работает. Как бы это «мемно» ни звучало, мы – «динамично развивающаяся, современная компания».

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

В целом

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

Последний, но не по значению совет – любому руководителю, который хочет расти в этой сфере, полезно читать профессиональную литературу, и, в принципе, читать. Рефлексировать, перекладывать свой опыт на то, что прочитано. Почему делается так, а не иначе? Если бы я знал то, что знаю сейчас, как бы я поступил в ретроспективе? Почему эта ситуация случилась, и что я мог сделать, чтобы этого не допустить тогда и сейчас? Благодаря этому простому «упражнению» специалисты довольно быстро растут. По крайней мере, это помогло мне и ребятам из моей команды.

Примеры полезной профессиональной литературы:Том Демарко и Тимоти Листер. Человеческий фактор. Успешные проекты и команды
Джефф Сазерленд. Scrum. Революционный метод управления проектами
Хэнк Рейнвотер. Как пасти котов
Кен Бланшар. Одноминутный менеджер (серия маленьких книг)
Руководство к своду знаний по управлению проектами (Руководство PMBOK®)