Вся команда мечтает о премиях и о том, на что их потратит…
Все более чем замечательно и тут, прямо в самой последней группе требований вылезает оно…
Незрелое требование… Или тихо увядавшее весь проект требование, наконец, потерявшее актуальность.
И все летит…
И рушатся планы. И грусть возникает на лицах проектной команды, а печаль поселяется в душе их…
Ведь, увы, так бывает.
И это совершенно не то, что хотелось бы видеть в проектах. Поэтому за «свежестью» и «увяданием» требований неплохо бы следить в ходе проекта.
Но что это за «свежесть» и как за ней следить?
Об этом мы и расскажем в нашей книге.
Данная книга посвящена подходу, позволяющему отслеживать «свежесть», «зрелость» и актуальность требований с ранних этапов и далее, в течение всего проекта. Вести мониторинг жизненного цикла этих требований и сократить негативные последствия, обусловленные этим жизненным циклом.
Кому это важно? В принципе всем, кто задействован в проектах как от заказчика, так и от исполнителя будет полезно знать о «свежести» и «зрелости» требований, но прежде всего это важно для аналитиков, работающих с требованиями, руководителей проектов, а также специалистов заказчика, отвечающих за требования с его стороны.
Материал этой книги – попытка поделиться собственным опытом и его систематизация.
Мы верим, что данный подход будет полезен и вам. И это позволит избежать грусти на лице и печали в душе у вас и ваших коллег, когда требования оказались не «свежи» и «увяли».
Благодарим за выбор этой книги и желаем интересного чтения!
ЧАСТЬ I. Почему просто собрать требования мало?
Глава 1. Типовой взгляд на требования в ИТ-проекте
Вместо эпиграфа
Из леса выходит обросший, одичавший партизан.
– Эй, бабка! Побыстрее убегай отсюда! Сейчас в деревню придут враги!
– Да ты что, милок? Война уж тридцать лет как кончилась!
– Вот это да-а! А я все это время поезда пускал под откос?..
Известный анекдот, когда что-то пошло не так. Посмотрим на это, как аналитики: партизан получил задачу – пускать под откос вражеские поезда, собрал требования: чтобы ни один не прошел, дальше в меру сил и возможностей решает ее, только вот время прошло, война закончилась, требование устарело, но, по какой-то причине не отменено (забыли, связи не было, да масса других возможных причин), и его продолжают выполнять, нанося уже не пользу, а прямой вред.
Увы, такое случается не только в анекдотах. Достаточно часто требования должны изменяться, отменяться, в том числе, в ходе реализации проектов. И чтобы не стать такими незадачливыми героями анекдотов, стоит подробнее разобраться с жизнью и смертью требований, чтобы по незнанию не пустить под откос какой-нибудь важный проект.
Как это сделать? Об этом и расскажет наша книга.
Требования, как принимаемый на веру набор положений
Существенной особенностью восприятия требований в проектах является то, что это свод положений, в которые верят в момент заключения соглашения заказчик и разработчик.
Достоверного и гарантированного способа убедиться, что выполнение требований приведет именно к ожидаемому результату нет. Это обусловлено человеческой природой: разные люди все равно по-разному представляют себе то, о чем читают или говорят. Полного совпадения не бывает почти никогда.
Предприняв определенные усилия, можно и нужно сблизить их восприятие (об этом, мы писали в книге «Как написать бизнес-требования? Бизнес-специалисту – как разговаривать на одном языке с ИТ».
Момент, когда требования в восприятии сторон вызывают достаточно доверия для начала работ по проекту, знаменуется подписанием договора заказчика и исполнителя.
С этого момента требования всем не только понятны, но и закреплены юридически.
Так почему же дальше проект не всегда движется по плану и достигает намеченного результата?
Что происходит такого, что было упрощено и не продумано явно в момент подписания?
А могло ли быть иначе?
Эти вопросы и ответы на них прямо связаны с жизнью требований.
Начнем с простого представления о требованиях, которое преобладает в практике.
Простая модель требований
Обычно, когда говорят о требовании, подразумевают нечто, понятное заказчику и
