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

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

К огромному моему сожалению, присутствовать не смог, хотя семинар проводился в 100 м от моей работы...
Идея простоты - замечательная. Мы уже используем что-то наподобие, принимая что:
- есть потребность: за её удовлетворение готовы заплатить деньги
- есть решение (проект) - человеко-машинная система, пособная удовлетворить эту потребность
- есть... даже не функции или UC, а "фичи" решения, описания того, что же оно должно делать - максимум штук 20-30, можно написать в whitepaper или своём резюме
- есть итерации (спринты) - на одной занимаемся одними фичами, на другой - другими, но после каждой имеем готовое решение, удовлетворяющее часть потребности
- есть задачи - каждая по "фиче", за каждую есть ответственный
- есть работы по выполнению этой задачи, и связанные с ними оценки, а сколько же осталось затратить времени.
Всё это ведётся в довольно простой самодельной системке моего производства .
У нас всё это не исключает детальных вариантов использования, трассированных со статическими и динамическими единицами, относящимися к реализации.

Но в таком упрощении я вижу следующие проблемы:
1) Необходима высокая степень доверия между заказчиком и разработчиком; в случае масштабного проекта на тендерной основе это может вызвать очень большие риски, на которые мало кто пойдёт.
2) Требований меньше не становится, просто проектная команда концентрируется на ключевых, считая, что остальные "сами собой разумеются". Но для разных людей "сами собой разумеются" разные вещи. Опять же, когда в команду вливается новый сотрудник - очень многое приходится рассказывать ему лично.
3) Требованиями в настолько широком плане может заниматься не меньше чем product/project manager, к-рый одновременно заведует маркетингом, разработкой и внедрением. Остальные за деревьями не видят леса. А product/project manager за лесом может не видеть деревьев, и создать требования, по которым трудно будет делать задачи...
4) Граница компетентности такого процесса - порядка 20 сотрудников на создание решения. Каждый такой сотрудник знает всех других и может лично взаимодействовать с ними напрямую.

Саша, ещё раз напомню свои идеи, чтобы не было недопонимания.

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

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

Предложенный мной метод предназначен для:
1) Формирования и наглядной визуализации динамической модели желаемой ситуации (vision).
2) Выявления ключевых работ и требований, которые должны быть выполнены и удовлетворены для получения этой ситуации (baseline + wbs).

Причём предлагается сохранять в модели работ и требований предположения, альтернативы, идеи и т.д.

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

Когда я создавал этот метод, я имел в виду микрокоманды и микропроекты (1-2 человека, небольшой веб-сайт, небольшой старап), а также малые проекты (3-5 человек, небольшая система или внедрение, малый бизнес), в которых можно и нужно охватить всё одним взглядом, понимать все детали проекта, т.к. всё делать самим и результат достаточно критичен, поэтому нужно не забыть и не учесть как можно меньше требований, задач и прочих аспектов проекта.

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

Но тем не менее, для масштабных проектов, из твоих слов не очень понял, почему применяемый ТОБОЙ подход требует высокой степени доверия.

Я процесс не строил, да и по словам наших экспертов при таких масштабах (1-5 человек) "построение процесса" как такового не имеет смысла.

<...>
Но тем не менее, для масштабных проектов, из твоих слов не очень понял, почему применяемый ТОБОЙ подход требует высокой степени доверия.<...>

IMHO чем меньше доверия - тем более полным (а значит, более формальным и детализированным) должен быть набор требований. А теперь представь себе внешнего заказчика, к-рый подписывается под ТЗ из 30 "фич"... Да иной ПМ программисту отдельную задачу длительностью в полдня детальнее ставит!

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

Если ты смотрел презентацию, то там упоминаются авторы и стандарты, так или иначе формулирующие какие-то рекомендации относительно построения образа системы, методик определения её требуемых свойств, а также действий, которые надо предпринять для получения этих свойств - Вигерс, Лефингвелл, ГОСТ 34, PMBOK, SWEBOK, BABOK.

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

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

