Сырая лучше чем ничего:)

Публикую презентацию к семинару в форматах PowerPoint и OpenOffice Impress.

Пример целевого сценария и дерева требований и работ для "Интранет-библиотеки спортивно-методической информации" в форматах GIF, FreeMind и MindManager.

Пример целевого сценария и дерева требований и работ для типовой Справочной корпоративной информационной системы.

Публикую презентацию к семинару в форматах PowerPoint и OpenOffice Impress.

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

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

Денис, отличный доклад, новые свежие идеи - это всегда супер.
Хотя многие придя на семинар, ожидали другого, и я в том числе, но мне понравилось. Интересно как ожидания других участников скорелировали с тем, что они получили?!

Жаль, что никто не поддержал мою идею выписать на доске все + и - такого подхода, или области применимости/не_приминимости.

Помогу Денису и напишу здесь:

Плюсы и область применения:

• Маленький (возможно средний) проект с небольшим кол-вом требований и аналитиков
• Хорошая наглядность (видна не противоречивость) и лекго/быстро можно набросать несколько 10ов требований
• Если есть куча муккулатуры, называемая ТЗ, то можно лекго вычленить требования и их структурировать
• Небольшая стоимость продукта (MindMap)
• Легкий импорт/экспорт в Excel/Word/Project
• Больщое кол-во разных доп. иконок, связей и т.д.

Минусы и область слабого применения:

• Не возможно управлять большим кол-вом требований
• Не поддерживается версионность
• Не возможно править одновременно несколькими участниками
• Не возможность синхронизирования с Excel/Word/Project, т.е. экспортнули в Проджект там что-то попроавили и обратно
• Нет шаблона (как например SRS, Vision, ГОСТ), по которому можно идти и выявлять требования

Дополняйте ....

Я нормально скачиваю и распаковываю презентацию с помощью 7-Zip

Денис, спасибо за семинар, было интересно. Хотя после рекламы "целостного подхода к описанию требований" ожидалось бОльшего.

Главный вопрос - позиционирование метода. Для кого он нужен, для кого подходит?
Мне кажется, это инструмент не столько аналитика, сколько PM'а/Product Manager'а, человека, который отвечает "за все". У него нет ресурсов или других возможностей использовать классические подходы к сбору требований (структуризация, формализация, утверждение) и организации проекта (RUP, ГОСТ, PMBoK), однако целостную картину видеть необходимо.
Это, кстати, вполне может быть вчерашний ведущий разработчик, который "вдруг" получил официальные обязанности по управлению продуктом.

Основной недостаток подхода, мне кажется, в том, что он совершенно не формален, целиком полагается на умение и желание человека находить варианты реализации. Если человек умеет и хочет - он по идее сам сможет нарисовать нечто подобное. А если не умеет или не хочет - то здесь метод не подскажет, что делать.

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

Получится хороший набор инструментов для любителей. 

winrar не хочет распаковывать...

Жаль, что никто не поддержал мою идею выписать на доске все + и - такого подхода, или области применимости/не_приминимости.

Помогу Денису и напишу здесь:
...

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

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

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

Если нужно править нескольким аналитикам одновременно, воспользуйтесь MindMeister.

"Нет шаблона (как например SRS, Vision, ГОСТ), по которому можно идти и выявлять требования" - это типичная ошибка формулировки проблемы как отсутствия некоторого свойства одного из возможных решений имеющейся задачи. Шаблоны сами по себе - не самоценность, они нужны для чего-то (выявления требований в нашем случае). Если это что-то достижимо другими методами, то это не значит, что эти методы ущербны. Всё равно что предъявлять претензии автобусу, что у него нет пантографа. Обычно такие ошибки совершают приверженцы какого-либо продукта.

Денис, спасибо за семинар, было интересно. Хотя после рекламы "целостного подхода к описанию требований" ожидалось бОльшего.

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

Главный вопрос - позиционирование метода. Для кого он нужен, для кого подходит?

Тут всё просто - кому он будет полезен,  тому и подходит.

Мне кажется, это инструмент не столько аналитика, сколько PM'а/Product Manager'а, человека, который отвечает "за все". У него нет ресурсов или других возможностей использовать классические подходы к сбору требований (структуризация, формализация, утверждение) и организации проекта (RUP, ГОСТ, PMBoK), однако целостную картину видеть необходимо.

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

Основной недостаток подхода, мне кажется, в том, что он совершенно не формален, целиком полагается на умение и желание человека находить варианты реализации. Если человек умеет и хочет - он по идее сам сможет нарисовать нечто подобное. А если не умеет или не хочет - то здесь метод не подскажет, что делать.

Метод создаёт инфраструктуру для мышления, является подспорьем для анализа. По поводу "совершенной" неформальности не соглашусь - я приводил в презентации пошаговую программу, как и что делать.

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

Получится хороший набор инструментов для любителей. 

Да, шаблоны для конкретной категории проектов/систем - это хорошо и полезно, хотя уже не про метод. Метод имхо хорош именно своей свободой, а шаблоны предоставляют типовую структуру, но и загоняют в рамки. Метод хорошо для инноваций, шаблоны - для конвейера.

winrar не хочет распаковывать...

Перезаливаю с простым зипованием.

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

Ну низя так узко смотреть

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

Я что не видел, чтобы документы сейчас писались от руки ....

"Нет шаблона (как например SRS, Vision, ГОСТ), по которому можно идти и выявлять требования" - это типичная ошибка формулировки проблемы как отсутствия некоторого свойства одного из возможных решений имеющейся задачи. Шаблоны сами по себе - не самоценность, они нужны для чего-то (выявления требований в нашем случае). Если это что-то достижимо другими методами, то это не значит, что эти методы ущербны. Всё равно что предъявлять претензии автобусу, что у него нет пантографа. Обычно такие ошибки совершают приверженцы какого-либо продукта.

Я больше имел ввиду мысль emanaev