IT / Статьи
цифровизация экспертная колонка
12.12.2022

Разделяй и требуй

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

Требования к автоматизированной информационной системе (АИС), которые позволяют достичь результата при решении какой-либо бизнес-задачи, на практике могут по-разному трактоваться и восприниматься представителями бизнеса и пользователями. О собственном понимании терминологии и наглядной разнице в смыслах рассказал читателям RSpectr функциональный архитектор PROF-IT GROUP Денис Окулов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

То есть

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

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

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

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

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

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

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

На данном этапе возникает много разногласий и противоречий

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Изображение: RSpectr, Freepik, Adobe Stock

Еще по теме

Что делают вузы для преодоления кадрового голода в отрасли

Каких мер господдержки ждут разработчики ВКС-решений

В правительстве РФ заявили о перевыполнении планов по программе «Цифровая экономика»

Что стоит за ростом производства компьютеров в России

Какой должна быть защита персональных данных в 2023 году

Мотивировать IT-специалистов к возвращению из эмиграции предлагается законодательно оформленной бронью и расширением льгот

Перспективы сертификации кибербезопасников в РФ и поможет ли она остановить утечки данных

Какие эффекты ожидаются от использования информсистемы пространственных данных

На портале можно будет записаться на прием к юристам

Каковы итоги уходящего года и перспективы будущего для рынка 1С

Как будет развиваться рынок low-code в России

Как в 2022 году проходило импортозамещение на рынке вычислительной техники

Какую архитектуру выбрать при разработке сложного приложения для крупного бизнеса

Как продолжить верить в Деда Мороза, но не попасть в новогоднюю аферу

Сможет ли искусственный интеллект проверять школьные сочинения