Требования VS не-требования, или где кончается аналитик

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

Картина того, чем конкретно должен заниматься IT бизнес-аналитик на проектах, «радует» своей несогласованностью, если смотреть на это в глобальном масштабе. В этом легко убедиться по любой случайной выборке вакансий, особенно в разных регионах. А можно сюда добавить еще и роли, которые вроде как и синонимы, но не совсем: системный аналитик, product owner, аналитик требований и пр.
IIBA (International Institute of Business Analysis), стандартизаторы БА, назвали всю эту ватагу бизнес-аналитиками и абстрагировали область деятельности БА в вакууме до максимума (анализ потребностей организаций и выработка решений), подразумевая, что им является как человек, занимающийся сугубо написанием юзер сторей, так и бизнес-архитектор, решающий краеугольные задачи бизнеса. К слову, комбинацию «бизнес- и системный аналитик», популярную как минимум в РФ, я не воспринимаю как оптимальную (коснусь этого далее), а потому подход IIBA, учитывая к тому же, что он существенно более широко распространен, мне значительно ближе. Т. е. есть БА, который = тому, что описано выше, и если его плоскость решений — это IT (одна из perspective по BABOK от IIBA), то перед нами IT БА — роль, суть которой в том, чтобы помочь выработать IT-решение в ответ на потребности организации. Широта этой формулировки оставляет весомый простор для толкования, даже после сужения области решений до IT, но традиционно IT БА — это роль, нацеленная на проработку требований к выбранному решению. «Традиционно» означает, что вам все еще нужно внимательно смотреть на описанное в вакансиях, даже если там используется термин IT БА в явном виде, ибо фокус в конкретном месте работы может быть любым по шкале от анализа деятельности организации до написания требований к IT-решению — а шкала эта ой как широка. Повторюсь, что чаще всего этот фокус — на требованиях. Просто для того, чтобы к ним дойти, надо иногда и в организацию, и в стейкхолдеров активно копнуть. И получается, что если мы поймем, что является требованиями, а что ими не является (не всегда это однозначно ясно, особенно для начинающих), поможет нам это в следующем:

Надеюсь, к этому моменту понятно следующее:

а) БА страдает от разночтения работодателями по всему миру.

б) Чаще всего под IT БА понимают человека, конечный фокус которого — на проработке требований к IT-решению.

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

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

BABOK v.3 (IIBA):

Пригодная к использованию формулировка потребности? Абстрактненько, но для старта сойдет. Т. е. у кого-то/чего-то есть потребность в чем-то, и формулировка ее и есть требование. Оставим пока так.

CPRE Glossary of Requirements Engineering Terminology (International Requirements Engineering Board) v. 1.0.0

Тут же сразу приведу еще один набор определений, т. к. они схожи:

IEEE Standard Glossary of Software Engineering Terminology (Institute of Electrical and Electronics Engineers):

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

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

Мы с вами знаем, что требования бывают разных видов. Я не буду погружаться в разные их классификации (у нас, кстати, есть пара видео на эту тему, пусть и не полностью покрывающие все виды требований: https://www.youtube.com/watch?v=Xfmid0muueo и https://www.youtube.com/watch?v=4hU3CAkFJsQ), но приведу тут для справки саму схему требований к ПО (помним, что у нас речь идет про плоскость IT-решений, да?), которая является комбинацией схем по BABOK, теории Вигерса и собственных доработок/исправлений:

Если мы возьмем первую часть определений, то A need perceived by a stakeholder — это что-то, что отражает потребность ЗЛ. Я рекомендую все же разделять термины «потребность» и «требование», и об этом в первом из видео выше мы подробно говорим. Но несмотря на это, если смотреть на требование как на выражение потребности ЗЛ, то сюда отлично ложатся бизнес-требования (что нужно организации или спонсору от лица организации — цели касательно текущего изменения, change, помочь в котором прилетел бизнес-аналитик), например «Сократить издержки на документооборот на 20% в течение месяца». Сюда также отлично ложится следующий уровень — требования ЗЛ (что нужно всем релевантным ЗЛ для достижения бизнес-требований организации): например, секретарю Маше нужно «иметь возможность создавать документы в электронном формате»и «чтобы процесс создания документов шел быстро».

Вторая часть определений касается иного вида требований — третьего их уровня. A capability or property that a system shall have. Когда мы говорим о том, что что-то должно быть в системе, мы а) прошли процесс определения решения, т. е. рассмотрели, какие варианты IT-решений есть (IT, опять-таки, потому что мы IT БА, но вообще решением может быть все, что угодно: изменения в бизнес-процессах, структуре организации, должностных обязанностях и пр.) и остановились на сочтенном оптимальным. И теперь, зная, например, что решение — это разработка с нуля и внедрение веб-системы электронного документооборота, мы можем оперировать второй частью определения (и третьим видом требований по порядку в иерархии) — требованиями к решению: это что-то, что должно быть заложено в систему, ее функциональная возможность или свойство.

Что еще полезного касательно требований мы можем почерпнуть из BABOK? Мне очень импонирует такое понятие оттуда, как Business analysis information. Основное, на что делается упор в связи с этим термином, это то, что аналитик работает не только с требованиями, что естественно. Через него проходят пласты информации, и та часть, которая ценна в контексте его задач, это business analysis information — информация, которая поможет бизнес-анализу на проекте.

Что из этого нужно вынести:

а) Кроме требований аналитик работает с морем иной информации (например, описание AS IS ситуации — назвать описание текущих процессов, лиц в домене или недостатков текущей системы требованиями язык не повернется; требования направлены в TO BE).

б) Частью этой информации являются требования.

в) Требования — наиболее ценная часть информации по бизнес-анализу, т. к., как мы ранее описали, в проработке требований и заключается фокус работы БА.

