Project Management: засуньте теорию в Ж!
 Публичный пост
2 октября 2020     5523   

Теория проектного управления по капле в час укладывалась в моей голове в последние 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 часов занятий", я решительно не понимаю.

Почему теория не работает

  1. На рынке бардак: в одном и том же тайтле могут находиться ну совсем разные требования / люди. Стандартизация через через теорию проблему не излечит.

Учите теорию когда нужно полечить небольшой кусочек и уточняйте у более опытных коллег какие именно инструменты помогут.

Я как-то пришла на очередную knowledge-sharing session в комьюнити проектных менеджеров. И там на сложных щах два часа рассказывали как управлять знаниями внутри проекта. Возможного к применению материала - 0. Теории - два часа.

  1. Рынок не знает как проверить знания менеджера и гоняет по ненужной теории. Которую начинают учить все, кому полезно и не очень.

Давайте людям кейсы и смотрите как они думают! Пост

  1. Замучанный теорией менеджер не умеет думать, а фокусируется только на наборе файликов, который ему нужно сварганить. Этакая роботизация населения. Времени в конце дня у теоретика остается мало. Потому что ваш статус репорт или трекер становятся неактуальными через минуту после публикации. Всегда.

Нет, я не вижу ничего плохого в Scope statement на каждый проект, но вашу ж ять! Не стоит внедрять все бумажки сразу.

  1. Бедный менеджер часто не понимает что он делает не так. Он же внедряет все по учебнику! В итоге человек записывается еще на 10 курсов и бежит получать +5 новых сертификатов. Неуверенность в себе или качество работы это не исправляет.

Используйте комьюнити и активно просите совета для конкретной ситуации. Не бойтесь признаться что все плохо. Более опытный коллега подскажет инструмент и объяснит его за несколько минут. Еще и покажет на примерах.

  1. Не разделяются сорта проектных менеджеров: чистому scrum-master-у сложно разобраться (да и зачем ему) в сухой олдскульной теории. А когда разбирается, понимает что для его вселенной размера одной команды оно все нафиг не надо. Он идет учить SAFe или что похуже Здесь голова бедняги ломается совсем. Хорошо если тут человек свернет в сторону теории Agile, о нем ниже.

Я бы хотела применять всю или хотя бы 1/5 от известной мне теории, но реальность оказывается совсем иной. А применять for the sake of it это групо и неэффективно.

  1. Через пару лет работы менеджер хочет получить бумажку, подтверждающую что он молодец. И идет зубрить теорию. Сдал - забыл. И продолжает работать как раньше.

Реальность != теория. И прилежный студент теряется в неопределенности. И зачем время на экзамены терял...

Хорошо, а что не так с 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 и понимайте свой проект. Тогда вы точно станете более успешным проектным менеджером. Остальное приложится.

Связанные посты
82 комментария 👇
Yury Katkov, миддл формошлёп 3 октября 2020

Да, вот как-то удивительно это бывает, что человек может вызубрить все термины из Agile и не понимать, что Agile - это про почаще показывать своё говнище тому, кто его заказывает и тем, кто им будет пользоваться.

  Развернуть 1 комментарий

@ganqqwerty, и добавить нечего :D

  Развернуть 1 комментарий

Опять спойлеры к еженедельному дайджесту клуба.

  Развернуть 1 комментарий
Kirill Nikitin, ИТ консалтинг 5 октября 2020

Самое удивительно, что можно написать ровно такой же текст про "Solution Architecture", "Networks" и многое другое. В реальности это проблема не конректной области знаний, не проблема теории, а проблема сложности мира как такового.

На примере тех же сетей: приходят специалисты обученные и сертифицированные по CCNP (Network Profeccional), умеют в уме считать любые маски сетей, знают все параметры BGP наизусть и не могут поднять соединение с провайдером.

На примере того же Solution Architect: есть замечательный стандарт TOGAF. Есть тонна учебников по нему и курсов. Но если применение этого заходит чуть дальше чем "мы работаем по TOGAF - мы тоже - ну тогда поехали делать как надо, а не как в книжке" проект летит к чертям.

