Зачем улучшать технологии управления требованиями к автоматизированной информационной системе

ПОЛЬЗОВАТЕЛИ И СТЕЙКХОЛДЕРЫ

Заинтересованных представителей бизнеса, который мы собираемся оцифровывать, автоматизировать, обычно называют стейкхолдерами. Это могут быть, например, шефы производства, финансов, коммерции, логистики и прочих подразделений. Бывает, что в круг стейкхолдеров вносят и акционеров, собственников бизнеса, и клиентов по причине их заинтересованности в конечной автоматизации.

Люди, которые будут использовать информсистему для своей работы или целей, – это пользователи. При этом пользователь может одновременно быть стейкхолдером, если он отвечает за выполнение бизнес-задачи. А если перед ним не стоит такая ответственность, то его основными целями являются удобство и простота цифровых продуктов.

ЧАСТО ПОЛЬЗОВАТЕЛЬСКИЕ ТРЕБОВАНИЯ ТРУДНО ОТДЕЛИТЬ ОТ БИЗНЕС-ТРЕБОВАНИЙ ИМЕННО ПОТОМУ, ЧТО СТЕЙКХОЛДЕРЫ ЯВЛЯЮТСЯ ОДНОВРЕМЕННО И ПОЛЬЗОВАТЕЛЯМИ, И БИЗНЕС-ОТВЕТСТВЕННЫМИ ЗА ЗАДАЧИ

При этом важно понимать, что цели пользователей и стейкхолдеров чаще всего не совпадают.

Пользовательские требования – это то, как себе представляет в идеале работу в АИС пользователь. Обычно эти требования включают в себя не только ответы на вопросы, что и как должна позволять делать система, но и эргономику, и визуальное отображение пользовательского интерфейса.

С другой стороны, есть функциональные требования – это требования к выполнению определенных бизнес-функций в АИС, например, функции казначея или бухгалтера. Обычно описываются очень подробно и детально. Также для большей точности их еще называют функционально-техническими требованиями (ФТТ), но по сути они все равно остаются функциональными требованиями и к чисто техническим их отнести нельзя.

Нефункциональные требования (технические) – это требования к системе как к техническому продукту и его эксплуатации. Например, туда относят доступность системы для пользователя или время отклика на операцию. Чаще это цифры, нежели слова.

ИДЕАЛЬНАЯ МОДЕЛЬ АВТОМАТИЗАЦИИ

Теперь давайте перейдем к модели того, как все это должно работать:

1. Бизнес-вызовы ставят перед стейкхолдерами бизнес-задачи.

2. Бизнес-задачи закрываются реализацией бизнес-требований к новой системе.

3. Бизнес-требования закрываются выполнением функциональных и нефункциональных требований к АИС.

Если все учтено и описано правильно, то мы получаем на выходе положительный результат и выполнение цели автоматизации.

Кто-то из читателей воскликнет: «А где здесь пользовательские требования, забыли про них?!» Все верно, мы про них забыли. Правильно это или нет, тут нужно разобрать поподробнее.

Итак, с точки зрения «оголтелого» бизнеса удобство рядовых пользователей АИС, если это не клиенты, которые приносят жизненно важную выручку, отходит на второй план, потому как за реализацию этих требований платит в конечном счете собственник бизнеса. Более того, реализация такого рода требований зачастую не коррелируется с достижением бизнес-требований и бизнес-задач, а скорее имеет обратное влияние на эффективность.

То есть

ДОПОЛНИТЕЛЬНОЕ УДОБСТВО И ЛЕГКОСТЬ ВЫПОЛНЕНИЯ РАБОТЫ НАЕМНЫМИ РАБОТНИКАМИ, КОНЕЧНО, ИМЕЮТ ВАЖНОСТЬ, НО ЦЕННОСТИ БИЗНЕСУ НЕ НЕСУТ САМИ ПО СЕБЕ, А ТОЛЬКО В СВЯЗКЕ С ДРУГИМИ ЭЛЕМЕНТАМИ ЦЕПОЧКИ ДОБАВЛЕНИЯ ЦЕННОСТИ ДЛЯ КЛИЕНТА

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

ОЖИДАНИЕ И РЕАЛЬНОСТЬ

На практике вышеописанная модель работает совсем не так, как в теории.

Бизнес-вызовы ставят перед стейкхолдерами бизнес-задачи – с этим все ок.

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

По мнению подрядчика/исполнителя от IТ, бизнес-задачи закрываются реализацией иногда пользовательских требований, чаще функциональных и не всегда нефункциональных требований к системе.

НА ДАННОМ ЭТАПЕ ВОЗНИКАЕТ МНОГО РАЗНОГЛАСИЙ И ПРОТИВОРЕЧИЙ

Бизнес-требования закрываются выполнением функциональных и нефункциональных требований к АИС, но противоречия предыдущего этапа могут не позволить до этого этапа добраться.

Почему же возникает путаница на втором этапе «идеальной» модели работы с требованиями к информационным системам/бизнес-приложениям? Причин, как всегда, сразу несколько.

Во-первых, в стане заказчика будущего решения таким мелочам, как различия между видами требований к будущей информационной системе, не часто придают значение, считая, что это «птичий» айтишный язык.

Во-вторых, нужно понимать, что проектные команды от бизнеса имеют, как правило, «двухголовое» управление – IТ-заказчик и функциональный заказчик. Это накладывает некоторые условности, например, решения по нефункциональным требованиям тяготеют к юрисдикции IТ-заказчика, а по функциональным – функционального заказчика.

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

В-четвертых, зачастую никто не держит в голове, что процесс управления требованиями при внедрении/разработке АИС – это такая постоянная деятельность, которую невозможно ограничить конкретным этапом проекта. У многих складывается впечатление, что достаточно один раз переписать все требования и на этом все закончится. Однако заказчики всегда будут приходить с новыми требованиями, пересмотром старых, и если у вас нет упорядоченности в этом процессе, то управлять изменениями становится трудоемко и конфликтно.

Если на практике возникают аналогичные проектные трудности, то это негативно влияет на цель проекта и снижает удовлетворенность заинтересованных сторон.

С чего можно начать в таких ситуациях? Для начала

НЕОБХОДИМО ЧЕТКО РАЗВЕСТИ ТРЕБОВАНИЯ ПО РАЗНЫМ СЛОЯМ ПРОЕКТНЫХ КОМАНД ЗАКАЗЧИКА

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

Функциональные требования лучше фиксировать с фокус-группой из ключевых пользователей будущей АИС, ведь именно они будут потом тестировать будущую систему.

Нефункциональные требования лучше проводить через IТ-заказчика.

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

Постоянно пересматривать подходы к управлению требованиями в силу причин и обстоятельств, описанных выше, нужно и важно.