Форум Сообщества Аналитиков
Дисциплины => Обучение => Конференции Семинары и Тренинги => Тема начата: Denis Beskov от 23 Марта 2007, 11:26:45
-
29 марта, в 7 часов вечера
UML2.ru (http://uml2.ru) при поддержке компании Luxoft (http://luxoft.com) проводит семинар на тему
"Разработка требований и состава работ - Холистический подход"
Многие начинающие, и не только, аналитики и менеджеры становятся в тупик при попытках описать требования и спланировать работу по созданию системы, в лучшем случае опираясь лишь на примеры работ по другим проектам.
Традиционные и достаточно современные подходы к определению требований к системе и состава работ, изложенные в BABOK, PMBOK, SWEBOK и специализированной литературе (Вигерс, Коберн, Лефингвел), несмотря не свои очевидные достижения, не предлагают метода формирования целостного и взаимоувязанного представления о создаваемой системе, и следовательно, требований к её внешним и внутренним свойствам, а также работ, необходимых для её создания, и, что исключительно важно, эффективной эксплуатации.
На семинаре будет предложен к рассмотрению и обсуждению простой и наглядный подход к формированию видения системы, основанный на едином сценарии использования системы с элементами деревьев решений, ментальных карт, и каузальных диаграмм.
Будут описаны особенности применения данного метода, даны рекомендации по использованию инструментов, приведены практические примеры.
Чтобы попасть на семинар, пришлите свои ФИО на rq_workshop (o) beskov.ru
Адрес проведения семинара: метро Октябрьское Поле, 1-й волоколамский проезд, д.10 строение 3 (http://maps.yandex.ru/moscow?upoint=d2631c04f365)
Путь от метро: первый вагон из центра, выход по подземному переходу направо, потом сразу налево, далее проходите около 50 метров вперед на остановку 105 и 800. Вам необходимы автобусы NN 105, 800, следующие до остановки "1-й Волоколамские проезд". Автобус останавливается напротив первой проходной.
Либо пешком от метро, идти минут 10.
-
обязательно буду
-
Буду на семинаре
-
Я буду
-
Ребята, кто будет, можете потом составить отчет по результатам конференции. Очень хотелось бы их увидеть.
-
Эд, обязательно
-
Вот думаю тоже быть. Денис, ты будешь докладчиком?
-
Я
-
Денис, если можно в докладе остановись более подробно на том, почему "классические" подходы "не предлагают метода формирования целостного и взаимоувязанного представления о создаваемой системе". И каким на твой взгляд должно быть такое целостное предстваление (vision такого предстваления, требования к нему -- что оно должно показывать, описывать и т.п.).
-
"Почему не предлагают" - боюсь, этого пообещать не могу. Предположим, наука и промышленность не смогли до определённого момента предложить нечто недорогое и безопасное, позволяющее людям передвигаться с помощью мускульной тяги со скоростью от 10 до 30 км/ч. И тут некто изобретает велосипед. Так вот акцент внимания изобретателя будет на:
а) как оно работает в принципе
б) как заставить его работать
в) как его использовать, чему оно может помочь
г) какие границы применимости у изобретения
д) какие недостатки
Учитывая то, что времени у нас по определению немного, заниматься вопросами того, а почему до сих пор никто не изобрел велосипед или почему об этом мало кому известно - мне кажется малополезным :)
Про то, каким оно должно быть я в основном и буду показывать и рассказывать :)
-
Я не совсем это имел ввиду. Переформулирую -- в чем именно недостатки "классических" подходв, и в чем конкретно они выражаются.
-
Друзья, товарищи!
Как насчет аудио или видео документирования данного мероприятия?
Думаю было-бы интересно лекцию послушать тем, кто не может поучаствовать?
Кто как к идее относится? Есть ли возможность реализовать?
-
kidman,
Да, этот вопрос поднимался, если один человек будет, то удасться записать семинар на видео.
-
есть камера. могу притащить. Кто смонтирует фильм? + 2 кассеты как минимум нужны
-
Так в этом и есть основной вопрос, камера как я понимаю у многих есть, а вот времени .... Приноси, заснимем, если всем будет некогда, тогда выложим в сыром виде, разрезаную на куски.
-
Сырая лучше чем ничего:)
-
Публикую презентацию к семинару в форматах PowerPoint (http://www.microsoft.com/downloads/details.aspx?FamilyID=428d5727-43ab-4f24-90b7-a94784af71a4&displaylang=en) и OpenOffice Impress (http://www.i-rs.ru/article/articleview/430).
-
Пример целевого сценария и дерева требований и работ для "Интранет-библиотеки спортивно-методической информации" в форматах GIF, FreeMind (http://freemind.sourceforge.net/wiki/index.php/Main_Page) и MindManager (http://www.mindjet.com/eu/products/mindmanager_viewers/index.php?s=3).
-
Пример целевого сценария и дерева требований и работ для типовой Справочной корпоративной информационной системы.
-
Публикую презентацию к семинару в форматах PowerPoint (http://www.microsoft.com/downloads/details.aspx?FamilyID=428d5727-43ab-4f24-90b7-a94784af71a4&displaylang=en) и OpenOffice Impress (http://www.i-rs.ru/article/articleview/430).
ZIP файл вероятно битый. По крайней мере, все кроме прицепленного в этом сообщении, удачно распаковываются, а презентация ppt не хочет
-
Записали на видео, качество будет не супер, но как говориться чем богаты ....
Видео выложено будет чуть попозже.
-
Денис, отличный доклад, новые свежие идеи - это всегда супер.
Хотя многие придя на семинар, ожидали другого, и я в том числе, но мне понравилось. Интересно как ожидания других участников скорелировали с тем, что они получили?!
-
Жаль, что никто не поддержал мою идею выписать на доске все + и - такого подхода, или области применимости/не_приминимости.
Помогу Денису и напишу здесь:
Плюсы и область применения:
- Маленький (возможно средний) проект с небольшим кол-вом требований и аналитиков
- Хорошая наглядность (видна не противоречивость) и лекго/быстро можно набросать несколько 10ов требований
- Если есть куча муккулатуры, называемая ТЗ, то можно лекго вычленить требования и их структурировать
- Небольшая стоимость продукта (MindMap)
- Легкий импорт/экспорт в Excel/Word/Project
- Больщое кол-во разных доп. иконок, связей и т.д.
Минусы и область слабого применения:
- Не возможно управлять большим кол-вом требований
- Не поддерживается версионность
- Не возможно править одновременно несколькими участниками
- Не возможность синхронизирования с Excel/Word/Project, т.е. экспортнули в Проджект там что-то попроавили и обратно
- Нет шаблона (как например SRS, Vision, ГОСТ), по которому можно идти и выявлять требования
Дополняйте ....
-
Я нормально скачиваю и распаковываю презентацию с помощью 7-Zip (http://www.7-zip.org/ru/)
-
Денис, спасибо за семинар, было интересно. Хотя после рекламы "целостного подхода к описанию требований" ожидалось бОльшего. :)
Главный вопрос - позиционирование метода. Для кого он нужен, для кого подходит?
Мне кажется, это инструмент не столько аналитика, сколько PM'а/Product Manager'а, человека, который отвечает "за все". У него нет ресурсов или других возможностей использовать классические подходы к сбору требований (структуризация, формализация, утверждение) и организации проекта (RUP, ГОСТ, PMBoK), однако целостную картину видеть необходимо.
Это, кстати, вполне может быть вчерашний ведущий разработчик, который "вдруг" получил официальные обязанности по управлению продуктом.
Основной недостаток подхода, мне кажется, в том, что он совершенно не формален, целиком полагается на умение и желание человека находить варианты реализации. Если человек умеет и хочет - он по идее сам сможет нарисовать нечто подобное. А если не умеет или не хочет - то здесь метод не подскажет, что делать.
Мне видятся такие варианты развития метода:
- сделать шаблоны для типовых проектов. Ту же идею "универсального сайта-сервиса" можно изложить в виде шаблона. Вот мол, если вы хотите разработать сайт, и не знаете, как организовать работы, то вот вам заготовка (типа чеклист), который вы конкретизируете, детализируете.
- идеально, если из этих чеклистов можно было делать типовые же ТЗ на разработку, типовые планы графики проекта и т.п.
Получится хороший набор инструментов для любителей. :)
-
winrar не хочет распаковывать...
-
Жаль, что никто не поддержал мою идею выписать на доске все + и - такого подхода, или области применимости/не_приминимости.
Помогу Денису и напишу здесь:
...
Саша, я изначально говорил, что "метод", на мой взгляд, применим для небольших проектов, возможно - для средних.
Я изначально говорил, что рассматриваю только задачу формулирования первичного набора требований и работ, до baseline, управление требованиями не рассматриваю в принципе. Поэтому "минусы" из серии "нельзя управлять большим количеством требований", "отсутствие историчности", "нельзя синхронизировать ..." - не совсем уместны.
"Большое количество разных иконок", "небольшая стоимость продукта", "невозможно править нескольким участникам" - это свойства конкретного инструмента, а не метода. Я говорил про то, что этот метод не требователен к инструментарию - можно рисовать в бесплатном фримайнде, можно маркером на доске, можно мелом на асфальте :)
Если нужно править нескольким аналитикам одновременно, воспользуйтесь MindMeister (http://mindmeister.com/).
"Нет шаблона (как например SRS, Vision, ГОСТ), по которому можно идти и выявлять требования" - это типичная ошибка формулировки проблемы как отсутствия некоторого свойства одного из возможных решений имеющейся задачи. Шаблоны сами по себе - не самоценность, они нужны для чего-то (выявления требований в нашем случае). Если это что-то достижимо другими методами, то это не значит, что эти методы ущербны. Всё равно что предъявлять претензии автобусу, что у него нет пантографа. Обычно такие ошибки совершают приверженцы какого-либо продукта.
-
Денис, спасибо за семинар, было интересно. Хотя после рекламы "целостного подхода к описанию требований" ожидалось бОльшего. :)
Не знаю, возможно я не совсем правильно позиционировал семинар, как подсказывает Юра Булуй - по сути, я хотел поделиться некоторыми работающими для меня идеями, чтобы их развить, убедиться в ценности, осознать возможности и ограничения, популяризовать, дать в пользование начинающим.
Главный вопрос - позиционирование метода. Для кого он нужен, для кого подходит?
Тут всё просто - кому он будет полезен, тому и подходит.Мне кажется, это инструмент не столько аналитика, сколько PM'а/Product Manager'а, человека, который отвечает "за все". У него нет ресурсов или других возможностей использовать классические подходы к сбору требований (структуризация, формализация, утверждение) и организации проекта (RUP, ГОСТ, PMBoK), однако целостную картину видеть необходимо.
Я думаю, что в России сейчас и ещё долго будет нередкой ситуация, когда человек, выступающий в роли аналитика, в то же время "выступает за всё". Вот эту вот секуляризацию, специализацию в форме игры "я тестировщик, а ты аналитик, а она ПМ и пусть каждый занимается своим делом" могут себе позволить только большие компании в больших городах. А всё-таки очень большое число проектов делается в полукустарных, ZOHO-условиях, и меня заботит прежде всего эта аудитория.
Основной недостаток подхода, мне кажется, в том, что он совершенно не формален, целиком полагается на умение и желание человека находить варианты реализации. Если человек умеет и хочет - он по идее сам сможет нарисовать нечто подобное. А если не умеет или не хочет - то здесь метод не подскажет, что делать.
Метод создаёт инфраструктуру для мышления, является подспорьем для анализа. По поводу "совершенной" неформальности не соглашусь - я приводил в презентации пошаговую программу, как и что делать.
Мне видятся такие варианты развития метода:
- сделать шаблоны для типовых проектов. Ту же идею "универсального сайта-сервиса" можно изложить в виде шаблона. Вот мол, если вы хотите разработать сайт, и не знаете, как организовать работы, то вот вам заготовка (типа чеклист), который вы конкретизируете, детализируете. - идеально, если из этих чеклистов можно было делать типовые же ТЗ на разработку, типовые планы графики проекта и т.п.
Получится хороший набор инструментов для любителей. :)
Да, шаблоны для конкретной категории проектов/систем - это хорошо и полезно, хотя уже не про метод. Метод имхо хорош именно своей свободой, а шаблоны предоставляют типовую структуру, но и загоняют в рамки. Метод хорошо для инноваций, шаблоны - для конвейера.
-
winrar не хочет распаковывать...
Перезаливаю с простым зипованием.
-
Я изначально говорил, что рассматриваю только задачу формулирования первичного набора требований и работ, до baseline, управление требованиями не рассматриваю в принципе. Поэтому "минусы" из серии "нельзя управлять большим количеством требований", "отсутствие историчности", "нельзя синхронизировать ..." - не совсем уместны.
Ну низя так узко смотреть
"Большое количество разных иконок", "небольшая стоимость продукта", "невозможно править нескольким участникам" - это свойства конкретного инструмента, а не метода. Я говорил про то, что этот метод не требователен к инструментарию - можно рисовать в бесплатном фримайнде, можно маркером на доске, можно мелом на асфальте :)
Я что не видел, чтобы документы сейчас писались от руки ....
"Нет шаблона (как например SRS, Vision, ГОСТ), по которому можно идти и выявлять требования" - это типичная ошибка формулировки проблемы как отсутствия некоторого свойства одного из возможных решений имеющейся задачи. Шаблоны сами по себе - не самоценность, они нужны для чего-то (выявления требований в нашем случае). Если это что-то достижимо другими методами, то это не значит, что эти методы ущербны. Всё равно что предъявлять претензии автобусу, что у него нет пантографа. Обычно такие ошибки совершают приверженцы какого-либо продукта.
Я больше имел ввиду мысль emanaev
-
Если различать:
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.intuit.ru/department/se/compprog/5/) понимается построение набора разноаспектных моделей которые в совокупности якобы дают эффект целостности. На мой взгляд это часто приводит к ситуации "шести слепых мудрецов и слона".
Я же понимаю под "холистическим" метод, который позволяет в одной модели увидеть максимум значимых для текущей деятельности аспектов. Конкретно в рассматриваемом методе в качестве текущей деятельности выступает процесс формализации видения решения и формирования первичного набора требований и работ.
-
Если сузить вопрос, то он звучит так: чем отличается данный метод от методов, систематизированных и предложенных Архангельским (см http://www.improvement.ru (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 выложили видео (http://www.rit2007.ru/paper_view.html?id=1196) с аналогичным докладом, который я делал на конференции.
-
Современное, доработанное воплощение предложенного мной в 2007-м году подхода называется Impact Mapping и используется для определения состава релизов, опираясь на его цели: http://www.impactmapping.org/
-
Также по всей видимости сквозной сценарий деятельности получил своё воплощение в том же 2007-м году как AAARR metrics: http://startitup.co/guides/374/aarrr-startup-metrics