Вся эта теория нужна и важна в двух случаях:

  1. У тебя есть "выпускник универа" которому надо войти. У него 0 опыта у него нет никаких навыков и рассказывать ему про "Слушать и слышать, а не делать вид" бесполезно (а что это?) Поэтому обвешиваем его теорией и пускаем в поле. И там он либо научится быть человеком, либо пойдёт искать другую профессию.

  2. У тебя есть PM/Architect/Networkl Engineer с 10+ лет опыта. И вот эта теория очень хорошо систематизирует знания, даёт дополнительные методы которые не пришли из "опыта" (но опыт уже помогает их встроить куда надо и как надо).

Так что как бы любая "теория" для чего-то для нужна. Но как всегда любое слепое применение инструмента - зло. Как бы хорош или плох этот инструмент не был.

  Развернуть 1 комментарий

Как всегда великолепная подача, и очень в тему жизненной ситуации. Чем больше твоих постов читаю, тем больше понимаю какой я крутой ПМ. 🤭

А то я всё комплексую, что хард скиллс не те. А оно вон как!

Еще раз, большое спасибо!

  Развернуть 1 комментарий

@VBodrov, хардскилс ПМа это умение составить такой timeline, который будет учитывать критические зависимости, основные вероятные риски и scope проекта. Со всеми согласовать, никого не забыть и оттрекать чтобы все присутствущие одинаково понимали когда будет готово и что именно мы делаем. А главное, зачем мы это делаем.

Какими именно инструментами это делается - вопрос десятый. Бывают успешные проекты, которые сдвинуты по срокам. А бывают неуспешные когда ожидания до и после деливери расходятся, хотя все по плану.

Я не адепт концепции "теория зло, ни-ни", я здесь скорее про изучение того что полезно сейчас, а не попытку проглотить весь PMBoK потому что "это же база".

  Развернуть 1 комментарий

@Covectb_cobaka,

одинаково понимали когда будет готово и что именно мы делаем.

Я вот всегда именно так свою работу и понимал. Особенно "что именно мы делаем".

Вот картинка, которая хорошо проблему иллюстрирует.

С космическими аппаратами точно такая же история. И кто смог одинаковую картинку в головах всех stakeholder'ов построить - тот красавчик.

  Развернуть 1 комментарий

@Covectb_cobaka, Если называть это PM, то, конечно, книжки про PM не помогут. Но это не PM, это куча разных практик.

Конкретно, практики как минимум следующие:

  • Governance (общение с внешними стейкхолдерами)
  • Requirements Engineering (утрясание того, что, собственно, хотят внешние стейкхолдеры/рынок, часто называется Product Management)
  • Architecture (утрясание общей картинки внутри проекта — то, что на картинке в предыдущем комментарии — на основании требований)
  • Leadership (удостоверение, что все участники проекта заняты по уши своими делами, и не лезут в чужие)
  • Project Management (ускорение и удешевление прохождения кейсов/тикетов/задач до завершения)

PMBoK только про последнее! На всё остальное свои учебники.

  Развернуть 1 комментарий

@dottedmag, у вас отлично получилось перефразировать основную мысль этого поста. Поделитесь учебниками?

  Развернуть 1 комментарий

@Covectb_cobaka, Governance не знаю, не занимался особо.

Requirements Engineering и Architecture — это в Systems Engineering. Есть хорошее введение — Левенчук "Системное мышление 2020" и его же "Системноинженерное мышление". Там куча ссылок на разнообразные книги по этим темам. Есть ещё SEBoK, но он старый.

Leadership не знаю, сложно с этой практикой, мало кто этим занимается в чистом виде.

Project Management собственно PMBoK, и Reinertsen "Principles of Product Development Flow".

  Развернуть 1 комментарий

@dottedmag, не согласен с формулировкой про лидерство.

Если трактовать, как "создание атмосферы, в которой все не только хорошо делают свои дела, но и:

  1. думают о том, как можно делать лучше свои дела;
  2. думают о делах других, и как можно делать их лучше;
  3. делают/помогают другим делать, что надумали в пунктах 1 и 2."

то, есть книга про такое лидерство - Tribal Leadership. Искал ссылку, увидел еще 15-минутный TED talk автора. Можно им заменить книгу, в принципе)

  Развернуть 1 комментарий

