Книга: Программное обеспечение и его разработка

Противоречивые требования разных пользователей

Противоречивые требования разных пользователей

Моя группа разработчиков потеряла 2 млн. долларов при разработке автоматизированной системы выпуска двух крупнейших японских газет; позднее за эту работу мы получили японскую медаль Исикавы за достижения в области технологии и промышленности. С одной из газет мы подписали соглашение о том, что беремся автоматизировать весь процесс выпуска от ввода японских иероглифов, редактирования их и разметки страниц с помощью телевизионных дисплеев и до передачи полученных фотоформ прямо на печатные станки. Мы могли бы выполнить эту работу, полностью уложившись в отведенный нам бюджет. Однако японское отделение IBM предложило пользоваться этой системой и другой газете, которая была конкурентом первой. Между этими двумя газетами постоянно возникали разногласия по вопросам, какие функции и как надо исполнять.

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

Через несколько лет после описанного случая мы понесли убыток еще на 10 млн. долларов. В это время мы были заняты автоматизацией двух новых нефтеочистительных заводов фирмы «Эксон» — в Эдмонтоне, Канада, и в Антверпене, Бельгия. И опять возникли те же проблемы, сначала мы пытались понять, какие функции нужно вносить в систему, а затем пытались удовлетворить сразу двух разных пользователей. То, что оба этих завода входили в одну компанию «Эксон», еще не означало, что среди них имелось согласие по поводу способов управления процессом очистки. Но опять-таки система работала! И работала хорошо. Просто заранее оказалось сложным оценить весь объем работ с достаточной точностью.

Другой важной причиной, по которой нельзя «замораживать» требования, является то, что пользователи таких систем получают в свое распоряжение совершенно новый инструментарий. На него распространяются те же законы, что и на другие новые орудия труда. По мере роста понимания возможностей нового инструмента пользователи начинают лучше осознавать те функции, которые можно было бы выполнять значительно эффективнее, если бы они были встроены в систему. Предвидеть заранее все функции, а иногда даже хотя бы большинство их не удается.

Один урок, который удается извлечь из всех этих наших усилий, — это разница между «товарными» программами и обеспечением проектов. Проект создается для одного заказчика; товарная продукция должна удовлетворять требованиям многих различных заказчиков. Снова и снова — при работе и на очистительных заводах, и в газетах — мы вынуждены были возвращаться в исходное положение и начинать все сначала, поскольку, когда один заказчик соглашался с предложенными ему методами автоматизации, другой начинал требовать чего-нибудь другого. «Чуть-чуть иначе».

Оглавление книги

Оглавление статьи/книги

Генерация: 0.318. Запросов К БД/Cache: 3 / 1
поделиться
Вверх Вниз