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

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

Пока обнаружил следующие подходы с использованием источников:

A. Аналогичный проект, выполненный ранее, в качестве шаблона.

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

D. Дисциплины - в качестве первого уровня выступают "Менеджмент", "Бизнес-анализ", "Требования", "Проектирование", "Реализация", "Тестирование", "Документирование" и т.д.

F. Функции - система описана в виде набора функций. Похоже на B, но привязка не к бизнес-сегментам и бизнес-процессам, а бизнес/техническим функциям.

R. Дерево требований - похоже на B и F, только есть уже готовые 3-4 уровня требований, под которые осталось подложить задачи.

T. Технические компоненты (Интерфейс, Бизнес-логика, БД, подсистема интеграции, ...) - аналогично B, но техноцентрично.

U. Пользовательские истории (user stories), прецеденты (use-cases) - является по сути развитием F.

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

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

Например, если вы будете считать, что в результате проекта по созданию сайта вам нужны следующие объекты поставки:
1) сам сайт;
2) какая-то документация к нему.
и будете строить весь проект исходя из получения такого результата, то вы легко можете придти к ситуации, когда заказчику будет передана CD-болванка с установленной и настроенной под проект CMS-системой и какой-то документацией. Формально результаты получены, но оказывается, что сайт:
1) не развёрнут на домене,
2) не наполнен контентом, или
3) он есть, но он не посещается, или он экстремально неудобен и т.д. и т.п. -
т.е. "не работает" не с точки зрения техники, а с точки зрения бизнеса, как некоторый инструмент.

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

На мой взгляд возможно свести воедино весь комплекс работ по созданию работающей с точки зрения бизнеса системы, если использовать нечто вроде "глобального сценария" или "обобщённого бизнес-процесса", описывающего желаемую ситуацию относительно создаваемого продукта. Для многих проектов по созданию массовых веб-приложений, таким сценарием, на мой взгляд, мог бы быть следующий:
П. Пользователь приходит на сайт
Н. Пользователь получает нужное
Д. Пользователь остаётся довольным
Р. Пользователь рекомендует сайт знакомым
В. Пользователь возвращается на сайт

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

П. Пользователь приходит на сайт
Н. Пользователь получает нужное
Д. Пользователь остаётся довольным
Р. Пользователь рекомендует сайт знакомым
В. Пользователь возвращается на сайт

Не понятно как оценить п. Д и Р. А выполняться п. Р и В, если достигнуты п. Н и Д. Так что критерии не понятны.

С другой стороны согласен, что идти тупо от поставки - это не правильно. Надо все таки идти от бизнес целей Заказчика.

Не понятно как оценить п. Д и Р. А выполняться п. Р и В, если достигнуты п. Н и Д. Так что критерии не понятны.

С другой стороны согласен, что идти тупо от поставки - это не правильно. Надо все таки идти от бизнес целей Заказчика.

Что заначит оценить? Убедиться в выполнении? Ну тут скорее речь о проектировании как минимум необходимых подзадач и их вариаций для выполнения каждого условия, а не достаточных. С достаточным игораздо сложнее. "Пользователь рекомендует" проверяется самим фактом, как мы это будем проверять - зависит от проекта. Возможно, для того, чтобы пользователь мог порекомендовать сайт, надо также предусмотреть на нём функционал "отправить ссылку другу" или даже "пригласить друга в систему" и вопрос проверки выполнимости условия решается сам собой.

Р. Пользователь не обязательно рекомендует сайт, если он Нашёл и остался Доволен. Скажем, я могу найти и остаться довольным Поиском Рамблера, но я привык пользоваться Яндексом и если что, буду его возможно рекомендовать.

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

Думаю что нужно достаточно четко отделять бизнес-идеи от технической реализации и юзабилити. Софт может быть создан для удовлетворения неких потребностей в нем. Для этого могут написать ТЭО или  сформулируют в бизнес-требованиях ПОЧЕМУ делается система, какие бизнес-цели должны быть достигнуты, какие критерии достижения и т.п. ... при этом а) сами бизнес-цели могут быть "неудачными" с т.з. бизнеса, и даже самый хороший софт не исправит ситуацию б) бизнес-идея  и требования хорошие, но инженеры "не справились" -- это другая ситуация. При варианте "а" -- инженеры не причем, а при варианте "б" -- очень даже причем, и тут очевидно нужно анализировать почему -- то ли бизнес-заказчики "не донесли" идею до инженеров, толи инженеры искренне не поняли что от них хотят, то ли просто использовали неадекватные технологии/методологии в конце концов ресурсы и т.п. ...

Итог будет подведен?

