Просмотр сообщений
2071
Конференции Семинары и Тренинги / Re: МСК - Семинар "Разработка требований и состава работ"
« : 05 Апреля 2007, 16:38:11 »
Саша, ещё раз напомню свои идеи, чтобы не было недопонимания.
Нужна методика быстрого формирования базовой версии требований, учитывающая, что для достижения бизнес-целей нужен не набор объектов поставки, а выстроенный и обеспеченный рабтающий бизнес-сценарий.
Традиционные подходы базируются на документах, шаблонах, списках, база данных требований. Среди прочих методик выявления требований называется мозговой штурм, но в нём обычно идеи отдельных людей группируются (кластеризуются) по принципу подобия, что делает результирующую полезной как классификация, но не дающей полной картины и не показывающей причинно-следственных зависимостей между тем, зачем данное свойство продукту нужно и как этого добиться.
Предложенный мной метод предназначен для:
1) Формирования и наглядной визуализации динамической модели желаемой ситуации (vision).
2) Выявления ключевых работ и требований, которые должны быть выполнены и удовлетворены для получения этой ситуации (baseline + wbs).
Причём предлагается сохранять в модели работ и требований предположения, альтернативы, идеи и т.д.
Полученную таким образом эскизную модель можно:
а) формализовывать дальше, раставляя метки категорий каждого узла (цель, бизнес-требование, задача, условие и т.д.)
б) использовать для дальнейшего уточнения и проработки деталей - "выращивать дерево";
в) использовать для формирования формальных отдельных наборов требований, задач и т.д. за счёт использования механизмов экспорта.
Когда я создавал этот метод, я имел в виду микрокоманды и микропроекты (1-2 человека, небольшой веб-сайт, небольшой старап), а также малые проекты (3-5 человек, небольшая система или внедрение, малый бизнес), в которых можно и нужно охватить всё одним взглядом, понимать все детали проекта, т.к. всё делать самим и результат достаточно критичен, поэтому нужно не забыть и не учесть как можно меньше требований, задач и прочих аспектов проекта.
Если этот метод может быть использован для средних и больших проектов - ну и слава богу.
Но тем не менее, для масштабных проектов, из твоих слов не очень понял, почему применяемый ТОБОЙ подход требует высокой степени доверия.
Я процесс не строил, да и по словам наших экспертов при таких масштабах (1-5 человек) "построение процесса" как такового не имеет смысла.
Нужна методика быстрого формирования базовой версии требований, учитывающая, что для достижения бизнес-целей нужен не набор объектов поставки, а выстроенный и обеспеченный рабтающий бизнес-сценарий.
Традиционные подходы базируются на документах, шаблонах, списках, база данных требований. Среди прочих методик выявления требований называется мозговой штурм, но в нём обычно идеи отдельных людей группируются (кластеризуются) по принципу подобия, что делает результирующую полезной как классификация, но не дающей полной картины и не показывающей причинно-следственных зависимостей между тем, зачем данное свойство продукту нужно и как этого добиться.
Предложенный мной метод предназначен для:
1) Формирования и наглядной визуализации динамической модели желаемой ситуации (vision).
2) Выявления ключевых работ и требований, которые должны быть выполнены и удовлетворены для получения этой ситуации (baseline + wbs).
Причём предлагается сохранять в модели работ и требований предположения, альтернативы, идеи и т.д.
Полученную таким образом эскизную модель можно:
а) формализовывать дальше, раставляя метки категорий каждого узла (цель, бизнес-требование, задача, условие и т.д.)
б) использовать для дальнейшего уточнения и проработки деталей - "выращивать дерево";
в) использовать для формирования формальных отдельных наборов требований, задач и т.д. за счёт использования механизмов экспорта.
Когда я создавал этот метод, я имел в виду микрокоманды и микропроекты (1-2 человека, небольшой веб-сайт, небольшой старап), а также малые проекты (3-5 человек, небольшая система или внедрение, малый бизнес), в которых можно и нужно охватить всё одним взглядом, понимать все детали проекта, т.к. всё делать самим и результат достаточно критичен, поэтому нужно не забыть и не учесть как можно меньше требований, задач и прочих аспектов проекта.
Если этот метод может быть использован для средних и больших проектов - ну и слава богу.
Но тем не менее, для масштабных проектов, из твоих слов не очень понял, почему применяемый ТОБОЙ подход требует высокой степени доверия.
Я процесс не строил, да и по словам наших экспертов при таких масштабах (1-5 человек) "построение процесса" как такового не имеет смысла.
