Требования

для программного
обеспечения:
рекомендации по сбору
и документированию
Илья Корнипаев

Область проблем и область решений

Функции значения показателя

производительности
.1 ------
УДК 004.588
ББК В32.50.41.25
К67

Корнипаев, Илья
К67 Требования для программного обеспечения: рекомендации по
сбору и документированию — М.: Издательство «Книга по Требо­
ванию», 2013. — 118 с.

ISBN 978-5-517-60923-6.

Эта книга о том, как собирать, документировать и проверять требования.

Она рассчитана на самый широкий круг читателей: начинающих аналитиков,
проектировщиков, архитекторов, разработчиков, тестировщиков, руководи­
телей проектов и других специалистов, задействованных в проектах по раз­
работке программного обеспечения (ПО) на ранних стадиях.
Читатель, независимо от того, сотрудник ли он компании-разработчика,
является ли он представителем заказчика или работает в ИТ-отделе ком­
пании, не связанной с разработкой ПО, может найти в книге полезные для
себя советы и рекомендации.
Книга написана на основе более чем пятнадцатилетнего опыта автора,
а также по материалам авторских курсов по разработке и управлению тре­
бованиями.

© Илья Корнипаев, 2013

© Lennex Corp., 2013
 3
(lllllllllllllllllllllilltlllllillllillllltlllililtlltilllllllliltlllltH lltllllllltlllilllllllilllllllllllllllilM llillttllllllilllllllllllllllllllllllillillllill

Оглавление
Предисловие.................................. 5
Главные вопросы............................................................................... 5
Зачем..................................... 5
Для кого ........................... ........................ .......................... .. . 5
Ч то.......................................................................... 6
Как читать эту книгу............................................... 6
Структура книги.................................. 6
Ограничение ответственности........................................................... 7
Благодарности ....................................... 7
Введение............................. 8
Что такое требования? ........................................................................10
Коммуникация при разработке систем ...............................................11
Область проблем и область решений................................................. 12
Количество требований и выбор решения.....................................16
Проблемы, связанные с преждевременным переходом
в область решений ........................................................................18
Управление ожиданиями заказчика ....................................................19
Типы требований .......................................... 20
Требования и качество ........................................................ 22
Требования и моделирование ........................................ 24
Требования и изменения .................................................................. 26
Источник изменений — заказчик................................................... 26
Рынок как источник изменений ................................................... 27
Разработчики как источник изменений ....................................... 28
Другие характерные трудности ........................................................ 29
Высокая неопределенность ...............................................29
Разный культурный и образовательный уровень
участников проекта ....................................................................... 30
Противоречия ............................................................................. 31
Использование естественного языка ............................................31
Объем и глубина проработки требований.................................... 34
Обзор процесса разработки требований ..........................................35
Глава 1. Определение заинтересованных сторон
и их представителей...................................................... 37
Заинтересованные стороны в проекте .............................................. 37
Определение представителей заинтересованных сторон
для сбора требований ....................................................................... 38
Диаграмма взаимодействия........................................................... 40
Выбор представителя заинтересованной стороны........................ 42
Заинтересованные стороны и их цели ......................................... 44
Заинтересованные стороны и их проблемы..................................46
Заключение ............ 49
Глава 2. Сбор требований....................................................................... 50
Обзор источников требований ........................................................... 50
Планирование сбора требований........................................................ 50
Люди как источник для сбора требований......................................... 52
Подготовка к встрече ...................................................... 53
4 Оглавление

Интервью................................ 5^
С чего начинается встреча? ......................................................... 58
Как сесть?.......................................................................................60
Установить контакт ................................................................ 61
Введение ...................... 62
Вопросы и ответы .......................................... 63
Окончание встречи....................... •••- ............ 67
После встречи ............................................................................. 67
Телефонные переговоры .......................................... 68
Переписка ............................................................................... 70
Групповые встречи .............................................................................71
Семинар рабочей группы (Requirements Workshop) ...........................72
Опросы....................................... 74
Другие способы получения требований ............................................ 76
Наблюдение за работой людей.................................................. . 76
Временное выполнение аналитиком текущей работы будущих
пользователей системы...................................................................78
Эксперты и консультанты ..............................................................79
Системы ............................................... 80
Документы ......................................................................................... 83
Обращения в службу поддержки ...................................................... 85
Прототипы ......................................................................................... 85
Опасные прототипы.................................. 88
Заключение ......................................................................................... 89
Глава 3. Работа с собранными требованиями .....................................91
С чего начинается хороший документ................................................. 92
Структура требований ........................................................................95
Текст требований ............................................................................... 97
Атрибуты требований ...................................................................... 102
Ключевые требования ...................................................................... 104
Ключевые критерии производительности ........................................ 105
Заключение ................................................................................... . 108
Глава 4. Проверка требований ............................................................ 109
Важность проверок ........................................................................... 109
Виды проверок...................................................................................110
Неформальные проверки коллегами (Peer Review) ..........................111
Критерии проверки текста требований ........................................... 113
Критерии законченного набора требований ................................... 114
Еще немного о проверках ................................................................. 114
Заключение................................................................ 116
Литература ...................... 117
Главные вопросы 5
IIIIIM IIlllllllilllllllllllllllllillllflllillllllllllllllllilllllllllin illllllillllllllllllllllllllllllllllllililllllllllllllllilllllllllllllttllllllllllllllllll

Предисловие
Моим учителям, научившим меня учиться.

Главные вопросы
В самом начале книги я постараюсь ответить на основные для
себя вопросы: «зачем?», «для кого?» и «что именно?». Итак, начнем:

Зачем
Вопрос «Зачем?». Это поистине самый главный вопрос аналитика.
Поэтому человек, который садится писать книгу, должен ответить
себе на вопрос «зачем?», если он все еще претендует на то, чтобы
считаться профессиональным аналитиком. Я взялся за эту работу
в первую очередь для себя, потому что мне важно доказать себе
самому, что я могу это сделать, что мне это нужно, мне это инте­
ресно. Сам, один, без принуждения, без денег, не рассчитывая ни
на что. С другой стороны, хотелось бы, чтобы то, что ты делаешь,
было бы полезно еще кому-то, поэтому я буду стараться сделать
книгу максимально простой и компактной, ибо сложных и больших
книг хватает. Возможно, к тому времени, как эта работа увидит свет,
будут доступны книги и лучше, и проще, но я попытаюсь написать
простую и полезную книгу. О том, насколько мне это удалось, су­
дить вам.

Для кого
Эта книга написана прежде всего для начинающих аналитиков,
работающих в проектах по разработке программного обеспече­
ния (ПО). Здесь и далее по тексту книги под аналитиками (IT-
аналитиками) я подразумеваю людей, ответственных за сбор и раз­
работку требований, независимо от того, какую еще работу они
выполняют. Надеюсь, эта книга будет также полезна другим специ­
алистам, занятым как разработкой ПО, так и разработкой любых
других систем (содержащих или не содержащих ПО). К ним можно
отнести инженеров, разработчиков, программистов, тестировщиков,
специалистов QA, специалистов службы поддержки, руководителей
проектов и других руководителей.
Я старался писать эту книгу так, чтобы она была понятна лю­
бому человеку, участвующему в разработке любой системы, как со
6 Предисловие
И 11Н Ш Ш 11| | 11М 1Ш 11Ш 1Ш Ш 11Ш 11Н Н 111Ш Ш 111Ш 111Ш 1М 1| 111111Н | Ш И 11111Ш 1Ш Ш Ш 1Ш М | 1| 1| | | | | | | 111111Ш 1| 1Ш | 111Ш М 111111М 111Н 1111

стороны заказника, так и со стороны команды разработки, незави­

симо от его образования и опыта. Однако стоит отметить, что опыт
участия в проектах по разработке систем вообще и ПО в частности
может существенно облегчить читателю понимание данного мате­
риала.

Что
Когда я провожу тренинги или читаю курс в академии, первый во­
прос, который я задаю аудитории: «Кто из вас делал успешные про­
екты без формальных требований, без документа, карточек и т.п.?»
Обычно поднимается несколько рук. Я поднимаю руку тоже. Да, я
делал успешные проекты без формальных требований, потому что
требования — это только инструмент, в умелых руках он помогает,
а в неумелых — нет. Можно сделать успешный проект и без формали­
зованных требований. С другой стороны, нет универсального механиз­
ма, универсального подхода, который бы детально, пошагово описывал
100%-но надежный путь получения успеха в проекте по разработке ПО.
Не ждите, что в этой книге вы его найдете. В ней вы можете найти
ряд важных, на мой взгляд, концепций, которые, возможно, помогут
вам улучшить понимание того, что происходит на вашем проекте,
и рекомендаций, которые, будучи примененными к месту, могут вам
помочь добиться лучшего результата. Такова жизнь.

Как читать эту книгу

Эта книга писалась так, чтобы читатель, прочитав эту книгу от
начала до конца, смог получить для себя максимальную пользу. По­
этому рекомендуется читать эту книгу именно таким образом.

Структура книги
Во введении обсуждаются вопросы общего характера, связан­
ные со сбором и формализацией требований, такие как: отноше­
ние к требованиям как к инструменту достижения успеха проекта,
определение проблемы и ее решения, связь требований и качества,
изменения требований в ходе проекта и т.д. Эта глава необходима
в книге для того, чтобы правильно расставить акценты и помочь
вам определиться, использовать ли вам требования на проекте или
нет. В заключение в этой главе кратко описывается процесс сбора
Ограничение ответственности 7
lllt lllllllltlt lH I II II I IIIIIIIIIIIIIH t lt llflt llt lllllt lllllllllllllt llllllfllllt llllllllllllllllllltlllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll

и разработки требований, который далее раскрывается в после­

дующих главах. Следующие главы книги дают ответы на вопросы:
• Кто такие заинтересованные стороны и как их определить, про­
блемы, цели и задачи заинтересованных сторон;
• Как собирать требования, общаясь с людьми и используя дру­
гие источники;
• Как писать требования и как их структурировать;
• Как проверять требования.

Ограничение ответственности
Книга основана на реальных событиях. Все имена вымышлены.
Все совпадения случайны.
Автор не несет ответственности за моральные страдания читателя
при прочтении этой книги.
Автор не несет ответственности за неумелое применение этой
книги читателем и нанесенный действиями читателя ущерб.
Все торговые марки и знаки принадлежат их уважаемым обла­
дателям.

Благодарности
Выражаю огромную благодарность всей моей семье, людям, ко­
торые поддерживали меня и вдохновляли на эту работу. Особенно
моей супруге Оле и брату Михаилу, принявшему также участие
в редактировании книги.
Большое спасибо Вадиму Арнольдовичу Перекреству — за то, что
поверил в меня и дал возможность преподавать, Елене Арсеньевой
за мои тренинги, Александру Байкину — за Летние Аналитические
Фестивали, отзывчивость и помощь.
Также выражаю свою благодарность людям, принявшим участие
в моем становлении и росте в профессии аналитика: Павлу Янов­
скому, Павлу Грачеву, Олегу Ночке, Александру Заровскому, Алексею
Емельянову, Алексею Мартынишину, Вагану Варданяну, Сергею Со-
рокопудову и Павлу Дранцеву.
Моя благодарность компаниям: VDI (и отдельно Анатолию Гавер-
довскому), «Ренессанс Капитал», «ВТБ Капитал», Epam Systems, «АТ
Консалтинг», Luxoft и другим компаниям, а также их сотрудникам,
которые терпели меня на протяжении многих лет.
8 Введение
1111Ш11111111|1|11111111Ш1111Н1111ШШ11111111Ш111И11Ш111111|1111111!|11ШШ11М1111Ш11111111111111Ш11ШММ1Ш11111М1М1111Ш1Ш1М11ШН

Введение
Однажды на конференции Better Software я имел удовольствие
слушать Карла Вигерса (Karl Wiegers) — автора книг и статей, посвя­
щенных требованиям. Человека, признаваемого всем !Т-сообществом
одним из столпов теории и практики управления требованиями. Его
доклад (в моем вольном переводе) назывался «Космические истины
о требованиях для ПО» (Cosmic Truths about Software Requirements).
Его выступление произвело на меня тогда сильное впечатление. Я
даже попытался его воспроизвести для своих коллег по слайдам
Карла, как только вернулся в Москву. Начиная писать эту книгу, я
подумал: а ведь это неплохая идея — начать с главного, чтобы по­
том на страницах книги шаг за шагом раскрывать, объяснять и ил­
люстрировать на примерах несколько простых, но важных истин:

№ 1. Первая простая истина, которую я давно осознал,

состоит в том, что многое уже придумано, и если так — зна­
чит, об этом уже где-то написано. Это нужно найти и про­
читать, чтобы применить для решения задач, стоящих передо
мной. (Не правда ли, звучит банально? ©) Иными словами,
не нужно изобретать велосипед, для того чтобы построить
велосипед. Я постараюсь изложить свой собственный опыт на
этих страницах, а также дать вам полезные, на мой взгляд,
ссылки, чтобы вам было что почитать и над чем подумать.
В то же время я не стал делать список литературы огромным,
потому что знаю: если список большой, никто им пользоваться
не станет (я, например, точно). Примеры из моего личного
опыта и опыта моих коллег выделены отступом и курсивом.

№ 2. Вторая простая истина заключается в том, что не су­

ществует универсального средства или шаблона, который бы
помог решить любую задачу, сделать любой проект. На прак­
тике это выражается в том, что существует великое множество
различных сред разработки и систем поддержки процесса
разработки, включая системы управления требованиями. Также
существует как минимум несколько популярных методологий,
определяющих тот или иной процесс разработки, и все они
применяются. Если взять, к примеру, требования, то вы мо­
жете найти несколько различных методологий и стандартов,
определяющих процесс разработки требований, шаблоны до­
кументов и т.п. У каждого средства, инструмента, методологии,
благодарности 9
Illlllllllllilllllllllllllllllillllin illlllllllllllllllillllllllllllllllllllllillllllllllllllllllllllllllllllilllllilllllllllllllllllllllllillllllllllllU iillllll

среды и т.п. находится немало сторонников и противников, по­

этому на страницах этой книги я не буду вам навязывать ника­
ких подходов, методов, средств и инструментов. Все, что я бу­
ду излагать, — это рекомендации, основанные на собственном
опыте и опыте моих коллег, которым я доверяю. Использовать
эти рекомендации или нет — это ваше дело. Более того, ес­
ли вы после прочтения этой книги решите вообще исключить
требования как формальный документ из своего процесса
разработки, это тоже ваше личное дело. Ведь не секрет, что
очень многим командам удавалось делать успешные проекты,
не имея на руках формального документа с требованиями.
Например, весь мир гибкой разработки ПО (Agile software
development) живет с карточками (User Stories), содержание
которых весьма и весьма далеко от формальных требований,
как их понимают многие авторы и описывают международные
стандарты.

№ 3. Еще одна простая истина состоит в том, что старые

проверенные средства работают. Лучше использовать их, чем
пытаться внедрить что-то новое и модное и при этом загубить
проект и свои отношения руководством с клиентом. Иными
словами, быть умеренным консерватором не так уж и плохо.

№ 4. Следующая простая истина заключается в том, что

в основе любого успешного проекта лежит хорошее взаи­
мопонимание заказчиков и исполнителей. И не секрет, что
работа аналитика во многом состоит в том, чтобы понимать
и правильно интерпретировать пожелания заказчика, а затем
передать это разработчику на понятном для него языке.

№ 5. А если вы согласились с тем, что в основе любого

успешного проекта лежит взаимопонимание, то следующая
неожиданная истина состоит в том, что работа аналитика,
собирающего требования, имеет мало общего с инженерной
работой. Сбор требований — это работа, похожая во многом
на работу доктора: проанализировать состояние больного —
поставить диагноз — предложить метод лечения. Перефрази­
руя известную поговорку про врачей, можно сказать: «Плох то
аналитик, от беседы с которым клиенту не становится легче».
При этом знания в технической области, несомненно, важ­
ны. В первую очередь — чтобы общаться с разработчиками,
10 Введение
lllllllllllllH llflllM IIIIIIIIIIIIIIIIIIIIIIH IIIIIIItlllllllllM llllllllllllllM llllltllllllllllllllllM IIIIIIH IIIIIIIIItllllllllllllllllM lllllllllllllllllllll

а также для понимания текущей ситуации на стороне заказ­

чика и анализа причин возникновения проблем.

№ 6. А теперь спросите себя: хотите ли вы доверить свое

здоровье доктору, который ничего не знает? Ответ очеви­
ден — нет. Тем не менее в моей практике я неоднократно
сталкивался с тем, что на позицию аналитика выдвигаются
люди, которые явно обладают недостаточными знаниями как
в предметной области проекта, так и в области применяемых
технологий разработки ПО. Это, на мой взгляд, серьезно ус­
ложняет задачу команды и увеличивает проектные риски (ко­
торые нередко просто перекладываются на плечи клиента
и разработчиков). А истина заключается в том, что аналитик
должен знать и предметную область проекта, и применяемые
технологии разработки.

№ 7. Отсюда мы можем плавно перейти к заключительной

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

Итак, эта книга — набор рекомендаций, но не догм, о том, в ка­

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

Что такое требования?

В этой книге требования рассматриваются в самом широком
контексте. Я намеренно не привожу определение этого понятия,
чтобы сразу же не загонять читателя в определенные узкие рамки,
характерные для той или иной методологии или стандарта. Под
требованиями можно понимать как цели, которых желает достичь
ваш клиент, так и формальную постановку задачи разработчикам.
Это могут быть как слова, произнесенные вслух, так и документ,
Коммуникация при разработке систем 11
iH iiiiiiiiiu iiu iiiiu iiiiiiiiiiiiiiiiu iiiiiH iiiiiiiiiiiim iiiiiiiiiiiiiiiiiiiiiiiiiiiU M iiiiiiiiiw iiiiiiH iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

разработанный по шаблону и соответствующий вашему строгому

регламенту. Любые бизнес-планы можно называть требованиями,
ведь это то, чего требуется достичь. Точно так же любую постано­
вочную часть проектной документации (например, спецификацию на
систему) можно называть требованиями, ведь это то, что требуется
сделать.
Естественно, такой подход в начале книги может напугать на­
чинающего аналитика, ожидающего простых и понятных примеров,
которые можно повторять на своих проектах, ожидая как минимум
положительного результата. Примеры, конечно же, будут. Просто
не стоит ожидать, что это будут самые лучшие и самые правильные
примеры, которые могут быть использованы в любом проекте с не­
изменным успехом. Любой пример, как и любой другой материал
из этой книги, стоит применять с умом и только в том случае, если
вы полагаете, что это принесет пользу.

Коммуникация при разработке систем

Коммуникация, несомненно, играет огромную роль при разработке
систем. Чем больше проблем возникает при общении, тем больше
шансов у команды провалить работу. Вспомните предание о Вави­
лонской башне. Господь дал людям разные языки, и они не смогли
завершить строительство. Однако даже один язык (например, рус­
ский) не является идеальным средством передачи информации. Вы
наверняка сами наблюдали ситуации, когда люди, разговаривая на
одном языке, не понимают друг друга. Поэтому чем меньше лю­
дей участвует в разработке и чем выше их взаимопонимание, тем
больше шансов на успех. Давайте теперь зададим вопрос с точки
зрения коммуникации: какая проектная команда будет самой эффек­
тивной? Ответ очевиден: самая эффективная команда — это один
человек, который сам себе ставит задачу и сам же ее реализует. На
мой взгляд, этот простой вывод объясняет взлеты многих одиночек
и их последующие падения. Разработав идею, воплотив ее в про­
дукт, человек далее не может эффективно развивать ее, поскольку
не справляется с коммуникациями, которых раньше просто не было.
В современном мире одиночкам очень мало места, и большин­
ство систем разрабатывается не одиночками, но коллективами, где
эффективные коммуникации просто жизненно необходимы.
Для того чтобы сделать коммуникацию наиболее эффектив­
ной, необходимо улучшить взаимопонимание всех, кто участвует
в процессе разработки. Тут можно пойти двумя путями: подбирать
 12 Введение
иипнннпипиммшншшипшшшшшшпшпншннншшншшшшпиишшпшшшшшшшнпннпшмшшнишнш

в команду людей, имеющих одинаковый опыт и знания, а также

упрощать язык общения — бороться с его неоднозначностью и бо­
гатством, чтобы сократить вероятность неверной интерпретации.
Первый подход достаточно очевиден и постоянно применяется.
Ведь люди, которые имеют общий опыт, начинают понимать друг
друга буквально с полуслова.
Второй путь тоже очень популярен. Издревле люди старались
формализовать общение при разработке систем, чтобы добиться
однозначного понимания всеми сторонами того, что будет в итоге
построено. Так появились чертежи и проектная документация, ис­
пользующие ограниченный словарь специальных терминов и гра­
фических элементов. Чем больше люди, участвующие в проекте,
разбирались в сути разрабатываемой системы, знали о приемах
проектирования, правилах построения чертежей, тем более эф­
фективной была коммуникация между ними в процессе работы над
системой. Но даже в этом случае нет гарантии, что все детали
будут учтены и заказчик не будет иметь претензий к готовому
изделию.
Однако оба этих метода зачастую могут быть применены внутри
проектной команды, но как только она сталкивается с заказчиком,
не обладающим похожим опытом и знаниями, проблемы в ком­
муникации возникают снова. Что с ними делать? Ведь проблемы
неэффективной коммуникации не учат решать ни в технических ву­
зах (откуда большинство из нас пришли), ни на тренингах по раз­
работке требования для ПО. Когда команда сталкивается с такими
проблемами, это легко заметить. Аналитик, приходя от заказчика,
начинает произносить фразы типа: «Какие они тупые!» или «Да
они космонавты!», а также обвинять впоследствии людей заказчика
в том, что «они не читают наши документы». Причина этого проста:
аналитик столкнулся с людьми, не имеющими ни общего опыта, ни
общих знаний с ним самим. Задача аналитика в этом случае со­
стоит в том, чтобы приблизить себя к этим людям, стать похожим
на них, обогатиться их знаниями и опытом, подстроиться под их
стиль, изучить их язык. Обратная задача — сделать представителей
заказчика похожими на аналитика, вложить в них аналогичные зна­
ния и опыт — вряд ли реализуема в рамках заказной разработки.

Область проблем и область решений

Для понимания аналитиком представителей заказчика важно
не только понимание их языка, глубокое знание их деятельно­

ft
Область проблем и область решений 13
iiiiiiiiiin iiiiiiiiiH iitiiillliiiiiiiH iik iiiiiiiiiiiiiiiiu iiiiiiiiiiiiiiiiiiiiiiiiiiiiitiiiiiiiH iiitiiiiiiiiiiiiiiiiu iiiiiiiiiiiiiiiiiiiiiiiiiiiitiu illiiflii

сти (или, как еще говорят, «предметной области»), но и, что более

важно, понимание их целей и задач.
Одна из самых опасных и, к сожалению, самых распространенных
проблем в области проектирования систем состоит в том, что лю­
ди не совсем понимают, для чего они разрабатывают те или иные
функции в системе.
Возникает она в основном оттого, что разработчики ожидают от
заказчика четкой постановки задачи в терминах системы (на языке
описания интерфейса и функций системы). Обыкновенно разработ­
чики стараются сразу начинать разговор с заказчиком с обсужде­
ния решения, т.е. системы, которую они будут разрабатывать или
дорабатывать для заказчика. Эта область очень комфортна для
них, ведь именно в ней разработчики являются специалистами.
Разработчик может начать общение с представителями клиента,
рассуждая примерно следующим образом: «Раз вы нас позвали,
следовательно, вам нужна система. Скажите, какая система вам
нужна?» Этот вопрос может поставить заказчика в тупик. Ведь если
говорить о разработке коммерческих приложений, обычно люди со
стороны заказчика делают свою работу, которая не связана с проек­
тированием систем, и им сложно определить, какая именно система
им нужна для решения их задач. Зачастую и заказчики ведут себя
соответственно — пытаются подстроиться под разработчика и объ­
яснить, какую систему они хотят получить, забывая о цели, которой
они хотят достичь с ее помощью.
На мой взгляд, необходимо всегда начинать с формулировки це­
ли, которую ставит перед собой заказчик, в терминах его бизнеса.

Например, заказчик может поставить цель:

• сократить операционные затраты на обработку и хранение
документов на 10 %;
• обеспечить сдачу регуляторной отчетности в сроки, уста­
новленные регулирующим государственным органом;
• увеличить клиентскую базу на 100 % за 12 месяцев;
• занять первое место в текущем году по объему продаж
в своем сегменте на российском рынке.

Такими терминами обычно оперирует руководство и владель­

цы предприятий. Такие цели принято называть требованиями
в области проблем или требованиями проблемной области.
оти цели можно далее детализировать в виде отдельных задач,
например:
14 Введение
1111Ш | | Ш 1Ш 11И 11Ш Ш П 1Ш 11Ш Ш 111Ш 1Ш Ш 11Ш 11Ш 11Ш Ш Ш 1Ш Ш И Ш Ш 1Ш Ш Ш 1Ш Н Ш Ш 1Ш 11Ш т Ш Ш 111Ш 1Ш Ш Ш Ш 11Ш 1Ш 1111

Цель: сократить операционные затраты на обработку и хра­

нение документов на 10 %.
Для достижения этой цели планируется решить следующие
задачи:
• снизить стоимость печати одной копии документа на
20 %;
• сократить среднее количество печатных копий документа
до 2;
• снизить затраты на хранение документов на 5 %.

Такие задачи очень редко доходят до IT-проектов. Почему?

С одной стороны, клиенты обычно не хотят разговаривать с людь­
ми из области разработки на эти темы (считают, что делиться
бизнес-задачами с ИТ-специалистами — это неправильно, потому
что в случае успешного достижения бизнес-цели ИТ якобы может
претендовать на свою долю в успехе), а с другой стороны, лю­
дям из мира разработки это не очень-то интересно (они зачастую
не хотят вникать в суть бизнеса, потому что им нравится решать
сложные технические задачи, и неважно, есть у бизнеса в этом
необходимость или нет). В результате мы получаем системы, кото­
рые не только не помогают компаниям добиваться успеха, а даже
совсем наоборот — система может стать непосильной ношей для
компании, не сокращая операционные затраты, а лишь увеличивая
их.
На Рис. 1 схематично показано, что для решения совокупности
задач из области проблем можно найти несколько решений. Более
того, я специально использую слово «решение», а не «система»,
поскольку может оказаться, что для достижения цели заказчика
совсем не обязательно разрабатывать систему. Возможно, стоит
ограничиться организационными мероприятиями для достижения
поставленных целей (например, написать инструкцию или приказ,
или ввести новую процедуру, или изменить форму, или нанять со­
трудника и т.п.).
Выбрав тот или иной подход к реализации решения для тре­
бований из области проблем, можно переходить к формулировке
требований для выбранного решения. Такие требования будем на­
зывать требования из области решения.
Давайте возьмем для примера одно требование из области проб­
лем и посмотрим, сколько можно придумать разных решений для
того, чтобы удовлетворить это требование. Этот пример я обычно
привожу на своих семинарах (Рис. 2):
Область проблем и область решений 15
M iiiH iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiin iiiw iM im iiiiiiiiiiiiiiiiiiiiim iiiiiiiiiiiiiiin iiiiiiiin iiin n iiiiiiiiiiiiiiiiitm H iiiiiiiiim iiiiiM iiitiii

Цель

Задачи
т
Область проблем

Область решений

Решение 1 Решение 2 Решение N

Рис. 1. Область проблем и область решений

Требование из области проблем может быть сформулиро­

вано так:
Продавец должен иметь возможность регистрировать
заказы.
Какие решения могут подойти для удовлетворения этого тре­
бования?
Аудитория обычно начинает с компьютерной системы (ПО).
Далее мы перебираем, какие же компьютерные системы могут
подойти для регистрации заказов продавцом (называются сай­
ты, бухгалтерские системы, CRM-системы, наконец MS Excel
и т.п.). После этого я прошу поразмыслить «пошире», и обычно
сразу появляется бумага и ручка в качестве решения (или д о ­
ска и фломастер, или, как вариант, доска и мел). Потом обычно
появляется телефон - продавец звонит кому-то и передает ему
информацию о новом заказе. Далее я прошу еще подумать, по­
являются счетные палочки и т.п. материальные способы учета
заказов (с помощью неких физических объектов), и останавли­
ваемся мы обычно на механических системах типа «Железный
Феликс». А однажды один из участников семинара мне сказал:
«Продавец и так может регистрировать заказы —для этого у не­
го есть голова (память) — не нужно никакого другого решения
для удовлетворения этого требования!»
16 Введение

С помощью этого простого примера легко убедиться в том, что

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

Рис. 2. Возможные решения для требования из области проблем

Количество требований и выбор решения

Используя данный пример, можно также прийти к выводу: чем
больше требований у клиента, тем меньше готовых систем можно
применить для реализации этих требований. Конечно, в опреде­
ленных пределах: при увеличении количества требований все еще
Область проблем и область решений 17

остается выбор готового решения. Это характерно в первую очередь

для хорошо регламентированных и распространенных задач, таких
как, например, бухгалтерский учет. Количество требований надо
воспринимать буквально, так как оно может расти по двум направ­
лениям: увеличение функциональных возможностей и ограничений,
налагаемых на эти возможности (проще говоря, «вширь»); увеличе­
ние требований по мере их детализации (проще говоря, «вглубь»).
При движении в любом из этих направлений теоретически идет
сокращение выбора готовых решений.
На Рис. 3 схематично показано то, как меняется количество вариан­
тов решений при увеличении количества требований. При количестве
требований, равном 1, вы можете выбирать от 0 до N готовых реше­
ний, решений на основе платформ или заказную разработку в широком
диапазоне компаний и применяемых средств разработки. При увели­
чении количества требований до N1 подходящих готовых решений уже
не остается, но еще остается возможность выбора ряда решений на
основе готовых платформ и заказная разработка в широком диапазо­
не. При увеличении количества требований до N2 пропадает возмож­
ность внедрять решения на основе готовых платформ. И наконец, при
увеличении количества требований до N3 даже возможность создания
заказного уникального решения может стать практически ничтожной.

количество
требований j i

О Ы ЫО -►
«оличестБо
реи*вний

Рис. 3. Сокращение выбора при увеличении количества требований

18 Введение
1111Ш 1Н 1Ш 111111Ш 111Н 11Н 11111Ш 11Ш 111111Ш 11Ш 11111Ш 11111111П 11Ш 111111Ш Ж 11111Ш 11111111Н 1111Ш | | | | 1| | 111Ш 1Ш Ш 11Ш Ш 111Н 11111Ш 1Н

Естественно, этот рисунок не отражает реальной зависимости,

а служит лишь для наглядной демонстрации концепции. В каждом
конкретном случае ситуация может отличаться от приведенной, для
одного набора требований график будет похожим, для другого об­
суждение сразу начинается с заказной разработки.

Проблемы, связанные с преждевременным переходом в область

решений
Проблема преждевременного перехода в область решений боль­
ше всего проявляется в сфере внедрения готовых пакетов ПО
и платформ. Это системы бухгалтерского и управленческого учета,
системы классов ERP (Enterprise Resource Planning) и CRM (Customer
Relationship Management), Intranet-порталы и т.д. Поставщик тако­
го решения обычно приходит со своей платформой, имея цель
продать (внедрить) ее клиенту. В результате все, о чем думает
поставщик, — это как продать систему клиенту, имея в виду уже
готовые функциональные возможности и имеющиеся доработки на
этой платформе. Это выгодно, поскольку позволяет продавать то,
что уже есть, проверено и хорошо работает. Нужно это клиенту или
нет — проблема клиента. В результате клиент может получить си­
стему, где половину функций он не будет использовать никогда, но
при этом, возможно, часть важных задач, стоящих перед клиентом,
не будет решена вовсе.
Хуже всего, когда готовое решение пытаются применить для реа­
лизации несвойственных этому решению задач. Поставщик системы
в этом случае постоянно вынужден бороться с ограничениями, за­
ложенными в архитектуру системы, в результате зачастую решение
получается дорогим и ненадежным. Воистину, если у вас в руках
молоток, то всякая задача вам будет казаться гвоздем.
Если заказчик не сформулировал свою цель в области проблем
и недостаточно детально разбил ее на задачи, он также может
столкнуться и с другими проблемами. Такая ситуация обычно описы­
вается разработчиками фразой «заказчик не знает, чего он хочет».
В такой ситуации нет никаких критериев для определения рамок
решения, что зачастую приводит к долгим согласованиям на этапе
заключения договора, а также к большому количеству запросов на
изменения и к большому количеству новых требований, поступающих
в ходе работы над проектом. Приемка системы в этом случае также
может превратиться в слабо сходящийся процесс (а проще говоря,
кошмар, который вы вряд ли захотите пережить второй раз).
управление ожиданиями заказчика 19
....... I l l ..................................................

С точки зрения заказчика, преждевременный переход в область

решений также приводит к тому, что в обсуждениях будущего реше­
ния начинают преобладать разработчики. Ведь это их территория,
тут они себя чувствуют комфортно, и заказчику обычно очень трудно
общаться с ними на одном языке. В таких ситуациях разработчики
легко склоняют представителей заказчика на свою сторону. С од­
ной стороны, может показаться, что это неплохо, ведь разработ­
чики знают свою работу (и поставляемую систему) и предлагают
только то, что будет работать. Однако на практике это не всегда
так. Разработчики всегда стараются быть на высоком профессио­
нальном уровне, что в том числе означает освоение новых сред
разработки, компонентов, методологий и т.п. В этом не было бы
ничего плохого, если бы эти технологии, методологии и компоненты
не обкатывались бы на реальных проектах с «живыми» заказчиками.
Новые технологии не всегда дают ожидаемый эффект, не всегда
разработчики правильно оценивают свои возможности по быстрому
освоению и применению этих методологий. В итоге может полу­
читься (и неоднократно получалось в моей практике), что навязан­
ные разработчиками новые технологии приводили к проблемам на
этапе реализации и сдачи системы. В области внедрения готовых
платформ мне неоднократно приходилось сталкиваться с тем, что
специалисты со стороны поставщика просто не в состоянии доско­
нально знать поставляемую систему, поскольку она очень сложна,
имеет закрытый код и часто меняется. Они физически не в силах
на начальных этапах проекта наверняка ответить на вопрос: «воз­
можно ли это сделать в системе?». Они вынуждены соглашаться,
что в дальнейшем приводит к большим проблемам.

Управление ожиданиями заказчика

Во многих книгах по управлению требованиями можно встретить
ссылки на статистику о причинах провалов проектов. Среди оче­
видных причин провалов проектов, связанных с аналитиком и его
работой, называют пропущенные заинтересованные стороны, низкое
вовлечение реальных пользователей в проект, пропущенные или
неоднозначно сформулированные требования и т.д. У аудитории на
моих курсах обычно не возникает никаких вопросов по этим пунктам.
Подробнее приходится обсуждать другой пункт — нереалистичные
ожидания заказчика. Почему же в этом виноват аналитик?
На самом деле все достаточно просто. Дело в том, что ана­
литик — это тот человек, который, общаясь с представителями
20 Введение
Ш 11111П 1М 111| 1Ш 11Ш 111Ш 1111111Ш 11Н 1Ш 111Н 1111Ш 111111Ш 1Ш 1Ш Ж 1Ш 1111Ш 1Ш Н 111П Ш 1111Ш 11! Ш 11111Н М 11111! 1Ш 1111111Ш Ш 111Ш Ш 11

заказчика, формирует ожидания. Если он очень компетентен в пред­

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

Типы требований
В литературе, посвященной проектированию систем и разработке
требований, существует несколько вариантов типизации требований.
Наиболее часто речь идет о следующих типах требований: требо­
вания заинтересованных сторон, бизнес-требования, пользователь­
ские требования, функциональные требования, нефункциональные
требования, системные требования, технические требования, до­
полнительные требования и т.д. и т.п. Все эти, а также другие типы
требований необходимы, на мой взгляд, для того, чтобы помочь
аналитику правильно определить степень детализации, или, как еще
говорят, глубину проработки требований, а также объем и границы
документа. В некоторых случаях типы требований определяют также
точку зрения, на основе которой данные требования формулируются.
Такие типы требований обычно определяют вертикальную иерархию
документов. Например, после разработки требований заинтересо­
ванных сторон команда может перейти к определению задачи в тер-
iwewitttsry-toeeww*
Типы требований 21
ll lllilH I I U I iin H llllllU I II IH Ilt llliU t lllllilM llllllllllllllllllllllllllllilU I II H lllilllllllllU IU I II II I IU I II IillllllllllilllllllilllU lllllillllU U I II

минах реализации и для этого приступить к разработке системных

требований.
В этой книге я не буду навязывать вам никакой типизации тре­
бований. Вы можете пользоваться любой удобной для вас терми­
нологией и писать требования тех типов, которые вам необходимы
или предписываются вашим процессом разработки.
Однако для любого из перечисленных типов требований есть еще
одна типизация — горизонтальная. При работе над требованиями
любого типа аналитик должен четко понимать, что ему необходимо
собрать требования, определяющие возможности, которые заказчик
должен получить, а также требования, являющиеся ограничениями,
которые будут накладываться на эти возможности.
22 Введение
1111М 11Ш М 11| | 111Н 1М 1М 111111Ш 1Ш 11111111М 1Н 1111111111| 1Ш 111Ш 1Ш 11111111111Ш 1111Н 1М Ш 111Ш 1111111111М 11| | | | | | 11Ш Ш 11Ш 1111Ш 1Ш 1П 11111

Юрий Булуй сделал подробное сравнение типизации требо­

ваний в своем докладе на конференции SEC-R2006[5], Он срав­
нил подходы к типизации требований, предлагаемые Карлом
Вигерсом, Дином Леффингуэллом, а также отношения к клас­
сификации в методологиях IBM RUP (Rational Unified Process),
IEEE SWEBOK (Software Engineering Body of Knowledge) u ГОСТах
серии 34. Любопытный читатель может найти в Интернете пре­
зентацию и статью Юрия, посвященные этой теме. Однако хочу
заметить, что начинающему аналитику вряд ли придется зани­
маться разработкой структуры проектной документации в своей
компании, поэтому общая рекомендация состоит в том, чтобы
следовать принятой в вашей компании методологии, предписы­
вающей состав и структуру проектной документации.

В книге будут рассмотрены возможности и ограничения приме­

нительно к области проблем и точно так же — возможности и огра­
ничения применительно к области решений.

Требования и качество
Качество продуктов, которыми мы пользуемся каждый день, для
любого из нас является важным. При этом для разных продуктов
мы пользуемся разными критериями оценки качества или сравне­
ния их между собой. Зачастую мы не осознаем этих критериев, мы
пользуемся ими бессознательно или даже не пользуемся вовсе.
Сейчас в любом обыкновенном продуктовом магазине большинство
продуктов питания герметично упакованы. Мы не можем попробо­
вать продукт, почувствовать его запах или даже увидеть, как он на
самом деле выглядит внутри упаковки, пока мы его хотя бы один
раз не купим. Поэтому первый раз мы вынуждены делать выбор по
упаковке, что, несомненно, не дает нам никаких гарантий того, что
мы купим самый лучший, самый свежий и самый вкусный продукт
из предложенных. То же самое касается и сложных технических
систем: автомобилей, бытовой техники, электроники, телефонов,
компьютеров — зачастую выбор делается, исходя из внешнего вида
изделия, его рекламного описания, навязанного продавцом мнения,
и, что происходит гораздо реже, человек подходит к выбору с опре­
деленными критериями, или, иными словами, требованиями.
Если перейти от бытовых проблем с определением качества
продуктов в область разработки ПО, то мы можем отметить, что
в индустрии разработки ПО использование термина «качество» в ос-
Требования и качество 23

новном связано с тестированием и наличием того или иного коли­

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

На одном из своих проектов я запретил разработчикам писать

обработчики ошибок. Почему? Потому что это никому не было
нужно. Мы как заказчики не видели никакой пользы в том, что
система сообщит пользователю дружественным текстом о том,
что она сломалась. Вместо того чтобы потратить деньги на раз­
работку и тестирование обработчиков ошибок с «дружественным
для пользователя текстом», мы предпочли пустить ресурсы на
более важные для нас задачи. А если система потом «падала»
с недружественным для пользователя сообщением об ошиб­
ке — что ж, разработчикам было еще проще разбираться с тем,
что же на самом деле произошло. Но при этом пользовате­
ли понимали, почему так ведет себя система, и поддерживали
этот осознанный выбор: «Оно пускай и некрасиво, зато дешево
и практично». Никто не говорил, что система некачественная, по­
тому что она не показывает понятные пользователям сообщения
об ошибках Все хотели скорее получить свои требования реали­
зованными в системе и скорейшего исправления обнаруженных
ошибок, если они мешали работе.

Для того чтобы проектная команда не тратила время и другие

ресурсы на работу, которая будет никому не нужна, и в то же
время заказчик получил то, что соответствует его критериям каче­
ства, необходимо, чтобы у проектной команды и у заказчика бы­
ли одинаковые представления о том, что же такое качественный
продукт. По моему опыту, обычно это достигается после 2-3 лет
совместной работы заказчика и поставщика или не достигается во­
все. Если заказчик и поставщик довольны друг другом — значит,
общее понимание того, что же такое качественный продукт, скорее
всего уже достигнуто. Если у вас нет желания рисковать и тратить
пару лет на достижение взаимопонимания, вам наверняка понадо­
бятся какие-то инструменты, позволяющие договориться о том, что
24 Введение
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIM IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIM IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII

такое качественный продукт, немного быстрее. Требования и другая

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

Требования и моделирование
Моделирование, несомненно, наиболее интересное и увлекатель­
ное занятие в работе аналитика. Большинство аналитиков, с ко­
торыми я работал, любили рисовать диаграммы, строить модели.
Многие авторы книг о разработке требований солидарны в этом
наблюдении, и тем более авторы книг о моделировании.
Однако хочу сразу предостеречь читателя. Основная ошибка мо­
лодых аналитиков состоит в том, что они стремятся смоделировать
абсолютно все. Это само по себе любопытно и увлекательно, но
вопрос состоит в том, полезно ли это для вашего проекта.
Задача аналитика состоит в том, чтобы помочь людям решить их
проблемы. Если модель помогает — значит, аналитик хорошо и про­
фессионально делает свою работу, если модель не помогает — зна­
чит, он просто выбрасывает деньги на ветер (обычно чужие деньги).
Для того чтобы ответить на вопрос, что же такое хорошая мо­
дель, давайте сначала дадим определение модели.
Модель — это упрощенное представление системы или про­
цесса, при этом внимание автора модели должно быть сосредо­
точено на определенных характеристиках системы или процесса,
а от всех остальных он должен абстрагироваться.
Если автор модели воспроизведет абсолютно все характеристики
моделируемого объекта, то он получит не модель, а собственно сам
моделируемый объект.

Если кто-то строит модель самолета в натуральную величи­

ну, при этом модель самолета воспроизводит абсолютно все
характеристики самолета, это значит, при удачном стечении об-
Требования и моделирование 25
( iiiiiiiiiiiiiiiiiM H liiu iiiiu iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiu iiiiiiiiH iiu iiiiiiiiiM im iiiiiiiiiiiiiiiiu iiiiiiiit iiiiiiiiiiiiiiiiiiH iiiiiiiiiiiiiiu ii

стоятельств в результате такого моделирования будет построен

самолет (а не модель самолета).

Так что же такое хорошая модель? Хорошая модель — это модель,

помогающая аналитику в его работе. Каждая модель должна иметь
строго определенную задачу, для которой она разрабатывается.
Модели могут применяться для:
• формулировки требований;
• проектирования решения;
• помощи аналитику в понимании автоматизируемого процесса
и структуры организации;
• помощи аналитику в понимании того, как работает текущее
решение;
• подключения визуального канала собеседника в процессе сбора
требований и обсуждения решения.
Задачи моделирования можно условно разделить на две группы:
для внутреннего пользования и для общения. С одной стороны,
аналитику нужны модели для того, чтобы ему самому было удобно
работать, наглядно представить ситуацию, структуру, процесс, систе­
му, чтобы он мог убедиться в том, что ничего не пропущено, в том,
что нет противоречий, потери информации и т.п. С другой стороны,
аналитику нужны модели для общения с представителями заказчика,
разработчиками, тестировщиками, при этом модель может служить
как формальным документом для передачи знаний, так и вспомога­
тельным инструментом для улучшения взаимопонимания участников
проекта и получения нужной аналитику информации.
Важно понимать: если модель описывает только определенные
характеристики моделируемого объекта или процесса, то это значит,
что один и тот же объект или процесс может быть смоделирован
множеством разных способов во множестве моделей. При этом
модели могут отличаться не только задачей, для которой они соз­
даются, но и способом реализации (иными словами, применяемым
языком моделирования и инструментом моделирования). На практи­
ке это выражается в том, что аналитик может построить несколько
моделей для одного проекта, каждая из них будет отражать только
какую-то часть информации, и необязательно они будут выполнены
в одной среде моделирования с использованием только одной но­
тации. Это нормально, не нужно стремиться все и вся моделировать
одном-единственном языке в одном доступном вам средстве,
омните, для ряда задач вполне подойдут листок и карандаш плюс
Ваше умение рисовать понятные собеседнику картинки.
26 Введение
iiiiiiiiiiM iiiiiiiiiiiiiiiiiiiiiiiiiiiiitiiiiiiiiiiiiiiiiitiiiiiiiiM iiiiiiiM iiiiiiiiiiiiiiiiiiiiiH iu iiiiiiiiiiiiiiiiiin iiiiiiiiitiiiiiiiiiiiiiiii iiiitiiiin i

В отрасли разработки ПО, к сожалению, есть масса примеров,

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

Требования и изменения
Самое плохое, что можно сказать об изменениях, так это то, что
они происходят. И самый лучший способ борьбы с изменениями —
это планомерная подготовка к ним. Задача аналитика, несомненно,
состоит в том, чтобы разработать такую проектную документацию
и такие требования, которые позволят максимально сократить коли­
чество запросов на изменения в ходе разработки. Как говорилось
выше, это возможно только при условии понимания командой раз­
работки целей и задач заказчика.
Тем не менее даже если на этапе сбора и разработки требо­
ваний такое взаимопонимание было достигнуто и документально
оформлено, нет никакой гарантии, что запросы на изменения не по­
явятся в ходе разработки или на этапе ввода системы в промыш­
ленную эксплуатацию.

Источник изменений — заказчик

Первый и самый главный источник запросов на изменения — это
заказчик. В случае если между проектной командой и заказчиком
есть контрактные отношения, лучше всего договор на разработку
дополнить формальной процедурой внесения изменений. Данная
процедура внесения изменений должна описывать действия сто-
Требований и изменения 27
........ Illllllllllllllllllllllllll

рон, в случае если у одной из них возникает необходимость внести

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

Рынок как источник изменений

Другая причина появления запросов на изменения — это рынок.
Представьте себе ситуацию, когда ваша компания собирается вы­
йти на рынок с новой версией системы, которая будет содержать
уникальный набор новых функциональных возможностей, которых нет
ни у одного из ваших конкурентов. Вы трудитесь над разработкой
этой новой версии, но в какой-то момент, пока вы еще находитесь
на этапе разработки, ваш конкурент выпускает что-то похожее на то
что вы еще только разрабатываете. Вы моментально оказываетесь
в роли догоняющего. В такой ситуации ваше руководство наверняка
захочет отложить запланированный запуск и подумать, что же можно
еще добавить в новую версию или изменить в ней, чтобы это дало
вашему продукту (и вашей компании) конкурентные преимущества
в изменившихся рыночных условиях.
Существуют также и другие ситуации, связанные с изменением
рыночных условий, которые приводят к появлению запросов на из­
менения. Это и изменения законодательства, и новые требования
от регулирующих органов, и изменения продуктовой линейки вашего
клиента, и другие ситуации, которые на этапе сбора и разработки
требований достаточно тяжело прогнозировать.
28 Введение
iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiM iiiifiiiitiiiitiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiM iiiiiiiiH M iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiin iiii

Тем не менее аналитик должен стараться предвидеть подобные

изменения и помочь руководителю проекта (продукта) и своей ко­
манде правильно спланировать свою работу исходя из тех рисков,
которые он видит.

Разработчики как источник изменений

Запросы на изменения могут поступать не только со стороны
клиента, источником запроса на изменения могут стать также разра­
ботчики и субподрядчики. Мы уже упоминали выше при обсуждении
проблем, с которыми приходится сталкиваться проектной команде
при преждевременном переходе из области проблем в область ре­
шения, что технологии разработки ПО развиваются очень быстро.
У хороших разработчиков всегда есть желание быть в курсе всех
новых технологических веяний. Велик соблазн попробовать новую
платформу, компонент или средство разработки, сулящие те или
иные преимущества. Это, к сожалению, не всегда приводит к ожида­
емому положительному результату. Недостаток консерватизма в вы­
боре технологической платформы, компонентов и инструментальных
средств для разработки может привести к тому, что ряд согласован­
ных требований не удастся реализовать в рамках первоначальных ;
оценок (сроков и денег) и, следовательно, придется согласовывать
изменения требований и/или календарного плана проекта.

У меня был один показательный в этом смысле проект, где

и заказчик неоднократно послужил источником изменений,
и разработчик, что называется, не остался в долгу.
Мы внедряли внутренний корпоративный портал. В качестве
заказчиков выступали четыре отдела компании. Каждый из от­
делов выдвинул свой набор требований, которые они хотели
бы реализовать во внутреннем информационном пространстве
компании. За четыре месяца, пока шел проект, поменялись
ключевые представители заказчика в трех отделах из четырех.
Даже при наличии четких формальных требований всегда очень
тяжело сдавать проект не тому человеку, с которым вы начинали
проект, а новому, который, может быть, еще и не понял толком,
куда он попал на работу, а тутсистему нужно принимать.
Кроме того, разработчики через некоторое время осознали,
что часть запрошенных функциональных возможностей на вы­
бранной портальной платформе они реализовать не успевают,
поэтому сначала попросили больше времени. Потом разработчи-
другие характерные трудности 29

ки поняли, что часть функциональных возможностей они не могут

реализовать и в дополнительное время, поэтому попросили еще
времени и денег. Чего, естественно, им уже никто не дал.
В результате была внедрена только половина из того, что бы­
ло запланировано изначально. Времени было потрачено больше,
чем первоначально планировалось. Также пришлось дополни­
тельно к портальной платформе внедрять еще одну систему, для
того чтобы удовлетворить часть нереализованных в портале тре­
бований. Поставщик на проекте был заменен на другого, чтобы
завершить разработку тех требований, которые, как оказалось
на выбранной платформе, все-таки было возможно реализовать.

Другие характерные трудности

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

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

Дин Леффингуэлл [3] пишет об этой проблеме иносказатель­

но как о синдроме «нераскопанных руин». Один из его друзей
работал гидом на автобусе, который возил туристов по США
и в том числе посещал древние руины Анасази на юго-западе
США. В течение туристического сезона самым любимым глупым
вопросом, который он слышал от туристов тысячу раз, стал:
«А сколько еще здесь неоткрытых (нераскопанных) руин?»

Вот и аналитик находится приблизительно в такой ситуации, когда

°н должен предсказать, сколько еще нераскопанных руин осталось.

У меня есть много знакомых аналитиков фондового рын­

ка, один из них сказал так: «Я аналитик, это значит, что моя
30 Введение
iiiiiiiiiiiiiiiiiiiiiiiiiifiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiifiiiiiiiiiiiiiiiiiiiiiiiiiiin iifiiiii

работа — предсказывать будущее». Я сначала улыбнулся, а по­

том подумал, что работа аналитика, участвующего в разработке
ПО, в отличие от работы аналитика фондового рынка, состоит
в том, чтобы будущее проектировать...

Итак, что же делать аналитику, чтобы давать оценки, в которые

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

Разный культурный и образовательный уровень участников проекта

Одно из самых интересных открытий, ожидающих начинающего
аналитика на его пути, состоит в том, что люди отличаются друг от
друга, причем довольно сильно. Особенно сильно аналитик удивляет­
ся тому что люди разные, если он успел поработать внутри проектной
команды несколько лет и не общался с представителями заказчика
из других предметных областей (бизнес которых не связан с раз­
работкой ПО или любой другой инженерной деятельностью). Откуда
обычно приходят IT-аналитики? Это или бывшие разработчики, или
бывшие тестировщики, реже люди из бизнес-подразделений стано­
вятся аналитиками в IT, и редко кому также удается прямо со студен­
ческой скамьи стать аналитиком. Когда человек, работающий в среде
единомышленников, обычно имеющих высшее техническое образо­
вание, в среде специалистов в определенных технологиях, читающих
одни и те же сайты (плюс книги, фильмы, музыка и т.п.), попадает
в другую культурную среду, он невольно начинает искать аналогии
и пытаться общаться на своем языке с представителями заказчика.
Это, как правило, не работает. Перед аналитиком может оказаться че­
ловек, который каждый день ворочает тоннами денег (нефти, метала,
и т.п.), или человек «старой закалки» предпенсионного возраста, или
достаточно молодой человек, не имеющий ни высшего образования,
ни богатого опыта. Аналитик должен готовить себя к таким встречам,
это часть его работы. Аналитик должен уметь общаться с любым че­
ловеком, который будет представлять заказчика. Не стоит ожидать,
что со стороны заказчика всегда будет достаточно о б ра зов ан н ы й
в техническом плане человек того же возраста, что и сам аналитик.
другие характерные трудности 31
.

Культурный и образовательный уровень различных представителей

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

Противоречия
Следующая трудность, которая поджидает аналитика на его нелег­
ком пути, — это противоречия. Противоречия могут быть где угодно.
Первый источник противоречий — это разный культурный и образо­
вательный уровень людей, о котором я писал выше. Другой источник
противоречий — различная мотивация. Руководство компании заказчика
может хотеть того, чего не хотят исполнители или управленцы средне­
го звена. Руководитель проекта со стороны разработки может хотеть
получить как можно больший бюджет, а соответственно и длительность
проекта, с чем могут быть не согласны представители заказчика. Пред­
ставители заказчика и разработчики могут отстаивать различные точки
зрения относительно применяемых технологий разработки, а также по
другим техническим вопросам. Этот перечень можно продолжать до
бесконечности. Все эти люди будут пытаться добиться от аналитика
поддержки их точки зрения, а уж человеку, который платит аналитику
заработную плату (его непосредственному руководителю), это делать
будет, несомненно, легче всех. Задача аналитика в таких ситуаци­
ях — сохранять свою независимость. Для этого всегда нужно идти от
цели проекта, не принимая лично ничьей стороны. Профессионализм
аналитика как раз и проявляется в том, чтобы в условиях морального
Давления он был способен методично фиксировать те требования, ко­
торые способствуют достижению цели проекта, отбрасывая те, которые
никак не связаны с целью проекта и решаемыми бизнес-задачами.

Использование естественного языка

Другая трудность связана с культурой использования естественного
языка (например русского). При написании текста требований у людей,
хорошо владеющих русским литературным языком, наступает «культур-
ный диссонанс». Им очень трудно писать требования, где все шаблон-
Но>и каждое требование начинается с тех же слов, что и предыдущее.
32 введение
lllllllllllllllllllin illllllltlllllltllllltllllllllllllllllilllilllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllfllllllltllllllllK lllllllllllt

Вот, например, выдержка из требований, написанных в ху­

дожественном стиле (с некоторыми косметическими правками
при переводе с английского на русский). Текст максимально
близок к оригинальному, в фигурные скобки я поместил свои
небольшие уточнения:

1.4. Пользователь должен иметь возможность

определить Индустрию для Компании.
1.4.1. Новое поле с названием «NACE Код Инду­
стрии» должно быть добавлено на закладу Кредитные
Риски для этой цели {в системе}.
1.4.2. Это поле должно представлять иерархиче­
скую структуру: первый символ кода, затем должны
отображаться следующие два символа кода (там где
они есть в иерархии), затем другие две цифры из спи­
ска (которые содержат указание на сектор индустрии),
затем показываются 3 цифры из листа, и затем по­
казываются 4 цифры, завершающие код индустрии.
Пользователь должен иметь возможность выбирать
начиная с любой части NACE иерархии для заполнения
этого поля. Заполненные поля будут включены в вы­
грузку данных для Adaptiv {внешняя система}.

Что мы видим в этом примере — буквально со второго требо­

вания душа автора просит связки. Обратите внимание, что второе
требование начиналось вполне неплохо (несмотря на преждевре­
менный переход в область решения, ведь это должны были быть
требования из области проблем), однако в конце добавляет: «для
этой цели». Третье требование, как вы сами можете убедить­
ся, начинается со связки — «это поле». Кроме того, совершенно
очевидно, что третье требование нуждается не только в работе 1
над текстом, но и в разделении его на несколько отдельных тре­
бований.
То, как лучше писать текст требований, будет рассмотрено I
подробно в главе «Работа с собранными требованиями», сейчас J
же отметим, что с такими требованиями очень трудно работать.
При удалении, добавлении или изменении любого требования
придется менять еще и соседние, при этом неважно, нужно ли
менять их по смыслу, но в данном примере уже форма изложения ']
будет обязывать автора обращать внимание на соседние тре- \
бования. Таким образом, аналитик, автор этих требований, по- j
другие характерные трудности 33
п т » п и и т ......... ш ш ш п и ш ...........

тенциально создал себе дополнительную работу. Чтобы не быть

голословным, проиллюстрирую, как эти же требования могли бы
выглядеть:

1.4. Пользователь должен иметь возможность опре­

делить параметр NACE Код Индустрии для Компании.

{раз уж мы спустились на уровень системы, мы описываем

новые поля, зачем плодить два требования? 1.4.1. в оригиналь­
ном виде удаляем.}

1.4.1. Пользователь должен иметь возможность вы­

брать NACE Код Индустрии с любого уровня иерархии
NACE.

{Нет смысла переписывать структуру стандартного справоч­

ника в требованиях, на него можно сослаться в начале докумен­
та в разделе «Ссылки»)

1.4.2. Поле NACE Код Индустрии должно быть до­

бавлено в выгрузку данных для Adaptiv.

Таким образом, мы получили более независимые друг от

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

Другая проблема, связанная с использованием естественного

языка для написания требований, состоит в том, что любой есте­
ственный язык, а уж русский-то наверняка, гораздо менее формален,
например, чем любой из языков программирования. Аналитик посто­
янно вынужден бороться с неоднозначностью, заложенной в самой
системе языка, должен стараться добиваться таких формулировок,
которые бы не допускали неправильной интерпретации ни со сторо­
ны представителей заказчика, ни со стороны команды разработки.

Возьмем, например, слово «продукт». Для представителей за­

казчика это слово может означать вид услуги, которую они оказы­
вают своим клиентам, или выпускаемый ими товар; для разработ­
чиков это слово может означать разрабатываемую ими систему.
34 Введение
Illlllllllll .

Или, например, слово «клиент». Разные представители за­

казчика могут под этим словом подразумевать абсолютно раз­
ные вещи: одни клиентом считают человека (Иван Иваныча),
с которым они общаются (это обычно кто-то из представителей
другой компании, уполномоченный вести дела с контрагентами),
другие — компанию, с которой у их компании есть деловые от­
ношения, третьи — только те компании, для которых у них отрыт
счет (если, к примеру, это банк). Для программиста слово «кли­
ент» обозначает обычно приложение, работающее с сервером.
С другой стороны, представители заказчика, да и проектная
команда могут называть одну и ту же вещь разными словами.
Например, слова «клиент», «компания», «фирма», «предприятие»,
«контрагент» могут относиться к одному и тому же ООО «Ро­
машка».

Если аналитик будет употреблять в требованиях слова, допуска­

ющие неоднозначные трактовки в контексте документа, или употре­
блять синонимы тех или иных терминов, это наверняка приведет
к проблемам. Несомненно, проблем с неоднозначностью, заложенной
в самом языке, гораздо больше, чем я привел в своих примерах.
Другая проблема, с которой постоянно сталкиваются аналитики
при использовании русского языка для написания требований в об­
ласти решений, — это отсутствие однозначной общепринятой рус­
ской терминологии для разработки ПО. Check-box переводят и как
«флажок», и как «галочка», и как «признак», или еще как-нибудь.
Combo-box просто никто не переводит на русский (вы бы, наверное,
быстро устали от документа, где Combo-box описан по смыслу —|
«поле для ввода с выпадающим списком»), а все так и пишут
«комбо-бокс» и т.д.

Мой опыт сложился таким образом, что я практически все

время работал с англоязычными поставщиками и/или с англо- 1
язычными заказчиками. Несомненно, английский язык гораздо ■
больше подходит для написания требований. С одной стороны
там значительно меньше проблем с терминологией в области
решений, а с другой стороны, английский менее гибок в плане
порядка расположения членов предложения: никто не удивится,
если в каждом вашем предложении подлежащее всегда перед А
сказуемым и оба присутствуют в начале каждого предложения, л
Тем не менее и английский язык достаточно богат, чтобы не бытьJ
однозначно интерпретируемым. Уж синонимов-то там в избытке.
другие характерные трудности 35

О бъем и глубина проработки требований

Как мы рассматривали ранее, требования разрабатываются как

«вширь», так и «вглубь». Следующая трудность, с которой сталки­
ваются начинающие аналитики, — это определение объема тре­
бований. С этим проблемы обычно возникают, когда нет четкого
понимания границ поставленной задачи, а это возникает в тех слу­
чаях, когда нет понимания целей и задач, которые стоят перед за­
казчиком. Т.е., если говорить простым языком, аналитик не знает,
где же остановиться в смысле «вширь». Таким образом, понимание
целей и задач, стоящих перед заказчиком (или четких границ за­
дачи по бизнесу), дает аналитику критерий оценки, что включать
в требования, а что нет.
Другая проблема — определение глубины проработки требо­
ваний. Обычно начинающие аналитики смотрят на своих старших
товарищей и делают так же. Т.е. пишут документы с той глубиной
проработки требований, которая принята в их компании или в их
команде. Отсюда возникает вопрос: а как «старшие товарищи»
определили эту самую глубину проработки требований (а также
стиль их написания)? Полагаю, что на основе собственного опыта:
писали очень детально — никто не читает, писали более сжато
и абстрактно — не удалось до разработчиков донести детали, полу­
чили проблемы при приемке. Таким образом, каждая команда (или
организация) сама устанавливает для себя оптимальную глубину
детализации требований. Если у вас нет «старших товарищей» или
сложившейся культуры разработки проектной документации, то вам
придется решить этот вопрос самостоятельно. Критерий дости­
жения оптимальной проработки требований тут можно сформули­
ровать так: людей, которые должны работать с этим документом,
не пугает его объем, и в то же время они находят в документе
все необходимые детали для того, чтобы сделать свою работу:
представители заказчика — для согласования документа, разработ­
чики — для разработки системы, тестировщики — для разработки
и выполнения тестов. Поэтому имеет смысл как можно раньше
обсуждать требования с заказчиками, разработчиками и тестиров­
щиками, чтобы понять, какая глубина проработки требований для
них комфортна.
®то Далеко не полный перечень проблем, с которыми сталкива-
. ся аналитики в своей работе. Мы будем еще не раз возвращаться
Щ обсуждению на протяжении всей книги.
епеРь вкратце опишем этапы процесса разработки требований.
36 Введение
iiiiiiiiiiftiiiiiiiiiiiiiiiiiiiiik iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiitiiiiiifiiiitiiiiliiiiifiiiiiiiiiiiiiiiiiitiin iiiiiiitiiiiiiiiiiiiiiH iiiiiiiiiiiiiiitiiiiiiiiii

Обзор процесса разработки требований

Процесс разработки требований начинается с определения за­
интересованных сторон. Аналитику важно понять не только то, кто
заказчик, но и кто еще заинтересован, а также определить про­
блемы, которые необходимо решить, цели и задачи, определяющие
рамки будущего решения. Этому будет посвящена глава «Опреде­
ление заинтересованных сторон и их представителей».
Помимо заинтересованных сторон и их представителей аналити­
ку необходимо определить также и другие источники требований.
С этой темы мы начнем главу «Сбор требований». Далее в этой
главе будут подробно рассмотрены методы работы с различными
источниками требований.
В следующей главе — «Работа с собранными требованиями» —
мы рассмотрим вопросы, связанные с документированием собранных
требований.
Далее в главе «Проверка требований» представим различные
виды проверок требований, уделив особое внимание согласовани­
ям с представителями заинтересованных сторон и разработчиками,
а также проверке требований в команде аналитиков.
Заинтересованные стороны в проекте 37

Глава 1. О п р е д е л е н и е за и н тер есо в ан н ы х

сторон и их представителей

Заинтересованные стороны в проекте

Прежде чем определить представителей заинтересованных сторон
в вашем проекте, неплохо бы задать себе вопрос: «А кто в прин­
ципе может быть заинтересован?» Я себе отвечаю на этот вопрос
следующим образом:
Заинтересованные стороны — это государства, организации,
отдельные люди или группы людей, а также системы, которые
могут прямо или косвенно быть заинтересованы в результатах
проекта, или, если результаты проекта либо ход его выполнения
прямо или косвенно влияют на них (как положительно, так и от­
рицательно).
Важно отметить, что помимо людей и организаций различных
видов в число заинтересованных сторон входят также и системы.
Также стоит отметить, что аналитику необходимо общаться не только
с теми, кто заинтересован в результатах проекта, но и с теми, кто
будет участвовать в проекте, но не заинтересован в его результатах.

Давайте рассмотрим простой пример. Проект по забиванию

гвоздя в стену. Итак, вас попросили забить в стену гвоздь. Какие
можно заинтересованные стороны тутназвать:
1. Тот, кто попросил (мама, папа, жена, теща, сын, дочь
и т.п.) — ему (или ей) необходимо, чтобы вы забили гвоздь
в стену, т.к. он (или она) хочет на него повесить, например,
картину.
2. Другие люди, живущие с вами в одной квартире, —
им, возможно, будет не все равно, как будет выглядеть ваше
общее жилище, и, может быть, кто-то из них будет не согласен
с выбором картины или с местом, на которое вы собрались ее
повесить.
3. Хозяин квартиры — если вы снимаете квартиру, возмож­
но, вы ограничены в своем желании ее украшать на свой вкус.
Это что касается заинтересованных в результате. Если же
говорить о процессе, то можно еще перечислить и другие за­
интересованные стороны:
4. Соседи — скорее всего, вы должны выбрать правильное
время для забивания гвоздя, чтобы шум не мешал вашим со­
седям.
38 Глава 1. Определение заинтересованных сторон и их представителей
iiiiiiiiiiiiiiiiiiiiiiiiiiiH iiiiiiiiiiiiiiiiiilittiiiiitiiiiitin iiiiiiiiiiififliiiiiiiiiiiiiiiiiiitiiiiiiiiiiiiiiiiiiiiitiiiiiiiiiiiiiiiiiiiiiiiiiiiu u iiiiiiiitt

5. Вы сами — вы тоже заинтересованы не только в резуль­

тате (тут вас можно причислить к заинтересованной стороне
номер 2), но и в том, чтобы «проект» проходил, по возможности,
и в спокойной, и в безопасной обстановке, чтобы у вас были
материалы (гвоздь), инструменты (молоток и т.д.), чтобы вам
не мешали и не лезли под руку, когда вы работаете.
Итак, мы взяли для примера очень простой проект, а нашли
сразу пять заинтересованных сторон.

В нашем примере мы не только сразу определили заинтересо­

ванные стороны, но и описали основные проблемы, цели и задачи
заинтересованных сторон, а также их отношение к ходу выполнения
проекта. Однако ввиду простоты примера мы не коснулись очень
важного вопроса: кто за это платит?

Определение представителей заинтересованных сто­

рон для сбора требований
Как начинается проект? Обычно все начинается с того, что кто-то
чего-то хочет. И он со своими желаниями и идеями приходит к вам.
Если вы работаете внутри организации, которая делает проекты для
автоматизации собственной деятельности, или разрабатываете про­
дукты для массового рынка, то обычно этот самый «кто-то» является
сотрудником вашей компании. Это может быть один из руководи­
телей отделов компании или наиболее активных сотрудников. Или,
в случае продуктовой компании, это может быть менеджер продукта,
или руководитель отдела маркетинга, или руководитель отдела про­
даж и т.п. Если вы оказываете услуги другим компаниям, то этот
«кто-то» обычно представляет компанию клиента, или от его лица
к вам приходит клиентский менеджер или продавец (опять же со­
трудник вашей компании).
Следовательно, этот человек (который к вам пришел первым)
и есть первый представитель заинтересованной стороны. Его при­
нято называть Инициатором.
Даже если на проекте он будет практически единственным за­
казчиком, вам все равно необходимо понять, кто же еще заинтере­
сован, и самый простой способ это узнать — спросить Инициатора.
Далее с тем же вопросом (кто же еще заинтересован?) необхо­
димо обратиться и к тем людям, о которых вам удалось узнать от
Инициатора, и так далее, до тех пор, пока вы не получите относи­
тельно стабильный список заинтересованных сторон.
 опеление представителей заинтересованных сторон для сбора требований 39
IBP®*1
^ 1, , , , ......................................................................... ним пн

Ну и как в предыдущем примере, мы опять не задали вопрос:

а кто же платит деньги? В большинстве проектов, в которых мне
лично приходилось участвовать, это было очевидно, и поэтому у ме­
ня лично создалось ощущение, что для аналитика, разрабатывающе­
го требования для ПО, это не так уж и важно. Однако в литературе
поли человека, ответственного за бюджет проекта, уделяется много
внимания, и существует специальная роль — Спонсор. Хорошо, если
Инициатор и Спонсор — это одно и то же лицо. Если это разные
люди, то аналитик должен будет выяснить, кто же является Спон­
сором, и включить его в список.

После некоторых размышлений о том, какой пример должен

быть основным в этой книге, я решил взять службу поддержки.
Служба поддержки как выделенная часть ИТ-отдела или хотя
бы такая функция есть практически в каждой организации, не­
зависимо от того, что это: ИТ-отдел компании, бизнес которой
не связан с ИТ-услугами, или это разработка заказного ПО,
внедрение или разработка коробочного ПО. Организация под­
держки ПО — это история, я полагаю, более или менее знакомая
многим из вас.
Представим себе руководителя отдела ИТ в качестве иници­
атора запроса на разработку системы автоматизации службы
поддержки. Его очень сильно волнуют показатели качества ра­
боты поддержки — соответствует ли работа службы поддержки
достигнутым договоренностям об уровне сервиса (SLA —Service
Level Agreement, соглашение об уровне сервиса). Спросим его:
а кто еще может быть заинтересован? В качестве ответа на свой
вопрос мы можем получить следующий список:

• Пользователи, которые обращаются в службу поддержки

• Специалисты службы поддержки (Специалист СП)
• Руководитель службы поддержки (Руководитель СП)
• Разработчики приложения — вторая линия поддержки. Для
упрощения примера представим, что служба поддержки
занимается одним приложением. Для решения вопросов,
связанных с его неправильной работой, обращение пере­
направляется к разработчикам. На самом деле уровней
поддержки, несомненно, может быть больше. Может быть,
что на втором уровне поддержки работают более опытные
специалисты службы поддержки или аналитики, а разра­
ботчики — на третьем и т.п.
40 Глава 1. Определение заинтересованных сторон и их представителей
lllllllllllilllllllllllllllllllllllllllllllllllllllllllllllllllllllillllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllltllllllllllllJIIIIIM l

В реальной ситуации заинтересованных сторон может быть

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

Диаграмма взаимодействия
Для того чтобы представить всю картину в целом, очень по­
лезно нарисовать диаграмму взаимодействия, которая будет изо­
бражать на самом верхнем уровне абстракции все взаимодействия
между заинтересованными сторонами, относящиеся к сути проекта.
В качестве способа построения диаграммы взаимодействия можно
использовать Контекстную диаграмму бизнес-прецедентов (в ориги­
нале это Business Use Case Context Diagram) из нотации UML или
любую другую подходящую формальную нотацию моделирования.
Хотя в некоторых случаях гораздо нагляднее простая диаграмма,
нарисованная от руки.
На этом этапе вам важна диаграмма для отражения взаимодей­
ствий заинтересованных сторон, связанных с основной проблемой.
Т.е. нужно представить взаимодействие заинтересованных сторон и,
не вдаваясь в технические детали, изобразить то, как работает биз­
нес-процесс. Но зачастую даже на уровне постановки проблемы ваш
заказчик будет настаивать на том, что ему нужна система для ее ре­
шения. С одной стороны, это выглядит как преждевременный переход
в область решения, но для оживления дискуссии и предотвращения
конфликта на этом достаточно важном этапе аналитик может включить
будущую (еще не созданную) систему в диаграмму взаимодействия
как «черный ящик», чтобы смоделировать взаимодействия между за­
интересованными сторонами [1]. Если удается обойтись без пре­
ждевременного перехода в область решений — прекрасно.

Вернемся к нашему примеру со службой поддержки, тутмы

как раз имеем ситуацию, когда система появляется преждев­
ременно.
 Определение представителей заинтересованных сторон для сбора требований 41
.
1— -- - ....

Рис. 5. Диаграмма взаимодействия

Если бы мы абстрагировались на этом этапе от системы, то

отчетность предоставлялась бы Специалистом СП и, возможно.
Разработчиком Руководителю СП, а от него Руководителю ИТ.
но поскольку мы ввели систему в контекст решаемой проблемы,
то отчетность предоставляется системой.
В реальной ситуации, посмотрев на эту диаграмму, можно
задать много вопросов. Например: а как происходит обраще­
ние (по телефону, по электронной почте, через сайт)? Или:
а нельзя ли совместить обращение и его регистрацию? Ведь
если обращение происходит через сайт, то оно автоматически
регистрируется. И так далее. Таким образом, мы можем выявить
как пропущенные заинтересованные стороны, так и ряд важных
аспектов, позволяющих уточнить контекст проблемы, а также
ее рамки.
42 Глава 1. Определение заинтересованных сторон и их представителей
iiiiiiiiiiiiiiim iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiM iiiiiiiiiiiiiiiim iiiiiiiiiiM iiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Хотелось бы специально обратить внимание на то, что эта

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

Рисуя диаграмму взаимодействия, мы также стараемся уйти от

конкретных людей и перейти к обсуждению ролей, так как в свете
решаемой проблемы нам важны именно роли, которые конкретные
люди играют при решении проблемы.

Например, Руководитель СП — это конкретный человек, ко­

торый занимает эту должность, но в реальной жизни он может
играть также и роль Специалиста СП, если не хватает людей
и кому-то нужно снять трубку и ответить на звонок, или в кон­
тексте действий — просмотр списка обращений и изменение
их статуса.

Выбор представителя заинтересованной стороны

Во многих случаях возможность выбора конкретных людей в ка­
честве представителей заинтересованных сторон у аналитика отсут­
ствует. Аналитик выявил роли, но кто именно будет формулировать
требования от лица каждой из ролей, выбрать ему зачастую не по­
зволяют.

Для нашего примера может оказаться, что Руководитель ИТ

или Руководитель СП будет сам назначать людей, которые будут
формулировать требования отлица Специалиста СП, Разработ­
чика или Пользователя.

В заказных проектах, когда аналитик участвует в проекте на

стороне компании-поставщика системы, на стороне заказчика про­
екта, обычно представители заинтересованных сторон выбраны еще
до начала тендера. И какая-то гипотетическая возможность выбора
нужного человека как представителя заинтересованной стороны по­
является только при выявлении аналитиком пропущенных заинте­
ресованных сторон. При разработке коробочных продуктов в роли
заказчика выступает маркетинг, продажи, владелец компании и т.д.,
т.е. выбора обычно тоже нет. В основном выбор есть тогда, когда
аналитик является сотрудником компании-заказчика проекта.
Определение представителей заинтересованных сторон для сбора требований 43
........................... Цинтии......................... .................. ..................

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

Возьмем для примера обучение вождению на автомобиле.

Человек сначала и не знает, как водить автомобиль, и не умеет
этого делать. Это первый уровень (см. Рис. 6). Затем ему рас­
сказывают, как водить автомобиль, и у него появляются знания,
но еще нет умений. Это второй уровень. Потом появляются уме­
ния, но забываются знания, человек просто водит автомобиль
и не отдает себе отчета в том, когда он нажимает на педали,
переключает скорости и т.п. Это третий уровень. Причем обычно
переход от второго к третьему уровню отследить достаточно
сложно: возможно, между ними и есть интервал врем енина
котором человек еще хорошо может помнить свои знания от­
носительно вождения и в то же время уже очень хорошо умеет
водить. Но бывает и наоборот: человек уже забыл, как это нужно
делать, но еще плохо умеет.
И только если человек захочет водить автомобиль еще лучше
или учить водить автомобиль другого человека, он поднимет
свои знания из пассивного состояния в активное и начнет ими
пользоваться для совершенствования своих умений и обучения
других людей. Это четвертый уровень — уровень мастерства.

Знания Умения

1ый уровень -
2ой уровень + -

Зий уровень +

4ый уровень + +
Рис. 6. Знания и умения

Первый уровень — когда нет знаний и умений — характерен для но­

вых сотрудников: они еще не знают, как выполнять работу, и не умеют
44 Глава 1. Определение заинтересованных сторон и их представителей
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII I M I I I I I II I I I II I I I II I I I II I t lll ll lll lll ll lll ll lll ll lll ll lll ll lll lll ll lll H t ll lll ll lll ll lll lll ll lll ll lll ll lll t l lll ll l ll llllH iiiii

этого делать. Такой сотрудник на проекте в качестве представителя

заинтересованной стороны, очевидно, пользы принести не может. Ту
же ситуацию можно получить, если привлечь для работы над деталь­
ными требованиями руководителя высокого уровня, который никогда
не выполнял ту работу, для которой вы проектируете решение, ведь
он не знает, как делать эту работу, и не умеет ее делать.
Второй уровень характерен для новых сотрудников, которые не­
давно начали работать, но еще не умеют хорошо делать свою
работу. То же самое можно сказать в отношении линейных руко­
водителей применительно к обязанностям их подчиненных — они
искренне полагают, что знают детали работы их подчиненных, но
поскольку сами они эту работу не выполняют, могут ошибаться
и даже наверняка это делают.
Третий уровень — это сотрудники, которые давно работают и де­
лают свою работу автоматически. С этой ситуацией очень часто при­
ходится сталкиваться аналитикам. Обычно на проект привлекаются
сотрудники с большим стажем и опытом. И опытным аналитикам эта
ситуация знакома, и о таких пользователях ходит шутка, что «поль­
зователи как щенки: глаза умные, все понимают, но сказать ничего
не могут». Тем не менее поскольку аналитику приходится работать
с такими людьми достаточно часто, он должен уметь «разговорить»
таких людей и помочь им сформулировать свои требования. Об этих
приемах речь пойдет ниже, во второй главе.
Четвертый уровень — это специалисты, которые не только умеют
хорошо делать свою работу, но и полностью осознают то, ЗАЧЕМ
и КАК они делают эту работу. Это «гуру», которые очень полезны
для проекта. Теперь вопрос: а как же выявить таких людей в рядах
представителей заинтересованных сторон? На мой взгляд, нужно
начать с вопроса: «А к кому вы посылаете на обучение новых лю­
дей?» Или: «Кто обучает новых сотрудников?» Это поможет выявить
людей, у которых есть и знания, и умения, максимально полезные
аналитику, и находятся они у него в активном состоянии.

Заинтересованные стороны и их цели

Процесс определения заинтересованных сторон и представителей
обычно идет параллельно с определением отношения их к проекту.
Как мы уже отметили в начале главы, заинтересованность стороны
может быть положительной или отрицательной, заинтересованность
может быть в результатах или в ходе проекта. Поэтому всегда по­
лезно эту информацию зафиксировать.
ОпРеДеление пРеАставителе* заинтересованных сторон для сбора требований 45

Для этой цели обычно принято использовать таблицу вида:

Роль ФИО Отдел Должность Цель/Влияние

Теперь сделаем это упражнение для нашего примера со

службой поддержки:
Наверняка Руководитель ИТ, обратившийся к вам, сказал,
что «нужно внедрить систему для Help Desk». Но совершенно
ясно, что система как таковая ему неинтересна (за исключе­
нием случаев крайнего фанатизма, которые мы по понятным
причинам рассматривать не будем). Поэтому аналитик должен
поинтересоваться: а зачем ему эта система? В результате ко­
роткой беседы может выясниться, что система ему нужна для
того, чтобы доказать руководству, что у него не хватает людей
для поддержки, или что процесс поддержки достаточно хо­
рош, но нет данных, чтобы доказать это руководству, или у него
другие цели, но так или иначе мы можем переформулировать
его слова следующим образом: «Руководитель ИТ-отдела за­
интересован в построении измеримого управляемого процесса
поддержки».

Таблица 1. Заинтересованные стороны и их представители

Роль ФИО Отдел Должность Цель/Влияние

Руководи­ Петров ИТ Руководитель Получение
тель ИТ, С. П. Отдела ИТ измеримого
Инициатор, управляемого
Спонсор процесса под­
держки
Руководи­ Сидоров ИТ Руководитель Получение
тель СП в.д. Службы под­ измеримого
держки поль­ управляемого
зователей процесса под­
держки
Специ­ Васечкин ИТ Специалист Получение
алист СП И. Г. службы под­ удобного ин­
держки струмента для
работы
46 Глава 1. Определение заинтересованных сторон и их представителей
tu iiiifiiitiiiiiiiiitu iiiiifiiiiiiiiiiiifiiu iiiiiiiiiiitiititK iiiiiiiiiiiiiiiiiiiiitiiiiiiiiiiiiiiiiiiiiitiiiiiiiiiiiiiiifiiiiiiiin iiiiiiiiiiiiiiH iiiiiiiitfi

Роль ФИО Отдел Должность Цель/Влияние

Разработ­ Дроздов ИТ Программист Получение
чик прило­ К. К. удобного ин­
жения струмента для
работы с об­
ращениями на
вторую линию
поддержки
Пользова­ Надеж­ Бух­ Бухгалтер Получение луч­
тель дина А. В. галте­ шего сервиса
рия от ИТ по под­
держке бухгал­
терской про­
граммы

Стоит сразу обратить внимание читателя на то, что эти цели

неизмеримы и, следовательно, непостижимы. Задача анали­
тика на данном этапе — в принципе понять, что нужно каждой
заинтересованной стороне и каким образом ход работы и ее
результат будут влиять на заинтересованные стороны. Полу­
чением измеримых и достижимых целей мы займемся в сле­
дующей главе.

Заинтересованные стороны и их проблемы

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

Таблица 2. Анализ проблемы

Проблема/потреб­ <описание проблемы или потребно-
ность сти>
Влияет на <список заинтересованных сторон, на
которые влияет проблема>
Приводит к <описание негативных проявлений про-
блемы>
Определение представителей заинтересованных сторон для сбора требований 47

Ее решение при­ <описание положительных аспектов ре­

несло бы шения проблем ы>
Важность и при­ <определение важности и приоритета
оритет решения проблемы>

В нашем примере проблема, над которой мы работаем, ка­

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

Однако очевидно, что данная проблема не очень волнует раз­

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

Проблема № 1
Проблема/потреб­ Нет объективных критериев оценки ра­
ность боты службы поддержки и нет средств
для измерения показателей, использу­
емых для оценки
Влияет на Руководитель ИТ, Руководитель СП
Приводит к 1) субъективной (чаще негативной)
оценке работы службы поддержки со
стороны руководителей компании и ос­
новных бизнес-подразделений
2) невозможности обоснования необ­
ходимого количества специалистов, за­
нятых поддержкой
3) невозможности оценить работу каж­
дого Специалиста СП
4в Глава 1. Определение заинтересованных сторон и их представителей
шц

