Как написать бизнес-требования? Бизнес-специалисту – как разговаривать на одном языке с ИТ

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

Евгений: "Правильно было бы назвать книгу "Шаблон документа «Спецификация бизнес-требований». Шаблон БТ за 300руб дороговато будет, если в сети можно найти бесплатно, и кроме того в каждой организации, где есть ИТ-департамент, скорее всего будет своя база шаблонов документов. И бизнес-аналитик, готовя спецификацию БТ, будет писать ее именно в шаблоне заказчика. Чаще всего. А не придумывать самому.

Юрий: Соглашусь, что для бизнес-аналитика ИТ-департамента, вооруженного опытом и проработанным набором шаблонов в рамках корпорации, данная книга вряд ли будет полезна как шаблон. Она ориентирована прежде всего на тех, кому время от времени нужно писать бизнес-требования, но это не является их основной профессиональной деятельностью. Таких людей много, и название «Как написать бизнес-требования? Бизнес-специалисту – как разговаривать на одном языке с ИТ» адресуется, прежде всего, им. Во введении сделан тот же акцент «Вы функциональный специалист бизнеса и решили автоматизировать свой бизнес-процесс? Вы уже делали это и знаете по собственному опыту, как порой нелегко донести до разработчика свои потребности?».

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

Евгений: жизненный цикл требования описан неправильно. У требования нет зрелости и отмирания. Это неуместные метафоры, не имеющие к требованиям ПО никакого отношения.

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

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

Юрий: Да, выделение понятия гибкости (в гл.4 «Еще одним способом создания избыточности является „гибкость“ – попытка предусмотреть и реализовать сразу все возможные в будущем … сценарии использования, а также предусмотреть несколько способов реализации каждой функции…») обусловлено желанием автора выделить этот случай, довольно часто встречающийся в практике, и обратить внимание на его негативные последствия. Понятие «избыточности» шире – это «наличие требований, которые прямо не связанны с достижением бизнес-цели.» (гл.4)

Евгений: «Странно, зачем реализовывать то, то что может быть исключено?»

Юрий: Исключение части функций – вынужденная мера, применяемая лишь тогда, когда «возникают ситуации, требующие на решение поставленных задач больше времени и ресурсов, чем казалось вначале. Это приводит к тому, что реализовать все требования в срок не получается.» и исключение – один из вариантов, но есть и другие: «Вариантов немного – увеличивать сроки и ресурсы на реализацию или уменьшать объем реализуемых функций. Можно и то, и другое вместе.» (гл.4).

Евгений: Часть вопросов не должен решать бизнес-аналитик, он их должен обсудить обязательно с архитектором(-ам) и ведущим разработчиком (тимлидом), и при наличии появившвихся ограничений или невозможности их реализовать идти к менеджеру проекта. Это не описано, а важно!

Юрий: Совершенно верно! Только до того, как все эти люди появятся в проекте, часто на стороне бизнеса идет подготовительная работа, к которой никто из них не привлекается. В результате формируется документ, суть которого сводится к тому, что «мы, бизнес, хотим автоматизировать вот это и мы себе это представляем вот так». Далеко не всегда есть формализованная процедура, база шаблонов и квалификация бизнес-специалистов, чтобы сделать это полностью и качественно, а ресурсов и времени не хватает почти всегда. Цель книги – помочь пройти этот начальный этап максимально продуктивно до того, как команда проекта вступит в дело. Также требования «не по бизнесу», имеющиеся в приведенном в части III шаблоне, позволяют задуматься и задать правильные вопросы всем названным людям для их решения.

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

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