@yand,

Это другие практики.

думают о том, как можно делать лучше свои дела;

Enterprise Engineering

думают о делах других, и как можно делать их лучше;

Enterprise Engineering

делают/помогают другим делать, что надумали в пунктах 1 и 2."

Enterprise Change Management.

  Развернуть 1 комментарий

@dottedmag, и все же обрати внимание, пожалуйста: «создание атмосферы, в которой...»

  Развернуть 1 комментарий

@dottedmag, Клуб в очередной раз реальность проткнул. Буквально сегодня у меня была первая лекция Левенчука в физтехе по системному мышлению.

  Развернуть 1 комментарий

@dottedmag, тут, наверное, можно проиллюстрировать диаграммой из OMG Essense, которую тот же Левенчук активно юзает в своих курсах

Области интересов
Области интересов

Верхний, зеленый сектор - это про бизнес анализ, governance и product management в части работы с внешними стейкходерами. Средний, желтый - архитектура и системный инжиниринг.
А нижний, синий - управление проектами, лидерство и операционный менджмент.

  Развернуть 1 комментарий

@Camargr, слушай, а Левенчук - это real deal или балабол? Просто вот читаешь какого-нить Фаулера или Эванса и понимаешь - да, пацыки сожрали кучу проектов за жизнь. А если Левенчука, Альтшуллера или Щедровицкого - все думаешь, блин, меня точно не дурят?

  Развернуть 1 комментарий

@ganqqwerty, нужно начать с того, что системного мышления не существует.

Это конечно наброс, но в общем смысле - системное мышление не заменит глубокое знание предметной области. Умение быстро погружать в предметную область и уметь синтезировать знания - это не системное мышление. Это опыт погружения в предметную область и синтеза новых знаний.

Я 5 лет отработал системным и бизнес аналитиком и ушел в разработку, чтобы когда-нибудь стать системным архитектором.

  Развернуть 1 комментарий

@maruschin, вот я в целом про такой философский подход к системам как к "системам вообще" - вроде с одной стороны звучит здраво, но ведь как глубоко вспомогательная дисциплина.

  Развернуть 1 комментарий

@ganqqwerty, я это и не люблю, "системное мышление" подается как наука о всем, по факту это наука ни о чем. Умение моделировать систему и получать из модели знания - хороший навык, но это не дают в системном мышлении, это куча всяких математических инструментов для каждого случая, от теории игр и до статистики.

Системное мышление это мета навык, который появляется где-то между кучи тулзов, которые ты изучаешь в процессе.

Мое ИМХО конечно же, но я не могу смотреть на книги и курсы по системному мышлению, меня тошнит от тупизны.

  Развернуть 1 комментарий

@maruschin, Про это как раз хорошая книга "образование для образованных 2020" у Левенчука, и я с ней довольно согласен https://ailev.livejournal.com/1530368.html - Системное мышление это трансдисциплина, которая ни в коем случае не заменяет знание предметной области. Он сам же и кричит везде, что это не ключ ко всему, и что человек без системного мышления, но с крутым пониманием предметной области - всегда будет лучше решать проблемы, нежели человек с сис. мышлением, но без знаний по предмету.

Сис. мышление же тебе дает такой фреймворк, о чем не забыть спросить, на что обратить внимание, когда работаешь на проекте. Системное мышление не вместо предметной области, а ДЛЯ нее.

  Развернуть 1 комментарий

@AntonLukin, я еще раз повторю) Системного мышления, которое подается Левенчуком и другими адептами "красной таблетки", "пятой дисциплины" - не существует.

Владения методами системного анализа или обладание образованием/опытом системного аналитика - это уже что-то более близкое к тому о чем они говорят, но чему не учат.

Системное мышление это не добавление к предметной области, это и есть знание предметной области, качественная характеристика этого знания.

Системное мышление как метанаука/метаинструмент помогающий эффективнее изучать и работать /c предметных областях - вранье, она экспуатирует основную когнитивную ошибку - ошибку обобщения.

Нет универсального и более эффективного фреймоврка для работы с системами, чем математика и куча около математических инструментов.

