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

ГЕОРГИЙ САВЕЛЬЕВ

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

Модель выявления требований

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

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

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

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

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

В наглядном виде модель выявления требований представлена на схеме:

Почему важно выявлять и документировать
бизнес-требования?

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

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

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

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

Кроме того, бизнес-требования в Agile — это ключевой инструмент Product Owner для управления бэклогом продукта и ведения переговоров со стейкхолдерами.

Какие бывают бизнес-требования?

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

Ниже приведены примеры бизнес-требований по видам критичных активностей.

Вид БТ: Значимые характеристики продуктов или услуг

Примеры БТ:

• Скорость обслуживания — очередь на кассе должна быть не длиннее 4 покупателей.
• Своевременность доставки — клиент должен получить пиццу горячей и не умереть ожидая ее.
• Простота получения услуги — оформление предварительно одобренного кредита должно завершаться за одно посещение клиента.

Вид БТ: Распознавание и обработка событий

Примеры БТ:

• Банк должен своевременно получать оповещения о сбоях в работе банкоматов.
• К моменту начала этапа работ, все нужные материалы и оборудование должны находиться на объекте строительства и быть готовыми к использованию.
• Сотрудники должны быть своевременно проинформированы о назначенных им задачах.

Вид БТ: Принятие решений

Примеры БТ:

• По каждому обнаруженному дефекту, на основе имеющейся информации, должно быть оперативно принято решение о способе его устранения в соответствии с протоколом реакции на аварийные ситуации.
• Решение о выдаче кредита должно приниматься на основании…
• Отпускная цена на товар для конкретного клиента определяется на основании… в зависимости от …

Вид БТ: Сбор, обработка, хранение и предоставление информации

Примеры БТ:

• С момента обнаружения дефекта и до его полного устранения должна регистрироваться и храниться следующая информация.
• Инвестиционный банк в конце каждого рабочего дня должен направлять Регулятору информацию о…
• Для принятия решений об участии в тендере необходимы результаты предварительной оценки себестоимости проекта.

Вид БТ: Обеспечение возможности выполнения действий

Примеры БТ:

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

Вид БТ: Предотвращение возможности выполнения действий

Пример БТ:

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

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

Требование, заданное с позиции «Система должна делать…», задает конкретное направление действиям разработчика, а также дает некоторые ограничения — в отличие от формулировки требований с позиции «Система не должна…»

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

Признаки проблем в бизнес-требованих

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

• Неконкретность (слишком абстрактная формулировка)
• Невозможность проверки (нет понимания, что является индикатором выполнения требования)
• «Магические» числа (приведены какие-то необоснованные данные: «время обработки заявки 14 минут»)
• Непонятная польза (не написано, для чего делаем то, что делаем; действительно ли это необходимо)
• Избыточная детализация (зачастую делает требование слишком жестким и нечитаемым)
• Невыполнимость (например, требование «обеспечить 100%-ую достоверность данных». Для чего это требование? Почему возникают недостоверности? С этой проблемой можно как-то бороться или это просто факт?)
• Несогласованность (противоречивость; с одной стороны Покупатель хочет найти продукт с наилучшими качествами по наименьшей цене, а с другой — Продавец хочет стимулировать покупку продуктов, приносящих наибольшую прибыль)
• Нерелевантность (приведено требование, которое вообще не понятно, какое отношение имеет к данному проекту)
• Привязка к конкретному решению, в том числе — конкретный бизнес-процесс

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

Работа с «магическими» числами

Чтобы проверить требование на наличие данной проблемы, можно определить чувствительность (столбец «чуть-чуть» в таблице) требования и его границы (столбец «гораздо» в таблице).

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

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

Любое число (разместим его в центральном круге) проверяется на чувствительность (на рисунке это столбец «чуть-чуть»). Что будет, если число будет немного больше? Есть ли какие-то последствия в таком случае для системы, стейкхолдеров? А если число будет чуть-чуть меньше?

Затем мы задаем вопросы, пытаясь выявить реальные границы требования. Что, если число будет значительно больше? На что это повлияет? А если влияние достаточно серьезно, то нельзя ли предложить дополнительный способ обойти проблему? Границы обозначены в модели как столбец «гораздо».

Расмотрим пример требования, которое содержит «магическое» число:

“

Проверим это требование на чувствительность. Для этого зададим вопросы:

1. Что будет, если время обработки заявки будет не 14, а 12 минут?
2. Что, если увеличить до 14,5 мин? Насколько это критично?

В процессе проверки может выясниться, что обработка заявки может занимать даже 30 минут, не принося никакого ущерба бизнесу.

Проверим границы требования, ответив на вопросы:

1. Может быть, целесообразно сократить время обработки до 0 минут, т. е. не обрабатывать заявки и перевести клиента на самообслуживание?
2. Что будет, если одна заявка будет обрабатываться день? Это плохо? Как это скажется на бизнесе?

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

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

Попробуем переформулировать требование на примере:

“

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

Примеры некорректных бизнес-требований

1. Обеспечить высокое качество обслуживания — Как проверить, что качество обслуживания высокое?
2. Сократить среднее время обработки заказа до 14 минут — Почему до 14 минут, чем это обосновано? А почему не до 1 минуты? Какую пользу принесет сокращение времени обработки заказа?
3. Обеспечить 100% достоверность учетных данных — Как мы узнаем какая достоверность? Как можно определить, что данные достоверны? В результате чего возникает недостоверность? С этим реально можно что-то сделать? Выполнимо ли данное требование?
4. Гарантировать правильность принимаемых решений — Что выступает гарантом? Это выполнимо?
5. Внедрить ERP — Кому и зачем это нужно? В чем проблема?

Типовые ловушки аналитика

Проблемы с требованиями, как правило, возникают, когда аналитик попадает в одни и те же типовые ловушки. Вот основные ловушки аналитика при работе с бизнес-требованиями:

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

Что можно сделать с каждой из этих ловушек?

Как документируются бизнес-требования?

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

1. Монолитно

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

2. Дробно

• Каждое требование описывается отдельно.
• Каждому требованию присваивается уникальный идентификатор.
• Возможна трассировка к конкретному бизнес-требованию.

Ниже будет приведен шаблон для каждого из этих видов документирования.

Где документируются бизнес-требования?

Стандартом ISO предполагается, что бизнес требования будут отражены монолитно в Спецификации требований стейкхолдеров (StRS). Для этого предусмотрен отдельный раздел Introduction, который включает в себя Business Purpose (цели), Business Scope (границы), Business Overview (обзор бизнеса).

В ГОСТе 34.602−89 предполагается, что бизнес-требования будут описаны также, монолитом, в техническом задании на создание автоматизированной системы. в разделе Назначение и цели создания системы и Характеристика объектов автоматизации.

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

В Agile бизнес-требования могут быть отражены по-разному. Это не формализовано, нет стандарта документов и способов описания.

Шаблон монолитного описания БТ

Карл Вигерс в своей книге «Разработка требований к программному обеспечению. Руководство» предлагает хороший шаблон описания БТ монолитом в рамках документа Scope and Vision (рамки и видение). В этом документе выделяется раздел Бизнес-требования, который включает в себя:

• Контекст.
• Описание возможности.
• Бизнес-цели.
• Метрики успешности.
• Образ результата (Vision).
• Деловые риски.
• Предположения и зависимости бизнеса.

Советы Вигерса по описанию БТ

• Сокращайте шаблон в соответствии с потребностями.
• Заполняйте не сверху вниз, а по мере поступления информации.
• Пустой раздел — признак его ненужности или необходимости дополнительного изучения.
• Не повторяйте то, что уже описано в другом месте — сошлитесь на имеющееся описание.
• Исходите из возможности повторного использования БТ в других проектах.
• Выявляйте конфликты, противоречия и выносите на обсуждение.
• Проводите повторное рассмотрение БТ при каждой смене лиц, принимающих решения, чтобы убедиться, что понимание БТ не изменилось

Шаблон дробного описания БТ

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

• Уникальный идентификатор.
• Краткое описание.

2. Определение, развернутое объяснение, что из себя представляет БТ.
3. Источник, откуда это требование взялось.
4. Зависимости, если они есть между другими требованиями.
5. Обоснование, краткое пояснение мотивации.
6. Комментарий, любые пояснения. В приведенном ниже примере представлено описание диаграммы состояний.

Как документировать —
объединять или дробить?

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

1. Нет нужды документировать, если:

• Узко-технический проект небольшого объема.
• Всем все понятно и вряд ли кому-то когда-то что-то будет непонятно.

2. Объединяем, если:

• Компактный проект с узкими целями.
• Узкая предметная область.
• Бизнес-требования умещаются на паре страниц.

3. Дробим, если:

• Много бизнес-требований.
• Сложные бизнес-требования.
• Могут реализовываться по отдельности.
• Высокая степень неопределенности.

Что делать с отсутствующими или плохими БТ?

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

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

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

2. Добавить комментарии к уже существующим требованиям, поясняя откуда оно взялось.

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

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

• Что делать, если, помимо ТЗ, есть еще и пользовательские требования?

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

• Вопрос:

  Имеет ли смысл создание промежуточных документов таких как VSD (Vsion & ScopeDocument) и BRD (Business Requirement Document)?

  С точки зрения Agile практик, бизнес-требования — это епархия Product Owner. Следовательно, работать нужно так, как удобно, и не создавать лишних документов для соблюдения формального протокола. Чем документов меньше, чем они компактнее и проще, тем эффективнее.

• Должны ли в описание БТ быть включены требования к описанию «хотелок» в части User Interface?

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

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

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

• Должен ли аналитик просматривать баги проекта и принимать решения о их важности?

  Иногда аналитик должен просматривать баги, а иногда — нет. Зависит от договоренностей в рамках проекта и распределения ролей в команде.

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

• Должен ли аналитик проводить тестирование и валидацию продукта?

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

• Что является объектом требований вида «Должна собираться информация о недоступности банкомата» — к чему это бизнес требование? К организации? Подразделению? К бизнес-процессу?

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

• Что делать с функциями, если они не мапятся на конкретное БТ или мапятся сразу на два (при этом функция должна быть в скоупе)?

  Важно понимать, для чего мы делаем трассировку. В данном случае мы делаем трассировку, чтобы понять — БТ выполняется или нет?
  Нам не важно замапить все на все. Если мы делаем трассировку к модулям, это не значит, что нам надо оттрасировать каждую функцию и каждое требование. Достаточно понимать, данное требование — оно выполнено или нет? Если понимания достигнуто, то дальше можно не трассировать. Если мы пытаемся оттрасировать в другую сторону и видим какую-то висячую функцию, то это не значит, что у нас не должно быть никаких висячих функций, которые мы не можем замапить на какую-то функцию.
  Стоит помнить, что трассировка — это инструмент, а не цель.

Георгий Савельев

Подписаться на новые статьи

Основы бизнес-анализа: вход в профессию для начинающих

Разработка ТЗ на информационную систему по ГОСТ и SRS

Вместо эпиграфа

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

— Что за чёрт?!

Подрядчик:

— Всё сделано по чертежу, вот, посмотрите.

Заказчик, переворачивая чертеж вверх ногами:

— Это должен был быть маяк!

Все знают этот старый анекдот. Но вот вопрос, почему подрядчик копал яму по чертежу, и даже не подумал его перевернуть? Хочется ответить, что просто неграмотный и не перевернул чертеж.

Да, возможно, это и так. Ну, а, если ошибся чертежник и переворачивать чертеж по правилам не было нужно? Почему возможна такая дикая нестыковка с ожиданиями заказчика?

Ответ простой — подрядчик исполнял задание, не задумываясь о бизнес-задачах заказчика! Он просто не знал, зачем заказчику то, что он делает. Возможно, заказчик собирался указывать путь кораблям? Но это предположение. Может быть, маяк ему нужен был совсем для другого, и тогда нужно было бы строить совсем другой маяк, или вообще не маяк?

Подрядчик всего этого не знал и не спросил, вот и получился анекдот вместо результата.

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

Давайте посмотрим, почему это происходит и как это можно улучшить.

Как начинается разработка

Как начинается разработка ИТ-решения?

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

— Конкуренция и то, что у других компаний данный процесс работает лучше.

— Время на принятие решений и выполнение операций превышает желаемое.

— Оптимизации и прочие внутрикорпоративные движения повышения эффективности.

— Желание стать более современным и цифровизированным подразделением.

— Хайп на рынке, влияние внешнего маркетинга.

— Вера в чудесное новое решение всех проблем.

— Новости законодательства и отраслевых регуляторов.

— Воля вышестоящего руководства.

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

Появляется критерий «соответствие ожиданиям», то есть:

— ожидания должны быть сформированы;

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

— для метрик и категорий определены целевые значения.

В реальности так бывает редко. Обычно ожидания сродни мечте или иллюзорному образу «светлого будущего». При этом воля (или драйв, как нынче модно говорить) имеется, а, значит, есть и движение к мечте.

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

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

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

Итак, ключевые факторы начала разработки это:

— Желание, или даже мечта, драйв;

— Возможность привлечь для создания решения необходимые ресурсы;

— Понимание целей того, что собрались сделать, и вера в бизнес-полезность этого.

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

Немного остановимся, на том, что такое требование и каковы его свойства.

Основные виды требований

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

Итак, выделяются следующие виды требований:

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

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

Ограничение — ограничение на выбор вариантов, доступных разработчику при проектировании и разработке решения

Требование к взаимодействию — описание взаимодействия с пользователем, другой программной системой или устройством.

Функциональное требование — описание требуемого поведения системы в определенных условиях. Функциональные требования описываются в форме традиционных утверждений со словами «должен» или «должна».

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

Среди нефункциональных требований обычно выделяют:

Требования по удобству использования — достаточно сложно формализуемый пункт, но часто важный, например, «размещение заказа из корзины должно выполняться не более, чем двумя кликами мыши».

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

Требования к безопасности — все, что касается обеспечения информационной безопасности и защиты информации, включая требования по криптографической защите.

Требование к доступности и надежности — необходимые параметры, определяющие доступность системы, простои (например, по рабочим дням с 9:00 до 18:00 московского времени, с не более, чем двумя перерывами обслуживания в день продолжительностью до 5 минут), резервирование данных и вычислительных средств.

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

Способы сбора требований

Источников требований к ИТ-решению не так много. Вот основные из них:

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

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

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

Среди традиционных способов сбора требований упомянем такие как:

— Проведение фокус-групп типичных пользователей.

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

— Проведение интервью для выявления требований.

— Проведение совместных семинаров.

— Наблюдение за пользователями на рабочих местах.

— Разработка и раздача опросных листов.

— Анализ документов.

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

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

— со слов, без документирования;

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

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

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

Разработка «со слов»

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

Так в чем же сильные и слабые стороны такого подхода? Какие условия необходимы для достижения успеха проекта при его реализации?

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

Как это может выглядеть? Например, так: заказчик вызывает к себе разработчика и рассказывает ему, что хотел бы видеть в ИТ-решении. Разработчик его выслушивает, возможно конспектирует, и после этого начинает разработку.

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

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

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

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

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

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

Недостатки не столь очевидны, но они есть:

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

— перенос единолично на разработчика задачи детализации требований и разрешения противоречий, существующих в требованиях, так как не делается детальной проработки и согласования требований с заказчиком;

— отсутствие возможности восстановления истории требований. Это негативно влияет на ведение изменений, может привести к «хождению по кругу», когда одно и то же требование то возникает, то пропадает в последовательных правках решения;

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

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

— потребность в многократном объяснении запутанных моментов со стороны заказчика при доведении информации до разработчика — излишние временные затраты и все тот же риск недопонимания и искажения восприятия;

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

В иных случаях шанс достижения цели разработки «со слов» без разочарований невелик.

Письменная спецификация требований к разработке

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

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

Первое ощущение, которое возникает при описании такого подхода — долго, нудно и, скорее всего, дорого. И это ощущение имеет под собой реальную почву. Так почему же и в каких случаях имеет смысл использовать такой подход?

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

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

При этом еще и определены приоритеты, как это строить, проработаны и сняты основные нестыковки, с которыми при построении решения столкнется разработчик.

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

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

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

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

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

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

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

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

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

Agile-подход

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

— Люди и взаимодействие важнее процессов и инструментов.

— Работающий продукт важнее исчерпывающей документации.

— Сотрудничество с заказчиком важнее согласования условий контракта.

— Готовность к изменениям важнее следования первоначальному плану.

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

Все заявления затрагивают требования, попробуем понять, как.

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

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

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

«Готовность к изменениям важнее следования первоначальному плану» указывает, как и предыдущее, что изменения неизбежны и к ним нужно быть готовыми. Тем не менее, чтобы изменить первоначальный план, его нужно сначала выстроить. А если изменять планы и не отслеживать (документировать) отклонения, вполне возможно начать ходить по кругу, зациклиться в изменениях, и цель не будет достигнута.

Таким образом, Agile придерживается позиции постоянной готовности к изменениям ради движения к цели в целом, и, для обеспечения этого, предлагает использование разумного объема документирования, исходя из текущей ситуации (и этот объем может меняться по ходу работ вместе с ситуацией).

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

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

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

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

Когда же разумно начинать разработку?

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

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

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

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

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

Начать разработку означает «начать что-то делать» для снижения риска «не разработать никогда, потому что не начали», а этот риск реален. Для проекта этот риск выглядит скорее с временным ограничением — «не успеть разработать вовремя».

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

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

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

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

— Получение части функций решения (непосредственно приближает к цели);

— Получение прототипа или макета для обсуждения и принятия более обоснованных требований (приближает к цели, но часть затрат может оказаться «выброшенной» — придется переделать, речь идет о прототипах и макетах, но полученная информация приближает проект к цели быстрее и точнее альтернативных вариантов);

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

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

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

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

Строить или перестраивать?

Мне нравится подход, восходящий к ТРИЗ (Теория решения изобретательских задач, разработанная Г.Альтшуллером в середине 20 века), который предполагает, что идеальное решение задачи, когда она сама себя решает. В рамках этого подхода при появлении любого нового компонента стоит спросить себя, а зачем он? Нельзя ли прийти к цели без него?

Зададим этот вопрос к бизнес-требованиям. Нельзя ли получить решение без них? И правильный ответ будет «да, это возможно».

Так зачем же нам тратить усилия на них? Все дело в затратах и вероятности. Как и в когда-то популярной вероятностной задаче о вероятности того, что обезьяна, сидящая за пишущей машинкой, напечатает роман «Война и Мир», в нашем ответе также нужно указать вероятность того, что полученное решение без требований совпадет с задачей.

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

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

Такое решение обычно существенно дешевле по стоимости внедрения, но может нести риски потери части бизнес-процессов, ухода персонала при переучивании на новые процессы (изменения не всем по душе) и утрате каких-то важных «ноу-хау», запрятанных в процессе и составлявших конкурентные преимущества.

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

Вопрос, нужны ли требования, еще и сводится к тому, хотим ли мы максимально быстро построить целевое решение, или готовы постепенно и последовательно приближаться к целевому, перестраивая и перестраивая?

Вы спросите: «Будет ли кто-то в здравом уме подписываться на многократную перестройку решения без уверенности в достижении цели?» — и будете правы, что это странный выбор. Но есть обстоятельства, когда такой выбор разумен:

— это исследования и уточнения требований, когда в некоторый момент можно просто остановиться, сказать себе «стоп, теперь нам все понятно» и приступить к разработке решения с понятными требованиями или просто получить необходимые выводы и остановиться (например, CusDev прототипы);

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

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

Проект или прототип?

Любое дело (конечно, не приводящее к разрушениям) можно делать, по крайней мере, двумя способами:

— сначала подумать, потом сделать;

— сначала сделать потом посмотреть на результат, подумать и переделать.

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

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