Бизнес-аналитик в гибкой методологии разработки Agile?
Роль бизнес-аналитика (БА, англ. — BA) в проектах Agile в некотором смысле сходна с ролью проектного менеджера (ПМ, англ. — PM). При этом некоторые люди считают эти роли совсем ненужными! Например, руководство по практическому применению Agile-методов Scrum Guide, где излагается суть подхода Scrum («скрам»), описывает только три роли: скрам-мастер, владелец продукта и команда разработчиков. Даже в случае, когда вы изучаете в описании Scram Guide роль команды разработчиков, не говоря уже об аналитиках или аналитической работе. Однако, большинство организаций согласны с тем, что хорошие бизнес-аналитики являются ценным активом для любой команды, будь он запланированный, маневренный или гибридный.
В этой статье подразумевается, что БА, действительно, проверяет то, что остается неизменным в Agile-проекте и то, что меняется. Говоря вкратце — По какой причине и Какие именно основы остаются теми же, и какие детали кардинально меняются (Каким образом, Когда, Где, С Кем).
Давайте начнем с того, Что должны делать бизнес-аналитики. (Я имею в виду — должны делать, а не действительно делают, так как они могут смотреть видео-приколы с кошками большую часть рабочего времени. Это – не занятие во время работы!) В любом случае, бизнес-аналитики выявляют, анализируют, взаимодействуют, управляют и проверяют необходимые условия. Также они помогают понять бизнес и обеспечивают решения, подходящие этому бизнесу. Кроме того, они помогают переводить технические вопросы в бизнес и поддерживать связи с заинтересованными сторонами.
Причина, по которой они делают эти вещи, должна быть достаточно очевидной: чтобы помочь обеспечить создание проектом нужного продукта, а также не пропустить информацию и понять требования заказчика. Также они являются ценными помощниками в продвижении и преодолении барьеров в коммуникациях между клиентом, заказчиком и технической группой.
Важным аспектом является тот факт, что все эти функции, роли, потребности или то, что вы хотите назвать, по-прежнему существуют на Agile-проектах. Кроме того — в некоторой степени – из-за того, что гибкие сроки нередко сжимаются, эти функции становятся более важными для команды, чтобы оставаться продуктивной и профессиональной, так что хорошие бизнес-аналитики бесценны.
Теперь о характере изменений. Давайте начнем с вопроса «Как?». Команды Agile, как правило, не создают большие, детализированные требования к документам, которые были рассмотрены и утверждены до начала серьезной разработки. Наоборот, требования могут быть зафиксированы в качестве истории пользователя, или на учетных карточках, которые выступают, как напоминание пойти и поговорить со специалистом по соответствующей теме до развития. Они, как правило, меньше по объему в отношении охватываемого ими масштаба и глубины описания. Больше похожи на микро-требования к невнимательным читателям, которые хотят видеть только небольшие, размером с бит, компоненты информации.
Такая зернистая структура фактически обеспечивает большее количество возможностей для перемещения и изменения приоритетов в накопленной базе знаний. Люди также имеют тенденцию давать более точную оценку и более детально проверять результат. Однако это увеличивает количество элементов управления, а бизнес-аналитики могут помочь в управлении и визуализации главной картины проблемы, являющейся особенно ценной. Переход к более «визуальным и вербальным» форматам часто возникает на Agile-проектах. Больше нет огромного количества письменной информации. Напротив, доски задач и совместные знания, полученные в процессе взаимодействия команд и работы в совмещенных пространствах, являются нормой.
Когда потребности выявлены, проанализированы, доведены, управляемы, и также подтверждена перемена, больше не существует фазы проекта, посвященной в основном выявлению и пониманию большинства требований. Теперь гораздо меньше подтверждений требований со знаком офф до начала работы. Вместо этого, они точно в срок собраны из всего проекта, для работы с ними программистов, и в том виде, в котором они появляются, начиная от демонстрации клиентам и планирования сессий. БА должны сохранять внимательность, получая потенциальный материал из вопросов клиентов. Важным аспектом является роль владельца продукта, помогающего фильтровать существенную информацию от ненужной, а затем назначать приоритеты для развития.
Вопрос «Где работать?», как правило, также претерпевает изменения в гибких Agile-проектах. У БА появляется меньшее количество выделенного рабочего пространства, а больше открытой командной работы. Процесс может быть долгим, кропотливым и сфокусированным на больших, более сложных документах, но такие условия хороши для уточнения деталей и охвата всего материала. Команды Agile в большей степени опираются на очное общение, которое более быстрое, дает возможность анкетирования и выявления проблем более эффективно, а также более легко передает язык тела и эмоции.
Многие Agile-команды состоят из одного или нескольких распределенных членов команд. Таким образом, каждый должен получить соответствующую ему область работы с онлайн-инструментами взаимодействия. Условия, как правило, содержатся в онлайн-хранилищах, доступных заинтересованным сторонам отовсюду. Адаптивность и готовность для БА попробовать, а затем освоить эти инструменты, очень важна для них, чтобы оставаться компетентными и добавить ценности команде.
Наконец, вопрос «С кем?». БА по-прежнему играет важную роль связиста или транслятора между клиентами, переводчиками и техническими ресурсами, но опять же, роль меняется. Команды разработки Agile способны быть обобщающими специалистами с более широким набором навыков, включая бизнес-переговоры и сбор требований. Это играет напрямую на традиционную территорию бизнес-аналитика, но БА по-прежнему ценны, если они выступают в качестве посредников в этой работе. Возможно, фокусирование своего времени на более важном взаимодействии с заинтересованными сторонами (бизнес- или техническими) и уверенность в том, что ни один голос не остался незамеченным, а также обеспечение выполнения задачи с подтверждением всех заинтересованных сторон, приводит к взаимным договоренностям.
Преднамеренный переход от посредника к координатору заслуживает отдельного внимания. Мы хотим избежать сделок между опрашиваемым и БА. Бизнес-аналитик передает полученную информацию разработчикам. Такие телефонные передачи размывают сообщение и являются кросс-функциональными, чтобы избежать афер. Для этого были созданы совмещенные команды. Отличные БА – не посредники, а замещают матч-мейкеров и диспетчеров. Иногда произношение (явно) глупых вопросов с целью получения тем, обсуждаемых между заинтересованными сторонами, и обратное воспроизведение отрывков диалога, помогает работе, когда возникает разница мнений.
БА, как правило, имеет хорошие коммуникативные навыки и умеет находить пробелы в знаниях или несоответствия. Когда они используют эти навыки, чтобы облегчить общение между бизнес- и техническими ресурсами, то добавляют массу ценности любому проекту.
В итоге, ценность бизнес-аналитиков приносит команде проекта не изменение при переходе к гибкости, а обеспечение готовности и способности менять свои инструменты и подход, чтобы соответствовать новым условиям. В то время как роль параметров может меняться, умные, отзывчивые и покладистые БА всегда будут востребованы, чтобы делать проекты успешными. Опытные бизнес-аналитики, которые готовы адаптироваться и быть там, где требуется помощь, всегда будут желанными и ценными членами команды.