Системное мышление - это математика для гуманитариев, которая не работает.

UPD: книгу его не читал, но по оглавлению чувствуется, что он такой-же инфоцыганин, как и Курпатов.

  Развернуть 1 комментарий

@ganqqwerty, хороший вопрос. Я с его книгами и лекциями "воюю" уже какой год с переменными успехом. Не хватает ему и Ко своего Вастрика, чтобы разложил все удобоваримым текстом. Хотя курсы редакции 2020 года - уже заметный шаг вперед к простому человеку вроде меня.
Так что онлайн учебник "Системное мышление 2020" - рекомендую. Даже делал по нему для своих инженеров по нему вебинар во время карантина.

  Развернуть 1 комментарий

@ganqqwerty, Левенчук тоже сожрал http://libertarium.ru/ailev.

  Развернуть 1 комментарий

@dottedmag, что-то я там ничего не увидел, окромя "руководил группой программистов в Ростовском мединституте" и кучи "консультирования"

  Развернуть 1 комментарий

@ganqqwerty, да, тоже такое настораживает, уж очень много слышу про разных русскоязычных гуру, практически неизвестных за пределами СНГ, и это тревожный звоночек

  Развернуть 1 комментарий

@TepMex, не ну консалтинг - тоже работа, просто за ней могут скрываться самые разные вещи

  Развернуть 1 комментарий

@ganqqwerty, я скорее к первому коменту, про Фаулера/Эванса vs Альтшуллер/Щедровицкий :)

Просто тоже настораживает когда у личности заметный пафос в РФ/СНГ соседствует с полной неизвестностью на западе, например.

  Развернуть 1 комментарий

@TepMex, кстати альтшуллера чуток знают на Западе. Ну типа, бодренькая идея, систематизировал брейнсторминг про изобретательство. Ну а Щедровицкий - это какая-то секта)))

  Развернуть 1 комментарий

@ganqqwerty, Альтшуллер норм работает в реальных технических задачах (машинку там спроектировать/самолетик/новый датчик), для которых ТРИЗ собственно и создавался. В АРИЗ есть таблички что реально помогают "взглянуть на задачу под другим углом" и подсказывают физические принципы, о которых ты забыл/не знал.

Насколько ТРИЗ применим к бизнесу/программированию/[name it]/"всему мирозданию" бабка на двое сказала. Но что-то из него точно можно взять.

  Развернуть 1 комментарий

@TepMex, так СНГ рынок и западный рынок сильно разный. Разные люди, разные социокультурные предпосылки, разный опыт и скиллы как результат. Это неудивительно :)

  Развернуть 1 комментарий
Alexander Babenko, Либертарианец, блогер, архитектор ПО 5 октября 2020

Пока читал, ловил какие-то сайд-ощущения из мира разработки. Аналогичная история: душные срачи на тему того, что кто-то должен знать некую базу, сумрачные гении со своими опросниками на входе в многие компании. А в итоге ценность разработчика вообще находится процентов так на 90 в том же списке, что и у менеджера приведено про способность внятно и просто коммуницировать, прикидывать риски "на глазок", работать с неполной информацией и в неизвестности и вот это вот все. Но самое смешное, что такие вещи не измеряются, потому живем с тем, что есть.

  Развернуть 1 комментарий
Дима Черненьков, делаю страховое моделирование для ФО, педалю digital transformation 3 октября 2020

А Стивен Кови чем не угодил? :) И что он вообще тут делает в списке литературы, я его ожидал не больше"Сумерек".

  Развернуть 1 комментарий

@DmitriyChernenkov, 7 навыков - самая раздутая и бесполезная книга про эффективность и софт-скиллы, которые могут быть полезны для ПМа. Я ее честно начинала читать раза три. Что-то прочитала, что-то проскиммила. Толку ноль.

  Развернуть 1 комментарий

@Covectb_cobaka, ну, книге 30+ лет, в наш век прослушивания "краткого содержания книги за 10 минут" на двойной скорости (я сам так делаю иногда) она смотрится винтажно. Мне кажется, она очень фундаментальная и про мета-уровень, с этим трудно работать в режиме " у меня через полчаса встреча, как мне ее лучше провести с учетом вводных из этой книги". При этом никаких возражений к тем самым озвученным принципам я придумать не могу и не очень могу их представить в целом.

  Развернуть 1 комментарий

