Бизнес-аналитик в IT: как войти в профессию и что делать в начале

Отвечаю на 10 популярных вопросов начинающих бизнес-аналитиков.

Привет, я Денис Гобов, Senior Business Analyst и соруководитель сообщества бизнес-аналитиков компании DataArt, в котором состоит 200 человек. Из них почти четверть — джуниоры и трейни. Кроме того, я основатель и тренер центра Art of Business Analysis, изначально созданного для повышения квалификации специалистов уровней «мидл» и «синьор», но сейчас мы развиваем еще и джуниорские программы. Причина — кадровый голод: спрос на бизнес-аналитиков пропорционален невероятному спросу на разработчиков и тестировщиков.

Я собрал самые популярные вопросы, которые начинающие бизнес-аналитики задают мне и моим коллегам. Надеюсь, ответы будут полезны всем, кто только собирается стать бизнес-аналитиком в IT, — независимо от нынешнего места работы и должности.

Многие хотят работать именно в IT, но нет желания программировать. Тогда начинают рассматривать возможные варианты: тестировщик, руководитель проекта, аналитик. Я, наоборот, сначала был разработчиком, а потом стал бизнес-аналитиком. Это тоже довольно распространенный профессиональный трек.

В начале нулевых, еще в институте, я попал в крупный проект — мы разрабатывали для «Украинской железной дороги» систему, которая автоматизировала управление пассажирскими перевозками (бронирование и покупка билетов, составление расписания, заведение информации о свободных местах и так далее). В проекте все были равны, каждый немного общался с клиентом, писал код и тестировал. Там, где задачи были относительно простыми, схема работала, но на одной сложной подсистеме она дала сбой. Заказчик не принял наш первый релиз, потом второй.

Причина заключалась в том, что мы недостаточно глубоко разобрались в бизнес-процессах заказчика, не до конца понимали текущее и желаемое состояние. Соответственно, код не мог быть правильным, сколько релизов ни выпускай. Так в компании появился запрос на новую позицию.

Основное время в проекте я стал уделять общению с клиентом, документированию его потребностей, продумыванию решений, которые эти потребности закроют. И понял, что мне больше нравится не разрабатывать, а разбираться, что нужно клиенту и как это лучше сделать.

Это человек, который сначала определяет, где находится бизнес клиента и где он должен быть (куда мы идем?). Затем вместе с заказчиком и командой прописывает маршрут, чтобы с минимальными затратами принести максимальную пользу бизнесу. Это если коротко.

Бизнес-аналитик нужен на всех трех этапах проекта.

1. Предпроектный анализ. Занимает, как правило, 2‒6 недель. Задача аналитика — выявить текущее состояние бизнеса, его потребности и определить границы решений: что делаем, а что делать не будем. Это верхнеуровневый анализ. Если, допустим, клиент внедряет ERP — аналитик определяет, какие модули нужны, с чем интегрируемся, какие будут типы пользователей.

Главная сложность на этом этапе — сформировать единое видение для заказчика и разработчика: куда идем, что делаем и что не делаем.

2. Анализ в рамках проекта. Может длиться полгода, год и больше. Бизнес-аналитик работает с детальными требованиями: выявляет, описывает, моделирует и согласовывает. Управляет запросами на изменения, если в процессе появились новые бизнес-задачи, поменялся закон, регулирующий деятельность клиента, появились или изменились пожелания заинтересованных лиц.

3. Постпроектный анализ. После релиза аналитик оценивает, насколько решение соответствует планам, что мешает приносить заявленную ценность, какие улучшения можно внести. Обновляет базу знаний по продукту, если планируется дальнейшее сопровождение/развитие системы или это предусмотрено контрактом.

Иногда говорят, что бизнес-аналитик — переводчик между бизнесом и IT. Я считаю, что это человек, который организовывает совместную работу. Это равноправный участник круглого стола, за которым сидят разработчики, тестировщики, менеджеры проекта, заказчик, его поставщики и клиенты, регулятор в лице отдела контроля качества, государства и международных организаций. Вот фактически с ними, так или иначе, работает бизнес-аналитик.

С высоты птичьего полета все бизнес-аналитики делают одно и то же. Они изучают работу организации заказчика и предлагают способы достижения бизнес-целей. Это можно сделать разными способами, например, с помощью перераспределения обязанностей в коллективе, изменения бизнес-процессов, вынесения каких-то работ на аутсорс. Т. е. не обязательно нужно разрабатывать новое ПО.

