Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 43
Текст из файла (страница 43)
нне/вьпиючение света 44 У1 О. Обагавильный базовый уРовены ви, что находиоил еыив данной линии. должно быть Реаянлмана в аротивнаи случае вынуеи вереи и будет задержан. Мо;кет незначи- тельно повлияэь на программное обес. лечение Функция закрытия 66 гаражных ворот Низкая Низкий 20 Базис дзя трудосм. КОСТИ Простота монтажа 50 Средняя Средний Может незначи- тельно повлиять на программное обес- печение Низкая Низкий Возмо|кность управ; лять занавесками, жалюзи, насосами и движками 44 Низкий Средняя 22 Хорошо, если полу. ч»тся сделать это Возможность програмэгэерования режима "жильцы в отпуске" Любой источник светаиожетплавно понижать мощность Можно использовать собственный перса. нальный компьютер для программирования режимов работы Интернацноналнзиреваниый ЦВ~-интерфейс Возможность про. граммирования работы в режиме об.
служивания зрелищ. ных мероприятий Наличие режима плавного перехода: постепенное увели. чение/умеиьшение яркости света Глава 20. Задание масштаба проекта 207 По настоянию Ев. ропейского дисг рибьютора (Не применяется, включена в 2о) 208 Часть 4. Управление масштабом Окончанне табе 20. 7 У1 О. Дополнительные функции: ностарай тась разрабани та те кз них, хтырме снезстне (Кз)ли).
Б)дулие функции: находлнсиесл ниже зтай линии функции длл данной версии не)нмрабагамваютоь Функция Число голосов Средняя Высокий Обязателен для версии 2.0 Высокий Можем ли мы Высокая Высотой 19 55 Лвтоматическое включение Низкая Средний 18 50 Средняя света, когда кто-то подко- дит кдвери Высокая 15 Высокий Высокая Высокий 10 Центральные станции ?правления Высокая Высокий 25 Средняя Средний Высокий 25 Средння 24 21 Высокий Высокая 24 Нет данных Нет данных 22 Высокий Управление системой кон- дициониронания воздуха Высоюгя 28 Высокий Низкий Лативацил голосом Высокан Средина Поддержка презентационного веб.сайта 27 Интернационализирован- ный интерфейс ПК-программатора Интерфейс с системой охраны дома света в туалете при откры- тии двери Лвтоматическое включение Управление освещением и т.п.
по телефону Наличие интерфейса с сис. темой управления автома- тикой в доме Легко дополннется новыми элементами при изменении схемы эксплуатации Пульты дистанционного управления Интерфейс с видео- и ау- диосистемой Восстановление функций по. еле сбои в анергоснабжении Трудоемкость Риск Маркетинговые коммемгарии предложить хотя бы аппаратный интерфейс? (Эрик) Глава 21 Умение обращаться с заказчиком Основные положении ° Нсобходимо привлекать заказчиков к управлению собственными требованиями и масштабом их проекта. ° Заказчики, вовлеченные в процесс, Г>удут владеть результатом.
° Выполнить зада и как следует — означает предоставить к указанному врел>е>ш д<>статочг>ь>е ц>упкцп>н>альнь>с возможности для удовлетворения ре. альпой потребности клиента. В Приемы ведения переговоров являются неоценимым подспорьем прп решении проблем управления масштабом. Привлечение заказчиков к управлению масштабом их проекта Сокращение масштаба проекта до размеров, сопоставимых с имею>нимся временем и ресурсами, может привести к враждебным отношениям между командой проекта н ее заказчиками, потребности которых необходимо удовлетворить.
Если быть честныьш, со всеми такое случалось. К счастью, это це обязательно должно быть так. Мы .можем актив. по >в>килек>нпь наишх заказчиков к уэфавленню их п>ребованиллн> и маги>пшбом ик нуп>екпш, ч>побь> обеспечить как качество, так и своеврел>енпос>пь раэ)>абаи>хи прогу>сгмл>ного обеспечен>т. Это заключение основывается на нескольких важных мол>ситах.
° Именно заказчики несут финансовую ответственность за выполнеш>е внешних обязательств перед клиентами. Поэтому лучшее, что может предложить команда— это приложение высокого качества, выполненное в срок и в пределах бюджета (пусть и в несколько сокращенно>>, в случае необходимости, ь>асштабе). ° Приложение, сто ва>кнеишие функции, удовлетворясмые им бизнеспотрсбпости — эсс это принадлежит заказчикам, а не команде разработчиков. Мы нуждаемся в указаниях заказчиков при принятии основных решений, и только они л>огут реально определить, как, сократив л>асштаб, пол) шть полезное приложение. Мы занимаемся только технологическими аспекталги. Это их проект. 210 Часть 4. Управление масштабом Сообщение о результате Если масштаб проекта необходимо сократить, убедитесь, что заказчик является испо. средственным участником процесса.
Закаэчик, участвующий в процессе, будет владеть результатом, Исключенный иэ процесса заказчик будет недоволен и, естественно, будет стремиться обвинить разработчиков в недостаточной старательности. Привлечение закаэчика помогает наименее болезненно решить проблемы )правления масштабом. Следуя философии, описанной в предыдущей главе, разумные заказчики по. обещают своим клиентам только критические функции, включенные в базовый уровень. Таким образом удастся избежать неприятностей с отставанием от графика и пропущенными функциями.
Любые дополнительные функции (которые удастся разработать по. цимо базовых) будут восприняты позитивно как превзошедшие ожидания. Иногда необходимость сокращения масштаба обнаруживается в отсутствие заказчи. ка; тогда, очевидно, необходимо сообщить ему об этом. Доставка подобного сообщения нашим заказчикам и/или руководству — деликатный процесс, требующий как умения вести переговоры, так и принятия определенных обязательств по полученным в рс" зультате сокращения графику и масштабу.
После такого сообщения мы не можем позволить себе потерпеть неудачу в предоставлении нового обещанного продукта, иначе все доверие будет потеряно. Переговоры с заказчиком Почти во всех бизнес-процессах требуется вести переговоры. Например, перегово. ры относительно даты поставки шариковых подшипников, о цене на крупный заказ, переговоры о вашем ежегодном повышении зарплаты с вашим менеджером, перегово. ры о достижимой квоте с вашим отделом продаж или переговоры о дополнительных ресурсах для вашего проекта.
Для защиты как вашего проекта, так и бизнес-целей вашего заказчика вам может пона. добиться вести переговоры об объеме работ для вашей команды. Кол1анде следует знать, что зачастую заказчик владеет приемами ведения переговоров и, естественно, будет использовать их в дискуссии с командой. Следовательно, руководителю команды, мепедже. ру или лидеру проекта также необходимо овладеть соввметствующнми пЯиечама. Ведение переговоров представляет собой вид профессиональной деятельности в деловой сфере. Это не особенно сложный процесс, и его можно осуществлять честно, красиво и стильно. Воспользуйтесь возможностью попрактиковаться в этом; возможно, вам сможет помочь ва~н отдел, занимающийся человеческим фактором, или вы можете принять участие во внешнем семинаре.
Если вам это не удастся, следует хотя бы ознакомиться с некоторыми правилами игры. Например, хороший обзор процесса ведения переговоров содержится в книге Фишера (ГЬЬег), Урн (1)гу) и Паттона (Ранов) Се((гик(в уев (1983), которую можно прочитать буквально за несколько часов. Они дают несколько полезных советов относи. тельно проведения любых переговоров.
° Начинайте высоко, но не слишком. ° Отделяйте человека от проблемы. ° Концентрируйте внимание на интересах, а не позициях. ° Пойгвите, с чем вы уйдете. Глава х1. Умение обращаться с заказчиком х11 ° Придумайтс вэаимовыгодныс варианты. ° Примените объективный критерий. Руководящий принцип при управлении масштабом: "меньше обещать и больше делать". Во время переговоров с заказчиком о задании базового уровня следует руководство. загься принципом випьже обпцажь и бавылв Зглажь, Тогда неизбежные издержки разработки программного обеспечения (непредвиденные технологические риски, изменения требований, задержки при приобретении закупаемых компонентов, непредвиденный уход основньпс членов команды и т.п.) нс приведут к нарушению графика вашего проекта.
Если вам посчастливится работать с тем одним проектом из тысячи, в котором эти неприятные обстоятельства не возникнут, — прекрасно! В худшем случае вы придете в замешательство, закончив проект раньше! Это даже развесслит вашу компанию! Управление базовым уровнем Преуспевающие менеджеры задают маржи для ошибок прн оценке трудоемкости и разрешают иногда включать уэаконенныс изменения в требования во время разработки. Эти менеджеры также препятствуют "просачиванию" функций, которое, по оценкам Джерри Вайнберга Целу Ие!пЬегб, 1995), может увеличить объем проекта на 50-100% после начала работы.
Концентрируя усилия на разработке критических для заказчиков функций, можно даже смягчить политически враждебное окружение. Если масштаб согласован иа достижимом уровне и разработка концентрируется практически полностью иа том, что, по мнению клиента, "должно быть", команда завоюет доверие, соблюдая график и критерии качества, и, быть может, предоставляя возможности, которые не были обещаны заранее. Однако ваши заказчики, внешние нли внутренние, естественно желают получить как можно больше функциональных воэможностей в каждой версии программной системы.
В конце концов, именно эти функциональные воэможности сащают добавленную стоимость, которая нужна им для доспвжения их бизнес-целей. Мы должны с пониманием относиться к требовательным клиентам, поскольку именно они в конечном счете добиваются успеха иа рынке. Только таких требовательных, компетентных клиентов и стоит иметь! Однако если пойти на поводу требований все большей и большей функциональности, эго может негативно сказаться на качестве и общей жизнеспособности проекта.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
