Живые требования – тот еще фрукт. Актуализируем и реализуем, пока не испортились
Шрифт:
Для начинающих свой путь аналитиков часто фокусировка на сборе и фиксировании требований выглядит некоторым культом, инициацией в профессии. Они часто полагают, что суть работы аналитика в том, чтобы получить от заказчика требования и зафиксировать их.
Это верно, но лишь отчасти, другие аспекты работы по поддержанию жизненного цикла требований остаются в тени.
При этом простая модель не выделяет других аспектов, для этого нужна иная модель.
Рассмотрим детально каждое из допущений простой модели и сформируем эту другую модель.
Глава 2.
Вместо эпиграфа
"Однажды к раввину пришел посетитель и начал жаловаться:
– Ребе, у меня все так плохо, так плохо! Я потерял работу, моя жена болеет, дочка никак не может выйти замуж, мой сын не хочет учиться. Ребе, подскажите, может, вы знаете, что мне делать?
– Да-да, есть одно старинное средство, – ответил раввин. – Нужно взять много бумажек, написать на них: «И это все пройдет», и разложить во всех комнатах.
Озадаченный человек поблагодарил и ушел.
Через пару лет возвращается тот же человек и благодарит:
– Ребе, как я вам благодарен, как благодарен, просто нет слов! Я нашел отличную работу, жена выздоровела, дочка вышла замуж, сын закончил учебу и устроился на фирме. Все просто отлично! Спасибо вам большое! Да, только еще хотел спросить – те бумажки, которые я в квартире разложил, их можно уже убирать?
– Зачем убирать? – удивился раввин. – Пусть пока полежат".
Да, говорит известная притча, проекты, как и вся наша жизнь, крайне изменчивы.
И для требований, как отражения жизни, фраза «и это все пройдет» часто более чем справедлива.
Что это означает для нас, как специалистов, работающих с требованиями? Вернемся к постулатам простой модели требований и посмотрим на них с позиции течения жизни.
Результат такого рассмотрения обеспечит нам более приближенную к жизни, чем простая, модель требований.
Динамическая модель требований
Ранее мы назвали допущения-постулаты для простой модели требований.
Пройдем по этим ранее заявленным постулатам, которыми обеспечивалась характерная для простой модели фиксация «неизменности» требований.
Насколько неизменным в реальности является тот постулат, что содержание требования, как его понимают все участники проекта, более не меняется?
На самом деле, это допущение не очень точно, потому что со временем коммуникации приводят к углублению и, иногда, изменению понимания требований участниками проекта. Чем длиннее по времени и сложнее проект, тем более вероятно, что понимание требований со временем претерпит изменения.
Далее, постулат,
Связи – элемент, характеризующий сложность системы. Очевидно, что по мере углубления и детализации понимания могут быть как выявлены новые связи, так и установлена ошибочность представления о каких-то связях, ранее кажущихся существующими.
Так что, длительность и сложность проекта и в этом постулате существенно увеличивает вероятность того, что неизменность, в данном случае, связей будет нарушена.
К тем же выводам мы придем, рассмотрев набор требований с точки зрения неизменности его состава, то есть, что не возникает новых требований, а существующие требования не удаляются из рассмотрения.
Увы, и это гарантировать тем труднее, чем длительнее и сложнее проект.
Проиллюстрируем тем же примером диалогового окна программы, что был приведен при описании простой модели. Вот пара требований из списка:
– в окне текст «Ваша карточка сохранена!»;
– форматирование следующее: цвет текста черный #000000, фона и букв на кнопке белый #FFFFFF, фона кнопки синий #0000AA, шрифт: Arial – для заголовка и кнопки размер 10, для текста – 8;
А теперь представим, что требования цветов взяты из бренд-бука компании, который в этот момент также находится в разработке, поэтому цвет может быть и #0000BB, и #EEEEEE, и еще множество других вариантов, которые сейчас неизвестны.
Конечно, сразу возникает идея сначала закончить и утвердить в таком случае бренд-бук, а затем уже его использовать в других проектах. В реальности обстоятельства могут требовать одновременности работ, обусловленной ограниченными сроками получения результатов обоих проектов по экономическим, управленческим, регуляторным или иным причинам.
Теперь по втором требованию. Пусть, для примера, фраза «Ваша карточка сохранена!» не полностью нравится бизнес-заказчику, у него есть мнение, что текст может быть «Операция выполнена!» или «Документ сохранен!», между которыми он никак не может выбрать.
Изменения по этим требованиям вроде бы не выглядят трудоемкими, но, если они потребуются десятки раз в течение проекта (а это вполне реально, если заказчик колеблется в выборе), это уже будет ощутимо.
Одним из вариантов сразу видится вынести формулировку текста в настройки, чтобы не менять код каждый раз.
Может сработать. Но может и нет, если текст будет существенно разной длины и это повлечет изменение верстки.
Важно то, что наше внимание к особенностям реализации требования обусловлено не его содержанием «вывести текст», а его состоянием «заказчик колеблется в выборе текста».
Возвращаясь к общему случаю, получаем другую, более сложную модель требования, которая опирается на то, что:
– содержание требования, как его понимают все участники проекта, может изменяться в ходе проекта;