Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Как бизнес-аналитику организовать эффективный рабочий день

Статья написана в соавторстве с Мэри Ротарь, 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’ом

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

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

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось7
До обраногоВ обраному16
LinkedIn

Схожі статті




2 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Из всех пунктов вызывает сомнение только создание отдельного чата на каждую сторю. В остальном — абсолютно согласна!

Хорошая и полезная статья с эффективными советами, одобряю!

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

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

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

С этим кардинально не согласен.
Девелопер должен априори читать требования задачи и делать то, что там описано. Если он не прочитал — это его вина на 100%. По-моему это очевидно. И спрашивать каждого прочитал ли он таску, перед тем как ее делать ненужное занятие.
Другое дело, что они могут неправильно понять требования или додумать что-то свое. Для этого важно иметь хорошие грумминги/пленнинги, чтоб все четко поняли свои задачи.

мы создаем под каждую story в спринте отдельный чат в Teams либо в Slack и добавляем людей, которые будут работать над ней

Я себе с трудом представляю удобство 10-20 отдельных чатиков каждый спринт + фоллоу апы по старым таскам. Будет полный ахтунг, имхо.
Я обычно создаю тематические каналы под большие направления/фичи, куда добавляются все задействованные участники и где происходит обсуждение. Ибо важно, чтоб в курсе были все занятые люди, а не только те, кто делают одну конкретную таску. Внутри сообщения обязательно таргетируются при необходимости.

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

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