Путь IT-менеджера (часть #1)
Привет! Меня зовут Алексей и я предлагаю сразу перейти на «ты».
Один мой друг разрешил опубликовать его историю про путь в руководители, что я и делаю с небольшими литературными изменениями. Все совпадения и имена совершенно случайны. Текст написан от первого лица. Ровно так, как он мне его и рассказывал.
Приятного чтения!
Когда я только начинал заниматься управлением проектами, мне казалось, что необходимо вникать во все детали работы моих сотрудников.
Заняв позицию руководителя, я оказался в ситуации, когда моя проектная команда непосредственно мне не подчиняется. Да, все они были выделены специальным приказом по компании в мой проект на какой-то процент своего времени. Кто-то на 10%, а кто-то на 50%. При этом у каждого из них был свой линейный руководитель, которого ребята слушались намного лучше, чем меня. Такая картина подчиненности присутствует в организация со слабой матрицей или в функциональных компаниях.
Чтобы грамотно контролировать работу своих сотрудников мне необходимо было понимать в деталях, что же происходит на их участке работы. А я никак не мог стать специалистом сразу во всех направлениях. Мне приходилось верить своим людям на слово! Представляешь? Верить Дмитрию, Василию и Игорю, что задача «Ticket-12345» будет сделана ровно за столько дней, за сколько они сказали. И, конечно же, они регулярно ошибались. А я отвечал за провал по срокам перед своим руководителем.
Думаешь, что надо было просто заложить буфер побольше? Увы, это не работает, сколько не добавляй. Люди знают, что у них есть запас и приступают к задачам только когда остается совсем мало времени до дедлайна. И в очередной раз не успевают в обещанный срок. При этом еще и общая длительность проекта вырастает. И финальную длительность уже видно клиенту/заказчику/директору.
В общем, сложность была в том, что я не знал всей специфики работы каждого человека в моей команде. А раз я этого не знал, то не мог достоверно убедиться, что их оценка по срокам — верна. И команда прекрасно это видела и понимала. Приходилось овертаймить, вникать в каждую мелочь, в каждый проектный момент, который как лавиной начал накрывать меня все быстрее и быстрее. Чем больше времени я проводил, углубляясь в специфику, тем глубже закапывался во все более неясные для меня технические детали проекта. Глубина этой кроличьей норы была бесконечной. На бесконечную детализацию требуется бесконечное число времени. А у меня были только 8 рабочих часов в день плюс еще часов 6 овертаймов. Больше я просто не выдерживал (может это меня и спасло).
Я стал понимать, что не логично делать все больше и больше работы в неверном направлении. Задачи и их техническая глубина потребуют от меня знаний нескольких технических институтов вместе с несколькими годами реального опыта по каждому из направлений деятельности команды. Столько человеко-лет у меня физически нет в рамках срока проекта. А дедлайн неумолимо приближался.
Я осознал, что направление моего движения не верное и усиливать работу в неверном направлении — это очень большая глупость, какую я только мог совершить как руководитель. Плюс происходит бездарная трата моего самого ценного ресурса — времени. Вместо того, чтобы заниматься управлением, я занимался изучением технических вопросов проекта. А ведь мои специалисты в команде явно во много раз компетентнее меня в технологиях. Нужно только как-то извлечь пользу для проекта из их компетентности, не заменяя их всех одним собой. Ведь такая замена — физически не возможна. Нельзя усвоить все знания и навыки на их уровне за короткое время жизни проекта, даже если проект идет несколько лет.
И я стал смотреть на управленческие процессы. Именно в них я видел свое спасение от спирали смерти и профессионального выгорания. А как тут не выгореть, если я считал себя классным руководителем, а на деле факты говорили про обратное. Сроки сдвигались, задачи оценивались не корректно, команда меня не слушалась.
>> Продолжение следует
