Рабочий день бизнес аналитика - Kompanii.top - большой справочный портал

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

А вот зачем нужен человек с модной профессией Business Analyst (BA), никто почему-то не понимает. Со стороны может показаться, что он целый день пишет документацию и, порой, отнимает много времени, обсуждая какие-то решения с командой. Чем занимается бизнес-аналитик, если уже есть PM и технический писатель?

Кто такой бизнес-аналитик — очередная прослойка менеджмента или лучший друг разработчика? Объясним в этой статье.

Кто такой бизнес-аналитик

Бизнес-аналитик — это человек, который стоит между бизнесом и командой разработки. Он собирает и выявляет требования к будущему продукту или функциям системы, а затем переводит их на понятный для инженеров язык.

Обязанности BA в команде могут варьироваться, но на всех проектах и во всех вакансиях бизнес-аналитика указаны 4 основные функции.

Управление требованиями: их выявление, подготовка и детализация, разделение запросов на требования и «какие-то не очень важные хотелки».
Стратегический анализ: во многих компаниях BA вместе с ТОП-менеджментом работает над стратегией развития компании и проекта, поскольку знает продукт лучше всего.
Проектирование решений: подготовка документации и, порой, создание прототипов. Все, чтобы придумать и донести до команды, каким образом решения будут разработаны и имплементированы.
Управление продуктом: коммуникация с дизайнерами, инженерами, стейкхолдерами, бизнесом и Product Owner-ами.

Зачем нужен бизнес-аналитик

Представьте ситуацию, заказчик присылает разработчику ссылку на конкурентов и говорит: «Мне нужен сайт! Точь в точь, как вот этот!» Программист: « Я не понимаю, что значит “точь в точь”, дайте ТЗ, меньше придется переделывать».

Заказчик идет к своему другу, по совместительству бизнес-аналитику, пожаловаться на программиста. Далее диалог между заказчиком и бизнес-аналитиком.

Заказчик: Вот ты мне скажи, ЧТО ТУТ НЕПОНЯТНОГО? Взять и сделать точно такой же сайт, неужели так сложно повторить?
Бизнес-аналитик (грустным голосом): Ну, вообще-то, я на стороне программиста. Непонятно в твоем запросе совершенно все. Сейчас докажу. Давай вместе посмотрим, что именно тебе нравится в этом сайте. Здесь есть кнопка «Сравнить», она тебе нужна?
Заказчик: Нет, не нужна.
Бизнес-аналитик: У этих ребят на сайте отдельная страница для доставки и еще одна — для оплаты, тебе точно нужно 2 верстать, или можно доставку и оплату объединить в одну страницу?
Заказчик: Можно совместить, мне и правда 2 страницы нечем заполнять.
Бизнес-аналитик: Видишь, уже получается не точь в точь, правда?
Заказчик: Я, наверное, имел в виду скорее визуальное оформление.
Бизнес-аналитик: А программист говорил о функционале.

Этот кейс показывает, насколько по-разному можно рассматривать один и тот же продукт (в данном случае сайт). Выходит, BA — тот человек, который может спасти проект от «сделали, но не то». Поэтому привлекать бизнес-аналитика лучше до того, как команда столкнется с проблемами в коммуникациях с заказчиком.

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

Кажется, будь у заказчика технический бэкграунд, это могло бы решить все вопросы. А вот и не угадали. Подкованные в техническом плане заказчики вместо того, чтобы сфокусироваться на составлении ТЗ, могут начать рассказывать команде, что и как делать, не обладая достаточной экспертизой в сфере. Или, хуже того, начинают писать код и отстаивают его имплементацию в проект. В этой ситуации BA выступает в роли психолога: напоминает заказчику о том, что на него работает команда профессионалов, и своими действиями он попросту замедляет процесс разработки. Команду, в свою очередь, просит относиться лояльнее к заказчику и не присылать ему ссылки на Википедию.

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

Постойте, но это больше похоже на работу Project Manager-а, разве нет?
В каком-то смысле так и есть. Не во всех компаниях выделены отдельные люди на обе роли, а с требованиями работать нужно в любом случае. Однако, в средних и больших проектах и у бизнес-аналитика, и у PM-а работы хватает на целый день (еще и с овертаймами).

Один день бизнес-аналитика в IT

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

10:00 — 12:00 Помощь команде

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

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

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

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

Что важно при работе с командами:

Быть на связи чуть ли не 24/7.
Фокусироваться на решении проблемы: выяснить, в чем суть, перевести разговор в позитивно-контструктивное русло и предложить альтернативное решение.
Эскалировать проблемы вовремя: не стараться все решить самостоятельно.
Проговаривать сложности, с которыми может столкнуться проект в случае изменений. Вовремя уведомлять стейкхолдеров.