@DmitriyChernenkov, Не в винтажности дело. Даже если ее вдумчиво читать, толку мало. ИМХО.
Вам книги понравилась? Если да, то почему?

  Развернуть 1 комментарий

@Covectb_cobaka, я ее прочитал впервые очень давно, одна из первых моих нонфикшн книг. Она мне помогла с наведением структуры, дала модель анализа собственного поведения.

  • Я забегался по херне на неделе и не сдвинул важную штуку с места. Что случилось? Я не делал вначале то, что надо было делать сначала.

  • Я ворвался с ноги в процесс, вышла херня, вообще не то, что я ожидал. Блин, кажется я не проанализировал, чего я хочу, какой конечный результат должен быть, а просто ввязался в драку без видения.

  • Я поскандалил с человеком. Почему? Потому что типа он козел и неправ? А не потому ли, что я его не слушал, а ждал своей очереди высказать свои аргументы, хотел, чтобы он меня понял, а не пытался его понять?

И т.д. Это четкий фреймворк рефлексии, хороший набор принципов. Если в соответствии с ним действовать и анализировать ситуацию, это замечательная практическая шутка.

  Развернуть 1 комментарий

@DmitriyChernenkov, Понятно. Спасибо что объяснили. Я видимо слишком поздно ее читала, поэтому никакого Эврика.

  Развернуть 1 комментарий

@Covectb_cobaka, я только за это одно видео готов сказать ему огромное спасибо

В целом да, многие вещи у него кажутся очевидными, но в молодости он очень правильно выпрямляет мозги. Ну и читать его надо по мне с очень большими задержками для рефлексии, очень интересные вопросы задает по ходу книги

  Развернуть 1 комментарий

@Covectb_cobaka, со многими хорошими книгами есть та проблема, что хорошая мысль, изложенная ясно, кажется самоочевидной, и хочется задать вопрос "а делать-то что". И дальше проблема: знать эти принципы, но их не применять - все равно что их не знать. Наличие в голове системы, которая распознает хорошие мысли и принципы как "очевидные", абсолютно не значит, что человек по жизни также эффективно распознаете ситуации, когда эти принципы полезны, и может их применить.

  Развернуть 1 комментарий

@Covectb_cobaka, Ray Dalio Principles и «Искусство войны» у меня по этой же причине не зашли. Какой-то набор рекомендаций о том, что не надо спать на потолке, а лучше спать на полу. Ну, не поспоришь)

  Развернуть 1 комментарий
Andrey Kucherov, Руковожу проектным офисом 3 октября 2020

Подписываюсь.

Про тот же самый набор скиллов, но с другой стороны: на удивление зашел фильм Лок.
Посмотрите, он по нынешним меркам коротенький, меньше полутора часов. Квинтэссенция ПМ-ства "без учебников": применяемых в реальной жизни подходов и методов. Можно разбирать на учебных курсах.

  Развернуть 1 комментарий

@Camargr, Еще рекомендую серию Смешариков "Карнавал" кажется. Там персонажи записывали в блокнотик когда кто-то не успевал в срок и бедный кажется кролик за всеми бегал.

  Развернуть 1 комментарий

@Covectb_cobaka, в поисках Карнавала я посмотрела пару других серий 😅
В общем, эта серия про планирование называется «Кордебалет» 🔥

  Развернуть 1 комментарий

@miowch, Точно! Спасибо что вы ее нашли.

  Развернуть 1 комментарий
Anton Sosnin, С++ и компьютерное зрение 5 октября 2020

Отличный пост, готов кидать его в лицо каждому, кто хоть краем мысли решит попробовать себя в управлении.

Кроме одного слова (закрыл глаза и уши, проговаривая сквозь зубы) - фасилитация. Оно меня угнетает тем, что ни один человек, который его употребил вслух не смог его перевести не задумываясь и в 1 предложение. Назовите это уже "методикой способствования", а то менеджеры застревают в нем, не могут дышать и погибают.

