`

СПЕЦІАЛЬНІ
ПАРТНЕРИ
ПРОЕКТУ

Чи використовує ваша компанія ChatGPT в роботі?

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Андрій Кухар

PM 2. Объем имеет значение

+24
голоса

Так увлекся подготовкой Темы недели по проектному менеджменту, что даже не рассказал о втором занятии курса по управлению проектами. А тут уже и третье прошло. Буду наверстывать упущенное.

1. Итак, второе занятие было посвящено вопросам управления содержанием (Scope Management). Эта область знаний весьма трудная и важная – не задав корректно объем работ, реализовать проект будет невероятно сложно. В то время как другие ограничения проекта (стоимость и длительность) могут в процессе в той или иной мере изменяться и это не приведет ни к чему катастрофическому, изменение объема работ чревато самыми серьезными последствиями.

2. Практически любой проект стремится "развалиться", так как в него постоянно добавляются новые ограничение, требования и пр., усложняющие его реализацию. Поэтому все это необходимо учитывать, планируя работы. Вообще планирование – постоянный процесс.

3. В PMBOK 4 появилась матрица трассировок требований (Requirements Traceability Matrix). В результате декомпозиции стратегических целей компании получается такая таблица, соотносящая конкретные требования к проекту с исходными данными. Она позволяет видеть значимость каждого требования с точки зрения бизнес и проектных целей и следить за их реализацией.

4. Прописная истина: если нет связи между стратегическими и операционными целями проект необходимо отменять.

5. Важные зависимости.
Кривая распределения степени влияния участников проекта в течение его жизненного цикла:

PM 2. Объем имеет значение

Кривая распределения стоимости (и ресурсов) в течение жизненного цикла проекта:

PM 2. Объем имеет значение
Т. е. на начальных этапах, когда на проект еще не потрачено много средств, акционеры проекта могут влиять на него. На завершающих, когда затраты высоки, мнение заинтересованных лиц уже не так важно -- в это время проект нужно вести к концу, а не изменять.

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-х вещах - в изменении набора работ (содержание) или/и в изменении длительности этих работ. А стоимость - уже результирующий показатель. Сама по себе она может меняться только при изменении стоимости назначенных на работы ресурсов, что не смертельно. Впрочем, мы это в следующую пятницу будем рассматривать детально-)

И - спасибо за коммент, Андрей.

 

Ukraine

 

  •  Home  •  Ринок  •  IТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Мережі  •  Безпека  •  Наука  •  IoT