Важно не зависать на коммуникации с командой и научиться понимать, когда все текущие вопросы решены и можно сконцентрироваться на другой задаче.

12:00 — 14:00 Написание документации

У документации есть один минус: если она слишком большая, ее никто не читает.

Что делает бизнес-аналитик на этом этапе:

Создает спецификации.
Описывает user stories / acceptance criteria / use cases.
Формулирует нефункциональных требования — описывает условия, в которых система эффективна. Например: «Система должна быть отказоустойчивой и совместимой с Google Chrome…».
Моделирует бизнес-процессы.
Прототипирует решения.

Что важно при написании спецификаций:

Заранее определить необходимые артефакты.
Описывать требования ДОСТАТОЧНО детально: ни больше, ни меньше.
Понимать принципы usability.
Придерживаться нотаций в работе с диаграммами.

14:00 — 15:00 Обед

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

15:00 — 18:00 Коммуникация с клиентом

Рабочие совещания — это те встречи, на которых можно не просто узнать о требованиях, но и докопаться до истинной потребности клиента. Другими словами, ответить на вопрос «зачем нам это нужно?» и подумать, действительно ли решение оптимальное, или есть еще варианты. Чтобы общаться с заказчиком на одном языке, нужно разбираться в предметной области бизнеса.

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

Важно! Валидируйте результаты с заказчиком и обязательно сохраняйте «аппрувы». Даже скрин сообщения в личной переписке считается за «аппрув». Доступ к тому же Slack клиента в любой момент могут закрыть, поэтому важно, чтобы вы хранили «аппрувы» у себя, рядом с требованиями.

18:00 — 19:00 Консультации с техлидами

Когда BA составляет требования, он должен понимать все смежные технические детали. Даже если он умеет писать код, на проекте за ним закреплены другие задачи, поэтому обязательно нужно советоваться с теми, кто занят разработкой: архитекторами, тим / тех лидами и предметными специалистами. На таких консультациях проговариваются высокоуровневые требования: каким образом их лучше спроектировать, внедрить, декомпозировать и так далее. Если в команде нет архитекторов, нужно идти к разработчикам и советоваться с ними. Прямая обязанность BA — понимать предметную область со всех точек зрения: не только со стороны бизнеса, а еще и с технической.

Из кого получается хороший BA

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

Роль BA в компании могут выполнять разные специалисты.

Sales Manager	Специалист по продажам — первый, кто начинает выявлять требования и понимать, что же хочет клиент. Опытные сейлзы прокачивают необходимые навыки BA, чтобы грамотно собрать первую информацию о предполагаемом продукте.
Account Manager	Аккаунт менеджер знает много о продукте и пожеланиях клиента, так что может сориентировать заказчика, куда развиваться.
Product / Project Manager	В рамках работы PM-ам приходится доносить требования до команды и управлять ими, поэтому на более-менее серьезном проекте не обойтись без знаний бизнес-анализа.
Тим лид или самый опытный разработчик	Девелопер может выполнять роль BA, если заказчик обладает хоть какой-то технической компетенцией. Эта модель чаще всего встречается в аутсорсинге.
QA инженер	Тестировщик понимает, что именно команда должна разрабатывать. В ходе тестирования QA составляет тест-кейсы и эти кейсы — чуть ли не единственная документация, по которой работает команда в отсутствие BA. Это не лучшая практика, но, тем не менее, она имеет место быть. Кстати, QA-специалистам достаточно нескольких месяцев, чтобы освоить дополнительные техники необходимые для BA и уйти в бизнес-аналитику.
UI / UX дизайнер	Дизайнеры много коммуницируют с клиентами и работают с обратной связью. Они могут рассказать команде, что и как должно работать. Поскольку дизайнер не разбирается в разработке, роль BA на таких проектах делится между дизайнером и командой.
Scrum master, Scrum team	Если команда работает по модели Agile, эти специалисты могут брать на себя роль BA.

Как стать BA?

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

Чтобы вырасти в бизнес-аналитика, нужно:

Понять роль бизнес-аналитика в своей компании, так как задачи от проекта к проекту могут сильно отличаться.
Определить свои текущие компетенции и сравнить с матрицей компетенций BA. Иногда, одна компетенция (к примеру, хороший английский) может стать решающей.
Выделить недостающие компетенции и пройти по ним обучение.
Овладеть основными техниками и методиками BA. Внедрять полученные техники в работу и отслеживать результаты.
Подать резюме на junior позицию с сопроводительным письмом. Важно написать, почему вы хотите работать в этой компании и почему они должны вас взять: что вы для этого сделали, какие курсы прошли и что умеете. Не бойтесь вместе с резюме подавать тестовые проекты, которые делали в процессе обучения — они станут отличным примером вашей первой работы.

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

