Границы применения
Тут, на мой взгляд, все ограничено рамками листа. Пусть это будет даже лист формата А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?
Со статьёй пока не знаю, надо апробировать, погонять разными людьми. Я пока в другую сторону ушёл, благодаря конференции.