(часть #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 навыков. И вот тогда мы можем с высокой долей вероятности прийти к успеху проекта.
Хорошего дня и успехов!
Автор: Алексей Егошин
