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