При этом, учитывая, что кроме business analysis information в проекте есть и иная information, все эти informations можно примерно так показать на схеме:

Что ключевое видится на картинке:

а) Описанные выше понятия Business analysis information и Требования, плюс их отношение друг к другу.

б) Факт того, что есть и иные "информации":

• Проектная информация — то, что является епархией проектного менеджера или того, кто де факто выполняет его роль. Тут важно понять, что фокус аналитика — целевое решение, а не проект по его разработке. Аналитик отвечает за четкое понимание того, каким должно быть целевое решение в плане его функционального и нефункционального наполнения. За мероприятия по воплощению этого решения в жизнь (проект) отвечает PM — сроки, бюджеты, команда, ресурсы, процессы и пр.
• Designs — это "конструкторские" аспекты решения. Т. е. то, как будет вестись разработка решения по требованиям, поставленным БА. Сюда входят принятые "разработческие" решения: стек технологий, архитектура, правила написания кода, структура базы данных и т. п. Грубо говоря, это технические детали реализации решения.
• Всякое прочее — например, у тестировщиков тоже, вестимо, есть своя информационная база и область принятия решений.

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

Начнем с того, что представим идеально четкий проектный процесс, в котором есть все типовые проектные роли, каждая роль имеет однозначно очерченные границы работ и ответственности и они не пересекаются. Тут не идет речь о том, что это идеальный в плане эффективности процесс — разработка развивается в сторону все более тесного взаимодействия и совместной работы участников, что правильно. Тем не менее, как я уже писал в начале, для старта подобная четкость нужна — а дальше уже зрелые специалисты нащупают, где и как совместно поработать или даже подменить друг друга. В таком вот сферически-вакуумном процессе аналитик — это требования и тот путь, который нужно пройти до их выработки, проектный менеджер — общий контроль всех на проекте по разработке решения по требованиям аналитика, разработчики и их вариации (архитектор, front-end, back-end, DBA, билд-инженеры и пр.) — это designs (технические аспекты решения), тестировщики — контроль качества решения.

Если взять картинку выше за основу, то все выглядит четко. Проблемы тут две:

1) Не все работодатели считают, что это "правильное" разделение ролей. Например, в картинке, где есть бизнес- и системные аналитики (как я уже писал, подобное популярно в РФ и отчасти в ряде смежных регионов), бизнес-аналитик — это тот, кто отвечает за частичку работ из области IT БА, которых я описывал выше — ту часть, которая идет примерно до требований к решению (т. е. отвечает за первые два уровня требований). Системный же аналитик — за требования к решению, плюс, что интересно, за часть designs — т. е. выполняет частично работу разработчиков — как правило, если мне не изменяет понимание, это архитектурные вопросы. И есть ощущение, что без "договариваться на лету" системному аналитику весьма сложно обособить себя от разработчиков.

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

2) Не все умеют/знают, плюс не всегда видится возможным четко понять, что перед нами: требования, проектная информация или designs. И это может вызывать вопросы, наиболее частые из которых — "Почему я отвечаю за это, если это работа других?" и "Почему ты сделал мою работу и думаешь за меня?"

Если брать за основу тезис о том, что как аналитик я отвечаю за требования и на требованиях заканчивается моя дефолтная граница работ, то мне нужно иметь точное понимание, где начинаются и кончаются требования. Несложно понять, что начинаются они (в идеале) с уровня бизнес-требований, а вот где остановиться, чтобы не залезть в область проекта или технические детали (designs)? Сложность в том, что "A capability or property that a system shall have" не дает нам черно-белого ответа на этот вопрос. Например, структура базы данных системы — это разве не property системы, и, как следствие, не требования? Кусок кода — это не property системы?

Тут я рекомендую присовокупить к определению известную нам классификацию требований и понять, что требования к решению (которые и составляют определение выше) бывают функциональными и нефункциональными, плюс сюда еще можно отнести transition requirements. Понимая каждый из этих видов требований — что они собой представляют и что в них входит — станет легче понять, где остановиться, дабы не лезть в не-требования. Функциональные требования — это функциональные возможности и поведение системы в их рамках, плюс информация, которой это поведение оперирует. Нефункциональные требования — это прочие аспекты, которые характеризуют функциональные требования, и в первую очередь — качественные характеристики (надежность, безопасность, производительность, удобство и пр.). Т. е. тут важно понять, что требования к решению, за редкими исключениями — это полезные для ЗЛ характеристики решения, касающиеся поведения и качеств решения в рабочем состоянии, т. е. каким должно быть с позиции взгляда X (поведение, информация, качества и пр.) решение в его рабочем и приносящем ценность стейкхолдерам варианте. Структура базы данных — это не полезная/ценная для ЗЛ характеристика решения. Это строительный компонент, который видят только ЗЛ со стороны разработки в рамках процесса разработки. И именно это должно отграничивать эту самую базу данных от фокуса работа БА и переносить ее в руки "строителей" — представителей разработки.

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

Отделить требования от технических деталей решения может статься более сложным, но давайте прощупаем. Помимо концепции "полезняшки рабочего решения VS аспекты разработки" или "что" vs "как", может помочь еще одна размышлялка: есть ли среди иных проектных ролей кто-то, кто более компетентен в вопросной области и заточен под работу с ней? Если да, то скорее всего речь идет о деталях реализации, раз выделен реализатор под подобного рода вопросы. Если нет, то надо, как и в случаях выше, договариваться. Примеры:

В общем, такая вот картина. Буду рад комментариям (например, в канале — https://t.me/itmineba), т. к. понимаю прекрасно, что у кого-то расстановка ролей может не так сильно зависеть от концепции требований. В особенности интересно будет услышать обоснования, почему оно так, и ощущения от того, удачно ли работает иная принятая картина.