Сегодня роль бизнес-аналитика — некий компромисс в отрасли разработки программного обеспечения. Он заключается в непонимании важности участия проектировщиков взаимодействия (Interaction Designer, IxD) в процессе разработки ПО и продиктован желанием хоть как-то это ПО создавать. В то же время бизнес-аналитик — наиболее подходящий кандидат на роль проектировщика взаимодействия, с потенциалом для существенного повышения качества разрабатываемых продуктов.
Статус-кво
Мир современного бизнеса — мир ПО. Достаточно посмотреть на рейтинг самых дорогих компаний мира по данным Forbes, чтобы понять, что программные продукты играют не менее важную роль чем сырьё или рабочая сила. А зачастую ПО имеет доминирующее значение в ведении бизнеса.
Роль бизнес-аналитика в разработке собственной Business Rule Engine с нуля
В 1999 году в своей книге «Бизнес со скоростью мысли» основатель компании Microsoft Билл Гейтс описывал «электронную нервную систему» организаций. Он считал, что программное обеспечение позволит организациям моментально реагировать на изменения состояния рынка, а в эпоху цифровых технологий без этого конкурентного преимущества не будут возможны ни рост, ни выживание организации вообще. Сейчас можно с уверенностью утверждать, что его предположение оказалось верным и те, кто осознал и принял этот факт, так или иначе нуждаются в специализированном ПО. В некоторых случаях можно обойтись готовыми решениями (например, такими как 1С), но чаще конкретному бизнесу нужно программное обеспечение, разработанное специально для него.
Времена, когда разработкой приложений занимался один человек, давно прошли, и тому есть две основные причины.
Во-первых, разработать нечто способное конкурировать с уже успешно существующими решениями в плане технической сложности — нетривиальная задача. А во-вторых, владеть достаточным количеством знаний одновременно во всех областях, влияющих на успешность цифрового продукта, невозможно. Для решения этих проблем принято формировать команды разработки. В таких командах существуют узкоспециализированные роли, такие как специалист по обеспечению качества (Quality Assurance, QA), специалист по поисковой оптимизации (Search Engine Optimization, SEO), графический дизайнер, специалист по вёрстке, специалист по продажам, менеджер проекта, программисты, которые обычно специализируются на определённом направлении и стеке технологий и многие другие.
Такое разделение на роли является достаточно условным. Бывает так, что программист может справиться с задачами по вёрстке, потому что ему часто приходится вносить небольшие правки в шаблоны веб-страниц, Или QA начинает программировать, потому что он учится этому в процессе работы с автоматизированными тестами. Подобных схем довольно много.
Ещё один неотъемлемый участник проекта — бизнес-аналитик (Business Analyst, BA). Он является своего рода специалистом «по связям с общественностью», основная задача которого заключается в анализе запросов заказчика и составление функциональных требований, необходимых программистам для работы.
Бизнес-анализ: методология и инструментарий. Роль бизнес-аналитика.
Проблема: аналитик как промежуточное звено
Заказчик приходит к подрядчику с определённой проблемой или идеей. Основная цель любой коммерческой организации —получение прибыли, и именно на это в конечном итоге рассчитывает заказчик. Поэтому мы можем говорить о понятии «бизнес-целей» или «бизнес-требований». Поскольку заказчик готов вкладывать в разработку своего продукта деньги, он хочет иметь представление о том, что за эти средства можно получить. Он долго обдумывает, что же конкретно ему нужно, имея в голове образ приложения практически на уровне графического пользовательского интерфейса.
Так происходит потому, что для человека, не связанного с программированием, интерфейс приложения — это самая понятная вещь из всего того, что он видит в процессе разработки. И именно поэтому заказчик оперирует элементами пользовательского интерфейса, дабы рассказать, что именно ему нужно.
Однако на самом деле проектирование взаимодействия пользователя с приложением — это очень нетривиальная задача, требующая специальной подготовки. Качество этого проектирования может стать определяющим в успешности всего продукта. Диктуя то, как приложение должно выглядеть и вести себя, заказчик неминуемо подмешивает к собственным бизнес-целям ещё и личное понимание прекрасного и представление процесса взаимодействия пользователей с приложением.
Проблема №1: Бизнес-цели заказчика перемешиваются с другими целями.
И тут в игру вступает бизнес-аналитик. Что он делает:
- внимательно выслушивает заказчика;
- тщательно всё записывает;
- детально всё анализирует;
- формулирует требования к продукту;
- составляет вайрфреймы (Wireframes) и утверждает их у заказчика.
Бизнес-аналитики прилагают максимум усилий, чтобы проект был успешным, а заказчик — счастливым. Последнее означает положительные рекомендации компании-подрядчика и новые проекты.
В процессе работы с разными проектами у бизнес-аналитиков формируется некое представление о том, какое решение на уровне пользовательского взаимодействия более перспективно. И они, несомненно, используют эти знания на всех этапах работы.
Однако заказчик далеко не всегда прислушивается к мнению бизнес-аналитика. Мне довелось работать с заказчиком, который на комментарий «давайте это сделаем по-другому, иначе пользователем будет тяжело с этим разобраться» ответил: «Если им будет тяжело — пусть не пользуются моим продуктом».
На мой взгляд, так происходит потому, что для заказчика бизнес-аналитик является неким промежуточным звеном, транслирующим его идеи программистам. И даже если от бизнес-аналитика поступает конструктивная идея, она зачастую воспринимается просто как мнение стороннего человека, важность коего очень условна.
Когда экспертиза субъективна
Если разобраться, знания, которыми обладает бизнес-аналитик в рамках конкретного проекта, сильно ограничены.
Единственным и самым главным источником данных для принятия решений и проектирования требований служит сам заказчик. К этим данным бизнес-аналитик может добавить свой багаж знаний, эмпирически накопленный на основании предыдущих проектов. Но этого совершенно не достаточно, чтобы убедить заказчика в верности своих идей, потому как каждый проект и аудитория пользователей уникальны. У бизнес-аналитика просто нет никаких доказательств, потому что он знает о пользователях продукта ровно столько, сколько и сам заказчик — практически ничего.
Проблема №2: Основаниями для функциональных требований является мнение заказчика.
Результат
В результате бизнес-аналитик и заказчик находят некий компромисс, как всё должно работать. При этом ни один, ни второй зачастую не обладают реальными знаниями о настоящих пользователях проекта, а лишь делают предположения. В этом случае функциональные требования становятся очень пластичными, появляется желание что-то добавить или поменять.
Сроки реализации затягиваются из-за постоянных запросов на изменения. Отдельные модули проекта исключаются, снижая мотивацию разработчиков создавать новые модули. Количество «протухшего» кода внутри проекта растёт, делая внесение новых изменений болезненным и дорогим.
Не сомневаюсь, что во многих случаях все в итоге получают желаемое: заказчик — работающую систему, а подрядчик — деньги. Заказчик тратит дополнительные средства на обучение своих сотрудников работе с системой, иногда даже нанимает специальных тренеров (да, я такое видел). Сами пользователи недовольны и даже порой раздражены тем, с чем им приходится работать.
Например, в одной авиакомпании бортовая мультимедийная развлекательная система для запуска фильма требовала содействия бортпроводника и была настолько неудобной, что перед длительными перелётами бортпроводники выводили её из строя, а потом просто объявляли пассажирам о её неисправности.
Если проект представляет собой коммерческий продукт, пользователи просто уйдут к конкуренту.
Решение: проектировщики взаимодействия
Как уже отмечалось выше, успех продукта сильно зависит от знания пользовательской аудитории. Заказчику может казаться, что он знает всё, но без специальных исследований эти знания часто не имеют ничего общего с реальностью. Это касается и бизнес-аналитика. В итоге проект превратится в подбрасывание монетки. Для решения этой проблемы нужен другой специалист — проектировщик взаимодействия.
Вот чем занимается этот специалист.
- Формирует представление о бизнес-целях и способах их достижения. Для этого он общается с заинтересованными лицами и экспертами предметной области.
- Формирует представление о пользователях. Для этого он анализирует количественные данные о пользователях, полученные, например, из маркетинговых исследований. Самостоятельно собирает качественные данные о пользователях, используя интервью, опросы, фокус-группы, дневниковые исследования, наблюдения за пользователями и другие техники. Анализирует результаты исследований и составляет персонажей (образы наделённых конкретными поведенческими характеристиками пользователей).
- Составляет прототипы в виде вайрфреймов, основываясь на персонажах и их характеристиках. При этом постоянно общается с командой разработки, чтобы не выйти за рамки технической реализуемости. Проводит юзабилити-тестирование прототипов с привлечением настоящих пользователей. Проводит эвристический анализ прототипов. Анализирует результаты юзабилити-тестирования и эвристического анализа и составляет новые прототипы, повторяя тестирования до тех пор, пока прототипы не будут достаточно хороши.
- В этот момент проектировщик взаимодействия может предложить заказчику конкретные пути достижения бизнес-целей с учётом потребностей пользователей. В отличие от классического бизнес-аналитика, проектировщик взаимодействия обладает достаточным набором данных, чтобы убедить заказчика в верности того или иного решения.
- Сопровождает процесс «пиксельной прорисовки» интерфейса и разработки. Проводит тестирования всех версий приложения с привлечением пользователей, оперативно вносит правки во все аспекты пользовательского взаимодействия.
Бизнес-аналитики — завтрашние проектировщики взаимодействия
Из всех специалистов в сфере информационных технологий бизнес-аналитики находятся ближе всех к проектировщикам взаимодействия. Они уже умеют общаться с заказчиками и экспертами предметной области, прототипировать интерфейсы, составлять и верифицировать у команды разработки функциональные требования. Им нужно знать, кто является пользователями продукта, в чём состоят их цели. Сделать это можно, только освоив методы качественного анализа, техники тестирования прототипов с привлечением пользователей и экспертов предметной области, теоретические основы информационного и продуктового дизайна.
Такой набор навыков является не просто перспективным, но и качественно новым фактором, определяющим успех разрабатываемых продуктов.
Уже сейчас встречаются проекты, на 80% состоящие из исследований и на 20% из процесса разработки. Крупные компании, имеющие опыт сотрудничества с разработчиками ПО, для заключения новых контрактов на разработку объявляют тендер, который выглядит примерно так: «Вот у нас форма пожертвований, сделайте что-нибудь, чтобы повысить конверсию». Чёткая бизнес-цель, никаких «нарисуйте собачку или цветочек». Таких проектов со временем станет всё больше, а за крупными компаниями, поступающими таким образом, подтянутся и другие.
Как быть с графическими дизайнерами?
Действительно, графические дизайнеры (веб-дизайнеры или просто дизайнеры), за годы работы эмпирически освоили многие аспекты пользовательского взаимодействия и могут «нарисовать красиво и удобно». Однако, их навыки имеют эмпирический, а не теоретический базис. У них, как и у остальных, не достаточно аргументов, «почему эта красная кнопка должна быть именно здесь». Кроме того, по моему субъективному мнению, навыки общения бизнес-аналитика скорее приближают его к проектировщикам, а стремление «выразить себя» будет мешать графическому дизайнеру в условиях полной свободы действий.
Что могут сделать остальные?
Как разработчика, вкладывающего время и усилия в продукт, меня всегда огорчает, когда что-то приходится выбрасывать. Отчасти это происходит оттого, что в условиях отсутствия экспертизы проектировщиков ведущие к длительной работе с исходным кодом решения принимаются неоправданно быстро и не имеют под собой серьёзных оснований (кроме мнения заказчика). Поэтому перед тем, как взяться за новую задачу, нужно всегда понимать
- какую пользу это принесёт бизнесу;
- какую пользу это принесёт пользователям.
Всегда задавайте эти вопросы себе, бизнес-аналитику и владельцу продукта на совещаниях.
В идеале, функциональные требования должны быть изложены на языке Gherkin, который описывает сценарий поведения пользователей и объясняет, почему предполагается, что пользователь будет вести себя именно так.
Как зарегистрированный пользователь
для того, чтобы чувствовать контроль над своим лицевым счётом,
я хочу видеть остаток своего лицевого счёта.
—————————————————————————————-
Допустим, в системе существует пользователь «Вася Петров».
А также я выполнил вход в систему как «Вася Петров».
Когда я перехожу на страницу «Состояние лицевого счёта»,
тогда я вижу остаток своего лицевого счёта.
Если ваши функциональные требования не составлены в таком формате, сделайте это. Если у вас нет ответов на вопросы о том, кому эта функциональность нужна и почему, постарайтесь получить ответ на этот вопрос у бизнес-аналитика и владельца продукта. Кроме того, подобное описание задач является базой для автоматического интеграционного тестирования продукта, а также является хорошей документацией функциональности.
Более того, в процессе описания требований в Gherkin вы можете обнаружить, что полезность функциональности сомнительна или, как в случае, когда задача пришла как запрос от пользователей и никак толком не анализировалась, что на самом деле пользователю нужно совсем не то, что он описывает.
Что почитать?
Подводя итог, считаю уместным порекомендовать литературу для дальнейшего изучения. Остановлюсь на двух книгах:
- Алан Купер. Интерфейс. Основы проектирования взаимодействия. 4-е изд. 2016.
- Расс Унгер, Кэролайн Чендлер. UX-дизайн. Практическое руководство по проектированию опыта взаимодействия. 2011.
*Мнение колумнистов может не совпадать с позицией редакции.
Источник: devby.io
Презентация на тему Введение. Роль бизнес-аналитика в жизненном цикле разработки ПО
человека;
используем приложения MS Office (Word, Visio);
прототип в AxureRP.
Отчетность
выполнение плана (посещения, практические задания в срок);
экзамен: два устных вопроса + практическое задание.
Лекции в формате бизнес-тренинга
презентации в PowerPoint (фактически конспект лекций);
будут выкладываться на req.siroezkin.info.
преподаватель — консультант
Слайд 5Содержание лекций
Роль аналитика в проекте по разработке
ПО;
Работа в MS Word;
Методы сбора требований, описание
границ и образа проекта;
Описание бизнес-процессов;
Построение диаграммы «High-level use cases», сбор нефункциональных требований;
Прототипирование;
Определение пользовательских требований;
Определение функциональных требований, ограничений и правил, принципы прослеживаемости требований;
Качество требования;
Инструменты по хранению, управлению и каталогизированию требований.
Слайд 6Роль бизнес-аналитика в жизненном цикле разработки ПО
Слайд 7Системный аналитик: Кто он?
Системный анализ (классически) –
методология исследования объектов
Исследование операций;
Системы поддержки принятия решений;
Почему
«математик. математик – системный аналитик»
Философия систем – математик→модель;
Математика – набор прикладных моделей;
Что такое наука;
Системный аналитик – Бизнес-аналитик – Аналитик требований
Слайд 8Бизнес-аналитик
Бизнес-аналитик в бизнесе – это бизнес-консультант
Бизнес-аналитик в
IT:
интерфейс между IT и бизнесом ;
системный аналитик
– значит процессный аналитик;
функциональный аналитик.
Слайд 9В двух словах
Аналитик помогает определить разницу между
тем, что заказчик ГОВОРИТ ЧТО ОН ХОЧЕТ,
и тем, что ЕМУ ДЕЙСТВИТЕЛЬНО НЕОБХОДИМО
Это проще сказать чем сделать
Слайд 10Требования к ПО
Совокупность утверждений относительно свойств ПО,
подлежащая реализации в процессе разработки
Слайд 11Уровни требований к ПО
Слайд 12Процесс разработки ПО
Слайд 13Основное связующее звено в проекте
Слайд 14Основные обязанности аналитика
Сбор;
Анализ;
Документирование;
Утверждение потребностей заказчика проекта.
Слайд 15Результаты работы
“Опытный аналитик может сократить трудозатраты проекта
на одну треть по сравнению с неопытным
а проекты с высококвалифицированным аналитиком требуют половину трудозатрат по сравнению с проектами которые используют менее квалифицированных аналитиков”
(Barry Boehm,
Software Cost Estimation with Cocomo II)
а проекты без аналитика могут закончится провалом!
Слайд 16Обязанности аналитика в двух словах
Аналитик должен в
начале понять! ожидания пользователей от новой системы,
обозначить функциональные требования и показатели качества,
которые позволят менеджеру проекта оценить,
разработчикам спроектировать и создать,
а тестировщикам проверить продукт.
Слайд 17Обязанности аналитика (сбор)
Определение бизнес потребностей;
Идентификация заинтересованных сторон
и пользователей продукта;
Извлечение требований;
Слайд 18Определение бизнес потребностей
“Почему мы беремся за этот
проект?”
Бизнес потребности включают:
Формулировка бизнес целей организации;
Первичное видение
того, что будет представлять система и что она будет делать.
Результаты:
Видение и границы проекта.
Слайд 19Идентификация заинтересованных сторон и пользователей продукта
Определение основных
классов пользователей продукта;
Работа со спонсором проекта что
бы выделить подходящих представителей для каждого класса пользователей;
Результаты:
Записать вклад каждого представителя со стороны заказчика который вы бы хотели иметь и договориться о соответствующем уровне участия в проекте каждого из представителей заказчика.
Слайд 20Извлечение требований
“Требования для программного продукта не валяются
просто так в ожидании того, что кто-то
соберет их”
Karl E. Wiegers.
Результаты:
Функциональные атрибуты;
Атрибуты качества;
Показатели производительности;
Бизнес правила;
Внешние интерфейсы;
Ограничения.
Слайд 21Обязанности аналитика (разработка)
Анализ требований;
Написание спецификаций;
Моделирование требований.
Слайд 22Анализ требований
“Ищите вторичные требования которые являются логической
последовательностью запросов заказчика, так же хорошо как
охотитесь на те не явно выраженные требования, которые должны быть, но не были озвучены”
Karl E. Wiegers
Поиск неоднозначных слов которые служат причиной неясности и неразберихи
Выделение конфликтных требований и областей требующих большей детализацией
Спецификация функциональных требований до необходимого уровня детализации для разработчиков которые разрабатывают продукт.
Слайд 23Написание спецификации и моделирование требований
Эффективная разработка требований
приводит к более широкому и глубокому пониманию
нужд заказчика и как следствие созданию системы, которая решает проблемы заказчика
Результаты:
Хорошо организованная спецификация
Графические аналитические модели, таблицы, математические выражения, прототипы
Слайд 24Обязанности аналитика (управление)
Управление согласованием;
Управление требованиями.
Слайд 25Управления согласованием
Аналитик должен гарантировать, что требования удовлетворяют
нуждам заказчика и что они:
понятные;
законченные;
правильные;
выполнимые;
необходимые;
трассируемые;
не двусмысленные;
проверяемые.
должен просматривать прототип (дизайн) и тестовые примеры, основанные на спецификации требований, чтобы гарантировать, что требования интерпретированы правильно
Слайд 26Управление требованиями
Установка базовой линии требований;
Хранение требований в
системе управления требованиями;
Отслеживание статуса каждого функционального требования
от начала проекта до верификации требования в продукте;
Сбор трассируемой информации от участников команды для соединения конкретных требований с другими элементами (задачи, варианты тестирования и т.д.).
Результаты:
Управление изменениями в требованиях через процесс управления изменениями и с помощью средства управления требованиями.
Слайд 27Способности аналитика
10 способностей которые необходимы аналитику для
успеха:
Умение слушать;
Умение проводить интервью и задавать вопросы;
Умение
анализировать;
Умение управлять групповой работой;
Наблюдательность;
Умение писать;
Умение структурировать информацию;
Умение моделировать;
Умением общаться и ладить с людьми;
Креативность.
Слайд 28Умение слушать
Активное слушание (исключение всего, что может
отвлекать; установка ключевых моментов для подтверждения правильности
понимания)
Быстро понимать то, что говорят, а также читать между строк для того, чтобы определить то, что возможно не решаются сказать.
Следить за предположениями которые выделяют то, что вы слышали от других и вашей собственной интерпретацией.
Слайд 29Умение проводить интервью и задавать вопросы
Способность задавать
правильные вопросы:
“Что должно произойти если. ”
“Может ли
проблема> когда либо произойти?”
…..
Слайд 30Умение анализировать
Способность оперировать на различных уровнях абстракции:
Опускаться
от высокоуровневой информации к деталям;
Отталкиваться от специфических
нужд одного пользователя к набору требований, которые принадлежат к целому классу пользователей;
Оценивать информацию полученную из различных источников информации для урегулирования конфликтов в требованиях;
Отделять желания пользователей от их нужд.
Слайд 31Наблюдательность
Способность выделить тонкости которые пользователь либо заказчик
не упоминал и таким образом обнажить новые
темы для обсуждения.
Слайд 32Умение структурировать информацию
Способность структурировать все части информации
в единое целое
Вход:
Огромные массивы беспорядочной информации собранной
в результате получения и анализа требований
Источник: thepresentation.ru
Кто такой бизнес-аналитик?
Бизнес-аналитик — это профессионал, который играет важную роль в успешной работе компании. Он является связующим звеном между бизнесом и сферой АйТи. Бизнес-аналитик изучает бизнес-процессы организации, выявляет возможные проблемы и находит эффективные решения. Он использует свои знания и опыт, чтобы помочь компаниям оптимизировать свои бизнес-процессы, что в свою очередь увеличивает эффективность работы, снижает издержки и повышает конкурентоспособность компании.
Основная задача бизнес-аналитика — определить проблемы и улучшить бизнес-процессы. Они анализируют данные с помощью различных методов, таких как статистический анализ, моделирование, экспертные оценки и машинное обучение, чтобы найти возможности для оптимизации. Бизнес-аналитики играют важную роль в принятии решений на всех уровнях компании, помогая повысить эффективность бизнес-процессов и увеличить прибыльность.
- Понимание бизнес-процессов. Бизнес-аналитик должен иметь возможность оценить текущие бизнес-процессы в компании, описать их, выявить проблемы и недостатки в системе.
- Улучшение бизнес-процессов. Бизнес-аналитик даёт рекомендации по оптимизации бизнес-процессов и их автоматизации, чтобы повысить эффективность работы компании.
- Описание функциональности программ. Он определяет, какие функции должны быть включены в программное обеспечение, чтобы обеспечить более эффективную работу бизнес-процессов.
- Создание отчетов и анализ данных. Это подразумевает умение собирать, анализировать и интерпретировать данные, чтобы предоставлять компании информацию, необходимую для принятия решений.
- Кроме того, бизнес-аналитик может заниматься другими задачами, такими как управление проектами, тестирование программного обеспечения и обучение пользователей.
Для работы бизнес-аналитика требуются следующие квалификации:
- глубокое понимание анализа данных;
- умение применять различные методы и инструменты для анализа данных, включая статистические методы и машинное обучение;
- широкое понимание бизнес-процессов, включая их взаимосвязь и влияние на функционирование предприятия;
- опыт работы с большим объемом информации, включая умение работать с различными базами данных и хранить информацию в облаке;
- отличные коммуникационные навыки для эффективного общения с различными заинтересованными сторонами, включая менеджеров, клиентов и коллег;
- умение работать в команде и сотрудничать с другими специалистами, такими как аналитики данных, экономисты и разработчики программного обеспечения.
Помимо этого, бизнес-аналитик должен быть в состоянии адаптироваться к новым технологиям и трендам в области анализа данных, поэтому регулярное обучение и саморазвитие являются неотъемлемой частью этой профессии.
Роль бизнес-аналитика в проекте
Роль бизнес-аналитика в проекте или продукте не может быть переоценена. Этот специалист играет ключевую роль в определении и удовлетворении требований пользователей, а также в разработке и улучшении продукта. Он использует IT-технологии для решения проблем, выявленных в бизнес-процессах, и при этом учитывает интересы всех сторон.
Например, бизнес-аналитик может провести исследование рынка и анализ конкурентов, чтобы определить, какие функции и особенности продукта могут привлечь больше пользователей. Он также может провести опросы и интервьюирование пользователей, чтобы узнать их мнение о продукте и выявить недостатки.
Кроме того, бизнес-аналитик работает с различными заинтересованными сторонами, такими как менеджеры продукта, разработчики, дизайнеры и пользователи. Он взаимодействует с каждой стороной, чтобы определить их требования и желания, и создает общее видение продукта, которое соответствует всем интересам заинтересованных сторон. Например, он может провести встречи с менеджерами продукта и разработчиками, чтобы обсудить возможности и ограничения продукта, а также с дизайнерами, чтобы обсудить дизайн и пользовательский интерфейс.
Кроме того, бизнес-аналитик может провести обучение пользователей, чтобы помочь им лучше понимать продукт и использовать его наиболее эффективно. Он также может предоставить отчеты и аналитику, которые помогут менеджерам продукта и руководству принимать более обоснованные решения. Таким образом, бизнес-аналитик является связующим звеном между различными сторонами, обеспечивая, чтобы все требования и желания были учтены в создании общего видения продукта.
Артефакты бизнес-аналитики
В процессе работы над проектом бизнес-аналитик создает различные документы и материалы, которые называются артефактами. Они могут иметь различные формы и содержать разный объем информации, но их цель — помочь лучше понять требования пользователей и определить, какой продукт будет наиболее эффективен. Среди наиболее распространенных артефактов, которые создает бизнес-аналитик, можно выделить:
- Техническое задание (ТЗ) — это документ, который содержит требования к продукту, описание его функциональности и особенности его использования. Техническое задание является основным документом для разработчиков и других участников проекта. В ТЗ также могут включаться разделы, посвященные процессу тестирования, требованиям к безопасности и т.д. Также важно учитывать, что ТЗ может состоять из нескольких частей, каждая из которых описывает отдельные аспекты продукта.
- User story — это короткий текст, который описывает поведение пользователя в системе или продукте. User story используется для определения требований пользователей и создания общего видения продукта. Однако, помимо описания поведения пользователя, в User story также могут включаться описания бизнес-правил и требований к функциональности продукта. Также возможно добавление дополнительных деталей, таких как дизайн-макеты и схемы.
- Use case — это диаграмма, которая показывает, как продукт будет использоваться пользователями. Use case помогает определить требования пользователей и создать общее видение продукта. Для более подробного описания Use case возможно включение дополнительных элементов, таких как описания действий пользователя и описания возможных сценариев использования.
Артефакты тесно связаны друг с другом и помогают определить требования пользователей и создать общее видение продукта. Техническое задание содержит требования к продукту и его функциональности, которые могут быть детально описаны, чтобы удовлетворить потребности пользователей. User story, с другой стороны, помогает определить требования пользователей на более глубоком уровне, позволяя более точно понять, что пользователи хотят от продукта. Use case диаграмма показывает, как продукт будет использоваться пользователями, и также помогает определить требования пользователей, что позволяет бизнес-аналитику более точно определить требования пользователей. Вместе эти артефакты обеспечивают более глубокое понимание требований пользователей и создание продукта, который наиболее эффективен и соответствует их потребностям.
При создании артефактов бизнес-аналитиком, их потребителями могут быть различные участники проекта, такие как разработчики, дизайнеры, менеджеры продукта, пользователи и другие заинтересованные стороны. Артефакты не только помогают им лучше понимать требования пользователей, но и способствуют более детальному анализу проекта. Например, они могут помочь определить, какой продукт будет наиболее эффективен и какие функции должны быть включены в него.
Кроме того, артефакты могут использоваться для обучения пользователей. Это может быть полезно при внедрении нового продукта или функционала, когда пользователи не знакомы с его особенностями. Также артефакты могут быть использованы для создания отчетов и аналитики, которые помогут менеджерам продукта и руководству принимать более обоснованные решения.
Наконец, артефакты могут содействовать более эффективному управлению проектом. Они могут помочь согласовать понимание требований между различными участниками проекта и предотвратить недопонимание. Более того, они могут использоваться для контроля за ходом работы и оценки прогресса проекта.
Таким образом, бизнес-аналитик играет важную роль в разработке продукта, обеспечивая связь между различными заинтересованными сторонами и создавая общее видение продукта, соответствующее потребностям и желаниям пользователей. Артефакты бизнес-аналитики, такие как техническое задание, User story и Use case диаграмма, помогают определить требования пользователей и создать продукт, который наиболее эффективно их удовлетворяет. Кроме того, артефакты могут использоваться для обучения пользователей, создания отчетов и аналитики, а также для более эффективного управления проектом.
Какие артефакты создает бизнес-аналитик? Об этом поговорим на бесплатном вебинаре, где рассмотрим роли бизнес-аналитика на проекте или в продукте, какие артефакты может создавать бизнес-аналитик, кто является потребителем создаваемых артефактов и какие требования к ним предъявляются.
- Зарегистрироваться на бесплатный вебинар
Источник: temofeev.ru
