Как написать требования к бизнес процессу
Перейти к содержимому

Как написать требования к бизнес процессу

  • автор:

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

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

Данный материал будет интересен бизнес- и системным аналитикам, менеджерам и владельцам продуктов, CEO небольших стартапов, в общем — всем, кому нужно писать требования к разработке фичей и ИТ-систем.

Здесь не будет базовой теории, что есть требование и что оно должно соответствовать SMART (надеюсь, вы это и так знаете). Скорее, я покажу некие best practice, как требования лучше оформлять в документации.

Начнем с обсуждения:

  • Общих принципов написания «удобных» требований
  • Использования таблиц
  • Использования схем и диаграмм

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

  • Подход Specification by Example
  • Варианты использования
  • Мокапы интерфейса

Требования это не роман и удивлять слогом тут никого не нужно. Я еще не раз это повторю в статье, но тот кто читает ваши требования, должен напрягаться по минимуму.

Здесь, как и в дизайне интерфейсов, отлично работает правило: «Не заставляйте меня думать», про которое писал Стив Круг в одноименной книге.

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

  • Используйте простой слог и слова, избегайте общих формулировок.
  • Избегайте сложносочиненных предложений. В идеале, одно предложение = одна мысль.
  • Если вы встречаете союзы «но», «или», то скорее всего, здесь скрыты два отдельных требования.
  • Не используйте двойные отрицания.
  • Для требованиий со структурой «если <условие>, то <результат>» пишите сначала результат, а потом — условие. Пример: « Система должна запрещать сохранение заказа, если хотя бы одного товара нет в наличии» .

« Должна быть возможность удалить конкретный товар или сразу все товары из корзины» .

По сути, данное требование содержит два отдельных требования:

  1. «Должна быть возможность удалить конкретный товар из корзины» .
  2. «Должна быть возможность удалить сразу все товары из корзины» .

Такое разделение поможет не пропустить скрытое требование разработчику или QA и подскажет менеджеру, что здесь лучше завести две отдельные задачи.

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

Используйте средства, которые доступны вам в любом редакторе:

  • Списки
  • Абзацы
  • Полужирный шрифт

Например, если вы используете союз «и» (или несколько таких союзов), то лучше каждое условие написать с новой строки.

«Необходимо перевести заказ в статус «Доставляется», если заказ оплачен и весь товар есть в наличии на складе.»

Давайте упростим восприятие этого требования. Получим следующее:

«Необходимо перевести заказ в статус «Доставляется», если:

  • Заказ оплачен
  • И весь товар есть в наличии на складе.

Что мы сделали? Мы сняли часть когнитивной нагрузки с того, кто будет изучать данное требование. Уже из форматирования становится видно, что:

  • Речь идет о заказе в статусе «Доставляется».
  • Действие изменения статуса должно выполняться при соблюдении двух условий.

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

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

«Заказ отображается в личном кабинете пользователя, если заказ находится в одном из статусов: «Новый», «Ожидает оплаты», «Оплачен», «Доставляется». Заказ в статусе «Доставлен» не должен отображаться в личном кабинете.»

Как можно его упростить:

«Заказ отображается в личном кабинете пользователя, если его статус не равен «Доставлен» .

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

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

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

Запомните, таблицы — ваш главный «бро» ��

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

  • Как я могу упростить эти требования?
  • Как эти требования можно оформить в табличном виде?

Почему таблицы лучше работают:

  • Таблицы воспринимаются проще, чем сплошной текст. Меньше вероятность упустить важные детали при изучении требований.
  • Таблицы проще изменять и дополнять информацией в будущем (новые колонки, новые строки).
  • Удобно добавлять комментарии (в отдельной колонке), отделяя их от требований.

Рассмотрим пример части из ТЗ на большую государственную систему из открытых источников:

«Успешно авторизованный пользователь, входящий в группу пользователей c ролью «Исполнитель», должен попадать на «UI-006 Главная страница личного кабинета», а пользователь, входящий в группу пользователей с ролью «Наблюдатель» – на «UI-092 Главная страница Мониторинга (дашборд)» подсистемы «Мониторинг». Если пользователь в личном кабинете настроил страницу по умолчанию, то открываемая страница должна определяться на основе выбранной настройки.»

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

«После успешной авторизации в системе, пользователю должна открываться стартовая страница, согласно условиям ниже:»

Если в дальнейшем у нас появится новая роль, то нужно будет всего лишь добавить еще одну строку в таблицу.

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

Пример формы редактирования из того же ТЗ:

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

  • Тип поля.
  • Значение поля при открытии формы.
  • Ограничения на выбираемые данные.
  • Можно ли редактировать поле и требования к валидации (если есть).

