Технологии программирования - Wiegers.Software R. Development Productivity Award Москва 2004 удк 004. 45 В41 Карл Разработка требований к программному с англ. М. дом Русская Редакция , 2004. ил. Isbn 5-7502-0240-2 Эта книга
 Скачать 37.95 Mb.
| Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
Полное содержание архива WinRAR ZIP archive.zip: Глава 6. Как отобрать пользователей для работы над проектомСторонник продукта от класса «Химики» Сторонник продукта от класса «Отдел Сторонник класса охраны труда и техники Сторонник от "Отдел охраны труда и техники безопасности» Рис. 6-3. Структура команды из аналитиков и сторонников продукта для системы контроля химикатов Безголосый класс Аналитик требований в компании Insurance был очень доволен, узнав, что пользующийся авторитетом сотрудник, Ребекка, стать сторонником продукта для новой системы обработки исков. У Ребекки было много идей насчет возможностей и пользовательского интерфейса системы. Вдохновленная возможно- стью работать под руководством эксперта, команда разработчиков с удовольствием реализовала ее предложения. Однако, выпустив продукт, они были шокированы ко- личеством жалоб на трудности работы с системой. Ребекка - опытный пользователь. Предложенные ею функции, обеспечивающие удобство работы с системой, хороши для таких же опытных пользователей, как и она сама, однако 90% клиентов, гораздо менее опытных, нашли, что система интуитивна непонятна и трудна для освоения. Аналитик требований вовремя не понял, что у сис- темы обработки исков по крайней мере два класса пользователей. Большая группа начинающих пользователей оказалась лишенной права на участие разработке тре- бований и пользовательского интерфейса, поэтому компании Humongous пришлось потратиться на переделку проекта, а она обошлась дорого. Аналитику следовало привлечь второго сторонника продукта - выразителя интересов класса не- опытных пользователей. 108 Часть II. Разработка требований к ПО Как «продать» идею о необходимости привлечения сторонника продукта Будьте готовы встретить сопротивление, когда вы предложите влечь к работе над проектом сторонников продукта. «Пользователи слишком заняты». «Менеджеры хотят сами принимать решения». «Они затормозят нашу работу». «Мы не можем себе этого позволить». «Я не знаю, что могу предложить в качестве сторонника продукта». пользователи не хотят высказывать свои требования к системе, которая, как они думают, заставит их изменить методы работы или создаст угрозу увольнения. Иногда менеджеры неохотно делегируют обычным пользователям полномочия, касающиеся Отделив бизнес-требования от требований пользователей, вы смягчите эти препятствия. Будучи реальным пользователем, ник продукта принимает решения на уровне интересов пользователей в рамках, налагаемых бизнес-требованиями проекта. Финансовый ме- неджер сохраняет всю полноту власти, чтобы принимать решения, сающиеся вида продукта, его графика работы и затрат. ментируя и обсуждая роль и обязанности апологета продукта, вы те предполагаемым кандидатам на эту роль возможность отвечать на вопрос, чем же они занимаются. же вы с укажите, что недостаточ - ное участие пользователей — общепризнанная основная причина про- вала проектов по разработке ПО (The Standish Group, оппонентам о проблемах предыдущих проектов, вызванных недоста- точным вовлечением пользователей в работу. Каждая компания свои страшилки о новых которые не удовлетворили потреб- ности пользователей, или оказались не столь полезны, или не оправ- дали ожидания. Вы не можете позволить себе переделывать системы или отказываться от них, если они не соответствуют необходимым бованиям, только потому, что никто не разобрался в требованиях. влечение сторонников продукта уменьшает такой риск. В какие ловушки можно угодить, привлекая сторонников продукта Модель привлечения сторонника продукта хорошо себя во многих рабочих средах. Она имеет смысл, только если сторон- ник понимает и принимает свои обязанности, обладает для принятия решений на уровне требований пользователей и время для выполнения данной работы. Остерегайтесь следующих по- тенциальных проблем. Глава 6. Как отобрать пользователей для работы над проектом Некоторые менеджеры изменяют решения, принятые квалифици- рованным и официально назначенным сторонником продукта. Воз- можно, у менеджера в последнюю минуту появилась новая безум- ная идея, он из прихоти захотел изменить направление работы или думает, что знает все потребности пользователей. Зачастую резуль- тат такого поведения — недовольные пользователи, срыв сроков сдачи проекта из-за того, что разработчики пытаются реализовать последние замечания менеджеров, а также расстроенные сторон- продукта, чувствующие, что руководство им не доверяет. Сторонник продукта, забыв, что он представляет других озвучивает только собственные требования: конечно же, ему не удастся хорошо выполнять свои Возможно, лично ему результат понравится, а вот остальным — ли. Сторонник продукта, не имеющий четкого представления о новой системе, может уступить решение важных вопросов аналитику. Ес- ли все идеи аналитика вызывают одобрение сторонника, его трудно назвать полноценным помощником. Из-за нехватки времени опытный пользователь назначает сторон- ником продукта менее квалифицированного коллегу. Это может привести к давлению со стороны опытного пользователя, который по-прежнему желает направлять ход работы над проектом. Остерегайтесь пользователей, пытающихся выступить от имени класса, к которому они не относятся. В случае с системой контроля химикатов компании Contoso сторонник продукта от класса «Со- трудники склада настаивала, что может выразить тре- бования класса пользователей «Химики». Ее было весьма трудно убедить, что это не его работа, однако аналитик не позволил ей ока- зывать давление. Менеджер проекта пригласил сторонника от клас • са «Химики», и тот проделал блестящую работу по сбору, оценке и передаче требований этих специалистов. Кто принимает решения Кто-то должен устранять конфликты между требованиями разных классов пользователей, сглаживать противоречия и решать возникаю- щие вопросы относительно границ проекта. На ранних стадиях та необходимо определить тех, кто будет принимать решения, щиеся требований. Если не ясно, кто за это отвечает, или ченные лица отказываются брать на себя такую ответственность, обязанность принимать решения по умолчанию возлагается на Часть II. Разработка требований к ПО Это — неудачный выход, поскольку у разработчиков нет необходимых опыта и стратегического видения для приня- тия оптимальных бизнес-решений. Не существует единственно верного ответа на вопрос о том, кто должен принимать решения по требованиям к программному проекту. Аналитики иногда прислушиваются к наиболее громогласному сотруд- нику или мнению начальства. Это но не лучший выбор. По возможности решения должны принимать сотрудники на низшем уровне организационной иерархии, которые непосредственно зани- маются выпуском продукта и знают все о нем. Прежде чем принимать- ся за выработку первого решения, каждая группа должна определить соответствующее правило решения (decision rule) — согласованный метод принятия решения (Gottesdiener, Лично мне нравится со- вместное принятие решений или принятие решений в ходе совещания (когда собираются идеи и мнения множества заинтересованных лиц), а не принятие решений через достижение консенсуса всех заинтере- Последний вариант — идеальный, однако вы не можете постоянно тормозить работу, ожидая, пока все заинтересованные ли- ца согласуют каждый вопрос. Ниже описаны некоторые конфликты, которые могут возникнуть в ходе работы над проектами, а также способы их устранения. Ведущим проект сотрудникам необходимо определить, кто будет принимать ре- шения при возникновении подобных ситуаций, кто обладает правом го- лоса, если согласие не достигнуто, и кто будет в дальнейшем нировать решения по важнейшим вопросам. 1 Если отдельные пользователи не могут прийти к согласию при опре- делении требований, решение принимают сторонники продукта. Суть привлечения апологетов такова: они уполномочены и обязаны устранять конфликты требований, возникающие у тех, кого они представляют. а Если требования различных классов пользователей или сегментов рынка несовместимы, сделайте выбор в пользу наиболее важного класса пользователей или сегмента, который окажет наибольшее влияние на успех продукта на рынке. 1 Иногда все корпоративные клиенты одновременно требуют, чтобы архитектура проекта удовлетворяла именно их требования. В таком случае на основе бизнес-целей проекта определите, кто из клиентов оказывает наиболее сильное влияние на успех или про- вал проекта, Глава 6. Как отобрать пользователей для работы над проектом i Иногда требования, высказываемые менеджером пользователей, не совпадают с интересами реальных пользователей. И хотя требо- последних должны соответствовать бизнес-требованиям, менеджеры, которые не входят в конкретный класс пользователей, обязаны прислушаться к стороннику продукта, выражающему мне- ние соответствующего класса. 1 Если представление разработчиков о создаваемом продукте не совпадает с пожеланиями клиентов, последнее слово за клиентами. Ловушка Не оправдывайте любые запросы клиента только потому, что «клиент всегда прав». Клиент прав не всегда. Однако у него есть своя точка зрения, и коман- да разработчиков должна понимать и уважать ее. i Аналогичная ситуация возникает, если требования маркетологов или менеджеров по продукту конфликтуют с представлением разработ- чиков о продукте. Мнение маркетологов, как представителей клиен- та, более весомо. Однако я знаю случаи, когда они потакали клиенту в его любых желаниях, как бы невыполнимы и дороги те ни были. Я также видел и обратные примеры, когда маркетологи предостав- ляли так мало информации, что разработчикам приходилось самим определять архитектуру продукта и формулировать требования. Переговоры о требованиях не всегда проходят так, как они должны проходить по мнению аналитиков. Клиент может отвергать все пред- ложения разумных альтернатив и другие точки зрения. Команде следу- ет определить, кто будет принимать решения по требованиям к проек- ту, еще до начала подобных столкновений. В противном случае нере- шительность и пересмотр уже принятых решений приведут к тому, что работа над проектом заглохнет в бесконечных спорах. Часть II. Разработка требований к ПО Что теперь? I Сравните схему на рис. 6-1 с тем способом, посредством которого вы узнаете мнение Возникают ли у вас проблемы с распространением информа- ции? Определите кратчайшие и наиболее подходящие пути распространения ин- формации, которые пригодятся для сбора требований в будущем. Определите для своего проекта классы пользователей. Какие них привилегированные, а какие (если таковые имеются) - нет? Кто бы мог стать хо- рошим сторонником продукта для каждого из важных классов пользователей? I табл. 6-2 в качестве отправной точки, определите обязанности сто- ронника продукта. Обсудите конкретные пункты с каждым предполагаемым сто- ронником продукта и его менеджером. Определите, кто должен принимать решения по вопросам, связанным с требова- ниями к проекту. Насколько эффективен процесс принятия решений, используе- мый в настоящее время? Где он дает сбой? Правильно ли выбраны лица, прини- решения? Если нет, кто должен принимать решения? Предложите ли- цам, принимающим решения, последовательность действий для достижения согласия по вопросам требований. Глава 6. Как отобрать пользователей для работы над проектом Как услышать голос клиента «Доброе Мария. Я — Фил, аналитик требований к новой информационной системе для сотрудников, которую мы соби- раемся разрабатывать для вас. Спасибо, что согласились стать сторонником продукта этого проекта. Ваша информация нам очень пригодится. А теперь расскажите что же вам все - таки нужно что же мне нужно, — размышляет Мария. — Не представ- ляю, с чего и начать. Ну, новая система должна работать на- много быстрее предыдущей. вы же знаете, как старая система зависает, если имя какого-либо сотрудника оказыва- ется слишком длинным — нам приходится обращаться в служ- бу поддержки, чтобы они ввели имя. В новой системе длинные имена должны обрабатываться без сбоев. Да, согласно му закону, нам нельзя использовать номера социального страхования в качестве идентификаторов сотрудников, и с вводом новой системы в эксплуатацию нам придется заме- нить все эти данные. Новые идентификаторы предполагается сделать шестизначными числами. Также пригодилась бы функция отчета о времени, затраченном каждым сотрудников в текущем году на обучение. А еще мне хотелось бы возможность менять имена сотрудников, даже если их семей- ное положение осталось прежним». Фил добросовестно записал все пожелания Мария, но его го- лова пошла кругом. Он не знал, что делать с этой информаци- ей, и не имел ни малейшего представления, что же передать разработчикам. «Ну что ж, — подумал он, — если Мария хочет, чтобы мы это сделали, нам это сделать». Часть II. Разработка требований к ПО Сердце процесса формулирования требований - - их выявление когда потребности и ограничения высказывают лица, заин- тересованные в проекте. Цель — пользо- которые занимают средний уровень в трехступенчатой моде- ли требований к ПО об этом в главе два других уровня — и функциональные требования). Это кото- рые пользователям необходимо выполнять средствами также представления пользователей об эффективности, удобстве и простоте работы с системой и других атрибутах качества системы. этой главе обсуждаются общие принципы эффективного выявления требований. Аналитику необходима структура для систематизации массива ин- формации, полученной в процессе выявления требований. Просто за- давая пользователям вопрос: «Чего вы вы получите массу не- упорядоченной информации, в которой легко утонуть. Вопрос: «Чтс вам требуется — гораздо лучше. В главе 8 как с помощью таких приемов, как варианты использования или построение таблицы откликов на события, создать структуру упорядочения пользовательских требований. Результат этапа формулирования требований -- представление о потребностях всех заинтересованных в проекте лиц Теперь разработчикам гораздо легче предлагать альтернативные собы удовлетворения этих потребностей. Те, кто занимается нием требований, не должны поддаваться искушению приступить к проектированию системы — до того момента, как блема станет абсолютно ясной. В противном случае готовьтесь к чительной переработке проекта по мере детализации требований, Концентрация на задачах пользователей, а не на интерфейсе, внима ние к ключевым потребностям, а не к пожеланиям позволяет команде не отвлекаться на детали архитектуры — сейчас это несколько Для начала подумайте, как вы собираетесь выявлять требования к проекту. Даже простой план повышает шансы на успех и делает более реалистичными ожидания всех заинтересованных лиц. Только четко сформулировав потребности, касающиеся ресурсов, графика и пуска, можно избежать того, что лиц, участвующих в выявлении ваний, отзовут для исправления ошибок или выполнения другой ты. План должен отражать: I цели выявления требований проверка рыночных дан- ных, исследование вариантов использования или разработка под- робного набора функциональных требований к системе);  перейти в каталог файлов | Образовательный портал Как узнать результаты егэ Стихи про летний лагерь 3агадки для детей |
