pshik, вы понимаете слова "Источник WBS"? Хорошо, так и запишем - ваши методы:

I. Поиск в интернете
K. Априорное знание - вы типа просто знаете и всё

pshikА вы хотите,чтобы я за вас нашёл и тут выложил?Не знаете - так зачем пытаетесь отвечать?

Нет тут стандарта.Ошибаетесь, стандарты есть.

Ишите то,что вам больше подойдёт
Это не ответ на вопросы "есть ли какой-то единый принцип ... или хотя бы какой-то конкретный набор подходов? Откуда берутся 1-2-й уровни?", а какие-то ваши домыслы относительно целей моих вопросов. Откуда вы знаете, может я материал для статьи собираю.

pshik Нет тут стандарта.Ошибаетесь, стандарты есть.

Да нет их.
Есть рекомендации к управлению проектами,которые не есть стандарт.Если вы читали ветку, там товарищ shelsoft приводил конкретные выдержки из ГОСТ Р ИСО/МЭК 12207-99, откуда виден конкретный достаточно широкий перечень процессов организации-разработчика, опираясь на которые вполне можно строить планирование конкретного проекта - другое дело, насколько такой подход будет удобен для задач проектного менеджмента.

Так_забежал_простоМожет, я чего-то не понимаю, но, ИМХО, исходный вопрос слишком абстрактный и автором делается попытка заменить процесс мышления готовым алгоритмом действий.История научной и инженерной деятельности как таковых, например, представляют собой процессы выявления, систематизации и выработки методов. С тем же успехом можно объявить попытку формализации бизнес-процессов "отказом от процесса мышления исполнителем процесса".

Ну да, чего-то там часто не учитывается при планировании проекта. Наверное, если из-за этого возникают какие-то конкретные проблемы, это что-то надо как-то учитывать. Как учитывать? Зависит от задачи, что именно хочется учитывать и зачем. Если нет и не предвидится никаких проблем - не надо учитывать ничего лишнего.Речь идёт о том, что будучи архитектором системы и достаточно хорошо представляя себе устройство системы, а также требования к ней, я был поставлен в роль менеджера проекта. В этой роли я попытался определить набор работ, необходимых для создания и внедрения системы, однако довольно быстро оказалось, что понимания устройства системы и требований к ней мало, чтобы сформировать достаточно полный состав работ.

Я начал размышлять о проблеме формирования WBS, задавать вопросы на сайтах, смотреть материалы и стандарты, проводить аналогии с Проектами вообще, не только софтверными. Выяснилось, что многие разработчики вообще не задумывались на эту тему, т.к. либо не попадали в такую ситуацию, либо работали по "образцу". Кстати, работа "по образцу" очень похожа на классическую методику разработки "code & fix" - т.е. берём некий состав работ по похожему проекту, а потом, если что-то не срослось, допиливаем его.

В то же время менеджеры проектов в основном либо имеют достаточно чёткое представление о своих методах проектирования WBS, либо ссылаются на ad-hoc-проектирование, как вы, особенно напирая на любимый тезис "управление проектами - это искусство, а не наука", что я в целом как инженер считаю неконструктивным.

В общем, это напоминает вопрос "Есть ли универсальная ERP-система? Если нет, то какие они бывают?" Правильный ответ на него такой: "А что Вам от этой системы надо?" А иначе получается обсуждение сферического коня в вакууме, ей-богу.Имхо, нормальный аналитическо-исследовательский цикл, и вопросы уместные, когнитивные.

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

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

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

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

В конкретной описанной ситуации, на мой взгляд, произошла неверная идентификация цели: целью проекта было названо создание программной системы вместо внедрения программной системы. Отсюда и вылазят лишние работы, не связанные с формально зафиксированным результатом.Собственно, я сейчас прихожу к тому, что ошибочной была попытка понимать под результатом некий НАБОР сконфигурированных взаимоувязанных ОБЪЕКТОВ (ПО, аппаратура, документация, инструкции), статику, а не ПРОЦЕСС ЭФФЕКТИВНОГО ПРИМЕНЕНИЯ системы для её целей, который позволяет более полно проработать необходимые условия выполнения процесса, и, следовательно, соответствующих работ.

Теперь осталось только описать такой подход как метод, раскрыть на примерах и пояснить преимущества - отдельной статьёй.