Для описания действий на форме (Сохранить и Отмена) лучше использовать отдельную таблицу, так как описания действий и полей формы сильно отличаются.

Когда использовать таблицы (спойлер — всегда!):

  • Вы описываете два и более объектов со одинаковыми свойствами (поля формы; разделы сайта; роли пользователей и т.д.).
  • Вы хотите описать реакцию системы при возникновении определенных событий.
  • Вы описываете миграцию данных или маппинг полей между системами.

Схемы и диаграммы — это еще один отличный способ улучшить качество передачи знаний в команде разработки.

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

Далее я поделюсь схемами, которые использую чаще всего.

Зачем нужна: Показывает как разрабатываемая система взаимодействует с внешними миром.

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

Когда использовать: На этапе проектирования системы, чтобы:

  • Понять, с какими системами придется интегрироваться.
  • Понять, какие интерфейсы ввода/вывода нужно реализовать.

P.S. Еще эту диаграмму очень любят архитекторы.

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

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

Пример контекстной диаграммы из книги «Разработка требований к программному обеспечению» (Джой Битти, Карл Вигерс):

BPMN — это нотация описания бизнес-процессов в виде набора обозначений и ряда определенных правил.

Зачем нужна: Позволяет зафиксировать описание бизнес-процессов на этапе их дизайна и использовать это «знание» на этапе разработки и внедрения решения.

Когда использовать: Вообще, у BPMN довольно широкий спектр применения.

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

При разработке BPMN-диаграмм (в контексте описания требований) главное — избавиться от перфекционизма.

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

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

  • Start/End Events — начальное и конечное события.
  • Activity — Действие, которое выполняет пользователь или система.
  • Gates — Шлюзы. Используются для принятия решений и запуска параллельных процессов.
  • Lanes — Дорожки, которые разграничивают разные типы пользователей и системы.

Пример описания бизнес-процесса обработки инцидентов:

Если вам интересна отдельная статья про примеры построения BPMN-диаграмм на реальных примерах, напишите об этом в комментариях.

Зачем нужна: показывает как объект переходит из одного состояния в другое.

Когда использовать:

  • У объекта много состояний (2+), логика переходов зависит от определенных событий.
  • С объектом могут совершать действия сразу несколько пользователей (например, редактирование заказа). Это поможет выявить исключительные ситуации, которые можно заранее продумать, а не фиксить потом на production.

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

Пример диаграммы состояний для объекта «инцидент» из BPMN-диаграммы выше:

Семь «золотых» правил описания бизнес-процессов

3 июня 2021

Семь «золотых» правил описания бизнес-процессов

Сергей Ковалев

Сергей Ковалев — руководитель и ведущий консультант консалтинговой компании БИТЕК (Бизнес-инжиниринговые технологии). Имеет 20-летний опыт организационного проектирования и управления бизнес-процессами. Автор публикаций, семинаров и книг по стратегическому и процессному управлению и развитию.

Чаще всего проблемы эффективного описания и дальнейшего использования процессных диаграмм вызваны человеческим фактором. Опыт описания процессов в российских компаниях показал, что зачастую персонал не заинтересован в этих работах. Причина понятна — описание бизнес-процессов дает ответы на вопросы «кто чем занимается» и «кто за что отвечает». Это делает работу компании прозрачной, подконтрольной руководству и управляемой. Прозрачность, в первую очередь, выгодна руководителям, она позволяет стимулировать персонал компании активнее работать на цели организации. Кроме того, описание бизнес-процессов позволяет выявить «излишки» финансовых, материальных, временных и трудовых ресурсов. Неудивительно, что всегда есть сотрудники, которые каким-либо образом отказываются открывать реальную информацию о деятельности предприятия.

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

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

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

Правило 2. Используйте простые и наглядные подходы описания бизнес-процессов.

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

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

Правило 4. Создавайте схемы деятельности, а не организационных структур.

Пример. Где заканчивается процесс «Поставка товара от поставщика»?

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

Правило 5. Избегайте излишней детализации процессов, особенно на схеме «как есть».

Правило 6. Избегайте составления схемы процесса ради схемы, не ведущей к дальнейшему анализу и действиям.

Пример. Спор о накладной

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

Правило 7. Не смешивайте понятия «как есть» и «как надо».

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

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

Напоминалка: Бизнес требования — документ

olala

Рассмотрим подробнее документ описывающий бизнес требования. За основу возьмем все тот же Scope and Vision из Software Requirements (3 edition) by Karl Wiegers and Joy Beatty. Что же в нем писать?

  1. Business requirements