Простите, 2 года не слышал это слово и вот оно опять.

  Развернуть 1 комментарий

@0xfe0d, Простите мне кальку с английского. To facilitate не имеет красивого перевода кроме чего-то вроде "методики способствования". В целом, я здесь про навык деликатно напоминать + деликатно сворачивать лишнюю болтовню на созвонах. Это скилл, я вам скажу :) Важно же еще понимать какая болтовня лишняя, а какая - не очень.

  Развернуть 1 комментарий

@Covectb_cobaka, ...но очень интересно)

прекрасная статья, а комментарии еще лучше

  Развернуть 1 комментарий

@Covectb_cobaka, управление "потоком" беседы, не?))) Правда я так и не поняла в чем отличие от грамотного организатора встречи, который по сути вовремя напомнит цель и задачи беседы и не даст уйти в дебри.

  Развернуть 1 комментарий

А почему нельзя использовать слово "модерация" / Умение модерировать? Обычно под ним понимают все вышесказанное. В России по крайней мере.

  Развернуть 1 комментарий
Anton Efimov, Senior Technical Product Manager 13 октября 2020

Из практических советов (подходит не только PM'ам) могу добавить насчет митингов:

  • Если создаете митинг сами, то обязательно have an agenda in the description
  • Если приглашены на чей-то митинг и он без agenda, либо сразу отказывайтесь либо, если это супер экстримально для вас, то пишите организатору и просите чтобы вам прислали эту самую agenda. Скажите что у вас конфликт и пытаетесь выбрать куда идти
  • Если пришли таки на митинг и вдруг поняли что it doesn't bring any value to you or you cannot to bring any value from your side, просто скажите об этом и уходите.

Время - это очень дорого.

  Развернуть 1 комментарий
Дима Черненьков, делаю страховое моделирование для ФО, педалю digital transformation 3 октября 2020

И хотел спросить, с "теорией ограничений" у вас был практический опыт - критическая цепь, вот это все?
Если пробовали, но не полетело, расскажите, пожалуйста, в чем были проблемы, интересно :)

  Развернуть 1 комментарий

@DmitriyChernenkov, Был. Полетело когда вгрохала 100+ часов на планирование. Только потом оказалось что оно нужно только мне.

Плюс, в условиях гибких требований все эти прибитые гвоздями планы не работают. Максимум роадмап с нечеткими целями на полгода-год. К нему теория ограничений сложно применяется.

Вам нужно иметь ну очень подробные требования чтобы все это расчитать. Так что только waterfall, а его в наших реалиях уже мало осталось.

  Развернуть 1 комментарий

@Covectb_cobaka, а почему данных, достаточных для waterfall, недостаточно для планирования по Голдратту? Основная идея "критической цепи" же про то, что вы соломку всю в одном месте складируете, не позволяя людям заниматься локальной оптимизацией своих про*бов.

  Развернуть 1 комментарий

@DmitriyChernenkov, в том и дело что если в полный рост оптимизировать, то данных достаточно только если очень вдумчиво их собирать. А это Waterfall, что не всегда хорошо.

Если мы говорим про мелкую оптимизацию следующих шагов цепи не в контексте планирования, а про Lean delivery и не брать новых задач сверх меры, тогда картинка ровно противоположная. Настраиваем конвейер и радуемся.

Не уверена что я здесь понятно изъясняюсь.

  Развернуть 1 комментарий

@Covectb_cobaka, действительно, не очень понятно. Waterfall - это про последовательность шагов со сроками этапов. В сроках есть оценка. Выделяешь из всех оценок паранойю и прикрывание собственных жоп, складываешь перед делайном и делаешь из этого метрику хода проекта. Я не понимаю, чего нужно более вдумчивого :)

  Развернуть 1 комментарий

@DmitriyChernenkov, кажется мы с вами говорим про разное. Какой именно кейс для применения теории ограничений вы подразумеваете?
Для меня есть разница между "одна команда + набор фич" vs "огромная программа / портфолио на 6 продуктов"

  Развернуть 1 комментарий

