После вынужденного перерыва возвращаюсь к обещанному циклу статей. Отвечаю на вопрос “куда пропал?)”. Все банально, нехватка времени. А еще я умудрился затеять ремонт. В квартире. Я конечно знал, что управление проектами родилось в строительстве, но только сейчас это реально прочувствовал на себе. Сколько аналогий с ИТ-проектами! Даже на таком казалось простом проекте как квартира, мне пришлось наблюдать все последствия плохого управления. А управлял этим делом нанятый прораб, который, как оказалось, только начал сам организовывать ремонты и по сути своей остался просто мастером. Получилось примерно как программиста отправить управлять ИТ-проектом.
Итак, о требованиях. Как многие знают, о требованиях я уже писал и рассказывал на конференции, а повторяться не хочется. Поэтому, сегодня буду краток и сконцентрируюсь именно на “правильных” требованиях, а конкретнее на их формулировке, пригодной для использования. По сути, мне придется сделать конспект ранее мной же сказанного, только другими словами. Как это там называется, кажется редакция 2.х))
Для “правильной” работы с требованиями нужно сделать 4 вещи:
-
Определиться с видами требований.
-
Определиться с уровнем требований.
-
Прогнать каждое требование через фильтр качества.
-
Создать систему идентификации прослеживаемости жизненного цикла требований.
Собственно все! Больше ничего не нужно. Давайте разберемся с этими четырьмя пунктами.
Определиться с видами требований.
Иногда встречаются документы, где в кучу намешаны требования совершенно разных видов. Например, требования к функциональности, безопасности, производительности. И все вперемешку. Это не только снижает понимание и восприимчивость команды, но и делает работу более энергозатратной. Не надо так делать. Лучше сгруппировать их по видам и отрабатывать отдельно.
В подавляющем большинстве случаев приходится иметь дело с функциональными требованиями. Стоит отметить, что иногда все же целесообразно включать в раздел функциональных и иные виды требований. Например, если нужно разработать отчет, который должен формироваться не дольше 1 мин, а данные этого отчета должны выдаваться в соответствии с уровнем доступа. Тогда у нас добавятся требования к производительности и безопасности. В данном контексте лучше их указать в разделе функциональных, т.к. указанные требования могут повлиять на архитектуру разработки с самого начала.
Определиться с уровнем требований.
Главная мысль заключается в том, чтобы не мешать требования разного уровня в одном документе. Разные уровни требований - разные виды документов. Иначе, неизбежно вызовет проблемы. И вообще, работать с требованиями верхнего уровня это высший пилотаж, доступный только сработавшимся командам, которые специализируются на однотипных задачах и могут себе позволить оперировать агрегированными понятиями, каждый понимая под ними одно и тоже.
Например: “В системе должна быть поддержка штрихкодов”. Где поддержка, при каких условиях, каким устройством, каких штрихкодов, в каких документах и каких операциях… Под этим может пониматься, например, “при сканировании двумерного штрихкода мобильным телефоном в документ “перемещение товаров” должен подставляться товар и его фактическое количество на складе”. И в каждой операции могут всплыть разные детали, иногда весьма существенные. Поэтому, все варианты использования сканера нужно расписать отдельными требованиями.
По моему опыту, куски с агрегированными требованиями в документах чаще встречаются не от того, что “и так все понятно”, а как раз наоборот. От того, что не смогли или не захотели разобраться. Видимо будут применяться золотые формулы: “там прорвемся” и “программисты разберутся”.
Если делаете документ с агрегированными требованиями, то поступайте так со всеми требованиями. Это обосновано, когда действительно не хватаем информации. Да и оценить работы будет сложно. Возможно, в этом месте как раз подойдет какой-нибудь SCRUM с открытым бюджетом. Сам документ вряд ли можно будет назвать техническим заданием, скорее это будет некая “концепция системы”.
Прогнать каждое требование через фильтр качества.
С тех пор, как я рассказывал о теме на конференции в 2012 году, ничего не поменялось. Читать тут.
Если читать лень, вот на картинке все наглядно:
Создать систему идентификации и прослеживаемости жизненного цикла требований
Такая очевидная и простая вещь, как идентификация требований, в большинстве проектов не организована и требования не прослеживается. Под идентификацией и прослеживаемостью подразумеваются две вещи: сам принцип идентификации и некая система, где эти требования учитываются. С принципом все просто, можно взять и пронумеровать типа раз, два, три. А вот с системой учета требований могут возникнуть вопросы. Где их учитывать? Есть специализированные программные продукты, но они громоздкие и дорогие, в нашей индустрии не прижились. Есть практика использования систем типа Task Manager. Таковых сейчас очень много, в т.ч. и бесплатных, которые прекрасно работают в облаке через браузер. Кто-то разрабатывает собственные системы, функционал не сложный. В крайнем случае подойдет и Excel или Google-таблица. Каждая команда сама решает, как им удобнее, все практики рабочие и могут иметь место. Важно, чтобы:
-
Когда вы обсуждаете что-то неработающее с пользователем, вы должны понимать требование номер “какой” вы обсуждаете.
-
Когда разработчик что-то программирует, он должен понимать, что работает над требованием номер “Х”. И когда выпустил новый релиз тоже. Реализовал требование “Х1”, исправил ошибку в требовании “X2”.
-
Когда специалист обучает пользователей, он должен быть уверен, что все требования включены в программу обучения или нашли отражение в пользовательских инструкциях.
-
Когда вы сдаете проект заказчику, вы должны четко понимать, какие требования “ХХ” выполнены и переданы, а какие остались не реализованными.
-
Когда в техподдержку приходят обращения, она должна понимать, относительно каких требований возник вопрос. Возможно, вопрос вообще находится за рамками проекта. Таким образом этапы внедрения в промышленную эксплуатацию часто превращаются в черную дыру, засасывающую все ресурсы.
-
И т.д и т.п. Вы всегда должны понимать, где находитесь. Идентификация требований является основой для управления ими.
Всем хороших проектов и ждем выпуск №4 :)
