Путь IT-менеджера (часть #2)
(часть #1)
Поняв, что двигаться быстрее и делать все больше и больше в неправильном направлении — не вариант, я стал смотреть в сторону процессов управления. Но каких?
Я сообразил, что мне нужна помощь или толковый совет. К сожалению, атмосфера в компании не располагала к доверию и спросить совета у руководителя я не мог. Это уже должно было мне о многом сказать, но в то время я не обращал внимания на такие «мелочи». Синдром отличника также делал свое дело и вредил мне, не позволяя задавать вопросы и просить о помощи.
На каком-то из локальных ивентов по менеджменту, куда я таки пошел, несмотря на жесточайший цейтнот в проекте и недостаток свободного времени, я услышал фразу «правильные процессы».
— Вот то, что мне нужно, — подумал я. — Только что значит «правильные»? 
Наверное, правильные — это те, которые описаны в умных книгах или в школах менеджмента. А какая у нас самая авторитетная организация про менеджмент в мире? Конечно же PMI — Project Management Institute.
И я подумал, что мне нужно прочитать PMBoK — Project Management Body of Knowledge. Ведь там описаны все процессы по управлению проектом. От самого начала и до завершения.
Начав читать PMBoK последней редакции я понял, что это очередная кроличья нора. Процессы затягивали меня в водоворот абстракций, входов и выходов, каких-то умных названий и непонятных последовательностей действий. А как человек практичный, я хотел все это привязать к своей реальности. Но у меня не получалось. На бумаге выходило очень умно и толково. Но в проекте нужен был результат, а не написанный и заверенный стейкхолдерами communication management plan, либо project plan — документ, описывающий проект, а не project schedule, как думают многие слыша слова «план проекта».
Пока я плавал во вселенной процессов, документов и зависимостей, мой проект уверенно шел под откос, все больше набирая скорость и уже начиная издавать отчаянное «Ту-ту!» перед крушением. Необходимые результаты проекта так и не делались. Польза не создавалась. Сроки опять переносились.
Наверняка все написанные и утвержденные процессы помогли бы моему проекту в будущем. Либо если бы они были созданы в самом начале проекта и поддерживались в актуальном состоянии по ходу его развития то, возможно, я бы не зашел в производственный тупик, не имея на руках результатов проекта.
После очередной статусной встречи по проекту со своим руководителем, на которой он вполне четко и прямо усомнился в моей компетенции как менеджера, я понял, что процессы — тоже не панацея. Их явно не достаточно.
Меня стали считать начинающим бюрократом, который все регламентирует и тем самым в немалой степени тормозит проект. А я боялся, что стоит отступить от процессов, как проект точно завалится. Хотя он и так уже летел в пропасть. С процессами или без них. Зато с процессами он умирал предсказуемо, по плану и контролируемо.
Активно вложившись в изучение, создание и настройку процессов я столкнулся все с теми же проблемами, что у меня и были только под другим углом.
— Дима, сколько займет выполнение этой задачи? — спрашивал своего инженера я на утренней встрече.
— Нуу… может быть дня четыре, если все будет нормально. — Неспешно отвечал Дима глотая свежесваренный ароматный кофе.
— Мы и так уже опаздываем по срокам, можешь сделать за два с половиной дня? Овертаймы я согласую. Ок?
— Нуу… я попробую. Но ты же понимаешь, что там сложный код и интеграция с внешней системой. Могут вылезти сторонние проблемы, о которых мы сейчас даже не подозреваем.
— Хорошо, давай встретимся завтра утром и ты скажешь, как на твой взгляд изменится прогноз. Успеем ли за оставшиеся полтора дня или нет. И если нет, то каков будет новый срок. По нашему новому процессу оценки мы двигаемся итеративно и уточняем финальный estimate по мере приближения к нему.
Я был в отчаянии. Такой подход к работе никак не приводил к уменьшению сроков. Да, возможно изначально самая первая оценка сроков проекта была ошибочной. Но теперь уже никуда не деться. У нас был fixed price и все заложенные ранее резервы были уже давно исчерпаны. Мы доедали последнее — проектный буфер. Впереди по всем веткам плана проекта маячил критический путь во всей свой красе. Это как попасть в комнату злых кривых зеркал. Куда ни посмотрю — со всех стороны на меня пялится какое-то страшилище. Все пути проекта стали похожи на такие зеркала — везде тупик и отсутствие резервов. А по некоторым мы уже вышли за deadline. Это был конец. Очередного запроса про перенос сроков мой руководитель не примет.
Я был в сильнейшем стрессе несколько дней. Дмитрий как обычно ошибся с оценкой. А может он просто делал работу с той скоростью, как мог, хотя мне всегда вежливо отвечал «я попробую». Но, вероятно, даже не пробовал. И не напрягался. Ведь его основной функциональный руководитель был им вполне доволен независимо от результатов моего проекта. А я не имел никакой власти над Дмитрием. Ровно та же картинка была и с другими участниками моей команды. Это был мой персональный управленческий тупик. Я был готов сдаться. Признать, что из меня получился плохой и некомпетентный руководитель. И вернуться назад в разработчики.
Решившись увольняться, я подумал, что неплохо было бы встретиться с друзьями и поделиться с ними своими впечатлениями о проекте, о менеджменте и о своих «успехах». Созвонились и на следующий день собрались с ребятами после работы в кафе.
— Сергей, привет! Ну что, как твои дела? Что там твой проект? Все ОК? — друзья завалили меня вопросами.
— Увы. Полный трындец. Все полимеры профуканы. — мой голос был грустным, при этом морально мне уже было нечего терять. Я смирился с тем, что завтра утром положу заявление об увольнении на стол своему руководителю. — Как я ни старался, как ни вникал в работу сотрудников, ничего не помогло. Все оценки провалились. Мы выбились из сроков уже не помню какой раз. Команда не воспринимает меня руководителем, а только каким-то координатором задач среди других своих более важных задач. Все рассыпается. Да и команды в общем-то нет. Так, группа специалистов, работающих каждый над своей задачей в удобное для них время. Такое ощущение, что сквозь пальцы просачивается песок и в руках ничего не остается. Никаких результатов. Зато песка мы просеяли ого-го сколько. По отчетам — работ выполнено масса. Но проект в глубоком дне. В общем, я собираюсь увольняться. Завтра.
— Хей-хей! Тише! Погоди! — Коля взял слово. Он работал менеджером в большой международной IT-компании. Почему-то до сегодняшнего дня я не сообразил посоветоваться с ним, а пытался решить свои проблемы сам. — Ты знаешь, мне кажется, что тебе не хватает знаний работы с людьми. Переговоры, решение конфликтов, убеждение, мотивация и типология людей, как люди ведут себя, в каких ситуациях и почему именно так. Эти знания не требовались тебе, пока ты был разработчиком. Но вот на позиции руководителя именно они ключевые. Этот набор знаний и особенно навыков еще называют Management Soft Skills. При этом их прокачивать и развивать довольно сложно и требуется не один день регулярной практики. А у тебя проблема прямо сейчас и ее требуется решить. И только после уже можно говорить про долгосрочную перспективу.
И мы с друзьями сели обсуждать что же можно сделать в краткосрочной перспективе по моему проекту. Закончили уже за полночь. Получился план действий с готовыми шагами по проекту, вариантами развития ситуации, описанными в майндмапе. А также, о чем именно мне требуется поговорить с руководителем прямо завтра с утра. Точнее уже сегодня
— Успехов тебе! — пожелали мне ребята и мы разошлись по домам.
Как рассказал мне Сергей, история с его первым проектом закончилась не плохо. Первый блин получился не комом, проект не провалился, но только потому, что Сергей попросил четкой и понятной помощи у своего руководителя с пунктами плана действий, который они с друзьями подготовили. Если бы не это — проект бы точно был сорван.
А еще Сергей пошел учиться и прокачивать Soft Skills. Сейчас он вполне успешный руководитель IT-проектов с отличным резюме и очень внушительным опытом в индустрии. И он точно знает, что Soft Skills — умение работать с людьми — ключевое для успеха проекта. Не забываем, конечно, и про процессы, документы, планирование, риски, контракты, бюджеты и т.п. — это все Hard Skills. При этом одних Hard Skills недостаточно. К ним крайне необходимо наличие Soft Skills навыков. И вот тогда мы можем с высокой долей вероятности прийти к успеху проекта.
Хорошего дня и успехов!
