Системы управления проектами (системы календарного планирования)

By Валерий Вязовой on Вторник, Август 01, 2000 - 12:00:

Уважаемые господа!
Хотелось бы услышать мнения по поводу проблем, возникающих при внедрении таких систем.

By Илья Филипсон on Четверг, Сентябрь 28, 2000 - 11:22:

Да и хотелось бы услышать, кто какими продуктами пользуется при планировании проектных работ. Мы-то делаем всё в Excele. Чертовски неудобно.

By Валерий Вязовой on Пятница, Сентябрь 29, 2000 - 14:45:

Excel - совсем не для этих целей:-) софта для управления проектами много. http://project.come.ru - посмотрите, там есть описания некоторых систем.

By Валерий Вязовой on Вторник, Октябрь 03, 2000 - 14:42:

хорошая статья по поводу софта http://www.itc.kiev.ua/article.phtml?ID=3555&pid=0

By snake on Среда, Октябрь 04, 2000 - 12:15:

Я приношу свои извинения за опоздание... Но о каком управлении проектами идет речь.. управление охватывает несколько разных аспектов.. Управление персоналом, оборудованием, технологией, финансовыми потоками...? Или все это вместе в комплексе. Насыщенность объекта управления проектами? Может быть 1..2 проекта крупных, или десятки "однодневок"??? Условия реализации проектов: с привлечением инвестиций или без.... Но насколько я понимаю полоценное управление - комплексное, но если Вы говорите о каком либо департаменте обеспечивающем одну из функциональных задач это уже совсем другое.. В целом по сути систем обеспечивающих комплексное управление, как понимается выше, нет. Есть системы, обеспечивающие тот или иной аспект управления проектами. Проблема использования эл.таблиц, как мне кажется заключается в том, что если Вы делаете программку для себя это удобно в той мере в какой нам это нужно.. Но ее нельзя использовать кому то другому...И каждый раз в новом проекте (пакете проектов) надо делать новую разработку

By Илья Филипсон on Среда, Октябрь 04, 2000 - 19:40:

Спасибо за project.come.ru. Систематизировано и познавательно :) Перед нами встала проблема выбора софта для управления проектами внедрения тиражного КИСообразного софта. Сначала было две альтернативы: MS Project или Open Plan. Но буквально на днях обнаружил российскую! систему управления проектами Спайдер. Посмотрел демо-версию (сразу понравился очень хороший хелп на русском (у нас англ. не все знают). Так что теперь альтернативы три, и с склоняюсь в пользу Спайдера. Но, естесвенно, неплохо сначала выслушать мнения более опытных людей об этих пакетах. Поэтому прошу высказываться...

By Галактионов Антон on Среда, Октябрь 04, 2000 - 22:31:

Илье : Да, кстати г-н Либерзон сказал, что в хелпе Спайдера есть пример, оказалось действительно это так. Рекомендую и Вам тоже туда заглянуть.

By Илья Филипсон on Четверг, Октябрь 05, 2000 - 18:00:

Антону. Заглядываю потихоньку. Спайдер нравится всё больше и больше.

By АБ on Пятница, Октябрь 06, 2000 - 09:56:

А все таки, обратите внимание на MS Project 2000. Вряд ли стоит выбирать программу для такой работы исходя только из наличия русского хелпа. По MSP2000 несколько учебных центров уже подготовили обучение, наверное скоро выйдут книжки и т.п... Я отсмотрел практически все, что можно было найти, в том числе и Спайдер (очень хорошая система, но закрытая и по-моему плохо приспособлена для групповой работы). И если вы думаете о расширении возможностей системы, а также о ее интеграции с другими используемыми вами инструментами, то надо брать систему на открытой платформе. Да и цену тоже надо иметь в виду. PS. Люблю Microsoft не больше всех остальных, но факты - упрямая вещь ;-) С уважением АБ

By Галактионов Антон on Пятница, Октябрь 06, 2000 - 21:54:

АБ : А может самому на Аксессе сбацать ? :)

By Владимир Либерзон on Понедельник, Октябрь 09, 2000 - 01:49:

Господа, приятно увидеть дискуссию по управлению проектами и конечно упоминания о Спайдере. Два замечания: 1) систему надо выбирать прежде всего исходя из ваших функциональных требований. Что толку в интегрированном софте или хорошем Хэлпе, если пакет не может промоделировать ваши ситуации и соответственно быть использован не для рисования картинок, а для моделирования принимаемых решений. Немаловажно и качество расписаний - если у вас ограниченные ресурсы, то оптимизация расписания в Спайдере это очень приличная экономия. 2) групповая работа в Спайдере организована неординарно, поэтому может оказаться сходу непонятной (это я для АБ) - дело в том, что обычная сетевая организация для управления проектами подходит плохо (и мы от нее сознательно отошли), не согласуется с системой распределения ответственности. Я, как менеджер проекта, хотел бы санкционировать внесение информации в мой проект, а не оказываться перед моделью, состоящей из тысяч работ, куда кто-то что-то навводил, а теперь мне разбираться почему какой-то бред получился. В Спайдере создается структура ответственности и люди могут автономно работать со своими фазами. В общий проект информация поступает по нажатию одной кнопки с санкции менеджера, если изменения санкционируются. А насчет открытости, информация из Спайдера может отправлена в Excel, Word, Access, Oracle и т.д. И соответственно импортирована. Здесь не место обсуждать подробнее, если есть интерес и вопросы, то дискуссию можно продолжить на сайте www.spiderproject.ru.

By Валерий Вязовой on Понедельник, Октябрь 09, 2000 - 10:36:

Антон! могу вам немного рассказать о "самоделках"..:-) весьма интересные истории

By Валерий Вязовой on Среда, Октябрь 11, 2000 - 16:01:

жпрошу прощения за офтопик. похоже я остался без хостингаL сайт на appost.lanit.ru/vyazovoy не отвечает, в том числе и по фтп. жаль конференцию. база была там. ОБЪЯВЛЕНИЕ! ищу хостинг для некоммерческого проекта. много не надо, мегов на 15-20.

By Галактионов Антон on Среда, Ноябрь 22, 2000 - 21:07:

Валерию :
Извиняюсь за паузу, был бы рад услышать интересные истории ...

By Валерий Вязовой on Четверг, Ноябрь 30, 2000 - 18:10:

хочу сообщить, что сайт мой переехал на www.project.km.ru
так вот, по поводу самоделок. на Аксессе, кстати.
был такой небольшой опыт в моей карьере.
писали вдвоем. я рисовал схемотехнику, коллега код.
от аксесса (97) пришлось отказаться через 1,5 месяца обкатки первой версии:-) - по причине жутких тормозов. хотя может мы и писали плохо.
сменили средство, но лучше не стало. постоянно изменяемые требования, смены руководства.
короче, потратили месяца 4-5 впустую.
жаль.
не думаю, что только у меня такой опыт был.
ведь есть разработчики, которые к своим сметным системам пытаются прикрутить системы календарного планирования, свои же. Вы много таких УСПЕШНЫХ систем знаете?

By Владимир Тикунов on Среда, Декабрь 06, 2000 - 17:18:

Валерию Вязову
> хотя может мы и писали плохо.
имею богатый опыт реализации, внедрения, эксплуатации систем на аксессе (2.0-2000).

Думаю причина вами указана верно. Тесты показывают SQL Server и Access имеют одинаковый "движок".

By Афонин Виктор on Четверг, Март 08, 2001 - 13:35:

MSProject 2000 - я бы рекомендовал ориентироваться на использования этого инструмента для управления проектами.

By Владимир on Понедельник, Март 12, 2001 - 01:53:

Да, Виктор, не ожидал от вас.
Придется пересмотреть свое отношение и к другим вашим сообщениям в других дискуссиях. Простительно в чем-то быть дилетантом, особенно не в своей профессиональной области, непростительно при этом поучать других. Ведь читатели форума, для которых управление проектами в новинку, могут всерьез отнестись к вашей "рекомендации".
Если вы это серьезно, то поясните, пожалуйста, в чем вы видите преимущества пакета начального уровня MSProject 2000 перед другими пакетами PM и, в частности, Scitor Project Scheduler 8, Project Management Workbench, Primavera Teamplay, P3E, Open Plan, Artemis Project View, Spider Project?
У меня нет сомнений, что для каких-то проектов MSProject 2000 может оказаться оптимальным решением (простые и маленькие проекты с избытком ресурсов), но для всех проектов!?

By Сергей Рубцов on Понедельник, Март 12, 2001 - 09:53:

Владимиру.
Уже говорилось, что MSProject обладает открытой архитектурой (если бы это было справедливо только для офисных приложений, то уже этого было бы не мало). Год назад меня пытались "перейти" на Primavera. Возможно мой проект был не таким уж крупным. Поэтому преимуществ PV я не увидел... А тех преимуществ, которые дают MSO-продукты, я лишился. Пользователя, который обладает навыками разработки приложений под MSO на "великом" VB Вы не переубедите в преимуществах других планировщиков...

By Владимир on Понедельник, Март 12, 2001 - 13:19:

Сергей,
если вам от Primavera нужно то, что может сделать и MS Project, то вы сделали правильный выбор. Если MS Project решает ваши функциональные задачи, то и прекрасно.
Я говорю о том, что набор возможностей MS Project очень ограничен, не всякий проект он способен адекватно отразить (а без этого моделирование принимаемых решений теряет смысл), не всякую отчетность способен дать и еще многое другое. Если он вас устраивает, то у вас или проекты очень простые (я уже упоминал в каком смысле) или вы просто не знаете, что подобные программы способны вам дать.
Кстати, имейте в виду, что MS Project не умеет оптимизировать загрузку ресурсов и часто выдает довольно неоптимальные расписания, если ваши ресурсы ограничены (leveling), так что будьте аккуратны.
А советовать всем и для любых проектов MS Project все равно, что посоветовать всем использовать MS Excel в качестве ERP системы. И считать умеет, и с MSO хорошо интегрирован.

