С момента появления бизнес-анализа как отдельной дисциплины роль БА изменилась вместе с процессами в ИТ-индустрии. Кроме того эта роль обросла разными представлениями по мере поиска “входа в ИТ” представителями других сфер знаний. О некоторых таких представлениях мне стало интересно порассуждать.
Не нужны никакие знания о разработке ПО?
Во многих источниках можно видеть, что бизнес-аналитику не нужно иметь технических навыков или инженерного образования. С другой стороны, если полистать вакансии, то для роли БА даже без совмещения с системным анализом, наниматели часто ожидают как минимум понимание ИТ-архитектуры и процессов разработки. Зачем это?
?Приходится разбираться в преимуществах и ограничениях систем, которые служат для автоматизации процессов. Невозможно предложить процессные и функциональные решения без понимания, на чем они строятся. Это чем-то напоминает проектирование здания без понимания особенностей строительных материалов. Можно уточнить у разработчиков, но как много вопросов в день они готовы обработать?
?Нужно обрисовать образ результата коллегам, которые применяют знания о системах и алгоритмах для решения любых задач. Их система аргументации и приоритетов построена на этих знаниях. Без минимальных знаний ИТ-архитектуры сложно понять, зачем вас просят изменить требование, потому что «у нас сервис отправки получает только мета-данные и не видит весь текст сообщения»…
Из нужных знаний я бы выделила:
?Принципы работы с данными. Не нужно уметь создавать базы данных, но обязательно понимать как данные организуются и как хранятся. Уметь моделировать данные на концептуальном и логическом уровне. Этот навык поможет правильно выделять объекты предметной области и связи между ними.
?Основы архитектуры. Нужно понимать какими способами системы могут взаимодействовать между собой. Это поможет сформулировать требования так, чтобы вас поняли, и читать документацию без переводчика. Еще такое знание помогает быстрее понимать ограничения для бизнес-процессов.
?Процесс разработки. Речь именно о производстве: написании кода, контроле версии, сборке и установке релиза, тестировании и работе с багами. Так вы будете быстрее понимать, почему вчера можно было «быстренько изменить», а сегодня уже поздно; почему «у нас монолит, мы не можем ничего выпилить из релиза».
Заказчик должен знать, чего хочет?
Ради красоты заголовка позволила себе немного рискованную формулировку. Плохо, если даже на уровне метрик продукта никто из заинтересованных сторон не понимает, к чему нужно прийти. Другая крайность - считать, что заинтересованные стороны должны уметь сформировать запрос на самом детальном уровне.
В реальности сформировать запрос во всех деталях означает провести работу по оптимизации процессов и проектированию функциональности. Заказчик не обязан иметь навыки анализа предметной области, оптимизации процессов и проектирования систем. Кто-то признаётся в этом честно, а кто-то старается играть роль адепта технологий. Я однажды услышала: «Мне все понятно, у меня же муж айтишник!»
Ваш потребитель лучше всех знает, что мешает ему в его собственном мире. Но это не значит, что он может облечь свое знание в слова (из книги Синди Альварес «Как создать продукт, который купят»).
Из своего опыта заметила:
?Заказчик не знает чего хочет - значит вы, как БА, можете смело применять многие исследовательские инструменты. Можно искать и предлагать свои варианты решения, есть шанс, что это примут с интересом и даже благодарностью (особенно, если заказчик не претендует на роль ИТ-эксперта).
?Когда клиент слишком хорошо знает, чего хочет — будьте бдительны, может быть ему это не нужно, но обнаружите вы это уже после внедрения. Лучше проверить гипотезы заинтересованных сторон через прототип или модель процесса, на которой видны возможные сценарии.
?Переменчивость запросов заинтересованных сторон может быть связана с недоверием к вам или ко всей команде разработки. Для выстраивания доверия помогают открытость и управление ожиданиями сторон. Важно не создавать завышенных ожиданий заинтересованных сторон и по возможности объяснять шаги работы над задачей.
Цель работы - составить документ?
Постановка задачи БА часто выглядит как «написать требования» или «составить документ» и гораздо реже как «спроектировать процесс» или «предложить варианты решения». Может создаться впечатление, что смысл и основной результат работы именно в составлении документа. Вопросы документирования всегда вызывают споры. На мой взгляд это происходит из-за подмены понятий "решение" и "носитель информации", где это решение изложено. Носитель видно, а кто видел как ваша голова работала, когда вы решение придумывали? В одной из команд, где нужно было списывать время на задачи, менеджера очень раздражали формулировки вида "4 часа ушло на анализ", а вот "4 часа писала документ ТЗ" - это совсем другое дело...
Документ — это важный инструмент передачи информации, аналитик должен уметь составлять разные виды документов. Кроме того, немало проектов, где артефакты анализа — это важная часть поставки в рамках договора с внешним заказчиком. При этом
? Не так важен сам документ, как то решение, что в нем описано и ценно в первую очередь то, насколько успешно будут внедрены изменения, которые вы предлагаете. Если по вашим описаниям смежная команда не сможет в срок разработать новый сервис, потому что вы маппинг данных не докопали, это проблема в вашем проектировании или в вашем документе?
?Самого по себе документа в общем случае недостаточно, чтобы внедрить изменения. Приходится признать, что текст требований мало кто читает внимательно. Люди игнорируют элементы задачи, которые им кажутся не связанными с выполнением этой задачи или выглядят очевидными. Например, в описании экранной формы вы описали выпадающий список. Чаще всего дальше типа поля мало кто дочитает. Понятно же что это такое и как выглядит в дизайне! То, что в списке требуется множественный выбор и нужна зависимость между опциями, обнаружится уже при тестировании.
На мой взгляд нужно учитывать, что:
?Как любой другой проектный артефакт, документ — это часть того, что можно сдать/показать/продать в результате работы команды, пренебрегать этим нельзя. При этом фокус работы БА нужно сохранять именно на внедрении изменений.
?Не стоит приобретать зависимость от документирования, лучше руководствоваться потребностями команды. Бывают случаи, когда кто-то пытается механически задокументировать функциональность, уже внедренную 3-5 лет назад, при этом разработка не стоит на месте и текст устаревает быстрее, чем его пишут…
?Когда позволяет методология вашей компании, имеет смысл комбинировать способы передачи информации и дополнять текст картами, прототипами, обсуждениями и видео-комментариями.