Если сузить вопрос, то он звучит так: чем отличается данный метод от методов, систематизированных и предложенных Архангельским (см http://www.improvement.ru), направленных на создание быстрого обзора проблемы, структурирование внимания, стратегическое и тактическое планирование?

Давай по очереди.

"Быстрый обзор проблемы".
Я в своём методе исхожу из ситуации, когда у проектной команды (Заказчика, Инициатора, Изобретателя) уже есть смутное видение того, что нужно получить и предлагаю метод формализации этого видения для дальнейшей работы, выбивающий из ступора. Так вот, в моём понимании, наличие видения - это ситуация, которая наступает уже ПОСЛЕ обнаружения, рассмотрения и описания проблемы, т.е. "Быстрый обзор проблемы" находится ЗА РАМКАМИ метода, может быть использован до него.

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

"Стратегическое и тактическое планирование"
Опять же, я воспринимаю термин "планирование" (развёртывание на плоскость) как процесс распределения ТОГО, ЧТО НУЖНО СДЕЛАТЬ, ВО ВРЕМЕНИ. Т.е. Это тоже за рамками метода, т.к. его фокус на том, а ЧТО ЖЕ НУЖНО СДЕЛАТЬ, а не в каком порядке.

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

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

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

Новизна
- Идея ЖЦ продукта на сегодняшний день является хрестоматийной категорией.
- Дерево целей в различных вариациях на сегодня тоже является одним из хрестоматийных инструментов инженера и менеджера.
- Идея о том, что источником требований будет весь ЖЦ продукта (а не один маленький его компонент) явно или неявно применяется на практике всеми инженерами очень давно. Возможно, в ИТ (в силу молодости) не так давно, но любое (к примеру) машиностроительное изделие проектируется с учетом всего: от изготовления, доставки, монтажа...через эксплуатацию, ремонт и модернизацию ...до утилизации.
- Технология mindmap описана в литературе и применяется давно.
- Идея о том, что требования трассируются из элементов объекта автоматизации (автоматизируемых процессов), а конкретные работы проекта могут разбиваться в соответствие с разбиением на функции/фичи/модули применяется в управлении проектами.

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

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

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

Вот ты пишешь, что "источником требований является весь ЖЦ продукта" - неужели тебе действительно это давали как методику выявления требований на твоей кафедре? Нам, насколько я помнию, нет. Да, про ЖЦ конечно рассказывали, но как именно, на основании чего создавать продукт (в нашем случае - САПР) - нет. Поэтому считай что я закрываю этим методом дыру своей собственной безграмотности и заодно предоставляю реалистичный, как я надеюсь, инструмент тем, кто не получил или не получает ВО.

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

Ещё раз - серьёзным проектам - серьёзные методы.

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

Во-первых, я не пытался объять необъятное, я искал то, с помощью чего можно выработать Vision (requirements baseline) и связать его с задачами, определив их.

Что нужно для того, чтобы построить план работ?
1. Определить состав работ.
2. Определить взаимосвязи работ.
3. Определить ограничения длительности работ.
4. Определить трудоёмкости работ.
5. Назначить ресурсы.
6. Перераспределить и соптимизировать сетевой график, выделив критический путь.

Я сконцентрировался на 1. И только. Потому что пока нет состава работ, всё остальное бессмысленно и от качества этого 1 зависит многое.

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

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

В-третьих, MindManager прекрасно импортирует и экспортирует в MS Project, никто не мешает выгрузить MindMap в Project, выполнить там пункты 2-6, и загрузить обратно.

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

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

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

Я специально оговорил в слайде, что процессы Управления требованиями не рассматривается, речь идёт только о фазе инициации проекта, а не его ходе.

И последний вопрос: сколько стоит проект (как карта на него отвечает)?
И еще много других вопросов...

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

Ты можешь дать конкретную ссылку на статью Архангельского с mindmap?

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

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

По следам былых сражений :-)

Довелось недавно побывать на курсе по управлению проектами с помощью MS Project, преподавателем которого выступал Андрей Леонидович Зайцев  (http://www.cmcons.com/we/personalii.htm#zaytsev ). Так первоначальный состав работ (WBS) и связи между работами он предлагал рисовать в виде майнд-мепа, а дальше генерить разнообразные презентационные материалы (Word, PowerPoint) и импортировать перечень работ и связи между ними в MS Project. Сам майнд-меп рисовался в MindJet MindManager. И такой способ работы он рекомендовал для работы над проектом любых размеров. (это я привожу как пример апробации).

Организаторы РИТ-2007 выложили видео с аналогичным докладом, который я делал на конференции.

Современное, доработанное воплощение предложенного мной в 2007-м году подхода называется Impact Mapping и используется для определения состава релизов, опираясь на его цели: http://www.impactmapping.org/

Также по всей видимости сквозной сценарий деятельности получил своё воплощение в том же 2007-м году как AAARR metrics: http://startitup.co/guides/374/aarrr-startup-metrics