By Сергей Рубцов on Понедельник, Март 12, 2001 - 16:05:

Владимиру.

>А советовать всем и для любых проектов MS Project все равно, что посоветовать всем использовать MS Excel в качестве ERP системы. И считать умеет, и с MSO хорошо интегрирован.

:-) Экспрессивно, но не совсем справедливо.

Необходимо отталкиваться от посылки, что не так давно крупные проекты (этак на $150 млрд. долларов) влегкую исполнялись без подобных инструментов. Поэтому людей, прошедших такой путь, практически невозможно убедить, что хорошее (MSP) хуже отличного (PV)... Поэтому Ваш аргумент о наличии каких-то сложных проектов не производит впечатления...

Ссылка на стандартные отчеты - тоже. Я, например, редко использую стандартные отчеты MSP. Предпочитаю разрабатывать собственные модули на VB. Уверен, что и в PV пришлось бы делать то же самое ...

By Сергей Рубцов on Понедельник, Март 12, 2001 - 16:07:

Владимиру.
А претензии к расчетной части MSP совсем несправедливы. Алгоритм известен. Программа работает по алгоритму. Какие здесь могут быть неожиданности? Или у Вас есть претензии к алгоритму?

By Владимир on Понедельник, Март 12, 2001 - 16:51:

Сергей,

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

А где же вы увидели ссылку на стандартные отчеты?
Попробуйте в MS Project получить отчет о том, что и кем было сделано за заданный период времени, какие материалы и в каком количестве были истрачены и поставлены (заодно и каковы остатки ваших запасов), какие затраты совершены и какие деньги поступили (и что вы кому должны) - ну совершенно естественный отчет за период по необходимой для управления проектом учетной информации. А будете вы использовать VB или что другое - дело ваше. Это пример, если вы управляете проектом, то у вас и другие потребности появятся.

Насчет PV я ни слова не говорил. С чего вы взяли, что я считаю PV образцом? Я повторяю, что считаю, что пакет надо выбирать исходя из потребностей ваших проектов, функциональности, возможности промоделировать ваши проекты и получить необходимые отчеты. И здесь нет одного ответа для всех. У вас простые проекты и я вас поздравляю - вам хватает MS Project. У кого-то проекты посложнее и функциональности MS Project ему не хватит. Вот и все.

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

Вам для размышления пример, который я приводил на другом форуме:
Операция 1 —длительность 2 дня, исполнитель —А,
Операция 2 —длительность 15 дней, исполнитель —В,
Операция 3 —длительность 15 дней, исполнитель —А,
Операция 4 —длительность 15 дней, исполнитель —В,
Операция 1 предшествует операции 2, 3 предшествует 4, связи —финиш-старт.
В MS Project вы получите проект, который длится 45 дней вместо тридцати двух по разумному расписанию.
Теперь измените длительность операции 4 с 15 дней на 14.
Расписание изменилось и проект теперь заверщается за 31 день —расписание стало оптимальным. При увеличении длительности обратно (на 1 день) срок завершения проекта отложится на 14!

Для вас такое поведение алгоритма не является сюрпризом? Тогда может быть поясните алгоритм?

Кстати, нестабильность расписания для управления проектом еще опаснее неоптимального расписания. После заключения контратков и утверждения планов коренное изменение расписания - это катастрофа.

Ну и что вы будет делать, возьмете VB и перепишете MS Project?

Успехов вам!

By Сергей Рубцов on Понедельник, Март 12, 2001 - 18:31:

Владимиру.

Спасибо за пример. Проверю.

>Попробуйте в MS Project получить отчет о том, что и кем было сделано за заданный период времени, какие материалы и в каком количестве были истрачены и поставлены (заодно и каковы остатки ваших запасов), какие затраты совершены и какие деньги поступили (и что вы кому должны)

Хм... Перечисленные Вами задачи похоже не попадают под класс задач управления проектами.
Это подклас задач систем MRP ...
Для ясности хотелось бы знать в Вашей интерпретации отличия между управлением предприятием и проектом. Похоже для Вас это - близкие понятия. Я против этого не имею ничего против..., но ясность в позициях важна...

By Владимир on Понедельник, Март 12, 2001 - 18:59:

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

By Сергей Рубцов on Вторник, Март 13, 2001 - 09:43:

Владимиру.
Я Вас понял.
Однако, неужели Вы не чувствуете, что сами размываете предметную область управления проектами, если различие между управлением предприятием и управлением проектом видите только в отсутствии у последнего задачи бух. учета?
Вы представляете, какую долю в ERP системах занимает задача бух.учета? На мой взгляд это 0,1%.
Т.е. Вы нечаянно поставили знак приближенного равенства между интегрированными системами управления предприятиями и системами управления проектами. Все-таки отличия должны быть большими и именно на ту составляющую, о которой Вы говорили выше. Ну..., естественно, это лишь мое частное мнение.

By Владимир on Вторник, Март 13, 2001 - 10:03:

Сергей,
есть такое понятие EPM (Enterprise Project Management) и соответствующие системы. Вы будете настаивать на внедрении именно ERP системы на предприятии, деятельность которого посвящена управлению проектами, несмотря на то, что ERP системы на это не ориентированы? Кстати, я ничего не размываю - стандарты управления проектами включают управление всем тем, о чем я упоминал. По-моему исключать из предметной области управления проектами важные для этого элементы только потому, что Вы их хотите иначе классифицировать, неправомерно. А знак приближенного равенства я поставил совсем не нечаянно - управление проектами это управление всем, что необходимо для достижения поставленных в проектах целей. Иначе это вообще непонятно что.

By Сергей Рубцов on Вторник, Март 13, 2001 - 10:56:

Владимиру.
Стандарты Ассоциации я читал. Вижу попытку натянуть на себя одеяло. Бог им судья. Мы не можем ни поддержать их, ни помешать им :-)

>несмотря на то, что ERP системы на это не ориентированы?
Это очень спорное утверждение особенно после того, как Вы подтвердили сходство между задачами управления проектами и управлением предприятием.

Я совсем не против Вашей постановки вопроса. В рамках такой задачи я естественно не буду продвигать MSProject. Этот инструмент "заточен" на несоизмеримо более узкую задачу. А это - не минус и не плюс.
А Ваш пример я сейчас проверяю :-)

By Сергей Рубцов on Вторник, Март 13, 2001 - 11:07:

Владимиру.
Пример проверил. Ошибки не обнаружил. Выслал Вам пример по почте

By Владимир on Вторник, Март 13, 2001 - 12:31:

Насчет незаточенности на проекты систем ERP. Можете ли вы назвать систему ERP, которая составит расписание исполнения проекта с учетом ограничений по наличию ресурсов, графиков поставок и финансирования? Я такой не знаю. Я уж не буду говорить о мультипроектном управлении.

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

Я не упомянул в своем примере и считал самим собой разумеющимся, что каждого ресурса (a и b) по одной единице. Я сделал необходимые исправления в вашем примере и выслал обратно.

А Project действительно ориентирован на совсем узкие задачи и тем, кому этого хватает, я бы его и рекомендовал. Выбор системы определяется потребностями пользователей.

By Сергей Рубцов on Вторник, Март 13, 2001 - 13:10:

Владимиру.
>Можете ли вы назвать систему ERP ...
Нет, конечно, не могу назвать... Но, возможно, у меня недостаточно информации. С другой стороны, к известным мне системам меня тоже есть большие претензии :-), но нет претензий к идеологии ERP.
Я имею в виду претензию на открытую архитектуру.
Очевидно же, что производителям MRP, ERP и PM систем все труднее делить поляну. А что будет года через два-три?

By Евгений on Вторник, Март 13, 2001 - 23:22:

Владимиру и Сергею:
Извините, что, возможно, помешал Вам в Вашей переписке, но ...
1. В ERP-системе BAAN IVC имеется модуль управления проектами (правда, на мой взгдяд, не самый сильный).
2. В приведенном Владимиром примере относительно составления расписания работ не конкретизирован критерий оптимальности, поэтому судить о предлагаемом решении трудно. По-видимому, имелся ввиду критерий минимизации времени проходжения работ через рабочие места (минимизация длительности критического пути). Но если критерий сменить, например, выбрать критерий расчета расписания с использованием минимального числа взаимозаменяемых рабочих мест, или с минимальным числом перемещений работ на взаимозаменяемых рабочих местах (минимальное число переналадок), то и результат будет совсем иной при оптимальном расписании!
3. Приведенный пример: "... при увеличении длительности обратно (на 1 день) срок завершения проекта отложится на 14!" удивит, разве только, человека, никогда не занимавшегося составлением расписаний. Профессионалам хорошо известно, что расписание - структурно неустойчывый объект, т.е. малые изменения параметров исходной задачи могут привести к резким изменениям результата. И Вы это сами хорошо знаете.
Еще раз извините, господа, что прервал Вас...

By Владимир on Среда, Март 14, 2001 - 00:28:

Евгений,

модули управления проектами имеются не только в BAAN, но и в SAP, и в Oracle. Без этого теперь нельзя. Но сказать, что эти модули слабые мало. Они просто не предназначены для решения стандартных задач управления проектами, а скорее для интеграции проектов в систему ERP. Поэтому на Западе их применяют в связке с профессиональными пакетами управления проектами, такими как Artemis, Primavera, Open Plan.

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

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

Я уж не говорю о том, что понятно изменение расписания на оптимальное, но не наоборот.

Спасибо, что присоединились к дискуссии.

By Евгений on Среда, Март 14, 2001 - 09:29:

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