Источник

Кирилл Рябков, руководитель отдела аналитики ПАО «Северсталь»

О рабочем бэкграунде

Основное образование я получил по специальности «Менеджмент качества» в Московском Государственном Институте Электронной Техники (ТУ).

Первый рабочий опыт был связан с основной специальностью. Занимался внедрением и поддержанием системы менеджмента качества (ISO 9000) в организации, осуществляющей услуги лингвистического перевода.

Работа состояла в оптимизации бизнес-процессов. Там же я увлекся и автоматизацией бизнес-процессов (внедрением информационных систем). Это увлечение определило мою дальнейшую судьбу в бизнес-анализе.

Профессии бизнес-аналитика и системного аналитика: в чем отличия?

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

Основная задача бизнес-аналитика – проработка бизнес-требований на предмет их влияния на сам бизнес.

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

Профессия может быть одна, но я сторонник того, чтобы четко определять роли и подбирать под них наиболее подходящих исполнителей.

Обязанности и основные задачи бизнес-аналитика

Из обязанностей и основных рабочих задач бизнес-аналитика могу выделить следующие:

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

Основные требования, которые предъявляют к специалистам работодатели

Основные требования к соискателям на позицию бизнес-аналитика выглядят примерно так:

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

Типичный рабочий день бизнес-аналитика

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

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

Стек технологий

Стек технологий, необходимый для работы бизнес-аналитика, минимален:

Confluence
Jira
Draw.IO/BPMN.IO
MS Office (Word, Excel, Visio, Note, Outlook)

На мой взгляд, технологии в бизнес-анализе имеют меньшее значение, чем умение коммуницировать с людьми и системное мышление. Кроме указанных выше технологий, могу выделить системы Process Mining (глубинный анализ процессов).

Трудности профессии бизнес-аналитика, к которым должен быть готовым новичок

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

Как и где лучше получить знания?

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

Рекомендую:

Изучать стандарт BABOK – это свод знаний по бизнес-аналитике от Международного института бизнес-анализа IIBA (хотя без практики и минимальных знаний будет сложно, но это уже достаточно важный первый шаг к развитию в профессии).
Курсы по процессному подходу (это основа для любого бизнес-аналитика).
Авторский курс Андрея Коптелова по управлению бизнес-процессами.
Книга «Процессный подход к управлению», В. Репин, В. Елиферов.

Диана Саввова, IT бизнес-аналитик компании DataArt

О рабочем бэкграунде

Я училась в Одесском Национальном экономическом Университете по специальности «Экономическая кибернетика».

Начинала свою карьеру с бизнес-анализа и это произошло случайно. Окончив четвертый курс университета я хотела устроиться на стажировку бухгалтером, чтобы получить опыт работы с финансами, но директор фирмы сказал мне: «Мы, конечно, можем тебя взять, но твоя специальность более широкая и техническая. У меня есть приятели в фирме, которые внедряют 1С. Стажировка консультантом по внедрению программного обеспечения тебе подойдет больше».

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

Профессии бизнес-аналитика и системного аналитика: в чем отличия?

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

Разделение этих двух профессий скорее зависит от проекта, и того, насколько бизнес-аналитик готов погружаться в технические детали.

Обязанности, навыки и основные задачи бизнес-аналитика

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

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

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

Если рассматривать классическое деление навыков специалистов на hard skills и soft skills, то в качестве soft skills важно: знание иностранного языка, умение кратко формулировать мысли и аналитическое мышление.

В качестве hard skills: знание методологии управления требованиями к программному обеспечению, прототипирование, умение работать с диаграммами, иногда использовать SQL.

Типичный рабочий день бизнес-аналитика

Условно мой рабочий день выглядит так (чаще всего это все-таки мультизадачная работа):

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

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

Стек технологий

Чаще всего я использую в работе такие инструменты: Confluence, Jira, Figma, Gliffy, Microsoft Teams. Для бизнес-аналитика не так принципиально использовать различные технологии, иногда достаточно Microsoft Word и телефона.

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

Трудности профессии бизнес-аналитика, к которым должен быть готовым новичок

Начинающие специалисты должны быть готовы к работе в команде, работе с возражениями и конфликтами, развивать свои коммуникативные навыки и уметь докапываться до сути проблемы, вместо «делать только то, что говорят».