TLDR: Project management - это когда маленький человек в ужасе хватается за любые методики, не успевает к дедлайну, и никто ему не может помочь. Никто.

  Развернуть 1 комментарий
Kirill Nikitin, ИТ консалтинг 6 октября 2020

Чёт заметил что в списке навыков нет "управления конфликтами". Как без этого?
И хорошей теории вроде полно.

  Развернуть 1 комментарий

Какую литературу посоветуешь по управлению конфликтами? Именно "хорошую теорию" (но можно и с практическим уклоном)

  Развернуть 1 комментарий
ДК, биздев 3 октября 2020

К списку рекомендуемой литературы добавил бы «Простите, я разрушил вашу компанию». Там нет про эджайл, но много отрезвляющего про весь этот теоретический инструментарий

  Развернуть 1 комментарий
Роман Романов, Предприниматель 3 октября 2020

а вы онлайн курсы ведёте?
я бы послушал.

  Развернуть 1 комментарий

@roma_ds, я преподаю в МАИ и веду онлайн-кус в OTUS. Открыта новым предложениям :)

  Развернуть 1 комментарий
Danis Gumerov, Frontend developer 5 октября 2020

@Covectb_cobaka, если не секрет, почему выпас котов в нерекомендуемых? Вроде считается "классической" книгой.

  Развернуть 1 комментарий

@artboomy, потому что она бесполезна и дурит голову. Чем вам эта книга помогла?
Для меня "классическая" != полезная.

  Развернуть 1 комментарий
Pavel Galeev, SW Embedded Designer 5 октября 2020

У меня было пару курсов про ПМ. ВШЭ и курсера. Кстати, ВШЭ был отличный курс. Пока что прям это мой идеал

Фишка в том, что в тот момент я пытался внедрить управление проектами в своем отделе. Но это был хардверь отдел. И многое оказалось полезым и удобным.

Потом я ушел в софт девелоперы. Видел немного всякой имитации ПМ и Аджайл... казалось мне я понимаю все эти шутки...
А потом я оказался в большой международной конторе. И увидел где и как работает Аджайл, особенно если н работает правильно. И пользу, и скорость и вот это все.

Теперь когда я слышу про "Аджайл гавно", то у меня две варианта - либо он вам не нужен, либо вы не умеете его готовить.

С ПМ сложнее, и вопрос "как правильно учиться и применять" для меня все еще открыт. Хотя бы потому что я глубоко в это пока перестал соваться на нынешней позиции

  Развернуть 1 комментарий

@gapel, А каким выглядел действительно "если н работает правильно" Эджайл? А то я уже видел много "всякой имитации". И впечатления смешанные. С удовольствием послушал бы, как это может быть :)

  Развернуть 1 комментарий

@gapel, вот я не видела ни разу, чтобы аджайл работал. это не значит, что фреймворк не работает никогда, но нужен ли он если его так сложно натроить?

  Развернуть 1 комментарий

Великолепный пост, который вышел за рамки рассматриваемого явления и коснулся трансцендентальных вещей. Спасибо.

  Развернуть 1 комментарий

Коллеги, наши бизнес-заказчики пока не смогут уделять время внедрению. Начинайте пока сами.

(с) Олег, клиент по 1С

  Развернуть 1 комментарий

Я аккуратно дополню, что эджайл методики это методики не проектные, а продуктовые и требуют некоторого сдвига сознания с проекта на продукт. И я смотрю на эти таблицы, так сложно, не помню чтобы они после презентации плана вообще где-нибудь появлялись.

  Развернуть 1 комментарий
Игорь Пнев, Фронтенд разработка. 3 октября 2020

Я в свое время поучился PMI, но с PM у меня карьера не сложилось. Сейчас общаюсь много со строительными частных домов и часто заходит разговор о проектном управлении и менеджеров. Когда им рассказываешь, что управление проектом это не про Ганта, а про коммуникации, накопления опыта и знаний, управление людьми и ресурсами, они делают большие круглые глаза. У большинства в лучшем случае PM = план-график. Но при этом они как-то умудряются строить и строить параллельно по 5 домов которые не разваливаются и приносят прибыль.

  Развернуть 1 комментарий