By Сергей Рубцов on Среда, Март 14, 2001 - 09:31:

Владимиру.
Помучался я с Вашим примером, но один из вариантов ответа нашел. Но сначала выражу согласие с Евгением в той части, что настройка в MSProject довольно гибкая, и, я проработав с этой средой несколько лет , не всеми ими пользуюсь. Поэтому очень трудно бывает объяснить результат.
В рассматриваемом нами случае (в стандартной настройке) установлен 8-часовой рабочий день. Отсюда и получается 42 часа вместо 32. Если Вы исправите настройку на 24-часовой день, то получите примерно то, что следовало ожидать.

By Владимир on Среда, Март 14, 2001 - 11:20:

Евгений, вы подменяете одну задачу другой.

Мультипроект и рассчитывается как мультипроект.

А для того, чтобы сократить пролеживание деталей применяются совсем другие средства. Есть такое понятие - операция типа ALAP (как можно позже). Задав тип операции вы регулируете, должна ли она выплняться как можно быстрее (ASAP) или ее исполнение должно быть отодвинуто как можно дальше без нарушения логических взаимосвязей и директивных дат. Так вот расписание всегда составляется с учетом типов операций проекта. Одно другому не противоречит никак. Если вы не будете успевать выпустить что-то в контрактные сроки, то для вас будет слабым утешением, что у вас пролеживания нет. А использовать резервы при оптимизации расписания очень просто,и задав директивные даты и типы операций (ASAP, ALAP). ALAP расписание обеспечит "работу с колес" (или "точно в срок", если вам так больше нравится), но в таком расписании нужно четко учесть риски и предусмотреть соответствующие резервы.

Резюме: если пакет умеет создавать сжатое расписание, то и "точно в срок" он сделает план лучше, имея большие резервы времени для манипулирования ресурсами. Если пакет не умеет оптимизировать расписания, то использование ресурсов нерационально, а значит простои непродуктивны. Эти простои не вызваны необходимостью производства точно в срок, а просто убогостью планирования. Это означает необходимость использовать лишние (избыточные) ресурсы, соответственно дополнительные затраты.

Сергей, я что-то не понял, о какой настройке в MS Project вы говорите, ссылаясь на Евгения. Поясните.

Что такое 42 часа вместо 32 я тоже не понимаю.

В том примере, который мы обсуждаем, MS Project для проекта из четырех операций и двух исполнителей составляет расписание длительностью 45 дней, хотя проект очевидно может быть исполнен за 32. При этом сокращение длительности одной из операций на 1 день приводит к тому, что расписание кардинально меняется и длительность становится оптимальной - 31 день. Обратное действие приводит к восстановлению первоначального расписания. У всех операций и ресурсов - стандартный календарь - 8 часовой рабочий день.

Выводы:
1) расписания, составляемые пакетом MS Project могут быть далеки от оптимальных даже для самых простых проектов,
2) расписания, составляемые пакетом MS Project нестабильны, что может привести к большим проблемам при реализации проекта и пакет не содержит средств борьбы с этим явлением.

Дополнение - я ничего не имею именно против MS Project, все это относится в той или иной степени и к другим западным пакетам.

Ваша фраза, что у MS Project так много настроек, что трудно объяснить результат, шокирует. Вы миритесь с тем, что пакет выдает что-то необъяснимое?

By Сергей Рубцов on Среда, Март 14, 2001 - 11:39:

Владимиру.
Прошу прощения, описался... Повторяю...
Если Вы выберете не стандартный календарь, где задан 8 часовой раб. день, а зададите календарь, в котором 24 часовой раб. день, то получите результат "похожий" на 32 дня... :-) Все скачки, которые Вы наблюдете, именно с этим связаны...

>Вы миритесь с тем, что пакет выдает что-то необъяснимое?

Хм... Мирюсь, конечно, как и с несовершенством человеческой логики :-)
А то, что я чего-то не могу объяснить, есть свидетельство лишь недостатка свободного времени для подробного изучения инструмента, а не недостатка MSProject. Да и работать за MS не хочется. Мне же они не платят за выступление в этом форуме :-).
С другой стороны, я допускаю такую возможность, что MSP есть ошибки... Но в этом необходимо сначала убедиться.

By Владимир on Среда, Март 14, 2001 - 13:18:

Сергей,

при переходе на 24-часовой день ничего не меняется, вы что-то неправильно делали. Высылаю вам тот же пример, но с 24-часовым календарем.
К тому же рабочий день обычно состоит из 8 часов и если у пакета это проблема, то я с таким пакетом вам работать не посоветую.

Что касается необъяснимостей в Project, то дело не в оплате. Если вы используете пакет, чтобы управлять своими проектами, то вам важно понимать, что происходит, потому что управляете вы своими проектами не от избытка свободного времени. К своей работе надо относиться профессионально и это не имеет отношения к работе за Microsoft.

Если в пакете есть ошибки - это простительно, все бывает, ошибки быстро исправляются. Если в пакете заложены подходы, которые в принципе приводят к ошибочным решениям - это намного хуже. Я не говорю об ошибках MS Project (они есть и не в них дело), я говорю о подходах и алгоритмах (помните свой вопрос - у вас есть претензии к алгоритму?).

By Сергей Рубцов on Среда, Март 14, 2001 - 14:52:

Владимиру.
Сразу прошу прощения, что с самого начала не "въехал" в предложенную Вами задачу. Искал не то, что нужно.
Итак, в Вашей задаче "завуалированно" задана последовательность исполнения работ. Т.е., я как кролик заполнял строчки именно в той последовательности, в которой Вы предложили :-).
Вы так в реальной жизни работаете? Я нет...
Почему MSP должен менять эту последовательность работ Из каких соображений? Может быть эта последовательность проектировщику "дорога" или обусловлена надсистемными причинами. Этих причин может быть туча, которые система не может знать... В этом смысле работу MSP я вижу логичной.

Фактически Вы предполагаете наличие группы работ, начало исполнения которых для проектировщика неважно (в Вашем примере это - работы 1 и 3). Стоит ли "городить" ради такого частного случая механизм оптимизации, который еще неизвестно как поведет себя совместно с другими оптимизирующими алгоритмами?

Во всяком случае - это не ошибка алгоритма MSP.

С другой стороны. А если бы такой алгоритм был в MSP? То как проектировщику избежать нежелательной оптимизации такого рода относительно группы работ? Правильно,... поставить соответствующие "флажки" запрета. Как видите, преимущество оборачивается недостатком (или, по Вашему, ошибкой алгоритма).

Впрочем, последняя возможность реализована в MSP в форме, например, приоритетов исполнения работ, фильтров и т.д. Пометьте, что работа 3 приоритетнее работы 1, и все будет ОК.

By Владимир on Среда, Март 14, 2001 - 16:17:

Сергей,

никакой последовательности работ в моем проекте не задано. Есть четыре (!) работы и я прошу пакет составить расписание исполнения этих работ с учетом ограниченности имеющихся у меня ресурсов. ВСЕ!

От последовательности ввода расписание зависеть не должно - иначе это полный бред, который, кстати, MS Project в предыдущих версиях поддерживал - стоило поменять последовательность операций в таблице (сортировка) и менялось расписание. Слава богу, в последних версиях я этого не замечал.

Как вы работаете в реальной жизни я не знаю и не понимаю, что вы имеете в виду, когда говорите, что так не работаете.

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

Стоит ли городить механизм оптимизации для четырех работ? А с чего вы взяли, что для тысяч работ пакет оптимизирует, если не может оптимизировать для четырех. Я вас уверяю, что и для больших проектов MS Project оптимальных расписаний не составляет. Ваша фраза о том, что механизм оптимизации неизвестно как себя поведет совместно с другими оптимизирующими алгоритмами для меня непонятна вовсе - какие другие оптимизирующие алгоритмы вы имеете в виду?

Какое отношение к расчету расписания проекта имеют фильтры я тоже не понимаю. Как видите, у меня слишком много вопросов по этому вашему постингу - может быть поясните?

Зато понимаю, что вы предлагаете пользователю самому расставить приоритеты работ, чтобы получить оптимальное расписание. Хотел бы я посмотреть на пользователя, который будет расставлять приоритеты в проекте, состоящем из тысяч работ. При этом он должен заметить, что предложенное расписание неоптимально и найти как его можно улучшить. Как вы себе это представляете? Вам приходилось иметь дело с большими проектами? И зачем пакет, если расписание все равно составляется вручную - для красивых отчетов?

By Сергей Рубцов on Среда, Март 14, 2001 - 18:52:

Владимиру.
Давайте спокойно со всем разберемся. А то получается так, что Вы не понимаете меня в самом начале, а потом начинате "разносить" догадки, которые обо мне строите. Я никуда с форума не убегу, пока не "закроем" вопрос с Вашим примером. У Вас будет время меня отлупить :-).

Во-первых, я акцентировал внимание только на один критерий оптимальности проекта, на котором акцентирован Ваш пример. Поиск правильной последовательности исполнения несвязанных работ, начало исполнения которых неизвестно или непринципиально (работы 1 и 3).
Итак, я действительно утверждаю, что от последовательности записи строк в MSP меняется результат. Не знаю, как в предыдущих версиях, но в последней это имеет место. И на Вашем примере это видно. В этом смысле я говорил о заданной Вами последовательности ввода работ.
Попробуйте измененить последовательность ввода описания работ до ввода связей (пока нет связей для MSP это эквивалентно расстановке приоритетов работ по умолчанию)... и увидите сами. Не вижу тут своего "бреда".
Теперь предлагаю Вам вернуться к моему постингу. Может теперь все прояснится?

Это было во-первых. Теперь, во-вторых. Вы пишите
>Зато понимаю, что вы предлагаете пользователю самому расставить приоритеты работ ... Хотел бы я посмотреть на пользователя, который будет расставлять приоритеты в проекте, состоящем из тысяч работ.

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

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

