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