ЛЮСТРА: Методика разработки бизнес-требований в проекте по автоматизации

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

Часть 1 | Часть 2 | Часть 3 | Часть 4

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

Авторская методика ЛЮСТРА помогает аналитику разработать бизнес-требования таким образом, чтобы минимизировать последующие изменения требований со стороны заказчиков в проекте по автоматизации бизнес-процессов. Ее цель — направить разговор со стейкхолдерами в сторону целей бизнеса, чтобы выявить легитимные и обоснованные потребности. Преимущество методики заключается в использовании мнемотехник, что делает ее легко запоминаемой и применимой в любом интервью с заказчиком.

Сфера применения методики ЛЮСТРА

Какие проблемы решает

Методика ЛЮСТРА решает следующие проблемы:

1. Частое изменение требований на проекте со стороны бизнеса из-за того что: 

   1. Были собраны требования не с лиц, принимающих решения. 

   2. Были собраны требования не всех заинтересованных лиц. 

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

   4. Во время опроса стейкхолдеры сформулировали решения, а не потребности.

   5. При сборе требований были учтены не все этапы работ, которые затронуты проектом. 

2. Заказчики изначально формулируют конкретные решения и аналитику сложно в разговоре с ними перейти на выявление потребностей.

3. Заказчики формулируют нефункциональные требования к системе, взятые «из воздуха», особенно в виде «магических чисел» вроде «отчет должен формироваться за пять минут».

В каких проектах

Наилучшим образом методика ЛЮСТРА проявляет себя в проектах, для которых верно одно или несколько из следующих утверждений:

1. Это проект по развитию существующей информационной системы.

2. Это стартовая автоматизация в компании со сложными бизнес-процессами.

3. В корпоративной среде произошел сдвиг в сторону требований к системе, когда и сами заказчики, и бизнес-аналитики формулируют требования к системе, а не бизнес-требования.

4. Бизнес-заказчики выдают большой объем информации, сложный для анализа и структурирования.

Как соотносится с другими методиками

Методика детализирует и уточняет существующие стандарты по разработке требований: ISO/IEC/IEEE 29148, BABOK Guide, онтологию Вигерса, INCOSE.

В методике не рассматриваются другие этапы работы с требованиями в проекте по автоматизации:

• определение проблем, целей и ограничений проекта, 

• определение списка стейкхолдеров,

• процесс интервьюирования,

• описание бизнес-процессов,

• генерация вариантов решений,

• проработка системных требований.

Предпосылки для методики ЛЮСТРА

Откуда появляются бизнес-требования?

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

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

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

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

• требования, которые человек должен выполнять

• в определённом контексте,

• не ущемляя своих интересов.

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

ЛЮСТРА: методика разработки бизнес-требований

Представленная выше схема по разветвлению и трассировке требования к бизнесу похожа на люстру — по этой мнемотехнике можно запомнить методику разработки бизнес-требований.

• Л — легитимность. Убеждаемся, что опрашиваем нужного стейкхолдера, и проверяем правомерность требований к бизнесу, чтобы потом ни у кого из участников проекта не было оснований их оспорить.

• Юзер

• Стори: формулируем потребности стейкхолдеров, которые возникают из предъявленных к ним требований, контекста, в котором эти требования приходится выполнять, и личных интересов. Формулируем, например, в формате User Story

• Требование к

• Решению: потребности стейкхолдеров определяют требования к решению.

• А потом всё остальное: требование к решению, в свою очередь, в зависимости от проблем и целей проекта, рисков и выгод поможет подобрать правильные решения для бизнеса, некоторые из них потом трансформируются в требование к системе.

При опросе стейкхолдера проекта, который является ответственным сотрудником предприятия, следует действовать в следующей последовательности:

1. Найти ИКС — место возникновения изменения, которое привело к формированию потребности. Выясняем, нужного ли стейкхолдера мы опрашиваем.

2. Сформулировать БИЗНЕС-требование: выяснить требование к бизнесу в лице ответственного сотрудника. Проверяем источники и предпосылки требований.

3. Провести ОПРОС: определить, что формулирует стейкхолдер. Подталкиваем его к тому, чтобы вместо конкретных требований сформулировать потребности.

4. Сформулировать потребности ответственного сотрудника в формате User Story или Job Story: что ему нужно для того, чтобы выполнить взятые на себя обязательства.

5. Выявить СВОД бизнес-функций, которые затрагивает потребность в данном бизнес-процессе. Выявляем неявные и подразумеваемые требования, расширяем список стейкхолдеров для опроса.

6. Сформулировать требования к решению на основании потребностей и выявленного реестра бизнес-функций.

Рассмотрим подробно каждый шаг методики.

Найти ИКС

ИКС — место возникновения изменения, которое привело к формированию потребности.

Выясняем, нужного ли стейкхолдера мы опрашиваем:

• Если причина изменений заключается в изменении интересов опрашиваемого сотрудника, продолжаем с ним интервью

• Если причина изменений заключается в изменении требований к сотруднику, тогда сначала надо убедиться в легитимности требований. Заканчиваем интервью с этим сотрудником и назначаем интервью с сотрудником, с которого началось изменение требований.

• Если причина изменений кроется в контексте, надо смотреть по ситуации.

Сформулировать БИЗНЕС-требование

Прежде чем выявить потребности сотрудника, выясняем: а что требуется от него самого? Задайте вопросы заказчику по мнемотехнике БИЗНЕС и сформулируйте требования по канве:

• База требования. В каком нормативном акте содержится требование к бизнесу? Если требование нигде не прописано, то кто источник требования? При каком условии это требование вступает в силу?

• Исполнитель. Кто должен выполнить требование?

• Заказчик. Кто выгодоприобретатель? Кто будет принимать исполнение требования?

• Нормативная Единица требования. В чём заключается требование? Что именно нужно выполнить? Какое действие с каким объектом нужно совершить?

• Стандарт требования. По каким параметрам требование можно считать выполненным? Место, время, продолжительность, формат, образ действия.

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

Подробности см. в первой статье.

Провести ОПРОС 

Определить, что формулирует стейкхолдер:

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

Подробности см. во второй статье.

Сформулировать потребности

Формулируем потребности ответственного сотрудника: что ему нужно для того, чтобы выполнить взятые на себя обязательства. Потребности ответственных лиц можно описывать в разных форматах, в рамках методики ЛЮСТРА используются User Story и Job story, чтобы подчеркнуть место возникновения потребности.

User Story следует применять, если место возникновения потребности — интересы стейкхолдера или требование к нему. Job Story используется, если нужно сосредоточить внимание на контексте, в котором у ответственного лица возникли сложности.

Подробности см. во второй статье.

Составить СВОД бизнес-функций

Определить бизнес-процесс и бизнес-функцию, в рамках которых нужно сформулировать требования к решению. Каждый бизнес-процесс и подпроцесс можно разложить на следующие бизнес-функции, которые описываются словом СВОД:

• Событие: итог бизнес-процесса

• Выбор: решения, которые нужно принимать в рамках данного бизнес-процесса

• Операция: действия, которые нужно выполнять в рамках данного бизнес-процесса

• Данные: информация, которую нужно собрать, обработать, сохранить и предъявить в рамках данного бизнес-процесса

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

Подробности см. в третьей статье.

Сформулировать требования к решению

На основании всего указанного выше формулируем требования к решению:

Подробности см. в первой статье.

Пример использования методики

Производственная компания, проект по автоматизации нового бизнес-направления.

Поступило исходное требование от оператора склада:

В системе в документе «Накладная» рядом с кнопкой печати накладной мне нужна отдельная кнопка для печати транспортной накладной.

1. Найти ИКС: выясняем место и причину изменений.

Почему раньше кнопка была не нужна, а теперь понадобилась?

Выясняем причину изменений: изменилось требование к сотруднику.

Раньше покупатели могли забрать товар только с помощью самовывоза и я печатал документ «Накладная». Теперь у компании появилась ещё и функция доставки, когда нужно распечатать и накладную, и транспортную накладную. Боюсь, что по привычке буду печатать только накладную, поэтому мне нужно видеть отдельную кнопку для печати транспортной накладной, чтобы не забыть про нее.

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

2. Сформулировать БИЗНЕС-требование

Нам необязательно подниматься до уровня требования к бизнесу: главное, убедиться, что требования к ответственному лицу легитимны. В данном случае требования закреплены в стратегии и финансовом плане, а также должностной инструкции руководителя отдела продаж и договорах с контрагентами.

3. Провести ОПРОС

Выясняем у руководителя отдела продаж, что это он переложил на оператора склада ответственность сформулировать требование, поэтому получилось требование к системе.

4. Сформулировать потребность

Направляем ход разговора в сторону формулирования потребности руководителя отдела продаж:

5. Сформулировать СВОД бизнес-функций

Процесс «Продажи», подпроцесс «Выставление документов, подтверждающих факт продажи». Разложим его на бизнес-функции:

События, которые являются итогом бизнес-процесса:

• Доставка товара: клиент получает товар вместе с накладной и товарной накладной.

• Самовывоз: клиент забирает товар с накладной.

Выбор, которые необходимо сделать в бизнес-процессе:

• Определить способ получения товара (доставка или самовывоз) и принять решение о необходимости печати определенных документов в зависимости от выбранного способа получения товара.

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

Операции, которые нужно выполнять в рамках данного бизнес-процесса:

• Принять заказ и выбор способа получения товара

• Сформировать необходимые документы в зависимости от выбранного способа получения

• Проверить корректность подготовленных документов

• Распечатать документы

• Выдать документы клиенту вместе с товаром

• Сохранить копии документов для внутреннего учета и отчетности

Данные, которые нужно собрать, обработать, сохранить и предъявить в рамках данного бизнес-процесса

• Информация о заказе (номер заказа, дата, наименование товара, количество)

• Информация о клиенте (ФИО, адрес доставки, контактные данные)

• Информация о способе получения товара (доставка или самовывоз)

• Информация для оформления транспортной накладной в соответствии с требованиями законодательства

6. Сформулировать требования к решению

На основании выявленных потребностей руководителя отдела продаж мы можем составить следующие требования к решению:

В соответствии с требованием к решению впоследствии вместе с заказчиком можно разработать разные варианты решения, например:

1. Внедрение электронного документооборота, который исключит нужду в печати.

2. Интеграция учетной системы с веб-сайтом, который будет отслеживать выбор клиента (самовывоз или доставка) и автоматически формировать необходимый набор документов.

3. Автоматизация существующей системы:

   1. в случае наличия в накладной услуги доставки, программное обеспечение автоматически должно формировать и «Накладную», и «Транспортную накладную».

   2. в случае включения накладной в план по доставке, программное обеспечение автоматически должно формировать и «Накладную», и «Транспортную накладную».

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

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

Метасистема требований в проекте по автоматизации

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

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

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

• требования законодательства,

• глобальный контекст — рыночные спрос и предложение, тренды, экологическая повестка, развитие технологий, особенности географии и погоды,

• потребности бизнеса, 

• потребности и опасения стейкхолдеров,

• бенчмаркинг: как это реализовано у конкурентов, или в этой же компании в другом подразделении 

2. При переходе от бизнес-требований к требованиям к решению необходимо оставить следующую информацию:

• локальный контекст — существующие процессы внутри компании: наличие или отсутствие данных, существующие технологии и информационные системы, структура подразделений, бизнес-процессы,

• потребности стейкхолдеров, рассмотренные в рамках бизнес-процесса по каждой из бизнес-функций, формулируем в качестве требований к решению

• набрасываем список вариантов решений,

• отделяем те варианты решений, которые точно будут переформулированы в виде требований к ответственным, а не требования к системе

3. Для работы над требованиями к системе должна остаться следующая информация:

• список требований стейкхолдеров к решению, каждое из которых представляет собой:

  • функциональное требование, которое может быть выполнено с помощью системы,

  • набор нефункциональных требований в виде бизнес-правил,

  • набор нефункциональных требований, ограниченных локальным контекстом

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

Заключение

С помощью методики ЛЮСТРА мы подсвечиваем заказчику направление, по которому мы должны пойти, чтобы разработать корректные бизнес-требования. Необязательно быть профессионалом и разбираться в предметной области, просто нужно начинать с того, чтобы уточнить у стейкхолдеров, на основании чего они действуют и принимают решения, что они должны и кому, и почему именно сейчас возникла потребность в изменениях.

Методика направлена на развитие способности видеть за программным кодом живой организм компании, его потребности и потребности его клиентов, выступая своеобразным напоминанием о первичности бизнеса перед системой. Она применяется при опросе стейкхолдера, когда сам заказчик формулирует требования на языке взаимодействия пользователя с системой: «Я хочу, чтобы система сама формировала», «Алгоритм должен рассчитать», «Мне нужна кнопка» — и помогает направить разговор о разработке требований в сторону бизнеса.

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

1. Опрашиваем нужных стейкхолдеров, которые отвечают за принятие решений.

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

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

4. Выявляем неявные и подразумеваемые требования, а также пропущенных стейкхолдеров.

5. Готовим почву для функциональных и нефункциональных требований к системе.