By Евгений on Среда, Март 14, 2001 - 20:28:

"Не делайте мне больно, господа!"
О каком оптимальном расписании может идти речь для тысячи работ? Ведь задача составления расписания относится к классу NP-трудных. Господа, Вы же профессионалы...
Владимир, в теории расписаний, Вы, я полагаю, это хорошо знаете, рассматривается проблема составления расписаний как с статичиским, так и с динамическим множеством исходных данных. Например, известна месячная производственная программа, но в первом случае (статическое множество) все заготовки доступны для обработки и любую из них можно выбрать при составлении расписания; во-втором (динамическое множество) заготовки подаются по мере их готовности в последовательности, неизвестной составителю расписания. В последнем случае составитель вынужден подстраиваться под ситуацию, хотя ему и была известна вся месячная программа. Сергей Рубцов в своем постинге, по-существу, указал на динамику исходных данных (поменять местами работы = изменить последовательность подачи заготовок). Ясно, что вид расписания в обоих случаях будет различен!

By Евгений on Среда, Март 14, 2001 - 20:52:

Господа,
ведь, расписание расписанию - рознь!
Бывают расписания для поездов и самолетов, бывают расписания выполнения проектов (здесь я полностью соглашаюсь с Владимиром: наиболее объективным критерием следует признать минимизацию длительности критического пути), но бывают и производственные расписания, где минимизация времени выполнения всех работ не является, как правило, главным критерием. В последнем случае важно своевременное ("точно в срок") и качественное (с минимальным числом переналадок) выполнение задания. Вот так, я думаю... Sorry.

By Владимир on Среда, Март 14, 2001 - 20:56:

Сергей,

я вовсе не хочу вас отлупить, а хочу спокойно понять ваши вопросы и утверждения, а то с какого-то момента я перестал понимать некоторые ваши рассуждения. Вернемся к самому началу - чего мы вправе ждать от пакета управления проектами в части составления расписания исполнения операций.
Если у вас другое понимание - поправьте.

Итак самый простейший вариант, который под силу всем пакетам, даже MS Project, - пользователь вводит перечень работ проекта и их взаимосвязи, ресурсы проекта, назначает ресурсы на исполнение операций и задает плановые длительности их исполнения, задает календари и директивные даты (если они есть). Этой информации достаточно для того, чтобы пакет составил расписание исполнения работ проекта.

Я утверждаю, что пользователь вправе ожидать, что пакет постарается составить не абы какое расписание, а такое, в котором нет излишних простоев ресурсов и длительность исполнения работ проекта будет минимальной с учетом имеющихся ограничений. У вас другое мнение? Интересно спросить других участников форума - чего от пакетов УП в этой ситуации ожидают они.

Почему вы так акцентируетесь на особенностях именно этого примера? Если вас смущает, что операции не связаны, - свяжите их, добавив начальную операцию 5 (milestone), которая предшествует первой и третьей. Это ничего не изменит.

То, что от последовательности строк меняется результат, я в этой версии Project не проверял - если так, то проблемы еще серьезнее, чем я думал. Ну не должен пользователь зависеть от того, в каком порядке операции введены - так и сортировать проект побоишься. И мое замечание про "бред" относится совсем не к вам, а к пакету - вы зря приняли на свой счет. Кстати, если порядок ввода задает приоритеты, то почему расписание все-таки изменяется при изменении длительности четвертой операции?

С добавлением начальной операции ваши дальнейшие рекомендации расставлять приоритеты операциям, у которых нет предшествующих, теряют смысл. Но все равно представьте проект, в котором всего лишь 20 начальных операций. Сколько сочетаний вы предлагаете перепробовать? Кстати, Project далеко не всегда выбирает не лучшим образом именно начальные операции. Если вам это интересно, я смогу вас снабдить десятками примеров нелучших расписаний, составленных MS Project. Этот пример интересен именно тем, что он мал.

А вот что я предлагаю в последнем предложении вашего постинга я опять не понял - поясните.

Кстати, проекты, которыми мы управляем, обычно состоят из нескольких тысяч операций (обычно от 2 до 15 тысяч) и сотен ресурсов. Какой размерности проекты, для которых вы пользуетесь MS Project?

Всего наилучшего.

By Владимир on Среда, Март 14, 2001 - 21:22:

Евгений,

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

На то и персональный компьютер, чтобы при изменении исходных данных в секунды (минуты) пересчитать расписание. Кроме того, расписание при управлении проектом не является чем-то статичным. Регулярно вводится информация об исполнении и изменениях и пересчитывается график оставшихся работ.

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

По поводу "точно в срок" я вам уже отвечал выше - задайте операциям тип ALAP и получите расписание "точно в срок".

Всего хорошего.

By Сергей Рубцов on Среда, Март 14, 2001 - 21:43:

Владимиру.
Уважаемый В.И.! По-моему, Вы упрямитесь :-). В целом я совершенно согласен с Вашими требованиями к продукту как к благому пожеланию.
Очевидно, весь наш диспут сводится к одному вопросу.
Что оптимальнее - 32 дня или 45 дней. Для Вас это почему-то априорно очевидно. Идеология MSP (да и PV) подразумевает перечисление основных этапов проектов
"сверху вниз" в порядке их исполнения, т.е. по умолчанию задается приоритет. Что здесь плохого. Да и не скрывал этого никто.
В документации об этом четко говорится. Да и без нее вроде понятно.
Поэтому 45 дней - правильный и логичный результат для Вашего примера в MSP.
На мой взгляд та "Малая Земля", которую Вы избрали для атаки на MSP не очень
сильная позиция. У MSP, наверное, существуют более серьезные недостатки, в поиске
которых я говтов оказать помощь...

By Евгений on Среда, Март 14, 2001 - 23:06:

Владимир,
зря Вы отмахиваетесь: "...я вам уже отвечал выше - задайте операциям тип ALAP и получите расписание точно в срок". Вчитайтесь, пожалуйста, в упоминаемые мною ранее проблемы с статическим и динамическим множеством исходных данных для составления производственного расписания. Это вовсе не "бред", а, увы, теория! Наличие же заготовки равносильно возможности начала выполнения первой технологической операции для данной детали. Нет заготовки - нельзя и начинать обработку детали, т.е. соответствующую ей технологическую цепочку работ следует сдвинуть "на потом". А Вы говорите: "...и к работам и их порядку никакого отношения не имеет...". Еще как имеет!
1. По поводу параметра ALAP (As Last As Possible). Такие расписания, возможно, и имеют смысл в планирования графика движения поездов, но в производстве, особенно в тех случаях, когда имеются промежуточные технологически зависимые операции в сборе (напр., одновременное сверление отверстий в двух деталях или совместная фрезеровка секций матрицы, смонтированных на нижнюю плиту), такой метод просто неприменим. Ведь эти зависимые операции могут встретиться и в самом начале технологического процесса обработки деталей!
2. Критерий составления расписания с минивальным числом переналадок (с минимальным числом смен технологических баз на взаимозаменяемом оборудовании) - это один из важнейших производственных критериев. Ведь любая переналадка оборудования и переустанов детали сопровождается потерей точности позиционирования и снижением качества обрабатываемой поверхности. А вот это, действительно, недопустимо. Поэтому на производстве, особенно в мелкосерийном и единичном, нередко коэффициент загрузки оборудования составляет 0.5, но это и не считается криминалом. Криминал, если какая-то деталь, входящая в состав изделия, будет забракована на этапе ее изготовления. Длина критического пути здесь, по-существу, значения не имеет.
3. Производственное расписание, как правило, нарушается через несколько часов после начала его реализации в цехе, и к этому все относятся как к нормальному явлению (чего нельзя сказать о нарушении расписания поездов). Сбор текущей информации о реальном состоянии работ - очень серьезная проблема. Владимир, расскажите, пожалуйста как Вашем пакете "...регулярно вводится информация об исполнении и изменениях..." для размерности задачи от 2 до 15 тысяч?
Заранее благодарен.

By Владимир on Четверг, Март 15, 2001 - 01:51:

Сергей,

вы считаете логичным, что не пакет составляет расписание работ, а человек? А пакет только красиво отображает составленное человеком расписание?

Вы не замечаете мои вопросы - в частности, почему тогда Project меняет порядок исполнения работ при изменении длительности одной операции на один день. Это тоже логично?

И как вы представляете себе ввод большого проекта при котором нужно соображать, в каком порядке ввести операции, чтобы пакет составил приемлемое расписание?

Кстати, я не помню такого в документации MSP, а уж у P3 этого нет точно. И в идеологии P3 этого нет - все таки P3 профессиональный пакет и так позориться не станет.

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

Если помните, я всего лишь предупредил, что нужно осторожно относиться к расписаниям, составляемым MSP, если ваши ресурсы ограничены, и привел вышеупомянутый пример.

Вы вряд ли кого-нибудь убедите, что менеджер проекта будет счастлив, получив расписание на 40% длиннее оптимального только из-за того, что он не в том порядке задал операции проекта. Кстати, я попробовал вводить операции в разном порядке, но с неизменным результатом. Поделитесь, как вам удалось добиться, чтобы порядок ввода изменил расписание? Не пришлете проект?

Евгений,

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

Операция типа ALAP исполняется как можно позже с учетом всех наложенных взаимосвязей. Тип ALAP совсем не означает, что операция обязательно уедет на конец проекта. Если она должна исполняться одновременно с какой-то, то она и будет исполняться с ней одновременно (взаимосвязь). Так что никакого противоречия здесь нет.

Насчет переналадок у меня опыта нет - приведите пример такой модели и я отвечу, как это промоделировать и составить разумное расписание. То, что вы пишете слишком общо, чтобы ответить конкретно.

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