@exdeniz, потому что строительство дома - стандартизированный процесс и скоуп, в отличие от.

  Развернуть 1 комментарий

@glebkudr, это если строить однотипные дома. Но обычно это индивидуальный проект и реально может быть очень разный.

  Развернуть 1 комментарий

@exdeniz, Строительство - немного другой мир. И проекты там тоже отличаются. Там много стандартов и инструкций. Если их убрать, правда останется план-график. И на нем тоже можно выехать. Но в культуре ИТ общение с людьми имеет сильно бОльшую ценность. Посмотрите как стоители друг с другом работают и как разговаривают. Плюс, у них меньше гибкости в проектах и часто меньше неопределенности.

  Развернуть 1 комментарий

@exdeniz, все равно есть нормочасы на операции, неопределенности в ит гораздо больше.

  Развернуть 1 комментарий

@exdeniz, даже несмотря на разность дизайна домов, уровень неопределенности в таких проектах все равно на порядки меньше, чем в разработке. У меня есть подозрение, что PMBOK в принципе был написан по лекалам как раз-таки строительных проектов.

Господство планов-графиков, Ганттов и прочих артефактов, присущих более-менее статичному скоупу, вполне уместно в этом домене.

  Развернуть 1 комментарий

@greemster, Верно. PMBoK про любое проектное управление, в первую очередь производственное и строительное. Один из selling points что PMP-certified может работать проектным менеджером в любой индустрии. Я в этом сомневаюсь ровно из-за веера дополнительных скиллов, которые будут уникальны для индустрии.

Однако пост не только про PMBoK, он в целом про изучение теории.

  Развернуть 1 комментарий
Сергей Некрашевич, Технический директор в контрактной RnD компании 3 октября 2020

Хотел бы я получить скилл загружать эту выжимку из опыта напрямую в мозг некоторым руководителям с предыдущих мест работы. Спасибо за пост!

  Развернуть 1 комментарий

@greemster, Часть постов (в том числе этот) доступны по прямой ссылке. Можно делиться)

Есть частое мнение что теория как раз таки очень нужна. В этом случае стоит понять какую проблему мы решаем. Если у менеджера что-то не получается, это не значит что проблема в теории.

  Развернуть 1 комментарий
Skrypnikov Stanislav, Product manager (DM иногда) 11 января в 13:02

А где же про бесполезность проектных метрик?) Ну и раз обосран был классический предиктивный подход от РМИ, надо было что ли про манагемент 3.0 упомянуть, как альтернативу.

  Развернуть 1 комментарий
Dima Ollyak, софтваре инжениир 29 января в 02:49

Классный пост, спасибо!

Довелось немножко покрутиться и в строительной отрасли, и в IT. В стройке сетевые графики суперполезны, даже в самых простых проектах, когда забор красишь. В IT сетевые графики нафиг не нужны, только создают обманчивую видимость порядка. В этой части я полностью согласен с постом.

  Развернуть 1 комментарий
Andrey Kucherov, Руковожу проектным офисом 8 февраля в 17:36

Я бы предположил добавить к

Summary: развивайте soft skills и понимайте свой проект

еще такое: несите за проект ответственность.

Что бы ни случилось в проекте, виноват всегда PM. Это аксиома. Виноват без самокопания, и разрушения своей картины мира, не потому, что он плохой человек, и надо срочно надо выгореть и уйти с котомкой в туман, бросив проект на произвол судьбы. А потому, что не предусмотрел, не проверил и не перепроверил, не отстоял своего мнения, нанял не тех людей, не объяснил или не понял сам. И он пытается учесть эти ошибки на ходу, и управляет проектом дальше. Продолжает пилотирование, как об этом пишется в "Чек-листе" Гаванде.
Шкура на кону Талеба тоже про это, да.

Еще вот здесь неплохо:
https://m.signalvnoise.com/its-always-your-fault/#.2mq7obc7m

Еще попадался удачный пример: PМ должен всегда, в любое фазе проекта, быть способен на листке бумаге или салфетке рассчитать своей планируемый бонус с проекта. Если не может - значит, у проекта серьезные проблемы - с контролем, финансами, планированием, или со всем вместе.

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб