PMBoK и PRINCE2: тяжелая артиллерия
Если с различными Agile жить просто и понятно, то вот эти две методологии, стандарта — уже серьёзнее. Плана больше, разброда меньше, требования жестче.
Оба два — стандарты управления проектами, а не только «методология разработки». Причем надо отметить, что управления проектами любыми, то есть речь не только про это ваше айти богомерзкое. Хоть дома по ним строй, хоть атомные станции, хоть космос запускай.
Для старта, что в обоих важно, и что отличается от различных Agile:
Могут уточняться. Но если в гибких аджайлах вы запросто меняете план (когда он перестал вам/задаче подходить) и сортируете его, разгребаете приоритеты беклога, то у этих двух — суть, содержание и состав работы так или иначе заранее фиксированы и оценены.
Как и набор этапов и шагов. Их нельзя «сделать чуть-чуть», поменять местами, или переобуться на полпути. Можно только закрыть к херам проект целиком.
У обоих (следовательно) внутрь включено прогнозирование, планирование, и формальные процедуры оценки и понимания «а что же мы всё-таки хотим в итоге сделать/получить». Описанные в конкретном документе — в плане управления (PMBoK) или бизнес-кейсе (PRINCE).
Корректно сказать, что в этом смысле они, оба два подхода, ближе к waterfall-модели.
PMBoK (Project Management Body of Knowledge)
PMBoK в своей классической форме — это предиктивный подход (plan-driven). Предполагает, что мы можем заранее спланировать большую часть работы, и далее контролировать исполнение. Изменения в содержании приветствуются умеренно, и проходят через процедуры управления изменениями (Change Control Board).
В последних версиях PMBoK упоминается не только «каскадная модель» (waterfall), но есть дополнительно дается набор методов — итеративный, предиктивный, гибридный — то есть, можно кусками подобрать гибкие подходы внутрь операций. Чтобы не замыкаться намертво в жестких рамких процессов там, где объективно не надо.
Но план и набор требований — всегда остаются, и изначально фиксированы.
- 10 областей знаний (потому что knowledge): управление интеграцией, содержанием, сроками, стоимостью, качеством, ресурсами, коммуникациями, рисками, закупками, заинтересованные стороны
- 5 групп процессов: инициация, планирование, исполнение, мониторинг/контроль, закрытие. Итого около 50 процессов (5х10).
- содержание работы, время и стоимость/ресурсы фиксированы, и жестко связаны. Это не «выберите любые два»; мы знаем что мы делаем, и как конкретно.
- соответственно, цель — пройти каждый этап практически, и весь проект с минимальными отклонениями от плана (и от оценки).
Основная ценность: соблюдение плановых параметров. То есть качество/полученный выход, время, бюджет. Здесь не надо «сделать что-нибудь больше и пораньше», как в аджайле; здесь надо сделать как надо, и как запланировано. Сроки и стоимость могут изменяться по объективным причинам — вылет за план, косяки и факапы, но содержание плана меняться не будет. Требования — считаются стабильными.
Команда (или команды) управляются централизованно, менеджером проекта. Самоорганизации или нет совсем — внутренняя организация задана на старте, или моменты само-управления штучные и эпизодические. Это опять же, в отличие от всяких аджайлов.
PMBoK ставит жесткие требования и к документам, и к отчетности. Без бумаги PMBoK не работает — вот эти все «устав проекта, план управления, реестры рисков, запросы на изменения» обязательные, несущие, без них нормально не взлетит. Главный документ — план управления проектом.
По своей структуре (внутри себя) PMBoK методологически вырастает из инструмента best practices, т.е набора лучших практик. Это у него даже в названии отражено. Поэтому — стандартизированные процессы, документирование, отдельный формальный контроль изменений.
План предполагает определённость. У нас не может быть в нём «непонятных задач», «исследовательских неопределенностей» и прочих внутренних шатаний.
До старта работы мы должны все мутные места понять, прояснить, оценить и внести в план: на основании каких-то знаний, метрик, процессов и практик. Корректно сказать, что у нас уже должно быть знание и «что» мы делаем, и «как» конкретно мы это собираемся делать.
Дальше прилагаем к этому календарное + ресурсное планирование, и понеслась.
Очевидно также, что если у вас в выбранной предметной области органически дофига неопределенностей, смены целей, и прочих переобуваний в полёте, то PMBoK сюда прикладывается хреново, полетит весьма коряво и низэнько, с пинка и мата. Выбирайте инструмент под задачу.
PRINCE2 (Projects IN Controlled Environments)
Prince — это методология управления проектами, внутри которой (аналогично) лежит директивный контроль. А также управление исключениями.
У нас есть заданные заранее бизнес-задача, требования и допуски (от Project Board), далее менеджер действует самостоятельно, по этапам. Пока в эти допуски — по срокам, бюджетам, качеству — укладывается. Если не укладывается, вопрос эскалируется до собрания PB.
В основе и по центру лежит бизнес-обоснование, business case. Содержимое «чего делаем, чего строим, как мы это делаем» записано в Business Case и в Initiation Docs, и в любой момент может (и должно) быть оценено применительно к кейсу, и к бизнесовой целесообразности.
Мы делаем проект только в том случае и только при том условии, что он нам (всё еще) бизнесово полезен, обоснован и выгоден. В противном случае закрываем к херам.
Управление в PRINCE обязательно по стадиям, с процедурой оценки каждой стадии. И по допускам, и по бизнес-цели.
Требования — в отличие от PMBoK — могут уточняться по ходу проекта, но для каждой начатой стадии они фиксированы.
- 7 принципов: непрерывное бизнес-обоснование, обучение на опыте, распределение ролей и обязанностей, управление по стадиям, управление по исключениям, фокус на продуктах, адаптация под окружение. Несмотря на то, что формулировки местами мутные, принципы должны соблюдаться, иначе проект не prince
- 7 тем: бизнес-кейс, организация, качество, планы, риск, изменения, прогресс. Это то, к чему вообще прикладывается управление, как таковое (аспекты управления)
- 7 процессов: запуск проекта, инициирование проекта, управление проектом, контроль стадии, управление поставкой продукта, управление границами стадии, закрытие проекта. Это логика управления по времени: календарь, сроки, этапы-очередности
- требования к выходным продуктам могут анализироваться поэтапно (но всё еще жестко заданы для каждого этапа, стадии)
- цель определяется только бизнесовой целесообразностью и/ли стратегической необходимостью, и валидируется
Говоря о фиксировании требований, в prince продуктовая декомпозиция. Сначала мы определяем, какую цель достигаем, какие продукты (результаты) нам для этого понадобятся, а следом по стадиям — как мы будем те продукты создавать, а результаты достигать.
Ответ на вопрос «что» фиксируется заранее, ответ «как» можно подгонять под необходимости.
Управление в prince иерархическое: команда, менеджер проекта, руководство проекта (project board), руководство компании.
Пока на каждом уровне иерархии задача/проблема может быть решена в заданных допусках плана — она решается внутри, пофиг как. Если вылетает по допускам, или есть такой риск — эскалация на следующий уровень.
Организация внутри команд: как ни странно, в prince можно впихнуть agile на командном и тактическом уровне. Так бывает, так и называется, Prince Agile. Управленческая структура сохраняется, а внутри команд или даже целых стадий — работайте чем удобно, хоть скрамом, хоть досками, хоть гибридом.
Но: допуски за которые нельзя вылетать, и общий контроль сохраняются.
Гибриды
Тут да, можно сказать что из этих двух, «гибридизируются» они только на тактическом уровне, и то не очень шедеврально. Потому что agile и гибкие практики фокусируются на релизе, продукте, time to market — а эти два на плане, структуре задач, и фиксируют содержание работ. Фокус разный.
Плюс к тому, «непонятные» задачи исследовательского типа, которые нормально перевариваются в agile — в PMBoK/Prince вам запросто похоронят и оценки, и допуски, и ожидания по срокам/ресурсам.
Я уже писал, что лучше без понимания сути документов и их процессов, в эти игрища не играть, и не мешать людям работать неприменимой бюрократией.
Конкретно, если у вас кто-то сидит заполняет документы «потому что так требует методология», и по этому документу никакие решения не принимаются — уберите нафиг этот театр, выбросите этот документ, скажите «стопэ», т.к происходит какой-то бред.
Ритуалистика вам привнесет только профанацию и кучу ненужной работы.
Лучше корявый аджайл, чем иллюзия мертвого Prince — потому что последний тупо дороже выйдет.
Кстати да, давайте про практические косяки тогда. Ближе к жесткой реальности. Чтобы я вам тут исходные документы не пересказывал.
PMBoK: косяки и грабли
Масштаб документации (golden burden)
В пмбоке большая, реально большая нагрузка по требуемым документам. Стремление сделать всё по учебнику вам запросто похоронит проект, тк сожрет затрат больше, чем сам проект. Особенно если речь о проектах небольших.
Как бы это очевидно должно быть, вот только нифига не совсем: если, к примеру, внешний инвестор требует PMBoK-доки и отчетность, то кому-то придется ее генерить, а соскочить сложно, вы уже заранее на это подписались. Или аналогичная ситуация, когда проект готовится «на продажу». Доки ради доков.
Мой тут совет — оставьте доки, но сократите их объём. Всё, что больше печатной страницы = идёт нафиг. Команды не будут это читать, а вы задолбаетесь это писать. Получается смерть от процессов, и нафиг оно надо.
Управление рисками, которое не актуализировали
Это когда вначале придумали, написали документ (риски), и больше в него никто не заглядывал ваще никогда — хотя проект идёт, мир меняется — до момента, пока что-то отхлебнуло, встало раком, и все забегали смотреть «а кто там был в документе прописан за это ответственным».
То есть и оценки не обновили, и стратегию реагирования никто не читал, и точно не примерял на себя. Формально «управление» написали, а реально там сложены фантазии для галочки, и счас весь проект живенько подкосится об триггернувшую проблему.
Критерии стопа проекта (stop-loss)
Есть процессы закрытия (этапов), и они обязательны. С конкретными критериями, и их надо оценить, прописать заранее. Но что происходит: проблема упущенной выгоды и loss aversion, боязнь потерять уже вложенное.
В результате, паникующие менеджеры пытаются изобразить какую-то картину «отклонений», тянут проект, жгут бюджеты — вместо того, чтобы честно сказать «у нас ситуация стоп», давайте закрывать, дальше думать.
Надо прописывать конкретные цифры, конкретные нестыковки, конкретные убытки. И проверять. Ну да, риски — а что вы хотели.
Критерии бизнес-кейса
Возможность вписать в план не-количественные показатели, чтобы потом героически их достигать. Есть устав проекта, и у целей/показателей должны быть в связи с ним обоснования + показатели.
Иначе в документе появляется пункт «улучшить XXX» или «оптимизировать YYY», выгода с которого никому не понятна, а definition of done может уехать в любую сторону от нуля до бесконечности.
«Улучшить» — это на граммулечку достаточно, или надо чтоб до горизонта?
Такой фигней грешат менеджеры, которым на старте страшно, и хочется прикрыть задницу размытыми формулировками; чтобы оставался зазор на «подгонку под ответ». Интент понятен, но есть риск пустопорожней возни, сожженного времени команд и сомнительной выгоды.
Иллюзия контроля
То, что PMBoK заставил нас написать план, вот ваще не гарантирует (само по себе), что этот план будет синхронизирован с реальностью, и даже с бизнес-целью.
Нарисовали иерархию, гантовку, и эта простыня стала самоцелью — время потрачено, выглядит солидно, надо выполнять. Хотя по хорошему надо было после первого/каждого этапа тормознуться, и задать вопрос «а не фигню ли мы делаем».
Неготовность пересмотреть содержание (и да, сломать PMBoK) любой ценой no matter what — это способ похоронить и проект, и бюджет на него. Очень дорогая и ненужная упрямость.
То же самое про ценность. Мы зафиксировали «треугольник» время+деньги+работа. В нем нет вопроса «а нужен ли этот сделанный проект и сожженный бюджет» будет через полгода, когда все всё сделают по плану, умнички и заиньки. Будет такая прикольная золотая погремушка, которая никому никуда (уже) не нужна, рынок ушел, ситуация поменялась.
Люди
PMBoK, к сожалению моему, к человеческому фактору (рабочим ролям и выполняемым работам) относится чисто формально.
Вот есть рукопахарь, он делает X часов работы в день, значит за полгода сделает X*125 рабдней = иди рисуй их в гантовку.
А на практике цифра плавает, люди по разному работают с разными задачами, в разных условиях, даже в разных коллективах.
Коллеги срутся, люди выгорают, есть форс-мажоры, у кого-то жена в больнице, кто-то в Грузию уехал итд итп.
Всего этого в рисках толком нет, в планах и гантовках тоже особо не впихнешь. Значит, надо рисовать что-то с запасом «на проебать», что мало-помалу обесценивает идею жесткого плана на долгосроке.
Управление изменениями
Любое малейшее изменение в проекте эскалировать до Control Board, и документировать — вы шизанётесь от макулатуры. Ну т.е это писать change request, собирать минимум трех людей на принятие решения, журналировать его, писать change.
Если вы дом строите, где отклонения от стандарта редки — окай пусть. Если вы айтишные формочки рисовать будете, вот так бегая на каждую новую линию на экране — вы забегаетесь.
Так что уровень эскалации должен быть где-то прописан, и должен быть зазор на самостоятельные допущения, чтобы такой фигни не происходило.
Способы есть. Но точно не в PMBoK. Надо прикручивать снаружи.
PRINCE2: косяки и грабли
Набор проблем похожий, как раз там, где стандарты и методологии сами похожи. Но тем не менее.
Бюрократия и театр управления
В принсе прописан ряд ролей, которые участвуют в принятии решений и во всяких boards. Ролей много. А людей на небольших проектах мало. В результате получается, что одни и те же люди принимают решения на разных уровнях, просто потому что методология того требует: играть роли, проводить формальные собрания итд. Либо вообще, управленцев становится больше, чем реализаторов. Если такое произошло — ну не майтесь дурью, сократите управленческую вертикаль. Оставив исключительно приверженность к допускам — чтобы не получилось «сами подумали, сами планы поменяли», вот так нельзя.
Но плодить бюрократию ради процессов — фу и дроч. Даже если (вдруг) у вас есть внешний аудит, например инвестор требует prince. Не надо ради бюрократии хоронить здравый смысл.
Что еще здесь больно: одни и те же люди на разных уровнях решений — чревато конфликтом интересов. Особенно если это разные отделы, бюджеты, подрядчики итп. У нас много где идет речь о бизнес-обосновании кейса: может получиться, что руководитель отдела внедрения поручает внедрение своему же отделу, поскольку ему самому это выгодно, а решение принимал он сам.
В лучшем случае дорогое самообслуживание, в худшем потеря независимости внутри проекта и нечестные бизнес-оценки.
Разрыв в эскалациях
Может получиться такая фигня: сообщают о проблемах и граничных условиях одни люди (команды, менеджер) — а принимают решения другие люди (project board), которые с происходящим по факту вообще никак не связаны. Вдобавок, происходит это через месяц, когда все уже нафиг забыли что там было проблемного, что-то накостылили потому что план горит, и следом давайте обсуждать. Так не работает: это разрыв в коммуникации, и сам по себе он не полечится. Коммуникация превратится в «нам спустили задачи сверху», нереалистичность, лажа, потеря вовлеченности.
Либо шевелитесь быстрее, либо сокращайте составы (так можно: board неполным составом), либо вписывайте в анализ и принятие решений прямую коммуникацию верх-низ.
Еще смежная проблема: когда управленцы в project board вроде как есть, но решения нормально не принимаются в тот момент, когда это должно происходить по методологии. Конкретно: вот собрались 5 человек, у них конец рабочего дня, им пофиг, им нужно что-то сказать по каким-то вопросам (важным!) которые счас озвучит менеджер, они их первый раз слышат и лучше бы последний. Еще и проект у них не один. Что они ответят на вопросы? «Да сделайте уже там как-нибудь, чтобы поехало, вы блин сами умные».
В случае наступления жопы начинается аврал, беготня, разруливание, паника. То есть: решения принимали не по допускам вовремя, а аврально по факту. Вроде роли соблюдали, а контроль и предсказуемость — отсутствуют.
Тонна документов, и не-адаптация подходов
Сдуру можно и хер сломать. Если не адаптировать prince под реальность — в основном, выкидывая воду, и сокращая раздутость документов — то получается как в PMBoK, golden burden и потеря смыслов за макулатурой. Что даже более больно, потеря времени на ритуалистику с цепочками документов туда-сюда. Тяжесть проекта и внедрения усугубляется тем, что Agile с подобной фигней справляется лучше, как минимум быстрее. Иногда упущенное время важнее структуры управления. Пока вы тут заседаете, конкуренты продукт выкатывают.
В этом же пункте грабли: попытка заменить живое общение и обсуждение документооборотом. Вон типа стандарт нам предписывает «описать в документе» — идите, читайте — ой, никто не читал, все забили. Бюрократическая транзакция должна документировать происходящее нормальное общение/решение, а не подменять его целиком.
Критерии стопа / допусков
Как и в соседнем стандарте. Вылет за допуск должен быть однозначной эскалацией, и следом взвешенным решением «идём ли мы дальше». Если да, то как. Причем на этапе прогноза. Никаких «мы дотащим, мы допилим, ну там почти» и естественно без приукрашиваний, вранья и подгонок под ответ.
Но люди это люди, и менеджер у которого на допусках лежит минус-премия, заинтересован скрыть превышения бюджетов, вылеты за сроки итд итп. Это проблема. Её надо адресовать.
Обучение на опыте (и постмортемы)
В Prince есть lessons log, который очень похож на постмортем: где мы обосрались, что пошло не так, как мы это будем исправлять и не-повторять в дальнейшем. Вопрос в том, что внутри него будет написано.
На практике, если не ходить и не проверять — там будет написано вроде «мы не попали в планы = надо было лучше планировать».
Это очевидная лажа, но если на нее не обратить конкретного практического внимания — она такой и останется. Кусок методологии не будет работать.
Так что придется быть конкретным.
Браться как за PMBoK, так и за PRINCE, если вы (пока) не видите для себя конкретные преимущества в их тяжелой артиллерии, развесистой структуре и макулатуре — я бы горячо не рекомендовал.
Если вдруг так получилось, что вы уже — вас запросто похоронит бюрократическая профанация и театр, если вы позволите ему случиться.
Или делайте компактно и по сути, или откажитесь в пользу более легких подходов.
Бизнес-ценность с оценкой, и прозрачность с контролем (без приукрашиваний и подгонок под ответ) — это core vitals, без них будет цирк.