Как и где лучше получить знания?

Советую начать свое развитие в бизнес-анализе с чтения литературы, такой как «Разработка требований к программному обеспечению» Вигерса К. и Битти Дж. и BABOK (Guide to the Business Analysis Body of Knowledge).

Можно осваивать профессию самостоятельно или выбрать курс по бизнес-анализу. Например, у школы IAMPM часто проводятся бесплатные вебинары с актуальными темами по бизнес-анализу, и не только. Также советую подписаться на различные аналитические сообщества на Facebook и в других соцсетях, там часто публикуют полезные статьи.

Выводы

Если вас заинтересовала профессия, можно получить знания самостоятельно с помощью упомянутых героями статьи материалов. Другой способ – пройти курс «Профессия Бизнес-аналитик» образовательной онлайн-платформы Skillbox.

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

***

Под руководством экспертов-практиков вы изучите системный и бизнес-анализ, чтобы помогать компаниям принимать стратегические решения и увеличивать прибыль, став связующим звеном между заказчиком и командой разработки. Успешно завершившие курс студенты получат диплом и смогут добавить в портфолио три выполненных проекта. Специалисты Skillbox из «Центра карьеры» помогут выпускникам получить первую стажировку и оффер от одной из компаний-партнеров.

Источник

Но самое главное, что должен знать и уметь бизнес-аналитик — это грамотная коммуникация со всеми заинтересованными сторонами. Очень часто он выступает посредником между теми, кто формулирует потребности организации, и теми, кто их реализует.

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

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

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

● Финансовый аналитик является экспертом в области финансового менеджмента. Он анализирует это направление деятельности, предлагает наиболее эффективные способы управления и перераспределения денежных потоков.

● Аналитик процессов специализируется на оптимизации работы в компании. Также он запускает новые продукты и разрабатывает подходящие стратегии развития.

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

●

Аналитик данных

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

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

Источник

Статья написана в соавторстве с Мэри Ротарь, CEO IAMPM.

Привет, меня зовут Кирилл Белявский, работаю бизнес-аналитиком в компании SoftServe и совмещаю это с должностью сервис-менеджера в офисе бизнес-анализа SoftServe.

Как бизнес аналитик я работаю на проектах, участвую в дискавери и пре-сейл активностях, провожу аудиты и оказываю консультации проектам для того, чтобы наши клиенты получали лучший сервис в плане бизнес-анализа. А как сервис-менеджер компании делаю так, чтобы нашим аналитикам было комфортно, чтобы у них было все необходимое для работы и развития. Помимо этого, веду лекции на курсах, выступаю на митапах и конференциях, участвую в вебинарах. В свободное время с другом веду подкаст о бизнес-анализе As a User I want to see.

Материал написан для начинающих бизнес-аналитиков, чтобы показать реалии IT-проектов и дать максимум практических советов. Все, что буду рассказывать, основано на личном опыте и опыте коллег, которых имел счастье узнать.

Рабочий день бизнес-аналитика

Рабочий день ВА проходит, как минимум, в трех измерениях

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

Рабочий день бизнес-аналитика проходит в прошедшем, настоящем и будущем спринтах одновременно, и его задача — постоянно балансировать на грани всех трех измерений:

В текущей итерации ВА помогает команде воплощать в жизнь требования спринта: отвечает на вопросы, что-то проясняет, сопровождает команду на моменте разработки требований.
К прошлой итерации относятся недавно реализованные требования — функционал, который разработали недавно и отдали заказчику. Теперь в текущем спринте заказчик может задавать много вопросов по работе функционала либо получать пользовательский фидбэк. Это он также будет обсуждать с BA.
Будущее — ВА обязан смотреть в завтрашний день и даже предвидеть несколько вариантов «завтра», потому что уже сейчас пишет и выясняет требования, определяет аспекты решения, которое будут имплементировать через несколько недель.

Как должны распределяться активности и как распределяются в действительности

Рабочий день ВА на 60% состоит из коммуникации: пообщаться несколько раз со всеми, ответить на письма, вопросы, поговорить с клиентом, командой, менеджерами. По 20% времени остается на документацию и анализ.

Рабочий день ВА — распределение активностей, каким оно должно быть

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

Рабочий день ВА — распределение активностей в реальности

Ненормированный рабочий день бывает еще и потому, что в аутсорсе работают с заказчиками из другого часового пояса, чаще из Америки. Вечером общаешься с клиентом, а потом, пока здесь ночь, на той стороне кипит работа — и с утра наваливается куча коммуникации.

