Управління erp-проектами pmbok або гост

Багато років розробляю на замовлення (і одну на продаж) програми, які підходять під визначення [B] Система планування ресурсів підприємства [/ B]. Тобто ERP. І завжди одне і те ж: [B] сценарій змінюється по ходу п'єси [/ B]. Замовник раптом усвідомлює, що він насправді хоче не зовсім того, що замовив. У мене за багато років склалося відчуття, що інакше бути не може. Карався сумнівами, поки не вичитав у Фредеріка Брукса: [I] «Правда полягає в тому, що клієнти не знають, чого хочуть. Зазвичай вони не знають, на які питання потрібно дати відповідь, і майже ніколи не замислюються над завданням настільки детально, як це потрібно вказати в специфікації. Я піду далі і стверджуватиму, що на практиці клієнти, навіть разом з інженерами-програмістами, не в змозі вказати повно, строго і коректно точні вимоги до сучасного програмного продукту, перш ніж будуть створені і випробувані будь-які версії продукту, специфікації до якого вони складають »[/ I] (Фредерік Брукс« Міфічний людино-місяць, або як створюються програмні системи », глава 16). Тому чекаю від стандарту обліку цього факту. Вкажіть мені такий стандарт - я з радістю на нього перейду. А то що я справді. Але якщо стандарт вважає, що вийде з першого разу - це, на мій погляд, провал планування. Але ж [B] fail to plan = plan to fail [/ B].

Юрій Максименко пише: Тому чекаю від стандарту обліку цього факту. Вкажіть мені такий стандарт - я з радістю на нього перейду. А то що я справді. Юрій, познайомтеся з методикою XP: Extreme Programming. Там давно вже все є - докладніше тут не буду, а то все дізнаються :))) А у Дуга ДеКарло є відома книга Extreme Project Management - її я сам не вивчав, але підозрюю, що основні ідеї близькі до XP. Насправді сформульовані Вам проблеми мають хоча і витончене, але в загальному цілком собі реалізоване рішення. Захочете поспілкуватися - пишіть в личку.

[B] Борис Звєрєв, [/ b] Борис, я і хотів в статті показати, що ГОСТи і стандарти PMI доповнюють один друга.Ну а для інформаційних систем в цьому випадку є ще методології вендорів, і менеджер проектів повинен вміти користуватися всіма цими інструментами . Мабуть, не довів в статті думка до кінця, але зате це вдалося Вам.Что стосується Цесельська Ігор пише: НТК СОВНЕТ, та й інші відомі документи то я не побачив величезну різницю між PMI і IPMA / СОВНЕТ, хіба що різна процедура здачі сертифікаційного іспиту .Але якщо судити з методологій SAP і Oracle, то в ІТ перемагає PMI. Може я помиляюся, але враження у мене таке. Цесельська Ігор пише: схоже на огляд журналіста-універсала Ніколи не вмів писати твори, популярні статті тощо тому це для мене комплімент. Дякуємо.

Добрий день, шановні пані та панове! Тема для мене дуже цікава, тому вирішив приєднатися. Я проектний менеджер в області інвестиційно-будівельних проектів і, звичайно ж, постійно використовував PMBOK в своїй роботі. Однак в силу певних обставин зараз я 1-й заступник директора проектного інституту, займаюся впровадженням методології проектного менеджменту в цьому інституті, і тому мене дуже цікавить досвід використання PMBOK саме в роботі організації, основним продуктом якої є проектна документація.Коллегі, що мають досвід в цьому відгукніться !!

Юрій Максименко пише: Тому чекаю від стандарту обліку цього факту. Вкажіть мені такий стандарт - я з радістю на нього перейду. А то що я справді. Так є це в PMBOK, тільки не виділено в розділ, є у всіх розділах. Корекція цілей проекту в міру його виконання - неминуча як смерть. З мого досвіду - важливо, щоб процедура управління змінами обов'язково була прописана в Регламенті управління проектом (або Статуті проекту, як він у вас називається) і підписана замовником. І не лінуватися писати їм офіційні повідомлення та залучати замовника в прийняття рішень щодо змін якомога раніше. Зумійте це позначити заздалегідь в руських і узгодити з замовником приблизний порядок реагування. Під підпис або протокол. Це не тільки гарна сковорідка під улюблений орган ПМОВ (__ * __), це реально допомагає і вам і замовнику. Чи не лаятися при настанні події ризику 'хто винен', а відразу переходити до реагування. І гроші додаткові даються набагато легше і терміни переносяться для врахування змін або відмовляються від неважливих вимог, щоб викроїти ресурси.

Андрій Куніцин пише: Юрій, познайомтеся з методикою XP: Extreme Programming. Там давно вже все є - докладніше тут не буду, а то все дізнаюся Це та методика, клторую Фоулер створив? Спробую перечитати ще раз. Не пам'ятаю, щоб там обмовлялося побудова відносин із замовником. Але можливий, просто забув. Андрій Куніцин пише: Насправді сформульовані Вам проблеми мають хоча і витончене, але в загальному цілком собі реалізоване рішення. Мають. Навіть я вмію їх вирішувати. Але не можу обгрунтувати свій підхід стандартом. Андрій Куніцин пише: Чи захочете поспілкуватися - пишіть в личку. Мене насправді мучать інші питання. Не знаю, чи є у мене право вантажити Вас ними. Наберуся нахабства - задам парочку питань.

Петро Александров пише: Так є це в PMBOK, тільки не виділено в розділ, є у всіх розділах. А, так ось чому я не помітив цього при першому читанні. Спробую вчитатися. Петро Александров пише: З мого досвіду - важливо, щоб процедура управління змінами обов'язково була прописана в Регламенті управління проектом (або Статуті проекту, як він у вас називається) і підписана замовником. Про те і мова, що цей регламент мені доводиться самому складати. З кожним разом виходить все розумнішими і розумнішими:) Але хотілося щось продумане взяти за основу.