Как стать автором
Обновить

Комментарии 16

Что, правда можно управлять воркшопом, на который явилось 25 человек? Да ещё из государственной организации (как подсказывает нам пример из второго абзаца)?
Всё зависит от уровня организации: если участники проинструктированы и подготовлены и у координатора есть опыт проведения подобных митингов, проблем возникнуть не должно. Школьным учителям удается справиться примерно с тем же количеством детей, почему бы не скоординировать 25 взрослых людей? :)
25 взрослых людей, специально собранных для того, чтобы они высказывали собственные мнения — это не дети, это гораздо хуже.

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

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

Но во вводной части сказано:
Представим себе создание информационной системы для государственной организации. У такой организации, как правило, сложная иерархическая структура со множеством подразделений.

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

Вы только подумайте — 24 не самых низкооплачиваемых человека сидят и слушают по кругу, как их коллега пытается что-то сформулировать.

Это очень дорого, лучше разбить их на команды по 3 человека хотя бы, что повышает производительность почти в 8 раз.
Асболютно согласен — people issues самая больная тема сбора требований. Но этот вопрос уже совсем не про воркшопы. Он более глобальный, и на него нет единого ответа или какой-то серебряной пули, все зависит от проекта, команды, ваших отношений с заказчиком и других факторов.
Моя практика показывает, что много людей вообще не понимают, что хотят. Тут ему воркшопом никак не поможешь и если от заказачика пришло семь человека, то 1-2 понимают зачем они здесь в лучшем случае)
Совершенно верно, большинство людей не понимает, чего они хотят. Однако задача аналитика как раз и состоит в том, чтобы выделить из обрывочных мыслей и идей общую картину требований к конечному продукту. В организации воркшопа очень важна подготовительная работа, — выявить и привлечь релевантных лиц, заинтересованных в продукте и способных принимать решения касательно его функционала. Надеяться, что на воркшоп все придут подготовленными без предварительных усилий как минимум недальновидно ;)
А это теория или практика?
Это практическое руководство.
А кто автор? На основе какого опыта?
Есть метод «quality attribute workshop», разработанный SEI/CMU (http://www.sei.cmu.edu/architecture/tools/establish/qaw.cfm), в котором процесс выявления и ранжирования требований основан на анализе use cases.
QAW и воркшоп из статьи очень похожи. Основная разница в целях — QAW только про качественные характеристики продукта (т.е. нефункциональные требования), воркшоп из статьи — про все типы требований (функциональные, нефункциональные, ограничения). Из-за разницы в целях немного отличаются процесс и вопросы к участникам.
Сложилось впечатление, что автор хороший теоретик, но совсем никакой практик. Предлагаю автору книгу написать.
Требования — «собрать», а не разработать??? Святая простота. «систему с… бизнес-процессами» — ой-вей, Карл, у них несколько бизнес-процессов в одной системе, а не наоборот. Хочу туда!
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.