«Привет, Фил, это Мария из отдела персонала. У нас проблема с системой, которую вы разрабатывали для нас. Одна из сотрудниц изменила фамилию на Спакл Старлайт, а система не принимает это изменение. Ты можешь помочь?»
Она вышла замуж за парня по имени Старлайт?»
"Нет, она просто взяла другую фамилию, — ответила Мария. — В этом-то и проблема. Как будто мы можем брать другую фамилию только при изменении семейного положения».
«Да, я не предусмотрел такой возможности. Я не помню, чтобы, и ты говорила мне о ней, когда мы обсуждали систему. Вот поэтому-то диалоговое окно «Изменить фамилию» доступно только из окна «Изменение семейного положения», - сказал Фил.
«Я полагаю, ты знаешь, что люди могут законным образом менять фамилию, когда захотят, — ответила Мария. — Мы должны исправить это к пятнице, а то Спакл не сможет обналичить чек. Ты сможешь исправить этот дефект к такому сроку?»
«Это не дефект, — резко парировал Фил. — Я и не знал, что вам нужна эта функциональность. Сейчас я занимаюсь оценкой производительности системы. Думал, что потребуется менять что-то другое». (Шелест бумаги.) «О-о, да здесь есть еще кое-что. Я, вероятно, смогу исправить это в конце месяца, но не на этой неделе. Извини меня. Но в следующий раз с такими просьбами звони пораньше и, пожалуйста, описывай их». «А что же я скажу Спакл? — возмутилась Мария. — Ей придется залезать в долги, если она не сможет обналичить чек». «Эй, Мария, это не моя вина, — запротестовал Фил. — Если ты не сказала мне при первом осуждении, что вам понадобится изменять фамилию в любое время, этого и нет в системе. Ты не можешь винить меня за то, что я не умею читать мысли в твоей голове».
Сердитая и смирившаяся, Мария отрывисто сказала: «Это как раз то, из-за чего я ненавижу компьютерные системы. Позвони мне, как только сможешь исправить недостаток».
Если вы когда-либо бывали в шкуре клиента на переговорах, подобных этому, то знаете, как расстраиваются пользователи продукта[3], который не позволяет выполнять основные задачи. Разработчики испытывают чувство разочарования, когда узнают о функциональности, которую пользователи ожидали получить, только после развертывания системы. Точно также раздражает, если приходится прерывать работу из-за необходимости модифицировать систему, так как она не выполняет те задачи, о которых вы говорили еще в самом начале разработки.
Масса проблем с ПО возникает из-за несовершенства способов, которые люди применяют для сбора, документирования, согласования и модификации требований к ПО. Как в случае с Филом и Марией, проблемы могут возникать из-за неформального сбора информации, предполагаемой функциональности, ошибочных или несогласованных предположений, недостаточно определенных требований и бессистемного изменения процесса.
Большинство людей при строительстве дома даже не интересуются подрядчиками, пока в полном объеме не обсудят свои потребности и желания и не уточнят все детали. Покупатели понимают, что внесение изменений влечет за собой изменение цены; им это не нравится, но они это понимают. Однако люди весело ищут оправдания, когда дело касается разработки ПО. Ошибки, допущенные на стадии сбора требований, составляют от 40 до 60% всех дефектов проекта (Davis, 1993; Leffingwell, 1997). Две наиболее распространенные проблемы, о которых сообщается в большом Европейском обзоре индустрии ПО, — определение и управление требованиями заказчика (ESPITI, 1995). Тим не мене многие организации еще применяют неэффективные методы на этих стадиях разработки ПО. Типичный исход — неожидаемые пробелы, а также различия между тем, что разработчики собираются строить, и тем, в чем клиенты реально нуждаются.
Нигде более, как на стадии сбора требований, так тесно не связаны интересы всех заинтересованных в проекте лиц с успехом проекта. К заинтересованным в проекте лицам относятся:
· заказчики, которые финансируют проект или приобретают продукт для решения каких-то бизнес-задач;
· пользователи, которые взаимодействуют напрямую или не напрямую с приложением (подкласс заказчиков);
· аналитики требований, которые пишут требования и передают их разработчикам;
· разработчики, которые создают, разворачивают и поддерживают продукт;
· тестеры, которые определяют соответствие поведения ПО желаемому;
· технические писатели, которые отвечают за создание руководства пользователей, тренировочные материалы и справочную систему;
· менеджер по проекту, который планирует процесс и руководит командой разработчиков вплоть до успешного выпуска продукта;
· сотрудники правового отдела, которые следят, чтобы продукт не противоречил всем действующим законам и постановлениям;
· производственники, которые должны построить продукт, содержащий данное ПО;
· сотрудники отдела продаж и маркетинга, выездной службы поддержки и другие, кому придется работать с продуктом и его пользователями.
Хорошо справившись с этой стадией процесса, вы получите отличный продукт, восхищенных заказчиков и удовлетворенных разработчиков. В противном случае вам грозит непонимание, разочарование и разногласия, которые подрывают веру в продукт и его ценность. Так как требования представляют собой основу для действий и разработчиков и менеджеров проекта, все заинтересованные в проекте лица должны быть вовлечены в создание этого документа.
Но разработка требований и управление ими — трудный процесс! Здесь нет быстрых или волшебных решений. Однако многие организации борются с одними и теми же трудностями, для преодоления которых мы можем найти общие приемы, годные в различных ситуациях. В этой книге описаны дюжины таких приемов. Их рекламируют для построения абсолютно новых систем, однако они отлично подходят для поддержки проектов и выбора коммерческих готовых решений (см. главу 16). Не используйте эти приемы только для модели «водопада». Тем командам, которые выбирают итеративный процесс, необходимо знать, что же делать на каждом этапе.
Из этой главы вы узнаете:
· несколько ключевых терминов, применяемых при конструировании ПО;
· особенности разработки требований, которые отличают этот процесс от управления требованиями;
· тревожные симптомы некоторых связанных с требованиями проблем, которые могут иногда возникать;
· некоторые характеристики великолепных требований.
| Держите руку на пульсе Чтобы оперативно проверить приемы построения требований в вашей организации, опростите себя, как много следующих положений верны для ваших текущих проектов. Если вы пометите хотя бы три или четыре положения, эта книга для вас. · Образ и границы проекта никогда не определены ясно. · Заказчики очень заняты, чтобы работать с аналитиками и программистами над требованиями. · Заместители пользователей — менеджеры по продуктам, по разработке, менеджеры пользователей или маркетологи — вызываются говорить от имени клиентов, но не точно представляют их потребности. · Требования существуют только в головах «экспертов», работающих в вашей организации, и никогда не фиксируются в письменном виде. · Заказчики настаивают, чтобы все требования были критическими, без учета их приоритетов. · Разработчики получают двусмысленную и неполную информацию, поэтому при кодировании им приходится делать предположения. · Взаимодействие между разработчиками и заказчиками ограничивается внешним видом пользовательского интерфейса и не затрагивает того, что же действительно клиенты собираются делать с помощью приложения. · Ваши заказчики подписывают требования и затем постоянно изменяют их. · Проект разрастается, когда вы принимаете изменения требований, график при этом нарушается, потому что никаких дополнительных ресурсов не выделяется и никакие функции не удаляются. · Запросы на изменение требований теряются по пути: ни вы, ни ваши клиенты не знают статус каждого запроса. · Заказчики настаивают на определенной функциональности, которую разработчики и создают, однако эти возможности системы клиентам не нужны. · Технические требования хороши, а вот заказчики нет. |