By Сергей Рубцов on Четверг, Март 15, 2001 - 10:35:

Владимиру.

>Вы не замечаете мои вопросы - в частности, почему тогда Project меняет порядок исполнения работ при изменении длительности одной операции на один день. Это тоже логично?

Похоже, в MSP "зашито" правило, в соответствии с которым при прочих равных условиях более длительная работа получает приоритет. Как отменить или изменить это правило я не нашел. Исправляется ситуация явным заданием последовательности исп. работ. Логично ли это? Ну... как посмотреть.
Например, мне тоже кажется, что Вы не обращаете внимания на некоторые мои аргументы. В частности, ранее я писал, что если бы MSP работал иначе (т.е. по-вашему правильно), то Вам бы вручную пришлось ставить "флажки" у тех работ, для которых Вы бы не желали применять соответствующий критерий оптимальности.

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

Вывод. Обсуждаемое примитивное правило MSP c одной стороны "грузит" необходимостью следить за порядком исполнения "начальных" работ, а с другой стороны "разгружает". Последнее связано с тем, что в действительности эвристическое правило "сделай сначала сложное" ,как правило , :-) верно.

>И как вы представляете себе ввод большого проекта при котором нужно соображать, в каком порядке ввести операции, чтобы пакет составил приемлемое расписание?

Только сейчас обнаружил, что из списка пропал один мой постинг. Поэтому повторяю ответ.
Дополнительная работа, которой "грузит" MSP, касается только тех работ, для которых не задается начало исполнения или знание этого параметра непринципиально. В Ваше примере это - работы 1 и 3. В реальной жизни такие ситуации встречаются крайне редко. С другой строны, этот недостаток дает иные примущества, о которых я уже писал в этом постинге

By Владимир on Четверг, Март 15, 2001 - 11:06:

Сергей,
во всех пакетах есть возможность задавать директивные даты исполнения работ, если для пользователя это важно. И это в любом случае (оптимизирует пакет расписание или нет) следует делать. Так что это ничего не меняет в трудоемкости планирования. А вот отсутствие возможности получения лучшего расписания при всех заданных ограничениях очень дорого обходится для проекта. Вы представляете, во что обходится задержка с окончанием проекта на 40% в жизни?

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

В жизни работ, сроки исполнения которых нужно определить исходя из общих интересов проекта, всегда бывает подавляющее большинство. Здесь я с вами абсолютно не согласен.

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

By Олег Смирнов on Четверг, Март 15, 2001 - 11:36:

Сергею Рубцову.
Зная Вашу настойчивость, я уверен, что у Вас получится составить оптимальное расписание любого проекта в MSP путем грубого изнасилования его-же (MSP).

Вчера вечером я около часа крутил этот злосчастный пример и сильно пожалел о своем потраченном времени (Билл Гейтс не платит мне за дебаггинг, а Вам ?:)

По моему мнению, инструмент “приоритеты” – продукт нечеткой логики, чего не скажешь про инструмент “связи”. Технология моделирования, которую Вы предлагаете, очень сильно напоминает алгоритм решения системы линейных уравнений методом подбора.
---
С другой стороны, мне очень близко мнение Евгения о невсесисльности методов моделирования из-за динамичности или непредсказуемости входных данных
(когда резинка “сегодня” поднимается над забором Ганта, невольно возникает много вопросов как к управляющему проектом, так и к MSP)

By Владимир on Четверг, Март 15, 2001 - 11:51:

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

By Сергей Рубцов on Четверг, Март 15, 2001 - 12:05:

Владимиру.
Мне трудно спорить с написанным Вами в последнем постинге потому, что сам разделяю эти положения. Но, странное дело, мы делаем из них различные выводы для самых очевидных ситуаций. Вы пишите
> ...Вы представляете, во что обходится задержка с окончанием проекта на 40% в жизни?

А я уже в нескольких постингах писал, что Ваше "ускорение" может быть далеко от улучшения.
Вот, к примеру, две работы : (1) собственно разработка программного продукта и (3) разработка дизайна коробки для него (нумерация из Вашего примера). Ваша оптимизация приведет к исполнению в первую очередь этапа (3) потому, что оно короче и проще, а MSP предлагет исполнить сначала (1). Это - эвристика, которая может быть полезной. Во всяком случае это свойство позволяет меньше исполнять рутинной проектной работы, если , конечно, осознавать наличие этого свойства...

Вы пишите.
>во всех пакетах есть возможность задавать директивные даты исполнения работ, если для пользователя это важно. И это в любом случае (оптимизирует пакет расписание или нет) следует делать. Так что это ничего не меняет в трудоемкости планирования.
А я и не "напирал" на это. Я только предполагал, что предлагаемая Вами оптимизация может добавить несколько ручной работы по учету выше описанной эвристики в работе проектировщика. Как много? Не знаю...

By Сергей Рубцов on Четверг, Март 15, 2001 - 12:12:

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

By Владимир on Четверг, Март 15, 2001 - 12:36:

Сергей,

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

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

В третьих, почему вы считаете, что при оптимизации расписания в первую очередь исполняются более короткие и простые работы? Это было бы слишком просто.

Но вы так и не ответили на мой вопрос - если вы считаете, что MSV расставляет приоритеты в порядке ввода, то чем вы объясните изменение расписания при изменении длительности четвертой операции на один день? Этот факт делает ваши аргументы в дискуссии лишенными смысла, а наш спор - беспредметной потерей времени.

By Олег Смирнов on Четверг, Март 15, 2001 - 12:39:

Владимир, мне кажется, что в первую очередь необходимо создать движущую силу, заставляющую проектную команду отслеживать изменения :)
Наверное это отклонение от темы дискуссии, но по моему мнению, на первом месте стоит умение управлять проектом, а на втором - эксплуатировать софт. Т.е. динамичное постараться сделать статичным, непредсказуемое - планируемым.

Сергей, ничего не понял про "кибернетического" человека. Это как - в голове планировать ресурсы и последовательность операций, оптимизировать расписание а потом рисовать в MSP ? ))

By Владимир on Четверг, Март 15, 2001 - 12:54:

Олег,
полностью с вами согласен.
Софт - это инструмент менеджера проекта и только.
Просто дискуссия неожиданно для меня завязалась относительно свойств пакета MS Project в ответ на мое замечание, что не для всех проектов MS Project - наилучшее решение при выборе такого инструмента.
Всего наилучшего.

By Сергей Рубцов on Четверг, Март 15, 2001 - 13:26:

Владимиру.
Для разрядки ситуации я утверждаю, что MS Project - не лучшее решение... :-)

В остальном Вы меня, Владимир, отказываетесь понимать. Уж не сознательно ли? Вы пишите

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

Разве? Я этот пример именно привел для конкурирующих ресурсов. И в Вашем примере работы (1) и (3) исполнялись одним ресрусом. Зачем же отрицать очевидное (см. Понедельник, Март 12, 2001 - 16:51:)?

>В третьих, почему вы считаете, что при оптимизации расписания в первую очередь исполняются более короткие и простые работы? Это было бы слишком просто.

Удивительно трактуете! Это не я считаю, а Вы. Посмотрите на свой пример!!! Ваше оптимальное решение получается только в этом случае!!!!
А я как раз утверждаю обратное - см. постинги.

>Но вы так и не ответили на мой вопрос - если вы считаете, что MSV расставляет приоритеты в порядке ввода, то чем вы объясните изменение расписания при изменении длительности четвертой операции на один день?

MSP действительно расставляет приоритеты именно так. Это первое правило. Но оно "перебивается" другим более важным эвристическим правилом, о котором я уже долго Вам говорю:
"Сначала исполняются для одного и того же ресурса более длительные работы, а потом более короткие" - см. пример с коробкой.

Олегу Смирнову.
Мысль была более простой :-). А именно, человек, просидевший за ПЭВМ 8 часов подряд, кардинально отличается от человека, пившего в это время пиво.

By Владимир on Четверг, Март 15, 2001 - 14:54:

Сергей,

я писал о вашем примере, а не о моем - дизайн коробки и программирование делают разные люди.

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

Как то правило, о котором вы говорите, работает в примере, о котором мы говорим, мне непонятно.
От изменения длительности операции, на которую назначен ресурс b и которая не является начальной, изменяется порядок назначения ресурса a на начальные операции (причем с нарушением вашего эвристического правила). Посмотрите еще раз пример.

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

By Сергей Рубцов on Четверг, Март 15, 2001 - 15:29:

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

Для ясности можно еще упростить Ваш пример. Если Вы не принимаете мои "коробки", то давайте рассуждать абстрактно. Возмите всего 2 работы: W1 и W2. Назначте им одного исполнителя. При изменении длительности работ в MSP будет меняться последовательность их исполнения... Первой будет исполняться работа с большей длительностью.

Этот пример является тем примитивом, на основе которого действительно можно делать общие выводы (не все какие придется, а те которые я привел выше :-)

>Как то правило, о котором вы говорите, работает в примере, о котором мы говорим, мне непонятно.
От изменения длительности операции, на которую назначен ресурс b ...

Вы опять искажаете смысл мною сказанного. Посмотрите мой предыдущий постинг. Я говорил о работах (1) и (3), т.е. о ресурсе А. Только эти работы обладают тем признаком, о котором я уже не раз писал : "неопределенность начала работ". Для работ (2) и (4) "начала" заданы окончаниями работ (1) и (3), соответственно.

Владимир, я ни в чем Вас не обвиняю. Естественно, я допускаю, что непродуктивное непонимание может быть вызвано моими плохими объяснительными способностями ...

By Владимир on Четверг, Март 15, 2001 - 18:07:

Сергей,

я уже предлагал ввести операцию 5, которая предшествует и первой и третьей? В этом случае их начало определено окончанием работы 5 или нет?

