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

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

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

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

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

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

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

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

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

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

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

Сергей.Все просто.

Сначало по PMBOK задачи бьются по 80 часов. По нашему это две недели. Это будет первым уровнем.
Затем каждую задачу разворачивают на конкретные этапы.Какие задачи бьются? Никаких задач ещё нет. Я и спрашиваю - откуда они рождаются, из чего. В PMBOKе ничего про 80 часов не вижу.

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

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


А является ли выделение уровней Levels обязательным в иерархической структуре WBS?
Может быть главным принципиальным свойством WBS является древовидная его структура, а не наличие в нем еще и уровней?А может ли стол существовать без крышки? Стол ли это вообще?

AlexTheRaven МайевтикНе могу понять, есть ли какой-то единый принцип формирования иерархической структуры работ в проекте по созданию ПО и ИС, или хотя бы какой-то конкретный набор подходов.
Нет, да и зачем бы он нужен? "Единый" тождественно равно "навзязанный и неоптимальный". Планирование работы людей - достаточно творческая задача, готовых алгоритмов для её решения нет.Хорошо, не единый подход, но хотя бы Best Pratices для определённых классов систем и задач.

На самом деле есть жизненный цикл ИС.Результаты работы тоже есть, автоматизируемые процессы (новые или существующие) тоже есть, составные части системы тоже есть, и что теперь? Почему надо планировать именно на основе ЖЦ?

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

Анализ даёт "требования". В зависимости от важности требований проектируются "модули" системы, которые их реализуют. "Реальные компоненты" реализуются при сопоставлении "модулей" и важности реализуемых ими "задач". "Раунды тестирования" проводятся по мере реализации "реальных компонентов". "Части решения" внедряются по мере проведения "раундов тестирования".Саша, это ты мне сейчас объяснял? Зачем?

На каждом из этапов ЖЦ сначала есть задача - "сформировать в целом" а потом "взять часть целого и детализировать".

Хорошо, первый уровень - Дисциплины или Фазы ЖЦ, что на втором?

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

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

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

pshikА вы знаете,что такое deliverables в проектном менеджменте?

Когда вы их сформулируете,тогда и будет у вас структура WBS.

Фундамент
Стены
Окна
Крыша
Отделка....это всё эти самые deliverables.

А потом внутрь и детализируетеОк, назовём это объектами поставки. Но проблема неучёта инфраструктурных, маркетинговых, кадровых, финансовых и проч. работ всё равно остаётся.

pshikВы о чём?
Я о проектном управлении,а вы похоже о всей компании.
Это разные учёты и разные уровни сложности.

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

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

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

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

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

AlexTheRaven МайевтикРезультаты работы тоже есть, автоматизируемые процессы (новые или существующие) тоже есть, составные части системы тоже есть, и что теперь? Почему надо планировать именно на основе ЖЦ?Если планировать по-другому - значит, провалится либо план, либо ЖЦ.А что, ЖЦ - самоцель? В условиях повторяющегося процесса ЖЦ исключительно полезен, а если речь про инвестиционный проект?

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


Меня невозможность влиять на пользователей тоже не устраивает. А ещё не устраивает закон всемирного тяготения - в гололёд больно падать :) .Я не просто констатирую своё отношение, но и предлагаю подходы к разрешению такой ситуации - см. ответ выше.

shelsoft, и что, я разве спрашивал, какие есть стандарты на эту тему? ГОСТ 12207 я уже посмотрел. Вы бы сайт sql.ru тоже со всеми этими процессами разрабатывали? И где там маркетинговые задачи? И где исследования потребностей аудитории?

shelsoft ГОСТ 12207 я уже посмотрел ...
Это книжка Сутеева что ли. А прочитать сможете ? :-P. Тогда найдете описание "тесного сотрудничества бизнеса и IT" (Процесс заказа), возможность построения для выполняемых проектов "глобального сценария" или "обобщённого бизнес-процесса", описывающего желаемую ситуацию относительно создаваемого продукта" , а также "целостный, интегрированный подход с планированием "из одной точки" с "иерархической структурой работ в проекте по созданию ПО и ИС". Да, 12207 предлагает пакет процессов, но их взаимосвязь не целостна.

