{"id":14285,"url":"\/distributions\/14285\/click?bit=1&hash=346f3dd5dee2d88930b559bfe049bf63f032c3f6597a81b363a99361cc92d37d","title":"\u0421\u0442\u0438\u043f\u0435\u043d\u0434\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u0443\u044e \u043c\u043e\u0436\u043d\u043e \u043f\u043e\u0442\u0440\u0430\u0442\u0438\u0442\u044c \u043d\u0430 \u043e\u0431\u0443\u0447\u0435\u043d\u0438\u0435 \u0438\u043b\u0438 \u043f\u0443\u0442\u0435\u0448\u0435\u0441\u0442\u0432\u0438\u044f","buttonText":"","imageUuid":""}

Этапы проведения бизнес-анализа в QA-проектах

Дмитрий Радкевич, руководитель направления бизнес-анализа в ИТ-компании по тестированию ПО «Точка качества», рассказал об этапах, инструментах и результатах проведения бизнес-анализа.

Этап 0

Всё начинается с этапа 0: планирование подхода к бизнес-анализу. Многие компании упускают этот этап из-за незнания или чрезмерной уверенности.

На этом этапе собирается предварительная информация о проблеме или возможности, стоящей перед клиентом. С учётом этого бизнес-аналитик определяет наиболее подходящий метод проведения бизнес-анализа в рамках проекта, а именно:

  • Выявляет и анализирует круг заинтересованных сторон (с кем и когда взаимодействовать, через какие каналы коммуникации, кто обладает полномочиями в принятии решений, какова их степень влияния в рамках проекта).
  • Определяет задачи бизнес-анализа, подбирает набор техник для использования при их выполнении и конечных артефактов, а также способ оценки и повышения эффективности бизнес-анализа.
  • Определяет подход к хранению информации (место хранения, степень детализации, уровни доступа, атрибуты артефактов и прочее).
  • Определяет подход к руководству изменениями (как и кем будут вноситься изменения в требования, какие этапы их согласования).

По мере реализации проекта и достижения более глубокого понимания первоначальный метод может изменяться.

Этап 1

Далее аналитик погружается в предметную область бизнеса, изучает его процессы и возможности, определяет цели и задачи, идентифицирует риски, определяет стратегию изменений, очерчивает границы решения и рекомендует конечное решение из числа возможных с учётом выгод клиента.

Результат работы на этом этапе — документ о концепции и границах (vision and scope document) или документ бизнес-требований.

Этап 2

Затем следует выявление требований заинтересованных сторон и переработка их в требования к решению (функциональные и нефункциональные). В результате клиент получает спецификацию / ТЗ или бэклог. Данный этап может проходить параллельно с последующими при реализации проекта по гибкой методологии.

Этап 3

После того как требования сформулированы, бизнес-аналитик приступает к сопровождению разработки и поставки решения.

Этап 4

После завершения разработки и тестирования бизнес-аналитик оказывает поддержку эксплуатации (как правило, консультирует пользователей).

Этап 5

Завершающий этап — мониторинг. Аналитик оценивает полученный бизнес-эффект и достижение поставленной цели.

В каком формате клиент принимает работу бизнес-аналитика

По ходу реализации проекта и в момент его завершения бизнес-аналитик предоставляет клиенту артефакты в соответствии с подходом к бизнес-анализу, который был определён на этапе 0.

С учётом большого количество определяющих факторов, начиная с методологии и заканчивая корпоративными стандартами, вариантов артефактов может быть много.

Каждый из них содержит в себе требования в графической либо текстовой форме. Главное, что требования в полной мере должны отвечать критериям качества. А артефакт — ничто иное, как «контейнер» для их хранения, который должен быть удобен в использовании и для команды проекта, и для заказчика.

Можно выделить следующие типовые результаты работы бизнес-аналитика в ИТ:

  • Документ об образе и границах
  • Спецификация требований
  • Варианты использования
  • Пользовательские истории
  • Диаграммы с применением нотаций UML, BPMN, EPC
  • Прототипы пользовательских интерфейсов

Связь тестирования и бизнес-анализа

И команда тестирования, и бизнес-аналитики работают с требованиями:

  • В начале функция бизнес-анализа создаёт требования.
  • Далее требования попадают в команду разработки.
  • Разработчики «пишут код» по требованиям.
  • Затем требования переходят к инженерам по тестированию. Они проверяют на соответствие разработанный продукт.

За годы работы у меня формировалось видение взаимодействия бизнес-аналитиков и команды тестирования: бизнес-анализ — входные «ворота», а тестирование — выходные «ворота» проекта. Если на входе и на выходе установить качественные «ворота», у разработчиков просто не останется шансов реализовать не качественное решение.

Я не могу назвать качественным разработанный продукт, если он работает корректно, но не решает задачи бизнеса. И наоборот, если решение отвечает целевому видению, но в нём много дефектов, — такой продукт также нельзя назвать качественным.

Взаимодействие бизнес-анализа и тестирования позволяет разработать корректно работающий и соответствующий целям компании продукт.

Заблуждения о бизнес-анализе

Я могу выделить одну общую группу заблуждений компаний о бизнес-анализе: «нам функция бизнес-анализа не нужна», «у нас и так всё прекрасно работает», «мы успешно реализуем проект и без бизнес-аналитика».

На все эти утверждения могу сказать одно: бизнес-анализ присутствует везде, где есть работа с требованиями! Вопрос в том, кто и как его осуществляет?

Если, по вашему мнению, бизнес-анализ на проекте не требуется т.к. проблем на текущем этапе нет, значит вам просто повезло, и вы неосознанно реализуете его эффективно. Но это рискованно, и неизвестно, в какой момент что-то может пойти не так.

Есть три главных риска при реализации ИТ-проектов на основе исследования Института управления проектами, выделенные практикующими менеджерами:

  • изменения в приоритетах организации
  • несоответствия на этапе сбора требований
  • изменение целей проекта

Все эти причины связаны с областями управления и разработки требований, то есть функцией бизнес-анализа.

70% ИТ-проектов заканчивается неудачей именно из-за отсутствия чётко сформулированных и актуальных требований. Чем более полно сформированы требования к ИТ-решению в самом начале, тем меньше доработок, сопряжённых с дополнительными расходами, потребуется на более поздних этапах работы.

Если вы нацелены разработать и выпустить востребованное, стабильно работающее и эффективное решение, лучше привлечь экспертов по бизнес-анализу на ранних этапах проекта.

Но даже если вы этого не сделали в начале, — не страшно. Специалист аргументированно поможет улучшить текущую ситуацию и быстрее достичь поставленных целей на любом этапе проекта.

Бизнес-аналитики «Точки качества» обладают всеми требуемыми знаниями и опытом для проведения бизнес анализа. Если вы желаете проконсультироваться с нашими экспертами или вашему проекту нужен бизнес-аналитик, заполните форму обратной связи на нашем сайте.

0
Комментарии
-3 комментариев
Раскрывать всегда