Живые требования – тот еще фрукт. Актуализируем и реализуем, пока не испортились

Юрий Дубровский, 2021

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

ЧАСТЬ I. Почему просто собрать требования мало?

Глава 1. Типовой взгляд на требования в ИТ-проекте

Вместо эпиграфа

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

— Эй, бабка! Побыстрее убегай отсюда! Сейчас в деревню придут враги!

— Да ты что, милок? Война уж тридцать лет как кончилась!

— Вот это да-а! А я все это время поезда пускал под откос?..

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

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

Как это сделать? Об этом и расскажет наша книга.

Требования, как принимаемый на веру набор положений

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

Достоверного и гарантированного способа убедиться, что выполнение требований приведет именно к ожидаемому результату нет. Это обусловлено человеческой природой: разные люди все равно по-разному представляют себе то, о чем читают или говорят. Полного совпадения не бывает почти никогда.

Предприняв определенные усилия, можно и нужно сблизить их восприятие (об этом, мы писали в книге «Как написать бизнес-требования? Бизнес-специалисту — как разговаривать на одном языке с ИТ».

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

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

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

Что происходит такого, что было упрощено и не продумано явно в момент подписания?

А могло ли быть иначе?

Эти вопросы и ответы на них прямо связаны с жизнью требований.

Начнем с простого представления о требованиях, которое преобладает в практике.

Простая модель требований

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

Ну, например, нужно сделать диалоговое окно с текстовым сообщением и кнопкой «ОК».

Вроде же всем все понятно? Конечно же, нет.

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

Рис.1. Возможный вид диалога со строкой текста и кнопкой «Ok»

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

— Необходимо вывести диалоговое окно с кнопкой «OK»

— В окне должен быть заголовок «Подтвердите действие»

— В окне должен быть текст «Ваша карточка сохранена!»

— Цвета: текста черный #000000, фона и букв на кнопке белый #FFFFFF, фона кнопки синий #0000AA.

— Шрифты: Arial — для заголовка и кнопки размер 10, для текста — 8.

— При открытии окна обработка останавливается, при нажатии «ОК» окно закрывается, обработка продолжается.

— Эскиз окна приведен на следующем рисунке, размер окна 450х140 пикселов.

Рис.2. Эскиз диалогового окна

Кажется, теперь все на месте (понятно, что можно численно задать расположение кнопки, надписи на ней и далее детализировать, но для примера нам достаточно и этого).

Раз так, требование можно фиксировать и, затем, выполнять.

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

Поставим в соответствие нашим требованиям критерии приемки и вот что получится:

1. Визуально убедиться, что:

— выведено диалоговое окно с кнопкой «OK», окно соответствует эскизу по набору и взаиморасположению компонентов (численно проконтролировать заданные параметры — размер окна 450х140 пикселов);

— заголовок «Подтвердите действие»;

— в окне текст «Ваша карточка сохранена!»;

— форматирование следующее: цвет текста черный #000000, фона и букв на кнопке белый #FFFFFF, фона кнопки синий #0000AA, шрифт: Arial — для заголовка и кнопки размер 10, для текста — 8;

2. Убедиться, что:

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

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

Такова традиционная модель: выясняем у заказчика, что нужно сделать, фиксируем, далее выполняем, проверяем результат на соответствие критериям, передаем результат заказчику.

Жизненный цикл требования состоит из его формулирования (сбора) и выполнения — это и есть простая модель требования.

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

Поговорим об этом подробнее.

«Водопад» — методология на простой модели требований

Как известно, «Водопадная», или каскадная модель — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.

Традиционно для каскадной модели фазы следуют в таком порядке:

— определение требований;

— проектирование;

— конструирование;

— воплощение;

— тестирование и отладка;

— инсталляция;

— поддержка.

Переход от одной фазы к другой происходит только после полного и успешного завершения предыдущей.

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

Сначала полностью завершается этап «определение требований», в результате чего получается список требований.

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

Задумаемся, какие ограничения устанавливаются для требований в момент завершения фазы определения требований по каскадной методологии? Ответ достаточно очевиден — в этот момент требования фиксируются и далее являются неизменными.

Что означает «неизменными» с точки зрения проекта? Как минимум, следующее:

— содержание требования, как его понимают все участники проекта, более не меняется;

— связи требования с другими требованиями прояснены и не изменяются значимым для понимания других требований образом;

— не возникает новых требований;

— существующие требования не удаляются из рассмотрения.

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

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

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

Допущения простой модели требования довольно быстро ограничили область применения «чистой» «водопадной» методологии, потому что в реальности требования далеко не всегда столь стабильны, как допускается для этой методологии.

Это порождает серьезные риски в проектах, которые достаточно часто недооценивают.

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

Стоит отметить, что развитые инструменты управления требованиями (тот же IBM Rational), предоставляют возможности именно управления изменениями в требованиях, но их использование в реальных проектах не очень распространено в силу высоких затрат как на приобретение и сопровождение самих инструментов, так и на связанные с их использованием процессы. Поэтому встретить эти средства можно только в очень масштабных и длительных проектах, и то редко.

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

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

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

Рассмотрим детально каждое из допущений простой модели и сформируем эту другую модель.

Глава 2. Как работать, если требования постоянно меняются?

Вместо эпиграфа

"Однажды к раввину пришел посетитель и начал жаловаться:

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

— Да-да, есть одно старинное средство, — ответил раввин. — Нужно взять много бумажек, написать на них: «И это все пройдет», и разложить во всех комнатах.

Озадаченный человек поблагодарил и ушел.

Через пару лет возвращается тот же человек и благодарит:

— Ребе, как я вам благодарен, как благодарен, просто нет слов! Я нашел отличную работу, жена выздоровела, дочка вышла замуж, сын закончил учебу и устроился на фирме. Все просто отлично! Спасибо вам большое! Да, только еще хотел спросить — те бумажки, которые я в квартире разложил, их можно уже убирать?

— Зачем убирать? — удивился раввин. — Пусть пока полежат".

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

И для требований, как отражения жизни, фраза «и это все пройдет» часто более чем справедлива.

Что это означает для нас, как специалистов, работающих с требованиями? Вернемся к постулатам простой модели требований и посмотрим на них с позиции течения жизни.

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

Динамическая модель требований

Ранее мы назвали допущения-постулаты для простой модели требований.

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

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

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

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

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

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

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

Увы, и это гарантировать тем труднее, чем длительнее и сложнее проект.

Проиллюстрируем тем же примером диалогового окна программы, что был приведен при описании простой модели. Вот пара требований из списка:

— в окне текст «Ваша карточка сохранена!»;

— форматирование следующее: цвет текста черный #000000, фона и букв на кнопке белый #FFFFFF, фона кнопки синий #0000AA, шрифт: Arial — для заголовка и кнопки размер 10, для текста — 8;

А теперь представим, что требования цветов взяты из бренд-бука компании, который в этот момент также находится в разработке, поэтому цвет может быть и #0000BB, и #EEEEEE, и еще множество других вариантов, которые сейчас неизвестны.

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

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

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

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

Может сработать. Но может и нет, если текст будет существенно разной длины и это повлечет изменение верстки.

Важно то, что наше внимание к особенностям реализации требования обусловлено не его содержанием «вывести текст», а его состоянием «заказчик колеблется в выборе текста».

Возвращаясь к общему случаю, получаем другую, более сложную модель требования, которая опирается на то, что:

— содержание требования, как его понимают все участники проекта, может изменяться в ходе проекта;

— связи требования с другими требованиями могут прояснятся и изменятся значимым для понимания других требований образом в ходе проекта;

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

Назовем это динамической моделью требования.

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

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

Итерационные и гибкие методологии, как средства реализации динамической модели требований

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

— требования;

— проектирование;

— изготовление;

— проверка соответствия требованиям;

— устранение несоответствий;

… (пока не будет устранено несоответствие требованиями)

— проверка соответствия требованиям;

— приемка (передача в эксплуатацию)

Предсказуемость (да и возможность) выхода из этого цикла зависит от двух параметров:

— фиксированы ли требования,

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

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

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

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

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

В этом случае необходимо представить динамическую модель как последовательность простых. То есть, на какое-то время требования фиксируются, затем опять могут изменяться, затем снова фиксируются и т.д. Как это сделать?

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

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

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

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

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

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