Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 27
Текст из файла (страница 27)
Например, группы могут иметь следующие названия. ° Новыефункции ° Вопросы производительности ° Предложения по усовершенствованию существующих функций ° Интерфейс пользователя и вопросы простоты обращения Группы могут быть специально ориентированы на возможности системы и способы поддержки различных типов пользователей. Например, при создании новой службы перевозки и доставки функции могут быть сгруппированы следующим образом. ° Упаковка и адресация ° Обслуживание клиента ° Маркетинг и продажи ° Услуги, основанные иа 1з'еЬ ° Выставление счета ° Управление транспортировкой Для любой из этих групп можно возобновить генерацию идей, если окажется, что процесс группировки стимулировал возникновение новых идей или некоторая область важных функциональных возможностей осталась неохваченной.
Определение функций В этот момент человеку, предложившему идею, нужно предоставить возможность дать ее краткое описание. Это позволит ему более подробно описать функцию и поможет удостовериться, что участники понимают ее одинаково. Кроме того, это позволит избежать грубых ошибок в процессе определений приоритетов. Итак, ведущий называет все идеи, оставшиеся в списке, и просит авторов дать их описание, состоящее из одного предложения.
Глава 11. Мозговой штурм и отбор идей 133 Область примене- Штурмуемая Описание функции ния приложения функция Домовладелец может предварительно задавать основанные на времени последоэателызости воз- никновения опрелеленных осветительных сабы- тий в зависимости от времени дня Достаточно быстрое время ответа, чтобы ие ме- шать проведению обычных операций Все зарегистрированные стороны будут уведоиле. ны посредством электронной почты, когда что. нибудь изменится "Автоматическое Автоматизация домашнего освещения задание освещения" "Быстрота" Система ввоза заказов иа покупку Система обнаружения неполадок "Автоматическое уведомление" Функция сварочною робота, такая как "автоматическая повторная сварка," может считаться достаточно описанной и не требует дальнейших обаясненнй. Важно не увязнуть в этом процессе; на каждую идею должно уйти не более нескольких минут.
Необхс» димо ухватить только суть идеи. Расстановкаприоритетов Иногда генерация идей является единственной целью, и процесс на этом заканчивается. Однако в большинстве случаев, в том числе на посвященных требованиям совещаниях, необходимо определить приоритеты идей. оставшихся после отсечения. В конечном счете, ни одна команда разработчиков не может сделать "все, что только пожелается . После того как проведена и согласована группировка, пора приступать к следующему этапу.
И снова можно использовать множество методов; мы опишем два иэ них, которые обычно применяем сами. Накопительное голосование: стодолларовый тест. Это простой тест; забавный, понят. иый и легко выполнимый. Каждому участнику выдается $100 "идейных денег", которые можно потратить на "покупку идей". (Вы можете даже добавить в чемодан инвентаря для совещания набор "идейных долларов".) Каждому участнику предлагают записать на листе бумаги, сколько денег он выделяет на каждую идею. Затем, после того как участники проголосуют, ведущий подсчитывает результаты и предлагает порядок классификации.
Можно набросать гистограмму, чтобы наглядно представить результат участникам. Обычно этот процесс работает просто замечательно. Однако вам следует помнить о следующем, Вс»первых, он срабатывает только однажды. Вы не можете повторно использовать его в одном и том же проекте, так как если результаты первой попытки известны, 134 т1асть х. Понимание потребностей пользонателей это повлияет на мнения участников при следующем голосовании. Например, если ваша любимая функция является первой в списке, а функция, которую вы ставите иа второе место, даже не получила достойного упоминания, вы можете поставить все ваши деньги на вторую. Вы уверены, что остальные участники позаботятся о том, чтобы ваша любимая функция по-прежнему осталась в списке.
Во-вторых, может оказаться необходимым ограничить сумму, которую кзждый может потратить на одну функцию. В противном случае хитрый участник, прекрасно знающий, что такие функции, как "быстродействие" и "простота использования," и так попадуг в верхнюю часть списка, может поставить все свои деньги на "работает на платформе Мас" и поднять приоритет этой функции. С дру. той стороны, можно разрешить более высокий лимит, чтобы иметь возможность понять, куда поступили по-настоящему крупные взносы. Они могут представлять высокоприоритетные потребности ограниченных сообществ заинтересованных лиц.
Разбиение на категории "критическая, важная, полезная". В свое время коллега научил нас методу, который также оказался очень эффективным, особенно для небольших групп заинтересованных лиц или даже одного такого лица (например, когда нужно узнать мнение начальника о ваших приоритетах). Каждому участнику дается число голосов, равное количеству идей, каждый голос должен относиться к одной из трек категорий "критический", "важный" или "полезный".
Суть метода в том, что голоса, принадлежа. щие каждому участнику, распределены по категориям равномерно (одна треть "критических". одна треть "важных" и одна треть "полезных" ); следовательно, только одну треть идей участник может отнести к критическим. ° Крнашческал. означает обязательная. При отсутствии данной функции участник не сможет использовать систему. Без нее система не будет выполнять свою основную миссию.
Поэтому иет смысла делазь систему без этой функции. ° Важная. При отсутствии данной функции произойдет значительная потеря пе требительской ценности, доли на рынке или прибыли либо уменьшится приток новых обслуживаемьсх клиентов. Если важные пункты не будут реализованы, некоторым пользователям продукт не понравится и они ие будут приобретать его. ° Поизнаа. Это означает, что было бы хорошо ее иметь. Тзкш функция делает жизнь проще, систему привлекательнее и приятнее илн приносит большую выгоду.
Замечание. При использовании данного метода все идеи, которые "пережили" этап отсечения, получают, как минимум, статус "полезных", что позволяет избежать обид со стороны их авторов. Когда участников много, одна и та же функция может быть отнесена разными участниками к различным категориям, но это не стрзгпно.
Ведущий выполняет следующее действие: умножает "критические" голоса на 9, "важные" на 3, а "полезные" на единицу и подсчитывает сумму! Это распределит результаты в пользу "критических" голосов, и каждая "критическзл" потребность клиента всплывет иа вершину списка. Мозговой штурм с использованием ЮеЬ До сих пор мы обсуждали процесс "живого" мозгового штурма, который очень эффективен, когда всех заинтересованных лиц можно собрать вместе и они являются относительно активными и не очень застенчивыми, ведущий — опытным, а политика заинте.
Глава 11. Мозговой штурм и отбор идей 1бб ресовапных лиц — управляемой. Время, проведенное разработчиками и внешними участниками проекта вместе, очень плодотворно. Процесс обмена мнениями способствует взаимопониманию. Поэтому мы всегда предпочитаем проводить посвященное требова. ниям совещание и "живой" мозговой штурм. Но иногда "живои" мозговой и~тури невозможен.
В этих ситуациях альтернативой является использование 1щегпег или локальной сети для организации мозгового штурма посредством создания дискуссионной группы. Этот метод особенно подходит для разработки перспективных приложений, когда необходимы исследования или долгосрочные прогнозы, концепция изначально расплывчата и требуется широкий диапазон мнений болыпого количества пользователей и заинтересованных лиц.
При использовании этого метода руководитель проекта спонсирует почтовый сервер или %еЬ страницу для фиксации свойств продукта и комментариев к ним. Запись идей и комментариев может производиться как анонимно, так и с указанием авторства, в зависимости от созданной администратором схемы. Преимуществом этого метода является его пермапентность; иден и комментарии мокнут циркулировать в сети на протяжении значительного периода вре.
мени. При этом отражается весь процесс эволюции каждой идеи. Самой важной особенно. стью является совершенствование идей с течением времени, Рабочий пример: совещание по вопросу требований к системе НОЕ1$2000 Вернемся к нашему рабочему примеру. В то время, пока проводилось интервыоирш ванне, на встрече команды разработчиков с представителями маркетинга было принято решение созвать совевгание, посвященное требованиям к проекту НОЕ18 2000. Присутствующие Команда решила не приглашать стороннего ведущего, а поручить провести совещание Эрику, директору по маркетингу.
Команда также приняла репэение, что ее интересы на совещании будут представлять два человека: Кэти, менеджер продукта, и Пит, менеджер разработ. ки. Команда посчитала, что они смоч г говорить от ее имени, а также сможут вносить предло жения во существу, так как оба недавно стали домовладельцами. Другие члены команды не будут принимать участие в совещании, но могут посещать заседания в качестве наблюдателей, чтобьг усльппать мнения клиентов и непосредственно увидеть результаты. Комавда приняла решение пригласить следующих представителей четырех "классов" заказчиков. 1. Дистрибьюторы: Джон, главный управляющий крупнейгвего дистрибьютора кохе панин, и Ракель, генеральный менеджер эксклюзивного дистрибьютора компании в Европе.
2. Дзвид, строитель типовых домов в данном районе, имеющий опыт в закупке иа рынке и установке конкурирующих систем. 3. Бетти, местный поставщик электрических систем. 4. Будущие домовладельцы, найденные с помощью Бетти, которые в настоящее время строят или собираются строить жилье высокого класса. 136 сувать 2.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