Ее решение при­ 1) адекватную оценку работы СП в со­

несло бы ответствии с критериями (SLA) на ос­
новании документальной статистики
2) оптимизацию работы СП с точки
зрения ресурсов и решаемых задач
Важность и приори­ Высокая важность, высокий приоритет
тет

Проблема № 2
Проблема/потреб­ Трудно контролировать ИТ по обраще­
ность ниям, которые не решаются в процессе
первого телефонного звонка
Влияет на Пользователь
Приводит к затратам времени на контроль процес­
са решения вопроса
Ее решение при­ 1) возможность видеть, где находится
несло бы обращение и кто им занимается (про­
зрачность)
2) сокращение времени на отслежива­
ние прогресса по решению вопроса.
в т.ч. автоматическая эскалация могла
бы помочь сократить участия поль­
зователей и улучшить их отношение
к ИТ (и службе поддержке в частности)
Важность и при­ Высокая важность, высокий приоритет
оритет

Проблема № 3
Проблема/потреб­ Прямые звонки и письма пользователей
ность отвлекают от основных задач
Влияет на Разработчик приложения
Приводит к 1.) потерям времени на вопросы, кото­
рые могли бы быть решены специали­
стами СП
2) потерям времени на ответы на во­
просы об ожидаемых сроках решения
проблем пользователей
Ее решение при­ сокращение времени Разработчиков на
несло бы поддержку
Закл1°чение 49
.„iiiiiiiiiiinHiiiiHiniiii .

Важность и приори­ Средняя важность, средний приоритет

тет

Пожалуй, на этом остановимся, хотя, несомненно, каждый

из представителей заинтересованных сторон может сформу­
лировать несколько проблем, которые в той или иной степени
соответствуют цели проекта.

Заключение
Определение заинтересованных сторон, их представителей, проб­
лем и задач, которые стоят перед ними, является первой важной
задачей аналитика. Аналитику стоит помнить, что пропущенные заин­
тересованные стороны, а также недостаточное привлечение к сбору
требований конечных пользователей — это весьма распространенные
причины провалов проектов.
Если эта работа сделана плохо, то проект может пойти
не в том направлении, разработка может начаться не в том объ­
еме, который необходим, что в результате может привести про­
ект к провалу.
50 Глава 2. Сбор требований i
iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiitiiiiiiiiiiiniiiiiitiiuiiiiiiiHiiiiiiiiiiimiiiiiitiiiiiiiiiuiiiiiutttiiitiiiiiiiiHiiitieiiiiiiiiiiaiiiiiiiiiii, j

Глава 2. Сбор требований

Обзор источников требований

Я выделяю следующие группы источников требований:

• Люди
• Документы
• Системы
• Новые технологии

Это достаточно условное разделение, т.к. во многих случаях

приходится работать сразу и с людьми, и с системами, и с доку­
ментами. Новые технологии, как правило, тоже сопровождаются до­
кументацией, возможно, системами, с которыми нужно иметь дело,
или с людьми — носителями знаний о новых технологиях. Основной
смысл такого разделения состоит в том, чтобы помочь вам ничего
не забыть на этапе сбора требований.
Чаще всего в проектах по разработке ПО именно люди являются
основным источником требований. Очень редко бывают ситуации,'
когда для разработки системы у команды есть только документ,
и нет никакой возможности обсуждать его с автором и другими за­
интересованными лицами. Еще менее вероятен случай, когда есть
работающая система, и команда хочет ее переписать без вовлечения;
в обсуждение будущих пользователей или других представителей,
заказчика. В конечном итоге именно люди будут оценивать вашу
работу, платить вам за ее выполнение, пользоваться системой.

Планирование сбора требований

Для оценки работы, которая наверняка будет запрошена у ана­
литика его руководителем, необходимо определить всех людей,
которые будут выступать в качестве представителей заинтересо­
ванных сторон, а также системы и документы, которые также будут
являться источниками требований. Перед тем как собирать требо­
вания с представителей заинтересованных сторон, аналитику стоит'
подготовиться и внимательно изучить имеющиеся в его распоря­
жении документацию и системы. Эта подготовительная работа тре-'
бует времени, с нее стоит начать. Далее на каждого представите­
ля заинтересованных сторон необходимо как минимум полдня, т.к.
вам нужно время на согласование организационных вопросов, на
 Планирование сбора требований 51

проведение встречи и на обработку результатов встречи. Помимо

I
встреч, возможно, необходимо запланировать и другие мероприятия
по сбору требований, о которых пойдет речь в данной главе. Однако
это еще не все. В процессе сбора требований может появиться ин­
формация о новых источниках, часть людей может быть недоступна
в удобное для аналитика время, поэтому стоит увеличить оценки.
Если аналитик занимается несколькими проектами и задачами, то
в оценку трудозатрат стоит добавить некоторый запас (например
3 0 %). Если аналитик работает на одном проекте, то оценки с точки
зрения календарных сроков следует увеличить как минимум на 50 %.
Приведенные оценки запасов достаточно умозрительны, каждый раз
аналитик должен постараться оценить степень неопределенности
и возможности изменения состава источников требований, чтобы
более точно дать оценки на свою работу. Сразу хочу отметить, что
в данной главе речь пойдет только о сборе требований, а, сле­
довательно, в совокупную оценку работ аналитика на начальных
этапах проекта стоит также добавить оценки на разработку требо­
ваний (и других документов разрабатываемых аналитиком), на их
проверку и согласование.

В нашем примере со службой поддержки планирование до­

статочно прозрачно. Допустим, что наш аналитик знает, что
такое ITIL, ITSM и т.п. Т.е. он понимает, какая теория лежит
в основе организации профессиональной службы поддержки.
Документов на момент начала сбора требований нет, так же как
и систем. Поэтому ограничимся днем на подготовку для решения
организационных вопросов, назначим и проведем встречи с ру­
ководителем ИТ и руководителем СП, одним из разработчиков,
одним из специалистов, одним из представителей пользова­
телей, а также проведем опрос среди специалистов СП и сре­
ди пользователей. Итого один день на подготовку, три дня на
интервью и пару дней на проведение опросов и обработку их
результатов, добавим запас и получим 8-9 дней на сбор требо­
ваний. Оценки на оформление и согласования документа будут
зависеть от вашей методологии разработки и от того насколько
активно заказчик будет участвовать в согласованиях.

Давайте теперь рассмотрим каждую группу источников требо­

ваний подробно. Отдельно рассмотрим обращения в службу под­
держки и прототипы, так как эти источники, на мой взгляд, этого
заслуживают.
 52 Глава 2. Сбор требовании & д о и как источник для сбора требований 53

iiiiiM iiiiiiiiiiiiiM iiM iifiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiM iiiiiiiiiiiiiiiiiiitiiiiiiiiiiiiiiiim iiiiiiiiiiiiiiiiim iiiiiiiiiiiiM iiiiiiiiiiiiiiiiiiiiiiiiiiin Л ^ ^ „„ iiiiiH iiiiiiiiiiin iiiiiiiiiiiu iiiiiiiiiiin iu iin n iin u iiiiiiiM iiin n iiH n iiH iiiM iM iiiiiiH in iiin iiiiiiiiiiiiiiiiiiiiiiiim iiiiiiiiiiiii

. текст — 10 % информации.
Л юди как источник для сбора требований
Работа аналитика во многом заключается в том, чтобы перево-1 Это отнюдь не значит, что информация в холодных каналах те­
дить с одного языка на другой. Зачастую это перевод с языка биз­ ряется, это значит, что на получение одной и той же информации
неса, мало связанного с информационными технологиями, на язык - аналитику потребуется затратить больше усилий, если у него в рас­
понятный программистам. Для того, чтобы перевести с одного языка 9 поряжении только холодные каналы. То же самое касается и приня­
на другой, аналитик должен быть своим и в среде бизнеса и в сре­ тия решений. Люди склонны скорее принимать решения в процессе
де разработки. Это ключевой фактор успеха профессиональной дея­ личной беседы, чем по телефону или в процессе переписки. Если
тельности аналитика. Следовательно, стоит уделять особое внимание у аналитика для сбора требований только телефон и переписка, то
тому, как понять людей (представителей всех заинтересованных щ ему придется увеличить оценки на сбор требований.
сторон) и как донести полученную информацию до программистов. Щ Для того чтобы принимающая и передающая стороны одинаково
Раз уж мы затронули тему передачи и преобразования информации Ш понимали информацию (вкладывали в нее один и тот же смысл),
стоить уделить немного внимания факторам, влияющим на этот про- Д очень важен совместный (или общий) опыт. В русском языке есть
цесс. Для передачи информации важна среда или, как пишет Алистер Щ выражение «понимают друг друга с полуслова». Это выражение как
Коберн (Alistair Cockbum) в свое книге, посвященной гибкой разработке Ц нельзя лучше иллюстрирует идею того, что людям, имеющим со­
ПО [4], канал коммуникации. Он вводит понятие «температуры канала вместный опыт, не нужно затрачивать большие усилия, чтобы пере­
коммуникации». Чем она выше, тем меньше потерь происходит при давать информацию друг другу.
передаче информации. Меньше всего потерь, когда люди общаются, j] Другой важный фактор при общении между людьми — это уваже­
непосредственно видя друг друга, — это самый горячий канал пере- j ние. Я искренне убежден в том, что понимание людей невозможно без
дачи информации. Потери увеличиваются, если люди находятся на рас- J уважения к ним. Уважение складывается из нескольких составляющих:
стоянии и общаются с помощью интерактивных средств: видеозвонок, i это и знание бизнеса заказчика, это и понимание его культуры и тра­
обычный голосовой телефон, чат. Ну и самые холодные каналы — это диций, это и, несомненно, бережное отношение к чужому времени.
электронная и бумажная почта. Коберн пишет, что чем холоднее канал, Следовательно, успех общения с представителями заказчика за­
тем больше усилий необходимо затратить на передачу и получение од­ кладывается еще до начала встреч. Для того чтобы общение про­
ного и того же количества информации. Несколько другими словами об ходило продуктивно, необходимо к нему готовиться.
этом же говорят психологи. Они вводят понятие невербального обще­
ния, которое включает позы, жесты, прикосновения, мимику лица и т.п.
Подготовка к встрече
Помимо невербального общения большое внимание уделяется интона­
ции голоса. Психолог Альберт Мейерабиан в ходе своих исследований В процессе подготовки к общению с представителями заинте­
пришел к выводу о том, какой процент информации передается с по­ ресованных сторон аналитику будет крайне полезно изучить все
мощью различных средств передачи информации при общении людей: доступные материалы, особенно если заказчик новый. Аналитику
также стоит попытаться получить информацию о заказчике у своих
• вербальные (только слова) — 7 %; коллег, если у них есть опыт общения с этим заказчиком или у них
• звуковые (включая тон голоса, интонации звука) — 35 %; за плечами проекты в данной предметной области.
• невербальные — 55 %. Следующее, что необходимо сделать аналитику, — это продумать
организационные вопросы, связанные со сбором требований с пред­
В целом же можно ориентироваться на несколько усредненные ставителей заинтересованных сторон.
данные, которыми оперирует большинство психологов: На первое место, конечно, выходят вопросы желания и возмож­
ности конкретных людей общаться с вами. Аналитик должен по­
• личное непосредственное общение — 100 % информации; нимать, насколько каждому из представителей заинтересованных
• телефон — 30 % информации; сторон интересно участвовать в проекте, насколько этот человек
 54 Глава 2. Сбор требований
11111111111Ш 1| 111111111Н 11111111111111111111111Ш 111| | 111111111111111111111111111111111111111111111111Ш Н Ш Ш 1Н 11| 1Ш 1Ш 1Н Ш П | | Ш 11Ш Ш Ш Ш 1Ш |

заинтересован в результатах проекта. Также нужно отдавать себе

отчет и в том, насколько каждый из этих людей может принимать
участие в проекте, распоряжается ли он своим рабочим временем,
есть ли у него время в течение рабочего дня для общения с вами.
Заинтересованность людей в проекте может быть разной. Самый
очевидный и простой случай, это когда человеку нужна система для ра­
боты: если система, которую вы собираетесь для него разработать, спо­
собна помочь ему выполнять его работу, снизить затраты его времени,
уберечь его от рутины, получить конкурентные преимущества на рынке,
заработать больше денег, снизить издержки производства и т.п. Даже
в этой ситуации аналитику стоит понять, в чем же именно заключает­
ся мотивация человека, с которым он обсуждает требования. Гораздо
более сложный случай представляет собой ситуация, когда приходится
собирать требования с человеком, которого текущее положение вещей
полностью удовлетворяет, и он не понимает, зачем ему тратить силы на
проект, который, по его мнению (несомненно, самому авторитетному),
никому не нужен. Бывают ситуации, когда приходится собирать требо­
вания с людьми, которые боятся, что в результате проекта они потеря­
ют что-то, начиная от авторитета и позиции «незаменимого человека»
и заканчивая угрозой потерять рабочее место. Также бывают ситуации,
когда аналитику приходится общаться с представителями заинтересо­
ванных сторон, роль которых в проекте и польза, которую они могут
получить от его реализации, пока не определена или неочевидна (как
для аналитика, так и для них самих). Действовать в таких ситуациях, на
мой взгляд, следует с двух сторон. Первое и самое главное, чем может
привлечь аналитик других людей общаться с ним, — это он сам. Мно­
гие люди любят, когда им уделяют внимание, когда их слушают. Если
аналитик является хорошим слушателем и интересным собеседником,
то с ним охотнее будут встречаться. Для хорошего человека не жалко
потратить часок даже и личного времени. Второе, и не менее важное, —
это помочь заказчику создать благоприятную атмосферу вокруг проекта.
Компании с высокой проектной культурой всегда стараются мотивиро­
вать участие своих сотрудников в проектах по развитию бизнеса и его
технологической платформы, в первую очередь материально. Если вы
столкнулись с заказчиком, у которого проектная культура находится еще
не на достаточно высоком уровне, может быть, вам стоит постараться
что-то сделать и в этом направлении, чем пытаться вытянуть весь про­
ект за счет собственной харизмы?
Следующий важный аспект в подготовке к встрече — это выбор
удобного времени. Не каждый из тех, с кем вам необходимо обсу­
дить требования, распоряжается своим рабочим временем. Тем, кто
Лю ди как источник для сбора требований 55
iiiiiiiiiK iiiiiit iiiiiit iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiit iiiiiiiiiit iit iiiif iiiiiu iiit iiiiiiiH iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

обязан все свое рабочее время выполнять операционную работу', не­

обходимо помочь найти время для работы на проекте. Лучше, если
об этом позаботится непосредственный руководитель этого челове­
ка. Однако если с этим возникают трудности, а вам очень хочется
с человеком поговорить, постарайтесь найти к нему личный подход.
Личный подход к каждому в любом случае необходим. Даже люди,
заинтересованные в результатах проекта и распоряжающиеся полностью
своим рабочим временем, могут испытывать трудности, чтобы найти
в своем расписании час для встречи с вами. Старайтесь в этом случае
мыслить шире. Возможно, человек сможет разделить с вами обед или
завтрак и посвятить его не только еде, но и обсуждению требований.

У меня был один достаточно трудный проект. Команда из че­

тырех аналитиков заняла переговорную комнату. Мы сидели там
постоянно, приглашая представителей заказчика для интервью
в эту переговорную. Мы пытались вытаскивать людей для беседы
во время рабочего дня. Такие разговоры обычно проходили в до­
статочно быстром темпе, прерывались звонками на мобильный
телефон и т.п. Однажды мы решили устроить людям завтрак. IT-
директор по дороге на работу купил выпечку. Чай и кофе на работе
имелись и были приготовлены на отдельном столе в переговорной.
«Деловой завтрак» прошел, что называется, в теплой дружествен­
ной обстановке, люди на мобильные не отвлекались (т.к. было еще
рано для звонков), были приятно удивлены забоюй о них, чувство­
вали себя более комфортно, чем в течение рабочего дня. Колле­
ги, которые не приехали на эту раннюю встречу, заходили после
этого угоститься пирожками. Наша команда в результате не толь­
ко получила новые требования, но и стала немного популярнее
в глазах представителей бизнеса. При этом расходы на это были
минимальными. Это лишний раз подтверждает простую истину, что
старые проверенные средства работают. (Как в русских народных
сказках: «Ты, бабка, сначала меня напои, накорми, а потом уж рас­
спрашивай».) Таким образом, коллективное мероприятие с едой
в начале проекта (завтрак, обед или ужин), куда приглашаются все
представители заинтересованных сторон и представители команды
разработки, является очень хорошей идей, поскольку это помогает
установить контакт между участниками проекта и сделать проект
более привлекательным для всех его участников.

Общение аналитика и представителей заинтересованных сторон

может проходить в разных форматах: это может быть личная ветре-
56 Глава 2. Сбор требований
пнищ ]

ча, телефонный звонок, видеоконференция, или же все общение J

может происходить по переписке. Также необходимо отметить, что 1
общение между аналитиком и представителями заинтересованных Ц
сторон может происходить в формате «один на один» или сразу 1
с несколькими представителями заинтересованных сторон. Важно
правильно выбирать каждый из этих видов общения, т.к. у каждого 1
из них есть свои особенности. Об этом подробно расскажу ниже.
Если вы собрались встречаться с человеком (или группой людей) j
лично или вы собираетесь устроить видеоконференцию либо теле- Я
фонные переговоры, большое значение имеет выбор места встречи.
Оно должно быть удобным. Это в первую очередь означает, что вас л
и вашего собеседника ничего не должно отвлекать от разговора, f
Можно воспользоваться вашим рабочим местом, рабочим местом '
вашего собеседника или переговорной комнатой. Однако не всегда
это удобно или возможно. Бывают ситуации, когда ни ваше рабочее 3
место, ни рабочее место вашего собеседника не дают необходимого 1
уровня комфорта для проведения интервью по сбору требований, i
С доступностью переговорных комнат тоже случаются проблемы. Тем
не менее сдаваться не стоит, нужно искать варианты. Возможно, для
переговоров подойдет чей-то временно пустующий кабинет или, как £
вариант, столик в ближайшем кафе.
Выбор удобного места для обсуждения требований также важен
и для телефонного звонка, и для видеоконференции. Как я уже от- 1
мечал, возможно, рабочее место для этого может не подойти, т.к. Ч
там может быть достаточно шумно, человека, с которым вы беседуе- ;
те, могут отвлекать коллеги, приходящая электронная почта и другие *
внешние факторы. То же самое касается и вас.

Один из моих коллег как-то рассказывал, что у него на рабо- 1

чем столе есть «одна большая кнопка», которая выключает все j
средства коммуникации на компьютере: электронную почту, Skype |
и прочие средства связи. Полагаю, это полезная практика: если вы 1
проводите переговоры с клиентом со своего рабочего места, луч- \
ше отключить все. что не нужно вам для этих переговоров, чтобы Я
ничего не отвлекало вас от обсуждения собственно требований.

Другой важный аспект в подготовке к встрече по сбору требо- |

ваний — это подготовка вопросов. Вы можете четко спланировать j
встречу и сформулировать все свои вопросы заранее или наметить
только основную тему беседы и ряд уточняющих вопросов. В первом 1
случае такое интервью принято называть структурированным, а во
ЛЮДИ как источник для сбора требований 57
.......... I ........I ........i n n ............

втором, соответственно, неструктурированным. Вопросы для встречи

могут быть открытыми (предполагающие в качестве ответа про­
странное рассуждение) или закрытыми (предполагающие выбор из
ограниченного списка ответов).

Примеры открытых вопросов:

• Опишите, пожалуйста, свой обычный рабочий день.

• Какие функции вы выполняете регулярно?
• Почему возникла необходимость в доработках системы?

Примеры закрытых вопросов:

• В какой момент осуществляется резервирование товара

на складе? (Возможные варианты: в момент поступления
заказа, в момент подтверждения заказа, в момент оплаты
заказа.)
• Какого числа обычно происходит закрытие месяца?
• Какие поля на форме заказа являются обязательными?

Вы можете выслать вашему собеседнику вопросы, а также другие

полезные, на ваш взгляд, материалы заблаговременно. Это может
помочь человеку правильно настроиться на встречу.
Еще один момент, который вам стоит продумать при подготовке
к встрече, это использование диктофона или камеры для записи
предстоящего разговора. Все прекрасно понимают, что включенная
камера или диктофон могут отвлекать собеседника, смущать его,
раздражать и т.п. Поэтому прежде чем вы озадачитесь вопросом:
«А как отнесется мой собеседник к тому, что я буду наш разговор
записывать?», ответьте сначала себе на вопрос: «А зачем мне это
самому нужно?»

У меня была пара проектов, на которых мы использовали

диктофон во время проведения встреч по сбору требований.
В первом случае мы писали полную расшифровку встречи в ка­
честве протокола. Это было требованием заказчика. Расшиф­
ровка в среднем занимала в четыре раза больше времени, чем
собственно встреча, т.е. после часовой встречи четыре часа
уходило на расшифровку. В другом случае мы были вынуждены
записывать интервью, поскольку не вполне понимали сленг, на
котором говорили наши собеседники, и прослушивали записи
58 Глава 2. Сбор требований
НИИ I I II I I I II I 1 I I I II I I I IM I I I II I I .

только для разбора непонятных моментов. Тем не менее рано

или поздно мы в них запутались, что, кто и когда сказал, стало
забываться. Записи стали бесполезными. И их, ввиду нехватки
места на сетевых ресурсах, куда-то заархивировали, и успешно
о них забыли.

Если у вас есть необходимость делать аудио- или видеозаписи,

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

Интервью
Несомненно, личная встреча аналитика один на один с челове­
ком, представляющим одну из заинтересованных сторон, является
самым эффективным и самым главным способом сбора требова­
ний. Возможность понять, что же на самом деле нужно человеку
и что он ждет от вас и вашей команды, ни в коем случае упускать
нельзя. Все ссылки на существующую постановку задачи и прочие
отговорки нужно мягко отводить и настаивать по возможности на
личной встрече.
Итак, если вам удалось запланировать и подготовить встречу
с человеком, с чего нужно начать эту встречу?

С чего начинается встреча?

Первое, с чего нужно начать любую встречу, так это вовремя
на нее прийти самому. Я уже отмечал выше то, какую роль в от­
ношениях между людьми играет уважение. Опоздание аналитика на
встречу, которую он сам же и организовал, его отнюдь не красит
и может быть воспринято как неуважение к собеседнику и к его
времени. Очень нежелательно начинать общение с такого эпизода.
Второе, с чего начинается встреча, — это ваш внешний вид.
Как говорит народная мудрость, встречают по одежке. Тут правило j
одно — вы должны выглядеть «своим человеком». Не хуже и не луч­
ше — вы должны соответствовать.
Интервью 59

Я надеюсь, вы смотрели в детстве советский мультик «Мауг­

ли»? Чему учил Балу Маугли?
Балу говорил:«Когда встречаешь другого зверя в лесу, нужно
ему сказать:
«М ы с тобой одиоАкрови^ ш ж я Ь >

Если в компании принят деловой стиль одежды, а вы придете в за­

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

Обратите внимание, что некоторые вещи в мелкую полоску

приводят к тому, что у собеседника «сводит глаза». Будьте вни­
мательны при подборе одежды для встреч.

Но внешний вид, разумеется, состоит не только из вашей одеж­

ды; прическа, косметика и другие элементы внешнего вида также
влияют на то, каким будет первое впечатление о вас. Помимо зри­
тельного образа могут быть также оценены ваш голос, запах, то,
как вы двигаетесь, как вы пожимаете руку и т.п.

Однажды я был на курсах по проведению интервью с канди­

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

Особенно хочу предостеречь от применения запахов. Лучше ни­

чем не пахнуть, ибо даже приятные, на ваш взгляд, ароматы могут
показаться вашему собеседнику резкими и неприятными (резкие
60 Глава 2. Сбор требований
I .

запахи могут вызвать в закрытом помещении головную боль или

даже потерю сознания).

Как сесть?
Редко встречаются переговорные, где есть только стол с двумя
стульями и выбора места нет. Обычно в переговорных комнатах сто­
ит прямоугольный стол и несколько стульев вокруг него (см. Рис. 7).
Если вы сядете за стол рядом (плечо к плечу), вам будет удобно
вместе работать с тем, что находится на столе. Эту рассадку можно
условно назвать «сотрудничество». Однако при такой рассадке вы
не будете видеть лица вашего собеседника, не сможете установить
с ним зрительный контакт. Кроме того, для первой встречи, воз­
можно, вы окажетесь слишком близко и нарушите границы личного
пространства собеседника.

-"ШЕШЗВ*-

дверь

Ц Документы, бумага (громоотвод)

Видно реакцию собеседника, но

позиция способствует конфронтации

Позиция способствует сотрудничеству,

но невидно реакцию собеседника

Удобная позиция как для общения, так и

для работы с документами

Рис. 7. Схема переговорной комнаты

Если вы сядете напротив, то вы сможете смотреть на человека,

наблюдать за его реакцией на ваши слова, не будете вторгаться в его
личное пространство (если, конечно, столик между вами не крохотный)
Интервью 61
||||1111111ШШ11Н111111Ш11Ш111Ш1Ш1Ш111Ш11Ш11111Ш1Ш11111Ш!1|11111111111Ш11111111111111М1111111Ш11Ш11111|111111111111111Ш11ПШ1Ш

но в то же время будете находиться как бы по другую сторону барри­

кады. Эту рассадку можно назвать «переговорной». Она характерна для
проведения переговоров, когда у каждой из сторон есть свои интере­
сы. Такая рассадка тоже не является оптимальной. Тем более что она
затрудняет совместную работу над принесенными вами материалами,
а также иллюстрацию ваших идей с помощью диаграмм и рисунков.
Лучше всего сесть «через угол» стола, или, другими словами, под
углом 90° к собеседнику. Это дает вам возможность самому выби­
рать правильный угол поворота к вашему визави. Вы можете сесть
так, чтобы максимально развернуться лицом к человеку или в слу­
чае необходимости повернуться так, чтобы вам было удобно вместе
обсуждать какие-то материалы, рисовать вместе диаграммы и т.п.
Помимо вышесказанного очень важно позаботиться о комфорте че­
ловека, чтобы во время беседы его не беспокоил прямой свет в глаза,
но в то же время чтобы света было достаточно для работы с прине­
сенными материалами. Несомненно, важна комфортная температура
в помещении. Также важно, чтобы ваш собеседник видел дверь, т.к.
человек всегда чувствует себя гораздо комфортнее, если выход на­
ходится в поле его зрения. Имеет значение и то, кто будет сидеть во
главе стола. Руководители обычно привыкли занимать это место, и,
если вы его займете, это может обеспокоить вашего собеседника. Ис­
полнитель, возможно, напротив, будет стараться не занимать это место.
Таким образом, вопрос «как сесть?» трансформируется в простую
рекомендацию о том, что аналитик должен думать о комфортной
обстановке для проведения интервью (как психолог должен думать
о комфорте для пациента в своем кабинете). От того, насколько
будут комфортны условия, зависит результат интервью.

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

Есть ряд общих тем, которые можно и нужно эксплуатиро­

вать: погода, расположение офиса, проблемы с пробками и пар­
ковкой. С мужчинами, возможно, стоит обсудить какую-нибудь
 f l
52 Глава 2. Сбор требований j
II I M I I H I I M il > 11 1II Ml М И II tl I I I I I 1 1 1 II III Г1 1 I I I I M il Н Ш И H I Ill ИМ I IH IIIIIIIU II IIIM IIIM I M il М И Ш И ) ,,, I

спортивную новость. Девушке - как, впрочем, и мужчине (я се- 1

рьезно) — не помешает искренний комплимент. Если вы при- А
ехали в другой город к клиенту, расскажите, что вас связывает |
с этим городом. Найдите общих знакомых, если вы уже работали g
в этой сфере и знаете, что некоторые люди из других органи- 1
заций. с которыми вам доводилось общаться, теперь работают Щ
в этой компании. Одним словом, вам необходимо показать, что
вы «свой», что человеческие проблемы вашего собеседника так­
же волнуют и вас, что вы такой же, как и он.

Существует множество других способов установить контакт. Не- I

которые люди для установления контакта с человеком просят его j
о помощи. Обычно о какой-нибудь мелочи — салфетке, например, |
стакане воды, и т.п.
Также для того, чтобы установить контакт, подойдет какая-нибудь \
короткая история. Люди любят истории. Вспомните, что известные ;
писатели — одни из самых популярных людей на планете. Умение I
рассказывать истории — это одно из качеств, которое помогает j
аналитику достичь успеха в работе.
Целью установления контакта является настройка собеседника «на ;
себя». Аналитик должен быть уверен, что человек уже переключился
со своих задач и мыслей и морально готов к проведению интервью, j
■
Введение
Итак, контакт установлен. Если вы уверены, что ваш собеседник
полностью в курсе дела и готов общаться, можно сразу переходить
к тому, чтобы обсуждать запланированные вопросы. Если вы в этом
не уверены, то лучше сделать небольшое введение, чтобы убедиться
в том, что ваш собеседник имеет представление о том, как обстоят
дела на проекте, и подготовлен к данной встрече.
Аналитику важно всегда помнить, что он один из тех людей,
а возможно, даже тот единственный человек, который формирует
ожидания будущими пользователями и представителей других заин­
тересованных сторон, особенно на ранних этапах проекта. Поэтому
аналитику нужно в начале встречи правильно информировать со­
беседника о ходе проекта и о том, какие ожидаются результаты от
данной встречи. Иными словами, сформулировать цель и контекст.
Как минимум необходимо проговорить: цель проекта, запланиро­
ванные контрольные точки, роль собеседника в проекте, является
ли данная встреча единственной или она одна из ряда встреч, на
И н т ер в ью 6 3

каждой из которых будут обсуждаться разные темы. Также необхо­

димо спросить вашего собеседника о том, насколько подробно он
смог ознакомиться с теми материалами, которые вы ему присылали.
Всегда необходимо помнить, что аналитик должен думать о том,
какие ожидания формируются в голове его визави. Лучше лиш­
ний раз обговорить с человеком известную ему информацию, чем
сформировать неверные (чаще завышенные) ожидания. Для верно­
го формирования ожиданий вы можете сообщить все, что имеете
право сообщить о порядке проведения работ, о сроках проекта, его
рамках и участниках.

Вопросы и ответы
Далее можно переходить к обсуждению ваших вопросов. Зада­
ете вопросы — получаете на них ответы. Казалось бы, все просто.
Но туг есть масса подводных камней. Задача аналитика на интер­
вью — не просто задавать вопросы и фиксировать ответы. Задача
аналитика состоит в том, чтобы понять, почему он получает такие
ответы. Зачем на самом деле нужно то, что просит собеседник.
Для этого важно всегда держать в голове, а лучше перед собой
на листке бумаги те бизнес-задачи, которые ставит перед собой
заказчик в данном проекте, и стараться понять, как тот или иной
ответ собеседника соответствует этим задачами.
Практически в любой проект по разработке ПО попадают требо­
вания, которые никому на самом деле не нужны. Люди думали, что
это может оказаться полезным, но затем не нашли этому никакого
применения. Такое случается очень часто. А ведь все эти функции
системы кто-то придумал, кто-то записал, кто-то спроектировал для
них пользовательский интерфейс и, возможно, прототип, кто-то это
программировал, кто-то тестировал, исправлял ошибки, принимал,
писал пользовательскую документацию... Все зря? Да, все зря.

В 2003 году я пришел работать аналитиком в IT-отдел компании,

где на тотмоментдругих аналитиков не было, не было также и лю­
дей в тестировании и поддержке. Все делали программисты. Их бы­
ло шесть человек. Со стороны казалось, что они целый день сидели
и поднимали трубку, отвечая на вопросы пользователей, а после
того как у большинства пользователей рабочий день заканчивался,
они начинали программировать. Сами тестировали свои разработки,
сами выводили их в промышленную эксплуатацию. К слову сказать,
программировали они в основном прямо в промышленной среде.
64 Глава 2. Сбор требований
IllllllltllllllllllflllllllllllllllllllllltlllllllllllllllllllllllllllllllllllllllllU lllllllllllllllllllllllllllU lllllllllllllfllllllllllllllllllllllllllllllliii

Когда я пришел работать аналитиком в этот коллектив, мне сразу

поручили несколько новых проектов. Кроме этого, мне поручили
поговорить с каждым из разработчиков, чтобы получить знания о те­
кущей ситуации и системах, а также предложить изменения для
существующего процесса разработки. И вот в процессе разгово­
ров с программистами, которые в одном лице были и аналитиками,
и архитекторами, и разработчиками, и тестировщиками, и службой
поддержки своих приложений, я получил от одного из них неожи­
данное признание. Он сказал мне: «Знаешь, у нас в наших системах
есть три категории функций: первая — нас попросили, мы сделали,
и это используется; вторая — нас попросили, мы сделали, это или
оказалось никому не нужно, или уже не используется, так как мы
сделали уже что-то другое вместо этого; третья — нас не просили,
но мы подумали, что это будет нужно, но это никому не пригодилось
в итоге». Итак, что же получается? В системе только примерно треть
кода используется. И самое интересное — разработчики говорят,
что ни разу не угадали со своими подарками бизнесу. И это лю­
ди, которые физически находятся рядом с бизнесом, очень часто
с бизнесом общаются, сами делают всю работу. Что уж говорить
о людях, которые пытаются угадать пожелания бизнеса, общаясь
с его представителями время отвремени...

Итак, вопрос «ЗАЧЕМ?» всегда должен быть главным для анали­

тика. Он должен всегда понимать, каким образом то, о чем просит
его собеседник, соответствует достижению цели проекта.
Другой важный практический аспект проведения интервью — это
фиксирование ответов собеседника. Даже аналитикам, которые об­
ладают прекрасной памятью, я советую фиксировать то, что говорит
интервьюируемый. Это психологический момент, поскольку фиксация
аналитиком ответов на вопросы дает его собеседнику уверенность
в том, что ничего из того, что он сказал, не потеряется. Это по­
казывает, что его слова важны.
Отсюда вытекает следующий практический вопрос: а как фик­
сировать ответы? Вы можете пользоваться бумагой и ручкой или
фиксировать ответы на вопросы с помощью компьютера. Мое мне­
ние — в большинстве случаев нужно использовать бумагу и ручку.
Аргументов в пользу бумаги несколько:

• Писать обычно быстрее, чем печатать;

• Бумаги может быть много (она масштабируется), бумагой вы
можете занять всю свободную поверхность стола, стен и даже
Интервью 65

I I nun и ..... ...............

пола и окон, а на мониторе компьютера вы не сможете никогда

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

Можно приводить аргументы в пользу бумаги и дальше. Однако

тут стоит вспомнить о Маугли и вернуться к «уроку Балу». Если вы
общаетесь с человеком, с легкостью владеющим современными
техническими средствами, возможно, бумага будет неуместна и вам
нужно будет принести с собой на встречу новый планшетник, чтобы
не показаться «человеком из прошлого».
Еще одно важное свойство бумаги может вам пригодиться если
речь пойдет о проблемах. О проблемах всегда говорить неприятно,
и если вы говорите о проблемах человеку в лицо, он подсознательно
начинает думать, что вы рассматриваете его как источник возникнове­
ния этих проблем. Когда между вами лежит листок бумаги, вы може­
те, обсуждая проблемы, рисовать или писать что-то на этом листке,
глядя, соответственно, на него, таким образом перенося проблемы
на этот листок. Тогда проблема, будучи записанной или схематично
зарисованной на листке бумаги, будет находиться перед вами на сто­
ле, и вы с вашим собеседником как сторонние наблюдатели можете
ее спокойно вместе обсудить. Я называю такой прием «громоотвод».
Старайтесь в процессе общения эффективно использовать ваше
взаимное расположение и угол оборота между вами. Как только вам
нужно что-то показать на бумаге, меняйте угол таким образом, чтобы
оказаться бок обок с собеседником и вместе смотреть на листок
бумаги, лежащий между вами на столе. Для того чтобы задать сле­
дующий вопрос, поворачивайтесь лицом к собеседнику, чтобы вопрос
не улетал в пространство.
Следующий важный момент заключается в том, что вам нужно зафик­
сировать не только пожелания вашего собеседника относительно того,
какие задачи нужно решить или какими функциональными возможно-
 66 Глава 2. Сбор требований

стями должна обладать разрабатываемая система, но и те ограничения,

которые будут накладываться на работу как бизнеса, так и системы.
Важно помнить, что несоблюдение таких ограничений может впослед­
ствии привести к тому, что система не будет принята заказчиком. Или
если ваш заказчик будет вынужден принять систему и заплатить деньги,
он не будет ее эксплуатировать, что, несомненно, отрицательно ска­
жется на репутации поставщика решения и дальнейших отношениях.
Поскольку вы встречаетесь с человеком лично, вам нужно поста­
раться использовать не только устное общение (вы ведь и по теле­
фону могли бы все вопросы обсудить), но и другие составляющие
общения, характерные для непосредственной личной встречи. Если вы
видите, что ваш собеседник не может выразить свои мысли словами,
предложите ему нарисовать простую схему того, что он пытается вам
объяснить. Вы сами, в свою очередь, также можете рисовать какие-то
рисунки, схемы или диаграммы, для того чтобы наглядно проследить
информационные потоки, организационную структуру и т.п. Глядя на
свои и ваши рисунки, ваш собеседник будет оперировать не только
словами, но и зрительными образами, таким образом, у вас будет
больше шансов получить полную картину по каждому обсуждаемому
вопросу.
Другим важным качеством бумаги является то, что она пред­
ставляет собой также и физический объект, который легко транс­
формируется: режется на части, сминается и т.п. Как уже упоми­
налось выше, человек воспринимает окружающую среду, используя
несколько каналов: зрение, слух, обоняние, тактильные ощущения,
и, наконец, вкус. Обычно во время интервью активно задействованы
зрение и слух, но аналитик может подключить еще и тактильные
ощущения — заставить собеседника раскладывать листочки бума­
ги, например, для демонстрации организационной структуры или
процесса. Этим приемом обычно приходится пользоваться, когда
ваш собеседник затрудняется с ответом на тот или иной вопрос.
Для включения тактильного канала восприятия можно использовать
не только бумагу, но и другие физические объекты, самый про­
стой — это ручка (или карандаш). Попробуйте попросить вашего
собеседника нарисовать что-то, если он затрудняется сформулиро­
вать мысль. Полезными могут оказаться также любые другие пред­
меты (стаканы, бутылки с водой и т.п): расставляя их на столе и во­
влекая в этот процесс собеседника, вы можете помочь ему выйти из
затруднительной ситуации и получить в итоге больше информации.
После того как все запланированные вопросы обсуждены, необ­
ходимо уточнить у собеседника, нет ли вопроса или темы, которых
Интервью 67
„■ „„Ш Н П И П Н Ш ПНИ " " ....... П К ........ I ........ " М И Ш И " ! ............" Н И Ш И " ....................П И Ш И ......... "Ш И Ш И

вЫ с ним еще не обсудили, но, возможно, с его точки зрения она

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

Окончание встречи
В заключение интервью важно еще раз вернуться к формирова­
нию ожиданий вашего собеседника. Если вы не скажете, что будет
происходить дальше, он может это просто придумать. В этом слу­
чае возможны различные недопонимания. Например, человек может
подумать, что вы прямо сейчас пойдете к разработчикам и все им
предадите, а они немедленно начнут делать систему и в ближайшее
время придут с готовым результатом. Также недопонимания воз­
можны относительно объема будущих разработок. Вероятно, отнюдь
не все, что пожелал ваш собеседник, окажется в готовой системе,
поэтому с вашей стороны будет очень разумно рассказать ему
о том, что будет происходить дальше (даже если вы это уже об­
судили в начале встречи, напомнить будет нелишним). Расскажите
о дальнейших шагах, которые вы и ваша команда будете предприни­
мать: о том, какие еще встречи запланированы, кто будет принимать
решения о дальнейших шагах, кто будет определять объем разрабо­
ток и сроки поставки и другую доступную вам информацию, которой
вы вправе поделиться с собеседником. Также важно предупредить
вашего визави о том, что у вас в дальнейшем могут возникнуть во­
просы, и попросить разрешения с ними к нему обращаться.
Еще очень важно поддерживать мотивацию человека участвовать
в проекте, поэтому старайтесь в заключение упомянуть о том, что
для человека важно, о том, что является главной причиной его уча­
стия в проекте. Однако постарайтесь сделать это аккуратно, так чтобы
не пришлось потом расплачиваться за обманутые завышенные ожидания.

После встречи
После проведения интервью постарайтесь как можно раньше
прислать протокол встречи. Возможно, это поможет вашему собе­
седнику вспомнить что-то, что было упущено в ходе беседы.
68 Глава 2. Сбор требований
1Ш 1 1 11Ш Ш Н 1И 1т 111Ш 11Ш И 1Ш 111Ш Ш Ш Ш 1Ш Ш 11Ш 11111| Ш 1Ш и Ш 1П Ш Ш 1Ш 1Ш Ш П Ш Ш П 1Н П 'Ш Н 1П Ш Ш 1! 1Ш | | Ц | ц
Ш Ш ит Ш |

Также важно сразу начать фиксировать результаты вашей встречи

в виде требований.

Телефонные переговоры
Теперь давайте обсудим проведение интервью по телефону. Под- ’
готовка к проведению телефонного звонка не очень сильно отли­
чается от подготовки к проведению личной встречи. Однако у вас
может не оказаться возможности влиять на то, откуда с вами будет
разговаривать ваш собеседник. Как и в случае с личной встречей,
нужно постараться сделать так, чтобы вас в процессе звонка не от­
влекали и звонок проходил в удобном для вашего собеседника '
месте и в удобное для него время.
Продолжительность звонка также нужно рассчитывать с учетом
личных предпочтений вашего собеседника, а также ваших предпо­
чтений.

Для меня встреча продолжительностью около часа является

вполне комфортной. Двухчасовая встреча — это на грани моих ;
возможностей. По телефону комфортная предельная продолжи- .
тельность разговора для меня в полтора-два раза короче. Од­
нако другие люди, наоборот, могут часами висеть на телефоне,
а личная встреча их тяготит.

Исходя из планируемой продолжительности телефонного звонка,

вам нужно готовить вопросы таким образом, чтобы на все хватило
времени. Чем короче запланированный звонок, тем более структу­
рированным должно быть интервью.
Считается, что при телефонном общении вы теряете 70 % ин­
формации, которая передается при личной встрече в рамках невер­
бального общения. Это в первую очередь мимика и так называемый
язык тела. Все, что остается у вас, кроме произносимого текста
в телефонном разговоре. — это интонация голоса, с которой вы
и ваш собеседник произносят слова.
Интонация, пожалуй, наиболее важный элемент речи. Одни и те
же слова, произнесенные с разной интонацией, могут передавать
различный смысл. В устной речи нет вопросительных или вос­
клицательных знаков, их роль выполняет та интонация, с которой
произносятся определенные слова. С помощью интонации аналитик
может удерживать внимание собеседника, подчеркивать наиболее
важные темы. С другой стороны, анализируя интонацию, с которой
Телефонные переговоры gg

говорит собеседник, аналитик может почерпнуть массу информации

о его отношении к тем или иным проблемам, степень его личной
заинтересованности в их решении и т.д.

Важно стараться при телефонном разговоре следить за ми­

микой лица, поскольку так вам гораздо легче передавать инто­
нацией эмоциональную окраску ваших слов. Трудно говорить
серьезно, светясь при этом от счастья, с улыбкой от уха до уха.
и наоборот — трудно передавать голосом позитивные эмоции
с кислой миной на лице. Именно поэтому операторов колл-
центров заставляют улыбаться в процессе разговора с клиентом.

Вы можете повысить температуру канала коммуникации, если

будете применять видео. Однако видеосвязь может как улучшить
информационный обмен, так и ухудшить его. Любые технические
проблемы в процессе видеозвонка могут серьезно повредить ин­
тервью. Используйте видеозвонок только в случае, если вы уверены
в том, что его качество будет не хуже телефонного звонка.

У меня достаточно много опыта проведения встреч, в том

числе интервью, с помощью видеосвязи. К сожалению, не всег­
да этот опыт был положительным. Skype, например, не всегда
давал нужное качество связи. Во многих случаях была возмож­
ность использовать переговорные, оборудованные видеокон-
ференц-связью. Казалось бы, выделенные каналы, отличное
оборудование, хорошее и стабильное качество связи, но не все
так хорошо на практике. Дело в том, что камеру и телевизор
обычно устанавливали в одном месте, чтобы, глядя в телевизор,
где показывают собеседника, человек смотрел в камеру. А теле­
визор обычно устанавливали напротив окна, потому что если
установить его на стене, где есть окно, ничего не будет видно,
из-за того, что человеку нужно будет смотреть против света.
Получалось, что человек всегда сидит спиной к окну, и вы види­
те не человека, а его черный силуэт. Зачем тогда, собственно,
видео, если можно поговорить и по телефону с тем же успехом?
Мой вам совет: сначала проверьте средства видеосвязи, прежде
чем применять их для проведения интервью.

В ходе телефонного звонка вы также можете использовать вир­

туальные пространства, где вы сможете показывать собеседнику
экран своего компьютера. Это помогает заменить тот самый листок
70 Глава 2. Сбор требований■
I Шинн ниш шшипншнщ-;

бумаги, о котором речь шла выше. Однако, к сожалению, полностью

заменить его не может, поскольку не масштабируется и не является
физическим объектом.
Сама схема проведения телефонного разговора не отличается от
описанной выше схемы проведения интервью при личной встрече.

Переписка
Если вы решите опросить представителя заинтересованной сто­
роны по почте (электронной или даже обычной — бумажной), вы,
как утверждается, потеряете до 90 % информации в ходе такого
общения. Все, что у вас останется, — это текст. Вы потеряете и ин­
тонацию голоса, и невербальные составляющие общения.
Чем же хороша переписка? В первую очередь вам не нужно
думать об организации встречи. Это не значит, что вы вообще мо­
жете устраниться от организационных вопросов: вопросы выделения
времени человеком на общение с вами, его мотивация по-прежнему
будут важны для успеха проекта. Это всего лишь означает, что вам
не нужно думать о месте и времени проведения встречи. Вы посы­
лаете свои вопросы и ждете ответы. Другое важное преимущество
переписки — вы получаете сразу автоматически протокол интервью:
вопросы и ответы на них в одном письме.

В ряде организаций, в которых мне приходилось работать,

к электронной почте относились так же, как и к бумажной, это
значит, что подтверждение по электронной почте является прак­
тически равносильным физической подписи на бумажном д о ­
кументе. В такой ситуации ваши клиенты наверняка, будут от­
носиться гораздо более ответственно к тому, что они пишут, чем
к тому, что они говорят.

Другой положительной стороной переписки является то, что ваш

собеседник огражден от неприятной ситуации, когда он не может
вам сразу ответить на поставленный вопрос. У него всегда есть
время подумать, проконсультироваться с коллегами или посмотреть
документы, прежде чем дать ответ.
В чем же другие недостатки переписки, кроме собственно потери
информации, которая обычно приводит к неправильной интерпре­
тации вопросов и ответов? Переписка — это обыкновенно более
растянутый во времени процесс, и этот процесс может существенно
повлиять на конечные сроки проекта.
Групповы е встречи 71
.

Я неоднократно слышал о правиле трех писем, применяемом

во многих компаниях, специализирующихся на разработке ПО. Это
правило звучит так: если тебе не удалось решить вопрос с помо­
щью трех писем (имеются в виду три исходящих письма) — по­
звони, не удалось решить с помощью звонка —назначай встречу.

Вы не можете контролировать аудиторию при переписке, ваш

собеседник может подключить любое количество людей для ответа,
они в свою очередь могут отвечать не одновременно, противоречить
друг другу и так далее. Это может вызвать массу негатива и при­
водить к непредсказуемым результатам. При этом предсказуемо
одно — потеря времени.
Мой совет прост: применяйте переписку как можно реже в ка­
честве единственного инструмента сбора требований. Старайтесь
применять личные встречи и звонки в сочетании с перепиской,
чтобы таким образом повысить эффективность сбора требований.

Групповые встречи
Под групповыми встречами мы будем понимать встречи по сбору
требований, когда на одну встречу приглашаются несколько представи­
телей заинтересованных сторон (одной или разных). Достаточно боль­
шой опыт проведения таких встреч мне говорит о том, что это очень
рискованное мероприятие, особенно для начинающего аналитика.
Начнем с подготовки. Аналитику необходимо найти помещение, где
все могут собраться, но это не самая трудная часть подготовительной
работы. Необходимо согласовать время, удобное для всех участников
встречи. На этом проблемы не заканчиваются. Часть людей может
подтвердить свое участие, но не прийти. Причин может быть масса:

• поменялись планы, возникла более важная встреча, например;

• заболел;
• решил не пойти, потому что увидел в списке участников встречи
кого-то, кто, по его мнению, может сформулировать требования
и ответить на все вопросы за него. А тот, другой, может тоже
не прийти по той или иной причине.

В назначенное время соберутся не все участники, обязательно

кто-нибудь опоздает.
В начале такой встречи нужно установить контакт со всеми
участниками, попытаться полностью контролировать ход обсуждения
72 Глава 2. Сбор требований
lillllllllllllllilllllllllllllllllltllllillllllllllllllllllllillllltllllfllllllllllllllllllitllllllllllllllliM IIIIH IIIIIIIIIIIIIllilllllllllllllllllllliiiiiiiiii

вопросов, стремиться к тому, чтобы все участники высказали свое

мнение. Однако:

• участники могут начать выяснять отношения между собой, об­

суждать разделение зон ответственности, заниматься полити­
ческими интригами и т.п.;
• один из участников может стесняться говорить в присутствии руко­
водителя или других «более опытных и авторитетных товарищей»;
• другой может постесняться признаться в том, что он что-то
не помнит, и начнет сочинять

Иными словами, если позволяет время, лучше все-таки встречать­

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

Семинар рабочей группы (Requirements Workshop)

Эта методика сбора требований очень мало распространена в на­
шей стране. В англоязычной литературе это называется Requirements
Workshop. «Семинар» или «Семинар рабочей группы» — это мой воль­
ный перевод этого термина на русский язык. Итак, что же это такое?
Суть состоит в том, чтобы собрать всех представителей заинтересован­
ных сторон в одном месте на целый день или даже на два дня и пол­
ностью посвятить это время разработке и согласованию требований.
Мне лично не приходилось использовать эту методику на практике.
Однако я всегда рассказываю о ней на своих курсах, и мне доводи­
лось встречать людей среди слушателей, применявших ее для сбора
требований в своих проектах. Данная методика достаточно хорошо
и подробно описана у Дина Леффингуэлла [3]. Нейл Мейден (Neil
Maiden) проводит семинары по креативному сбору требований, и это
тоже очень интересная методика [6]. Она немного отличается от
классической, но в целом формат проведения семинаров аналогичен.
Основной смысл таких семинаров — это сбор требований в необхо­
димом объеме за минимальный срок. Я лишь кратко опишу основные
принципы, по которым поводятся такие семинары, а пытливый читатель
сможет сам найти подробную информацию по этому вопросу.
Правильная подготовка к семинару — это ключ к успеху.
Первое, что нужно сделать при подготовке к семинару, это вы­
явить все заинтересованные стороны и определить представителей
от каждой из этих сторон. Каждого из этих людей нужно убедить
Семинар рабочей группы (Requirements Workshop) 73

0 необходимости посетить семинар, ставя во главу угла эффектив­

ность этого мероприятия и те выгоды, которые получит он сам и/
или его отдел/организация от успеха мероприятия.
Второй шаг в подготовке к семинару — это выбор правильного вре­
мени и места проведения мероприятия. Все участники должны иметь
возможность провести это время (день или два) за пределами рабочего
места, не отвечать на звонки, электронную почту. Поэтому некоторая
удаленность от офиса пойдет на пользу. Также важно продумать то, как
люди попадут туда, где будет проводиться семинар. Задержка или, что
еще хуже, неявка любого из участников может расстроить все планы.
Третий подготовительный шаг — это сбор и распространение сре­
ди участников семинара подготовительных материалов. Стоит уделить
пристальное внимание этому пункту, ведь если материалов будет
очень много, их никто не будет читать, если слишком мало, то их
будет недостаточно для подготовки участников к семинару. Подго­
товительные материалы могут включать как документы, относящиеся
непосредственно к проекту, так и те, которые помогут настроить­
ся на правильный лад. В частности, настроить «раскрепощенное»
мышление, которое может пригодиться в процессе семинара. Также
хочу обратить внимание, что материалы лучше высылать не поздно
и не рано: у человека должно быть как минимум 2-3 дня, чтобы мож­
но было успеть с ними ознакомиться. Если вы пошлете их слишком
рано, например, за месяц, то он может элементарно о них забыть,
поэтому лучше высылать материалы за 3-7 дней до начала семинара.
Четвертый, не менее важный шаг в подготовке семинара — это вы­
бор ведущего (в оригинале он называется facilitator). Самая понятная
аналогия, наверное, это наемный тамада на свадьбе. Он независимый,
для него все родственники и друзья — что со стороны жениха, что со
стороны невесты — одинаковы. Его задача — провести мероприятие
так, чтобы было весело и позвали еще. Так же и ведущий семинара:
его задача — вести семинар так, чтобы участники не отвлекались,
а работали в команде для достижения цели — собрать и утвердить
в короткий срок требования. Если не удается найти внешнего неза­
висимого ведущего и приходится брать кого-то из проектной команды,
то ему запрещается участвовать в обсуждении и вносить свои идеи на
рассмотрение. Его работа — вести семинар и следить за регламентом
и соблюдением правил семинара его участниками.
Повестка дня семинара обычно состоит из следующих основных пунктов:

• Вводная часть — представление места, повестки дня и правил

проведения семинара;
74 Глава 2. Сбор требований
Н И Ш И ............... I fl 111 И 111И 11111 i I I I П 1 111II1111111111 }Н | ! и 1111И 111I I 111I I 111И 11П 11111 И 11111111111 ■I I I tl 111И 11111 1111..............

• Презентация проекта — по сути, это краткий экскурс по под­

готовительным материалам, отправленным заблаговременно;
• «Мозговой штурм»;
• Определение возможностей и ограничений;
• Определение приоритетов и рамок проекта/фаз;
• Определение дальнейших шагов.

После вводной части и презентации проекта проводится «мозго­

вой штурм». Это достаточно распространенная методика, описанная
во многих источниках. Суть ее заключается в том, что каждый дол­
жен высказывать свои идеи, критика запрещена. Все идеи фикси­
руются, например, с помощью карточек.
Далее эти идеи группируются по смыслу, и с ними начинают
работать командно. Если участников много, то они разбиваются на
команды, в каждой из которых есть и представители заинтересо­
ванных сторон, и представители команды разработки (желательно,
чтобы они умели формулировать требования). Если участников мало,
то все коллективно работают над собранными идеями. Цель данного
этапа — сделать из идей требования, при этом не стоит забывать,
что необходимо получить полный перечень требований, включая
ограничения.
После определения полного списка требований наступает этап
определения границ проекта (или фазы проекта). Возможно, что все
требования будут реализованы, а может быть, требований получится
очень много и нужно будет их распределить по фазам или даже
часть из них отбросить ввиду имеющихся ограничений.
В завершение определяют дальнейшие шаги.
Это очень сжатое описание методики. Совершенно понятно, что
такой подход, несмотря на все его преимущества, требует значи­
тельных затрат на его подготовку и проведение. Это сложный метод,
с которого аналитик вряд ли начнет свою карьеру.

Опросы
Опрос или анкетирование — это метод, который может помочь
аналитику в двух ситуациях.
Первая и достаточно распространенная ситуация — когда пред­
ставитель заинтересованной стороны не может в полной мере сфор­
мулировать требования ввиду того, что реальных пользователей
системы, работающих в одной роли, очень много. Эта ситуация
характерна, например, для коробочных продуктов. У продукта может
Опросы 75
.............. I M I l i ..........l l l l l l l l ........................................................................................................................................................................................ I l l l l l l l l i r i l l l l l l l l l l l l

быть не одна сотня или даже тысяча пользователей, и один чело­

век вряд ли сможет сформулировать все требования от лица такой
аудитории. В заказной разработке такие ситуации тоже возможны,
например, в колл-центре может быть несколько сотен операторов,
работающих в три смены. Для того чтобы наиболее полно собрать
требования, бывает очень полезно провести опрос среди большого
количества пользователей.
Вторая ситуация, в которой мне помогало использование опро­
сов, — это выявление наиболее активных представителей заин­
тересованных сторон. Когда между инициатором проекта и заин­
тересованными сторонами были конфликты или разногласия, мне
приходилось действовать в обход.

Приведу пример. Руководство компании совершенно спра­

ведливо считало, что вся информация о клиентах, какими бы
услугами компании они ни пользовались, принадлежит ей,
а не продавцам услуг. У продавцов была прямо противополож­
ная позиция — они не хотели делиться информацией о «своих»
клиентах с коллегами, продающими другие услуги. Инициати­
ва по внедрению единой CRM-системы, которая бы охватывала
все направления бизнеса и объединяла бы информацию о пред­
ставителях всех клиентов и их взаимодействии со всеми про­
давцами, была адресована руководством компании в ИТ-отдел.
Естественно, при такой постановке вопроса было достаточно
сложно найти взаимопонимание со всеми отделами, взаимо­
действующими с клиентами. Было решено начать с тех, кто сам
готов принять участие в проекте и хочет сотрудничать. Я сделал
опрос с помощью интранет-портала и разослал его нескольким
десяткам сотрудников, работающих с клиентами, в результате
откликнулись восемь, и это послужило хорошим стартом. Най­
денные с помощью опроса восемь человек стали первыми пред­
ставителями заинтересованных сторон, с которыми началась
работа на проекте.

При составлении опросов (анкет) особое внимание нужно уделять

тому, сколько и каких вопросов вы посылаете. Чем больше вопросов,
тем меньше человек дойдет до конца. Чем меньше вопросов, тем
меньше информации вы получите. Чем больше открытых вопросов
вы зададите, тем дольше вы будете обрабатывать результаты, чем
больше закрытых вопросов вы зададите, тем больше шанс упустить
что-то важное. Поэтому необходимо тщательно продумывать вопросы
76 Глава 2. Сбор требований

при составлении анкеты. Обычно формулируют несколько закрытых 1

вопросов, для того чтобы получить статистику, и несколько открытых, 1
чтобы выявить новые требования.

Вернемся к нашему примеру со службой поддержки прило- J

жения. Допустим, что у нас много специалистов СП и мы хотим 5
провести среди них анкетирование. Сначала нужно определить, j
зачем мы это делаем и что такого мы должны выяснить у всех 1
специалистов СП, чего мы не можем выяснить у одного пред- Ц
ставителя. Вопросы могут быть такими:

• Какие наиболее частые проблемы возникают сейчас при \

регистрации обращения пользователя?
• Какие наиболее частые проблемы возникают при эскала- \
ции обращения на вторую линию поддержки?
• Какой информации не хватает специалисту СП для улуч- ^
шения его работы и сокращения времени на закрытие об- \
ращения?

Как мы можем заметить, все наши вопросы открытые, и при ■']

небольшом числе специалистов СП данный подход достаточно \
эффективен. Если бы мы анкетировали большой колл-центр, ^
то вряд ли бы мы отважились задать много открытых вопро- ■
сов.

Проведение опросов среди будущих пользователей системы по­

вышает их самооценку. Этим мы показываем людям, что их мне- i
ние важно. Они чувствуют себя вовлеченными в процесс создания ;
системы, особенно если по итогам опроса проводятся какие-то
мероприятия, направленные на публичную демонстрацию того, что !
результаты опроса реально используются для улучшения жизни ко­
нечных пользователей, принявших в нем участие. Впоследствии это
положительно сказывается на том, как идет приемка и внедрение
новой системы в промышленную эксплуатацию.

Другие способы получения требований

Наблюдение за работой людей I

Наблюдать за работой людей можно по-разному. Во-первых, мож­

но попросить разрешения прийти на рабочее место человека, где
другие способы получения требований 77

он расскажет, как он работает. Во-вторых, можно найти место ря­

дом с рабочим местом человека, наблюдение за работой которого
вам интересно для получения требований. В-третьих, вы можете
не присутствовать рядом, а наблюдать за работой человека уда­
ленно, с помощью камер и/или средств, позволяющих видеть, что
человек делает на компьютере (или использовать для этого журналы
операций в системе).
Когда прибегают к таким способам получения требований? В ос­
новном, когда представители заинтересованной стороны (в частно­
сти будущие пользователи) не могут внятно рассказать о том, как
они выполняют свою работу. Вспомним Рис. 6 — это третий уровень,
когда работа доведена до автоматизма и человек не отдает себе
отчета в том, как он делает свою работу. В этом случае посещение
рабочего места представителя заинтересованной стороны может су­
щественно ускорить процесс получения требований. Аналитик своим
глазами сможет увидеть, как и что делают люди.
Однако у этого метода есть также и свои недостатки. Во-первых,
обычно это более трудозатратный метод по сравнению с интер­
вью. Для получения одной и той же информации приходится тра­
тить больше времени. Во-вторых, часть работы, возможно, аналитик
не увидит, поскольку она может выполняться не каждый день. Это,
например, периодическая отчетность или работа с нестандартны­
ми случаями или ошибками. В-третьих, человек может вести себя
в присутствии аналитика на своем рабочем месте скованно и стес­
ненно, бояться показаться некомпетентным в присутствии коллег,
ошибаться и путаться. Может рассказывать не то, как он работает,
а то, как это положено по инструкции, даже если это неудобно и он
и его коллеги уже давно выработали для себя более эффективные
способы выполнения своей работы.
Если работа аналитика связана с разработкой и развитием си­
стем автоматизации деятельности предприятия, на котором он ра­
ботает, т.е. он сотрудник той организации, для которой делается
автоматизация, то ему имеет смысл найти рабочее место не в ИТ-
отделе, а в бизнес-подразделении. Это способствует большему по­
гружению аналитика в предметную область, хотя и имеет также свои
негативные стороны. Если аналитик сидит вместе с представителями
бизнеса, он очень много времени вынужден тратить на поддерж­
ку. И в то же время он становится менее доступен для команды
разработки. Еще в моей практике бывали случаи, когда аналитик,
посидев рядом с представителями бизнеса, затем уходил работать
в бизнес-подразделение. Поэтому по возможности нужно стараться
78 Глава 2. Сбор требований
1 Н 1 1 1 Н 1 1 1 1 Ш |1 1 1 1 1 Н 1 1 Н 1 1 Ш 1 1 Н 1 М 1 1 1 Н 1 Н 1 1 Н Н 1 1 Н 1 Ш 1 П 1 Ш Ш Ш 1 |1 1 Н 1 |1 Н ||Н Н 1 1 1 1 1 1 Н 1 1 Н 1 |1 Н ||1 1 Ш Ш 1 ||П 1 1 Н 1 1 Н 1 Ш 1 Ш Ш ||1 И Ц 1 Н 1 1 Н Н Ш ||

на некоторое время сажать аналитика в бизнес-подразделение, но

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

Временное выполнение аналитиком текущей работы будущих

пользователей системы
От наблюдения за работой пользователей аналитик может
в какой-то момент даже перейти к временному выполнению работы
вместо будущих пользователей системы. Конечно, такая ситуация
больше характерна тогда, когда аналитик работает в штате орга­
низации, для которой выполняется работа по автоматизации ее
деятельности. Редко когда аналитику со стороны внешней компании
разработчика доверяют выполнять реальную работу, хотя я лично
наблюдал и такие ситуации.
Какая от этого польза? Очевидно, что аналитик в таком случае
максимально глубоко погружается в предметную область. Однако
не стоит забывать и о недостатках такого метода получения требо­
ваний. Основным недостатком такого метода, несомненно, являются
большие потери времени. Однако это не единственный недоста­
ток. Я уже писал во введении, что одна из трудностей, с которой
приходится сталкиваться аналитику, — это различия в культурном
и образовательном уровне между ним и представителями заинтере­
сованных сторон. Это значит, что велика вероятность, что аналитик
будет выполнять работу не так, как будущие пользователи системы.
Следовательно, может получиться, что аналитик соберет требования
другие способы получения требований 79

для системы, которая будет удобна для работы аналитику, а не тем

людям, которые будут ею пользоваться на деле.

В свое время в среде программистов ходила шутка: «Рано

или поздно интерфейс любой программы, которую мы делаем,
становится похож на Visual Studio». Человек, проектируя систему,
хочет сделать ее удобнее для пользователя, а если реального
пользователя рядом нет, то он начинает ее делать удобной для
себя. Поскольку программист привык работать в среде разработ­
ки и считает ее удобной, то и интерфейс любой программы, кото­
рую он разрабатывает, без должного контроля со стороны может
очень скоро стать похожим на интерфейс среды разработки.

Также не стоит забывать о том, что аналитик может пропустить

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

У меня лично была в подчинении девушка-аналитик, которая

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

Эксперты и консультанты
Помощь экспертов в предметной области при сборе требований
может серьезно помочь аналитику, особенно начинающему. Эксперт,
если у него за плечами большой опыт выполнения аналогичных про­
ектов. очень полезен как источник знаний в предметной области.
Он помогает аналитику, рассказывая о том, как бывает на других
предприятиях и проектах. Но это не значит, что аналитик должен
воспринимать эксперта как истину в последней инстанции. Если
для коробочных продуктов эксперт, вероятно, и может выступать
в роли представителя заинтересованной стороны, то для заказных
разработок — только как человек, с которым можно посоветоваться
и узнать что-то из его опыта. Для заказных разработок необходимо
80 Глава 2. Сбор требований
11Ш 11|М Н Ш Ш Ш !Ш Ш 111 Ш 1Ш |11Ш 111111 111Ш 11111Н 111 !1Ш Ш 1|Ш Ш Ш 11Ш Ш Н 1111Н 1М Ш И 1Н Н 1Ш Ш Н Ш Ш 111Ш Ш И 1Ш 1Ш 1Ж Ш М Н 1'||

ориентироваться только на требования, полученные от представи­

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

В самом начале моей карьеры аналитика у меня был проект,

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

Системы
Системы также являются важным источником для получения тре­
бований. Стоит выделять следующие:

• системы, которые мы собираемся заменить в ходе проекта на

новую (или новые);
• системы, которые будут взаимодействовать с проектируемым
решением;
• конкурирующие или аналогичные системы.

Для любых разработок, за исключением новых и абсолютно уни­

кальных, обычно есть какая-то предшествующая система (как любят
говорить, «наследие», или legacy). Это система, которой в данный
момент пользуются люди, она помогает им решать их задачи, но чем-
Системы 81

то не устраивает. Существующая система дает аналитику более де­

тальное понимание проблем заказчика. Аналитику необходимо узнать:

• как система используется для решения задач бизнеса:

• какие функции в ней реализованы хорошо, а какие вызывают
нарекания;
• какие задачи в данный момент не могут быть решены с по­
мощью системы, каким образом и с помощью чего в данный
момент реализуются эти бизнес-задачи;
• какие функции системы не используются и почему;
• какие функции системы используются не по их прямому на­
значению.

Для меня самым распространенным и наименее очевидным

с точки зрения автоматизации бизнеса всегда было требование
«сделайте нам, пожалуйста, из каждого списка в системе воз­
можность выгрузки данных в MS Excel». Каждый раз причины для
этого были разные. Наиболее распространенные такие:

• «Текущая система не позволяет делать вот такой отчет,

а мы в экселе написали макрос, который по выгружен­
ным из системы данным его строит», т.е. на самом деле
существует требование разработать определенный отчет.
Аналитик должен зафиксировать это требование, хотя если
стоимость разработки отчета в несколько раз выше, чем
стоимость разработки функции выгрузки, возможно, имеет
смысл сделать выгрузку и оставить людям их макрос.
• «В текущей системе очень медленно работает функция по­
иска, поэтому мы выгружаем в эксель все данные, а в экс­
еле поиск работает быстро». В этом случае необходимость
выгрузки данных гораздо менее очевидна, имеет смысл
снабдить проектируемую систему надежной и быстро ра­
ботающей функцией поиска.
• «В текущей системе нет возможности (или она недоста­
точная) выборки данных по определенным критериям,
поэтому мы выгружаем данные в эксель и там пользу­
емся функцией автофильтров». В этом случае, так же как
и в случае с поиском, возможно, требуется расширенная
функция поиска или фильтрации информации в списке,
которая бы позволяла получать информацию в системе
в списке по заданным критериям выборки.
82 Глава 2. Сбор требований
1 1 Н 1 Н | | | 1 Ш Ш 1 1 М 1 1 1 1 Ш 1 11111 11Ш 1Ш и 1Ш 1Ш 111Ш 1111 11Ш Н Л 1 1Н !1Ш Ш 1Ш 1Ш М Ш 11 111Ш 1Ш Ж 1Ш | 11Ш Ш Ш 1 111Н Ш 1111 111111 11111Ш | | | | | | | |

Вторым типом систем, которые служат источником требований

для разрабатываемой системы, являются системы, с которыми нужно
будет взаимодействовать проектируемой вами системе. Казалось бы,
с ними все достаточно очевидно — аналитику необходимо получить
требования по интеграции. Однако стоит также изучить и возмож­
ности этих систем, особенно если эти системы принадлежат вашему
заказчику. Возможно, ряд требований, выдвинутых представителями
заинтересованных сторон, уже реализованы в системах, с которы­
ми должно быть интегрировано ваше решение. Это означает, что
вы имеете потенциальную возможность снизить риски проекта, со­
кратив объем разработок. Если часть требований уже реализована
в существующих системах, которые вы не собираетесь заменять, то,
возможно, достаточно лишь дать доступ тем заинтересованным ли­
цам, которым эти функциональные возможности необходимы для их
работы. Если же это по определенным соображениям невозможно,
стоит также обсудить данные функциональные возможности с пред­
ставителями заинтересованных сторон, выяснив, нравится ли она
им или не нравится и почему нельзя ее использовать для работы.

В моей практике я видел достаточно неприятные последствия

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

Третий тип систем, на которые стоит обращать внимание при

сборе требований, это аналогичные, или конкурирующие систе­
мы. В мире разработки коробочных решений это один из ключе­
вых факторов успеха. Компания, разрабатывающая решения для
массового рынка, должна досконально знать возможности систем,
конкурирующих с ее продуктами, иначе она рискует остаться без
продаж. Однако в мире заказной разработки также полезно знать
о функциональных возможностях готовых систем, их достоинствах
и недостатках. Это особенно актуально, когда перед аналитиком
документы 83
„ П И Ш И ........................... н и ш и ................... Ш И ................... П Ш П Ш Ш Н П Ш И ........ I ............... И М И .........И Ш М М Н Ш ........ I l l ........ Ш И П ........ ......................

ставится задача выбора между одной из продающихся на рынке

систем и заказной разработкой «с нуля».

Мне в своей практике приходилось участвовать в тендерах,

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

Документы
Анализ документов играет важную роль при сборе требований.
Документы позволяют собрать требования полнее, избежать ошибок
и пропусков, тем самым сократить количество запросов на измене­
ния, которые поступают во время реализации, приемки, ввода в про­
мышленную эксплуатацию и во время промышленной эксплуатации
разрабатываемой системы.
Можно перечислить следующие категории документов, помогаю­
щих аналитику собирать требования:

• внутрикорпоративные стандарты, процедуры, регламенты, долж­

ностные инструкции, описание производственных процессов и т.п.;
• документация на существующие (заменяемые), аналогичные или
конкурирующие системы, документация на системы, с которыми
разрабатываемая система будет взаимодействовать;
• обзоры, рейтинги, аналитические отчеты и сравнения функци­
ональности систем, присутствующих на рынке;
• законодательство;
• международные стандарты, отраслевые стандарты, ГОСТы и т.п.

Если в компании существуют регламенты и должностные ин­

струкции, а также описание бизнес-процессов, это может сослужить
хорошую службу аналитику при сборе требований. Такие документы
дают возможность взглянуть на все процессы «сверху» и понять
взаимоотношения между различными заинтересованными сторонами.
С другой стороны, они могут дать информацию о некоторых деталях,
которые, возможно, упущены в процессе интервью. Если документы
достаточно актуальны и подробны, их стоит использовать как для
м Глава 2. Сбор требований
И"»! ..

подготовки к встречам с представителями заинтересованных сторон,

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

В своей работе мне нередко приходилось пользоваться об­

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

Законодательство в ряде проектов является обязательным ис­

точником требований. Существует ряд отраслей, где законодатель­
ство достаточно сильно проникло как в область автоматизации, так
и в область хранения и обработки информации. К таким отраслям
можно отнести банковскую сферу, рынок ценных бумаг, обработку
персональных данных и другие области. Аналитик, принимающий
участие в разработке приложений для одной из законодательно
регулируемых областей, обязан хорошо знать применяемое зако­
нодательство.
Различного рода стандарты обыкновенно являются источником
требований для технических систем.
 Обращения в службу поддержки 85
I
• iiiiiit iiim iiiiiiiiiiiiiiiiiiiiiiiiit iiiiM iiiiiiiiiiiiiiiiiiiiiiiiiin iiiiiiiiiiiiiiiiiH iiitiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiit iiiiiiiiiiiiiiiiiiiiiiiiiiiii

К примеру, многие протоколы передачи данных — это де-

факто международные стандарты (TCP/IP, HTTP, HTTPS. FTP,
SMTP, и другие).
В частности, для обмена финансовой информацией приме­
няются протоколы SWIFT и FIX.

Обращения в службу поддержки

Обращения в службу поддержки можно рассматривать также как
очень ценный источник для новых требований. Этот источник оди­
наково ценен как для продуктовой разработки, так и для разработки
в рамках заказной разработки. Если служба поддержки правильно
организована, то обращения, которые представляют собой новые
требования, сразу попадают к аналитикам.
Однако даже если обращения пользователей, представляющие
собой новые требования, попадают к аналитикам, то в базе с об­
ращениями остается достаточно и другой полезной информации.
Анализируя обращения пользователей, можно сделать массу выводов
о том, как пользователи работают с системой, что представляет для
них трудность, что вызывает непонимание и нарекания,
Если аналитику приходится работать с закрытыми обращения­
ми пользователей, особенно в не очень хорошо структурирован­
ной базе, у него могут возникнуть трудности как технического, так
и психологического характера. В неструктурированной базе с об­
ращениями пользователей время на поиск информации может быть
очень большим, и тем не менее аналитик не может гарантировать
того, что он не пропустил что-то важное и понял все запросы верно.
Если говорить о психологической стороне проблемы, то аналитику
всегда неприятно работать с жалобами на систему, ведь обращения
пользователей означают по сути то, аналитик (если он причастен
к разработке текущей версии системы) не очень хорошо сделал
свою работу раньше.

Прототипы
Прототип — это модель. Смоделировать можно что угодно. При­
менительно к области разработки ПО под прототипами понимают
модель, которая демонстрирует те или иные аспекты внешнего вида,
архитектуры и поведения проектируемой системы. Важно отметить,
что любой прототип, который вы делаете в рамках сбора или уточ­
нения требований, должен отвечать следующим критериям:
 •iqtfHBwox иэтва ей aoxonnnBdJodu хитьАи xriaibo яхвхэиахо ojoxe
autf онжАн эн ‘BtfAdx хиавхэоэ эн ‘хэжоиои niqdoxox ‘BxonHWBdjodu
И1 ИВН ox 'V9A бн unioiodu nntnoiexogBd sxeiratfo хэжои эн ивэ »их
-т/вив ииээ ixonwwBdJOdu nojodotf нэжЛн эн ива V9A вн bnHBaodnw
-wBdJOdu buff BUHBBOdMwwBdjodu эхпев H0HH9wada00 nojAdtf иодощ
вн нэь 'эы э 1/ оняиэхиьвне \/8Л вн qxBaodMHWBdJOdu lAiahndu '^lBaocl
-nwwBdJodu хэы/оаеои bedoxox 'etfacb эжхвх oxe ‘onecj>dai.HH иихэяиэх
-ваоЕЯШэи qinodio и RiahOBd яхвниошяа ‘enHHBtf qinHBdx охяиох эн
хэы/оаеои BBdoxox 'Btfado oxe ихАэ ou BHHEaodnunxoxodu Bi/tf
|ээхз siAi 9iBwdo0 а аоиивф Леякои одоэо яхихэто эн Ахои эн

(qinooduo 9ля две эн

онжАн ЭЖ01 w o ie до ‘аиивф w o ie в n e io g e d ондоНА 'оньанох
‘пи ииээ) <ueioged wuVotu ондоМ хвх ‘Э1 иШаА >яв мАминим хвх
01 ‘lA tfeVio эн ииээ ажв\у т /неф aineanm eduo вШаэа o ih хв±
а и н а ж о ^ и e o a o io j ошчд ojqh A nhadioa ио±е аю ои шэНэн u d i
eaddh 'qdBttHei/Bх я1 эШ в iahox но хвх 'ивевхои и (/a o x j $IA1 e ie n
-dоф ‘аж оньэнох) i/ивф иовэ «aowodxBe ей» ubidoV эн вхииевхве
9U9±MBBiotfadu ahddioa и о т э о э вн /яд ииээ ‘оньэв tioяlвжuot/odu
/яд hujow вэиэфdэ^ни оюхэяиэ 1 ваоеяиои B um oiodu nxuatfadau
■qoounasdH эн o i-o ih Awa ээв и ‘япаэов esd яэииъьескэа ехиьее»
-ве waudLHaBiotfadu э /ящ ■цинэжouиdu в ^ о ф нвнвонэо ‘vdBtfHau
-вх я1 э\/ш л я а нэжиои хвх — эонжоиэ эомвэ и ‘unaionatfосивев
э ^ о ф вн яияд онжмо& oih ‘В1 нэи 1гх m a in a e io tfa d u э ^ о ф вн
япяд онжиоИ oih :вэиэф dэlни оюхояиэ 1 ваоея1ю и иинввоэвюоэ
вн ошяд m U B d a iu ojohiai оннадооо '(и м эм в е ‘nhadioa ‘вцвш-э
‘ихноае) aoiHani/x H w m a iH e e io tta d u о иинвимох aoxuHt/Adioo
хииаю иэУ опивеа о а/яннви ажхв! в ‘xtsHHaihouffadu хи ‘a o in a
-них xnuainaBioVadu о эпннвН ouBx<daVoo а и н а ж о и ^ и «hadioa
4dBtfHdi/B)i» вит unHaxowndu uutf эиaф dalни иихэячэ! ваоеяиои
яlBBNiBgedeBd и unH eaogadi Я1еэии яoouaaoV o i-x e x анщ

чяиэхэиэ иэиэхваоеяиои xnfriAtfAg хитвэ ы/V OH90d9iHH иияэ

-яиэ1 ваоея1гои ипндоУА эохв1 охь ‘нох о иэУи яиньохои ино ‘онжва
ээнэм эн охь и ’HHHBaogadx х1яня1/вноиУ1»нЛф Bdogo ыЛ/ хиньохэи
эжхвх е 'xiqHHBtr хи^пвоховн хиньохэи — ино чяц-ивф ихе вн эинви
-ина aoH4i/Bxondu axnBniBdgo :хэаоэ ива hoim ‘laoxg siAl э х в ^ о ф а
аоиивф оахээжони вэхиУохвн иинвииох иоЬГжвх а оныядо 'HnnBdouo
хионэ ихэвь ииПвеихвиохав ыЛ/ иоээнеид boxoiAeqi/ouon 9tqdoxox ‘m u
-ивф х и хвх ‘иоээнеид nowHTnofAdnxBAi/uoxe ‘^^lкинэжol^иdu vwtnAxox х
uAxoot/ хвх яьоиои хэжои ива хиннви хиТпвохэвн иинэьА1/ои д

Ш 111Ш 11111111Ш |||11Ш |1Ш ИП 1Ш 111Ш Ш 11< 111111111М М 111||||1111Ш М Ш |1||11111111111111111111|1Ш 11|1П Ш 1111М 111111Ш 1111111Н 1111Ш 1111Ш Н

IS wuHioiodU
 «Axibuube» яle i/a tf OHhodo чэоитисУи еЮо»ин ьэя±ьиаь
.ou ешяд енжиои эн m i aedoiox ‘ьиПемйофни ьеняитеэб яоеииав
-ou aloaw монШ в м о т з вн et/iox ‘/я т ю и э ит эиб и lHawon а
oxquoi ииинтиэа иинвводабх моннэтАиоби о и ‘auou oie итоАи
■,0du вхииевхве nnodoio оэ хэвоиэ/-, («хххххххххххх» atfoda oi-oih
oifiqg m i ‘uoinVoa o ie хвх) а/янней1эиГпьоювн вн вжохои эн ешяд
uedoiox ‘un'newdocpHH внэниоиве вшяд m i oih ‘Awoiou он наш он
stnAuodu ошяд оно BonacfrdaiHH 0ююяиэ±вв 0£яи0и иинваоэвюоэ
gueie wdHtfduoou вн eonecpdaiHH ojoxcnuai ваоеяиои eunioiodu
иинваоэвиюэ au eie вн и ‘m Heaogadi sdogo ausie вн и онаТпАи
-odu оияд am eaogadi o iq т и э 1 ваоЕяиои паз в эн вниАюои яияд
вшяд внжиои bBdoiox ‘о/иПв^оф ни о<Аняшеи'пнэШфно> Olfвжвdg
-ою яэотзевю иивюиаиэоиа хвх ‘иаиои ей ohVo аи'тиоювн вн
хижохои эн 'Х1янне& aunioiodu а винввоЕяиоиэи ве-еи иэгпхинеов
‘nm u g o d u dawndu untfoandu jauuox хиом ей ниио 1я&жен&о

эи Гп во ю ен
вн ижохои чнэьо a n d o x o x ‘апннвУ юЛминим >в» nirn x e u m o io d u а
awHHBtf araH4i/Bad охяиох qiBaoeqt/ouon boqiB deio Btfjaoa смийохдоэн
‘B iraiB aoesi/ou ьиУ ia irh ib h o u и wwhWbluish mqg u n io io d u R g o ih
э^эю иэ но ‘0H 4t/ain)K0!/0utfadu
n ow eA d m aao d u a q iB i/a V latfA g
*»в» ‘» b i B naion atf awHHairatfaduo qiBHi/0UR8 Ааааоиаь qiB i/oaeou a i
— WRHanxxBdaiHM ажв^ пии хвиПвАшэ XR H H auatfaduo 8 ниэю ио
аинэАааои qiB aodndiO H O w atf ‘dawnduBH — w naoahnnBHntf q iR g 1эж
-Окм u n io io d u т в д 'XRHHBtf isdA ixA dio nun ииПвм1офни ‘a o iH a w a i/e
эинэжoLfouoEd эонмиве8 Я lв ж в d g 0 i 0 0 ЯЯ1/01 a i ‘кмихэаьихвлэ яияд
хэжом u n io io d u т в д ’nxiogB dE Ed atfad o a u n io io d u sib o h u b h nun
‘nnhBiHaeadu n » a o io jtfo u RwiAiEdiodu orVtiowou э o ie qiELratfo nun 'n j
-вмЛд ЭХ13И1/ вн в и н а ж о ^ и B O i^ d a iH n oJOXoqi/aiBsoeqtrau u n io io d u
nxAd 10 qiBaoondBH Э13Жом R g винаьэиээдо 0 J0 HwwBdJ0 du ojatnotB i
-ogBd atfna a o » q i/o i эн loiBatsg iqu n io io d u o ih 'q im a w io онжвд

■иидвинва
-o g a d i о qiB iog ed о н а т я в Hodoio xiqHHBaooadaiHHBe n ai/ain a
-Biotfedu qiBaodntioaoduo iqgoih o jo i uuV ‘XBnnBaogadi а x r h
-нэжоиеи ‘natfn otnriEenirBad qiBaodndionoiAiatf нажиоИ u n io io d u •
:xnhodu
хээа 10 BoqiESodnjBdiogB и iqwaiono xB»niondai>iBdBx хпннаи
-atraduo вн Hahoiotfedooo яияд наж1/огг B unioiodu »HhiogBdeBd •
InauaiBaoEqi/ou uutf w rh ib h o u и wiqHtfBi/jBH qiw g ,0Hqi/aiB80t?'
-ai/o в miHalmgo qiBiowou нажио» u n io io d u ‘qi/aWow ввхвоа »вх •

HHHeeogadi dogo ‘ Z e a e irj - 98

88 Глава 2 . Coop требований

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

• Первая угроза — это напрасная трата времени и ресур­

сов (в случае если эти новомодные элементы пользовательского
интерфейса не дают выигрыша по времени разработки);
• Вторая угроза — это то, что представители заказчика отвле­
каются от решения действительно важных для проектирования
пользовательского интерфейса вопросов. Следовательно, ана­
литик с таким прототипом имеет все шансы потратить время
на обсуждения красоты новых элементов и не успеть обсудить
важные аспекты.
• Третья угроза заключается в том, что новые технологии вообще
и элементы пользовательского интерфейса в частности могут быть
недостаточно надежны. И в дальнейшем при тестировании, при­
емке и эксплуатации могут показать себя не лучшим образом —
приводить к ошибкам и даже «падению» всего приложения.

Чтобы избежать таких проблем, я рекомендую использовать толь­

ко проверенные технологии, стараться избегать продажи новых тех­
нологий на этапе прототипирования, если это возможно, особенно
если это не является прямой ответственностью аналитика и не яв­
ляется главной бизнес-целью всего проекта.
Другая распространенная ошибка заключается в том, что про­
тотип содержит много всего. С его помощью пытаются показать
много разных аспектов и обсудить много вопросов. С таким про­
тотипом аналитику приходится прилагать усилия, чтобы удержать
представителя заинтересованной стороны в рамках намеченных во­
просов. Человек часто отвлекается и начинает уходить в сторону
от намеченного обсуждения. Для того чтобы этого не произошло,
необходимо стараться прототипировать только то, что необходимо
для обсуждения, возможно, придется сделать несколько разных про­
тотипов. каждый из которых имеет определенную цель — обсудить
с представителем заинтересованной стороны только один вопрос.
Заключение 89
jiiiiiiiiiiiiiaiiiiiiiiiiiiiiH iiiim iiiiiiiiiiiiiiiiiH H iiiiiiiiiiittu iiu iiiiiiiiiiiiiiiiitiiiiiiiiiiiiiiiiiiiiiiiiH iiiiiiiiiiiiiiiiiiiiiiiiu u iiH iiiiiii»

Для того чтобы избежать рассеивания внимания представи­

теля заказчика при обсуждении прототипа пользовательского
интерфейса, не обязательно рисовать пустые формы и распола­
гать на них только те элементы, которые вы хотели бы осудить.
Достаточно просто разработать один раз форму (или формы),
а затем затенять все, что не касается обсуждения того или иного
вопроса.

И самые большие проблемы могут у вас возникнуть, когда ваш

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

Существуют разные приемы, позволяющие избежать ситуа­

ции, когда на этапе прототипа заказчику может показаться, что
у вас есть готовая работающая система. Первый и самый про­
стой — это всегда показывать только картинки и никогда не по­
казывать работающее приложение — говорить, что картинки на­
рисованы в графическом редакторе, дескать, это все «фотошоп».
Если нужна динамика или интерактив, стараться использовать
средства для прототипирования, отличные от среды разработ­
ки настоящего приложения, — если разрабатывается тяжелый
интерфейс, прототипируйте в web. Если разрабатывается web,
прототипируйте в тяжелом интерфейсе (win). Или, как я уже
агитировал, используйте для разработки прототипа MS Excel —
тогда уж точно никто не подумает, что у вас уже есть готовое
рабочее приложение.

Заключение
Работа по сбору требований — это самая трудная часть работы
аналитика. Как говорит Карл Вигерс, это не похоже на сбор полевых
цветов на лугу летним теплым солнечным днем, это больше похоже
на добычу руды: извлекаем на поверхность из недр земли много
породы, прилагая при этом большие усилия, для того чтобы потом
90 Глава 2. Сбор требований 4
iiiiiiiiiiiiiH iiiiiitiiiiiiiiiM iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiH iiiiiiiiiiiiiiiiiiiiitiiiiiiiiiiiiim iiiiiiiiiiiiiiiiiiiitiiiiiii,,,^

из нее выплавить немного металла. Если брать золото в качестве

примера, то на сегодняшний день рентабельными считаются место­
рождения. где из тонны породы добывают 4-5 граммов драгметалла.
Такая же тяжелая работа ожидает аналитика. Люди, которые по­
лагают, что, придя к представителям заказчика, они получат готовые
четкие требования, как минимум наивны, и их ждет разочарование.
Для того чтобы сделать эту работу хорошо, аналитику не стоит
полагаться только на свой предыдущий опыт и знания, необходимо
каждый раз прилагать усилия — на каждом проекте, с каждым за­
казчиком, с каждым представителем заинтересованной стороны.
Заключение 91
iiiiiiiiH fiiiiiiiiiiiiitiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiK iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiia iiiitiiiiiiiiiiiiiiK iiiiiin iii

Глава 3. Работа с собранными требованиями

Теперь, пользуясь нашей метафорой с добычей золота, время
переплавить те крупицы, которые были собраны нами ранее, в один
красивый, сияющий солнцем слиток.
Вопрос оформления собранных требований всегда стоит перед
начинающими аналитиками. Как передать в документе те знания, ко­
торые получены в ходе сбора требований? При этом важны и стиль,
и форма изложения текста требований. Также важна глубина про­
работки требований. Поначалу достаточно трудно определить, где
же остановиться в описании деталей. Через некоторое время по­
являются другие проблемы: как сделать документ понятным и ло­
гически связанным, чтобы при его чтении у людей, для которых он
предназначен, не возникало желания отложить его чтение на потом?
Начинающие аналитики обычно ориентируются на своих более опыт­
ных коллег в этих вопросах, они копируют стиль, форму и глубину
проработки. Однако копирование стиля старших товарищей не всег­
да приводит к хорошему результату.
Наиболее стабильны в этом плане компании, где заказчики и раз­
работчики работают в рамках одной организации и не меняются
часто (продуктовые компании, in-house разработка, долгие проек­
ты). В этом случае аналитики имеют возможность выработать такой
стиль работы, который позволяет им при минимальных затратах
добиться максимальной эффективности при передаче информации
от заказчика к разработчикам. Этот стиль формируется и эволюци-
онно развивается вместе с компанией и ее культурой. Копирование
стиля — наиболее простой и эффективный способ для начинающих
аналитиков. Единообразие стиля, формы изложения и глубины про­
работки требований помогают не только выполнить текущую задачу,
но и облегчить себе и коллегам решение последующих задач.
В заказных проектах, когда проектная команда формируется под
заказчика, у аналитика возникает гораздо больше трудностей в этих
вопросах, поскольку ему приходиться каждый раз подстраивать свои
методы работы под нового заказчика и команду разработчиков.
В каждом новом проекте ему необходимо написать такой документ,
который будет не только прочитан, но и понят. В этой ситуации
простое копирование стиля написания документа, глубины прора­
ботки деталей с другого проекта может не принести ожидаемого
результата.
С другой стороны, в процессе работы над требованиями очень
важно, чтобы у аналитика и руководителя проекта была свобода
92 Глава 3. Работа с собранными требованиями
шшшшишпшшшшмшнншшшшшишшщмшшишнтшшпшшшшшшпижшпшшншпннншишпшшпмм

по выделению части требований по определенным критериям, раз­

деления документа на части и т.п. Это необходимо для анализа
требований и при формировании рамок проекта или разделения
проекта на фазы. Таким образом, аналитик должен написать такие
требования, которые были бы удобны как для чтения от начала до
конца, так и для работы с ними как с набором объектов, имеющих
определенный перечень атрибутов (т.е. требования как таблица).
Эти два критерия — удобство для чтения и удобство работы
с требованиями как с набором — нередко вступают в противо­
речие.
Таким образом, работа аналитика при формализации собранных
требований состоит не только в том, чтобы зафиксировать собран­
ную информацию, но и при этом соблюсти баланс между подроб­
ностью и лаконичностью, между удобством для чтения и удобством
для работы с требованиями как с таблицей.

Аналитик на данном этапе уже знает, какую проблему нужно

решать, теперь нужно определить: в какой форме и где писать
требования Это может быть специальная система управления
требованиями, или это может быть просто документ формата
MS Word, или это таблица в MS Excel? Какой формат и какую си­
стему лучше применять? «Серебряной пули» увы, не существует.
Если в компании уже принят какой-то формат или шаблон либо
используется какая-то система или все сразу, то начинающему
аналитику стоит принять правила игры и помнить, что при любых
шаблонах, форматах и системах он может сделать свою работу
хорошо или не очень.

С чего начинается хороший документ

Любой хороший документ начинается с введения. Введение — это
не просто страничка из шаблона, которую туда вставили методологи
для красоты и увеличения объема документа.
Пропускать введение и начинать писать требования — это боль­
шая ошибка.
Во введении должна быть изложена основная суть, которую так
же можно условно свести к одному вопросу: ЗАЧЕМ? Т.е. аналитик
письменно должен ответить на вопрос, зачем он пишет этот доку­
мент. Однако давайте немного раскроем этот вопрос.
Во-первых, действительно стоит написать, для чего нужен этот
документ.
С чего начинается хороший документ 93
u iu tiin iiiiiiiiiK iiiD iiiiiiiiiifiiiiiiiitiiiiiiiiiiiiiiiiiiiiiim iiiiiiiiiiiiiiiiiiiiiu iiiiH iiiiiiiK iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiit iiiiii

Например, аналитик разрабатывает требования, которые яв­

ляются основой для поведения тендера по выбору поставщика
решения. Или аналитик разрабатывает детальные системные
требования, которые будут служить основой для разработки
системы.

Краткую формулировку цели написания документа можно также

дополнить следующими важными деталями:

• целевая аудитория:
• область применения;
• контекст;
• рамки;

К сожалению, я неоднократно встречался с ситуацией, когда

аналитик, формулируя цель документа, совершенно не задумывался
о том, может ли она быть достигнута этим документом.

Например, аналитик пишет подробные требования, относя­

щиеся к области решения, включая в них мелкие детали реа­
лизации, технологические и архитектурные аспекты проектиро­
вания, но при этом пишет, что этотдокумент предназначен для
согласования с заинтересованными сторонами. В случае если
на стороне заказчика нет представителей заинтересованных
сторон, обладающих необходимыми знаниями, квалификаци­
ей, да наконец временем, чтобы прочитать этот документ, то
мы получим проблему. Заказчик не будет читать документ, или
будет затягивать согласование, или подпишет, но потом пойдут
запросы на изменения и т.п. Поэтому аналитик должен всегда
задавать себе вопрос: а сможет ли целевая аудитория прочитать
и понять документ? Будет ли согласование осмысленным или
этотдокумент будет подписан «не глядя»?
Я с некоторых пор начал обращать внимание аналитиков,
работающих со мной на проектах по разработке ПО, на эту про­
блему. Для того чтобы аналитик лучше себе представлял, для
кого он пишет документ, я просил писать в разделе «Целевая ау­
дитория» конкретные имена и фамилии людей, для которых этот
документ предназначен. Кроме этого, я просил также писать, что
аналитик от этих людей ожидает, какую роль относительно этого
документа люди из целевой аудитории играют.
94 Глава 3. Работа с собранными требованиями

В некоторых шаблонах цель, область применения, целевая ауди­

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

• Информация об источниках требований:

• описание заинтересованных сторон и сведения о том, кто яв­
ляется представителем каждой из заинтересованных сторон;
• ссылки на документы, которые являются источниками требований;
• перечень систем, которые являются источниками требований.
• Термины, аббревиатуры и сокращения, используемые в доку­
менте. Этот раздел должен содержать определения терминов
и расшифровки аббревиатур и сокращений. Если аналитики для
проекта поддерживают отдельный словарь с терминами, аббре­
виатурами и сокращениями, то стоит просто на него сослаться.
• Ссылки на другие документы. Это могут быть требования более
высокого уровня, паспорт проекта, модели и другая проектная доку­
ментация, которая может помочь целевой аудитории лучше понять
документ. Стоит обратить внимание, что просто вставлять ссылки
на документы можно, только если целевой аудитории абсолютно
понятно назначение и содержание документов из их названий.
В противном случае необходимо подробно описать, для чего вы
приводите ссылку на тот или иной документ в начале документа
с требованиями. Стоит также отметить, что не стоит давать ссылки
на документы, которые недоступны целевой аудитории, документы,
которые находятся в разработке и постоянно меняются, ссылки на
папки с проектной документации без указания конкретных полез­
ных документов и т.п. В этом разделе должны быть только нужные
ссылки, которые помогают читателю, а не наоборот.

В начале документа также полезно иметь раздел «История из­

менений». Этот раздел обычно начинает заполняться после того как
готов первый черновой вариант, и требования начинают обсуждаться
внутри проектной команды, а затем и с представителями заказчика/
поставщика.
Структура требований 95
I H I I I I I I I I I I I I I I I I I I I I i ll llll llll llll lll lllt i llll llll lll llll llll lll llH I I I I I I I I I I I I I I I M H M I I I I I I I I I I I I I I I I I I I I I I t lll lli M i n i H I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I H

Структура требований
Требования собираются из различных источников. В процессе
работы с источниками аналитик получает достаточно много дубли­
рующих требований (повторов) и противоречий. Если требования
записываются в том порядке, в котором они собираются, то вели­
ка вероятность того, что требования, связанные между собой по
смыслу, будут находиться в разных местах документа. В случае
если документ умещается на одну страницу, это, полагаю, не будет
представлять особой трудности. Однако если документ достаточно
объемный, то его содержимое должно быть как-то организовано.

На эту тему есть симпатичный детский стишок: «Петя рос,

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

Аналитик должен начинать думать над структурой документа

с требованиями с самого начала. За основу структуры документа
с требованиями рекомендуется взять одну из моделей.
Если документ предназначен для согласования с клиентами, сре­
ди которых есть и будущие пользователи системы, то требования
в документе должны быть организованны именно в том порядке,
в котором пользователи привыкли выполнять описываемые в тре­
бованиях действия на работе. В этом случае за основу структуры
требований можно взять диаграммы, описывающие работу пользо­
вателей, например, диаграммы вариантов использования (use-case
diagrams), или сценарии использования (Use Scenarios), или диа­
граммы потоков данных (DFD diagrams).
Например, для определения структуры требований можно взять
диаграмму взаимодействия. При этом нужно учитывать то, что на­
верняка ни одна из разработанных моделей не описывает полностью
разрабатываемую систему или моделируемый производственный
процесс. Следовательно, аналитику необходимо дополнить структу­
ру требований разделами, которые будут посвящены требованиям,
не попавшим в модель, взятую за основу структуры документа.

Поскольку наш пример достаточно простой и диаграмма не­

сложна, то и структура требований также будет простой:
96 Глава 3. Работа с собранными требованиями
n i i i i i M i i i i i i i i i i i i i i i i i i i i i m i i i i M i i i H i i i i i i i i i i i i i i i i M i i i n i i i i u i i i i 'i i i i i i i i i i i i i n i i i i i i i i i i i M i i i i i i i i i i i i i i i i i i i i i i i i i i i i i n i i i i i i i i i i m i i i i i i i i i i i i ,

1. Работа с обращением
1.1. Поступление обращения (возможно. будут требования по
автоматическому предзаполнению формы обращения)
1.2. Регистрация обращения
1.3. Эскалация обращения
1.4. Закрытие обращения
2. Отчетность
2.1. Отчет...
2.2. Отчет...
2.3. ...
3. ...

Структура требований — это «скелет», на который аналитик «нара­

щивает мускулатуру», заполняя разделы. Но любой аналитик должен
помнить, что если он на каком-то этапе обнаруживает, что структура
начинает его не удовлетворять, то он должен эту структуру улучшить.
Структура документа, так же как и требования, которые помещаются
в эту структуру, это не нечто фундаментальное и неизменное — они
должны совершенствоваться в процессе работы.
Используя структуру, аналитик помещает требования, относящие­
ся к одному предмету (функции, объекту и т.п.) в одном месте: это
позволяет ему легче находить повторы, пробелы и противоречия,
а следовательно, быстрее и проще улучшать документ.
Хорошая структура еще больше помогает при дальнейшей рабо­
те с документом как проверяющим и согласующим, так и людям,
которые дальше пользуются этим документом для проектирования,
разработки и тестирования: архитекторам, разработчикам, тести­
ровщикам. Хорошая структура также помогает руководителю оце­
нить (хотя бы приблизительно) прогресс выполнения работы на
этапе сбора требований.
Тем не менее стоит предостеречь начинающих аналитиков от
чрезмерного увлечения структурой. Случается, что количество раз­
делов начинает доходить до половины количества самих требований,
а уровни заголовков достигать семи или более. С определенного
момента чрезмерная структурированность требований начинает толь­
ко мешать. Еще больше проблем вызывает выделение некоторых
общих аспектов поведения системы в отдельные разделы с после­
дующими ссылками на эти разделы из всего документа.

Мне как-то прислали документ на согласование, содержащий

примерно 90 страниц, при этом первые 40 страниц пестрели
Текст требований 97
iiiiiiiiiiiiiiiiiitiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiH iiiiiiiiiiiiiiiiiiiin iiiiitiiiin iiiiiiiiiiiiitiiM iiiiiiiiiM iiiiifiiiiiiiiiiiiiiiiu iiiiiiiM iiiiiiiiiiiii

ссылками на последующие 50. Автор документа решил, что нет

необходимости описывать, что будет, если пользователь нажмет
на кнопку <’Ок» или «Отмена» на каждой из форм, и т.п. общие
сценарии поведения системы, а сделал отдельный раздел, опи­
сывающий поведение элементов пользовательского интерфей­
са. Оказалось, что этот «общий» раздел немного превысил все
остальное. Согласовать этотдокумент стоило больших усилий,
поскольку читать его было очень сложно. Помимо текста раз­
делов пришлось проверить все ссылки. Было найдено большое
количество ошибок именно технического характера, как то: не­
правильные ссылки, копирование разделов без изменения вну­
треннего содержания и т.п. И даже проверка внутри команды
компании-разработчика не смогла предотвратить эти проблемы.

Структурированность документа — это инструмент, хорошая струк­

тура помогает, плохая — наоборот.

Текст требований
Существует несколько подходов написания текста требований.
В первую очередь это классический подход [2]. Также можно вы­
делить сценарии, в том числе Варианты Использования (также из­
вестные как Прецеденты) [1,3], и пользовательские истории, при­
меняемые в гибких методах разработки ПО [4,7].

В любом из этих подходов суть остается неизменной: требова­

ние описывает значимый результат, который достигается в опре-
деленных условиях с определенными д а р а м е та ш п р ^ и ^ в щ ^
тельности.

Различия этих подходов состоят только в стиле изложения тре­

бований. Начинающему аналитику, повторюсь, придется в основном
ориентироваться на культуру организации, в которой он работает,
и следовать по стопам более опытных коллег.
Рассмотрим классический подход. Для примера приведем не­
сколько шаблонов и требований, написанных с их использованием.
Пример шаблона для требования из области проблем (возможность):

<Роль> должен иметь возможность <возможность> с(в) П о ­

казатель производительности> с <момент отсчета>, находясь
в <условия эксплуатации:».
98 Глава 3. Работа с собранными требованиями
lllllllllllllllllllllltlttllllllllllllllK lllllllllllllllllIllllllllIilltlfllllltlllllltlllH IIIIIIIllIllllllllllllllltlllU tlllllllllllllltllllltllllliiiiiitiii,,

Пример шаблона для ограничений из области проблем:

<Роль> должен быть ограничен в <возможность>, находясь

в <условия эксплуатации>.

Пример шаблона для требований из области решений (возмож­

ность):

<Система> должна выполняемая функция> не менее чем (с)

<количество> <объект>, функционируя в <условия эксплуата-
ции>.

<Система> должна предоставлять <Роль> возможность <вы-

полняемая функция> не менее чем (с) <количество> <объект>,
функционируя в <условия эксплуатации>.

Пример требования из области проблем

Роль Оператор колл-центра...

Цель/возможность/функ­ ...должен иметь возможность по­

ция лучить...

Объект ...информацию о позвонившем

клиенте...

Параметры/критерии про­ ...в течение 5 секунд после фор­

изводительности мирования запроса...

Другие условия если поиск осуществляется

с использованием номера до­
говора.

Пример ограничения из области проблем

Роль Продавцу...
Цель/возможность/функ­ ...должен быть запрещен доступ
ция
Объект ...к информации о доверенностях
представителей контрагентов.
Текст требований 99
|| 1Ш Ш Ш 1Ш И Ш 1Ш Ш 1М Ш 11Н 1Ш 1 М 111 111Ш Н Н 11 Н 11Ж 11 1Ш 1 1Ш 1 11Ш 1|1Ш Ш 1Ш 111М Н Ш И 1Ш Ш 1Ш Ш Ш 1Ш 1Ш Ш Ш 11Ш М Ш 11 М 1| 1Ш | |1

Пример требования из области решений

Система Система учета заявок...
...должна предоставлять возмож­
ность...
Роль ... Специалисту СП...
Цель/возможность/функ­ ...выполнять текстовый поиск...
ция
Объект ...по базе обращений пользова­
телей...
Параметры/критерии про­ ...возвращая результаты поиска
изводительности за не более чем 7 секунд после
формирования запроса...
Другие условия ...если в строке поиска введено
одно слово.

Пример ограничения из области решений

Система Система учета заявок...
...должна запрещать...
Роль ...специалисту СП...
Цель/возможность/функ­ ...редактировать...
ция
Объект ...открытое обращение пользо­
вателя...
Другие условия ...если обращение передано на
вторую линию поддержки.

Дополнительно стоит отметить, что текст одного требования дол­

жен содержать только одно требование. Если вы обнаружили, что
в тексте требования больше одного значимого результата, то такое
требование рекомендуется разделить на несколько. Это позволяет
в дальнейшем при работе с требованиями сократить затраты на
исправления, согласования и т.п. Чем меньше взаимных влияний
в тексте требований, тем легче с таким документом работать. Заме­
тить, что в одном требовании на самом деле содержится несколько,
можно по наличию союза «и», запятым и спискам.
Если требования описывают структуры данных, то каждый эле­
мент структуры формально можно считать отдельным требованием.
100 Глава 3. Работа с собранными требованиями
М 11Ш 1Ш 11Ш 11Ш !111Ш 1Ш 1|т Н 1Ш 11111Ш |Ш 11Ш 1М 1||Ш 1Ш Ш |111Ш 11Ш 11111Ш Н 11Ш Ш 11Ш 1Ш Ш 11Ш 111||1!1Ш 11|||11Ш 1|Ш 1Ш 1М |1М 1||

Например:

2.1. Обращение должно содержать следующие атрибуты:

• ФИО обратившегося
• Департамент обратившегося
• Дата и время регистрации обращения
• Система
• Суть (текст) обращения

В этом примере мы видим один из возможных вариантов

более простой для восприятия формы записи требований. При
этом надо учитывать, что каждый элемент списка параметров
обращения — это отдельное требование, и мы могли бы запи­
сать их в более формальном виде:

2.1. Поля формы обращения (это заголовок структуры,

а не требование).
2.1.1. Обращение должно содержать ФИО обратившегося.
2.1.2. Обращение должно содержать департамент обратив­
шегося.
2.1.3. Обращение должно содержать дату и время регистра­
ции обращения.
2.1.4. Обращение должно содержать систему.
2.1.5. Обращение должно содержать суть (текст) обращения.

Любой из этих двух вариантов допустим. Первый, по моим

наблюдениям, встречается чаще. Хотя мы также использовали
табличную форму записи требований, относящихся к структурам
данных, дополняя атрибуты сущности описанием их форматов
и вводя признак обязательности.

2.1. Обращение
Атрибуты:
№ Наименование Формат Обязательный
2.1.1. ФИО обратившегося Текст (ссылка Да
на список со­
трудников)
Текст требований 101
tllllllllllllllllllllllllK lllllllllllllllllllllllllllllllllIllllllilllllllllllllllilllllllllllllllllllilllllllllllllllllllllllllltllllllllilllllllllllllltltllllll

2.1.2. Департамент обра­ Текст (ссылка Да

тившегося на список де­
партаментов)
2.1.3. Дата и время реги­ Дата и время Да
страции обращения
2.1.4. Система
Текст (ссылка Да
на список си­
стем)
2.1.5. Суть (текст) обращения Текст Да
2.1.6.

Каким еще критериям должно удовлетворять требование, кроме

того что оно должно описывать значимый результат (значимый для
одной из заинтересованных сюрон), получаемый в определенных ус­
ловиях, с определенными параметрами производительности? Требова­
ние должно быть четким, ясным, понятным и лаконичным. Очевидно,
что это достаточно общие и неконкретные критерии, чтобы ими легко
воспользоваться, особенно начинающему аналитику. В чем же суть
этих критериев? Давайте вернемся немного назад и вспомним, что я
рекомендовал помещать в начале документа. Любой документ имеет
целевую аудиторию, т.е. людей, для которых он написан. Очень часто
аналитики жалуются, что представители заказчика не читают их доку­
менты. Возможно, это происходит потому, что документ написан не для
них, он им непонятен. Поэтому критерии четкости, ясности, понятности
и лаконичности можно использовать только применительно к конкретной
целевой аудитории. Аналитик должен прилагать усилия к тому, чтобы
сделать документ, с одной стороны, максимально понятным тем, кто
с ним будет работать, с другой — сделать его максимально лаконичным
и четким, чтобы у людей не пропало желание его читать при одном
взгляде на количество страниц. В попытке сделать документ ясным
и понятным для целевой аудитории аналитик может опираться целиком
на свои внутренние ощущения и на мнение коллег-аналитиков. Однако
гораздо эффективнее пытаться периодически показывать документ или
отдельные требования тем людям, для которых он предназначен. Это
приносит гораздо больше пользы, чем «экспертный анализ».
Следующий критерий, который можно применить к требованиям
внутри документа, это соответствие уровню документа. Если требова­
ния описывают решение (систему), то появление среди них требова­
ния, которое относится к уровню проблемы (бизнеса), будет не очень
уместно, как и наоборот — появление требования, относящегося
102 Глава 3. Работа с собранными требованиями
1Н1ШШ1М111ШННШН111Ш111111ШМ11Ш|||1И1||П11Ш1111111Ш11МтШШ11ШШШ11Ш1111Ш111И111Ш11|11Ши111Н111ШМ1)ПШШ1Н||||

к системе на уровне описания проблемы. Однако в процессе сбора

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

Для примера реализуемого и проверяемого требования во­

обще, но не реализуемою и не проверяемою в час!ноет, можно
взять требование доступности системы 24x7 (24 часа в день, 7
дней в неделю) с наработкой на отказ в 1 год. Практически такие
системы существуют — например, системы биллинга сотовых опе­
раторов. Но выдвигать такие требования к любой системе нецеле­
сообразно. Ведь реализация этого требования может быть в десят­
ки раз дороже, чем реализация всех остальных ваших требований.

Здесь обычно возникает вопрос: а как же аналитик в процессе

сбора требований может оценить реализуемость и тестопригод-
ность требования? Во-первых, здравый смысл помогает аналитику
отсечь заведомо нереализуемые и нетестопригодные требования,
переформулировать их или договориться о смягчении некоторых
критериев — допустим, доступности или производительности. Ес­
ли требования, выдвигаемые представителями заинтересованных
сторон, не выглядят как абсолютно нереализуемые, то однозначно
дать оценку об их реализуемости могут только разработчики. То же
самое и с тестопригодностью. Аналитик наверняка может ответить
на вопрос, можно ли протестировать требование для большинства
требований, относящихся к области функциональных возможностей
проектируемого решения, и для ряда требований из области требо­
ваний к производительности, доступности и надежности. Однако для
оценки на тестопригодность некоторых требований ему понадобится
обратиться за помощью к специалисту из команды тестирования.
Ну и наконец, требование должно не противоречить применимому
законодательству. Аналитик, работающий с заказчиками, к которым
применяется государственное регулирование, должен хорошо знать
Атрибуты требований 103
1 Ш 1 Ш | Ш Ш 1 И 1 1 11Ш Ш 1 | 1Ш 111Ш Ш Ш Ш Ш Ш 1 11Ш Ш 1М 1111 1Ш 1 Ш 1Ш П Ш 11 Ш 1Ш 111 1Ш 111111 Н Ш 1 11Ш 1Н 111Ш 11 1Ш Н Ш 11 1И 11Ш Ш 1Н 11Ш 1

соответствующую законодательную базу. Во-первых, законодательная

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

Атрибуты требований
Атрибуты требований обычно применяются как дополнительный
инструмент, позволяющий самому аналитику хранить в удобной фор­
ме дополнительную информацию, касающуюся каждого требования.
К таким атрибутам в первую очередь нужно отнести источник требо­
вания. В этот атрибут аналитик может помещать информацию о том,
откуда он это требование получил. В качестве возможных значений
этого атрибута можно себе представить полный перечень предста­
вителей заинтересованных сторон, документов и систем, с которыми
аналитик работает для получения требований.
Другие атрибуты обычно нужны не столько самому аналитику,
сколько всей команде разработки и заказчику.
Такие атрибуты, как «важность», «приоритет» и «сложность реали­
зации», используются для определения рамок проекта и проектных
фаз. Очевидно, что важные и приоритетные требования должны быть
сделаны в первую очередь, независимо от сложности их реализации.
Менее важные и приоритетные требования, имеющие низкую слож­
ность реализации, — кандидаты на то, чтобы быть реализованными
во вторую очередь и т.д.
Для распределения требований по фазам проекта может быть
введен атрибут «фаза», который, очевидно, будет содержать фазу,
в которой запланирована реализация требования.
В ряде случаев для поддержки процесса разработки проектной
документации для требований вводятся атрибуты, которые отобра­
жают статусы требования. Например:

• статус внутренней проверки, который показывает состояние

проверки требования внутри аналитической команды;
• статус согласования, который показывает, согласовано ли каждое
из требований. Причем статусов может быть два: статус согла­
сования с заказчиком и статус согласования с разработчиками;
• статус тестирования, который показывает наличие разработанных
и согласованных сценариев тестирования для каждого требования.
• статус удовлетворения, который показывает наличие разрабо­
танных и согласованных требований более низкого уровня.
104 Глава 3. Работа с собранными требованиями
iiiiiiiiiiiiiiiiiiiiin iiiitiiiH iin iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiin iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

Названия этих статусов в частности и атрибутов вообще достаточно

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

Ключевые требования
В оригинальной редакции этот термин звучит как «ключевые
пользовательские требования» (Key User Requirements). Я считаю,
что слово «пользовательские» тут не очень уместно. Что же такое
ключевые требования? Ключевые требования — это минимально
необходимый, но в то же время достаточный набор требований
для того, чтобы описать ту систему (решение), которая может быть
внедрена в промышленную эксплуатацию. Т.е. если из этого набора
требований удалить хотя бы одно требование, система, реализующая
этот набор, уже не может быть внедрена в промышленную эксплу­
атацию. Она будет бесполезна для заказчика.
Практическая ценность этой концепции очень проста: реализуя только
минимальный набор необходимых требований, мы существенным об­
разом снижаем проектные риски. Особенно это важно, когда команда
разработки и заказчик еще не имеют опыта совместной работы. Такой
подход позволяет им с минимальными затратами получить что-то, что
может быть полезно и реально применено для целей автоматизации
деятельности заказчика, в отличие от подхода с пилотами и большими
прототипами, когда заказчик зачастую, по сути, инвестирует в потенци­
альную совместную работу, не получая никакой практической пользы.
Ключевые критерии производительности 105
IIIIIIIIIIIIIIIIIIIIIM tlllllllllllllllllllllllllllllllU llllilllilillllllllltlltlllillllllllllllllllllllllliilllllilllllllllllllllllllillllllllllllllllllllllllill

К сожалению, вопросом определения ключевых требований редко

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

Ключевые критерии производительности

Другая концепция очень мало распространена в области раз­
работки требований — это ключевые критерии (или показатели)
производительности. Этот термин известен всем. В оригинале это
KPIs — Key Performance Indicators. Но смысл этого термина с точки
зрения применения его в области разработки требований нуждается
в уточнении.
По аналогии с ключевыми требованиями ключевые критерии про­
изводительности определяют значения параметров производитель­
ности системы, без достижения которых система не будет полезна
заказчику, а следовательно, не может быть принята в промышленную
эксплуатацию.

Стоит сразу пояснить, почему этому вопросу я уделил вни­

мание. Неоднократно я видел ситуации, когда критерий произ­
водительности записывался в таком виде:

21.1. Система должна сохранять информацию, введен­

ную на любой форме не более чем за 2 с.

Или:

21.2. Система должна возвращать результаты поиска

не более чем за 5 с.
106 Глава 3. Работа с собранными требованиями
1 11 Н 1 Ш Ш Ш 1 1 1 Ш М 1 1 Ш 1 1 1 Ш 1 1 1 1 Ш 1 1 | | 1 П !1 1 Ш ! Ш 1 Ш Ш Ш 1 | 1 1 Ш Ш 1 1 Ш 1 1 1 1 1 Ш 1 1 ! | | 1 | | ! 1 1 !1 1 1 1 1 1 1 1 Ш Ш 1 1 1 1 1 1 1 1 Щ | Ш 1 [ | 1 1 1 1 1 1 Ш 1 | 1 1 !Ш Ш Ш | | Ш

В принципе нормальные критерии производительности. Од­

нако что же может произойти, если вдруг в конце проекта об­
наружится, что система не удовлетворяет одному из них? Во-
первых, почему в конце? Во-вторых, что же происходит?
В конце, потому что параметры производительности обычно
проверяются, когда разработан и проверен весь перечень функци­
ональных требований. А происходит следующее: недостатки в про­
изводительности системы обычно кроются на низком уровне, как
разработчики говорят — «в ядре». И начинаются правки кода систе­
мы, которые нередко приводят к появлению проблем с работаю­
щими и уже оттестированными функциональными возможностями.
Если выражаться на сленге разработчиков: «Мы начали тюнить
пеформас, и это привело к коре рефакторингу, из-за чего поехал
функционал». Т.е. пытались добиться соответствия параметрам
производительности, а в итоге сломали систему, и это, я напомню,
в конце проекта. Команда попадает в цейтнот, все начинают рабо­
тать сверхурочно, теряется внимание, и в конце концов, команда
может подойти к дате сдачи проекта с нерабочей системой.

Как же может аналитик помочь свой команде в ситуации, когда си­

стема на поздних этапах не удовлетворяет критериям производитель­
ности? Во-первых, аналитик должен попытаться определить вместе
с заинтересованными сторонами, какие критерии производительности
являются действительно ключевыми, и без их достижения система
не может быть внедрена в промышленную эксплуатацию. Во-вторых,
аналитик на этапе сбора требований должен понять функцию каждого
критерия производительности, особенно это важно для ключевых.
На Рис. 8 показано четыре функции показателей производитель­
ности. К сожалению, аналитики обычно ограничиваются первой функ­
цией, т.е. фиксируют определенную величину. На самом деле это
достаточно редкий случай.
Разберем пример на графике «а». Заказчику нужно, чтобы си­
стема поддерживала 100 одновременно работающих пользователей.
Это значит, что у него есть 100 реальных пользователей и меньше
быть не может, а больше в обозримом будущем не планируется.
Графики «б» и «с» отражают более распространенные случаи. Для
большинства web-решений нагрузка носит вероятностный характер,
а это значит, что требование о том, что система должна поддерживать
200 одновременно работающих с системой пользователей, скорее
всего также носит характер прогноза. Более того, для новых сайтов
количество одновременно работающих пользователей в начале рабо­
Ключевые критерии производительности 107

ты в режиме промышленной эксплуатации может быть значительно

меньше. Следовательно, если команда сталкивается с проблемами при
удовлетворении этого критерия производительности, возможно, стоит
не пытаться решить эти проблемы за оставшиеся несколько дней до
окончания проекта, а договориться с заказчиком о приемке системы
с более низким значением этого показателя, при условии, что команда
потом доработает систему и поставит ее заказчику еще раз позднее.
Это тем более имеет смысл, когда запланировано несколько поста­
вок (проектных фаз), соответственно и производительность системы
может наращиваться постепенно. Как видно на графике «б», удовлет­
воренность заказчика при достижении значения 100 одновременно
работающих с системой пользователей будет равной приблизительно
70 %. Я полагаю, что в такой ситуации заказчик скорее всего пойдет
навстречу команде разработчиков и предпочтет в срок получить рабо­
тающую систему с более низким значением критерия производитель­
ности, чем согласиться переносить сроки внедрения.

а) определенная величина б) иэхеиииэация

tC орем» «*»поп>-ет!#г

с) минимизация д) оптимизаикя

Рис. 8. Функции значения показателя производительности.

На графике «с» отражена аналогичная ситуация, с той лишь раз­

ницей. что в данном случае заказчик заинтересован в минимизации
значения критерия производительности. Например, время выполне­
ния системой поискового запроса не должно превышать 3 с. При
этом, как следует из графика, достижение системой значения этого
показателя, равного 5 с, дает около 90 % удовлетворенности заказ­
108 Глава 3. Работа с собранными требованиями
tiiiiu iiiiiiiiiiiiin iiiiiis iittis tiiiittiiiiiiiiM iiiiiitiik iitiiJiiiiiiiiiiiiiiiiiiliiittiiiiiim iiiiiitiiin iiiiiifiiiiiitiiiiiiiiiiiiiiitiiiiiiiiiiiiiiiiiiii

чика, и даже 7 с дают около 70 %. Следовательно, как показывает

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

Заключение
В заключение этого раздела давайте суммируем рекомендации
по документированию требований:

• Определите структуру требований и постоянно улучшайте ее

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

Основные рекомендации для написания текста требований:

• Используйте простой прямой язык.

• Пишите требования, которые можно реализовать и проверить.
• Используйте определенную и согласованную терминологию.
• В одном требовании пишите только одно требование.
Важность проверок 109

Глава 4. Проверка требований

Важность проверок
Важность проверок трудно переоценить. Ведь чем раньше вы
нашли ошибку, тем дешевле ее исправить. Опубликованы раз­
личные исследования на тему того, сколько может в среднем
стоить исправление ошибки, допущенной на этапе сбора тре­
бований, если она обнаружена и исправлена на разных этапах
жизненного цикла ПО. Все авторы сходятся в том, что стоимость
исправления ошибки, обнаруженной в требованиях на этапе сбо­
ра требований, на два порядка ниже, чем стоимость исправ­
ления той же ошибки, но найденной в период промышленной
эксплуатации системы (см. Рис. 9). Трудно не согласиться с по­
добными результатами. Если вы нашли ошибку в требованиях
в процессе работы над ними, то для ее исправления вам до­
статочно лишь исправить документ и, возможно, согласовать эти
исправления с заинтересованными сторонами. Если же ошибка
в требованиях находится на этапе проектирования, то приходит­
ся менять не один документ. В зависимости от ошибки в та­
кой ситуации могут быть самые разные варианты — от космети­
ческих изменений в пользовательском интерфейсе системы до

Рис. 9. Стоимость исправления ошибки [7]

1 1 0 Глава 4. Проверка требований
H lllflllflllllin iltlH llllllllllllllllllllltllllllllllfllllllllllltllllltlllM llllllllfH llllllllltltlllllllllllllfllllllllllllltlH llllllllllllilllllllliiiiiiiii

пересмотра архитектурных концепций. Однако все еще не так плохо,

ибо еще не начата работа по разработке кода. Когда ошибка в тре­
бованиях находится на этапе разработки кода системы, то в этой
ситуации последствия для проекта могут быть гораздо серьезнее
и т.д. Очевидно, что самые большие расходы на исправление ошиб­
ки, допущенной при сборе требований, будут тогда, когда система
уже находится в промышленной эксплуатации. Ведь исправление
ошибки нужно будет делать не только во всех документах и коде
системы — вам придется еще и делать исправление (патч) в работа­
ющей системе, что само по себе сопряжено с большими затратами
и рисками.

Виды проверок
Относительно классификации видов проверок многие источники
расходятся. Единственное, в чем они сходятся, так это в том, что
единой классификации проверок нет. Поэтому условно можно раз­
делить проверки на формальные и неформальные.
Основное отличие формальных и неформальных проверок состо­
ит не в том, что для формальных проверок существуют описанные
четкие процедуры проведения проверок проектной документации
и кода, ведь они есть и для неформальных проверок. Основное от­
личие состоит в том, что существуют формальные количественные
критерии отклонения документа или кода. Если документ или код
не проходит проверку на соответствие этим критериям, его пере­
писывают заново. Т.е. исправлять документ или код, не прошедший
проверку на соответствие заданным критериям, запрещено.

Например, формальная процедура проверки может предус­

матривать процесс, когда автор документа посылает его ру­
ководителю, тот назначает двух проверяющих и посылает им
документ на проверку. После проверки руководителю направля­
ются замечания. Руководитель анализирует замечания и делает
вывод о том, исправлять этотдокумент или переписывать. Для
чего может быть применено в качестве критерия прохождения
проверки отношение одинаковых замечаний к общему количе­
ству замечаний проверяющих. Допустим, что оба проверяющих
нашли по 10 ошибок (замечаний). 8 из них одинаковые. Таким
образом, всего было получено 12 замечаний. Считаем значение
критерия прохождения проверки:
Неформальные проверки коллегами (Peer Review) -j ■) -j
НШ ППИШ Ш И И ...................... I I I I I I I I I I I I l l l l l l l l l l l l l l .................. I l l t l l l l l l l l l .I l l l l l l l l l l l ................... H l l l l l l l l l l l l l ........... .....

8/12 = 0,67
Если оба проверяющих нашли по 10 ошибок, но только 2 из
них одинаковые, то мы имеем:
2/18 = 0,11
Допустим, что значение коэффициента проходимости про­
верки равно 0,5. Тогда в первом случае руководитель просит
автора документа исправить 12 найденных ошибок, и после
проверки исправления ошибок документ можно использовать.
А во втором случае документ придется переписывать заново,
поскольку существует большая вероятность того, что в доку­
менте осталось еще очень много ошибок, не найденных про­
веряющими.

Тщательность проверок и жесткость критериев прохождения про­

верки обычно зависит от сути проекта. Чем больше риски, связан­
ные с выявлением ошибок на более поздних этапах проекта, тем
больше усилий вы будете вынуждены затрачивать на проверки,
и тем более жесткие критерии их прохождения вы будете исполь­
зовать.
Самые тщательные и долгие проверки, несомненно, проводят­
ся на проектах по разработке систем, от работы которых зависят
жизнь и здоровье человека. Это системы, которые применяют­
ся в медицине, атомной и оборонной промышленности, а также
в других отраслях экономики, где от работы системы зависят
жизнь и здоровье людей (например, химическая промышленность,
металлургия, и т.д.).
Следом за риском для жизни и здоровью людей идут, несомнен­
но, финансовые риски. Если потенциальная угроза потери большой
суммы денег высока, то и проверки должны быть более тщатель­
ными.

Неформальные проверки коллегами (Peer Review)

Неформальные проверки, как я уже писал, это не те проверки,
где нет описанной процедуры, а те, где нет четких критериев про­
хождения или непрохождения проверки. На большинстве совре­
менных проектов по разработке ПО в формальных критериях нет
необходимости, поскольку невелики риски причинения вреда жизни
и здоровью людей, а также риски больших финансовых потерь из-
за ошибок, допущенных при разработке проектной документации
и кода системы.
112 Глава 4. Проверка требований

Можно выделить следующие основные виды проверок требований:

• Проверка представителями заинтересованных сторон. Эта про­

цедура обычно носит название «согласование» и применяется
практически на любом проекте.
• Проверка разработчиками и тестировщиками. Такие проверки
обычно происходят походу использования документа. В процессе
работы с документом разработчики и тестировщики (а также ар­
хитекторы, ведущие разработчики, ведущие тестировщики и дру­
гие люди из области разработки и тестирования вне зависимости
от названия их ролей и должностей) находят ошибки и делают
замечания автору документа — аналитику. В ряде компаний су­
ществует специальная процедура или обязательный этап про­
екта — приемка требований разработчиками и тестировщиками.
• Проверка коллегами аналитиками, или Peer Review. Это спе­
циально спланированные проверки, целью которых является
улучшения качества документа до того, как он попадет к пред­
ставителям заказчика, разработчикам и тестировщикам.

Стоит отметить, что проверки коллегами аналитиками результатов

работы своих коллег — это, пожалуй, наиболее простой и эффектив­
ный метод улучшения процессов в любой аналитической команде,
состоящей из двух и более аналитиков. В результате введения этой
процедуры как обязательной вы получите не только улучшение ка­
чества документов (в отношении уменьшения ошибок), но и другие
положительные изменения:

• в процессе проверки идет обмен знаниями о предметной об­

ласти между аналитиками, повышается взаимозаменяемость
аналитиков в команде;
• в процессе проверок аналитики учатся друг у друга использова­
нию профессиональных приемов, методов моделирования и т.п.;
• в результате проверок у аналитиков в команде выравнивается
стиль, документы разных авторов начинают становиться более
похожими друг на друга, что облегчает работу с ними пред­
ставителям заинтересованных сторон, разработчикам и тести­
ровщикам.

Однако не стоит забывать о том, что хотя этот метод и относится

к неформальным, тем не менее он должен быть описан и грамотно
применен.
Неформальные проверки коллегами (Peer Review) 113
lllfllllllllllllllillilllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllliriiillllllllllllllllflllllllllllM M IIII

Первое, что потребуется для введения проверок в вашу практи­

ку, это согласие со стороны руководства на выделение времени на
проверки. Далее вам необходимо разработать регламент проведения
проверок: на каком этапе будут назначаться проверяющие, когда им
будет поступать документ на проверку, сколько времени на проверку
будет отводиться и т.д.
Следует обратить особое внимание на разработку правил вы­
полнения проверок.
Аналитик, который посылает документ на проверку, должен убе­
диться в том, что документ полностью готов, — как минимум про­
верить его самостоятельно перед отправкой. Отправка сырого до­
кумента, содержащего орфографические ошибки, может быть вос­
принята проверяющим как проявление неуважения к его времени
и труду.
Со своей стороны проверяющий должен формулировать свои за­
мечания только в виде предложений по изменению формулировок
требований, или предложений по добавлению новых требований,
или предложений по удалению противоречивых или дублирующих
требований. Личные комментарии, качественные оценки работы кол­
леги и неформальный тон замечаний могут привести к негативным
последствиям.

Стоит уделять больше внимания подготовке к началу вве­

дения процедур проверки аналитиками работы коллег. Как ни
странно, даже аналитики, которые отлично работают и с бизне­
сом, и с разработчиками, и с тестировщиками, и с поддержкой,
порой не могут работать друг с другом. У меня в команде были
тяжелые случаи, когда аналитики наотрез отказывались работать
друг с другом в рамках проверок. Были случаи, когда это не ра­
ботало, потому что аналитику было «некогда» смотреть на то,
что сделал другой, и он осуществлял проверку «по диагонали»,
или «до третьей ошибки». Были аналитики, которые подходили
к проверке как к игре — «найди больше ошибок» — и выкатыва­
ли огромные списки вопросов и замечаний, вместо того чтобы
вникнуть и понять, почему они получили на проверку документ
такого качества. Были аналитики, которые отправляли на про­
верку очень сырые документы, проверка которых ничего, кроме
раздражения, не вызывала.
114 Глава 4. Проверка требований

Критерии проверки текста требований

Если говорить о том, как, собственно, осуществляется проверка
требований, то, несомненно, стоит привести критерии проверки для
текста каждого требования. Они практически такие же, как и для
написания, поэтому просто перечислим их еще раз для повторения.
Итак, каждое требование должно:

• представлять собой только одно требование, а не несколько;

• описывать значимый результат;
• быть выполнимым;
• быть тестопригодным, т.е. вы должны знать, как проверить, что
оно реализовано;
• быть ясным и точным;
• быть законным;
• соответствовать уровню документа.

Критерии законченного набора требований

Стоит также повторить критерии для проверки законченного на­
бора требований.
Полный набор требований должен:

• иметь ясную и четкую структуру;

• при этом требования, близкие друг к другу по смыслу, должны
содержаться в одном разделе;
• быть полным — все необходимые требования должны быть за­
фиксированы;
• быть непротиворечивым: в нем не должно существовать требо­
ваний, противоречащих друг другу;
• соответствовать критерию отсутствия избыточности: каж­
дое требование должно быть сформулировано только один
раз (не должно быть повторов);
• соответствовать определенному уровню: все требования должны
быть написаны на одном уровне детализации.

Еще немного о проверках

Многим молодым аналитикам почему-то кажется, что они сумеют
написать хороший документ с требованиями с первого раза, по­
этому они относятся к проверкам как к инструменту, который может
Еще немного о проверках
...... иш шишш ш тпт

улучшить результат их работы, но незначительно. При этом они за­

бывают, что процесс проверки занимает достаточно много времени
и, возможно, придется выполнять цикл проверок и исправлений
замечаний не один раз. Конечно, в этой ситуации руководитель
аналитика несет ответственность за правильное планирование, это
его задача — правильно спланировать работу, исходя из реального
опыта его подчиненных, учесть все возможные временные затраты
на проверки и исправления замечаний. Однако любой аналитик дол­
жен понимать, что написать достаточно большой документ и пройти
проверку с первого раза у него вряд ли получится (разумеется,
это не относится к проектам, где проектную документацию никто
не читает).
Умение управлять своим временем — это очень важный навык
аналитика. Не менее важный навык аналитика — это умение кри­
тично относиться к себе и к своей работе. Всегда нужно помнить
о том, что не аналитик является «истиной в последней инстанции»,
а клиент (т.е. заинтересованные стороны, конечно).
Аналитик должен четко осознавать, что циклов проверки будет
как минимум два, а рассчитывать время на три цикла проверки.
 116 Заключение
Ш11Ш1111Ш1М1||1Ш111111||||1П111ШМ||1М1111|Ш1111111ШШ1111!11111ШП1Ш11111Ш111111|1Ш1Ш1Ш1НиШ11111Ш111111111П1Ш11Ш||||н

Заключение
Работа аналитика имеет огромное влияние на успех проекта.
Аналитик может помочь своей команде сделать проект успешным
или, наоборот, привести проект к провалу.
Для того чтобы быть хорошим аналитиком, человек должен об­
ладать многими важными для работы качествами.
Аналитик должен быть непредвзятым — то есть всегда стараться
выполнить свою работу так, чтобы заказчик достиг поставленной
цели и при этом команда разработки работала с минимальными
рисками и минимально возможной неопределенностью. Професси­
ональный аналитик всегда должен знать ответы на главные вопро­
сы: «зачем?», «почему?», «для чего?», чтобы прослеживалась связь
с основной целью проекта, которую ставит заказчик.
Аналитик должен уметь эффективно взаимодействовать со всеми
участниками проекта. Для этого он должен хорошо знать предметную
область и применяемые в разработке технологии. Он должен уметь
работать с разными представителями заказчика, с разработчиками,
с тестировщиками, с руководителями разных уровней и, конечно же,
с коллегами-аналитиками.
Аналитик должен быть командным игроком, понимать, где чья
зона ответственности, помогать своим товарищам, а не отнимать
у них работу.
Аналитик должен уметь излагать свои мысли четко и ясно. Для
этого он всегда должен помнить, для кого он излагает свои мысли,
кому они должны быть понятны.
Аналитик должен уметь воссоздавать структуры и процессы и в сво­
ей голове, и на бумаге (мониторе), для того чтобы убедиться в пра­
вильности исходной информации и принятых проектных решений.
Аналитик должен уметь пользоваться современными методами
моделирования и инструментами для моделирования и управления
требованиями.
Аналитик должен быть аккуратным и пунктуальным.
Аналитик должен быть организованным и мотивированным.
А еще любой аналитик должен помнить, что лучшее — враг
хорошего. Он должен уметь вовремя остановиться, ведь улучшать
любой документ можно до бесконечности. Задача аналитика — сде­
лать достаточно хороший документ, соответствующий той цели, для
которой он создается.
Здоровый перфекционизм и чувство меры — вот что позволит
вам добиться успеха!
Еще немного о проверках 117

Литература

1. Alexander I. F., Stevens R., and Alexander I. Writing Better

Requirements. Massachusetts: Addison Wesley Longman, Inc., 2002.
2. Hull E., Jackson K., Dick J. Requirements Engineering — 2nd ed.
London: Springer, 2005. Перевод на русский язык — Элизабет Халл,
Кен Джексон, Джереми Дик. Разработка и управление требованиями
Второе издание (сетевая публикация).
3. Leffingwell D., Widrig D. Managing software requirements: a use
case approach — 2nd ed. Boston: Addison Wesley, 2003. Перевод
на русский язык первого издания книги — Дин Леффингуэлл, Дон
Уидриг. Принципы работы с требованиями к программному обеспе­
чению. Унифицированный подход. 2002 г., Вильямс.
4. Cockburn A., Agile Software Development: Addison-Wesley
Professional, 2001. Перевод на русский язык — Алистер Коберн.
Быстрая разработка программного обеспечения. 2002 г., Лори.
5. Юрий Булуй. Классификация требований к программному обе­
спечению и ее представление в стандартах и методологиях. Доклад
на конференции SEC-R 2006 (сетевая публикация).
6. Maiden N. Using Creativity Techniques in Requirements Processes:
A Step-by-Step Process. Выступление на конференции Software
People 2011.
7. Кент Бек. Экстремальное программирование. Библиотека про­
граммиста. — СПб: Питер, 2002.