×Закрыть

Какие книги читать для того, чтобы стать Business Analyst?

Друзья, поделитесь опытом, кто как стал BA.
Достаточно ли будет книг для того, чтобы стать бизнес аналитиком?
Ведь, как показывает практика, теория очень отличается от реальности, хоть и является основой.

Нашла такие книги:
— BABOK, — IIBA — A Guide to the Business Analysis Body of Knowledge-International Institute of Business Analysis (2015)
— Vigers Karl — Software requirements

Достаточно ли этого или лучше сразу вливаться в процесс и с практикой обучаться?

Спасибо

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

сомневаюсь что чтение книг поможет стать бизнес или каким другим аналитиком.

Спроси или у Лехи или у Егора )))) Реально будет быстрее и полезнее ))

Karl Wiegers, Joy Beatty. Software requirements (3rd Edition)
Посмотрите в её сторону. Возможно, что-то для себя найдёте

считаю что каждый аналитик, продукт овнер и остальные должны прочесть большу синюю книгу или хотя бы первых 10 глав(может 14) www.bookzone.com.ua/...ogue/catalogue_30948.html
для того что, понимать как выработать общий язык в команде

а какой у вас background? от этого тоже зависит.
ВАВОК есть смысл читать, когда будет уже практический опыт. Годик-два. До этого не воспринимается материал. Идет просто как теория.

Вигерс — да, must-read.

Если цель «войти в IT», то тут одними книгами по БА не обойтись. Нужно всякого разного читать по сфере разработки: и программирование, и тестирование, и soft skills...

Предыдущий опыт тоже важен. Если вы круто рубите в финансах, то можно и с минимальными знаниями по разработке попасть на соответствующий проект.

Цели «войти в IT» нет, уже опыт есть. Есть понимание по управлению проектами, business development процессам, взаимодействию команд, написанию гайдов, командной работе, анализу и струкрутированию данных. Разбираюсь в вёрстке и UI/UX дизайне. Но печалит отсутствие структурирования требований заказчиков и процесс разработки в целом, по общению с разработчиками из разных компаний. От этого страдают девелоперы и затягивается время сдачи проекта. Вот и хочется заниматься бизнес аналитикой + создавать нормальные ТЗ для оптимизации работы команды.

ага. ну это сильно упрощает дело.
Вигерс все еще в силе. К нему я бы добавил Writing Effective Use Cases (Alistair Cockburn). Юз-кейсы — это очень хороший (но не единственный и не универсальный) инструмент документирования требований. Чуть более развернуто здесь писал об этом analyst.biz.ua/...ting-effective-use-cases

Еще хорошо уметь рисовать диаграммы (я бы начал с activity и sequence), конкретных книг не посоветую, но в сети много информации и примеров.

Хороший инструмент — мокапы. Для сбора и визуализации требований очень полезно. (чуть больше тут analyst.biz.ua/2011/03/mockups и analyst.biz.ua/2011/07/prototyping/

Ну и в зависимости от того, по какой методологии работаете, у вас будет различный набор артефактов (видов документаци и пр.). Сейчас в тренде agile, поэтому скорее всего это будут пользовательские истории (user stories) и некие product vision / product requirements document и т.д. — их множество, и в каждой компании свои отличия.

Хорошо пишет про пользовательские истории Mike Cohn www.mountaingoatsoftware.com/books

Это то, с чего бы я начал. Инструменты так сказать. Ну а дальше уже нужно учиться ими правильно пользоваться: составлять и обновлять, собирать и анализировать требования, управлять ими.

Спасибо. Почитала отзыва по книге. Пишут, что много воды...

Там просто сложные вещи сложным языком для больших корпораций

Подписаться на комментарии