Страница 1 из 5 12345 ПоследняяПоследняя
Показано с 1 по 30 из 147
  1. #1

    По умолчанию PMBoK 2008: обзор по главам

    Решил завести обсуждение для PMBoK 2008, буду кратко рассказывать, что нового увидел, в первую очередь для себя (а рассказывать буду для других). Кстати, несмотря на то, что он на английском, читается он легко. Читаю я PMBoK 2008 Exposure Draft, ибо другого ничего не нашел.

    Буду рад замечаниям и комментариям, а также поправкам.

    Пока прочел первую главу, но уже несколько откровений.
    Начнем по порядку. Всё начинается с введения, и цели стандарта. Опять слова про best practices и ответственность организации/project management team за его применение. Цель стандарта - дать обзор практикам проектного управления. Также сходу дано упоминание про Code of Ethics, что они есть и что он описывает ожидания от самих себя практиков проектной деятельности.

    Определение проекта не поменялось, это по-прежнему временное предприятие по созданию уникальных продукта, услуги или результата. Утверждается, что управление временным предприятием по созданию нечто уникального как проектом, позволяет достичь набора бизнес-целей более эффективно (efficiently and effectively).

    Понятие управления проектом немного изменилось, и включает в себя инициирование, планирование, исполнение, мониторинг и контроллинг (надеюсь дальше пояснят), закрытие. И что самое интересное (наконец-то!), стали говорить совместно о четырех составляющих: о балансе содержания, расписания, качества и бюджета. Насколько я помню, ранее говорилось о трёх. Также сразу упомянуто об итеративности процессов проектного управления.

    Сразу же также говорится о взаимосвязи управления портфелем, программой и проектами. Портфель включает в себя портфели, программы и проекты, программа включает в себя проекты. ВНИМАНИЕ. Сразу говорится о взаимосвязи стратегического планирования и проектной деятельности. "Проекты часто используются как способ реализации (достижения) стратегических планов" (Projects are often utilized as a means of achieving an organization's strategic plan). Задачи портфельного же управления следуют за задачами стратегии.

    Вот появилось и упоминание о проектном офисе. Управление разделяемыми ресурсами, развитие и регламентация методологии проектного управления, координация межпроектных коммуникаций.

    Связь проектного управления и операционной деятельности. Утверждается, что результаты (имеется ввиду deliverables) проекта передаются в операционную деятельность в определенных точках ЖЦ проекта.

    Роль менеджера проектов. Ну, тут тоже самое что и 2004ом PMBoK по-моему. Все те же skills.

    Далее описание Project Management Body of Knowledge и пересечение с другими понятиями (неинтересно...). Standard describes project management processes, tools and techniques for managing scope, schedule, quality and cost, as well as any project environment aspects that influence the project's outcome. Блаблабла.

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

    На том пока всё. Завтра возьмусь за вторую главу.
    Последний раз редактировалось Andruxa; 20.04.2009 в 20:50.

  2. #2

    По умолчанию Глава вторая

    Жизненный цикл проекта и Организация. Эта глава описывает базовые представления о структуре проекта и как организация связана с проектом.

    По поводу ЖЦ - ничего принципиально нового: жизненный цикл по PMBoK2008 - совокупность последовательных фаз, название и число которых определяется нуждами вовлеченной в управление организации(й). ЖЦ предоставляет базовую основу для управления проектом независимо от специфики его работ.

    Потом речь заводится о характеристиках ЖЦ проекта. Ничего особенного кроме утверждения, что любой проект бьётся на Старт, Подготовку и Организацию, Выполнение работ и Окончание проекта. Типа для топ-менеджмента глубже и не надо (в общем-то да). Опять старые картинки про то, что затраты и число привлеченного персонала в ходе проекта сначала растут потом падают, картинка про стоимость изменений - в конце изменения обходятся очень дорого.

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

    Далее идёт речь о фазности проекта. Мол, может быть одна или много фаз. Это не то, о чем говорилось в структуре ЖЦ, фаза - это совокупность логически связанных активностей, которые обычно заканчиваются поставкой. Что самое интересное, утверждается что нет одного пути для определения идеальной структуры проекта (да, стратегии).

    Руководство проектом может подразумевать прерывание проектов по завершению фазы. Так-то. И ещё какие-то неглубокие мысли в разделе Project Governance Across Life Cycle.

    А вот теперь - новости. Отношения фаз. Помимо стандартных последовательного выполнения и быстрого прохода (когда вторая начинается раньше конца первой), появилось итеративное отношение, когда дальнейшие работы планируются уже по завершению поставки фазы. Утверждается, что это используется в часто менющихся средах, или для таких работ как Research and Development... но это влечет за собой необходимость в содержании проектной команды на всём протяжении итеративных фаз, а также упоминается о рискованности подхода.

    Опять какие-то слова про различия и сходства проектной и операционной деятельности. Наверное для тех, кто вообще впервые сталкивается с понятием проекта.

    Стэйкхолдеры. Их много. Мне понравилась фраза: Likewise, project managers who ignore stakeholders can expect a negative impact on project outcomes. Также теперь четко проговорено про позитивных и негативных аффилированных лиц - мол одним от проекта хорошо, а другим - плохо.

    Как и в ITIL (или ISO), PMBoK проводит различие между Заказчиком и Потребителем. Что не может не радовать. Кстати хорошо отмечено про то, что эти ребята сильно влияют на содержание проекта (я бы сказал - практически они его и определяют).

    Пару слов про спонсора, управляющего портфелем, менеджера программы (опять сказано, что программа - это когда есть выгода от управления несколькими проектами как единым целым). Офис Управления Проектами также выделен в отдельного стэйкхолдера, как и проджект-менеджер, как и проектная команда, как и функциональные менеджеры. Далее описываются некто операционные менеджеры (кто отвечает за производство), что они могут предоставлять народ и другие ресурсы для проектов, как и проект в их руки передает результаты и документацию например. Вобщем, вода. Ещё про вендоров налили напоследок раздела стэйкхолдеры.

    Влияние организации на проектное управление. Сначала говорится, что в организации есть культура и нормы, и что PM должен знать, кто конкретно в организации самый ЛПР, и работать с ним, чтобы достичь влияния на project success. Далее идут организационные матрицы, все их мы видели ещё в 2004 PMBoK, ничего нового.

    Активы организационного процесса. Волшебная мантра предыдущего PMBoK, предполагалось что они чуть ли не каждый процесс обуславливали. Что новенького, так то, что здесь они бьются на две категории - процессы и процедуры, и корпоративная база знаний. И то и другое хорошо расписано.

    В целом, ничего. Пишут подробнее, чем в прошлый раз, хотя много и воды, чего-то и не достаёт (например, про стэйкхолдеров слабо описано, не сказано явно - только на примере, что это все, кого проект затрагивает).

  3. #3

    По умолчанию Глава третья - процессы управления проектом для проекта.

    Управление проектами - приложение знаний, навыков, инструментов и техник к активностям проекта для удовлетворения требований проекта.

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

    И самое главное. Проектные процессы бьются на две категории: процессы управления проектом (описываются областями знаний) и продуктово-ориентированные процессы (определяются ЖЦ продукта).

    Группы процессов управления (далее речь будет идти только о них) следующие, это те же самые:
    1. Процессы инициации,
    2. Процессы планирования,
    3. Процессы исполнения,
    4. Процессы мониторинга и контроллинга. Нужны для отслеживания, обзора (пересмотра), и регулирования прогресса и исполнения проекта.
    5. Группа процессов закрытия проекта.
    Далее старые картинки про активность процессов в течении жизни проекта, ничего нового. Далее приведены две хороших картинки про пересечение процессов по группам и пересечение групп с областями знаний (те же самые 9). Всего 42 процесса, что меньше чем в предыдущем. В прошлом их было 44 что ли. [update]Общая картинка на самом деле изменилась: теперь процессы контроля как бы "оборачивают" процессы инициации, планирования, исполнения и закрытия.

    Вот пошли и процессы инициации, первый процесс - разработка устава проекта. Второй - идентификация аффилированных лиц (очень хорошо, по-моему новый процесс). Выходы его - реестр стэйкхолдеров и Stakeholder Management Strategy. Вот даже так.

    Процессы планирования - нужны для установления содержания, определения целей, определения курса действий (стратегии?..) для достижения целей. Разработка плана управления проектом. Сбор требований (один из выходов - план управления требованиями). Определение содержания. Создание Work Breakdown Structure. Определение активностей (специфичные действия по созданию поставок - delivarables - проекта). Упорядочивание активностей. Оценка ресурсов активностей. Оценка длительности активностей (работ). Разработка расписания. Оценка затрат. Определение бюджета. Планирование качества. Разработка HR-плана. Планирование коммуникаций. Планирование управления рисками. Идентификация рисков, качественный и количественный анализ рисков, планирование реагирования на риски. План поставок. Фух.

    Процессов исполнения поменьше. Управление исполнением проекта. Контроль качества. Набор проектной команды. Развитие проектной команды. Управление командой проекта. Распространение информации. Управление ожиданиями стэйкхолдеров. Руководство поставками.

    Процессы мониторинга: мониторинг и управление проектной работой (включая отчетность и прогнозирование), управление изменениями, проверка содержания (этот зверь о приемке уже готовых deliverables(!)), управление содержанием, управление расписанием, управление затратами, выполнение управления качеством, сбор отчетности, управление рисками, администрирование поставок.

    Процессы закрытия. Закрытие проекта или фазы. Закрытие поставок.

    В итоге. Произошли изменения, причем в лучшую сторону очевидно (кому нужны детальные подробности - они тут). По-крайней мере, новый PMBoK мне уже субъективно и по памяти нравится больше. Он стал более жизненный, что ли.

    Что ж, общие главы закончены, остались лишь области знаний. Оттуда я не буду выдирать все подряд, а лишь то, что запомнится по прочтению.
    Последний раз редактировалось Andruxa; 23.04.2009 в 10:58.

  4. #4
    Член сообщества
    Регистрация
    22.11.2005
    Сообщений
    315

    По умолчанию

    Скромный комментарий: никак не могу уловить систему в вашем изложении

  5. #5

    По умолчанию

    Система простая - вылавливаю основное (для управления проектами, IMHO конечно же, но думаю что недалек от истины) + излагаю последовательность, приведенную там

    В основном, пытаюсь выловить что-то новое в проектном управлении, чего до PMBoK 2008 не видели, или от него не ожидалось вообще. Впереди ещё будут прототипы, я их с нетерпением жду. Из опыта и из HBR - это очень важная деталь любого проекта.

    А какую систему бы хотелось?

  6. #6
    Член сообщества
    Регистрация
    25.11.2005
    Сообщений
    1,731

    По умолчанию

    Цитата Сообщение от Еремченко Сергей
    Скромный комментарий: никак не могу уловить систему в вашем изложении
    Не стреляйте в пианиста - он играет, как умеет.
    Не требуйте многого от инициативы постующего. Выстраивайте систему у себя, на основе его информации.
    Андрей просто фиксирует увиденные им основные отличия от предыдущего, третьего классического издания PMBOK 2004 года.
    Андрей, продолжайте, лично мне это важно.

  7. #7
    Член сообщества
    Регистрация
    19.12.2005
    Сообщений
    1,108

    По умолчанию Давайте уточним...

    Цитата Сообщение от Andruxa
    Система простая - вылавливаю основное (для управления проектами
    "Основное" для управления ВАШИМИ ВИДАМИ проектов, в ВАШИХ КОНКРЕТНЫХ условиях.
    То, что "выловите" ценное для Вас, может не подойти для других, или оказаться неполным. Так что лентяям придется самим читать РМВоК, а не ждать от Вас дайджест, или цитатник.
    Проект, проекту - рознь. Слишком они разные бывают, а PMBoK - сборник всяких правил, но горе тому, кто попытается применить ВСЕ правила РМВоК в проекте "покупка батона хлеба, по дороге с работы".
    А ведь это тоже проект.
    С уважением Виталий.

  8. #8

    По умолчанию

    Цитата Сообщение от eliferov
    "Основное" для управления ВАШИМИ ВИДАМИ проектов, в ВАШИХ КОНКРЕТНЫХ условиях.
    То, что "выловите" ценное для Вас, может не подойти для других, или оказаться неполным. Так что лентяям придется самим читать РМВоК, а не ждать от Вас дайджест, или цитатник.
    Ну я в первом посте всё так и обозначил... пишу скорее чтобы поделиться находками. Русского ждать еще долго - до лета по-моему, зато уже сейчас можно посмотреть, что же нас ждёт. Но надеюсь, что мне удастся соориентировать, что где в нём можно посмотреть уже сейчас. Например, Егору Ракитину (ау!) можно уже посмотреть взаимосвязь между стратегией, портфелями, программами и проектами.
    Проект, проекту - рознь. Слишком они разные бывают, а PMBoK - сборник всяких правил, но горе тому, кто попытается применить ВСЕ правила РМВоК в проекте "покупка батона хлеба, по дороге с работы".
    А ведь это тоже проект.
    С уважением Виталий.
    Да. Зато там куча всяких умных мыслей, по типу "в проектах бывает так, а бывает и вот этак". Я и сам, дважды пройдя обучающие курсы по PMBoK, прочитав его от корки до корки, лишь убедился, что подход - тяжеловатый в принципе.

    Мне нравится сам процессный его подход (в IPMA скажем не так всё строится), + деление на области знаний. В общем, это просто большой качественный интересный стандарт, для меня скорее даже книжка. Еще важна помимо подхода - сама терминология. Которой я тоже делюсь, в своём правда корявом переводе.

  9. #9

    По умолчанию

    Да, кстати, в стандарте так и сказано:
    Good practice means there is a general agreement that the application of those project management processes has been shown to enhance the chances of success over a wide range of projects. This is does not means that the knowledge, skills and processes should always be applied uniformly on all projects. For any given project, the project manager, in collaboration with the project team, is always responsible for determining which processes are appropriate, and the appropriate degree of rigor for each process.

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

    Главное - процессы и их выходы. Кстати первые три главы - это самая основа для всего остального. Всё остальное строится в PMBoK на том, что описано и представляет собой лишь детальное описание процессов - как их выполнять, с помощью какого инструментария. Вот этот инструментарий тоже составляет (мой) интерес.

  10. #10
    Член сообщества
    Регистрация
    22.11.2005
    Сообщений
    315

    По умолчанию

    Цитата Сообщение от Евгений_Кс
    Не стреляйте в пианиста - он играет, как умеет.
    Не требуйте многого от инициативы постующего. Выстраивайте систему у себя, на основе его информации.
    Андрей просто фиксирует увиденные им основные отличия от предыдущего, третьего классического издания PMBOK 2004 года.
    Андрей, продолжайте, лично мне это важно.
    Перечитал первый пост автора темы, понял, что был не прав, ожидая от темы именно обзора PMbok2008 по главам

  11. #11

    По умолчанию

    Цитата Сообщение от Еремченко Сергей
    Перечитал первый пост автора темы, понял, что был не прав, ожидая от темы именно обзора PMbok2008 по главам
    Я открыт для пожеланий

  12. #12
    Член сообщества
    Регистрация
    11.09.2008
    Сообщений
    2,549

    По умолчанию

    Андрей - молодец, тему читаю с интересом.

  13. #13
    Член сообщества
    Регистрация
    10.02.2009
    Сообщений
    1,257

    По умолчанию

    Цитата Сообщение от Bend
    Андрей - молодец, тему читаю с интересом.
    Полностью поддерживаю и жду продолжения!

  14. #14

    По умолчанию

    Если системно излагать - то получится сам PMBoK
    Завтра продолжу...

  15. #15

    По умолчанию Глава четвертая - Управление интеграцией

    Подход следующий: управление интеграцией проекта включает в себя процессы и работы по идентификации, определению, объединению, унификации и координации различных процессов и работ по управлению проектом различных групп управления проектом.

    В принципе, процессов этой области знаний уже достаточно для управления проектом

    Включает в себя следующие процессы: разработка устава проекта, разработка плана управления проектом, управление исполнением проекта (выходы - deliverables), мониторинг хода выполнения, управление изменениями, закрытие проекта или фаз.

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

    По большей части, ничего нового, но на чем хотелось бы остановиться. По прежнему, устав - это то, что инициирует проект, в качестве одного из входов выделяется:
    Statement of Work (положение о выполнении работ):
    • "Бизнес-потребность" (Business need) - то, что инициирует проект со стороны бизнеса,
    • Описание содержания,
    • Стратегический план (Strategic plan). "Все проекты должны поддерживать организационные стратегические цели", стратегический план выполняющей проект организации должен рассматриваться как фактор при принятии решений по выбору и приоритезации проектов.
    Разработка плана управления проектом по-моему не изменилась существенно, также (как и для Project Charter, устава) в качестве инструмента создания рассматривается Expert Judgement. Что интересно, среди инструментов исполнения процесса управления исполнением проекта появилась КСУП (Project Management Information System) и рассматривается как часть организационной среды, в которой проект выполняется. При рассмотрении процесса управления изменениями уделяется внимание интеграции с Configuration Management System.

    Больше ничего хоть сколько-нибудь волнующего (IMHO конечно) в данной главе не встретил. Всё тот же подход, всё то же управление интеграцией.

  16. #16

  17. #17

    По умолчанию Глава 5 - Управление содержанием

    Управление содержанием проекта включает процессы, необходимые для уверенности в том, что проект включает все необходимые работы (и только их) для достижения успеха проекта.

    Процессы этой области знаний: сбор требований, определение содержания, создание СРР (структуры разбиения работ), проверка содержания, управление содержанием.

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

    Самое интересное - это инструменты для сбора требований.
    В качестве таких инструментов выделяются
    • интервью - стандартно и привычно,
    • фокус-группы! интересно и свежо,
    • воркшопы - группы по разработке,
    • техники групповой работы (брэйнстормы, делфи, майнд-мэппинг! и др.)
    • групповое принятие решений,
    • опросники и опросы,
    • наблюдение... говорят ещё также job shadowing, что показывает как оно должно происходить
    • прототипы. говорят, удобно для быстрого получения обратной связи от стэйкхолдеров. более того, сразу говорится что прототипы поддерживают концепцию progressive elaboration - итеративной разработки.
    Ещё одна интересная вещь, не помню была она или нет - requirement traceability matrix - таблица, связывающая требование, его происхождение и нужная для его отслеживания в течении ЖЦ проекта. Утверждается, применение этой матрицы помогает убедиться в что каждое требование добавляет business value, путем привязывания его к бизнес- и проектным целям. Короче говоря, это табличка, показывающая, как в течении ЖЦ выполняются все нужные требования.

    update Также сказано что важно разграничивать как то, что входит в содержание, так и ясно проговаривать то, что не входит.

    Насчет определения содержания и составления WBS - всё то же самое (только про WBS появились примеры). Интересная штука - Verify Scope. Это проверка того соответствует ли продукт изначально заявленным требованиям (выполняет после проверки качества). Отличается от контроля качества, потому что контроль качества направлен (по PMBoK) на проверку соответствия продукта требованиям по качеству, но не по содержанию продукта.

    Ну и последний процесс - Control Scope. Очень интересно и по-моему, вполне достаточно, про него сказано: uncontrolled changes are often reffered to as project scope creep. Короче говоря, если содержанием не управлять, то оно расползётся

    Интересная глава вобщем, рекомендую к прочтению. Кстати, по прочтению этой главы промелькнула мысль - процессы-то все несложные, и не так уж сложно подходящей автоматизацией добиться их выполнения (всех). Достаточно даже по абзацу текста ввести на каждый процесс, чтобы утверждать полную поддержку PMBoK. То есть принципиально это реализуемо... на практике -- требует обоснования необходимости введения каждого дополнительного процесса.
    Последний раз редактировалось Andruxa; 27.04.2009 в 10:23.

  18. #18
    Член сообщества
    Регистрация
    25.11.2005
    Сообщений
    1,731

    По умолчанию

    Цитата Сообщение от Andruxa
    Кстати, по прочтению этой главы промелькнула мысль - процессы-то все несложные, и не так уж сложно подходящей автоматизацией добиться их выполнения (всех). Достаточно даже по абзацу текста ввести на каждый процесс, чтобы утверждать полную поддержку PMBoK.
    Если мысль промелькнула и улетела - ну и пусть ее.
    Если же осталась - поясните.
    Как это автоматизацией добиться от людей выполнения? Под дулом автомата что ли?
    Спасибо за презентацию различий между буками, и за наводку на блог К. Трунина.

  19. #19

    По умолчанию

    Цитата Сообщение от Евгений_Кс
    Как это автоматизацией добиться от людей выполнения? Под дулом автомата что ли?
    Почти Просто проставить обязательные для заполнения поля. Если человек не заполнил - дальше не двинется. А вводить просто предложения - начальство не даст. Да и смысл - если надо заполнить, PM подумает всё же, что же туда занести... например, таблица рисков. PM Expert "пропагандирует" например такой подход - составляется корп. реестр стандартных рисков (штук 300), а из них выбирается уже подходящие для проекта. Вот почему бы так не автоматизировать процесс оценки рисков? Ну и другие обязательные для заполнения поля в КСУП ввести.

    Да и вообще, чтобы это структурированно выглядело, все документы по проекту оформить в виде электронных форм. Это удобно по-моему. Я кроме MS Project других КСУП не знаю, наверняка в какой-нибудь Primavera так и делается.

  20. #20
    Член сообщества
    Регистрация
    25.11.2005
    Сообщений
    1,731

    По умолчанию

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

  21. #21

    По умолчанию

    Хм... PM'ы должны обладать какими-то знаниями предварительно, проникнуться пониманием значимости выполнения процессов, иметь целостную картину. А иначе это будет свалка, согласен.

  22. #22

    По умолчанию Глава 6 - управление расписанием.

    Честно говоря, эта глава показалась мне скучной - вообще-то ничего нового.

    Процессы: определение работ, определение порядка выполнения работ, оценка ресурсов работ, оценка длительностей работ, разработка расписания, управление расписанием.

    Из интересного - так это картинки. Их стало больше, они стали нагляднее. Хотелось бы также обратить внимание на такой момент, как атрибуты работ. Они появляются в результате процесса определения работ (тесно пересекающегося с составлением WBS), и эти атрибуты служат входами для остальных процессов.

    Также более подробно освещено планирование набегающей волной - rolling wave planning, как техника определения работ. Утверждается, что можно при progressive elaboration детализировать пакеты работ не сразу, и лишь по достижении этих самых пакетов. Что, в общем-то, стандартный приём того же Agile.

    Интересно расписано про определение зависимостей процесса определения порядка выполнения. Предлагают три типа зависимостей - обязательные (mandatory), зависимости по усмотрению (discretionary) и внешние (external). Также говорится и про то, что при определении последовательности, можно применять шаблоны. Так, например, Most Valuable Specialist в Microsoft Project с сайта microsoftproject.ru (запямятовал имя-фамилию) в своём видео MS Project за 100 минут утверждает, что шаблоны - очень нужная для корпоративной проектной деятельности вещь. Мол, без шаблонов и MS Project не очень ценен. Наверное, он прав, хотя я никогда шаблоны не использовал - всё всегда с нуля.

    Исчез метод PERT. В разработке расписания помимо critical path method указан ещё critical chain method (по-моему, это Голдраттовское). Если честно - о чем это, я не врубился. Кто пояснит - тому большое спасибо! Как я понял, так это тот же критический путь, только с учетом доступности ресурсов и "выдачей" буферов работам не на критическом пути для "утряски" ресурсов. Как-то так...

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

  23. #23
    Член сообщества
    Регистрация
    25.11.2005
    Сообщений
    1,731

    По умолчанию

    Цитата Сообщение от Andruxa
    В разработке расписания помимо critical path method указан ещё critical chain method (по-моему, это Голдраттовское). Если честно - о чем это, я не врубился. Кто пояснит - тому большое спасибо! Как я понял, так это тот же критический путь, только с учетом доступности ресурсов и "выдачей" буферов работам не на критическом пути для "утряски" ресурсов. Как-то так...
    Вы правильно поняли.
    Есть книжка в Сети на русском языке:
    Э. Голдратт. Критическая цепь.
    Это применение ТОС к Управлению проектами.

  24. #24

    По умолчанию

    Спасибо! Нашел тут описание.
    http://result.by/pages/novoe-v-uprav...proektami.aspx

    Там заодно про инфороботы какая-то... еретическая концепция
    И всё-то они умеют, и всё-то они знают, и когда надо - напомнят.
    Не верю :/

  25. #25
    Член сообщества
    Регистрация
    29.11.2005
    Сообщений
    426

    По умолчанию

    Цитата Сообщение от Andruxa
    Спасибо! Нашел тут описание.
    http://result.by/pages/novoe-v-uprav...proektami.aspx

    Там заодно про инфороботы какая-то... еретическая концепция
    И всё-то они умеют, и всё-то они знают, и когда надо - напомнят.
    Не верю :/
    Андрей, там плохое описание, мутное и с ошибками.
    Это один из тех случаев, когда лучше не прочитать вообще. И по "Критической цепи" не нужно изучать CCPM, но там хоть Голдратт пишет, нет мути от непонимания.
    НЕ НАДО ИЗУЧАТЬ ТЕОРИЮ ОГРАНИЧЕНИЙ ПО БИЗНЕС-РОМАНАМ, и по самопальным статьям. Есть куча специальной литературы, тем более, что Вы читаете по английски.

  26. #26
    Член сообщества
    Регистрация
    10.02.2009
    Сообщений
    1,257

    По умолчанию То: Andruxa

    Андрей!
    С интересом читаю Ваш обзор РМВоК!
    Скажите, с какими программами по управлению проектами Вы работаете?

  27. #27
    Кандидат
    Регистрация
    10.04.2009
    Сообщений
    20

    По умолчанию

    Цитата Сообщение от Andruxa
    ...В разработке расписания помимо critical path method указан ещё critical chain method (по-моему, это Голдраттовское). Если честно - о чем это, я не врубился. Кто пояснит - тому большое спасибо! Как я понял, так это тот же критический путь, только с учетом доступности ресурсов и "выдачей" буферов работам не на критическом пути для "утряски" ресурсов. Как-то так...
    Есть такая книга: "Critical Chain Project Management by Lawrence P. Leach", ее выставляли на http://www.forum.mbq.ru/viewtopic.php?p=521#521 , но ссылка устарела, поэтому дублирую файл вложением.
    Вложения Вложения

  28. #28

    По умолчанию

    Да, по бизнес-романам TOC изучать не очень. У меня после Deadline ничего в голове не осталось, кроме счастливой концовки и утопического начала. Но у меня есть Деттмер! И я на него лето своё потрачу.

    Насчет программ. Я работал с Project Expert - не по работе, по собственным проектам, по работе работал с MS Project (в общем и в целом, не так уж с ним всё и плохо при коллективной работе). Сейчас работаю в компании, в которой используют скорее issue tracking, который более удобен для Agile-процессов, нежели Project. Скажем так, управлять бюджетом лучше в Project, поручениями - в issue-tracking-системах.

  29. #29
    Член сообщества
    Регистрация
    25.11.2005
    Сообщений
    1,731

    По умолчанию

    Цитата Сообщение от Георгий Лейбович
    НЕ НАДО ИЗУЧАТЬ ТЕОРИЮ ОГРАНИЧЕНИЙ ПО БИЗНЕС-РОМАНАМ... тем более, что Вы читаете по английски.
    Георгий, позвольте дополнение.
    У бизнес-романов - своя цель и своя ниша. Они дают первоначальное, общее и, что важно, эмоциональное впечатление о предмете. Как аннотация к книге или трейлер к фильму.
    Если человек чтением бизнес-романа не начинает, а заканчивает изучение предмета, это не значит, что бизнес-романы вредны.
    Ну, а первоисточники, тем более на английском - святое дело. (лично Георгию) Даже если некоторые говорят, что It is hard to teach an old dog tricks

  30. #30
    Член сообщества
    Регистрация
    29.11.2005
    Сообщений
    426

    По умолчанию

    Цитата Сообщение от Andruxa
    Да, по бизнес-романам TOC изучать не очень. У меня после Deadline ничего в голове не осталось, кроме счастливой концовки и утопического начала. Но у меня есть Деттмер! И я на него лето своё потрачу.
    Андрей, если Вы собираетесь серьёзно прорабатывать книгу Деттмера, имейте в виду, что через 10 лет, в 2007 году, вышло следующее, переработанное издание. Я его прочитал. Много доработано. В частности, связь с проектированием, построение деревьев. Если хотите, у меня должно быть кое-что в обсуждениях на форуме CCPM, что-то в статьях. Если книга заинтересует - напомните ближе к лету (раньше Вам не понадобится), и я постарюсь найти и выслать. Раньше нет смысла, так как не поймёте, что обсуждается.

    Кроме того, у меня есть в электронном виде большая статья Деттмера о стратегическом менеджменте, а может и две.

    Успехов,
    Георгий

Страница 1 из 5 12345 ПоследняяПоследняя

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •