Помоги аналитику! Требования и проектирование? Тьфу!

ReqsVsDesign

Оригинальная статья: «Help a BA! Design and requirements? Pshaw!» by Doug Goldberg.

Вопрос читателя:

Постоянно идут споры о таких элементах в спецификации требований, которые также можно отнести к проектированию. Это, к примеру, макеты страниц, структура и содержимое файлов и т.д. Так что же на самом деле относится к спецификации требований, а что нет?

Ответ от Doug Goldberg:

Читатель прав насчет того, что об этом постоянно идут споры. Я поучаствую в этой дискуссии, представив ту точку зрения, которая последнее время стремительно завоевывает популярность. На самом деле я и сам в последние год-два все больше придерживаюсь этой новой тенденции.

Когда-то аналитики месяцами (а порой и годами) сидели и писали документацию, чтобы затем передать ее другим командам. Команды читали документацию (да-да, читали) и затем начинали проектирование и разработку. Отслеживая связи между результатами своей работы и изначальными требованиями, команда проектирования и разработки удостоверялась в том, что все точки над «и» расставлены, – и все работало как часы.

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

Одна из таких вещей – моделирование с использованием диаграмм, где специалист создает абстрактное представление проблемы или бизнес-области. Сейчас для этих целей мы используем UML-диаграммы, хотя на самом деле существует множество нотаций моделирования. Диаграммы дают нам возможность видеть проблемы и их решения в графическом формате, что позволяет донести до людей то, что не могли донести слова. Возникновение все новых стандартов моделирования даже привело к появлению нового программного обеспечения (к примеру, inteGreat и Enterprise Architect, которые позволяют как моделировать, так и сопровождать модели текстом). Данное поколение инструментов, как и генерируемая ими документация, предоставляет огромные возможности для эффективного взаимодействия мира требований с миром проектирования.

Следующий пункт – быстрое создание прототипов. Эта практика значительно меняет обстановку, в которой работают аналитики. Инструменты данной категории предназначены для быстрого моделирования карт сайтов и макетов страниц непосредственно во время извлечения требований, рядом с клиентами. Возможность извлечь информацию, трансформировать ее в решение и получить отзывы от клиента в течение нескольких минут – всё это ведет к более эффективным требованиям и раннему пониманию проблемы и бизнес-области. Все это также означает смену фокуса работы – то, с чем так и не могут смириться аналитики старой закалки… включая и меня.

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

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

Короче, вот что я хочу сказать. Для того чтобы взаимодействие между участниками проекта и аналитиком было успешным, аналитик ОБЯЗАН уметь вдаваться в детали проектирования, если это придаст цельности обсуждениям. Испытывают ли некоторые неудобство, когда границы между требованиями и проектированием размываются? Конечно! Однако на самом деле вопрос должен звучать не «куда поместить требования, связанные с проектированием?», а «принесут ли пользу проекту более ясные, точные и непротиворечивые требования, собранные на более раннем этапе с меньшими усилиями?».

Остальное не имеет значения. И мы, аналитики старой школы, должны вести переговоры с клиентами согласно новым тенденциям. И мы также должны понять: мир меняется.

А что думаете вы? Как бы вы ответили на вопрос читателя?

Автор: Doug Goldberg. Doug Goldberg работает старшим бизнес аналитиком в Далласе, штат Техас, US рынок. Имеет за плечами 15 лет опыта в качестве аналитика в сфере разработки приложений для финансового и технологического рынков и области здравоохранения. Некоторое время занимался программированием на Java/J2EE. Doug также занимается обучением бизнес аналитиков, как лично, так и в режиме онлайн, включая кураторство учебных групп CBAP. Является активным блоггером и в данный момент занимает пост вице-президента Professional Development for the Dallas Chapter of the IIBA.