Теория проектного управления по капле в час укладывалась в моей голове в последние 9 лет. Я даже сдала PMP (пост). В какой-то момент я начала преподавать проектно-менеджерские скрепы и поняла что почти всё преподаваемое на курсах и даже в универах - дикий булшит.
Формируем проблему
Попробуйте объяснить студенту второго курса без опыта в ИТ вот эту конструкцию. Да даже не студенту. А потом расскажите как это повлияет на его ежедневные дела. Оно-то повлияет, но не факт что завтра.
И вот эту
А теперь вспомните что работает в реальном мире. И когда вы в последний раз высчитывали критический путь руками. Когда его вообще высчитывали. Ладно, когда для него хватало реальных данных. Я не верю что буквально сегодня утром вы аккуратно рассортировывали stakeholders на кучки и последовательно документировали как коммуницировать с каждым из них. Ну, вы поняли.
Первая лекция по управлению проектами третьего семестра магистратуры по политологии, крутой итальянский ВУЗ. И бедным студентам пытаются скормить все процессы как завещал PMI, одним скопом. Ладно бы рассказали и забыли, так им потом это сдавать!
Соответственно, желающие стать проектными менеджерами начинают смотреть на доступные курсы. Они считают, что им на старте карьеры тоже нужно знать по какой формуле высчитывается насколько их проект on track с финансовой стороны вопроса. Некоторые проваливаются в Agile, но там начинается совсем другая балалайка, о ней сильно ниже.
В то же время, потенциальный работодатель часто не может придумать ничего лучше, кроме как активно гонять кандидатов по теории. Получается замкнутый круг: чтобы пройти собес или получить повышение через assessment, нужна теория. Какая - никто не знает. И мы учим все на свете, от planning poker до списка артефактов на фазе закрытия проекта размером с постройку нового самолета. Потому что PMBOK от PMI и ему подобное - наше всё (нет).
В реальности же мы будем управлять хорошо если двумя командами и пилить правый верхний угол левой ноздри организма нашего продукта. Даже не ухо-горло-нос!
Что преподают / пытаются изучить
Coursera: в лучшем случае идем по областям знаний от PMI. Планирование, бюджет, риски, что такое проект. Вот цитата из описания курса по техникам оценок: "create network diagrams, determine the critical path and calculate float, define milestones and a create a milestone schedule".
Все бы хорошо и расписание проекта с milestones правда нужно знать и уметь делать. Но это можно объяснить на пальцах за чашкой пива, а не тратить шесть пар. Network diagrams в реальной жизни строятся только на огромных проектах и часто только потому что это нужно по контракту. Обычно же мы ограничиваемся task tracker в какой-нибудь тулзе.
University of Virginia: все то же, под другим соусом. Тут же мелькают Cost Risk Analysis и Earned Value.
Однажды я помогала одному менеджеру подготовиться к assessment-у чтобы получить повышение. Там ему сказали что из-за его понимания Earned value он может идти на Senior-а. Я спросила, а когда он в последний раз считал риски или прогресс проекта в деньгах. Он засмеялся и ответил "Никогда". Что и требовалось доказать.
Посмотрите направо. Вот где выращивают проектных управленцев, кто может только в Excel маньячить!
Почему-то в головах преподавателей до сих пор жива идея что на каждый чих нужна табличка. При том что в реальности бизнес-чуваки не читают ничего длинее одного твита и чаще всего можно выразить ровно то же через один слайд презентации.
Онлайн-курсы в рунете очень отличаются на вкус и цвет, однако почти все содержат что-то такое:
Я могу понять зазубривание разных ISO под задачу. Или изучение способов реагирования на риски для проекта с внешним подрядчиком, где риск = деньги = убытки по контракту. Но зачем это дается в каждом втором курсе "Станьте проектным менеджером через 48 часов занятий", я решительно не понимаю.
Почему теория не работает
- На рынке бардак: в одном и том же тайтле могут находиться ну совсем разные требования / люди. Стандартизация через через теорию проблему не излечит.
Учите теорию когда нужно полечить небольшой кусочек и уточняйте у более опытных коллег какие именно инструменты помогут.
Я как-то пришла на очередную knowledge-sharing session в комьюнити проектных менеджеров. И там на сложных щах два часа рассказывали как управлять знаниями внутри проекта. Возможного к применению материала - 0. Теории - два часа.
- Рынок не знает как проверить знания менеджера и гоняет по ненужной теории. Которую начинают учить все, кому полезно и не очень.
Давайте людям кейсы и смотрите как они думают! Пост
- Замучанный теорией менеджер не умеет думать, а фокусируется только на наборе файликов, который ему нужно сварганить. Этакая роботизация населения. Времени в конце дня у теоретика остается мало. Потому что ваш статус репорт или трекер становятся неактуальными через минуту после публикации. Всегда.
Нет, я не вижу ничего плохого в Scope statement на каждый проект, но вашу ж ять! Не стоит внедрять все бумажки сразу.
- Бедный менеджер часто не понимает что он делает не так. Он же внедряет все по учебнику! В итоге человек записывается еще на 10 курсов и бежит получать +5 новых сертификатов. Неуверенность в себе или качество работы это не исправляет.
Используйте комьюнити и активно просите совета для конкретной ситуации. Не бойтесь признаться что все плохо. Более опытный коллега подскажет инструмент и объяснит его за несколько минут. Еще и покажет на примерах.
- Не разделяются сорта проектных менеджеров: чистому scrum-master-у сложно разобраться (да и зачем ему) в сухой олдскульной теории. А когда разбирается, понимает что для его вселенной размера одной команды оно все нафиг не надо. Он идет учить SAFe или что похуже Здесь голова бедняги ломается совсем. Хорошо если тут человек свернет в сторону теории Agile, о нем ниже.
Я бы хотела применять всю или хотя бы 1/5 от известной мне теории, но реальность оказывается совсем иной. А применять for the sake of it это групо и неэффективно.
- Через пару лет работы менеджер хочет получить бумажку, подтверждающую что он молодец. И идет зубрить теорию. Сдал - забыл. И продолжает работать как раньше.
Реальность != теория. И прилежный студент теряется в неопределенности. И зачем время на экзамены терял...
Хорошо, а что не так с Agile
Недавно в Клубе бродил известный видос про Agile is dead. Этот блок ровно про то же.
Компании внедряют Agile как религию. Однако передвигать стикеры != эффективно брать задачи по мере готовности предыдущих со следующих этапов.
Оу, Agile не работает! Давайте отправим команду на тренинг!
Тренинги сфокусированы или на зарабатывании денег, или на хипстерских штучках, которые неприменимы к реальности среднего индивидуума. Вот приходит человек после тренинга, воодушевленный такой. И начинает приблуды прикручивать. Хорошо если они будут полезны, чаще окажется наоборот. Проходит месяц, человек расстроен. Повторит три раза и нафиг разочаруется в идеалогии. Будет с грустными глазами работать как раньше.
Часть тренингов / курсов / книг рассказывает про что угодно, кроме взаимодействия внутри команды или общению с людьми. Agile коучи бывают разными, но магическим образом некоторые из них способны превратить 15-минутный созвон который все ненавидят в продуктивный митинг, желанный всеми. Как, спросите вы? Уж точно не через теорию. Ну, по крайней мере хорошие коучи.
В итоге мы оказываемся в индустрии Agile-Scrum-Kanban-процессы-коференции, а про mindset все забыли. Так что теорию Agile тоже можно задвинуть на дальнюю полку. В отличие от mindset и точечных практик для вашего размера проблемы / команды / проекта.
Что нужно преподавать / изучать
Вот тут неплохо рассказано каким суперменом должен быть ПМ. И там очень мало про RACI, Critical path и прочих священных коров.
Нужный набор скиллов, имхо:
- Навыки переговоров
- Теория лидерства
- Управление людьми
- Объяснять сложное простым языком
- Фасилитация
- Тайм-менеджмент
- Занудство follow-up на любой чих с пониманием что это за action items вы пинаете третью неделю подряд и зачем они нужны
- Слушать и слышать, а не делать вид
- Коммуникация со сложными людьми
- Писать письма простым языком
- Понимание как работает голова инженера
- Понимание целей и приоритетов ваших stakeholders
- Понимание вашего домена
- Способность переключаться между уровнями абстракции aka 1 команда <> роадмап 10 команд на два года
- Спокойствие в любой ситуации
- Переваривание хронической неопределенности
- Account management (держание заказчика за руку и почесывание за ушком когда надо)
- Жизненный реализм
- Умение аргументированно сказать нет
- Отсутствие страха получить по ушам
- Эксперементаторский дух
- Способность попросить товарища о помощи
- Самостоятельность / независимость
- Приобретенное занудство (натуральное часто сложно контролировать)
- Смирение с фактом что хорошо не получится никогда
Как становится заметно, это в бОльшей степени soft skills. А суровая теория или придет по мере прогресса в карьере, или отвалится за ненадобностью. Когда я шла на PMP, мне теория была нужна для систематизации знаний и это справедливый повод ее учить. Но до этой точки еще нужно добраться.
Список литературы
Essential Scrum
Project Management basics
Оргуправленческое мышление Щедровицкого
Черный лебедь Талеба
Мифический человеко-месяц
Проект Феникс
The Goal
Dao Toyota
Общаться с ребенком Как
UPD из комментов:
«Простите, я разрушил вашу компанию»
Не рекомендую:
PMBoK
Как пасти котов
7 навыков высоко-эффективных людей
Добавьте свои (не)любимые книги
Зачем это всё
Теория не заменит практики! Мне очень грустно видеть проектных менеджеров, кто сдал PMP и следует его заветам без понимания продукта. То есть они ни на что не влияют, и потенциально могут быть заменены AI лет через 7-10. То же относится к адептам бесконечных Excel-табличек, кто не знает о чем его проект и какие проблемы пользователей мы решаем.
Учитесь думать, не залипайте в таблички со статусами задач. ПМ, который способен вспомнить что вот тут мы забыли сбегать к закупкам, а вон там надо бы процесс деплоя улучшить, бесценен.
Найдите себе ментора и ходите за ним хвостиком полгода-год. Поменять ментора, размешать, повторить. Следите чтобы ментор или разбирал ваши случаи, или рассказывал что и как он делает на своем проекте. Теория и тузлы ради тулзов не работают.
Я считаю, что начинать учить теорию классического проектного управления стоит годика эдак через два-четыре от начала работы. Только после первых набитых шишек. И не лезте в хардкор формата PMI, разных ISO и всей этой дичи. Оно понадобится через много лет, если вообще понадобится.
В первые три-пять лет опыта работы нужно научиться сначала управлять одной командой. Потом двумя, потом жить без команды. Наконец, усвоить десяток принципов и успокоиться. Теория прорастет или сама, или хорошо ляжет в голову когда есть достаточно разнообразного опыта.
И все равно в какой организации вы работаете, учиться важно всегда. Только вот фокус этого обучения будет разный. Следовательно, поймите какие скиллы нужны именно сейчас и забейте на остальную теорию. Возможно, вам для нынешней роли стоит вкурить бизнес-анализ. Или дизайн приложений. Или еще что-то ну совсем не про теорию проектного управления.
Однажды у меня был проект в Core Infra. И чтобы лучше им управлять, я скурила пяток курсов и книг по организации датацентров чтобы их мигрировать. Когда до меня дошло чем занимаются люди вокруг, жить стало сильно проще и я поняла почему доставка коробки проводов важнее согласования прав доступа к серваку.
Или вот, когда-то давно делали мы большой и страшный редизайн продукта. Пришлось вкурить как копирайтеры пишут текст и почему поля ввода должны быть на одном экране. Это позволило сфокусироваться на сборе требований и экспериментах, а не только задавать вопросы разработчикам "когда там готово-то будет".
Summary: развивайте soft skills и понимайте свой проект. Тогда вы точно станете более успешным проектным менеджером. Остальное приложится.
😱 Комментарий удален его автором...
Опять спойлеры к еженедельному дайджесту клуба.
Подписываюсь.
Про тот же самый набор скиллов, но с другой стороны: на удивление зашел фильм Лок.
Посмотрите, он по нынешним меркам коротенький, меньше полутора часов. Квинтэссенция ПМ-ства "без учебников": применяемых в реальной жизни подходов и методов. Можно разбирать на учебных курсах.
Я в свое время поучился PMI, но с PM у меня карьера не сложилось. Сейчас общаюсь много со строительными частных домов и часто заходит разговор о проектном управлении и менеджеров. Когда им рассказываешь, что управление проектом это не про Ганта, а про коммуникации, накопления опыта и знаний, управление людьми и ресурсами, они делают большие круглые глаза. У большинства в лучшем случае PM = план-график. Но при этом они как-то умудряются строить и строить параллельно по 5 домов которые не разваливаются и приносят прибыль.
А Стивен Кови чем не угодил? :) И что он вообще тут делает в списке литературы, я его ожидал не больше"Сумерек".
И хотел спросить, с "теорией ограничений" у вас был практический опыт - критическая цепь, вот это все?
Если пробовали, но не полетело, расскажите, пожалуйста, в чем были проблемы, интересно :)
К списку рекомендуемой литературы добавил бы «Простите, я разрушил вашу компанию». Там нет про эджайл, но много отрезвляющего про весь этот теоретический инструментарий
Да, вот как-то удивительно это бывает, что человек может вызубрить все термины из Agile и не понимать, что Agile - это про почаще показывать своё говнище тому, кто его заказывает и тем, кто им будет пользоваться.
Хотел бы я получить скилл загружать эту выжимку из опыта напрямую в мозг некоторым руководителям с предыдущих мест работы. Спасибо за пост!
@Covectb_cobaka, если не секрет, почему выпас котов в нерекомендуемых? Вроде считается "классической" книгой.
Отличный пост, готов кидать его в лицо каждому, кто хоть краем мысли решит попробовать себя в управлении.
Кроме одного слова (закрыл глаза и уши, проговаривая сквозь зубы) - фасилитация. Оно меня угнетает тем, что ни один человек, который его употребил вслух не смог его перевести не задумываясь и в 1 предложение. Назовите это уже "методикой способствования", а то менеджеры застревают в нем, не могут дышать и погибают.
Простите, 2 года не слышал это слово и вот оно опять.
У меня было пару курсов про ПМ. ВШЭ и курсера. Кстати, ВШЭ был отличный курс. Пока что прям это мой идеал
Фишка в том, что в тот момент я пытался внедрить управление проектами в своем отделе. Но это был хардверь отдел. И многое оказалось полезым и удобным.
Потом я ушел в софт девелоперы. Видел немного всякой имитации ПМ и Аджайл... казалось мне я понимаю все эти шутки...
А потом я оказался в большой международной конторе. И увидел где и как работает Аджайл, особенно если н работает правильно. И пользу, и скорость и вот это все.
Теперь когда я слышу про "Аджайл гавно", то у меня две варианта - либо он вам не нужен, либо вы не умеете его готовить.
С ПМ сложнее, и вопрос "как правильно учиться и применять" для меня все еще открыт. Хотя бы потому что я глубоко в это пока перестал соваться на нынешней позиции
Самое удивительно, что можно написать ровно такой же текст про "Solution Architecture", "Networks" и многое другое. В реальности это проблема не конректной области знаний, не проблема теории, а проблема сложности мира как такового.
На примере тех же сетей: приходят специалисты обученные и сертифицированные по CCNP (Network Profeccional), умеют в уме считать любые маски сетей, знают все параметры BGP наизусть и не могут поднять соединение с провайдером.
На примере того же Solution Architect: есть замечательный стандарт TOGAF. Есть тонна учебников по нему и курсов. Но если применение этого заходит чуть дальше чем "мы работаем по TOGAF - мы тоже - ну тогда поехали делать как надо, а не как в книжке" проект летит к чертям.
Вся эта теория нужна и важна в двух случаях:
У тебя есть "выпускник универа" которому надо войти. У него 0 опыта у него нет никаких навыков и рассказывать ему про "Слушать и слышать, а не делать вид" бесполезно (а что это?) Поэтому обвешиваем его теорией и пускаем в поле. И там он либо научится быть человеком, либо пойдёт искать другую профессию.
У тебя есть PM/Architect/Networkl Engineer с 10+ лет опыта. И вот эта теория очень хорошо систематизирует знания, даёт дополнительные методы которые не пришли из "опыта" (но опыт уже помогает их встроить куда надо и как надо).
Так что как бы любая "теория" для чего-то для нужна. Но как всегда любое слепое применение инструмента - зло. Как бы хорош или плох этот инструмент не был.
Пока читал, ловил какие-то сайд-ощущения из мира разработки. Аналогичная история: душные срачи на тему того, что кто-то должен знать некую базу, сумрачные гении со своими опросниками на входе в многие компании. А в итоге ценность разработчика вообще находится процентов так на 90 в том же списке, что и у менеджера приведено про способность внятно и просто коммуницировать, прикидывать риски "на глазок", работать с неполной информацией и в неизвестности и вот это вот все. Но самое смешное, что такие вещи не измеряются, потому живем с тем, что есть.
Чёт заметил что в списке навыков нет "управления конфликтами". Как без этого?
И хорошей теории вроде полно.
Из практических советов (подходит не только PM'ам) могу добавить насчет митингов:
Время - это очень дорого.
А где же про бесполезность проектных метрик?) Ну и раз обосран был классический предиктивный подход от РМИ, надо было что ли про манагемент 3.0 упомянуть, как альтернативу.
TLDR: Project management - это когда маленький человек в ужасе хватается за любые методики, не успевает к дедлайну, и никто ему не может помочь. Никто.
Великолепный пост, который вышел за рамки рассматриваемого явления и коснулся трансцендентальных вещей. Спасибо.
Классный пост, спасибо!
Довелось немножко покрутиться и в строительной отрасли, и в IT. В стройке сетевые графики суперполезны, даже в самых простых проектах, когда забор красишь. В IT сетевые графики нафиг не нужны, только создают обманчивую видимость порядка. В этой части я полностью согласен с постом.
Я бы предположил добавить к
еще такое: несите за проект ответственность.
Что бы ни случилось в проекте, виноват всегда PM. Это аксиома. Виноват без самокопания, и разрушения своей картины мира, не потому, что он плохой человек, и надо срочно надо выгореть и уйти с котомкой в туман, бросив проект на произвол судьбы. А потому, что не предусмотрел, не проверил и не перепроверил, не отстоял своего мнения, нанял не тех людей, не объяснил или не понял сам. И он пытается учесть эти ошибки на ходу, и управляет проектом дальше. Продолжает пилотирование, как об этом пишется в "Чек-листе" Гаванде.
Шкура на кону Талеба тоже про это, да.
Еще вот здесь неплохо:
https://m.signalvnoise.com/its-always-your-fault/#.2mq7obc7m
Еще попадался удачный пример: PМ должен всегда, в любое фазе проекта, быть способен на листке бумаге или салфетке рассчитать своей планируемый бонус с проекта. Если не может - значит, у проекта серьезные проблемы - с контролем, финансами, планированием, или со всем вместе.
Я аккуратно дополню, что эджайл методики это методики не проектные, а продуктовые и требуют некоторого сдвига сознания с проекта на продукт. И я смотрю на эти таблицы, так сложно, не помню чтобы они после презентации плана вообще где-нибудь появлялись.
Вот это твой Нужный набор скиллов, имхо это огненное огнище, потому что видно, что ты на работе и в жизни видела некоторое дерьмо. Сразу захотелось с тобой поработать, жаль что ты больше не ходишь в корпорации, а то б позвал как только закончится hiring freeze :-)