+24 голоса |
Так увлекся подготовкой Темы недели по проектному менеджменту, что даже не рассказал о втором занятии курса по управлению проектами. А тут уже и третье прошло. Буду наверстывать упущенное.
1. Итак, второе занятие было посвящено вопросам управления содержанием (Scope Management). Эта область знаний весьма трудная и важная – не задав корректно объем работ, реализовать проект будет невероятно сложно. В то время как другие ограничения проекта (стоимость и длительность) могут в процессе в той или иной мере изменяться и это не приведет ни к чему катастрофическому, изменение объема работ чревато самыми серьезными последствиями.
2. Практически любой проект стремится "развалиться", так как в него постоянно добавляются новые ограничение, требования и пр., усложняющие его реализацию. Поэтому все это необходимо учитывать, планируя работы. Вообще планирование – постоянный процесс.
3. В PMBOK 4 появилась матрица трассировок требований (Requirements Traceability Matrix). В результате декомпозиции стратегических целей компании получается такая таблица, соотносящая конкретные требования к проекту с исходными данными. Она позволяет видеть значимость каждого требования с точки зрения бизнес и проектных целей и следить за их реализацией.
4. Прописная истина: если нет связи между стратегическими и операционными целями проект необходимо отменять.
5. Важные зависимости.
Кривая распределения степени влияния участников проекта в течение его жизненного цикла:
Кривая распределения стоимости (и ресурсов) в течение жизненного цикла проекта:
Т. е. на начальных этапах, когда на проект еще не потрачено много средств, акционеры проекта могут влиять на него. На завершающих, когда затраты высоки, мнение заинтересованных лиц уже не так важно -- в это время проект нужно вести к концу, а не изменять.
6. Также присутствуют две другие зависимости, имеющие место при принятии решений группами. Чем больше власти сконцентрировано в руках одного человека (т. е. уровень диктатуры), тем меньше времени тратится на принятие решения. Так что демократия (в наивысшей своей степени она выражается в том, что с мнением каждого участника обсуждения нужно считаться), в данном случае не всегда приемлема. Если необходимо принять решение в разумный срок, руководителю проекта необходимо брать дело под свой контроль. С другой стороны, чем выше уровень диктатуры, тем выше риск принятия неверного решения. В общем, как и во многих жизненных ситуациях, нужна некая «золотая середина».
7. Умение декомпозировать цели в задачи отличает профессионала в области управления проектами от дилетанта. Хотя считается, что задача должна быть уточнена до минимально возможного уровня, который и определяет каждый конечный результат проекта, фанатизма следует избегать. В детализации должна быть целесообразность. Если минимальная задача в проекте занимает 15 минут, дальше идти, как правило, просто нет смысла.
Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365
+24 голоса |
Слегка оффтопик. Что меня всегда поражало в любой прикладной дисциплине, так это та пропасть, которая зияет между ее теоретической базой и ежедневной практикой. Например, я не очень понимаю, как можно учиться, скажем, верховой езде, изучая особенности поведения сферического коня в вакууме :) А большинство книг по менеджменту занимается, как по мне, именно этим...
Надеюсь, хотя бы у вас на курсах практика будет?
конечно, теория без практики мертва.
чтобы закрепить полученные знания, каждый участник курсов должен применять их в своей каждодневной работе
Тоже оффтопик.
Фраза "сферический конь в вакууме" - любимейшая в арсенале Владлена Березина, ведущего этот курс тренингов :)
Кстати, было бы интересно услышать его мнение по поводу Вашего замечания.
Видел я как-то, как новичков учат на лошадях ездить. Сначала - обязательно скажут, что к лошади сзади не подходить (риски), потом - как на нее залезать (содержание), потом - как держать повод и т.д. А, если, на первом занятии дадут на нее влезть и проехаться, то уж не самому. У нас же все практики, получается-) Залезу, набью себе шишки (в лучшем случае), куда-то доеду... Ну ладно бы самому плохо было, а так ведь проекты валят почем зря...
Это был оффтоп. А по сути - что практика без теории, что теория без практики - вещи одинаково опасные. Что тут комментировать?
Безусловно, нужно применять теоретические знания на практике, иначе толку никакого. Но есть еще один момент - стиль изложения теоретического материала.
Дело в том, что большинство стандартов по УП (такие, как PMBOK) написаны так, чтобы их можно было применять независимо от сферы деательности, в которой реализуется проект. Например, в PMBOK вы не найдете никакой специфики по УП в области разработки ПО.
Выход, думаю в том, что кроме общих стандартов руководитель проекта должен ознакомиться с литературой по УП в данной конкретной сфере деятельности.
Тогда разрыв между теорией и практикой станет меньше.
PMBOK как раз и задуман как стандарт управления любыми проектами.
Для специфических областей применения существуют отраслевые стандарты. Для разработки ПО, например, существует SWEBOK (Software Engineering Body of Knowledge).
Не спорю, так и есть.
Просто когда читаешь его в первый раз, то действительно создаётся впечатление, что пишут там о "сферических конях".
Потому и говорю, что для более полного понимания вопроса нужно пользоваться еще и отраслевой литературой (не только стандартами, т.к. стандарты обычно пишутся не совсем простым языком).
Насчет языка - первый раз его читать сложно. Для этого и курс такой. Насчет специализированной литературы - конечно. Только она на стандартах основывается... По сути - язык 4-го PMBOKа для новичков сложен. Это факт. Поэтому курс "Практические методы управления проектами" мы читаем по 2-му изданию. Он много проще в понимании, хоть и больше в процессах (54 и 42).
Я, собственно, клоню к тому, что в управлении проектами важность теоретических знаний иногда не столь высока, как наличие как практических навыков, так и вообще способностей к этому делу.
Умение выполнять поставленные задачи точно и в срок, причем разной степени сложности, с учетом всех обстоятельств, в любой предметной области -- а именно этому, как я понимаю, учит ПМ -- это, если хотите, все же своего рода искусство, доступное не всем. Потому что для того чтобы в нем преуспеть, помимо формальных знаний и приоретаемых навыков, нужен еще и своеобразный талант.
Так вот -- знания приобрести достаточно просто (как и потерять потом, ага); навыки и опыт, наблюдая за тем, как это делают другие и самостоятельно тренируясь "на кошках" -- чуть сложнее, но тоже вполне по силам. А вот талант(который, вообще говоря, тоже можно нарабатывать и приобретать) -- это самая большая проблема. Потому что формальные методы здесь не подходят совершенно. А какие подходят? И что нужно делать, чтобы наработать и приобрести такой талант? И вообще, талант в какой-либо области?
Вот это - вопрос. Правда, наука на него ответа не дает, и дать не может. Но, впрочем, наукой жизнь не исчерпывается...
Прошу прощения за оффтопик, просто под настроение :)
И вообще, талант в какой-либо области?
Вот это, как по мне, очень хороший вопрос. Дело в том, что теоретическая литература по УП утверждает (небезосновательно), что УП - это отдельная область знаний, и что специалист по УП может одинаково успешно работать, скажем, в области разработки ПО и в области сельского хозяйства.
Что касается практики, то сомневаюсь, что это так на все 100.
Думаю, что прежде всего нужен талант организатора.
...специалист по УП может одинаково успешно работать, скажем, в области разработки ПО и в области сельского хозяйства.
Теперь ключевой вопрос. Что говорит литература по поводу того, должен ли этот самый специалист быть специалистом не только в УП, но и специалистом непосредственно в области разработки ПО либо в области сельского хозяйства?
Если утверждается, что это необязательно -- ох, снова мерещится мне призрак сферического коня в вакууме... :)
В PMBOK такого утверждения (что это необязательно) не встречал, но встречал в других источниках.
Полностью согласен с замечанием про коня :)
Думаю, что для успеха необходимо разбираться как в УП, так и в специфической для проекта области.
Кстати, только что вспомнил - видел на одних курсах по УП пояснение по этому вопросу. Суть в следующем.
Различают несколько "типов" менеджеров проектов - для нас важны менеджер-лидер и менеджер-эксперт. В учебном пособии был приведен график востребованности менеджеров различных типов в зависимости от размера проекта (числа сотрудников). Так вот, в маленьких проектах важны знания предметной области и востребованы менеджеры-эксперты. В больших лучше справляются менеджеры-лидеры.
Объясняется это тем, что в большом проекте, как правило, менеджер находится довольно далеко от непосредственных исполнителей и от него больше требуется умение "вести армию к победе". В маленьком же проекте менеджер непосредственно ставит задачи исполнителям, и здесь знания предметной области довольно существенны.
было бы здорово, чтобы Вы обсуждали PMBOK, прочитав его. Во введении (essentials) об областях знаний ПМа сказано четко и даже картинка есть (кружочки такие). А именно - что представляет собой управление проектами и какими умениями и знаниями должен обладать профессиональный ПМ. Когда прочитаете - можно будет говорить не о сферическом коне...
По поводу "больше практики" - тут даже сложно комментировать. Процент приведу только, чтобы понятно было. Вероятность успеха проектов в организациях, тотально использующих проектную методологию - 68%. В неиспользующих - 32%.
По-моему, все ясно.
Тот же PMBOK утверждает, что для того, чтобы эффективно управлять проектами, необходимо:
- обладать знаниями по управлению проектами
- обладать навыками межличностных отношений
- обладать знаниями и навыками в области общего менеджмента
- иметь понимание окружения проекта
- обладать знаниями стандартов и нормативных актов для данной конкретной области применения
Так что без экспертизы в конкретной области - никуда :)
Короче говоря, подтверждается тот факт, что нередко определенные некорректные убеждения (или сомнения и недопонимания) формируются как раз из-за банального отсутсвия знаний по предмету. Матчасть все-таки надо учить (с) Особенно, если речь идет о непростой области типа управления проектами.
Это видно по комментам. Именно для этого тренинги такие и читают. И именно поэтому сертифицируют ПМов. PMP такие вещи бы не обсуждал. ИМХО.
1. Итак, второе занятие было посвящено вопросам управления содержанием (Scope Management). Эта область знаний весьма трудная и важная – не задав корректно объем работ, реализовать проект будет невероятно сложно. В то время как другие ограничения проекта (стоимость и длительность) могут в процессе в той или иной мере изменяться и это не приведет ни к чему катастрофическому, изменение объема работ чревато самыми серьезными последствиями.
Коммент: вышесказанное верно про стоимость, не про длительность. Все ограничения и области знаний (типа рисков) в конечном итоге выражаются в 2-х вещах - в изменении набора работ (содержание) или/и в изменении длительности этих работ. А стоимость - уже результирующий показатель. Сама по себе она может меняться только при изменении стоимости назначенных на работы ресурсов, что не смертельно. Впрочем, мы это в следующую пятницу будем рассматривать детально-)
И - спасибо за коммент, Андрей.