Оно само по себе не плохо. Это один из взглядов на вещи, по своему полезный. То, что любой план может быть сведен к сетевому графику - это закон природы. Умный человек не привязывается к одному взгляду на вещи, а умеет взглянуть на одно и то же с разных сторон, выбирая оптимальный взгляд для каждой ситуации.
К примеру, глядя на карту целей как на сетевой график, ты получаешь группу безымянных задач, к каждой из которых определено событие окончания, связанных отношением "окончание-окончание". Некоторые из этих задач обладают нулевой длительностью, и являются с точки зрения сетевого планирования "майлстонами".
Существенных отличий предлагаемого взгляда на вещи - несколько. Первое - активности безымянны, в модели отсутствуют. Именно это позволяет свести четыре типа отношения задач к одному типу отношения между событиями.
Активности подразумеваются неявно, и выражаются _только_ в терминах ограничений на темпоральное отношение.
Этот подход, в свою очередь, позволяет убрать отношение подзадачи, которое есть в сетевом планировании, как класс (при переходе к сетевому планированию оно трактуется как специальный случай связи "окончание-окончание"), и заменить его вполне содержательным правилом, которое я указал в корневом посте.
В результате _комбинации_ перечисленного, и появляются все приятные свойства системы. В частности, легкость логической проверки плана. А они связаны с _разделением_ размышления о целях, и способах их достижения. Думая в терминах сетевого планирования мы думаем сразу и об одном, и о другом. Думая в терминах декларативного - мы разделяем эти проблемы, настолько, насколько это возможно, и решаем из раздельно.
Это свойство дает возможность продуктивно работать над очень объемными и сложными планами, причем - работать группой, не свернув себе шею. Такой взгляд на вещи удобен, когда составляется костяк плана. Сетевой график - более удобен и нагляден, когда составляется schedule. И он является предельным частным случаем детализации "карты целей" - нет тут никакого противоречия и противопоставления.
Я достаточно доступно объяснил разницу? А теперь несколько общих слов. Планирование - это составной элемент _практики_ управления проектами, а не теории, и чтобы понять любой подход надо проектами все-таки немного поруководить достаточное время, чтобы наловить граблей самому.
Умозрительный подход, Сергей, здесь не работает, это не та вещь, которую можно понять не имея практического опыта. Это знания высшего порядка, как магическая книга, - для мага низкого уровня будет набором кракозябров.
Ты можешь думать, что раз тебя сделали менеджером, и ты умен, то ты сразу начнешь во всем разбираться. Это не так. Ума недостаточно, чтобы понять многие вещи. Только в математике его достаточно. А здесь - требуется практический опыт. Это инженерный подход.
И если ты будешь отказываться признавать этот факт, то только затормозишь продвижение по уровням вверх, не более того. Перечитай вот этот пост, это примерно то, что я хочу тебе сказать сейчас. http://gaperton.livejournal.com/14664.html
Наличие имён у активностей требуется для демонстрации плана работ. Имена активностей указывают на подсистемы. Кстати, имя активности у меня можно отбросить. И ввести ещё одно ключевое слово relation или как угодно.
Работа над подсистемой core включает в себя работу над целями netlist_opt(...) и simulation(...). Так просто проще.
Можно указывать, конечно, что это ведёт к достижению некоторой цели core(tested,all). Можно. Но можно и так. ;)
Так мне показалось проще, потому, что если цель находится глубоко и требуется во многих системах сразу, то получится не очень удобно.
(напоминать о ле--вых St-te мо--дах не буду - к вопросу о магии;)
(напоминать о ле--вых St-te мо--дах не буду - к вопросу о магии;)
Не напоминай. Мало того, что это не имеет никакого отношения к теме, так я еще и никак не претендую на то, что лучше тебя разбираюсь в монадах. И что вообще - в них разбираюсь. Так что есть целых два повода о них не упоминать.
К примеру, глядя на карту целей как на сетевой график, ты получаешь группу безымянных задач, к каждой из которых определено событие окончания, связанных отношением "окончание-окончание". Некоторые из этих задач обладают нулевой длительностью, и являются с точки зрения сетевого планирования "майлстонами".
Существенных отличий предлагаемого взгляда на вещи - несколько. Первое - активности безымянны, в модели отсутствуют. Именно это позволяет свести четыре типа отношения задач к одному типу отношения между событиями.
Активности подразумеваются неявно, и выражаются _только_ в терминах ограничений на темпоральное отношение.
Этот подход, в свою очередь, позволяет убрать отношение подзадачи, которое есть в сетевом планировании, как класс (при переходе к сетевому планированию оно трактуется как специальный случай связи "окончание-окончание"), и заменить его вполне содержательным правилом, которое я указал в корневом посте.
В результате _комбинации_ перечисленного, и появляются все приятные свойства системы. В частности, легкость логической проверки плана. А они связаны с _разделением_ размышления о целях, и способах их достижения. Думая в терминах сетевого планирования мы думаем сразу и об одном, и о другом. Думая в терминах декларативного - мы разделяем эти проблемы, настолько, насколько это возможно, и решаем из раздельно.
Это свойство дает возможность продуктивно работать над очень объемными и сложными планами, причем - работать группой, не свернув себе шею. Такой взгляд на вещи удобен, когда составляется костяк плана. Сетевой график - более удобен и нагляден, когда составляется schedule. И он является предельным частным случаем детализации "карты целей" - нет тут никакого противоречия и противопоставления.
Я достаточно доступно объяснил разницу? А теперь несколько общих слов. Планирование - это составной элемент _практики_ управления проектами, а не теории, и чтобы понять любой подход надо проектами все-таки немного поруководить достаточное время, чтобы наловить граблей самому.
Умозрительный подход, Сергей, здесь не работает, это не та вещь, которую можно понять не имея практического опыта. Это знания высшего порядка, как магическая книга, - для мага низкого уровня будет набором кракозябров.
Ты можешь думать, что раз тебя сделали менеджером, и ты умен, то ты сразу начнешь во всем разбираться. Это не так. Ума недостаточно, чтобы понять многие вещи. Только в математике его достаточно. А здесь - требуется практический опыт. Это инженерный подход.
И если ты будешь отказываться признавать этот факт, то только затормозишь продвижение по уровням вверх, не более того. Перечитай вот этот пост, это примерно то, что я хочу тебе сказать сейчас.
http://gaperton.livejournal.com/14664.html
Reply
Работа над подсистемой core включает в себя работу над целями netlist_opt(...) и simulation(...). Так просто проще.
Можно указывать, конечно, что это ведёт к достижению некоторой цели core(tested,all). Можно. Но можно и так. ;)
Так мне показалось проще, потому, что если цель находится глубоко и требуется во многих системах сразу, то получится не очень удобно.
(напоминать о ле--вых St-te мо--дах не буду - к вопросу о магии;)
Reply
Reply
Не напоминай. Мало того, что это не имеет никакого отношения к теме, так я еще и никак не претендую на то, что лучше тебя разбираюсь в монадах. И что вообще - в них разбираюсь. Так что есть целых два повода о них не упоминать.
Reply
Leave a comment