Отличие бизнес-аналитика в IT в том, что его главный инструмент для достижения целей — именно ПО. В его проекте требуется разработка, доработка или внедрение коробочного решения.

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

Вот что отличает хорошего бизнес-аналитика.

На сайте Art of Business Analysis мы собрали расширенный список базовых компетенций бизнес-аналитика. Это то, что нужно развивать.

Главный результат — снижение неопределенности у заказчика и команды: появляется понимание, куда и как двигаться.

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

Еще один результат — база знаний, которая нужна, чтобы понимать, на основе каких требований система была построена. Она пригодится для сопровождения системы и переиспользования в других проектах.

У каждой компании — своя классификация. Расскажу, как мы в DataArt определяем джуна, мидла, синьора и эксперта.

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

Мидл решает стандартные задачи в рамках типовых проектов. Он работает самостоятельно, ему не нужна поддержка со стороны.

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

Основная ценность эксперта — в обучении других бизнес-аналитиков. У него огромный опыт, он подскажет, какой инструмент для этой задачи работает лучше, какие подходы к построению решения применить оптимальнее, с какими потенциальными задачами/проблемами проект может столкнуться в будущем.

Если вы уже работаете в IT (дизайнер, разработчик, тестировщик и т. д.), можно попробовать следующие варианты.

Если работаете не в IT:

Кроме перечисленных выше софт-скиллов будущих коллег интересуют ваши хард-скиллы и технические знания.

1. Выявление требований. Вы знаете техники, которые для этого используются и умеете их применять: интервью, анализ документов.

2. Специфицирование и моделирование требований. Вы умеете информацию по проекту изложить в структурированном виде или смоделировать.

3. Управление изменениями. Вы знаете, по какому циклу проходит запрос на изменение, какие вопросы нужно задавать заказчику.

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

5. Прототипировние. Вы умеете прототипировать элементы будущего решения, например, с помощью Balsamiq, Axure или Figma.

6. Декомпозиция. Вы знаете, как разбить сложную задачу на множество подзадач.

7. Методологии. Вы понимаете принципы Agile, отличия от каскадной модели и знаете, как строится работа бизнес-аналитика в зависимости от методологии.

Какие именно технические знания проверяют на собеседованиях — вопрос дискуссионный. В большинстве случаев спросят про SQL, т. е. навык написания запросов к базам данных. Точно нужно знать принципы, по которым строятся программные продукты. Хорошо бы понимать принципы объектно-ориентированного программирования и API.

Книги. Если вы погуглите этот вопрос, вам обязательно попадется BABOK (Business Analysis Body of Knowledge). Это детище Международного института бизнес-анализа (IIBA) — самой авторитетной ассоциации в нашей сфере. Однако я BABOK на начальном этапе не рекомендую, несмотря на то что я евангелист этой книги и провожу тренинги на ее основе.

Во-первых, она огромная. Во-вторых, построена как справочник и, если начать с нее, в голове образуется каша. Приступайте к этой книге, когда наработаете практический опыт — тогда лучше поймете, что там написано. Вместо BABOK советую шесть книг.

1. Handbook for the CPRE Foundation Level according to the IREB Standard. Позволит проникнуться терминологией бизнес-анализа и инженерии требований. Распространяется бесплатно в электронном виде.

2. Карл Вигерс «Разработка требований к программному обеспечению». Иногда говорят, что это библия для начинающих бизнес-аналитиков. Перевод на русский неидеальный, поэтому рекомендую читать на английском.

3. IIBA Global Business Analysis Core Standard. Это выжимка из BABOK, подготовленная IIBA. Распространяется бесплатно.

4. Алан Купер «Психбольница в руках пациентов». Легко читается. Интересный взгляд на индустрию, ПО и позицию бизнес-аналитика.

5. Dean Leffingwell. Agile Software Requirements. Поможет понять специфику требований в рамках agile-проектов.

6. Джозеф О’Коннор «Искусство системного мышления».

Вебинары и статьи:

1. Мой вебинар, посвященный подготовке к собеседованию.

2. Доклад Use Case VS User Story — сравнение двух самых популярных техник специфицирования требований. Извините, тоже мой.

3. Две статьи о том, как описывать требования к интеграциям: файловый обмен и API.

4. Много полезного на англоязычном ресурсе Modernanalyst. Форум, список из трех сотен книг, архив вебинаров и анонсы грядущих выступлений.

Статья основана на выступлении Дениса Гобова на IT talk.