WBS он и есть WBS - структура работ по проекту. И составляется он так чтобы учесть все работы которые нужно выполнить от постановки задачи до поставки результата. Чем точнее и мельче его написать тем легче будет управлять и отслеживать. В идеале задачи с продолжительностью в 1 день.

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

Т.е. это просто карта помощь. Для создания сайтов наверное тоже есть типовые WBS - попробуй посмотреть в MS Project.

И составляется он так чтобы учесть все работы которые нужно выполнить от постановки задачи до поставки результата.

Фраза из серии "Делайте то, что нужно делать, а то, что не нужно делать - не делайте".

Как учесть все работы? Откуда эти работы брать? Что понимается под формлировкой "постановка задачи"?

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

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

У меня есть друг, который занимается научными проектами - работает в теме ЭРД. Он постоянно мониторит рынок проектов по своей тематике ищет работы на стороне. Одним из критериев подбора проекта является именно составление WBS. Он говорит, что берется за проект только в том случае, когда он приблизительно знает как за это взяться, какие шаги нужно предпринять для его выполнения.

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

Ну это же и есть описанный мной метод А.

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

Т.е. определить состав необходимых работ можно, если ты раньше делал похожие проекты. А если проект новый?

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

Кем включено, когда включено, что включено? Т.е. вы на позицию (роль) менеджера себя никогда не ставили, я правильно понмиаю?

"Разработчику не знать". Сейчас время стартапов. Есть три человека с хорошей идеей и мозгами (допустим, Галоген, Бас и Я). Кому из нас при определении работ по проекту незачем знать про маркетинг? Разработчик, который не работаёт наёмным работником в офисной клетке - это что, не разработчик?

У меня есть друг, который занимается научными проектами - работает в теме ЭРД. Он постоянно мониторит рынок проектов по своей тематике ищет работы на стороне. Одним из критериев подбора проекта является именно составление WBS. Он говорит, что берется за проект только в том случае, когда он приблизительно знает как за это взяться, какие шаги нужно предпринять для его выполнения.

Опять нечто из серии астрологии и "менеджмент - это искусство". Откуда появляется понимание того, что делать? Из астрала, как стихи? Из предыдущего опыта? Если человек делает только то, что делал раньше - то он всё время делает одно и то же?

Во-многих случаях "постановка" выгладит так - "создать эффективную систему такую-то". Как из этого получить задачи?

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

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

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

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

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

И вот как же агли в стартапах применяется без бизнесмена лидера ... это вопрос.

Вальсируя с медведями
"В начале, на заре ИТ-индустрии, обоснование для создания новых продуктов было очень простым. Системы, которые тогда устанавливали, обычно заменяли ручной труд клерков. Экономия трудозатрат и была мерилом выгоды, а затраты на разработку системы – издержками.

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

Когда стоимость проекта строго ограничена, а выгода обозначена самым туманным образом, с разработчиков требуют ответственности за затраты, а за выгоду не отвечает никто. Чаще всего происходит плохая реализация выгоды и тыканье пальцам наугад."

.. ушел в никуда, извиняюсь. Т.е. источник WBS это прежде всего здравый смысл и опыт индустрии. Формализовать же процесс можно - давай просто переведем его в RUP и будет тебе готовый вариант да еще разбитый по итерациям. Проект программный стандартный разворачивается по стандартным фазам. постановка задачи, проектирование, развертывание, анализ ..
ну и по создаваемым компонентам.

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

Как писал известный автор "каждому проекту своя методология", видимо и подход с WBS и источниками где-то на том же уровне

Вот решил и сюда свои пять копеек вставить :-)
Безусловно опыт индустрии это супер полезная штука.

Но готов согласится с Автором

Как писал известный автор "каждому проекту своя методология", видимо и подход с WBS и источниками где-то на том же уровне

От Методологии зависит метод управления , а от него в свою очередь план (План это просто инструмент управления

Т.е. прямого ответа на твой вопрос Денис не существует.
Но в основном для Софта Используется три подхода:
1. Классический аля MSF 1.0 (Издеваюсь, на самом деле они ближе к пункту 2) - До завершения формирования Архитектуры планируемс :-)
2. Двух уровневое планирование, Проект разбивается на фазы, каждая фаза имеет свои результаты и в соответсвии с ними и планируем каждую фазу. В дополнение к нему неплохо подкатывается Rolling Wave Planning
3. Agile

Еще полезно ковырнуть разницу между PWS и WBS - некоторые вопросы сразу проясняются.
На самом деле у PMI в свое время был отдельный стандарт на формирование WBS :-) Но он совсем старенький.

p.s.  Делал тренинг так еле в 8 ч вещания с небольшой практикой  уложился :-)

С уважением Дмитрий ;-)

p.s.  Делал тренинг так еле в 8 ч вещания с небольшой практикой  уложился :-)

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