Это приводит к быстрому выгоранию, поэтому для себя я вывел правила, которые делают рабочий день продуктивнее.

Правила эффективного рабочего дня

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

Главный показатель эффективности бизнес-аналитика — наличие свободного времени при выполненных задачах. Чтобы достичь такого состояния, я использую 6 правил, которые помогают выполнять запланированное, не растягивая рабочий день до бесконечности и не выгорая.

1. Не обсуждайте требования только с одним членом команды

Когда идет разработка, требования, как правило, разбиваются на кусочки. В скраме это User Story. Над одной стори работают минимум два человека, например, разработчик и тестировщик, который будет проверять эту функциональность. Обычно их даже трое: тестировщик, бэкенд и фронтенд разработчики. Сначала к ВА придет один участник команды с вопросами по текущей story, потом другой будет задавать свои вопросы, а потом придет и третий. Затем участники начнут разбираться между собой, у них не сойдутся показания, они снова придут к ВА — в итоге коммуникация займет массу времени.

Поэтому на проектах я говорю: «Ребята, приходите все сразу». То есть все люди, которые работают над одной story, должны прийти и поговорить со мной вживую или онлайн.

На удаленке мы создаем под каждую story в спринте отдельный чат в Teams либо в Slack и добавляем людей, которые будут работать над ней. Дальше коммуникация идет в одном канале по одному вопросу. Участники чата видят вопросы и ответы ВА, информация не теряется, а время экономится. В спринте много stories, но специалистов меньше, чем stories, поэтому они группируются — поработали над одной, пошли на другую.

Даже до удаленки, когда все работали в одном помещении и ко мне подходили по поводу story, я говорил: «Приведи остальных, кто работает над этой story, тогда пообщаемся».

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

2. Готовьте повестку с тайм-кодом для совещания

Не просто продумывайте agenda, а записывайте и придерживайтесь запланированной повестки. Это очевидный совет, тем не менее, на практике я часто вижу, что ВА не делают повестку и тайм-код совещания.

Тайм-кодом я называю распределение времени на каждый пункт. Например, при часовом совещании 15 минут пойдет на первый вопрос, 10 минут — на второй, 20 — на третий и так далее в зависимости от сложности вопроса.

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

Предварительная agenda и тайм-код сильно экономят время, но почему-то не все ими пользуются.

3. Избегайте совещаний, которые могли быть email’ом

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

Чтобы понять, нужно ли ваше присутствие, спросите себя:

Создам ли я какую-то ценность для остальных участников встречи?
Создаст ли эта встреча какую-то ценность для меня?

Если на оба вопроса отвечаете «нет», значит, на этот митинг идти не надо.

Как отказаться? Уточните у человека, который вас приглашает, чего он ожидает, какую пользу вы должны принести. Если он не может ответить, то не стоит идти на такое собрание.

Можно отказываться напрямую: «Понимаю, что это важно, но сейчас нет времени. Пожалуйста, напишите минутки (протокол) совещания в конце встречи, я позже прочитаю».

4. Избегайте мультизадачности

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

Для выполнения задач мне нравится использовать метод pomodoro. Идея в том, чтобы фокусироваться на какой-то задаче 20-30 минут, не отвлекаясь на другие факторы (сообщения, звонки и прочее). 30 минут — небольшой отрезок, и ничего не случится, если моментально не ответить на сообщение в мессенджере.

Метод полной концентрации на одной задаче особенно хорошо работает на удаленке, потому что здесь больше отвлекающих факторов.

5. Создавайте артефакты, которые можно использовать повторно

Как это выглядит на практике. Например, я делаю презентацию о бизнес-ценности какой-то фичи. Сначала использую ее для клиента и таким образом провалидирую: понял ли я бизнес-потребности, правильно ли расписал flow.

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

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

На своих проектах я стремлюсь создавать reusable requirements, то есть требования, которые можно применить повторно. Идея похожа на дизайн-системы, которые используют дизайнеры.

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

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

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

6. Добивайтесь фидбэка

Часто возникает ситуация, когда люди что-то не поняли и сделали не так, и ВА говорит: «Но я же написал email/в чат/в confluence» или «Я же указал информацию в требованиях».

Однако, если ВА написал, это не значит, что это точно прочитали. Поэтому бизнес-аналитику стоит спросить людей, видели ли они написанное и готовы ли обсудить информацию.

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

Когда ВА просто делает допущение, что разработчики вовремя увидят то, что нужно, он, по сути, опирается на неподтвержденную информацию, которую считает правдой.

Итог

Если коротко подытожить правила одним списком:

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