Прочитал книгу моего давнего френда Валерия Комскова "Введение в профессию бизнес-аналитика". Целью было более подробно ознакомиться с тем, как понимают эту профессию другие. С одной стороны, я достаточно давно в ИТ, и с аналитиками сотрудничал вместе почти на всех своих работах, естественное понимание роли имеется. С другой, как и вообще в ИТ, границы определений, что касается профессий, достаточно размыты: в одних компаниях понимают одно, в других другое. Хочется обобщения от человека, который в этом разбирается.

Главное преимущество книги в том, что она вообще есть. Если вы захотите стать бизнес-аналитиком, у вас не такой большой выбор учебных материалов. Есть много более специализированных трудов: например, по аналитике данных, по анализу маркетинга, по анализу оргструктур и так далее. Но если претендент решит выбрать это направление в ИТ (а аналитиков в компаниях трудится много, не сильно меньше, чем программистов!), то ему надо бы сначала ознакомиться с более общими подходами, погрузиться в контекст. У программистов с этим проще на порядок, как мне кажется: есть очень много материалов и по конкретным технологиям, и по архитектурам.

На эту же цель ознакомления с профессией работает первая часть книги: автор рассказывает, как сейчас устроена разработка ПО, какие роли, этапы бывают. Также в книге очень много места уделено разным нотациям - UML, BPMN, eEPC и т.д. Она годится если не как справочник, то хотя бы как навигатор по этой теме.

Теперь чего не хватило, на мой взгляд. Я бы хотел большего внимания требованиям. Видел аналитиков, которые регулярно путают функциональные и нефункциональные требования, связывают требования с конкретной реализацией, забывают об атомарности, не отделяют архитектуру от фичи и т.д. и т.п. В книге это есть, конечно, но очень сухо, пунктирно. Не хватает подробных примеров и особенно разбора типовых ошибок. Также не хватает внимания взаимодействию между аналитиком и другими ролями: как правильно, как не очень, как эффективнее. Может быть, с некоторой долей художественности, на конкретных примерах.

Ещё хотелось бы более чёткого понимания разницы между двумя ролями - бизнес-аналитиком и системным-аналитиком. Часто в вакансиях это воспринимается как две разные роли, со своими требованиями (маленький секретик: SA, как говорят, сейчас остро не хватает, и платят им хорошие деньги!). Бизнес-аналитик должен быть максимально погружен в продукт, в бизнес-контекст - эту мысль тоже хорошо бы донести до читателя максимально чётко. Потому что - опять же, из опыта - бывают аналитики, которые озадачивают разработку фразами типа "ну я не знаю, как это работает, но мне сказали..." или "непонятно, какую цель это преследует, но проще сделать так".

В завершение ещё раз хочу поблагодарить Валерия: книга однозначно стоит того, чтобы её прочесть и будущим бизнес-аналитикам, и тем, кто будет взаимодействовать с ними. Профессия действительно массовая и важная. ИТ-ландшафт всё сложнее, и основная работа плавно переносится из области "написать код, чтобы работало" в область "понять, что и зачем надо делать". Для разработки аналитики выступают как шея для головы: куда повернёт, с тем и будет иметь дело команда. И на мой взгляд, хороший бизнес-аналитик для производства ПО как бы не более важен, чем хороший разработчик!