Стоит прочитать: обзор книги Карла Вигерса «Разработка требований к программному обеспечению»

Юрий Селютин

старший аналитик компании Bercut

C «Разработкой требований к программному обеспечению» я познакомился на этапе перехода в отдел аналитики и проектирования систем, то есть, еще не будучи аналитиком. Очень вовремя! Книга помогла избежать ряда типовых ошибок и открыла мне глаза на многие базовые вещи, о которых я не знал. В ней подробно описаны основные принципы, технологии и приемы, четко показаны преимущества и недостатки различных подходов в разработке требований к ПО. Прежде всего, книга полезна тем, кто только начинает путь в аналитике, или хочет его начать. Но и для аналитиков с опытом, кто не читал книгу, будет много полезной информации. Считаю, что это настольная книга бизнес- и системного аналитика, как говорится, must read!

«Основное следствие проблем с требованиями — переделка того, что, как вы думаете, уже готово»

С самого начала книги автор доносит мысль о том, что переделки в проекте — это вещь неизбежная. Невозможно, чтобы заказчик и компания-разработчик сразу поняли друг друга в полной мере. Однако выявление необходимости переделок на разных этапах будет стоить совершенно по-разному. Наиболее безболезненно и наименее затратно исправлять ошибки, которые появились в ходе качественной работы квалифицированного аналитика с требованиями. В случае, если ошибка была обнаружена в ходе разработки, то помимо проекта придётся переделывать также и часть уже написанного кода. Если в ходе тестирования, то часть кода, которую потребуется скорректировать, будет еще больше. Теперь представьте, какие затраты будут, если ошибку обнаружит уже после завершения разработки и тестирования сам конечный пользователь и позвонит с жалобой? В книге автор приводит пример из собственного опыта, который был переведен в цифры одним из его клиентов. Трудозатраты на исправление дефекта внутри компании составляли 200 долларов. При этом исправление ошибки, когда она была обнаружена пользователем, уже составляла 4200 долларов, т.е. больше чем в 20 раз дороже. Книга доказывает, что качественная работа с требованиями — это не пустая трата ресурсов, а инвестиция в успех проекта.

«Нигде более, как на стадии сбора требований, так тесно не связаны интересы всех заинтересованных в проекте лиц с успехом проекта»

И здесь автор прав. После того как получен запрос или бизнес-задача от заказчика и до того момента, как стартовала разработка, то есть непосредственно написание кода, наступает то самое время, когда можно максимально приблизить проект к успеху. В этот момент начинается работа по выявлению, сбору, анализу, классификации, спецификации, документированию и управлению требованиями. Автор подробно описывает каждый из этих этапов, приводит живые (что самое интересное) кейсы, примеры ошибок и варианты исправления. Главное, чему учит книга — это как избежать тех самых ошибок при разработке требований к ПО. Требования представляют собой фундамент проекта, они являются основой для действий команд разработки и тестирования, для инженеров внедрения и для руководителей проектов. Поэтому от их проработки зависит успех всего проекта.

«Разработка ПО включает по крайней мере столько же общения, сколько и обычная работа с компьютером, но зачастую мы делаем акцент на работе с компьютером и не уделяем достаточно внимания общению»

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

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

У меня был такой опыт. Я подготовил проект, отвечающий требованиям, обозначенным заказчиком в запросе. По моему проекту была выполнена разработка и произведено тестирование внутри проектной команды. Однако после отгрузки доработки системы и приёмки заказчиком выяснилось, что бизнес-цель, которая ставилась при создании запроса, не была достигнута. Разобравшись, я понял, что совершил классическую ошибку, о которой пишет Вигерс: увлекся процессами проектирования, уделив основное внимание решению технической задачи, обозначенной заказчиком в блоке требований. При этом я не учел требования бизнеса. Как выяснилось позже, в запросе присутствовали противоречивые требования. Их можно было бы устранить только в ходе общения с представителями бизнес-подразделений заказчика.

«Лучше один раз увидеть, чем 1024 раза услышать»

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

У каждого типа представления свои преимущества, и они подходят каждый для своей цели. Например, при помощи изображений можно преодолеть барьеры, связанные с непониманием некоторых терминов внутри команды. Или при помощи диаграмм потока сообщений можно визуально быстро сориентироваться, в какой момент где какие данные передаются в системе. Автор приводит примеры ряда различных способов представления требований (карты, таблицы, диаграммы, прототипы) и поясняет, в каких случаях удобно использовать те или иные методы.

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

Детально расписаны роли участников проектов и их задачи, обоснована необходимость постоянного контроля обратной связи. Представлены методы управления требованиями, контроля внесения изменений, приемы моделирования и подходы к дизайну, а также рекомендации, как правильно фазировать процессы в жизненном цикле ИТ проекта.

В книге даже приведены шаблоны документов, которые, признаться, я по сей день частично использую в проектах. Подробно останавливаться на каждом описанном процессе не буду, их очень много. Понять, что можно узнать из книги легко – достаточно прочитать оглавление, оно очень подробное =).