Назовём такой подход L (Life-cycle standard).

shelsoft2) "Вы бы сайт sql.ru тоже со всеми этими процессами разрабатывали?"
Есссественно !!! И разрабатываю (не sql.ru :-) ), поскольку "Описанная последовательность
предназначена для того, чтобы в проекте создания программного средства в ыбрать,
упорядочить, применить и повторить присущие проекту или подходящие для него
процессы, работы (виды деятельности) и задачи (задания) ".
12207 предалагает 2 основных метода адаптации процессов с точки зрения их набор:
1) сужение списка процессов за счёт исключения неприменимых, вырожденных процессов.
2) расширение списка процессов в зависимости от контекста проекта и предметной области.

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

Например, речь идёт о создании игрушки, сценарий эксплуатации (описание желаемой ситуации в динамике):
1. Игрушку приобретают.
2. Игрушкой играют.
3. Игрушку утилизируют.

Это значит, что:
1.1. Игрушку надо создать (подсистема и задачи производства).
1.2. Надо предоставить возможность приобрести игрушку (подсистема и задачи сбыта, ценообразования).
1.3. Надо заинтересовать в покупке (реклама, мерчандайзинг).

2.1. Игрушка должна быть интересна.
2.1.1. Нужно провести исследование и креатив образа игрушки (маркетинг, дизайн, прототипирование).
2.2. Игрушка должна быть безопасна для здоровья (ограничения проектирования).

3.1. Игрушка должна допускать утилизацию (ограничения проектирования).
3.2. Игрушка должна быть безопасна для природы (ограничения проектирования).

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

shelsoft"Но, о чём я говорю - он не даёт никаких рекомендаций, методик относительно того, откуда и как эти дополнительные процессы взять. А брать их можно, если построить обобщённый сценарий функционирования продукта, чего обычно не делается ."
...
Все логично. Поэтому я и просил сравнить первый этап в различных методологиях разработки ПО (MSF,RUP и т.д.).
Практически все содержат 1) Выявление требований 2) Уже собственно говоря планирование ...
Методики "вывода требований" я надеюсь обсуждать не будем (не помню термина "сценарии эксплуатации", как то ближе "Варианты использования", есть еще "Событие-реакция" и т.д.)
Прецеденты как форма записи функциональных требований - это мой рабочий инструмент. НО. Тут мне выпала доля выступать в роли ПМа и я увидел, что для планирования проекта не только с точки зрения объекта поставки, но и с точки зрения бизнес-использований мне их не хватает.

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

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

Если брать мой пример с игрушкой, то область применения прецедентов - это пункты, связанные с функциональными требованиями:
2.1.1. Нужно провести исследование и креатив образа игрушки (маркетинг, дизайн, прототипирование).
и
1.1. Игрушку надо создать (подсистема и задачи производства).

Перестаньте уже пожалуйста поминать RUP с МSF'ом, они не предлагают никаких механизвов выведения следующих работ и условий:

1.2. Надо предоставить возможность приобрести игрушку (подсистема и задачи сбыта, ценообразования).
1.3. Надо заинтересовать в покупке (реклама, мерчандайзинг).
2.1. Игрушка должна быть интересна.
2.1.1. Нужно провести исследование и креатив образа игрушки (маркетинг, дизайн, прототипирование).
2.2. Игрушка должна быть безопасна для здоровья (ограничения проектирования).
3.1. Игрушка должна допускать утилизацию (ограничения проектирования).
3.2. Игрушка должна быть безопасна для природы (ограничения проектирования).

Требования/условия 2.1-3.2. по RUP/MSF в лучшем случае берутся из уст заинтересованных лиц, если они об этом вспомнят, но в контексте именно процесса разработки ПО о пунктах 1.2.-1.3. традиционно не упоминают.

pshikНу в общем это делается так:

Проект разбивается на подпроекты, или по простому,проект SQL.ru
-дизайн
-разработка
-производство
-внедрениеСуть моего вопроса - по какому принципу разибвается проект. Откуда вы эти вот "дизайн, разработка и т.д." взяли?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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