Поговорим о требованиях и о том, зачем стоит их понимать и отделять от остальной проектной информации. На первый взгляд это может показаться философией теории ради, однако я попытаюсь донести мысль о том, что практически это также полезно, особенно если страдает понимание пласта работы IT-аналитика (что наблюдается нередко). И начнем издалека.
Картина того, чем конкретно должен заниматься IT бизнес-аналитик на проектах, «радует» своей несогласованностью, если смотреть на это в глобальном масштабе. В этом легко убедиться по любой случайной выборке вакансий, особенно в разных регионах. А можно сюда добавить еще и роли, которые вроде как и синонимы, но не совсем: системный аналитик, product owner, аналитик требований и пр.
IIBA (International Institute of Business Analysis), стандартизаторы БА, назвали всю эту ватагу бизнес-аналитиками и абстрагировали область деятельности БА в вакууме до максимума (анализ потребностей организаций и выработка решений), подразумевая, что им является как человек, занимающийся сугубо написанием юзер сторей, так и бизнес-архитектор, решающий краеугольные задачи бизнеса. К слову, комбинацию «бизнес- и системный аналитик», популярную как минимум в РФ, я не воспринимаю как оптимальную (коснусь этого далее), а потому подход IIBA, учитывая к тому же, что он существенно более широко распространен, мне значительно ближе. Т. е. есть БА, который = тому, что описано выше, и если его плоскость решений — это IT (одна из perspective по BABOK от IIBA), то перед нами IT БА — роль, суть которой в том, чтобы помочь выработать IT-решение в ответ на потребности организации. Широта этой формулировки оставляет весомый простор для толкования, даже после сужения области решений до IT, но традиционно IT БА — это роль, нацеленная на проработку требований к выбранному решению. «Традиционно» означает, что вам все еще нужно внимательно смотреть на описанное в вакансиях, даже если там используется термин IT БА в явном виде, ибо фокус в конкретном месте работы может быть любым по шкале от анализа деятельности организации до написания требований к IT-решению — а шкала эта ой как широка. Повторюсь, что чаще всего этот фокус — на требованиях. Просто для того, чтобы к ним дойти, надо иногда и в организацию, и в стейкхолдеров активно копнуть. И получается, что если мы поймем, что является требованиями, а что ими не является (не всегда это однозначно ясно, особенно для начинающих), поможет нам это в следующем:
Картина того, чем конкретно должен заниматься IT бизнес-аналитик на проектах, «радует» своей несогласованностью, если смотреть на это в глобальном масштабе. В этом легко убедиться по любой случайной выборке вакансий, особенно в разных регионах. А можно сюда добавить еще и роли, которые вроде как и синонимы, но не совсем: системный аналитик, product owner, аналитик требований и пр.
IIBA (International Institute of Business Analysis), стандартизаторы БА, назвали всю эту ватагу бизнес-аналитиками и абстрагировали область деятельности БА в вакууме до максимума (анализ потребностей организаций и выработка решений), подразумевая, что им является как человек, занимающийся сугубо написанием юзер сторей, так и бизнес-архитектор, решающий краеугольные задачи бизнеса. К слову, комбинацию «бизнес- и системный аналитик», популярную как минимум в РФ, я не воспринимаю как оптимальную (коснусь этого далее), а потому подход IIBA, учитывая к тому же, что он существенно более широко распространен, мне значительно ближе. Т. е. есть БА, который = тому, что описано выше, и если его плоскость решений — это IT (одна из perspective по BABOK от IIBA), то перед нами IT БА — роль, суть которой в том, чтобы помочь выработать IT-решение в ответ на потребности организации. Широта этой формулировки оставляет весомый простор для толкования, даже после сужения области решений до IT, но традиционно IT БА — это роль, нацеленная на проработку требований к выбранному решению. «Традиционно» означает, что вам все еще нужно внимательно смотреть на описанное в вакансиях, даже если там используется термин IT БА в явном виде, ибо фокус в конкретном месте работы может быть любым по шкале от анализа деятельности организации до написания требований к IT-решению — а шкала эта ой как широка. Повторюсь, что чаще всего этот фокус — на требованиях. Просто для того, чтобы к ним дойти, надо иногда и в организацию, и в стейкхолдеров активно копнуть. И получается, что если мы поймем, что является требованиями, а что ими не является (не всегда это однозначно ясно, особенно для начинающих), поможет нам это в следующем:
- Аналитики смогут понять, что будет являться их главной задачей в большинстве мест, где требуется IT бизнес-аналитик. И тут поясню пару условностей. Во-первых, если это не противоречит тому, что от вас априори ожидают на рабочем месте. При этом весьма часто на рабочем месте не знают, чего от вас ожидать: чтобы понимать, где кончается аналитик и начинаются другие люди, нужно иметь зрелые и понятные процессы, а это не всегда так. Вас могут взять на работу и сказать «Твори свою магию», и процессы вокруг себя придется вырабатывать самому — тут, кстати, и пригодится описанное в этой заметке. Во-вторых, не отрицаю того, что сферы деятельности проектных ролей не обязаны быть резко разграниченными: коллаборация нескольких ролей над чем-то — штука отличная, и я во многом поддерживаю тезис «всегда можно договориться о том, кто что делает». Однако это должно именно что быть ситуативным. Это не должно быть основой ежедневного процесса. Стартовый фокус и понимание своей работы и зон ответственности должны быть.
- Рекрутеры и конструкторы проектных процессов смогут понять и, вероятно, принять, за что должен отвечать IT БА (и чего с него спрашивать не стоит). Как и любая иная роль, БА — это специализация, вынесение части проектных работ в отдельную компетенцию, дабы не ломать этим мозг тем, у кого иной фокус. И если, например, БА, которого вы берете, занимается проектированием баз данных (как и ваши разработчики, DBA или архитекторы), то, спрашивается, зачем вы выносите подобное из рук тех, кто умеет и заточен изначально под эту задачу, в руки тех, кто по скиллам и типу работ должен делать совсем иное?
Надеюсь, к этому моменту понятно следующее:
а) БА страдает от разночтения работодателями по всему миру.
б) Чаще всего под IT БА понимают человека, конечный фокус которого — на проработке требований к IT-решению.
в) Поняв, что такое требования и что ими не является, мы (аналитики, рекрутеры и менеджеры) лучше поймем, где оставить зону ответственности БА, а где — отдать другим людям.
а) БА страдает от разночтения работодателями по всему миру.
б) Чаще всего под IT БА понимают человека, конечный фокус которого — на проработке требований к IT-решению.
в) Поняв, что такое требования и что ими не является, мы (аналитики, рекрутеры и менеджеры) лучше поймем, где оставить зону ответственности БА, а где — отдать другим людям.
Давайте рассмотрим для начала, что такое требования. Возьмем различные определения и попытаемся разобрать:
BABOK v.3 (IIBA):
BABOK v.3 (IIBA):
A usable representation of a need
Пригодная к использованию формулировка потребности? Абстрактненько, но для старта сойдет. Т. е. у кого-то/чего-то есть потребность в чем-то, и формулировка ее и есть требование. Оставим пока так.
CPRE Glossary of Requirements Engineering Terminology (International Requirements Engineering Board) v. 1.0.0
- A need perceived by a stakeholder.
- A capability or property that a system shall have.
- A documented representation of a need, capability, or property.
Тут же сразу приведу еще один набор определений, т. к. они схожи:
IEEE Standard Glossary of Software Engineering Terminology (Institute of Electrical and Electronics Engineers):
1. A condition or capability needed by a user to solve a problem or achieve an objective
2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document
3. A documented representation of a condition or capability as in 1 or 2
Давайте посмотрим на значимую для нас разницу. В первом пункте user (IEEE) расширено до stakeholder (IREB), что замечательно — требования могут быть не только у тех, кто будет непосредственно пользоваться решением. В целом, первый и второй пункты — это отличные формулировки для понимания того, что такое требования, но давайте полирнем это Карлом Вигерсом (его труды — не стандарт, но де факто признаны «библией», а потому не будем игнорировать):
Software Requirements, 3rd edition, Karl Wiegers and Joy Beatty
A statement of a customer need or objective, or of a condition or capability that a product must possess to satisfy such a need or objective. A property that a product must have to provide value to a stakeholder.
Фактически это то же самое, что и предыдущие два определения, а потому разберем их все в связке чуть детальнее.
Мы с вами знаем, что требования бывают разных видов. Я не буду погружаться в разные их классификации (у нас, кстати, есть пара видео на эту тему, пусть и не полностью покрывающие все виды требований: https://www.youtube.com/watch?v=Xfmid0muueo и https://www.youtube.com/watch?v=4hU3CAkFJsQ), но приведу тут для справки саму схему требований к ПО (помним, что у нас речь идет про плоскость IT-решений, да?), которая является комбинацией схем по BABOK, теории Вигерса и собственных доработок/исправлений:
Мы с вами знаем, что требования бывают разных видов. Я не буду погружаться в разные их классификации (у нас, кстати, есть пара видео на эту тему, пусть и не полностью покрывающие все виды требований: 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 — информация, которая поможет бизнес-анализу на проекте.
Business analysis information refers to the broad and diverse sets of information that business analysts analyze, transform, and report.
Examples of business analysis information include elicitation results, requirements, designs, solution options, solution scope, and change strategy.
Что из этого нужно вынести:
а) Кроме требований аналитик работает с морем иной информации (например, описание AS IS ситуации — назвать описание текущих процессов, лиц в домене или недостатков текущей системы требованиями язык не повернется; требования направлены в TO BE).
б) Частью этой информации являются требования.
в) Требования — наиболее ценная часть информации по бизнес-анализу, т. к., как мы ранее описали, в проработке требований и заключается фокус работы БА.
При этом, учитывая, что кроме business analysis information в проекте есть и иная information, все эти informations можно примерно так показать на схеме:
а) Кроме требований аналитик работает с морем иной информации (например, описание AS IS ситуации — назвать описание текущих процессов, лиц в домене или недостатков текущей системы требованиями язык не повернется; требования направлены в TO BE).
б) Частью этой информации являются требования.
в) Требования — наиболее ценная часть информации по бизнес-анализу, т. к., как мы ранее описали, в проработке требований и заключается фокус работы БА.
При этом, учитывая, что кроме business analysis information в проекте есть и иная information, все эти informations можно примерно так показать на схеме:
Что ключевое видится на картинке:
а) Описанные выше понятия Business analysis information и Требования, плюс их отношение друг к другу.
б) Факт того, что есть и иные "информации":
в) Связь между Требованиями и смежной информацией (проектной и технической). Как видите, связь нечеткая — области пересекаются. Это и является сложностью в отделении требований от не-требований со всеми вытекающими влияниями на описанное в начале заметки. Это мы и попытаемся далее разобрать.
а) Описанные выше понятия Business analysis information и Требования, плюс их отношение друг к другу.
б) Факт того, что есть и иные "информации":
- Проектная информация — то, что является епархией проектного менеджера или того, кто де факто выполняет его роль. Тут важно понять, что фокус аналитика — целевое решение, а не проект по его разработке. Аналитик отвечает за четкое понимание того, каким должно быть целевое решение в плане его функционального и нефункционального наполнения. За мероприятия по воплощению этого решения в жизнь (проект) отвечает PM — сроки, бюджеты, команда, ресурсы, процессы и пр.
- Designs — это "конструкторские" аспекты решения. Т. е. то, как будет вестись разработка решения по требованиям, поставленным БА. Сюда входят принятые "разработческие" решения: стек технологий, архитектура, правила написания кода, структура базы данных и т. п. Грубо говоря, это технические детали реализации решения.
- Всякое прочее — например, у тестировщиков тоже, вестимо, есть своя информационная база и область принятия решений.
в) Связь между Требованиями и смежной информацией (проектной и технической). Как видите, связь нечеткая — области пересекаются. Это и является сложностью в отделении требований от не-требований со всеми вытекающими влияниями на описанное в начале заметки. Это мы и попытаемся далее разобрать.
Начнем с того, что представим идеально четкий проектный процесс, в котором есть все типовые проектные роли, каждая роль имеет однозначно очерченные границы работ и ответственности и они не пересекаются. Тут не идет речь о том, что это идеальный в плане эффективности процесс — разработка развивается в сторону все более тесного взаимодействия и совместной работы участников, что правильно. Тем не менее, как я уже писал в начале, для старта подобная четкость нужна — а дальше уже зрелые специалисты нащупают, где и как совместно поработать или даже подменить друг друга. В таком вот сферически-вакуумном процессе аналитик — это требования и тот путь, который нужно пройти до их выработки, проектный менеджер — общий контроль всех на проекте по разработке решения по требованиям аналитика, разработчики и их вариации (архитектор, front-end, back-end, DBA, билд-инженеры и пр.) — это designs (технические аспекты решения), тестировщики — контроль качества решения.
Если взять картинку выше за основу, то все выглядит четко. Проблемы тут две:
1) Не все работодатели считают, что это "правильное" разделение ролей. Например, в картинке, где есть бизнес- и системные аналитики (как я уже писал, подобное популярно в РФ и отчасти в ряде смежных регионов), бизнес-аналитик — это тот, кто отвечает за частичку работ из области IT БА, которых я описывал выше — ту часть, которая идет примерно до требований к решению (т. е. отвечает за первые два уровня требований). Системный же аналитик — за требования к решению, плюс, что интересно, за часть designs — т. е. выполняет частично работу разработчиков — как правило, если мне не изменяет понимание, это архитектурные вопросы. И есть ощущение, что без "договариваться на лету" системному аналитику весьма сложно обособить себя от разработчиков.
Тем не менее, в усредненном варианте с наличием IT БА, который не дробится на подвиды, описанное выше разделение ролей я рекомендую взять за первый практический гайдлайн из этой заметки — при наличии всех упомянутых ключевых ролей схема работает отлично, и это либо то, что нужно понять в плане ожидаемых от нас зон ответственности, либо выработать подобное при их отсутствии, если есть такая возможность.
Если взять картинку выше за основу, то все выглядит четко. Проблемы тут две:
1) Не все работодатели считают, что это "правильное" разделение ролей. Например, в картинке, где есть бизнес- и системные аналитики (как я уже писал, подобное популярно в РФ и отчасти в ряде смежных регионов), бизнес-аналитик — это тот, кто отвечает за частичку работ из области IT БА, которых я описывал выше — ту часть, которая идет примерно до требований к решению (т. е. отвечает за первые два уровня требований). Системный же аналитик — за требования к решению, плюс, что интересно, за часть designs — т. е. выполняет частично работу разработчиков — как правило, если мне не изменяет понимание, это архитектурные вопросы. И есть ощущение, что без "договариваться на лету" системному аналитику весьма сложно обособить себя от разработчиков.
Тем не менее, в усредненном варианте с наличием IT БА, который не дробится на подвиды, описанное выше разделение ролей я рекомендую взять за первый практический гайдлайн из этой заметки — при наличии всех упомянутых ключевых ролей схема работает отлично, и это либо то, что нужно понять в плане ожидаемых от нас зон ответственности, либо выработать подобное при их отсутствии, если есть такая возможность.
2) Не все умеют/знают, плюс не всегда видится возможным четко понять, что перед нами: требования, проектная информация или designs. И это может вызывать вопросы, наиболее частые из которых — "Почему я отвечаю за это, если это работа других?" и "Почему ты сделал мою работу и думаешь за меня?"
Если брать за основу тезис о том, что как аналитик я отвечаю за требования и на требованиях заканчивается моя дефолтная граница работ, то мне нужно иметь точное понимание, где начинаются и кончаются требования. Несложно понять, что начинаются они (в идеале) с уровня бизнес-требований, а вот где остановиться, чтобы не залезть в область проекта или технические детали (designs)? Сложность в том, что "A capability or property that a system shall have" не дает нам черно-белого ответа на этот вопрос. Например, структура базы данных системы — это разве не property системы, и, как следствие, не требования? Кусок кода — это не property системы?
Тут я рекомендую присовокупить к определению известную нам классификацию требований и понять, что требования к решению (которые и составляют определение выше) бывают функциональными и нефункциональными, плюс сюда еще можно отнести transition requirements. Понимая каждый из этих видов требований — что они собой представляют и что в них входит — станет легче понять, где остановиться, дабы не лезть в не-требования. Функциональные требования — это функциональные возможности и поведение системы в их рамках, плюс информация, которой это поведение оперирует. Нефункциональные требования — это прочие аспекты, которые характеризуют функциональные требования, и в первую очередь — качественные характеристики (надежность, безопасность, производительность, удобство и пр.). Т. е. тут важно понять, что требования к решению, за редкими исключениями — это полезные для ЗЛ характеристики решения, касающиеся поведения и качеств решения в рабочем состоянии, т. е. каким должно быть с позиции взгляда X (поведение, информация, качества и пр.) решение в его рабочем и приносящем ценность стейкхолдерам варианте. Структура базы данных — это не полезная/ценная для ЗЛ характеристика решения. Это строительный компонент, который видят только ЗЛ со стороны разработки в рамках процесса разработки. И именно это должно отграничивать эту самую базу данных от фокуса работа БА и переносить ее в руки "строителей" — представителей разработки.
Если брать за основу тезис о том, что как аналитик я отвечаю за требования и на требованиях заканчивается моя дефолтная граница работ, то мне нужно иметь точное понимание, где начинаются и кончаются требования. Несложно понять, что начинаются они (в идеале) с уровня бизнес-требований, а вот где остановиться, чтобы не залезть в область проекта или технические детали (designs)? Сложность в том, что "A capability or property that a system shall have" не дает нам черно-белого ответа на этот вопрос. Например, структура базы данных системы — это разве не property системы, и, как следствие, не требования? Кусок кода — это не property системы?
Тут я рекомендую присовокупить к определению известную нам классификацию требований и понять, что требования к решению (которые и составляют определение выше) бывают функциональными и нефункциональными, плюс сюда еще можно отнести transition requirements. Понимая каждый из этих видов требований — что они собой представляют и что в них входит — станет легче понять, где остановиться, дабы не лезть в не-требования. Функциональные требования — это функциональные возможности и поведение системы в их рамках, плюс информация, которой это поведение оперирует. Нефункциональные требования — это прочие аспекты, которые характеризуют функциональные требования, и в первую очередь — качественные характеристики (надежность, безопасность, производительность, удобство и пр.). Т. е. тут важно понять, что требования к решению, за редкими исключениями — это полезные для ЗЛ характеристики решения, касающиеся поведения и качеств решения в рабочем состоянии, т. е. каким должно быть с позиции взгляда X (поведение, информация, качества и пр.) решение в его рабочем и приносящем ценность стейкхолдерам варианте. Структура базы данных — это не полезная/ценная для ЗЛ характеристика решения. Это строительный компонент, который видят только ЗЛ со стороны разработки в рамках процесса разработки. И именно это должно отграничивать эту самую базу данных от фокуса работа БА и переносить ее в руки "строителей" — представителей разработки.
Отделить требования от проектной информации, в целом, несложно: требования характеризуют целевое решение, проектная информация — проект по его разработке. На примерах с комментариями:
Отделить требования от технических деталей решения может статься более сложным, но давайте прощупаем. Помимо концепции "полезняшки рабочего решения VS аспекты разработки" или "что" vs "как", может помочь еще одна размышлялка: есть ли среди иных проектных ролей кто-то, кто более компетентен в вопросной области и заточен под работу с ней? Если да, то скорее всего речь идет о деталях реализации, раз выделен реализатор под подобного рода вопросы. Если нет, то надо, как и в случаях выше, договариваться. Примеры:
В общем, такая вот картина. Буду рад комментариям (например, в канале — https://t.me/itmineba), т. к. понимаю прекрасно, что у кого-то расстановка ролей может не так сильно зависеть от концепции требований. В особенности интересно будет услышать обоснования, почему оно так, и ощущения от того, удачно ли работает иная принятая картина.
