Поняв, что двигаться быстрее и делать все больше и больше в неправильном направлении – не вариант, я стал смотреть в сторону процессов управления. Но каких?
Я сообразил, что мне нужна помощь или толковый совет. К сожалению, атмосфера в компании не располагала к доверию и спросить совета у руководителя я не мог. Это уже должно было мне о многом сказать, но в то время я не обращал внимания на такие “мелочи”. Синдром отличника также делал свое дело и вредил мне, не позволяя задавать вопросы и просить о помощи.
На каком-то из локальных ивентов по менеджменту, куда я таки пошел, несмотря на жесточайший цейтнот в проекте и недостаток свободного времени, я услышал фразу “правильные процессы”.
– Вот то, что мне нужно, – подумал я. – Только что значит “правильные”?
Наверное, правильные – это те, которые описаны в умных книгах или в школах менеджмента. А какая у нас самая авторитетная организация про менеджмент в мире? Конечно же 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 навыков. И вот тогда мы можем с высокой долей вероятности прийти к успеху проекта.
Хорошего дня и успехов!
Комментарии (11)
sotnikdv
08.04.2018 02:04+1Классно, всю статью описываем проблему, а потом в двух абзацах «а потом он поговорил с друзьями, они придумали план, поговорил с начальством и все стало хорошо»
В чем ценность статьи? В нераскрытом тезисе, что менеджер управляет людьми и должен уметь с ними говорить?
Lofer
08.04.2018 12:01На мой взгляд, задается (обозначается?) весьма интересная проблема: использование всяких PMBok (Scrum) это движени в сторону более формализированного общения и взаимодействия. Попытки минимизировать какие-то субъктивные критерии и мехнизмы в проектном управлении.
А после делается рекомендация — надо применять «Soft skill», а это движение ровно в противоположную сторону.
Что-то вроде «я тебя не буду бить ногами если ты ...»?
Не вижу разницы между «бить ногами физически» и «психологическим давлением» что бы вести проект внутри команды. Либо карты на стол и соблюдение условий с обеих сторон — или одна из сторон начинает «вооруженный нейтралитет».
Изначально это не верная стратегия (на мой взгляд), хотя иногда необходимое зло.sotnikdv
08.04.2018 22:49Вы же понимаете, что soft skills это общее название всего, что относится к взаимодействию с людьми? Это даже не вопрос менеджмента, это обязательное качество любого участника команды, просто менеджмент их более интенсивно использует.
А процессы это определение базовых правил, по которым действует проект. Без процессов разработки не получится и вопрос больше в оверхеде, разумности и возможности подстраивать процессы под реалии проекта.
Работа менеджера это именно коммуникации И настройка и поддержание процессов. Ни о каком «движении в противоположную сторону» речь не может идти от слова совсем. Это как скакали на левой ноге, поняли, что получается медленно, решили совсем сменить подход на противоположный и начали скакать на правой.
Какого черта у нас менеджмент размножается методом повышения до уровня некомпетенции людей, которые уже в конце проваленного проекта начинают брать книгу по специальности, а людей боятся до самого конца — тайна великая есть.
Также я не понимаю нафига люди лезут в менеджмент без даже попытки почитать что либо. Считают, что менеджмент — ненастоящая работа, сидишь себе царьком, да ценные указания раздаешь? «Не имел власти над»… Родной, бодливой корове бог рогов не дает. Учись коммуницировать, твой инструментарий это процессы и взаимные коммитменты между кучей уровней, а не власть.
И какой гений им эти позиции предлагает без обучения и менторства? Такой же самоучка? Почему нет элементарных азов и почему этому менеджеру дали рулить живыми людьми? У которых своя жизнь, мотивация, чувства и т.д.? Которые стоят компании дорого во всех смыслах и которых найти на рынке труда непросто?
Я не имел власти… А поговорить ты с ним мог, царь? Он не холоп твой, а такой же член команды, просто тебе доверили координацию, а ему технику. Что у него, почему и т.д.
P.S. Ну и смешивать PMbok и SCRUM не стоит. Явления разного порядка.Lofer
09.04.2018 01:42Вы же понимаете, что soft skills это общее название всего, что относится к взаимодействию с людьми? Это даже не вопрос менеджмента, это обязательное качество любого участника команды, просто менеджмент их более интенсивно использует.
Программисты между собой никак не общаются что бы код написать? или тестеры? или бухгалтера? А бизнес аналитикам общение не требуется? или все эти «ресурсы» между собой никак не общаются?
Возьмем к примеру такую «простую» штуку, как «Communication Plan» — документ регламентирующий процессы общения (кто, когда, о чем и как должен быть информирован) внутри команды\проекта.
Его же придумали по какой-то причине? Устав армейский, регламентирующий общение. Формализированные нотации (UML, IDFx, BPMN и т.д.)
В этом то все и дело.
Все человеческое общение сводится к первому шагу — общий словарь понятий (глоссарий). Не будет его — дальше не имеет смысла. Выделять какую-то группу "… их более интенсивно использует"? Это заблуждение.
Работа менеджера это именно коммуникации И настройка и поддержание процессов.
Мне больше нравится другое определение — менеджер, это человек который должен решать те проблемы, для которых еще нет решений (инструкций). Результат его работы — это инструкции, как поступать в некоторой ситуации, что бы достичь результата.
Для поддержания процесса — достаточно надсмотрищика или любой системы с движком бизнес процессов :)
Ни о каком «движении в противоположную сторону» речь не может идти от слова совсем.
Плодятся новые сущности (процессы), просто «потому что Soft Skills»? так это выглядит.
korus
08.04.2018 12:04А я не имел никакой власти над Дмитрием.
Т.е. у человека не было полномочий даже, какой же он менеджер?:)
По статье — воды много, результата мало. Тот же PMBoK, вид сверху. Там говорится: вот, возьмите шаблон процесса и всё будет идеально, здесь же — про Soft Skills, с тем же результатом, только даже без описания совершённых действий. Хотя в жизни всегда нужен баланс и учёт рисков. В каком-то проекте не критично будет просто задать план проекта, распределить роли и забыть про него (когда команда даже без тебя в состоянии не напрягаясь вытащить его, т.е. её навыки, как технические, так и «гибкие» достаточны или избыточны для этого проекта), в каком-то обсуждать и договариваться как внутри команды, так и за её пределами.
В этой ситуации я бы ещё в середине проекта (когда моя команда постоянно нарушает сроки, т.е. или не компетентна, или занята другими делами) привлёк аналитика (если самостоятельно не разбираюсь в данной технологии) + да, пообщался с другими руководителями, в чьих проектах моя команда также участвует сейчас.
Если проблема в компетенции, то обучение\замена команды\перенос сроков в соответствии с этим.
Если проблема в том, что команда занята на других проектах, то обсуждения\договоры\мотивация-демотивация\смена команды\согласование графика работ. Например, 3/2 — 2 дня человек мой, 3 дня нет.
Проблема ещё часто в том, что многие не учитывают снижение эффективности человека при переключениях (если 2 проекта, то до 30% рабочего времени, у некоторых больше, у некоторых меньше). И это также необходимо закладывать в календарные сроки.
Как определить, когда нужно подключать дополнительного аналитика или начать паниковать? В этом как раз помогает выстроенный процесс, наличие плана проекта и т.д. Т.е. управление — это не только Soft Skills или Hard Skills. Это скорее умение достичь результата используя сбалансированные ресурсы и инструменты (командные и личные качества и скиллы\шаблоны\процессы).
SergeyMats
08.04.2018 15:38А что в итоге сделали-то? Так подробно к этому подводили, аж на две части растянули, а по сути только общий вывод даже без примеров…
«- Вовочка, расскажи нам про верблюдов!
- Ну, верблюды живут в Африке...
- А суть-то, суть?
- А суть они под пальмы!»
NetViruS
10.04.2018 15:49Мда. Я ждал 2-ой части но это просто фиаско. Само собой выражение — "я попробую" не приемлемо. Советую автору почитать "Законы победителей" Бодо Шефер. Там как раз рассказывается о том, что значит эта безтолковая фраза. По большей части то, с чем столкнулся автор — это обычные ничем не замотивированные офисные лентяи. Тут хорошо могла бы помочь известная книга "Бесжалостный менеджмент". Ибо автор был руководителем но не считал себя сам таковым.
KM32
10.04.2018 15:49Добрый день!
Очень хотелось бы увидеть третью часть с подробным описанием, как и что делал ваш друг :)
Первые две части были отличным вступлением.
А в целом то, что не хватает полномочий — это норма для менеджеров проектов.
В таком случае можно сделать так:
1. Коммит от нач. отделов по срокам его подчинённых. Можно и перед заказчиком.
Это справедливо — разделять ответственность с владельцем ресурсов. Часто нач. отделов не беспокоит, чем его подчинённые заняты если не прилетает эскалаций и «все тихо».
2. Разбивка задачи на более мелкие с расстановкой промежуточных вех и коммиты под них от исполнителей.
Работа занимает всё отведённое на неё время. (с) Паркинсон.
Проваливают строки = эскалация в мягкой форме, пытаетесь договориться о SLA и за чей счёт дальше гуляем. Далее по ситуации.
3. Понять на сколько интересен проект исполнителям, если не интересен, то попробовать изменить на тех, кому интересен.
Казалось бы, банально, но часто рядовых гребцов даже не спрашивают, что они хотят и кто бы их мог заменить.
Из «софт» составляющей:
1. Налаживать рабочие отношения с нач. отделами.
2. Перенимать авторитет заказчика и заинтересованных лиц в проекте (если он — авторитет есть).
3. Налаживать рабочие отношения с исполнителями.
Менее формально артефакты PMI (PMBoK) можно составить так:
Устав проекта = договорённости с заинтересованными лицами и исполнителями, можно устно и в почте подкрепить договорённости: как, кто и что будет делать для проекта.
План управления проектом = аналогично как с уставом, можно на берегу или в процессе договориться с членами команд:
1) Что делать если заказчик меняет скоуп проекта.
2) Что делать если исполнитель ошибся с оценкой.
3) Что делать если исполнитель не выполнил согласованные работы в срок.
и т.п.
Два артефакта могут по ходу изменяться или наполняться новыми договорённостями, это не отлитые в бетон вещи.
Всё достаточно банально и не претендую на полноту, но сила в простых вещах.
Lofer
То есть требуется еще знания психологии. Но ведь какой нюанс — психология подразумевает два правила: культурные различия и быть «вне процесса».
Культурные различия — подразумевает что вы не должны судить только по своим критериям, но и должны знать чужие (особенно если "… иншааллах", говядина для индусов и т.д.).
Быть вне процесса — не ругатья с «ленивым программером», а смотреть как с ним ругается Пупкин.
Обучение психологии — лет пять учебного заведения.
Таким образом в нормальном мире — проектный менеджер будет готов лет после 15 обучения и некоторой практики :)
Или под Management Soft Skills — подразумевется нечто другое? Есть какой-то чеклист, тесты-сертификаты для Soft Skills?
Levitanus
Ну, судя по всему, да. Такая же Байда с преподаванием, можно сколь угодно хорошо знать свой предмет, но без психологии, нормальной, от общей, до социальной, теории способностей и прочей полезной фигни, вкупе с методикой, хорошо сформулированной, по конкретному предмету, а не из разряда «делай так», только обдирать нерадивых клиентов получится, или просиживать штаны с неблагодарными тварями в универе)
А это мин. 15 лет + 2-5 лет на конкретную скилловую нишу в области своей проф компетентности. Зря, что ли на хабре столько статей за бездарный менеджмент?