Основные проблемы при работе с требованиями
Проблема №2. Не то время
На разработку и анализ требований в наших проектах выделяется мало времени — слишком мало, ничтожно мало. И связано это не столько с экономией времени, которого всегда ни на что не хватает, сколько с формулировкой задачи.
Согласитесь, что написать ТЗ или спецификацию это совсем не то, что разработать требования. Разработка требований включает в себя не только их идентификацию, структурирование и формулирование, но и такие мероприятия, как исследование области проблем, включая специальные области (отказобезопасность, надежность и т.п.), разработку вариантов архитектуры и сопутствующих им производных требований, анализ, валидация и верификация. Однако, в подавляющем большинстве проектов, которые мне приходилось наблюдать, разработка требований сводится именно к написанию ТЗ или спецификации. Поручается эта задача, как уже обсуждалось в первой части, тому сотруднику, который в настоящий момент более или менее свободен. И, в полном соответствии с формулировкой задачи, время на нее отводится почти никакое. Подобный подход практикуется в основном для проектов составных частей критичных систем.
И для обоснования этого подхода подводится серьезная доказательная база:
мол, если мы что-то упустили, то потом, во время валидации (согласования спецификации), или во время испытаний все равно все будет обнаружено. Ведь для этого испытания и проводятся, не так ли?
а Заказчик не хочет оплачивать такую интенсивную и затратную работу над требованиями.
Да, так. И испытания проводятся согласно программе и методике испытаний (или согласно плану верификации и валидации). Но при этом, все методы и тестовые примеры разрабатываются исходя из набора требований, и предназначены для того, чтобы доказать себе и Заказчику, что все требования подтверждаются. Это значит, что требования упущенные (или требования к «потерянным» функциям и режимам) не войдут в планы испытаний и тестирования. А «неправильные» требования будут подтверждены, и тем самым будет узаконено создание и передача в эксплуатацию «неправильной» системы. В результате — остаются скрытыми проблемы, которые обнаруживаются только во время эксплуатации. Эти проблемы несут с собой большие финансовые и репутационные потери, либо приводят к полному краху целевой системы (на рисунке ниже — Boing 737 MAX, катастрофа в Эфиопии, взято с сайта today.com).
Проблемы с выделением необходимого времени и усилий на выявление и определение заинтересованных сторон, на проработку области проблем свойственнен и проектам по созданию информационных систем. Хотя, в силу специфики, при создании или модернизации информационных систем этим вопросам и уделяется больше внимания, чем при разработке составных частей критичных систем, однако все равно — недостаточно. Разработчики информационных систем тоже не без греха, и зачастую полагают, что знают лучше Заказчика, что именно нужно сделать. Место полученной от заинтересованных сторон и валидированной с разных точек зрения информации о существующих проблемах и потребностях занимает компетенция разработчика. Наличие такой компетенции и большого опыта проведенных проектов мешает прислушаться и поинтересоваться, а какие еще потребности есть у представителей Заказчика, в особенности у пользователей разного уровня.
И, наконец, пару слов о том, что времени и денег на работу с требованиями выделяется недостаточно, или не выделяется вообще. Каждый более или менее серьезный проект содержит в себе этап эскизного проектирования или эскизно-технического проектирования. Эти этапы предназначены не только для написания пояснительной записки к эскизному или эскизно-техническому проекту, но и (в первую очередь!) для исследования области проблем, для нахождения упущенных требований, функций и режимов изделия/системы. К сожалению, время и ресурсы, отводимые на эти этапы, часто тратятся на подчистку «хвостов» от других проектов, а не на исследование области проблем. И это становится причиной возникновения «хвостов» уже в текущем проекте. Получается порочный круг, который необходимо разорвать.
Часть 3. Не тот метод.