Объясните пожалуйста, почему при изменении длительности операции 4 с 15 дней на 14 MS Project первой исполняет более короткую работу 1, а не более длинную 3.

Кстати, я еще раз посмотрел свой пример - если бы пакет исполнял работы в порядке ввода, то он начинал бы с работы 1 и составил оптимальное расписание с самого начала.

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

Я уже вообще перестал понимать ваши аргументы и что вы пытаетесь доказать.

By Евгений on Четверг, Март 15, 2001 - 22:02:

Извините, господа, что опять Вас перебиваю...
Вы обсуждаете способы составления расписаний для управления проектом. Вам лучше знать, вероятно, специфику данной задачи, управление проектом - дело тонкое. А я, увы, имею дело больше с расписаниями производственными, с грубыми и вечно задерганными начальниками цехов, мастерами-матершинниками, с твердолобыми руководителями производственно-диспетчерских бюро...
У нас бывает так: прибегает начальник и орет: "Вы что там ....!!! Вы когда собираетесь сдать заказ ¹ХХХХ ?!! Да там же только базовая деталь фрезеруется N дней. Да Вы у меня премию ...., вот где увидите! (и образно показывает, где именно)". После таких динамически поступивших исходных данных производственное расписание расчитывается по критерию, для которого максимальный приоритет назначается партии деталей, имеющей max цикл обработки (есть такой производственный критерий).
А иногда, подходит бухгалтер к начальнику цеха и шепчет ему тихонько на ухо: "Ты, Иван Иваныч, сдай хоть один, пусть маленький, но готовый комплектик деталей, чтобы можно было бы заказик какой-нибудь закрыть, А то, уважаемый, я не могу ничего тебе оплатить, и, следовательно, зарплата рабочих ...". Иван Иваныч бледнеет... Вот здесь вспоминают о другом популярном производственном критерии - max приоритет придается партий деталей с минимальным циклом обработки.
Господа, не ассоциируются ли приведенные выше примеры с некоторыми противоречивыми положениями, возникшими в ходе Вашей дискуссии? Есть ли предмет для спора?

By Евгений on Четверг, Март 15, 2001 - 23:26:

Владимиру:
Согласен с Вами, что отсутствие заготовки "это не ограничение на порядок исполнения работ. Точнее - это не ограничение в виде взаимосвязи операций". Осутствие заготовки есть ограничение на начало первой работы и, следовательно, определяет задержку всей технологической цепочки связанных работ! Это типичная ситуация при наличии динамических начальных условий в задачах составления производственных расписаний. Подробности см., например, в [Graves S. A review of production scheduling. // Oper. Res., 1981, 29, N4, 646-675]. В пакете MSProject, реализован, по-видимому, метод критического пути CPM (алгоритм, который использует сетевые графики как способ представления сравнительно устойчивых компонент деятельности производственного подразделения, т.е. последовательности работ с максимальным циклом их выполнения). Недостатком этого метода является то, что чем более детальным является план, тем менее устойчивым будет соответствующее ему расписание [Kusiak A. Flexible manufacturing systems: a structural approach //Int.Journal of Prod. Research, 1985, 23, N6, 1057-1073]. Так что удивляться чему-то в приведенном Вами примере не следует.

By А.Г. on Пятница, Март 16, 2001 - 00:03:

Господа, разрешите добавить несколько перпендикулярное направление в дискуссию. Касающееся не столько программных реализаций, сколько вообще идеологии проектного менеджмента. Если мое сомнение окажется справедливым, то обсуждаемая вами неоптимальность - далеко не самая неприятная из возможных.

Сомнение следующее. В греческом есть два разных слова для обозначения времени: хронос и кайрос. Первое означает время в смысле продолжительности, протяженности, т.е. именно то время, которое всячески отображается и учитывается в современных средствах управления проектами (сетевые графики, заборы Гантта и прочие полезные вещи).

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

Важность учета второго понятия времени поясню на примере из организации личной работы (тоже своего рода проектный менеджмент). Есть дела, привязываемые к времени-"хроносу" - встреча с Пупкиным И.И. в 17:00, до этого нужно зайти в библиотеку и прочитать журнал "Деловые Нью-Васюки", на что потребуется 45-50 мин; дороги от библиотеки до кабинета - 10-15 мин. Optimistic Gantt, Pessimistic Gantt, итд итп - все понятно.

Откуда берется время-"кайрос"? От неоднородностей времени типа: "время, в которое я прохожу мимо газетного ларька", "время, в которое я увидел пролетающего мимо тов. Скумбриевича", "время, в которое коллеги неожиданно все разом перестали висеть на телефоне и он освободился". Не надо приводить примеры дел, которые можно сделать _только_ в этот момент и о которых следовательно нужно вспомнить _именно_ в этот момент? Полагаю, найти соответствующие примеры на уровне _фирмы_, а не человека, тоже не составит труда.

Куда я клоню? Даже возможность быстро пересчитывать сетевые графики на основании поступающей информации здесь не поможет - потому что здесь речь идет не о перекраивании реальности под заранее нарисованную модель, для чего нужны сетевые графики, а об отслеживании _радикальных_ изменений реальности и об адекватном реагировании на эти изменения, т.е. совершенной перекройке всех действий (а не просто пересчете количественных параметров когда-то сочиненного плана).

Т.е. речь идет о совершенно другом подходе к стратегии - не планировать действия и выполнять план во что бы то ни стало, а _имея в виду_ долженствующее быть сделанным, отслеживать благоприятное для этого время.

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

В области техники личной работы я знаю, как можно реализовать второй подход к стратегии. Я это называю "системой структурирования внимания". Чтобы при виде пролетающего мимо Скумбриевича рука сама потянулась в портфель за желтой папкой с ботиночными тесемками, при планировании рабочего дня в голове должна была быть создана соответствующая упорядоченность (как ее реализовать в органайзере, расписании на неделю итп материальных носителях - дело техники).

А вопрос-то собственно состоит в том, есть ли средства решения этой же проблемы на уровне фирмы, или проекта? Т.е. существуют ли средства управления проектами, позволяющие реализовывать второй подход к стратегии? Для простоты сначала можно представить проект в виде нескольких совершенно разных сетевых графиков, осуществляемых независимо друг от друга (наподобие музыкальных голосов в гармонии), при этом существует некая система, на основе данных об изменениях ситуации рекомендующая график ("сюжетную линию", последовательность мероприятий...), на исполнение которого в настоящий момент должно быть обращено первостепенное внимание.

PS: Владимир, а откуда информация о нераспространенности сетевого планирования до начала 80-х? Когда я рассказывал своему деду (инженеру-мостостройщику) про проектный менеджмент, он говорил, что все это сетевое планирование у них было (60-е-70-е г.г.), только называлось по другому и рисовалось, естественно, на бумаге, а не на компьютере. Причем инструментарий очень похожий - тот же Ганнт, те же ресурсные графики. Сколько КАМАЗов бетона, сколько рабочих...

Еще к вам как к специалисту в области управления проектами вопрос: чем пользуются для управления проектами (и вообще насколько приемлют эту идеологию) китайцы, японцы и подобные им восточные товарищи? Это меня интересует потому, что вышеописанный второй подход к стратегии у них особенно хорошо разработан.

By Владимир on Пятница, Март 16, 2001 - 00:19:

Евгений,

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

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

Метод критического пути работает при условии неограниченности ресурсов проекта. При ограниченных ресурсах используются эвристические методы, которые в разных пакетах отличаются и соответственно дают решения, в той или иной мере устойчивые и разумные. Как вы справедливо заметили, точного оптимума гарантировать никто не может, но у одних пакетов решения совсем тупые, у других получше и инструментов воздействия на расписание побольше, чем у MSP.

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

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

By Владимир on Пятница, Март 16, 2001 - 00:41:

Для А.Г.

Японцы и китайцы активно внедряют у себя современные технологии управления проектами, приглашают американских преподавателей и т.д. В Японии и Китае имеются отделения PMI, в Японии довольно много PMP (сертифицированных Project Management Professionals).

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

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

А Гант свои графики вообще в начале века предложил.

By Евгений on Пятница, Март 16, 2001 - 01:36:

Владимир,
Вы пишете: "...я считаю, что в пакете управления проектами должны быть средства, повышающие устойчивость расписаний". А я считаю, что Вы коснулись очень интересной и весьма дискуссионной проблемы - оценки качества оптимизирующего эвристического алгоритма составления расписаний. Дело в том, что в классической теории управления известен интересный факт: чем более устойчивая система, тем менее она управляема (например, неусточивый велосипед гораздо более управляем в движении, нежели движущийся устойчивый тяжелый грузовик). Вот мой вопрос: не возникнет ли, господа, ситуация, при которой алгоритм, генерирующий устойчивое расписание на статическом множестве данных, т.е. хорошее расписание, минимизирующее критический путь проекта (брахиста_хрона - минимальное время в терминах уважаемого АГ), не будет обладать достаточной долей "управляемости", т.е. не будет способен эффективно реагировать на "кайрос" - на динамически изменяемые начальные или текущие условия планирования? А может быть именно MSP, если его непрерывно применять для коррекции расписания, и даст наилучший результат по сравнению с другими продвинутыми пакетами? Вспомните историю о "Гадком утенке"! Я вовсе не защищаю MSP, я просто высказываю гипотезу...
Хотелось бы узнать Ваше мнение, господа профессионалы.
АГ: Китайцы имеют такие же проблемы в составлении производственных расписаний как и мы. В некоторых случаях используют даже российский софт. Российкие программы, кстати, нисколько не хуже американских. Я это знаю.

By Владимир on Пятница, Март 16, 2001 - 08:56:

Евгений,

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

У MSP расписание "неуправляемое", ваша гипотеза не пройдет. Пакет предназначен для начинающих, слишком сложные возможности может отпугнуть "домохозяйку".

Качество расписаний сейчас проверяется сравнением на тестовых примерах и в жизни. Например, существует совокупность тестовых примеров Паттерсона, на которых можно прогнать алгоритмы и сравнить полученные раписания с оптимальными.
Опять же наши расписания все тесты, которые мы пробовали, прошли успешно.

By Сторонний наблюдатель on Пятница, Март 16, 2001 - 09:41:

Доброго времени суток, господа! Можно и мне к вам присоединиться?

А.Г. подкинул интересную идею, описывая «…хронос и кайрос…», которая навела меня на вот какую давнюю мысль. (Может быть уважаемый Владимир Иосифович поможет мне разрешить мои сомнения?)

Собственно что представляет собой календарный план проекта – структурированный набор работ, осуществляемый в некой логической и временной последовательности. Есть общая структура разбиения работ (СРР / WBS), есть собственно работы, есть логические связи между ними, ресурсы, календарь, ограничения, проч. Хорошо!

Но здесь начинается трабл. Жизнь, к сожалению, много «кучерявее», чем такой «забор Ганта». Представьте, что вы начали проект и после выполнения работы «А» вам нужно решить, что делать – работу «В» или работу «С» (Пример: «если мимо пролетит Скумбриевич, то дать ему папку, если нет – следовать в направлении библиотеки»). Т.е. проблема в том, что я не вижу :) , как в «заборе Ганта» сделать оператор «if … then … else ...», что, собственно сплошь и рядом есть в системах процессного (не проектного!) управления. Как нам поймать Скумбриевича, если, таки, он пролетит!