Бизнес требования — это первые(главные) требования к продукту. Если цели неясны и нет определенных ожиданий от продукта, то данный документ написать будет очень сложно. Очень часто заказчики и спонсоры думают, что “все итак ясно” и делать его не надо, но это ошибка, которая потом будет стоить очень дорого (потому что все остальные требования полагаются на бизнес требования). При этом, действительно, скорее всего не все аспекты продукта будут покрыты данным документом и после определения бизнес требований могут (и это нормально) оставаться неточности и неясности. Таким образом, этот документ поможет структурировать бизнес требования, определить цели, риски, ожидания и ограничения к проекту. Также документ поможет выявить противоречия в требованиях, так как очень часто бизнес требования диктуются несколькими людьми.

  1. 1. Background (предпосылки)

Здесь пишем про то, как появилась идея создать продукт (контекст). Кто, почему и при каких условиях придумал продукт? Очень хорошо полагаться на исследования и статистику, если имеются.

  1. 2. Business opportunity (бизнес возможности)

Описываем бизнес проблему и рынок на которой существует эта проблема. Если проблем нет, то описываем бизнес возможности(и новшества), которые предоставит продукт (опять же основываясь на рынке). Это и преимущества продукта, уникальные решения и способы удовлетворения нужд пользователей.

  1. 3. Business objectives (бизнес цели)

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

  1. 4. Success metrics (метрики успеха)

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

  1. 5. Vision Statement (видение)

Описание долгосрочных целей. Сбалансированное мнение всех заказчиков и заинтересованных лиц. В книге предлагается следующий паттерн:

  • Для [целевая аудитория продукта]
  • Которая [описание нужд и возможностей]
  • [Название продукта]
  • Это [Категория продукта]
  • Который [основные возможности, ключевые выгоды, причины купить или использовать]
  • В отличие от [предыдущие альтернативы, текущая система, текущий бизнес процесс]
  • Наш продукт [преимущества нового продукта в сравнении с текущими и альтернативами].

Для* одиноких женщин, *которые* нуждаются в любви и ласке, представляем решение *котик*. Котик — это такое домашнее *животное*, *которое* помогает справиться со злостью лучше всех, он будет ласкать вас, играть с вами и просто радовать глаз. *В отличие от* мужчины, которому нужно готовить свежую еду и периодически стирать носки, *котик* будет кушать готовую еду (продается практически в каждом магазине), ему не надо стирать одежду (достаточно его мыть раз в полгода). А еще котик не играет в танки!

  1. 6. Business risks (риски)

Опасения, проблемы и все плохое, что можно ожидать.

  1. 7. Business assumptions and dependencies (предположения и зависимости)

Здесь записываются предположения, сделанные заинтересованными лицами, но не имеющие подтверждения, и зависимости от внешних факторов (законодательство, third party приложения и прочее).

2. Scope and limitations (объем и ограничения)

Описание того, что должно быть сделано и, чего НЕ должно быть.

2.1. Major features (главная функциональность)

Пишем основные логические части продукта. Не забываем привлекать экспертов команды и заинтересованных лиц в это дело.

2.2. Scope of initial release (допустимый минимум или объем первоначальных работ)

Говорящий сам за себя заголовок или Глава 5 книги из первого поста.

2.3. Scope of subsequent releases (объем последующих работ)

План. Всегда нужен план. Здесь он будет примерный, но нужен. Проектный менеджер поможет, определенно.

2.4. Limitations and exclusions (ограничения и исключения)

Список того, что хочется, но по каким-то причинам не будет сделано в запланированные версии. Так называемое “out of scope”.

3. Business context (бизнес контекст)

Здесь фиксируем лица и даты, чтобы никто не убежал , чувствовал свой вклад и понимал когда наступит время Х 🙂

3.1. Stakeholdes profiles (заинтересованные лица)

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

3.2. Project priorities (приоритеты)

Описываем последовательность действий(и действия) и все, что с этим связано. Функциональность, качество, план, стоимость и персонал. Эти приоритеты должны быть согласованы.

3.3. Deployment considerations (особенности развертывания)

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

Как разработать
бизнес-требования

Давайте поговорим о том, откуда берутся требования. И бизнес-требования (БТ), и нефункциональные требования напрямую вытекают из потребностей бизнеса.

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

Из бизнес-требований, помимо функциональных (ФТ) и нефункциональных требований, напрямую могут вытекать ещё и требования причастных сторон. В свою очередь, из требований причастных сторон могут вытекать ФТ и НФТ.

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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *