Бизнес-требования — в чем разница между хорошим и плохим?

Что такое «хорошее» требование?

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

«Хорошо», хотя требования молодые и незрелые

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

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

На этом этапе формирования жизни «хорошим» требованием будет сказать, что:

  • начинается со слов «Мне (или нам, или нашему отделу, или моим людям, или конкретной роли) нужно (или не нужно, не хочется, не хочется, следует, не следует, хочется или не нужно ‘не хочу)» ИЛИ определяет определенное измерение конкретного компонента будущего решения;
  • упоминает один элемент/особенность/поведение/заявление о том, что тот, кто имеет право принимать решения в бизнес-среде, является результатом проекта, который стоит финансирования;
  • он фокусируется на бизнес-результатах, а не на используемых технологиях; и
  • может быть связано с лицом, имеющим полномочия «владеть» и «финансировать» требование.

Пара прекрасных (ИОНШО — на наш не слишком скромный взгляд) примеров:

  1. Отдел продаж должен иметь возможность видеть, срок действия контрактов истечет в ближайшие 90 дней.
  2. Я хочу, чтобы система автоматически рассчитывала налоги с продаж на основе применимого законодательства о налогах с продаж.
  3. Посетителю сайта не нужно будет нажимать более одного раза, чтобы перейти на страницу оформления заказа с любой другой страницы сайта.
  4. Мы должны быть в состоянии отреагировать на инцидент с красным кодом в любой точке мира в течение 24 часов.
  5. Налог с продаж будет определяться на основе почтового индекса адреса доставки.

Уточнение требований

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

Точно так же, например, возьмем первое требование из набора выше:

«Продавец должен иметь возможность видеть, срок действия контрактов истечет в ближайшие 90 дней».

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

Упражнение на ясность

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

Хорошо, вот мой двухминутный список:

  1. Кто или что такое «Продажи»? Что они могут сделать? Что они будут делать с тем, что я им даю?
  2. Что значит «видеть»? Им нужны физические контракты или просто списки?
  3. Что такое контракт?
  4. Что заставляет контракт «истекать» и почему их это волнует?
  5. Предстоящие 90 дней? С тех пор как? Меняется ли это представление изо дня в день, еженедельно, ежемесячно, ежечасно или как?
  6. Подумайте, что в данном контексте такое день, 24 часа (сутки в одном месте) или глобальные сутки (и это 47 часов или как это работает)?

Хорошо, это первые 6 вопросов (или сколько вы хотите сосчитать) вопросов, которые поразили мой слабый ум, но помните, я автор! Вы, вероятно, можете сделать намного лучше, потому что вы смотрите на мир со своей точки зрения. Все это указывает на то, что, хотя требование было ясно для меня, когда я писал это, оно может иметь некоторую субъективность, которую необходимо учитывать, чтобы не привести нас к неправильному решению.

Когда это когда-нибудь закончится?

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

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

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

Почему бы нам не объяснить?

«Почему многие из нас пропускают процесс разъяснения?» — спросите вы? (По крайней мере, я думаю, что это то, что вы сказали в моей голове.) Во-первых, многие люди не любят задавать вопросы, опасаясь оказаться в неведении. (Это моя линия — вопросы не показывают невежество, проявляйте интерес!) Во-вторых, выяснить, что спросить, — тяжелая работа. (Конечно, не так сложно, как быть президентом, но все же.) Несмотря на то, что вопрос вызывает интерес, некоторые вопросы, по крайней мере, ЗВУЧАТ глупо, так как же вы можете быть уверены, что ВАШИ вопросы не глупы? Хорошо, кто из вас заметил нелепое использование скобок в этом абзаце, чтобы «уточнить», что имелось в виду? Это объяснило или было неправильно? Ах, головоломки, которые мы создаем для ясности.

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

Дилемма разложения

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

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

Функциональная и информационная составляющие

В своей простой форме декомпозиция заявления о требовании включает в себя постановку трех вопросов, начиная с «Что в требовании говорится или подразумевается, что система (или человек) должна будет СДЕЛАТЬ?» Поскольку любое действие требует определенной формы действия, мы ищем глагольные и объектные ответы (например, «рассчитать налог с продаж», «депозитный чек»). Поскольку глаголы указывают на действие, объекты обычно являются данными (или чем-то, о чем нам нужны данные).

Когда у нас есть список всех вещей, которые система или пользователи должны СДЕЛАТЬ, второй вопрос для каждого элемента в списке: «Какие данные система должна ЗНАТЬ, чтобы сделать это?» Поскольку данные — это вещь, мы теперь ищем существительные или именные словосочетания (например, «налог с продаж», «сумма задолженности», банк-эмитент).

Третий вопрос: «Откуда берутся эти данные?» и ответ может быть просто другой функцией или где-то вне системы (например, банк, клиент, IRS — извините за последнее, но это важный источник, а также боль в анатомии)

И вот как это происходит

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

Теперь все яснее?

Подтверждение перед кодированием

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

Пусть победит лучшее требование.

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

Ваш адрес email не будет опубликован.

5 + пять =

Top.Mail.Ru