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

Шрифт
Интервал


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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