Мария, добрый день.
Совершенно случайно нашел Вашу очередную статью на инфостарте и решил все-таки Вам написать.
Если честно, то при знакомстве с различными книгами по РМ-у почему-то реально в голову лезет одна и та же навязчивая мысль: тебя методично вербуют адептом в какую-то тоталитарную секту. Это ж надо так умудриться - высосать из пальца целое творение почти на 8 сотен страниц по управлению проектами в виде последнего pmbok-а. Я вот думаю, а как же мы раньше жили без этого? Создали ядерную бомбу, первыми полетели в космос, создавали ледоколы и т.д. Читаешь и думаешь: и запомнить не запомнишь, и толком понять невозможно - слишком многамногабукаф. Вроде смотришь - а король-то голый, но вокруг все с восторгом носятся и нахваливают платье короля.
Иван, спасибо за письмо. И особенно за аналогию про тоталитарную секту - возьму на вооружение, если не возражаете, попали в точку. Я сама называю PMBOK "Библией проектного управления" - такое ощущение, что на него многие молятся. Действительно, вы говорите правильные вещи. Большинство нормальных людей сойдутся с вами в одной простой мысли - PMBOK читать как книгу практически невозможно. Мало того, если все-таки сумеете впихнуть в себя эти 800 страниц, то выясните, что это еще и бесполезно. Мудрее вы от этого не станете и лучше управлять проектами не начнете. И этого мало, открою еще одну страшную тайну - PMBOK и не рассчитан на то, чтобы его читали. Это не методология, и не учебник, и не стандарт. Это Project Management Body of Knowledge - свод знаний по управлению проектами. Читай, энциклопедия. И как к энциклопедии к нему и надо относиться.
Меня однажды спросили на собеседовании: "Мария, а вы в своей работе применяли все принципы из PMBOK?" - На что я честно ответила: "Конечно же, нет. Дело в том, что крайне неудобно копать экскаватором ямку в песочнице"...
PMBOK не из пальца высосан. Он собрал много успешного опыта разумных людей. Но - в полной мере предлагаемый комплект инструментов ориентирован в первую очередь на длительные проекты, в которых участвуют более сотни людей, с распределенной командой, длительностью несколько лет. Пытаться прикрутить весь комплект к чему-то мелкому - это в некотором смысле, забивание гвоздей микроскопом. Хотя не все методологи и адепты проектного управления это осознают. Ну и да, как в любой сфере, приносящей деньги, разумеется, на каждое рациональное зерно там накручено еще много всякого разного, местами избыточного.
Про то как жили раньше - была в советское время тоже развитая методология управления проектами, и в том же атомном секторе прекрасно умели и планы проектов писать, и диаграммы Ганта рисовать - авторы PMBOK не придумали ничего нового, а просто собрали лучшие практики воедино.
Вот Вы пишете, что занимаетесь бизнес-консалтингом, т.е. с бизнесом на "ты" и "дверь ногой". А ведь бизнес в своем корне мыслит единственной категорией - сколько денег принесет использование того или иного подхода. Простой реальный жизненный пример: инвесторы при вложении инвестиций в строительство недвижимости хотят знать, сколько денег они получат на выходе - все, точка! Их больше ничего не интересует - ни темпы строительства, ни технологии стройки - ни-че-го. Им абсолютно все равно, как это будет делаться, ибо БИЗНЕС РАЗГОВАРИВАЕТ ВСЕГО ЛИШЬ НА ОДНОМ ЯЗЫКЕ - ЯЗЫКЕ ДЕНЕГ И МЫСЛИТ ИМ ЖЕ. Способна ли любая методология ответить на простейший вопрос: сколько этих самых пресловутых денег в реальных единицах (гори они синим пламенем) она готова принести бизнесу (вы же помните, бизнесу абсолютно все равно, как вы будете строить и будете ли вообще, главное - чтобы отскок был обещанный)? Это самая реальная история, инвесторы считают только деньги. И, наверное, сложно их в этом упрекнуть, потому что свои деньги считают все, и мы с Вами здесь не исключение.
Ну да ладно, в сторону эту лирику, ибо спорить здесь можно до бесконечности, а от споров деньги не генерятся :).
А вот здесь всё, на мой взгляд, чуточку хитрее. Вообще, я не люблю категоричных утверждений: "только деньги и никаких гвоздей". Мне ближе формулировка "в первую очередь интересуют деньги". Потому что на самом деле есть еще много нюансов, интересующих бизнес, с деньгами, в целом, связанных, но - опосредованно. Что имеется в виду? Имидж. Влияние. Перспективы. Развитие. Управляемость. Безопасность. Снижение рисков. Психологический комфорт руководства. Развитие команды. Иногда - этика. Что ещё, помогайте в комментариях???...
И тут начинается интересное. Кто смотрел мой цикл вебинаров по управлению проектами (кстати, я думаю сделать онлайн-курс на эту тему), мы там разбирали уровни зрелости проектного управления.
Так вот, если организация находится на "начальном" уровне, то использование PMBOK в полном объеме будет не только не полезным, а, скорее вредным. Да и на уровне "управляемом" попытка "всё делать правильно" может привести к тому, что дефицитные ресурсы потратят на то, чтобы "делать по уму", и при этом упустят из виду наиболее острые проблемы, требующие немедленной реакции. Так вот, тут мы и подошли к той проблеме, о которой вы говорите. Действительно, когда организация находится на "начальном" уровне, тут стоит вопрос, каким образом заработать деньги. И наиболее ценным оказывается сотрудник, действующий не по правилам, но эффективно - ведь успех здесь зависит от личного подвига конкретных героев, тушащих пожары. А по мере развития организации уже важнее оказывается не личный героизм и возможность "урвать" здесь больший заработок, а предсказуемость успеха. И здесь - да, нам важно выстроить процессы и процедуры. Чтобы мы не просто получили кучу денег "здесь и сейчас", а получили уверенность в том, что мы будем постоянно зарабатывать. И следование методологии как раз может дать эту уверенность.
На это месте мне вспоминается рассказ моего мужа, как он учился играть в го (кто не знает, это такая восточная игра, вместе с шахматами и бриджем считается одной из сложнейших интеллектуальных игр). И, говорит, было ему до чертиков обидно, когда он в начале своего спортивного пути на турнирах играл, применяя правила и принципы, которым его учили тренеры в секции, и проигрывал соперникам, которые играли "неправильно". Но, будучи человеком упорным, учиться и совершенствоваться продолжал. И через некоторое время обнаружил, выходя в финалы соревнований, что уже не встречается с обыгрывавшими его раньше соперниками, потому что они отсеиваются на более ранних отборочных турах. К чему я это говорю? Да, действительно, решая наиболее острые проблемы по принципу "хватай мешки, вокзал отходит" можно при определенном везении добиться большего успеха, чем в той же обстановке планомерно применяя разумную методологию. Но достичь надежного стабильного долговременного результата таким образом не получится.
Можно ли испортить хорошую вещь применяя "умную методологию из книжки"? О да, сколько угодно!.. Как говаривал один мой знакомый руководитель "Храни нас бог от эффективного менеджера"... И вообще, используя книжку из 800 страниц гораздо легче разводить имитацию бурной деятельности - тем более, что можно пенять собеседникам, которые будут чувствовать свою неполноценность, ибо они эти 800 страниц не читали (а если читали, то невнимательно - ибо, как справедливо сказано вначале, ну невозможно это прочитать!).
Я человек честный, и поэтому, конечно, скажу еще одну вещь. Наибольший интерес к подробному изучению и разработке собственных методологий наблюдается, по моему опыту, в первую очередь в разнообразных госструктурах или сильно бюрократизированных структурах. Где задача обоснования часто бывает не менее, а то и более актуальной, чем заработок денег. Скажем, большие расходы, которые проще внести в смету, оказываются привлекательнее, чем меньшие расходы, если их обосновать затруднительно. В этом месте я не обесцениваю Project Management для бизнеса, который действительно заточен на получение прибыли, о нет. Я просто говорю, что ОСОБЕННО его ценят бюрократизированные структуры.
Можете подсказать толковый курс по РМ именно в части IT? (или, может, не курс, а какую-то суперадекватную литературу?). Возможно, в конечном итоге я изменю свою точку зрения по отношению к РМ-у в целом.
Не бла-бла-бла, а курс, который нацелен на практическую часть, где по шагам разбирается создание реального устава проекта, разрабатывается реальный план, график, затрагиваются вопросы по управлению бюджетом, человеческими ресурсами, практически прорабатываются вопросы по созданию метрик проекта, KPI для участников и т.д., - словом, курс, где не зачитывают тупо переписанные из умных книжек фразы, а где разбираются на реальном примере все составляющие реального, живого проекта.
Ну, сам себя не похвалишь, никто не похвалит. Я вот стараюсь читать курсы по управлению проектами (особенно корпоративные) в привязке к реальности, с разбором реальных кейсов и конкретных вопросов. В любом случае, по каждому пункту нужно разбирать "а что из этого мне пригодится в реальности". На Инфостарте планирую такой онлайн-курс для руководителей проектов 1С. Ну и знаю преподавателей, которые рассказывают с привязкой к реальности - да, так бывает (хотя не всегда).
Теория теорией, но если ты никогда не писал реальный устав, план, график, ТЗ, вряд ли ты их напишешь даже после изучения теоретической части, нужно представлять себе четко их «физическое обличие». Каким образом они должны быть оформлены, подготовлены, что в них быть должно, а чего нет, — словом, нужен детальный разбор реального полета, по-другому летать не научишься, к сожалению.
Однозначно! Подробно изучать теорию не имея опыта управления реальными проектами - это скорее вредно, чем полезно. Одно из моих хобби - парусный яхтинг (я яхтенный капитан). Так вот, в западных школах принята такая схема обучения: сначала курсант проходит курс на море Competent Crew (компетентный матрос) - 5 дней на яхте на море. Учится на практике настраивать паруса, стоять за штурвалом, вязать швартовы и т. п. И только после этого уже проходит продвинутый береговой курс теории - по навигации, терминологии, безопасности и т. п. Потому что если теории будет не на что ложиться - то обучение пройдет впустую. Так и в проектном управлении. Напомню, что к экзамену на Project Management Professional (PMP) допускаются только РП-практики, имеющие практический опыт управления проектами не менее 36 месяцев. Одного моего знакомого, например, завернули - он прослушал курс теории, внимательно изучил PMBOK, но опыт работы у него был - в проектном офисе крупной компании. То есть, опыт теоретический, а не практический.
Читать разные книжки по PM без реального разбора потенциального проекта - это застрелиться можно уже после первой же страницы, а когда их 7 с лишним сотен, как в шестом издании pmbok?...Это же не дарья донцова, которая прочитывается нашими дамами за 2 часа! Где взять столько лишнего времени и мозгов на это "запрещенное" чтиво?
Ну ладно, ладно, поделюсь несколькими лайфхаками, как читать PMBOK.
1. Убедитесь, что вам это правда надо. Желательно, чтобы был внешний стимул: запрос работодателя, необходимость сдать экзамен, системные проблемы при руководстве крупными проектами и т. п.
2. Воспользуйтесь дополнительной литературой специально заточенной на разъяснение PMBOK. Я лично могу посоветовать как минимум два источника. Во-первых, это курс Ивана Селиховкина, который мы публикуем на Инфостарте. Он так и позиционируется автором, как разъясняющий PMBOK. Во-вторых, лично я читала пособие Риты Малкахи "Подготовка к экзамену PMP: Как сдать PMP с первой попытки". Я читала на английском и еще старую версию (по 4-ому PMBOK), с тех пор последователи переиздавали неоднократно (самой Риты, к сожалению, уже нет в живых). И вот там, в хорошо написанной книжке ты, наконец, понимаешь, все эти бесконечные скучные блок-схемы и умные слова - к чему они нужны в реальной жизни??? И прочитав, скажем, главу про "Управление содержанием" у Риты ты морально готов прочитать аналогичную главу в PMBOK - она уже ляжет на подготовленный фундамент.
3. Это всё чтение имеет смысл тогда и только тогда, когда вы уже прошли практический курс компетентного матроса на реальной яхте получили опыт реального управления проектами. И на каждой точке вы можете остановиться и сказать "о, вот этого-то и не хватало в том самом проекте N!" или "а вот до этого мы интуитивно сами додумались, и не зря!.." или "ага, вот скажем в том проекте M, если бы у нас был бы план коммуникаций, в него стоило бы включить вот такой пункт, глядишь - тогда и не наступили бы на те грабли"...
Мария, ну вот Вы как умудрились стать РМ-ом при таком раскладе? Где Вы черпали реальную информацию по разработке сопровождающих проект документов? Не думаю, что на Вас снизошло озарение после прочтения вышеуказанной макулатуры...Это ж сколько надо иметь фантазии, чтобы накрапать сей "нелегкий" труд?...Я б не смог налить столько воды. А про лаконичность и "архиваторы" они, видимо, не знают...И, что самое интересное, от издания к изданию источники неплохо так пухнут, мотивируя это непрерывным развитием...
Истина, на мой взгляд, как обычно кроется в вине в нахождении золотой середины. Я в своей жизни видела РП, которые пренебрежительно откидывают "всю эту мукулатуру", и с шашкой наперевес, на боевом скакуне бросаются в гущу управления проектами. Они бывают успешны. Если повезет (см. литературу по теме "систематическая ошибка выжившего"). Видела РП, которые мало понимали, чего делать в реальности, но были подкованы в вопросах оформления документации. Они иногда успешно имитируют бурную деятельность. И (существенно реже, чем первые два вида) встречала РП, которые и понимали, что делать, и понимали, как закрепить и усилить эффект при помощи методологии. Вот в сочетании - оно работает, да.
Если даже ты наизусть знаешь, как в теории устроен двигатель машины, но ни разу его сам не разбирал...Я считаю, что практическая часть не менее важна части теоретической, если не более, потому что проекты создаются не в теории, а на практике...как-то так. На мой взгляд, именно практические рекомендации с реальными образцами были бы куда информативнее различных толстенных теоретических талмудов.
Конечно же, практическая часть важнее. И нельзя подпускать к реальным проектам теоретиков, это просто опасно! Но будьте готовы, что практическая часть будет куда менее универсальной. И ею менее охотно делятся - ибо удачные инструменты дают конкурентные преимущества. Кстати, масса разнообразных Workflow-систем, различных конфигураций и надстроек 1С родились именно таким образом: какая-нибудь компания разработала под себя инструмент, он получился хорошо, и они стали продавать его за деньги желающим... И, кстати, в итоге почти любой инструмент приходится допиливать под бизнес-процессы пользователя, практически ничего нельзя использовать "прямо из коробки".
Еще вопрос с уклоном в профессиональную сторону ведомого проекта в области IT: как Вы считаете, должен ли РМ обладать навыками и знаниями из той области, в которой ведется проект? Если уж совсем ближе к делу, то насколько РМ должен обладать различными навыками и инструментарием профессионального разработчика, если проект идет в области разработки ПО? Или РМ - это управленец-универсал общего назначения без абсолютной привязки к специфике, в которой им ведется проект?
Не люблю давать универсальных ответов. Мой опыт показывает следующее: идеальный PM - это хороший техспециалист, и хороший управленец. "Съесть то он съесть, да кто ж ему дасть"... Если такого не завезли, лучший вариант - связка из хорошего PM и хорошего заместителя тех. консультанта, которого PM, черт возьми, слушает!!! Не могу удержаться, приведу антипример "как не надо" (Источник: Xander Toons):
И самый последний вопросик: Вы действительно свято верите во всемогущую силу (сборище различных методологий) теории управления проектами? Может, это все вовсе и не нужно, и это все, может, только усложняет жизнь? Может, это все бровада, сказка про голого короля, выгодная обширной аудитории создателей различных многотомных методологий, высокодоходной индустрии по производству различных тренингов и тренеров для них? Главное - подсадить массово, а уж легион, готовый кинуться на помощь нашему обывателю, падкому на все модно-современное, найдется! Хороший или плохой - вопрос уже десятый.
Не верю я во всемогущую силу ничего (я вообще агностик). Но я знаю и утверждаю, что при разумном и толковом применении уместных методологий (в сочетании с применением мозга, а не вместо!!!!) они могут повысить шансы ваших проектов на успех.
Помнится, в своей статье Вы сами писали про имитацию бурной деятельности с задействованием большого круга лиц для масштабности. И еще я слышал от одного очень известного в Ваших кругах РМ-а, что у состоявшегося РМ-а обязательно должно быть свое кладбище проектов. Только представьте себе ситуацию, когда некий хирург утверждает, что он состоялся только благодаря тому, что предварительно зарезал дюжину пациентов для приобретения надежного опыта! А опыт всегда требует совершенствования!
Иван Селиховкин, при всем моем уважении (на полном серьезе) к его преподавательским талантам (серьезно, мне очень нравятся его образы и метафоры своей доходчивостью, включая удава, на которого все так сурово набросились в комментариях к первым его статьям), все-таки в первую очередь очень известен не как PM, а как тренер и преподаватель. Это все-таки немножко другая сфера, требующая немножко других качеств и другой аргументации. Но вообще, способность вовремя остановить убыточный проект, а не доводить его до конца всем на посмешище - это ценное умение, которое экономит много денег организации. Очередной антипример:
Есть старая индейская притча: «Лошадь сдохла – слезь». Казалось бы, всё ясно, но..
- Мы уговариваем себя, что есть еще надежда.
- Мы пытаемся бить лошадку сильнее.
- Мы говорим «Мы всегда так скакали».
- Мы организовываем мероприятие по оживлению дохлых лошадей.
- Мы объясняем, что наша дохлая лошадь гораздо «лучше, быстрее и дешевле».
- Мы организовываем сравнение различных дохлых лошадей.
- Мы сидим возле лошади и уговариваем ее не быть дохлой.
- Мы покупаем средства, которые помогают скакать быстрее на дохлых лошадях.
- Мы изменяем критерии опознавания дохлых лошадей (доказывая, что наша - вовсе не такая).
- Мы посещаем другие места чтобы посмотреть, как там скачут на дохлых лошадях.
- Мы собираем коллег, чтобы дохлую лошадь проанализировать.
- Мы стаскиваем дохлых лошадей в надежде, что вместе они будут скакать быстрее.
Но суть одна: ЛОШАДЬ СДОХЛА - СЛЕЗЬ !!
Еще пару вопросов вдогонку.
Вы всегда можете гарантировать успешность того или иного проекта?
Нет. Вспоминаем матчасть - любой проект уникален, и любой проект сопряжен с рисками. В этом его отличие от операционной деятельности. См. Chaos Report от the Standish Group International.
Т.е. изначально каждый ли проект потенциально успешен? И можно ли в принципе вести проект "не по методологии", написанной людьми, которым также свойственно ошибаться? Ведь каждый проект уникален, и объять все некой универсальщиной возможно ли?
Нет, не каждый. Можно вести как угодно. Но в наше время, когда количество накопленной информации уже настолько непостижимо, что даже не буду ссылаться на конкретные цифры, особенно важно умение использовать чужой опыт и чужие наработки, а не гордо наступать на грабли самостоятельно. Вы же помните, что именно этим мудрый человек отличается от умного.
И еще реальный пример. Представьте компанию на 1000 чел, у которой нет корпоративной электронной почты, но она им нужна очень сильно для различных коммуникаций (забудьте на время про облака, спуститесь на землю). И вот полетело задание it-директору на автоматизацию этого дела. Проект не суперсложный, но, в любом случае, требует вложений в необходимую технику и ПО, а также в обучение персонала сначала на установку и настройку, затем на обслуживание...
И вот проект успешно завершен, выделенное бабло радостно попилено, все довольны, в срок достигнуты поставленные цели - все при своих корпоративных аккаунтах.
И вроде все хорошо, но есть одно НО! Какую экономическую выгоду он принес компании, кроме того, что сожрал кучу денег? Вспомните про инвестора, мыслящего языком денег, который спрашивает, сколько бабла осядет на моих счетах в результате освоения данного проекта за минусом потраченного!??? Как перед ним отчитываться?
Хороший вопрос. Что история реальная - верю, сама с похожим сталкивалась не так давно. Давайте попросим членов сообщества дать на него ответ. Коллеги, как вы считаете, как можно обосновать подобный проект? Дам только одно направление мысли - на мой взгляд, этот проект правильно рассматривать не автономно, а в рамках портфеля проектов, ведущего к значимым для компании целям - повышение управляемости, повышение безопасности и т. п.
И, да, огромное спасибо за ответ, обычно Ваша братия либо весьма немногословна, либо предпочитает вообще отмалчиваться, когда поднимаются озвученные мной темы.
Надеюсь, Вы меня поняли.
Заранее признателен за исчерпывающий ответ.Иван Иванов.
Не за что. Обращайтесь. Буду рада продолжению дискуссии.
Подробнее об управлении ИТ-проектами вы можете узнать на моих онлайн-курсах