Владимир Иосифович! Помогите разобраться. Но, Бога ради, не относите Скумбриевича и вообще то или иное событие с числом выходов (результатов) более 1 на проектные риски! Если можно :)

By Владимир on Пятница, Март 16, 2001 - 15:11:

Стороннему наблюдателю.

Как вы правильно заметили, жизнь кучерява - поэтому я не стал бы отдавать какой-либо программе право выбирать куда следовать. Рекомендвать - да, но не решать за человека. Поэтому остутствие в программах УП операторов if then else я не считаю серьезным недостатком. Предусмотреть возможность появления Скумбриевича следует (не знаю, чем вам не нравятся риски, но это - типичный риск) и менеджер должен разработать реагирование на этот риск (дать ему папку), включить в план проекта и в случае действительного появления Скумбриевича запустить намеченное реагирование вручную - он обязан принять решение, а не машина. Управление проектами - не управление процессами и имеет дело с людьми. Напрямую программы управления проектами проектом не управляют, а дают рекомендации и ответы на вопросы "что если" тем, кто принимает решения. Соответственно любое изменение намеченного плана должно санкционироваться теми, кто за план отвечает.

Кроме разработки реагирования на появление Скумбриевича менеджер должен определить признаки и симптомы грядущего появления Скумбриевича, оценить вероятность появления Скумбриевича. Признаки и симптомы направлены на то, чтобы появления Скумбриевича не пропустить и своевременно приготовить ту папку. Эти признаки и симптомы не всегда видны из программы и вообще количественной информации (например запах Скумбриевича может следовать впереди него).

By Сторонний наблюдатель on Пятница, Март 16, 2001 - 16:30:

"...запах Скумбриевича может следовать впереди него..." Чего только не услышишь на форумах! :)

Уважаемый Владимир Иосифович! Вы пишите: "...Напрямую программы управления проектами проектом не управляют..." Вот именно! Меня и интересует, как я могу используя СКПК пересчитывать календарь проекта в зависимости от развития событий на том или ином его участке (if then else). То, что есть сейчас в большинстве программ (поправьте, если я ошибаюсь) предполагает переписывание всего календарного плана проекта под каждый "...запах Скумбриевича..."

By Евгений on Пятница, Март 16, 2001 - 19:27:

Господа, давайте оставим запахи в покое!
Владимир, очевидно, говорит о методе сетевого планирования проектов, так называемом PERT-анализе [извините за ликбез]. Метод PERT применяется, когда длительность каждой работы является неопределенной (случай «кайроса»). Чтобы оперировать с этой неопределенностью используются статистические распределения и вероятности. Этот метод позволяет избежать так называемого "комбинаторного взрыва" при составлении расписаний. Будучи эвристическим, PERT-метод имеет свои оригинальные алгоритмические реализации (каждая реализация есть "ноу-хау" соответствующих софтверных фирм). Думаю, что и такие пакеты как Primavera, Open Plan, Spider и аналогичные им, используют PERT-анализ для составления расписаний. В этом случае, минимизируя «хронос» для различных «кайросов», можно получить приемлемый результат. Так я думаю.

By Сторонний наблюдатель on Пятница, Март 16, 2001 - 19:46:

Евгений: "...длительность каждой работы является неопределенной..." На здоровье!

Мой вопрос не о вычислении длительности работы, а о вариациях связей между ними и возможности составления расписания в зависимости от положения "переключателя" на данных связях. Если такое в СКПК конечно возможно :)

By Евгений on Пятница, Март 16, 2001 - 22:17:

Стороннему наблюдателю:
В производственных расписаниях (в них я больше понимаю) имеется строгая технологическая последовательность работ, определенная технологом. Изменение этой последовательности физически недопустимо (напр., нельзя нарезать резьбу прежде, чем будет просверлено соответствующее отверстие). Каждая работа в качестве ресурсов может использовать несколько взаимозаменяемых рабочих мест, сгруппированных в станочные группы. Поэтому, при составлении расписания могут возникать различные альтернативные (в пределах станочных групп) маршруты движения деталей по рабочим местам. Положение "переключателя" имеет смысл только для рабочих мест в одной станочной группе. Это описывается, как правило, критериями типа: "загружать оборудование равномерно" или "использовать минимально возможное число станков" или "загружать станки с минимальным числом переналадок". Т.е. речь идет только о характере загрузки оборудования (заметили разницу с расписанием для управления проектом?), но технологическую последовательность работ нарушать категорически запрещается! Часто добавляются и правила выбора из очереди равноприоритетных по другим критериям работ: правила типа First-in-First-out (FIFO) или Last-in-First-out (LIFO) и пр. При этом, эвристические алгоритмы составления производственных расписаний подбираются, как правило, для различных комбинаций критериев (различных положений "переключателя") строго индивидуально. Ясно, что для таких наборов критериев оптимальное расписание не обязательно будет иметь минимальное время реализации. Хотя Владимир, по-видимому, не обратил ранее на это внимание.

By Владимир on Суббота, Март 17, 2001 - 00:54:

Стороннему наблюдателю.

Переписывание календарного плана означает, что событие риска не было предвидено заранее и на него не было заранее разработано реагирование. Если же альтернативный вариант был проработан, то переключение с одного варианта на другой в нашей программе займет пару минут для проекта любой сложности и не потребует дополнительного ручного ввода. Приезжайте к нам, мы покажем как это делается. Объяснять технологию на этом форуме неудобно.

Евгению.

Метод PERT позволяет моделировать лишь неопределенности в определении длительности и стоимости работ и не учитывает корреляции между характеристиками работ. Мы используем более тонкие методы, учитывая в том числе то, что при пессимистическом варианте развития проекта состав работ может отличаться от состава работ в оптимистическом варианте.

Я думаю, что и в производственных расписаниях из двух расписаний с одинаковым количеством переналадок более короткое будет предпочтительным, не так ли?

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

By А.Г. on Суббота, Март 17, 2001 - 17:08:

У меня возникает следующий большой вопрос. Вспоминаю классификацию человеческого знания: неосознанное незнание, осознанное незнание, осознанное знание, итд до неосознанного знания.

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

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

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

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

By Владимир on Суббота, Март 17, 2001 - 17:46:

А.Г.
В анализе рисков учитываются и known unknown и unknown unknown. Для предвиденного непредвиденного рассчитываются так называемые contingency reserves - резервы, которые следует заложить для надежного исполнения проекта (достижения целей проекта с заданной вероятностью), а также мероприятия на случай наступления предвиденных событий. Кроме того, на основании исторической информации и опыта менеджера проекта следует добавить так называемые management reserves - резервы на непредвиденные события, которые так же требуют обоснования. Понятно, что непредвиденные события на то и непредвиденные, что кроме резервов иного реагирования заранее разработано быть не может.

Средства УП достаточно гибки, чтобы корректировка плана проекта не была чересчур трудоемкой.

By Евгений on Суббота, Март 17, 2001 - 22:35:

Владимиру:
"Я думаю, что и в производственных расписаниях из двух расписаний с одинаковым количеством переналадок более короткое будет предпочтительным, не так ли?"
Нет, не так, поскольку время в данном случае значения не имеет и предпочтение может быть отдано, например, производственному расписанию, использующему минимальное число станков.

By Владимир on Суббота, Март 17, 2001 - 22:55:

ОК,
я считал это самим собой разумеющимся - из двух расписаний с одинаковым количеством используемых ресурсов и одинаковым количеством переналадок станков более короткое расписание предпочтительнее?
Если я еще чего-то не упомянул с вашей точки зрения - упомяните за меня.

By Евгений on Воскресенье, Март 18, 2001 - 12:48:

Владимиру:
"из двух расписаний с одинаковым количеством используемых ресурсов и одинаковым количеством переналадок станков" наиболее предпочтительным может оказаться вовсе не самое короткое, а то расписание, которое обеспечит первоочередную обработку нужной запчасти от автомобиля начальника.

By Владимир on Воскресенье, Март 18, 2001 - 14:42:

Евгений,

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

По-моему у нас пошел офтопик.

Всего наилучшего.

By А.Г. on Воскресенье, Март 18, 2001 - 18:03:

Владимир, спасибо за разъяснения о рисках. Впрочем вопрос об операторе if-then-else остается - именно как стандартном узле схемы, а не о способе действий в чрезвычайных случаях.

О резервах. Существуют ли, и какие, нормы резервов - отдельно по ресурсам и по времени? Приходилось слышать шутку об умножении суммы проекта на 2, продолжительности - на 3. Как обстоит дело в реальности? И чем обоснованы нормы резервов?

Например, в тайм-менеджменте есть правило - планировать не более 60% дня, оставляя прочее время резервом (создавая "буферные зоны" для смягчения неожиданных ударов по расписанию). Ничем не обосновывается (эмпирика), хотя у меня есть подозрение, что не обошлось без золотого сечения. Есть ли что-то подобное в подходе к планированию времени в PM?

By Владимир on Воскресенье, Март 18, 2001 - 21:47:

А.Г.

Существуют разные подходы к этой проблеме и много публикаций. Мы резервы рассчитываем, а не назначаем по каким-либо нормам.
Мне не хотелось на этом форуме упоминать о нашем пакете, но приходится. На сайте www.spiderproject.ru можете скачать Демо версию пакета Spider Project, в котором встроен анализ рисков и расчет contingency reserves (резервов на предвиденное непредвиденное).
Деловую игру на эту тему недавно провели на семинаре PMI - материалы (и созданный проект) - на сайте www.pmi.ru в разделе Мероприятия.
Из западных подходов и теорий заслуживает упоминания теория Critical Chain. Автор - Goldratt. Если запустите поиск - получите много ссылок.
В схеме проекта много контрольных событий, часть из которых - принятие решения о дальнейшем развитии проекта. Эти же события - точки ветвления if-then-else.

В связи с тем, что некоторые вопросы начинают принимать технический характер и на часть из них я не могу ответить абстрактно без ссылок на решения, реализованные в нашем пакете, у меня просьба - задавать подобные вопросы на сайте www.spiderproject.ru. Мне бы не хотелось, чтобы мои разъяснения кто-то воспринял как рекламу.

Всего хорошего.

By Валерий on Среда, Март 21, 2001 - 14:30:

интрересно было читать ваши постинги, господа.
по поводу if-then-else мне подумалось, что запросов таких из реальных ситуаций не поступило. или их крайне мало.
для реализации в том виде, о котором, как я понял говорит А.Г.

By Сторонний наблюдатель on Среда, Март 21, 2001 - 18:38:

То: Валерий

"...по поводу if-then-else мне подумалось, что запросов таких из реальных ситуаций не поступило..."

Каждый из нас "варится", в той или иной степении, в своей среде :) Если в "Мостоотряде-18" такого не надо, это не значит, что этого не надо нигде. Мне же, как руководителю IT-проектов, крайне необходимо иметь возможность гибкого пересчета расписания по принципу "if-then-else".

Знаете в чем разница в наших бизнесах? :) Я могу, в определенных разумных пределах выполнить работу ¹2 ДО работы ¹1, а Вы - нет. Вы не можете залить бетон до сооружения опалубки. И если опалубка не поставлена, то нужно, условно говоря, ждать. В IT если программеры в срок сделали фичу "А", то я иду по пути работ "АА", если нет, то по пути "АВ". Я вообще могу отказаться от фичи "А" и заказать фичу "В" без потери в свойствах ПО и отступов от ТЗ. Попробуйте, поменять свою технологию заливки бетона (мост на Комсомольском проспекте уже был :(- )

Более того, Вы вынуждены выполнить ВЕСЬ комплекс работ, определенный календарным планом. И только ПОЛНОЕ выполнение календарного плана означает ПОЛНОЕ выполнение проекта (что, наверное :), справедливо для строительства). Если же предположить, что системы СКПК допускают применение оператора "if-then-else", то это будет означать, что для ПОЛНОГО выполнения проекта не нужно 100% выполнения ВСЕХ работ (что обычно бывает в IT). Критерии "проект завершен" другие!

Куда нам после этого пристроить PMBOK и как относиться к классике управления проектами? Какой инструментарий использовать для управления сроками в проектах с динамично меняющимся составом календарного плана? У Вас есть ответы? К сожалению, MSPr и а-ля СКПК дают уж слишком мертвую картинку.

By Владимир on Среда, Март 21, 2001 - 21:24:

Стороннему наблюдателю.
В любом проекте, в том числе и в строительном могут возникнуть различные пути достижения результата. В любом проекте при определенных условиях может нарушиться (измениться) порядок исполнения работ по факту (например, намеченный порядок строительства захваток). Это ничему не противоречит. Просто желательно и по новому пути идти с планом, а значит по возможности заранее разработать процедуры реагирования на меняющиеся обстоятельства. А вот выбор варианта нельзя отдавать машине - нужно просто иметь простые и эффективные средства переключения с одного варианта реализации проекта на другой. Приезжайте - покажем.
А выполнение проекта означает 100% исполнение его работ - просто некоторые ветки при этом "закрываются" - считаются исполненными без расхода ресурсов и затрат, если надобность в них отпадает. Такое закрытие тоже может быть легко автоматизировано. Здесь абсолютно нет проблем, хотя трудоемкость разработки модели проекта безусловно возрастает из-за многовариантности

By Сторонний наблюдатель on Четверг, Март 22, 2001 - 09:46:

Владимир: "...Приезжайте - покажем..." Спасибо за приглашение, обязательно, но, боюсь, не ранее, чем через 3 недели - очень жесткий график работ.

By Валерий on Четверг, Март 22, 2001 - 12:05:

Стороннему наблюдателю.

я рад, что вы знаете о моем месте работы:-)
заметьте, что я не привязывался к отрасли.
пример опалубка/бетон - тривиальный. при желании (Вашем, разумеется) я могу вам привести пример из нашей отрасли с if-then-else...
я немного не об этом говорил.
т.е. разоаботчики СУП реагируют на потребности пользователей. так?
значит, или запросов к разработчикам "реализуйте нам if-then-else" мало, либо у них есть методика, позволяющая моделировать проекты с динамично меняющимся составом календарного плана.
скажу вам честно, мне не приходилось встречаться с этим.
на стадии ТЭО - да. несколько вариантов расписания, зависящих от технологии. но не от события в процессе.

By Павел Майстров on Среда, Март 28, 2001 - 15:32:

Предлагаю посмотреть популярную в Скандинавии ERP/CRM систему "Hansa Financials"
www.hansa.lv/rus/index.html
www.hansaworld.com

By Аноним on Суббота, Октябрь 06, 2001 - 17:20:

День добрый!

Заинтересовало обсуждение проджекта. Большое спасибо за пример оригинального расписания, будем соблюдать осторожность. У меня есть подозрение, что суть проблемы состоит в слишком сильном превалировании пути 15+15 над 2+15, что заставляет проджект наброситься сначала на более "опасный" участок. С другой стороны, если учесть, что критический путь проекта составляет 30 дней, то и 45 дней на завершение вроде бы не так уж много. Да и стоимость не меняется.

Гораздо забавнее оказалось сопоставить объемлющую задачку для четырех рассматриваемых и назначить ей ресурс. Проджект на затраты, простите, положил, и несмотря на чрезвычайно высокую стоимость "общего" ресурса, все равно сделал 45 дней. Увеличив, при этом, затраты на проект на порядок. Вот это уже крупный минус, что в левелинге ресурсов проджекта столь малое внимание (видимо, вообще никакое) уделяется вопросу изменения стоимости при увеличении длительности.

Однако по поводу возможности использовать Spider Project в рабочих группах у меня есть некоторые сомнения. Какова степень интеграции пакета со стандартными офисными утилитами? Что надо ставить на рабочих станциях, чтобы автоматизировать выдачу заданий и отчетность? По этим пунктам проджект очень продвинутая утилита.

By Владимир Либерзон on Воскресенье, Октябрь 07, 2001 - 01:08:

Чтобы автоматизировать выдачу заданий и сбор отчетности нужно ставить на рабочих станциях сам Спайдер. На самом нижнем уровне достаточно Демо. Однако возможны варианты. Так, в АйТи для ведения учета используют Lotus Notes, а Спайдер отправляет в Lotus задания и забирает отчетность.
Более короткие расписания практически всегда и более оптимальны с экономической точки зрения. Короткое расписание означает минимизацию простов, а за простои нужно платить. Удивляет то, что удлинение проекта в 1,5 раза вы не сочли проблемой. Вы не боитесь опоздать на рынок со своими разработками, или нарваться на штрафные санкции при работе по контракту?

By Stream on Среда, Апрель 02, 2003 - 16:57:

Господа, испытываю неподделный интерес к программному обеспечению управления проектами. Хотелось бы реально потыкаться в это носом. Но под руками ничего нет. Из текстов вынес, что наиболее любопытно было бы практиковаться в планировании в MS Project 2002(локализованный) и Spaider.
Я энергетик из маленького энергетского городка и даже в окрестных облцентрах об этом никто ничего не слыхал. Покупать для предприятия не могу, сначала надо проверить и поиграть. Помогите чем можете. В ближайшее время буду в городе - герое и столице нашей Родины. Подскажите, где это можно приобресть по доступной цене.

By Владимир Либерзон on Четверг, Апрель 03, 2003 - 16:14:

Демо версия Спайдера (рабочая на 40 операций с которой можно поиграть и даже поработать) выложена на сайте www.spiderproject.ru. Там же можно скачать руководство по программе, а в форуме задать вопросы и посмотреть, что обсуждалось. В разделе Публикации имеется презентация по спецификациям пакета. Если будете в Москве - можете подъехать в офис компании и выяснить интересующие вас вопросы, адрес и телефон есть на сайте.
Всего доброго.